Earlier this month Forrester issued a report entitled “The State of IT Service Management In 2011”. In conjunction with itSMF USA, Forrester surveyed 491 ITSM professionals and the report of results by Glenn O’Donnell contains a lot of interesting insights.
The one that interested me the most was the state of Change Management. Although 95% of the survey respondents were from North America, my experience in Australia and elsewhere tells me that the findings would be consistent with the state of Change Management in other countries.
The survey asked, “What percent of your Incidents are the result of change to IT infrastructure, applications, processes or tools?”
The following graph shows the results.
Source: Forrester / itSMF Q2 2011 US ITSM Online Survey
20% indicated that less than 10% of their incidents were the result of these type of changes. Although not a perfect score (which would be zero) this is a good result for 1/5 of the respondents.
So, a fifth are doing ok, over half (58%) are operating in unacceptable environments and nearly a quarter just don’t know! The latter is the most worrying of all the results.
Change Management as a process has been around since the earliest days of ITIL. It has been developed and improved but the basic principles haven’t really changed that much over the years. So why is the state of Change Management in such a state of disarray?
I believe there are two key reasons. Firstly the implementation of a change management process that is so inflexible and difficult to navigate that it will be bypassed and secondly the failure to implement a change management process that covers the entire service lifecycle.
The report talks about ITIL maybe being too ambiguous in regards to Change Management and also says “If you interpret ITIL with too much dogma, the process becomes overbearing and impedes progress. If the change process is too draconian, people will circumvent it”.
The latter is certainly true. I have seen too many organisations implement a change management process that is overly rigid and does not allow for the application of common sense that people circumvent it.
Generally, people do not deliberately try and bypass process. They do so when it does not work. They do so when it impedes the ability to respond to business needs. They do so when it is a bottleneck. They do so when the project is demanding progress and the change management process is inhibiting that happening.
The other failure has been the implementation of change management process as a operational change control mechanism i.e. the gateway to production. In most organisations, the change management process is initiated when all the design, development, build etc. has been completed and the change needs to be moved into production. All of a sudden, the project or change team are asked to jump through hoops of which they had no prior knowledge in order to move the change into an operational state.
At this point, even if the change is deemed as not suitable for operational use, the chances of “rejecting” the change is limited as all the investment has already been made. The change management processes, like other ITIL processes, is a lifecycle process. It should be initiated as soon as the need for change is identified. This may be an outcome from the service portfolio management process, service catalogue management processes or the incident / problem management process.
The change management process should ensure that the investment in making the change is justified before any work takes place. The process should ensure that everyone involved in making the change understand the criteria by which the change will be accepted into operational use so that there are no surprises when this stage in the lifecycle is reached.
Our industry has “flavours of the month” when it comes to ITIL processes. A few years ago it was Configuration Management and before that it was Service Level Management. Now it is Service Catalogue Management. I think we should take a step back and go back to basics. Take a good look at some of the less “sexy” processes that have been around a long time and make sure they are working effectively before deciding on the next initiative. The truth is, that if your basic processes such as incident and change management are not working effectively, the rest of the your process initiatives are likely to fail as well.
Processes should be subject to incident and change management just as infrastructure and applications are. Therefore if these processes are not working, how can we effectively manage issues or improvements to other processes?
So, it is time to check where you would fall if you answered the survey question posed. If you are in the “less than 10%” group then well done. If you are anywhere else, you need to determine why your change management process is not working.
The Forrester report can be purchased from Forrester at:
It is also available free to itSMF USA members at: