5th Edition PMBOK® Guide—Chapter 6: Change Requests as Outputs of Process 6.7 Control Schedule

The outputs of the Schedule Management process 6.7 Control Schedule are as follows:

1. Work Performance Information The schedule variance (SV) or schedule performance index (SPI) calculated for the work packages and control accounts of the WBS.
2. Schedule Forecasts Estimates of the future conditions of the project based on the work performance information provided.
3. Change Requests Performance reviews, including schedule variance analysis, may result in change requests to the schedule baseline. These are then input to the Perform Integrated Change Control process 4.5 in Integration Management.
4. Project Management Plan Updates
  • Schedule baseline
  • Schedule management plan
  • Cost baseline: schedule compression technique of crashing may require additional resources
5. Project Documents Updates
  • Schedule data: if a new schedule is generated, more realistic schedule data may result
  • Project schedule: updated schedule data will result in a schedule model which generates an updated project schedule
  • Risk register: schedule compression technique of fast-tracking may generate new risks
6. OPAs
  • Causes of variances
  • Corrective action (if chosen)
  • Lessons learned from schedule control

1. Work Performance Information

The most important outputs are the work performance information and schedule forecasts, which are used to a) inform the project team and stakeholders of the progress of the project, and b) indicate whether changes may be required.

The work performance information needs to be compared to those thresholds that were set up in the schedule management plan to see if they exceed those thresholds, and if so, what countermeasures or corrective actions are indicated in the plan to bring the actual performance back in line with the schedule model.

2. Schedule Forecasts

Now, even if the current work performance is acceptable, trend analysis may be used to create schedule forecasts that show that the future conditions of the project may be unacceptable. In that case, preventive actions may be indicated to bring the future performance back in line with the schedule model.

3. Change Requests

It is also possible that the actual performance is so out of line with the schedule that it is decided to re-estimate the durations of the activities of the project and thus re-do the schedule model.

In any of the these cases described in the last three paragraphs, corrective actions, preventive actions, or changes to the schedule itself, the change is formalized with a change request and is then an input to the Integration Management process 4.5 Perform Integrated Change Control.

4. Project Management Plan Updates

If the change requests changes or updates the schedule model, the schedule baseline, as part of the overall project management plan will have to be updated and the project team and stakeholders informed so that they understand that the old schedule baseline is no longer operative, and that everybody should be working off of the latest version of the schedule model.

If schedule compression techniques are used, the additional resources used in crashing activities will also have to be accounted for in the cost management plan, which is part of the overall project management plan as well.

5. Project Document Updates

Not just the project management plan, but many of the project documents such as the project schedule (the output of the schedule model) and possibly even the risk register (to add the risks involved if fast-tracking is used as a schedule compression technique) may have to be updated.

6. OPAs

If the work performance information, in the form of earned value measurements such as the schedule variance (SV) or schedule performance index (SPI), shows that the actual performance is out of the line with the schedule model, then obviously changes should be made to bring it in line, or redo the schedule, as I mentioned in the above paragraph 3 regarding Change Requests. This will involve finding out the reason or cause for the variance and addressing it. These causes for the variance should be added to the lessons learned so that the cause can be avoided, if possible, for the rest of the project. This is an example of where lessons learned can be useful not just on future projects, but on the current project as well.

This concludes my survey of the Schedule Management Knowledge Area covered in chapter 6 of the 5th Edition of the PMBOK® Guide. The next chapter will cover another one of the “triple constraints”, that of cost in the Cost Management Knowledge Area. After posting on other topics this weekend, I will continue next week with posts on Chapter 7.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

<span>%d</span> bloggers like this: