What is Change Management?
If someone told you that tomorrow you would wake up and everything you were told about the future would be here (warp speed, time machines, hoverboards, alien races on earth to borrow from pop culture) would you be ready for it? Change Management assumes that for most people the answer will be no. Most people need time to adapt to a new idea, process or system and in certain cases, such as automation; the change can have significant social or economic impacts.
Change Management is a combination of many things; tools and templates, a framework of processes, ideas, methodologies and even culture. As always within the Project Management ecosystem, there is rarely a one-size-fits-all solution so most organisations will define what their approach will be under a governance model. Ideally an organisation can use their change management approach for more than just projects because, let’s face it, we live in a dynamic and rapidly changing world.
Why do we need Change Management?
Project Management includes a focus on achieving outcomes, it is one of the reasons why projects exist and Project Managers have jobs. What then are the biggest risks that the outcome will not be achieved? The obvious answer is that the technical implementation will slip schedule, have scope creep, cost more money, and have too many defects in testing or many other typical risks. Yet one of the most commonly overlooked risks is adoption of the Product or deliverable created by the Project.
Change Management should feature during the initiation or inception phases of a Project to ensure change risk can be considered and an approach defined. Many frameworks exist which can be adapted relatively easily for most organisations such as ADKAR, PROSCI or Satir Change Management model to name a few (there are quite a few). It does take effort though which is why some organisations build whole functions to manage it.
As a rule of thumb, all projects should incorporate a Change Management Plan, which integrates with the Project Management Plan and will detail all the analysis and actions required to support the change. It is optional to create separate roles that will be responsible for this plan (establishing a dedicated Change Manager) but it should be made clear that Change Management is everyone’s responsibility including the recipients of the change.
As one key recommendation, when completing your Project and Change Management Plans, think about how much discretion you are allowing in adoption. The more discretion (the scale between a change being optional or mandated) applied to a change, the greater the adoption risk. In 2020, when companies had no choice but to send employees to work from home and go from physical collaboration to virtual. As a result there was little to no discretion applied to the change and millions of workers world wide rapidly adopted the changes including using new tools and systems, until the new status quo was a team meeting by video with household pets and children running around in the background.
Change Management can also be used to describe the control processes within a project (more often described as Change Control). Change Control differs from Change Management in that it is a set of processes (and controls of course) that mitigate risk of impacts to projects due to variation. All projects must have a change control procedure wherever there is the concept of baseline data whether that is the agreed Sprint backlog, a requirement now being developed, budget, time or other dimension.
Project constraints are there for a reason and provide the first set of controls. These are usually based on what was agreed during when the project was approved and a financial, time, benefits and any other relevant data became the first baseline. Things do happen though including events outside the Project’s control and the Project may need to adjust. There can be countless micro-adjustments made through the project lifecycle that are akin to steering a ship to keep it on course; some additional fuel consumed above plan but the destination reached on time. What Change Control will need is the concept of materiality agreed under governance. Setting tolerances can do this, for example if the budget is exceeded by over 10% of the baseline then change control is required.
Where material changes are agreed to, the project can then be rebaselined, which will allow for Key Performance Indicators to reset and the risk of more change monitored. The more change or variation to a project the unhealthier it is (that’s what a project auditor will likely see anyway) so it will always be important to actively mitigate changes before they impact the project and trigger change control processes.
The interaction between Change Management and Change Control
Baselines are set not just along project parameters such as time, cost etc. They are also set on the change itself. Change Management needs to know what the change is going to be in order to plan given within the plan are likely activities such as communication and training. Change Control can mitigate the risk of rework and ensure that the change tasks are completed as promised.