Controlling Project Change: Part 2 in a 3 Part Series

>>>Controlling Project Change: Part 2 in a 3 Part Series

Project ManagementEditor’s note: Recently we brought you the first part of our 3-part series on Change Management. If you missed it, please click here.


Within this series, we dive into three key areas of Change Management:

-Managing change,
-Controlling change, and
-Selling change.

Part 1 of this series provided an in-depth look on managing project change and scope creep. Part 2 will examine the role ofcontrolling project change:

Controlling Project Change:

Change within a project is inevitable and potentially affects the business and/or technical outcome of a project. Change must be continuously identified, monitored, and controlled from project initiation through closure. Per the Project Management Body of Knowledge (PMBOK), the project management process to control change is Integrated Change Control. Integrated Change Control as defined by the PMBOK refers to the process of review and approval of all change requests to the project’s organizational and technical deliverables, and the subsequent tracking and control of the requested change.

Mature organizations tend to have a standard integrated change management process in place, which is incorporated into the overall project management plan. If one does not exist, it is incumbent upon the project manager to establish a project-level change management process that should minimally include:

  • change control authority,
  • a workflow defining change request submission, evaluation, and approval process, and
  • a tracking mechanism of all changes.

My experience is that identifying the change control authority and the change control process in the project charter to be very beneficial, since the project charter typically requires key project sponsor and stakeholder approval. This initiates the awareness of change control from the business perspective.

The magnitude of the change request tends to drive the amount of change required to the project management plan. The evaluation of the requested change must take into consideration not only the primary or obvious purpose of the request but also the downstream impact on resources, work schedule, quality, costs, time, and risks. The team assigned to evaluate a change request must address these items when performing the evaluation and formulating the recommendation. The project manager must be engaged in the evaluation and prepared to make the necessary updates to all project artifacts, if approved.

Typically, change request decisions are to: approve and proceed; reject; or defer to some later point for reconsideration or action. The result of the decision by the change control authority must be recorded and incorporated into the project artifacts. If approved, all aspects of the project management plan must be updated as appropriate, and the approved change and its project impacts communicated to the project team.

As project managers, we have the responsibility to assure a change management process is clearly defined and communicated. In addition to the change management process definition and communication, project managers must also sellthe reason for, and value of managing change to the project team. I have found the education and selling of the value of change management process starts with the project kick-off meeting and is continuously reinforced through process during project team meetings and other activities and available lines of communication. Keeping the project team aware of change management is not only a challenge but critical to the success of the project. Have you had a successful experience or approach to share?

Stay tuned for the next edition when we dig further into selling change management to the project team.

George Galbraith is a Principal Consultant at SDLC Partners, a leading provider of business and technology solutions. Please feel free to contact George at ggalbraith@sdlcpartners.com with any questions on this blog post or to further discuss Project Management.