4squareviews

This post is geared towards explaining why change requests originate from different processes, explaining what can be in change requests, and explaining where change requests go next in the project management processes.

A. Change requests

Before we consider what change requests are specifically, let’s get a better idea of what they are in general on a project.

One way of doing this is by analogy. Let’s say your goal is to take a road trip from city A to city B. You are trying to do it within a certain time period, let’s say, 4 hours. That will be analogous to doing a project. You plan to go a certain distance every hour, so that you will get to your destination on time. You have decided to check the actual mileage every half hour with the planned mileage in order to figure out whether you are on schedule or not.

In this analogy to a project, the process 4.3 Direct and Manage Project Work is equivalent to the process of driving. This is in the Executing Process Group. The process 4.4 Monitor and Control Project Work, in the Monitoring & Controlling Process Group, is represented in this analogy by your checking your actual mileage every half an hour or so.

At that point, if you actual mileage differs from the planned mileage for that portion of the trip, you may make a change in your speed based on that information. This would be an analogous to a change request on a project based on your measuring against the performance baseline

However, even if you haven’t reached your half-hour “checkpoint”, you may want to change your speed, or your route entirely, depending on current conditions in the road. So change requests can come either during the Executing Process Group, or during the Monitoring and Controlling Process Group.

B. Change requests

There are many types of changes you can make on a project, and these have analogies in the road trip analogy I’ve been using.

If you’re behind schedule on your trip, and you accelerate your speed in order to catch up, that’s an example of corrective action. This is, in formal PMBOK® Guide terms, “action which is designed to bring expected future performance of the project work in line with the project management plan.”

Let’s say your GPS system warns you of a impending traffic jam because of an accident. You decide to take the surface street rather than the freeway to bypass this traffic bottleneck. This is an example of a preventive action. This is, in formal PMBOK® Guide terms, “action that can reduce the probability of negative consequences associated with project risks.”

If you find that you accidentally took a wrong turn, then you will have to change your route immediately in order to get back on the right road. This is analogous to a defect repair, an action that repairs the defect or a problem with the deliverable.

In reality, these three categories of changes are designed to handle present (corrective action), future (preventive action), and past (defect repair) mistakes on the project.

C. Where do the change requests go?

You can see from this diagram that, whichever process originates the changes requests, they get transferred over to the process 4.5 Perform Integrated Change Control, which is the process of managing changes including approving or rejecting them. This is an integration process in the Monitoring & Controlling Process Group. For only those approved changes, the implementation of those changes is done back in the Executing Process Project under the process 4.3 Direct and Manage Project Execution.

I hope this clarifies the general flow of how changes are made to a project in in terms of the project management processes.

Filed under: Uncategorized |