Controlling scope is a process that lives up to it’s title. It’s all about maintaining control by preventing scope change requests from overwhelming the project.
I can remember numerous times where because we didn’t maintain control of the change request process we ended up doing work that was outside of the scope of the project and we didn’t get paid for our efforts. Shame on us for allowing that to happen.
The primary reason for controlling scope is to ensure that all change requests are processed. It is to make sure you understand the underlying causes for the change and just exactly how it will effect the project.
Will the requested change increase costs? Will it increase the amount of time it takes to complete the project? Will it require extra resources? Where will the money or the resources or the time come from? Making a change to the scope is not as simple as one would like it to be.
Controlling scope is an ongoing process that begins once the scope baseline is created. From that point on all change requests are approved or denied through the Perform Integrated Change Control process.
Here is how it works:
1) Inputs
a) Project Management Plan – It contains the scope baseline and the management plan which consists of the WBS, WBS Dictionary, and the Project Scope Statement. The Project Management Plan is the documented source for what the project team is supposed to produce. The scope baseline describes what the Project Manager is supposed to control.
b) Work Performance Information (WPI) – These are similar to the performance reports the Project Manager receives on a regular basis as to the status of the project. These WPI’s provide information on all aspects of the work completed and how it relates to the project.
c) Requirements Documentation – These are the documents you should consult to understand and evaluate the change compared to the original scope.
d) Requirements Traceability Matrix – This document connects the dots from the requirement to either the reason for the requirement or to whom requires the requirement.
e) Organizational Process Assets (OPA) – These are forms or report requirements, paperwork that are unique to the company that you will need to use in order to process these change requests.
2) Tools – The only tool used here is Variance Analysis. We’re using two types of variance measuremnt here:
a) Schedule Variance (SV) = Earned Value (EV) – Planned Value (PV)
b) Cost Variance (CV) = Earned Value (EV) – Actual Cost (AC)
Both are used to measure the differences between what was defined in the scope baseline and what was created. Variance Analysis can be used to as a way to investigate the root causes behind those differences.
3) Outputs
a) Work Performance Measurements – An important part of monitoring and controlling processes is collecting and understanding work performance data and whether it differs from the baseline. If it differs, then corrective action will need to be taken. These measurements are collected and used as part of the Communications process with stakeholders, and as part of the Report Performance process.
b) OPA updates – Any corrective actions requires that organizational process assets be updated. The reason behind this is that you may have discivered that a standard company practice proved to be inadequate for what your project needed. As a result of this discovery you now need to change company documents to reflect this new reality.
c) Change Requests – What a surprise that change requests are part of the output for scope control. As these changes are made to the scope baseline you will need to reflect these changes in other documentation as well: The WBS, WBS Dictionary; scope management plan; project management plan.
d) Project Management Plan updates – As mentioned above, changes have to be recorded and documents need to be changed to reflect the new reality.
e) Project Document Updates – See c & d above.
