4squareviews

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.

Filed under: Uncategorized |