Control scope is there to ensure that it is only the work identified as being ‘in scope’ that is delivered, and in this way scope creep is avoided.
The actual results are compared against the scope baseline and the requirements in order to ensure that all of the approved scope is in fact being delivered. In this way, control scope prevents scope change requests from overwhelming the project and ensures that they are all handled properly.
If control scope is allowed to creep you will lose control of the project and unofficial changes in product scope will cause the project to get behind schedule and to over-run its budget.
Stakeholders, including the customer, we’ll all have different ideas about what is in and out of scope, and hence it is challenging for the project manager to resolve such disputes. Be clear that for many reasons scope may need to change but if it does, it is important that all changes must follow the change control process.
The most important aspect of this is to take consideration of the impact of control scope on schedule, cost, quality, resources, risk, etc. on any such potential changes to scope. Also important is to ensure that the underlying causes of scope change requests are fully understood and managed, and while doing so to prevent any unnecessary change requests for proceeding further.
Changes to scope is an ongoing process that can start as soon as the scope baseline is created.
Control Scope inputs.
There are five inputs to the control scope process:
Project management plan.
This contains the scope baseline consisting of the WBS codes WBS dictionary as well as the project scope statement. It contains the scope management plan describing how control scope will occur as well as the change control plan describing the project change control system.
The project management plan also contains the configuration management plan describing how the physical elements of the product will be controlled, and the requirements management plan describing how the project requirements will be managed and controlled.
Work performance information.
This provides information on deliverable status and describes which deliverables are complete, which are currently ‘work in progress’, and how much work remains. It will typically also include any issues, problems or risks that the development team is dealing with for particular deliverables or products.
This is particularly useful as an input because whenever a change request is raised or detected, the requirements documentation acts as a reference to understand what was originally agreed so that the change can be evaluated against the backdrop of the regional requirement.
Requirements traceability matrix.
This helps the project manager to a value weights potential changes and change requests with regard to the original requirement. It also helps to identify the source of each requirement select the appropriate stakeholders can be involved and consulted as is appropriate.
Organisational process assets.
This will normally cover any particular policies and procedures that have been laid down by the delivery organization regarding scope management.
As a consequence of scope, one of the tools is variance analysis where the causes of such variances and lessons learned are documented. This may cause change requests possibly for taking corrective or preventative actions, or maybe defect repair.
The upshot of this is normally that the scope baseline will need to be updated and that will normally mean schedule and cost baselines need you to change as well.
Control Scope outputs.
There are five outputs from the control scope process:
Work performance measurements.
These will show how actual progress is different from the original plan and such measurements are collected as part of the control scope process is used by the communications process, report performance.
Organisational process assets updates.
Whenever any form of corrective action is implemented, it is highly likely that changes will also need to be made to any organisational process assets, is clearly they were not entirely adequate this time, and will need to be updated for future projects.
If any changes are made to the scope baseline, then these must be incorporated as updates to the WBS. If such a change results in enhancing the original scope, then this two must be decomposed down to the level of work packages, causing additional changes to other documentation.
Project management plan updates.
As already stated, any change in scope will need to be updated within the project management plan because of resulting changes in potentially cost, schedule, risk, quality, ect.
Project document updates.
Similar to the above examples, there may be other documentation that needs to be updated for example the risk log or regular reports.
The Control Scope tool.
There is only one tool used within the control scope process:
This is used to measure any such differences between what was originally defined within the scope baseline verses what was actually created, and this is a very effective way to investigate the root causes behind such differences.
In summary, to control scope, you will want to compare the baseline and requirements with the current actual results by conducting variance analysis. If a variance exists then a change requests should be sublimated. As a result of this work performance measurements will be created along with a updates to the project management plan, documentation and organisational process assets.
Want to know more? CLICK HERE for my PMP Primer!
“PMI” and “PMP” are registered marks of Project Management Institute, Inc.