Uncertainty is uncomfortable for everyone. Whether it’s political turmoil or a reorganization at your company, employees who are concerned about their future are likely to be distracted and unproductive.
From Pocket https://ift.tt/2m2RjF0
Uncertainty is uncomfortable for everyone. Whether it’s political turmoil or a reorganization at your company, employees who are concerned about their future are likely to be distracted and unproductive.
From Pocket https://ift.tt/2m2RjF0
DevOps is the hottest buzzword in the world of service delivery. More and more organizations are jumping onto the DevOps bandwagon in the hope of transforming their broken product delivery pipeline. And yet, not many people know what exactly DevOps is.
From Pocket http://ift.tt/2xlwdHM
There are many paths to growth, and high performers take more than one—supported by reinforcing capabilities such as advanced analytics and digital customer-experience management.
Growth is a tonic for most companies.
From Pocket http://ift.tt/2hR6ALl
Here are a few things I seem to be saying a lot lately, while immersed in driving DevOps transformations. 1) Patience patience patience. Some people have to see and feel it to believe it. It takes years to change a corporate culture, to bring everyone along. 2) Evolution not revolution.
From Pocket http://ift.tt/2oivYw8
IT is evolving from simply managing technology to becoming a trusted strategic business partner that empowers the business.
Source: IT Service Management: Transforming IT from managing technology to empowering business
Published in the Service Management Paper of May 26th, 2015
Many people recognize DevOps as an enormous benefit — faster application deployment, automated toolchains, support of more granular updates, better cooperation across groups. However, less appreciated is the journey enterprise IT groups need to make to achieve this outcome. The plain fact is that established IT processes reflect a very different set of goals: stability, infrequent change, hands-on administration, and alignment with ITIL. So how does an enterprise IT organization implement change to achieve DevOps outcomes?
— more
This is a link to an article from the daily Service Management Paper. This paper is published through an automatic process every day. On this site I start collecting the articles that are of interest as a way to archive the papers,
Published in the Service Management Paper of May 26th, 2015
Implementing IT service management (ITSM) in your organization is no walk in the park. When you plan to implement ITSM, you may have to encounter questions such as where do I start? How do I start? What am I trying to achieve? What information must be obtained from the processes I have, people involved, and the product? If you don’t have complete answers to your questions,your ITSM implementation might fail. Here are 10 reasons why an ITSM implementation can fail.
— More
This is a link to an article from the daily Service Management Paper. This paper is published through an automatic process every day. On this site I start collecting the articles that are of interest as a way to archive the papers,
There are many reasons why ITIL implementations fail and I want to mention some here:
1. Trying to IMPLEMENT ITIL. ITIL is not an Implementation Framework, it is a reference framework for IT Service Organizations. It is a bit silly to try to implement a reference framework. You do not implement the encyclopedia or the phone book either. You can use ITIL as a reference framework when you transform your IT department to a mature IT service organization. Leaving you to choose which of the best practices to use and how to use it. If you want to use ITIL as a standard for implementation, please don’t. Use something like ISO20000 instead. Because everyone is talking about Implementing ITIL, I’ve grown used to the concept of ITIL implementations. It should be ITIL Transformations.
2. Starting with the CMDB: It has been argued before by several Service Management Guru’s that trying to set up a CMDB is very difficult. To do it well is almost impossible. It is a daunting task to start with and it will not bring any additional benefits to an ITIL transformation. When you’ll try to set up a CMDB together with some of the staff involved, you’ll end up with more specifications than was needed to design the Apollo program (allright, that is a but too much, but it will be very close). CMDB’s are useful when applied lightly. Otherwise it will mainly distract from reaching the desired results.
3. Designing the processes with the staff involved: I’ve used to think that it is wise to have the people responsible for doing the processes help to design the processes. Now I know I’m wrong. I’m not against involvement of the ITIL Transformation victims at all. But, at the right time and with the correct starting point. Now I’m a firm believer of Design Top-Down and transform Bottom-Up. Involving staff in process design has several negative aspects: 1. it demonstrates that process design is not difficult at all and anyone can do it, certainly the system operator with limited education. 2. It is an easy way to obstruct any possible improvement of IT by taking forever to come to an fully agreed design. 3. When there are no guidelines on the results the processes are suppose to deliver than all this design work is futile to begin with. In the end you’ll have wasted time of the IT staff and in the meantime the number of incidents have gone up since the incident solvers were in a workshop. Well done!
4. ITIL (or ISO20000 for that matter) are a goal in itself. And when that is the case you’ll have a couple of meters of paperwork to show for a successful project (specific when it was run in a Prince2 way) and the RFI for the next ITIL project on your desk. I’ve been in organizations where they had evidence (ic. handbooks) of 6 ITIL implementations. And still they were no where near to delivering services to the business satisfaction and against reasonable costs. If there is no clear goal, in terms of business value and strategy, then almost all ITIL transformations will certainly fail.
5. Thinking that ITIL is only for the operational IT management part of IT. In Holland they call IT management ‘Beheer’ and this is the least sexy part of any IT organizations. If ITIL is for ‘Beheer’ then anyone else do not want to be involved. It makes for very interesting situations where the developers, project managers, architects and others are doing their upmost best to stay out of Incident- or Change management. Which means that only a small part of the IT Service Organization is trying to transform to become more service- and process-oriented. Which is not found to be a successful solution.
What to do when you want to Implement ITIL, sorry – transform your IT department according to the guidance offered by ITIL?
1. Create a Change Program for your IT Department using ITIL and other frameworks for guidance
2. Define clear results in term of Busines Value that the IT department has to achieve
3. Based on these results design the processes on reaching these
4. Train, develop, coach, train your IT staff in all aspects to be able to execute these processes and to achieve the desired results.
5. Start using the processes as soon as you can, and discover in using them how to improve these processes and what tools you need. And get these tools.
I wonder what more reasons we can find for all the failing ITIL implementations and what would we advise to prevent more failures from happening?