ITSM 101: Change management processes

Discover the benefits of adopting ITSM's change management processes and learn about the hiccups that often arise along the way.

As IT organisations struggle to improve their efficiency and effectiveness, they must reduce unplanned reactive work while improving the quality of IT services provided to the business. IT old-timers groan because this has been true for a long time -- though how hard management stresses it can vary. There are countless management platitudes that sound great but yield little improvement. However, change management is a critical IT Service Management (ITSM) process that can really make a difference.

To be clear, change management isn't a magic elixir that will solve all the woes of the world. It will, however, help greatly reduce unplanned work while improving availability, security and agility, freeing staff to work on planned projects. Far from being a platitude that simply sounds good but can't be achieved, there is sound, proven logic to support the benefits of change management.

  • Human error creeps in during design, coding and operations. Any change made to systems creates a degree of risk that there will be a negative outcome.
  • Up to 80% of network availability incidents stem from human error, according to seminal work by IDC. Some organisations have more than others. Regardless, when the incidents arise, projects must be put on hold and resources redeployed until the crisis is addressed. This causes project backlogs and management frustration.
  • All things being equal, a system incident most likely stems from a change. Yes, environmental issues and hardware failure could be a cause, but the probability is lower. Eighty percent of repair time is spent trying to figure out what changed. If that can be resolved quickly, your data center will achieve higher availability and IT staff will have more time to focus on planned work.

Despite the evidence that change management and formal processes are effective, there's a very pervasive "cowboy" mentality in IT, where employees do not like to be told that they must follow a process. To implement change management, or any process for that matter, there must be conscious planned effort to change the culture as well.

Considerations for implementing change management
Rather than repeat what's in the ITIL Service Transition book about change management, let's instead review some real-world questions and comments that often arise when designing and implementing the change management process.

  1. Facilitate cultural change. The need to change the culture cannot be stressed enough, because the process must not be designed and implemented in a vacuum. In fact, that's usually a good recipe for failure. Instead, care must be taken to involve the right people during the design and implementation of a process. You must perform training, as well as offer communication and awareness programs. Job descriptions and compensation programs need to be updated to reflect the process. Last but not least, IT management, ITSM management and the change management process owner and manager must work hard to continuously sell and reinforce the need for change management.
  2. Why have a change manager? There must be defined accountability held by a person who is responsible for balancing the hazard associated with taking or not taking risks. This person must have the overall perspective of the organisation to ensure that changes aren't performed that may look good at a local level but could be problematic at a higher level. For example, a person in networking may think that updating a switch is low-risk without realizing that the planned weekend for the change is at the end of the accounting period and the change would create an unacceptable level of risk.
  3. Focus! It is best to design a process and implement it in a specific segment of IT where both the business and IT are willing to prototype and debug the process. It is far easier and less politically risky to change a process in a small area than to pursue an all-or-nothing approach.
  4. Start simple. As complexity increases, so too does the difficulty of cultural transformation and risks around the long-term sustainability of change management. Instead, plan for continuous process improvement and develop a roadmap that identifies how the process will evolve with each new release. However, be sure to start simple and learn. Sometimes just starting change management can be the hardest part.
  5. Multiple models. ITIL's change management process identifies the use of multiple models: standard, emergency, minor, normal and major. These are simply workflows that appropriately balance risk, cost and time. In fact, an organisation can have any number of models as long as they make sense and are clear as to which model should be followed when. Groups implementing change management would do well to identify their various models to enable the proper degree of agility and risk management.
  6. The standard change model is vital. Speaking of models, the standard change model allows for low-risk, predictable changes to be recorded and implemented. These changes do not need to go to the Change Advisory Board (CAB) and can allow IT greater flexibility. They still need to be performed only during the authorised change window and must be recorded so people can readily answer the question "What changed?" Over time, changes that meet the necessary criteria should be formally reviewed and approved to follow this model. The majority of changes in the organisation should follow this model. Note: There must be a means to formally revoke a change's "standard" rating should it become apparent that the changes are problematic for any reason.
  7. Beware of emergency changes. Emergency changes carry the greatest degree of risk to the organisation. Tremendous care must be taken so that IT personnel does not think emergency changes are a great way to get rush changes into production to compensate for lack of planning. Emergency changes should be a safety valve truly reserved for emergencies, and later tested and investigated by the CAB and a very concerned VP or CIO who want to know why someone put the organisation at risk.
  8. Criteria of a failed change. Groups often argue over what constitutes a failed change, because they are often linked to individual and group performance objectives and compensation. A change should be deemed as failed if an incident arises or the change cannot be implemented as planned. Note those two elements -- if an IT service is negatively impacted, the change is a failure. And when the change is being implemented, if it cannot go in strictly as planned, it is flagged as a failed changed and the rollback plan is executed. Failure cannot, and must not, be sugar coated. The ability to change must continuously improve over time. If change outcomes are not predictable, something is very wrong and must be corrected.
  9. Change detection. Automated tools can be implemented that help detect and communicate changes to a configuration item's approved configuration. By using these tools, a group can literally certify that systems have not been modified in any way and that the change management process is being followed. This is critical because both operations and information security have a tremendous need to understand as quickly as possible whether anything has changed.
  10. Accountability. IT personnel must follow the change management process, and when they choose not to, there must be defined consequences. Quality guru W. Edwards Deming noted that there are only two things you do with a process -- you either follow it or formally change it. There is no other option, and people must not be allowed to spontaneously deviate from processes that management has identified as necessary to mitigate risks. The Information Technology Process Institute performed a study of controls that correlated with high-performing IT organisations, and the top two were the ability to detect unauthorised changes and defined consequences (disciplinary measures) when the change management process was not followed.

Change management is a critical control process for IT. Far from being a purely bureaucratic control implemented to satisfy regulators, it has enormous proven benefits for the overall organisation. These include improved availability, lower costs, regulatory compliance, fewer security breaches and so on. The ITIL Service Transition volume contains the ITIL change management process that groups can use as a comparison and pragmatically borrow from as they embark on their journey of process improvement.

Reference: For more information about using IT change management to embark on a process improvement journey, read the Visible Ops Handbook published by the IT Process Institute.

Read more on Regulatory compliance and standard requirements