The 7 Deadly Sins of Change Management

Many businesses, and IT organizations, become frustrated with a lack of agility and responsiveness with their change management process. Rather than being viewed as a “value enabler,” the change management process is often seen as overly bureaucratic and a hindrance to getting things done. But in my experience, these issues usually boil down to a poor implementation and misunderstanding of the purpose of change management.

What Is the Purpose of Change Management?

The change management process has three primary purposes:

• To ensure the appropriate planning, review, coordination, and communication of a change.
  While not all changes are created equal, all changes must have the appropriate degree of planning, evaluation, approval, orchestration, and communication. Without these elements, there can be no control over the managed environment, which ultimately means that the business cannot rely on IT.
• To protect what’s already in production.
  A change must have no negative impact to services that are already in the managed environment.
• To ensure that a change delivers the intended result.
  The whole reason why a change is being made is to deliver a planned result. If a change is implemented, but it does not deliver the intended result, this points to larger issues that must be addressed.

Seems rather straight-forward and common sense, doesn’t it? So why do so many change management implementations result in frustration, subterfuge, and headache? Perhaps you’ll recognize some reasons in my list below.

The Seven Deadly Change Management Sins

1. Every request for change has to go before a change advisory board (CAB).
   Out of all the sins, this is the one that I see most frequently. Because change models and evaluation criteria are not defined, *every* request for change – regardless of complexity, resource needs, or impact – gets dumped onto the CAB.
2. No true management support.
   This is my second-most encountered issue with change management implementations. I believe that management – especially senior management – must exhibit strong, visible support to ensure an effective change management process. But what I often find when it comes to enforcing policies and supporting the process, is that senior managers do not want to (visibly) enforce the very policies and process that they commissioned!
3. Request for Change (RFC) not raised…until just before implementation.
   This behavior essentially guts the change management process by bypassing the crucial initial review, evaluation, planning, and communication of upcoming work. This action in turn, has a cascade effect on work that has already been planned, resulting in resource conflicts.
4. No one, other than the change manager, has any accountability for the success of the process.
   I frequently encounter the misconception that once an RFC is logged, then it’s the responsibility of the change manager to coordinate all of the activities related to the change. The fact is that the change manager is accountable for the operation of the process – and ensuring that the handling of each RFC follows the process – not the design, build, testing, and implementation of a change itself.
5. The change schedule is not published outside of IT – sometimes, it’s not even published *within* IT.
   The change schedule is intended to promote communication and transparency, not only regarding the change management process, but also regarding the demand and workload within IT.
6. CABs do not have the proper membership.
   CABs are often just made up of IT personnel, with no participation from business colleagues.
7. Process over engineering.
   When discussing change management, I often use the analogy of the control tower at an airport. The control tower ensures that at any given time there is one and only one airplane on any given runway at the airport. The control tower does not pilot the plane, does not manage the loading and unloading of passengers and cargo, nor the servicing of the aircraft, and so on. Those activities belong within other roles and procedures. The control tower’s job is to ensure safe landings and take-offs. A good change management process is like the airport control tower – but unfortunately, many change process definitions include all of the other “airport operations” that really shouldn’t be there.

Any of the above sound familiar? It’s no wonder that our business partners are frustrated. It’s no wonder that IT is frustrated.

Seven Things You Can Do to Fix It

If your change management process is suffering, here are seven things you can do to fix it:

1. Define change models.
   A change model is simply a pre-defined way of implementing a change. Executing the steps within a change model is often the fastest way to implement a change.
2. Define and enforce the responsibilities of the change owner.
   The change owner is accountable for the success of a change, not the change manager. It is the change owner who is responsible for capturing the requirements for a change, ensuring the design and build of a change, defining and executing appropriate testing, and ensuring a smooth implementation of a change.
3. Define evaluation criteria.
   Not all RFCs should go before a CAB for review and authorization. In fact, in a well-defined change management process, most RFCs should be authorized by someone other than a CAB. Defining evaluation criteria helps ensure the “right” RFCs go before the “right” people as defined in… (see my #4).
4. Define a change authority matrix.
   Defining and following a change authority matrix identifies who the “right” people are to review and authorize RFCs. Have your senior management review, approve, and sign-off on it – this helps enforce accountability – and get management commitment.
5. Publish the change schedule – to everyone.
   Not only will this improve change management awareness and communications within IT, it is a great way to illustrate how much work is getting done by IT.
6. Produce and publish metrics that make sense to the business.
   While publishing the number of changes implemented within a timeframe is nice to know, measuring and publishing the business improvements resulting from the implementation of a change is much more meaningful. For example, if a change is intended to reduce order processing time – measure that!
7. Remove any non-value added work and wait time from the process.
   For example, why arbitrarily conduct CAB meetings on a weekly basis? Take a page out of Agile and use the daily stand-up meeting like a “CAB meeting.”

Is your change management process not producing the results your organization needs? Even worse, is your change management process in the way of making changes? Don’t give up – these seven fixes are sure to move your change management process from being the “barrier” to being the “value enabler”!

If you’d like more tips, I highly recommend Stuart Rance’s blog listing his top tips for supercharging your requests for change. And for the beginners out there, Joe The IT Guy does a great job explaining the basics in his blog ITSM Basics: A Simple Introduction to Change Management.