How To Control Scope In Your Project?

In the previous post we learned how the scope of deliverables are validated by the customer or sponsor. In this post we shall see how the project scope is controlled in the project and how any changes in the scope are updated in the scope baseline.

This exercise allows us to ensure that deliverables do not contain any unwanted features and miss any planned features.

I trust you already know the difference between project scope and product scope, that understanding will help here.

As a project manager some of the tailoring considerations you will have are –

• how scope management works with project knowledge management practices,
• if agile development approach is used then how the right scope is included in the appropriate iteration
• are the requirements and scope are defined well enough to be considered in the current iteration/cycle
• how audit processes work to ensure scope definition and detailing is done as per set guidelines

How to control Scope on project

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.

Side effects..

The first one is – change requests. You or customer may find many things incorrect and such ‘complaints’ are documented and ran through change control board. These are used to implement corrective or preventive actions and to manage scope variance. Change requests could also be raised due to scope changes specifically requested by the 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.

And in the process, along with scope baseline we may update cost baseline and schedule baseline as well as performance measurement baseline.

If the impact of the change is huge then we may even end up making updates to project documents such as requirements documents and requirement traceability matrix.

How scope change is implemented

1. Someone on the team or any of the stakeholders discovers a need for change of scope
2. Project manager documents the change (this step is mandatory).
3. 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.
4. 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.
5. New work is planned as per the findings from variance analysis.
6. 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: Anatomy of implementing change in project scope

That’s about how changes in scope is controlled in the project. With this we are pretty much familiar with concepts involved in Scope management, and now let us see how Quality on the project is managed at a high level.

[SneakyAffiliate sneakyaffiliateurl=”https%3A//www.pmexamsmartnotes.com/pmprecast-myposts” sneakyaffiliatecookiexpdays=”1″ sneakyaffiliatesplash=”Are%20you%20sure%20you%20want%20to%20leave%20before%20you%20checkout%20special%20PM%20PrepCast%20sale%20by%20Cornelius%3F”] [/SneakyAffiliate]