Change is inevitable in any project.
Changes can be due to unexpected external events such as a new government ruling that invalids your business case, or torrential rain that caused water to leak from the roof into the ceiling, and down into the room that houses computer servers – the ones you are in the midst of testing.
Changes can also be caused by internal factors such as movements that required a replacement of a key resource on the project, or simply when a key stakeholder changed their mind on a specific requirement. In a typical project, stakeholders contribute to majority of the changes. Keeping this in mind, the project manager should take necessary steps to prepare the stakeholders to address changes as they arise.
The best time to introduce change management is during the creation of the project charter. Although not required until later phases of a project, it is prudent for the project manager to outline the approach and steps for managing the various types of changes during various phases of the project.
Having change management guidelines established in the project charter gives the project manager the opportunity to educate and align expectations with sponsors before the start of the project. Getting agreement with the sponsors early in the project gives the project manager the “authority” to publish this to all stakeholders and enforce it when necessary.
Waiting until changes happen before working on the change management approach can be difficult, prone to disagreement, and open to criticism. Setting up “ground rules” early in the project will help the project manager remain impartial, and provides justification on why a project cannot be completed as planned (on target).