Three Critical Elements for Successful Change Management in IT

This is the second of our two-part blog on change. Last week’s blog, available here, focused on the three types of change: static, dynamic, and complex, the techniques for discerning the kind of modification needed, and the way to implement the change based on type. We delved into the Container, Diversity, and Exchanges model, which helps you find the way forward in a complex change environment.   

This week, we will examine three critical elements for managing modifications: definition and initiation, communication and monitoring, and training and support. No matter how much modification is needed, the change and, potentially, the project are at risk if these three elements are not handled properly.

Definition and Initiation of Change

Many changes fail because they start wrong and do not follow a clear change request process.   It does not matter if your project is Agile or Waterfall. You must have a change request process that clearly defines the who, what, where, when, why, and how of the change. Here are some questions that must be answered in the change management request.

• Who can approve the change, and who is being impacted by it? Have all the required stakeholders approved the change, and are there any conditions accompanying its approval?
• What are the specifics of the modification, including how we will handle any progress in the previous direction?  For example, if you have progress against a specific requirement that has been altered or removed, how do we handle the completed work?  Do we have to make changes to remove the progress or leverage it to implement the new requirements?  Too often, this element is not defined, which causes problems later.
• When will the change occur? Before initial rollout or later? Also, when are modifications allowed in the project plan schedule? The schedule must have enough time to make, test, and train for the change.
• Where is the request documented? Is it a particular system like Jira? Another “where” consideration is the locations to which the change applies, especially if an organization is multinational.   
• Why are we modifying?  If we are changing to increase ROI or enable a new feature, have we devised new metrics to measure our progress?  Our progress against the why of the change has to be measured.
• How is the change going to be made?  Will we use a particular process or tool to expedite the change?  The details about how the change is being made can impact the change’s implementation or impact whether the change will be done at all.

A detailed Impact Analysis is crucial to initiating and implementing the change order.  The impact analysis must consider all elements required for the change order, including changes to requirements, quality assurance, training, processes, and other related features.  Many times during my thirty years of advising projects, I have had to call into question the impact analysis performed for a change order. 

One key point often neglected is accounting for upstream and downstream impacts of change.  A change on the front end of an application usually impacts an interface or API.  On the other hand, a change in an interface also necessitates changing how data is captured on a screen or even the data entry process and associated training.   The better the impact analysis, the better the change!

Once the change is defined correctly, you must adequately initiate it.  How a change is initiated depends on its relationship to other project elements.  Sometimes, it makes sense to bundle several changes together in a release.  Other times, the change is so significant that it requires its sprint or release. 

Whether bundled or not, you should communicate the impact of the change to scope, schedule, budget, and project risks as part of an ordinary governance meeting or, if large enough, a separate kickoff meeting. 

In the change initiation meeting, it is just as important to say what is not being done as it is to say what is being done.  The team and stakeholders need to know when a requirement has been removed or changed to avoid missed expectations or additional work on a no longer desired feature.

Communication and Monitoring

Communication about a change only begins at its initiation. You should create a communication plan for stakeholders, partners, and users throughout the project. The plan should include stakeholder meetings on the progress of the change against the plan and expected results. Likewise, you need to have a proper communication plan for interface partners so they can adjust their plans accordingly.   Sometimes, trading partners will not be able to meet your schedule, and accommodations will have to be made. 

Lastly, it is essential to keep users of the system or process affected by the change apprised of progress. One best practice is having a super user group that gets an early look at the change through mockup or beta testing. Super users will be the best advocates for the change if they are brought up to speed on the latest progress.

To communicate progress properly, you need to monitor against critical metrics and milestones associated with the change.  You should establish the associated metrics and how they will be monitored during the change process.  Define interim milestones and proof-of-concepts for significant changes.  You can then incrementally monitor and assess if a change has the desired outcome and adjust if the results are unexpected.

Training and Support

Each change management plan needs to include training, support, and documentation. The most needed, properly implemented software or process change will fail if users and trading partners are not trained. Likewise, calls may overwhelm support personnel if users are not trained on the change or if support documentation is unclear or missing. 

Here are some best practices I have implemented on projects related to training and support.

• Plan for training environment and playground early in the project.  Over the years, I have seen too many project plans that do not include technical support or resources for creating a training environment and practice training playground.  They are two different things.  A training environment with static scenarios needs to have the ability to be refreshed easily by the trainers.  It is also good to have a practice environment where users can execute ad-hoc scenarios.  Both environments require user support and provide an opportunity to train application support personnel before going live.
• Conduct an operations readiness desk with Level 1, 2, and 3 Help Desk scenarios.  You need to train your support staff as well as users.  While you will get some support training from User Acceptance Test and Training Support, practicing the feedback cycle between the call center and application maintenance teams is essential.  The more you can script call center responses to resolve issues on the first call, the less likely you will have long hold times.
• Plan for Hyper Care.  Changes are very seldom painless.  To lessen the pain and get it over quickly, plan for extra support and at least daily communications with super users to resolve problems and user training issues upfront. 

I have touched on three of the critical elements of change management.  The ability to change well is as much an art as a discipline.  You cannot simply define the change and hope all goes as planned.

I will close with a poem on our three critical elements of change.

When making a change,
Don’t fire and forget,
Or the results that come,
You’ll soon regret,

Instead, start the change,
With proper analysis,
In this way, you’ll avoid,
Project paralysis.

Then, communicate and monitor,
Both night and day,
To ensure your client,
That everything is ok.

And plan for training,
And help desk support,
So you will achieve,
A good report.