You took all the pains, made all subsidiary plans, took help from Organizational Process Assets, and prepared project plan considering Enterprise Environment Factors. With an excellent plan in place, you jumped right into project execution feeling confident that things will be just fine.
However, the truth about projects is that,
- defects are almost always found in deliverable
- things may, and will, go wrong along project execution on constraints such as time, scope, cost, quality, resources or risks
- customer will change her expectations midway or after delivery is made
- as project progresses you will find that things are not going as per your expectations
And when there is this kind of gap between what customer wants and what the team is producing, project manager needs to take some actions.
Let us look at an example scenario.
Consider the project Kathy was doing to landscape the gated-community project for Mammoth Construction Company. She had planned for a smaller excavator for the excavation of land for garden. But half way through she figures out that she is falling behind schedule and decides to call in a bigger excavator.
This kind of decision is an example of a Corrective action.
PMBOK® guide defines Corrective action as “documented direction for executing the project work to bring expected future performance of the project work in line with the project management plan”.
Let us continue with our example.
Kathy figures that the costs may increase and need to be controlled immediately. She decides to substitute some of the top-line exotic plants in the garden project with plants that cost less.
This is a Preventive action that Kathy has taken. With this action she can stay within budget.
Note that preventive action is taken before things go bad on the project. Project manager needs to be proactive in identifying potential issues and scenarios that might create pressure on project objectives such as cost, time, schedule in near future. And to avoid this she needs take preventive action in time. Such actions will save a lot of money, time and effort further down the line.
PMBOK® guide defines Preventive action as “documented direction to perform an activity that can reduce the probability of negative consequences associated with project risks”.
Let us look further into our example scenario.
Further, the team finds that workers have laid walking tracks in such a way that it would be uncomfortable for walkers to maintain the pace around the bends. Kathy has to now redo the stretches of tracks around bends.
This is an example of defect repair.
PMBOK® guide defines Defect repair as “formally documented identification of a defect in a project component with a recommendation to either repair the defect or completely replace the component”.
It’s not over yet. There is one more source that may introduce changes in project work.
This type of changes will almost always happen in any project, and it has got nothing to do with Project manager’s performance. There is not much she can do to avoid this. The probability of this occurring depends on how good the Customer understands her business needs.
Kathy completes the phase and customer inspects the completed garden work. She decides to have an Egyptian style entrance for the park, instead of the gate.
This is a change of scope that customer has brought in during project execution. Such change to scope may result in changes to cost and schedule baselines. As you can imagine this brings in change control process.
A change request is raised whenever any of the above scenarios happen.
This is how it is done –
- A change request may be raised by any stakeholder of the project.
- It must be documented and updated into change management system. This change request needs to be run by change control board (CCB). It will analyze the impact and decide whether to approve or reject the change request. We shall see more about change control in this post.
- Only approved change requests are taken up for implementation.
- Changes requested by customer will impact constraints result in changes to baselines.
The costs associated with preventive and corrective actions, and defect repairs are to be born by the organization that is doing the project. Why? Because the causes of these changes are internal to the organization. Cost of scope changes that customer has asked for, are paid by the customer organization.
In this lesson we saw about the differences between Corrective action, Preventive action, Defect repairs and Change of scope, and that change requests are in order whenever these scenarios happen on the project.
Now there may be a question as to whether a change request is raised for every defect.
The short answer is YES. When a defect is found a change request is filed. This does initiate the Perform Integrated Change Control process. If there is no impact to the plan or baselines then the CCB (change control board) does not get involved.
In the next post we will see what happens in Project Execution phase.