In this post, I am summarizing the high-level overview of the change request process that comprises the process 4.5 Perform Integrated Change Control. Because up to 10% of the PMP Exam can revolve around this topic, it is vitally important to understand it to pass the exam. But beyond the pragmatic goal of passing the exam, managing change requests is at the heart and soul of good project management practice, and so special attention needs to be paid to this area in any case.
I am indebted to the Rita Mulcahy’s PMP Exam Prep book for its clear statement of the process for change requests. What I have done is taken her high-level overview and added my own acronym which I have shared with our study group because the content needs to be memorized, and more importantly, understood.
A. ECHO—acronym for overall change request process
You want a change on my project? Tell it to the ECHO chamber! In other words, follow the four general processes outlined below.
- Evaluate the Impact
- Create Options
- Have it Approved
- Okay it with Customer (if needed)
This is an acronym I created to keep these four general processes straight in terms of order. What do they mean? I’ll discuss each of them in turn.
B. ECHO—meaning of individual terms
Remember there are three basic types of changes: corrective action (dealing with problems that are occurring now), preventive action (dealing with problems that may occur in the future), and process improvement to correct defects (dealing with problems that have already occurred).
|
Process |
Explanation |
|
| 1. | Evaluate the Impact | A change in the project will usually involve one of the constraints, such as changing the scope. Your job is to evaluate the effect of this change of one constraint on the other constraints in the project. Will it cause increased costs? Will it require more time?
|
| 2. | Create Options | Rather than telling management “Houston, we have a problem”, it is best to say “Houston, we have a problem—and here are the options we have figured out.” These options will be in the form of adding resources (crashing), compressing the schedule (fast tracking), or some other way of accommodating the proposed change.
|
| 3. | Have it Approved | After creating options to manage the impact of the change on the project, it is taken to either the sponsor or the change control board. NOTE: The change management plan may allow the project manager to approve certain (relatively minor) changes.
|
| 4. | Okay it with Customer (if needed) | If the project is external (i.e., the result of the project is to be delivered to a customer rather than used internally within the organization), then the change request must be okayed with the customer. Obviously this step is unnecessary if the project is internal to the organization itself.
|
C. ECHO—Summary of change request process
1. EVALUATE THE IMPACT
The iron law of constraints means that each constraint is effected by the others. So if there is a scope change, you must evaluate what impact it will have on the other major constraints of time and cost. Remember that “scope” in the above diagram can include, in the larger definition of project constraints (see p. 6 of PMBOK® Guide) such constraints as quality, resources, risks, and even customer expectations.
2. CREATE OPTIONS
In response to the change request, there are different types of changes that may require different options. A preventive action may be suggested as a change with the idea preventing a risk from occurring or mitigating the impact of the risk if it does occur.
If a variance is detected between the actual performance and the baseline, then crashing or fast tracking may be an option which will allow the project to “get back on track,” so to speak. However, if analysis of the variance shows that it was the original estimates that were unrealistic, then it may be necessary to change the performance baseline through re-estimating.
If defects are discovered as part of quality control, then it may be necessary to repair those defects, but then through quality assurance it may be necessary to get to the root cause of the defects and create improvements to the manufacturing process which prevent those defects from reoccurring.
These are just some examples of the types of options that you can create to respond to the change request.
C. HAVE IT APPROVED
Another way I have to remember this step is to think of “H” in ECHO standing for “Higher Authority”, either the a) sponsor or the b) change control board. You send the change request, together with the a) analysis of its impacts on the project and b) your suggested options to the sponsor or, in a larger company with a more formal system, to the change control board.
The approval/rejection decision is then made by that authority.
D. OKAY WITH CUSTOMER
Again, for projects which are external, i.e., where the result of the project is to be used or delivered to a customer, they must approve of the change request because they must in effect approve the consequences of the change request as they effect the project as a whole.
This is the change request process at a high level. The next posts will discuss the process in a more detailed fashion.
Again, my thanks to Rita Mulcahy’s PMP Exam Prep book for laying out the change request in such a clear way. My adding an acronym to this high-level process is just my way of making it more easily memorizable by those trying to prepare for the exam.
Filed under: Uncategorized |
4squareviews 
Leave a comment