IT services strategy expert Derek Lonsdale, CIO adviser in the Cambridge, Mass., office of London-based PA Consulting Group Ltd., shares his hands-on experience with change management challenges. In this first part of a two-part interview, he identifies roadblocks to change and tells how CIOs and their change management process teams can avoid them. In
the second part of the interview, he talks about how CIOs can keep change management in sync with business demands and how they can lend their service delivery expertise to processes outside IT.
SearchCIO.com: What primary change
management strategy challenges do CIOs encounter?
Lonsdale: Businesses are now changing at a much faster pace than they used to. When the business wants to change something, they don't want to go through a bureaucratic change management process. They want things to happen at a faster, more agile pace than IT has been used to in the past. That makes it much harder for IT.
How can the CIO keep up with the rapid pace of change management?
Here's how the scenario usually works: The business comes up with some enhancement requests and sends them off to IT. IT then has to go through its risk analysis to make sure the change is OK, make sure the change is tested -- all the nitty-gritty of the fairly bureaucratic change management process. [The requested change] goes to a change advisory board, and there are multiple approvals before the business is told, "Yes, you can go ahead." IT has to streamline that process while maintaining the rigor within it to safeguard the data center and the environment they are releasing these changes into.
One way to overcome the bureaucracy of change management: Have a higher ratio of standard changes.
The ITIL [IT Infrastructure Library] change management process is considered a best practice; but what I've also seen done that is effective, is to use it alongside a much more customer-focused framework, like Lean or Six Sigma. Lean is all about focusing on the value to the customer, what the customer wants, and making sure that there is no waste within that process flow.
Within a standard change management system, there's a fair amount of waste. There's rework, there are multiple approvals, handoff of change tickets from one group to another group, and identifying who the approvers are in the first place. The fact that the change advisory board meets once a week probably means that the business has to wait until that meeting for their decisions to be made.
Does the change management advisory board often end up becoming a bottleneck?
It's complicated. In a recent project we did for an organization, we found that because they defined their change management process poorly, they had way too many low-priority changes going to the advisory board for approval. There were so many that they were clogging up all of the time for important change requests the business was interested in.
What we did was help them define what a "change" was. Quite often, there's a lot of confusion about what a service request is, what is a change and what is a project -- in other words, what are the right things to go through the change advisory board. With this project, we categorized a lot of those things as service requests instead. They were not causing any risk to the business if these things went ahead, so why should they go through a change advisory board?
What are the must-haves for an effective change
management process strategy?
This organization had to start by addressing the following questions:
- What is the importance of change management?
- What is its purpose?
- What are its goals?
- What are the benefits of a new process
- What does a change management process look like?
- What are the key performance indicators for the process?
- What is necessary to make that change management process happen in the business?
- What people, process and technology changes are required?
We say the purpose of change management is to protect the environment, but what is the scope? Does the process just cover things in production, in QA [quality assurance], and test? Does it include things in the development environment? Including production is always a yes; QA is sometimes a yes; but we don't recommend that development be part of the scope because there are too many changes and it's too bureaucratic. If there's any request that takes more than 10 days of effort, then it's a project, not a service request. That's a good baseline to start with. These are all simple questions, but if they are not answered up front, they can really derail your change management process.
More on ITIL and ITSM
How much should the change management process be automated, and in what areas should it
The approval process has to be automated. You can have standard changes that should be automated, regular changes that happen every month, such as rebooting a server. Anything that is repeatable, where you understand the risk -- where it's the same resources involved all of the time, never caused an outage, and so on -- can be a standard change. That's one way to overcome the bureaucracy of change management: Have a higher ratio of standard changes.
Let us know what you think about the story; email Christina Torode, News Director.
This was first published in June 2012