replace most face-to-face communication at a practical level( Agile Principle: Give them the environment and support they need, and trust them to get the job done). From email to Instant Messaging, from VoIP to Tele-presence and from virtual desktop to( internal) social media, there are plenty of options to communicate. What counts is that the right medium is chosen for the right messaging. Individual coaching is of course best done face-to-face, but operational discussions can take place through any other medium.
Organisationally, a culture should be developed that permits teams dealing with service management to be empowered to handle issues themselves as much as possible( Agile Principle: The best architectures, requirements, and designs emerge from self-organizing teams). This requires first of all a management culture that is happy to delegate and at the same time provide support to their teams where needed. This is contrary to the top-down management structure you see in more traditional companies. On the one hand, this relates to the management support that is required in ISO 20000; on the other hand, it supports the Agile idea of self-organising teams, where the decision-making power is as much as possible delegated to the teams who are running the show practically. Secondly, the structure of the organisation changes along with the culture: when more decision-power lies with self-organising teams, a hierarchical structure is less needed to exert control over those teams. You do need a certain level of supervisory management to make sure that the output of the various teams gets aligned with each other and with the overall vision for the company. Management is also needed for“ removal of impediments” to productive working( a classic Scrum Master task) and for people management tasks such as performance management and coaching. You do not need the heavy hierarchy a lot of traditional IT companies are suffering from, though. In practice, service providers can have somewhat smaller teams organised around the services provided, where there is a cross-functional ability within the teams to support services through their design, implementation and operation phases. This also does away with the stove-piped organisations where each function is in its own tower, which makes it difficult to establish cross-functional processes that depend on a lot of handovers between towers.
Managing Change Change is a given in life and that also applies to service providers( Agile Principle: Welcome changing requirements, even late in development. Agile processes harness change for the customer ' s competitive advantage). Change expresses itself in changing service requirements, changing products and services, a changing competitive landscape, changing tools and technology and many more variations of change. In fact, one of the reasons why I stopped being an engineer at some point is the fact that I got tired of having to keep up with new technologies all the time( I had developed a greater people-focus in the meantime, resulting in having to deal with change on the people side instead). In contrast to all this change in the IT services industry, service providers are often slow and rigid in adapting to change, if not plainly resistant to it. It is after all deemed safer to stick to what you know and what you are good at than having to adapt to new things all the time. Until you are out of business because nobody is interested in your services anymore, that is.
Agile, in its origin as a software-oriented mind-set, tells us to embrace change, simply to be adaptive to ever-changing customer needs. It is that type of change that happens most often in non-software environments as well: numerous are the cases where between contract-signature and implementation of a service the customer has changed his mind and decided they want something quite different from what was originally agreed. Network service providers, for instance, often have a hard time coping with this, simply because the nature of their business is traditionally so rigid: even simple changes such as upgrading bandwidth on an Internet circuit can be a pain that takes several weeks to implement. By
14 itSMFI Forum Focus— June 2017 extension, embracing change should also cover other types of change, such as market change, technological change, etc. Services should be developed taking a continual need for change into consideration.
How do we get this mind-set put into practice in a services environment? This can be done by making the services as flexible as possible from the start. The above network services example is in fact a good one, for new technology permits a whole lot more flexibility nowadays: paradigms such as Software-Defined Networking( SDN) and Network Function Virtualisation( NFV) cater for a lot of adaptation to changing customer requirements. This is a start at a product or services level. Now the whole Service Management System supporting this service needs to be made flexible as well. This includes putting flexibility in everything ISO 20000 tells you to. I believe this can be solved by keeping things simple( Agile Principles: Simplicity- the art of maximizing the amount of work not done- is essential): simple, intuitive processes, metrics and reporting that are easy to use, straightforward to produce, well understood by customers and that can be equally effortlessly changed when needed. It is the cumbersome nature of some service management processes( and their supporting systems) I have seen that makes service providers inflexible, so if these processes are simplified, not only does the organisation become more efficient, it also provides the opportunity to change them as and when required.
Change Management While we are on the subject of change, let’ s take the Change Management process as an example. There is often a kind of tension between the people running the services( i. e. the operations side) and the people wanting to change the services for the better( i. e. the development side). The operations people want as little change as possible, given that any change is a risk for the
continuity of the services. The development people want to continually enhance the services in order to improve them. The way forward is necessarily that there needs to be a middle path between the two perspectives, again from the viewpoint of value creation.
Customers usually want their change requests to be implemented both as quickly as possible and as safely as possible, i. e. without disruption to the live environment. Quick and safe only go together if a number of aspects is catered for:
1. Thoroughly developed and tested service enhancements( part of the Release and Deployment process and / or Design and Transition of New and Changed Services process in ISO 20000);
2. A regular planned release schedule – if we are working in an Agile way, iterative service enhancements( more on iterative aspects in Agile service management later) should be accompanied by an equally predictable( and frequent) release schedule in which changes are deployed that have been developed until then;
3. An efficient, simple and flexible Change Management