Skip to content

How to Drive Project Scope Management


One of the main responsibilities of the Project Manager is to maintain control of multiple restriction elements: Scope, Time, Cost, Quality, Risk, etc.

So, project scope control is a key feature for the success of a project. When major changes are recorded in the project it’s mandatory to apply a scope change request. However there may be resistance to apply formal scope change management for small changes. The sponsor and other members of the project team may consider that it is unnecessary overhead for small choices. But it should be done, to keep project in control.

The Statement of Work (SOW)

To accurately determine the project scope, project team should analyze the statement of work.

The first suggested is to read the statement of work from beginning to end, understanding that it is a tedious, boring, mechanical, and difficult to follow document. But this is part of the process that provides exposure to user requirements and is needed to understand the spirit of the project and what the deliverables need to achieve.

The next suggestion is to understand the definitions normally included at the beginning (or end) of this document (glossary) to help understand the details of the statement of work. The terms used in the document typically infer a legal context, so understanding definitions shed light on those areas that could cause misunderstandings that arise between supplier and customer.

Then you need to understand what is the responsibility of the project implementation team. Keep an overview of all the SOW and an understanding of the legal terms used in the agreement, focusing on what is the responsibility of the team running the project. This section details what has been promised to deliver: either a certain amount of time on their servers and equipment, delivery dates of any product, support staff hours, etc.

Next you have to understand what is the responsibility of the customer team. Access to experts in the field of their staff, or quick approvals, perhaps their own support staff, facilities, etc. It is important to understand that the failure of the customer to comply could adversely affect project delivery.

When you have already established definitions, areas of responsibilities and commitments assumed by the team, you have to rescan each item in the statement of work to establish whether it is a deliverable, risk, restriction, time element, payment event or any other categorization of project work.

Once your statement of work is labeled and categorized, it must be processed searching for patterns – what to do, when to do it, what risks or problems to be taken into account, and any open question that needs to be answered.

The WBS and Project Scope

From the information obtained from the processing of statement of work, you get what it takes to create an initial version of the WBS that will drive the rest of the project plan.

The work breakdown structure is a tool that is used to describe the scope of a project in terms of its deliverables, divided into pieces that are small enough to plan and work easily. These pieces are called work packages.

The WBS is created at the project begining project right after the project charter is approved and the team is formed. The team should create the WBS in a meeting where people that will really do the job must be present.

The upper level of the structure is the final product of the project.

The next level is a list of all deliverables contained in project charter. To conform is suggested to consider only nouns, not verbs (such as “database” and not “build up data”). At this level the major deliverables that will exist after the project is completed should be included. These major deliverables should describe in  100% of the final product.

On the third level we should broken down each of the major deliverables, and their components should describe 100% of deliverable second level.

In order to develop the project WBS a group activity is suggested: the Project Manager must put the product and deliverables on a chalkboard that the whole project team can see at once. Then you should point to the first deliverable and ask, “What is this?” and record the responses of the team. The Administrator must then go to the next deliverable and repeat the question.

There are questions to answer: “Some responses involve a deliverable divided into smaller elements, while others should not be divided, as they are small enough. But what is small enough?, When you stop the process?” (Project Management Partners, 2002)

The answer is: When the person in charge of producing a work package has all the necessary info for making it and when it is clear to everyone the time the item should be completed. This last part is especially important. Knowing what to do is vital to the project success.

The WBS is not the project schedule. It dosen´t contains tasks or phases. This is a common misconception that drastically reduces the value of the WBS.

Once WBS is finished, it can be used for estimating and monitoring costs, identifying activities in the project schedule, identify risks and control the project scope.

How to control project scope

There are different techniques to control project scope:

Freeze late Scope change requests

The later scope change, the more it impacts schedule and budget.

You might think that if the sponsor is willing to approve budget increases and time to make the change, this simply should occur. This is partially true. There comes a time in the project that more scope changes are needed. That’s the time to get a commitment to freeze scope. Not only the new changes will be costly to implement, but they will be a distraction to the project team.

Depending on the nature of the project, this freeze is done when the team is preparing to start implementation. At this point, the team is focused on the implementation of the solution. Now the scope change requests are not only expensive, but also very harmful. The team may lose concentration and mood.

The best way to deal with these changes is to separate and treat them as enhancement requests after the solution is implemented and stabilized.

Tracking valid change requests that are not approved

You may not approve sponsor´s scope changes during the project, but these requests can be done at a later time. These types of change requests must be recorded in a list of pending. After the project is completed and the solution is implemented and fully operational, there may be opportunities for improvements or a second phase of the project.

Do not use the contingency reserve in scope changes

Part of the estimation process is to add contingency reserve in the budget and timetable to reflect the level of uncertainty associated with the estimate. (For example, if the hours of effort were estimated at 5000 hours, it is possible to add 500 hours to contingency, reflecting a confidence factor of 90% and 10% uncertainty.) Once contingency is approved, there will be a lot of pressure on the Project Manager to use the contingency to absorb the additional requirements. The customer can say, “Why do we need invoke scope change management of this improvement 100 hours, if you already have 500 hours of contingency built into the estimate?”

The project manager must resist temptation and pressure. The purpose of the contingency estimate to reflect the uncertainty in the estimates. There will be plenty of opportunities to use the contingency when the activities take longer than expected. Do not use the estimate contingency to absorb the additional work.

Batch processing

It is not always practical to obtain sponsor´s approval for all change requests each time they arise. The project team usually has no direct access to the sponsor and is difficult to get attention for small requests. Make packed change requests enables better use of time. This means that the Project Manager keeps track of small changes in the scope, its commercial value and its impact on the project. Then, when a certain threshold is reached, all sent to the sponsor for approval. This means that instead of visiting the sponsor ten times to allow small changes in the scope, a batch of ten small changes together, at once, be submitted for approval.


It may be useful to give authority to the Project Manager discretion to approve small scope change requests, provided that they are below a threshold of hours of effort and cost. This authority must be expressly delegated by the sponsor. This discretion implies that the project is progressing on time or ahead, and that changes do not imply that the project exceeds the cost or duration agreed. If the project is at risk of not meeting their commitments cost or duration, this discretion should not be used – even for a change request of one hour.

In this case, all changes must go through a normal process of scope change for the approval of the sponsor.

Contingency budget for scope changes

The organization can recognize that a certain level of scope change is inevitable and may be allowed to allocate a percentage of the total project budget to control small changes. For example, a 5% contingency added to the budget for the change in scope. If your total project budget is $ 500,000.00, the contingency budget scope change would be $25,000.00 small scope changes. The customer must rationalize the budget to ensure that you will be making all the important changes in scope. If the customer quickly using the contingency budget in small changes in the scope, there will be nothing to requests for further change. This budget is used to change requests under a certain threshold in cost or hours. Larger requests may be made, but through the normal management of change in scope and should be evaluated by the sponsor.

What to do when you can not define the project scope

When it is not possible to define in advance the total project scope, you can not plan far ahead. For these cases may be useful a best practice called Rolling Wave Planning Project (RWPP).

Gregory D. Githens, PMP defines RWPP as an iterative mechanism to develop a project that is applicable to projects in which new products and develop IT projects. Rupen Sharma, PMP emphasizes the aspect of the iterative planning similar to what is done in Agile methodologies like SCRUM.

The Rolling Wave Planning technique is recommended when you do not have the clarity needed to plan in detail the whole project. This lack of clarity in the scope may be due to new requirements, when they can not get clear answers from the interested parties.

The idea is really simple: it is planned to where you have visibility is implemented and then re-planning.

For this it must be from a WBS consider all stages and objectives of the project. It must then detail the WBS and activities of the first phase. As the project advances knowledge is acquired. At the conclusion of this phase of knowledge will be used to detail the WBS and activities just for the next phase in a cycle that continues to complete the project.

That is, you should plan frequently, but only the work of the next phase.

This mechanism allows the team to be certain about how to develop the project also responding to the request of the parties concerned to start implementing the project and continue completing the project scope on the fly. Only it should bear in mind that each of the stages of the project (and their dates of start and end) must be clearly established and recognized by everyone involved in the project.

Below I list the references mentioned and other materials of interest on the subject:

  • Gregory D. Githens, PMP. “Rolling Wave Project Planning”
  • Rupen Sharma, PMP. “Basics of Rolling Wave Planning”
  • Johanna Rothman. “Starting With Rolling Wave Planning”
  • Johanna Rothman. “Rolling Wave Planning”
  • Glen B. Alleman. “Rolling Wave Planning”
  • John Goodpasture, PMP. “Rolling Wave Planning”
  • John Reiling, PMP. “Rolling Wave Planning and Progressive Elaboration”
  • Jose Moro. “Rolling Wave Planning or planning gradual”
    Project Management Partners: The Process of Project Management – Decomposition. (2002, January 17). Retrieved November 30, 2015, from