4squareviews

As we stated in a previous post on the inputs to this Control Scope process, the process consists of asking three questions:

1. “what’s the plan?”
2. “is the project going according to the plan?” and if the answer to question 2 is no,
3. “how can we get the project back to the plan?”

The outputs are based on the answers to question 2 (Work Performance Information, and updates to the Project Management Plan and Project Documents) and question 3 (Change Requests).

Here are the specific outputs to this process:

5.6.3 Control Scope:  Outputs

5.6.3.1 Work Performance Information

Just as a review, there are three levels of knowledge on a project.

1. Work performance data–generated in the Process 4.3 Direct and Manage Work by the project team
2. Work performance information–this level of knowledge is useful to the project team;  the work performance data is analyzed in the separate monitoring and controlling processes connected with each knowledge area, like this one Process 5.6 Control Scope; they are then in turn inputs into the overall monitoring and controlling process 4.5 Monitor and Control Project Work
3. Work performance reports–this level of knowledge is useful to the stakeholders; the work performance information is organized and presented in the overall monitoring and controlling process 4.6 Monitor and Control Project Work so that it is useful to those stakeholders who are engaged with the project.

This output is work performance information that is based on the analysis done in the Process 5.6 Control Scope.  The main tool/techniques of this process (described in the last post) are variance analysis and trend analysis.   These not only answer the question 2 above, i.e., is the project going according to the plan, but if the answer is “no”, then they dig deeper into the reason for the variance existing now or the trend that a variance may exist sometime in the near future.   Other parts of the analysis are determining the impact the variance in scope has on the other two major constraints, that of schedule and cost.

The Work performance information is then input into the overall monitoring and controlling process 4.6 Monitor and Control Project Work.

5.5.3.2  Change Requests

The answer to question 3 above, “how can we get the project back to the plan?”, will determine the change request which will either

• fix the project scope back to fit the plan OR
• in the case that the plan has been discovered to be unrealistic, it may be necessary to change the plan to fit the project scope

If the scope needs to be changed, then there will be a change request outlining what needs to be changed.   If the plan needs to be changed, then the scope management plan, the various project baselines, and the project documents may need to be changed (see next paragraph).

There are three types of change requests:   defect repair, corrective action, and preventive action.   Here’s how to keep them straight in your head.   In Charles Dickens’ novel A Christmas Story, the main character Ebeneezer Scrooge is visited by ghosts, the Ghost of Christmas Past, the Ghost of Christmas Present, and the Ghost of Christmas Future.   As a project manager, you too may be visited by three ghosts, but in this case these are:

• The Ghost of Nonconformities Past (i.e., variances from the plan that have already occurred):   in this case you need to make a defect repair to make sure that the variance is repaired and the project scope can continue as planned
• The Ghost of Nonconformities Present (i.e., variances from the plan discovered in the Variance Analysis tool and technique mentioned in the last post):   in this case you need to take corrective action to make sure that the variance is corrected and the project scope can continue as planned
• The Ghost of Nonconformities Future (i.e., trends towards a future variance from the plan discovered in the Trend Analysis tool and technique mentioned in the last post):   in this case you need to take preventive action to make sure that the a potential variance in the future is prevented by reversing the downward trend in the performance baseline.

The change requests are then inputs to the process 4.6 Perform Integrated Change Control, which analyzes and decides upon what changes to perform on the project based on change requests from ALL monitoring and controlling processes, not just this one.

And remember, there is the fourth possibility that the analysis done in this process uncovers that the plan was unrealistic because it did not realistically account for all the project scope that had to be done.   That is covered by the next two sections listed below.

5.6.3.3 Project Management Plan Updates

• Scope management plan–it may be uncovered in the Lessons learned register (see section below on Project Document Updates) that during this process, more efficient and effective ways of controlling the scope are discovered, including getting at the cause of the variances and choosing the best type of action to take with a change request.   In this case the portion of the scope management plan that gives the guidelines for this particular process may be updated.   The change in scope may be severe enough to change not just the deliverables and the work packages, but the requirements themselves, in which case the requirements documentation will also need to be updated (see section below on Project Document Updates).
• Baselines–the scope baseline may be changed if the change requests outlined in the above paragraph are approved, which may in turn cause changes in the baselines for the other two major constraints, the schedule baseline and the cost baseline.   If the scope baseline is determined to have been unrealistic, then the scope baseline, and the other baselines of the schedule baseline and cost baseline may need to be changed as well.   This will in turn change the performance measurement baseline (used in earned value analysis), because this combines measures of all three constraints.

5.6.3.4  Project Document Updates

• Lessons learned register–rather than the results of the process, i.e., possible changes in the scope, if the process 5.6 Control Scope itself needs to be changed, then this is where you would put updates to the process that are more effective and efficient in controlling the scope, which would in turn be used to change the portion of the Scope management plan that gives guidelines on how to do the process.
• Requirements documentation (including requirements traceability matrix)–if there is a change request that makes a recommended change in the scope, the scope baseline (which contains the deliverables in the Project Scope Statement, and the work packages in the WBS and WBS dictionary) will normally be what is altered if the change is approved.   However, the variance in the scope may be so great that even the requirements, from which the deliverables and eventually the work packages are derived, may need to be changed, in which case the requirements documentation will need to be updated.

And that, my friends, is the end of the fifth chapter of the 6th Edition PMBOK® Guide; the next chapter will cover the knowledge area of Schedule Management.

Filed under: Uncategorized |