On Taking the Time to Do Change Management Right

Change management is time-consuming and does not always produce positive results that are immediately apparent. As such, it can be tempting to save time on projects by cutting corners on change management. But doing so misses the whole point of change management.

By Kevin Turgeon

23 August 2024

Good change management takes a lot of time and effort, and its positive results are not always immediately apparent. This makes it tempting to save time on a project by cutting corners on change management. Doing so, however, typically reduces stakeholder support and overall project success.

Following good change management practices is time-consuming and does not always produce immediately apparent results. Consider the following example of a project team developing the timeline for part of a project. Suppose the project team wants to follow good change management practices while creating this timeline. In that case, they will need to determine the significant stakeholders for this part of the project, pull them together and get their input on what the timeline should look like, draft the timeline, pull the stakeholders back together and get their thoughts on the draft, revise the draft, and finally get the stakeholders approval of the final timeline. All of this work will take a lot of time and might not result in a timeline that is much different than what would be created by a project manager and a few subject matter experts working in isolation.

Since following good change management practices does not always produce different outputs than not doing so, it is tempting to save time on a project by cutting corners on change management. But this misses the point of change management. The objective of change management is not to produce superior project outputs in the form of documents, artifacts, and deliverables; change management aims to increase stakeholder support for the documents, artifacts, and deliverables created as part of a project.

People are more likely to support things they have a role in creating than things created without their input, even if the thing created without their input is identical to what would have been made with their input. As such, choosing not to include stakeholders in the development of project deliverables, even when doing so will most likely not significantly impact the form of the final product, is a bad idea because it will decrease stakeholder support for the deliverable, which in turn will decrease stakeholder support for the overall project.

There are two reasons why people are more likely to support something they have a role in creating than something created without their input. First, the act of creation develops a bond between the creator and the creation. It takes time and effort to make something, and this investment produces caring in the person who creates something for the thing they create – and this caring manifests itself as long-term support for the creation. Second, people have an intrinsic desire to have a say in things that impact them. Denying a person input on something that will affect their life can be interpreted as a hostile act, and most people will, to some degree, push back on the result.

It can be tempting to cut corners on change management – especially since doing so will often save time (at least in the short-term) and may not significantly alter what is being developed – but doing so usually results in decreased stakeholder support for a project, and this is often much more damaging than to overall project success than losing a bit of time completing a task.