Controlling the project scope is the a project management activity of monitoring the status of the project, finding whether the deliverables meet documented requirements, and managing changes to project scope baseline.
Before we go further let us quickly recall what is meant by Scope Baseline.
Scope baseline refers to the documented and agreed upon deliverables expected from the project. Typically scope baseline consists of – Scope Statement of the project, Work Breakdown Structure of this scope, and details of the components of WBS.
Recall from Work Breakdown Structure related lesson that WBS is typically a hierarchical representation of unit of work. This unit of work decomposed from high level requirements and at a bit higher level of complexity and context than individual tasks that can be assigned to people.
What do you need to control scope?
First thing to look at is the project management plan, specifically the scope baseline, which is the ‘expected scope’ against which implemented scope of the project is compared and variance is calculated. If there is a deviation then project manager needs to plan corrective or preventive actions by running change request through change control board.
Other information we use from project management plan are requirements management plan, scope management plan, change management plan and configuration management plan. These documents tell us how to go about managing changes to requirements and scope, managing any changes to the baselined documents, and process to update configurable items, respectively. Control Scope process can also spring up surprises and you may discover other changes such as changed requirements, thereby affecting other subsidiary plans as well.
What is meant by ‘configurable item’?
In brief, configurable items are documents (or project artifacts such as design, artwork, spreadsheets, and source code) that are versioned. This means any changes to them are made by authorized people on the team, and in consultation with the required team members and/or other stakeholders and by using change control process.
These documents are kept in an access-controlled environment, using systems that allow multiple people to make changes to the same document without overwriting each other’s modifications. Configuration management plan defines these items and the process of controlling changes to these artifacts. When there is an approved change to a configurable item it is versioned and re-baselined.
We may need to go back and refer to requirements documentation and requirement traceability matrix – in order to verify whether deliverables indeed satisfy the documented requirements or there are any deviations.
Next, we will need to know how are we doing on the project execution, which is the performance related data, such as how many deliverables have started, what stages of development are they are at, how many change requests are received and which deliverables are completed.
Lastly, the policies, procedures, templates and guidelines set by the organization to control scope, as well as any templates already available will help us control scope better.
How do you control scope?
By comparing project’s current state of scope against the baselined scope information, and finding differences. If and when a variation is found, a corrective or preventive action is identified. Any change will require project manager (or any stakeholder) decide whether preventive or corrective action is necessary and to raise a change request. When a change request is approved by change control board, it is taken up for implementation by making necessary changes to schedule and recreating scope and schedule baselines.
Let us pause here for a moment and look at what really happens when a change is discovered.
We have seen that changes to scope can happen for different reasons – scope creep, gold plating or customer request. There are certain changes that are so small that project manager (or project management team) finds no impact on any of project constraints by implementing them. In which case, change control process is not necessary.
The first one is – change requests. You or customer will find lot of things incorrect and such ‘complaints’ are document and ran through change control board. These are generated to implement corrective or preventive actions taken to manage scope variance. These could also be due to changes requested by customer.
Subsidiary management plans such as scope management plan as the project management activity itself provides feedback on how we’d planned to do it earlier. So you update project management plan with this information.
If the impact is huge then we may even end up making updates to project documents such as requirements documents and requirement traceability matrix.
Anatomy of Change
- Someone on the team or any of the stakeholders discovers a need for change looking at current project progress.
- Project manager documents the change (this step is mandatory).
- This change request is then presented to Change Control Board through Perform Integrated Change Control process. Project manager may in parallel assess impact of change on project objectives so as to help make a decision during change control meetings.
- If the change is approved, then the impact on project constraints such as schedule, scope, and cost are assessed in detail. This is where variance analysis comes into play.
- New work is planned as per the findings from variance analysis.
- Scope baseline is updated to create new baseline, and distributed to the team. All further development effort will refer to this new baseline. Previous baseline becomes obsolete when a new baseline is created.
Changes are then taken up for implementation as per the revised schedule.
Figure 2: Anatomy of a change