What is Change Management?

Everyone in Project Management talks about Change Management and is quick to say “Yes, we manage change.”

When we hear this, we ask, what do you mean by change management? Change management has come to also include how to change the organization. That is not a project management topic. Language is important. Words are subject to interpretation and therefore subject to misinterpretation. To limit this adverse impact, developing a common lexicon can help.

This is one of the reasons for the WBS dictionary (perhaps we will write about this technique in the future). Change management in the context of project management is how we manage alterations of the scope. Project managers likely know what happens when the scope change happens without controls that assess the impact of the proposed change.

This is not just a project management issue but has compounding impacts when the project is a product development endeavor.

The consequence of uncontrolled scope change can seriously impair our ability to stay within the project budget as well as delay the delivery of the desired result of the project. We propose that maybe that is a stretch due to project budget overruns. We will take parts of the Change Management process that we see as improvements that we have had success executing.

No matter how well we plan a project, change happens during execution. We have interim deliverables, perhaps customer samples, perhaps product testing, from which we learn. This learning can easily have an impact on the project scope and the customer’s desired end goal.

This could be a small change, could be a large change; could be a slight impact, or a large impact to the project. Either way, the best way to deal with any change is to be prepared for it.

One can’t know what, how, or when a change will occur, but one can plan for it, and by plan, we mean to have an articulated process for our project change management, even if the organization does not have a formal change management process.

There are a multitude of Change Management Plan examples and samples on the web. Most provide an explanation of how to create your own plan. The misses as we see it are One defining what is a change and two, enforcement of process.

Table of content

• 1. Define Change
• 2. Change Management Enforcement
• 3. Conclusion

Define Change

Defining ‘A Change’ may or may not be difficult. It is easy to define ‘a change’ as anything that deviates from the original, signed-off scope. Anything. But two things, one, how do we know what is asked is different from the origin? Second, and perhaps more importantly, what about the change to a company process that is typical for project execution.

This could be something like paying invoices or tracking resource hours. A process change may impact, positively or negatively, the delivery of the current project. Is a Change Request required? You decide. Your organization should decide. Ultimately, the definition or definitions of ‘A Change’ requires documentation following the Change Management Plan. No verbal agreements – if it isn’t documented, it is not traceable, confirmable, or auditable. It did not happen.

 

¹

 

Next, define the cost range of a change that will require a Change Request form. Personal preference is to document all changes by using the Change Request form. For example, changing the color of light switch covers. Special light switch covers were specified for a building project. All covers would be red. During the execution of get approvals, the client decided to change the color.

Since the covers were special with color options, changing color was a no-charge. This change was documented with a Change Request as part of the project history. Complete with approval signatures. We think CYA (Cover You’re A*s) is appropriate in some cases to explain to someone in the future why the cover color was changed and may actually be part of the project closure activities. Some other project managers may not have spent the time to complete the Change Request form which is okay.

For your project, you’ll need to set that change cost limit that will require the Change Request form.
For example, a $4 Billion project had a Change Request lower limit of $50,000. Meaning anything that would cost under $50,000 did NOT need an approved Change Request. And as mentioned earlier, we recommend any change, even $0.00 impact should be documented.

 

²

 

Change Management Enforcement

Starting with the approval of the Change Management Plan included in the Project Plan, enforcement of the plan begins. NOTE: The Project Plan is a living document, therefore, the Change Management Plan is a living document. This means that it can be changed itself but there should be a process to change of the plan. This change process should be documented in the Project Plan as well.

The Change Request process is straight forward. Someone verbalizes a request to make a change that impacts the project to the project manager. The project manager should give them a Change request form and explain how to fill out.

When a requestor submits a form, they are required to provide, on the form an account number to charge for the team resources. If the Change Request is approved by the Change Request Committee the funds will be returned.

Once a change request form is received the clock starts to get it filled out and back to the requestor. This takes time. On more than one project, a fee has been charged for the team to complete the Change Request form. After all, the resources required for completing the form are committed to the project. Completing the form will take resources time and money, and that has to be repaid. This is also one way to control change requests.

Another guideline we use are time limits for executing a Change Request form. The requestor usually has 24 hours, clock hours not business hours, to return it to the project manager. Assuming that happens, the project manager needs to get the request in the appropriate team members promptly, ideally in one business day. The appropriate team members have 24 to 48 clock hours to complete and return to the project manager. Enforcement of the clock hours is critical because as while working on a change request the other parts of the project are moving forward and no one really likes rework.

Conclusion

We should spend time, perhaps through training, with our team members to make sure they understand the reason for change management. This awareness can help avoid those impromptu, ad hoc, or outright bypass of the organizations or project’s change management process. Extending this to the customer is likewise helpful.

Developing a Change Management plan requires clarity on what defines a change and therefore would require a Change Request. In addition, it is also important to set the dollar value, or magnitude of change that would require a Change Request. 

Lastly, it is critical to ensure the team and stakeholders review the Change Management plan. This will help avoid having to call attention to it mid-project and surprise someone that they are working around an approved process. This confusion can impact project execution.
In future articles we will look at Scope Creep and expediting Change Request review as well as how agile handles changes. Please feel free to contact us if you have any questions about the information we present.

¹ Amazon: Project Management of Complex and Embedded Systems: Ensuring Product Integrity and Program Quality 1st Edition

²Amazon: Project Management of Complex and Embedded Systems: Ensuring Product Integrity and Program Quality 1st Edition