5th Edition PMBOK® Guide—Chapter 4: Change Management Plan

One of the subsidiary management plans under the Project Management Plan is the Change Management Plan. I have already discussed change requests in an earlier post.

In this post, I want to accomplish the following

  • Review how change requests fit into the project management process
  • Discuss the elements of the Change Management Plan
  • Discuss the philosophy behind managing change on a project, utilizing an acronym called PECHO which summarizes this philosophy

1. Change Requests—where do they fit in the project management process?

Change requests are identified, reviewed and approved, and then implemented at different parts of the project management process.

They can be identified either while project work is performed during the Executing Process Group (Process 4.3 Direct and Manage Project Work) OR as a result of comparing planned results to actual results during the Monitoring and Controlling Process Group (Process 4.4 Monitor and Control Project Work).

These outputs of the two processes mentioned above then become inputs to Process 4.5 Perform Integrated Change Control, where they are reviewed, analyzed, and then either approved or rejected. IF they are approved, they are then outputs to this process, and become fed into Process 4.3 Direct and Manage Project Work as inputs to be implemented.

Here’s a diagram summarizing this process.

2. Change Requests—review of types of requests

Do you remember the Charles Dickens story The Christmas Carol? In it, Ebenezer Scrooge was visited by three ghosts, the Ghost of Christmas Past, the Ghost of Christmas Present, and the Ghost of Christmas Future.

On a project, a project manager is also haunted by three types of problems, Defects Past, Defects Present, and Defects Future. In other words,

  • Defect repair—defects or nonconforming products which have already been created as a result of project work must be modified or repaired;

  • Corrective action—an activity which realigns the project work, which is not conforming to the project management plan

  • Preventive action—an activity which ensures that the future project work will be aligned with the project management plan

Of course, rather than aligning the project work to the project management plan, another types of change may be:

  • Updates—changes to the project management plan itself

3. Change Management Plan

The time to manage changes starts before they even happen, of course, during the Planning Process Group. That’s the time when you should create a Change Management Plan so you know how to handle the changes when they do occur.

Here are the elements of the Change Management Plan

Plan Element Explanation
1. Change Control Procedures General policies and procedures by which changes are approved, validated, and implemented
2. Change Control Plan Plan outlining how changes will be managed and controlled depending on whether they occur during Executing process or during Monitoring & Controlling Process.
3. Change Control Meetings The Change Control Board is responsible for approving or rejecting changes; Change Control Meetings are for evaluating changes, creating options, and preparing change requests for submittal to whoever has authority to approve those changes (PM, Change Control Board, or sponsor).
4. Change Control Board Rules regarding creation of a CCB to approve changes (who sits on board, who has approval authority, etc.)
5. Change Authorization Procedures Levels of authority for authorizing changes (i.e., changes may be authorized by PM, Change Control Board, or sponsor depending on degree of change
6. Change Control System This is part of the Project Management Information System, and includes standardized templates for tracking and controlling changes

And here are the various elements of the Change Management Plan with regards to when they come into play. The Change Control Procedures and the Change Control Plan are set up beforehand, so that when changes occur, Change Control Meetings can be used to evaluate them. Once they are evaluated, they are then approved or rejected in the Change Control Board according to the Change Authorization Procedures, and then they are tracked in the Change Control System whether they are approved or not.

4. PMI philosophy of managing change

I learned an acronym for simplifying the PMI philosophy with regards to how to manage changes on a project. I first thought of the elements of

  • Prevent changes if possible (eliminate need for changes, or see if changes are not allowed as per charter)
  • Evaluate the impact of the change on the other constraints of the project
  • Create options to reduce the impact (compressing schedule, etc.)
  • Get the change request approved by authority (PM, CCB, or sponsor)
  • Get approval from customer (if required)

Playing around with this awhile, I saw the following letters PECHO (meaning CHEST) in Spanish.

  • Prevent changes
  • Evaluate impact
  • Create options
  • Higher-ups, aka authority, approval
  • OK from customer

In this way, you can see that the best way to handle changes is to NOT have to handle them by preventing them. But if you do you need to first see what implementing this change will do to the project. Then create options as to minimize that impact, and then create a change request which outlines the change (does it change the product scope or any part of the performance measurement baseline itself) AND your recommendations.

The authority or higher-ups must then either approval or reject the change. Internal approval is first granted and then okayed with the customer, although some Change Control Boards include both representatives from the company doing the project and the customer’s company.

Then you log the change request in the change control tracking system and indicate whether it has been approved. If approved it is then implemented! Of course, if the project plans are changed, then this version is labeled “1.1” to distinguish it from the original project plan “1.0” (or however your change configuration numbering system is set up).

And that sums up the philosophy behind how to minimize the impact of changes on your project, but following a well-designed change management procedure set forth in the change management plan.


4 Responses

  1. Useful information. Thanks 🙂

  2. I have a respectful different view in packaging the PMBoK definition of Change Managament. In the beginning there was Engineering. A change within an engineering environment alerts to a delta to Form – Fit & Function. The classic naming convention was an “Engineering Change Proposal, Change Request”. The term Change Management is often used interchangeably. I believe this to be wrong. Change Management is a term that defines how a change within Busineses operation, business processes and procedures impact the organisation at user level/cultural/operational level.

    • It’s an interesting comment because a Change Request in PMBOK “dialect” can mean either a change to the product, which would correspond to your “delta to Form-Fit & Function” OR a change in the process. By having these two different usages of “Change Request” under one name, it can make it confusing. This carries over into configuration management, which is used to designate the various versions of the product and the various versions of the project plan, etc. I wonder how the terminology could be changed to keep these two meanings straight. PMI is now in the process of making the 6th Edition of the PMBOK guide and I hope that the terminology is clearer in the next version…

  3. […] Change Management Plan (includes elements of the change management plan) […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: