This chapter is from the book
This chapter is from the book
This chapter is from the book
Monitoring and Controlling the Project
Monitoring and controlling refers to comparing the actual results with the plan, which is a task that a project manager performs throughout the project. This is the process of tracking, reviewing and regulating the performance of the project to determine whether corrective actions, preventive actions, or defect repair (rework) is needed. You are essentially determining the health of the project by comparing metrics. For example, you need to determine whether the project is ahead of schedule or behind schedule by comparing the actual schedule with the planned schedule. You also need to determine whether the project is over or under budget by comparing the actual amount spent with the planned amount that should have been spent.
The actual results are known as work performance data.
This is compared against the plan to determine the variance.
The interpretation of the variance is considered work performance information.
For example,
“We have spent $30,000 so far on this activity” is our work performance data.
“We should have spent $25,000 so far on this activity” is our plan.
“The difference of −$5,000 is our variance.”
“Therefore, we are $5,000 over budget so far” is our work performance information.
Any changes to the baseline must go through a change control process.
On adaptive projects, monitoring and controlling may compare the actual number of user stories approved so far versus what was planned at this stage (or the actual story points delivered versus the story points planned).
For more details on monitoring and controlling, see Chapter 14. Here we concentrate on one aspect, integrated change control.
Integrated Change Control
On predictive projects, having a robust and efficient change control process is vital to ensure changes are properly controlled and approved. Otherwise, the project may end up with runaway costs, it may fall way behind schedule, and tasks may be performed inefficiently and haphazardly.
The perform integrated change control process of the PMBOK® Guide, Sixth Edition, is the process of reviewing, approving, and managing all changes on a project.
The project manager must properly control all changes on a project. The PM does not need to eliminate all changes, but those changes do need to be properly controlled. The project manager needs to prevent unnecessary changes to a project.
Why is that?
On predictive projects, most changes are going to cost money! You need to determine who is going to pay for it. So, changes need to go through a proper change control process to avoid scope creep, gold-plating, and uncontrolled costs. Of course, there may be other impacts to the project as well, such as schedule and resources, but regardless, they still need to be properly controlled.
There are many reasons why you would need to go through a change control process, such as
Team members realize they missed a requirement.
The customer wants to include some additional requirements.
Senior management decides to increase the scope.
A machine breaks down and needs to be fixed or replaced (corrective action).
One of the components of the machine is wearing down and may cause the machine to fail. You need to replace that part before the machine fails (preventive action).
There are regulatory changes.
These are just a few reasons why you may need a change on a project. This is not an exhaustive list by any means.
Key Artifact of Integrated Change Control: Change Management Plan
The change management plan documents procedures regarding change control, and each organization has its own procedures regarding change control, which are documented here. Following are some of the items that the change management plan can include:
Identifies who has the authority to approve or reject changes—Generally, the change control board (CCB) is the authority to approve or reject requested changes. The change management plan documents who will be part of the change control board and what level of authority each member has. Even if there is no official change control board, there still must be some authority who can approve or reject changes, even if this authority is one person. If no one has been identified initially, the authority may be the project sponsor. The project manager, too, may have a certain authority to approve or reject changes, which are initially documented in the project charter but also are documented here. For example, if the project manager has the authority to approve changes up to the value of $5,000, this is documented in the project charter and also documented in the change management plan.
Identifies who can submit a change request: The entire change control process needs to be properly controlled, and that includes who can submit a change request to the change control board. Although any stakeholder on a project can propose a change, there should be only a limited number of people who can actually submit the change request document to the CCB. Generally, the project managers have this authority, but the change management plan identifies who these people are. They determine whether the change is valid, is relevant for the project, and adds value to the project.
Identifies what constitutes a change: Generally, any changes that impact the baseline must go through the change control process. As the team is planning the project, any work identified is added to the plan. When the scope, schedule, and costs have been baselined, any identified changes must go through the change control process. However, each organization may have its own definition of what constitutes a change, which also is documented here. For example, “Any task that is less than two hours of work will not be considered a change.” If that is the case, it is documented here.
Describes the change control process: Each organization has its own procedures regarding change control, but a basic understanding of PMI’s general process is needed for the PMP exam. This process is discussed next.
Describes documentation and templates that must be used and updated during the change control process: Each organization has its own templates and documents that must be used for requesting changes, analyzing changes, and submitting change requests.
Key Artifact of Integrated Change Control: Configuration Management Plan
Configuration management refers to version control of artifacts, ensuring that team members and stakeholders are accessing the latest version of documents. The configuration management plan documents the configuration management system and procedures.
Distinguish this with the version control system:
Configuration management retrieves the latest version of the document.
Version control allows access to the previous versions of the documents.
Steps Involved in the Change Control Process
Each organization has its own procedures for change control, but the following are the basic steps that you need to know for the PMP exam:
Step 1. A stakeholder identifies the need for a change.
This is documented in the change log.
This request may be initiated verbally, but it must still be documented.
Step 2. Perform an impact analysis.
The team analyzes the change to determine the impact to the budget, schedule, resources, and other constraints.
You also need to determine the impact to other areas of the project, such as other project processes or impacts to other project teams.
You also identify any possible alternative actions.
Step 3. Submit the change request to the change control board.
Step 4. Follow the steps outlined in the change management plan to obtain approval (or rejection) from the appropriate authority (CCB, sponsor, or other authority).
Step 5. Update the change log with the status and any other project documents to reflect the change. Communicate the status to any other interested stakeholders.
Step 6. Implement the change.
Step 7. Verify/test the change (control quality).
Change Control in an Adaptive Environment
For the most part, the day-to-day work of an agile project does not always require a change control process in the same way as a predictive project. Any new user stories are added to the product backlog, which is regularly reprioritized. Only the high-priority user stories are implemented in a sprint. So, in an adaptive environment, change control is built into the agile process.
In addition, the many levels of feedback cycles that are performed frequently on an agile project ensure that potential changes are communicated and understood to ensure an adequate change management process is in place.
However, any major changes to the vision of the agile project or any additional sprints needed will require an approval process. The approval process in agile is beyond the scope of the PMP exam.