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