PMP Primer Masterclass Online Training

Project Scope Management


Project Scope ManagementProject Scope Management

This has six processes:

  • Plan Scope Management
  • Collect Requirements
  • Define Scope
  • Create WBS
  • Validate Scope
  • Control Scope

There are two aspects of Scope management; one is product scope and the other project scope.

Product Scope covers the required features of the product and clarifies the boundaries what is not included.

Project Scope is concerned with the work of the project, and again clarifies the boundaries of what is not included.

Project Scope management within PMBOK will use the following PMP areas:

  • The end-product requirement details
  • measurement techniques to verify those details
  • creating the project Scope management plan
  • creating the work breakdown structure
  • controlling changes to these processes
  • Project Time management

I will go into detail for each of the processes, but first here are two summary diagrams of the processes:

Plan Scope Management

This describes the process for determining the project scope and facilitates the creation of the work breakdown structure (WBS).

It also describes how the project product or service is to be verified and accepted, and details how changes to scope will be managed.  This document forms part of the project management plan.

Plan Scope Management inputs

Project Management Plan

This document is incomplete at this point, but can be helpful in determining how scope aspects should be managed

Project Charter

This gives information on the project requirements and the statement of work (SOW)

Enterprise Environmental Factors

The environment is helpful in defining the project scope.

Organizational Process Assets

These may include guidelines or process to help scope the project and manage the requirements.

Plan Scope Management outputs

Scope Management Plan

This describes how the remaining scope process are to be implemented and it forms part of the Project Management P

Requirements Management Plan

Requirements traceability matrix

Part of the requirements documentation includes the source of each requirement, and identifying the source is what this document does. Here the sources will be named, whether an individual, group or organisation.

The source origin could be a legal requirement, or clauses within a contract. Additional information for example, may include who owns the requirement.

Plan Scope Management tools

Expert Judgment

Those who represent both the customer and supplier side including those with management and/or specialist skills.


These are the most effective way to gather all the scope and project boundary information.

Collect Requirements


From the collect requirements process:

  • Requirements documentation
  • Requirements management plan
  • Requirements traceability matrix

Put at its simplest, the project scope defines precisely what is included and what is not included by clarifying the boundaries. It is counter-intuitive in many ways, because often organizations try to deliver more than was agreed upon, to exceed customer expectations.

This can be called ‘gold plating’, and can cause projects to overrun schedules, budgets and hence increase risk. It is very easy in performing collect requirements that folks will ask for more than they actually need.

To be in control of scope throughout the project requires close management of collect requirements, the details etc., and the processes. Any scope changes must be handled in a structured, linear, and controlled manner.

Each requirement is documented clearly along with its acceptance criteria as it is vital that the scope is well defined and clearly communicated.

The key to the success of scope control is to ensure that if any change is requested, that it is first evaluated, captured and documented and that no change should be implemented unless it is clear that it is necessary, and that the right authority has first been given for its implementation.

It is important to compare this against the output from collect requirements.

From the planning process group perspective, the requirements for the product and project are first gathered, then, the deliverables forming part of the product and the project scope are defined and documented, leading to the creation of the work breakdown structure (WBS).

The purpose of the requirements documentation

This contains an understanding of what is needed to satisfy the stakeholders, why each requirement is important, and it covers both the project itself and the products to be created.

This lays out what needs to be performed and justifies why each requirement is important.

Information captured here should include:

  • The source of the requirement and the core business problem that is being solved
  • How each requirement addresses the problem
  • Relevant measurements for each requirements
  • How existing business processes interact with the requirements
  • Constraints and assumptions
  • Predicted impact of the requirements on others
  • Business, legal, and ethical compliance

It is a significant lever on determining the project schedule, budget, quality specifications, risk factors and both human and non-human resource requirements.

The requirements documentation is accompanied by the Requirements Management Plan, describing how the requirements will be managed, and that goes on to define the team activities needed to gather and manage the project requirements.

The detail contained within the requirements that lead to a clear understanding of what is needed to satisfy the stakeholders so that their expectations can be managed.

This key documentation is the touchstone from which the schedule, budget, quality specifications, resource plans, and risks emanate from.

The pre-requisites to the Collect Requirements process are the Project Charter and the Stakeholder Register.

Collect Requirements inputs

Project Charter

The project charter provides an overview of the project’s product, service or result and this is used to determine the requirements.

Stakeholder Register

The stakeholder register lists all of the project stakeholders and it is important that the right stakeholders are involved in helping to explain the requirements along with the underlying needs from the earliest point in time of the project.

Requirements Management Plan

This is in effect, a strategy for how the requirements will be managed, and covers the team activities to both gather and then manage the project requirements.

This document forms part of the project management plan, and covers how requirements will be obtained and decisions made how the requirements will be documented, and how requirements changes will be managed.

Scope Management Plan

This helps give focus to the boundaries of the requirements

Stakeholder Management Plan

This helps define the level of involvement that each stakeholder should have in defining the requirements.

Collect Requirement tools


Subject matter experts should be used here as they are more able to articulate what the product should consist of and why this is important. The project manager or a business analyst may conduct such interviews.

Facilitated workshops

These are a highly efficient ways to capture and define the requirements, and the use of an experienced facilitator is key, along with all appropriate stakeholders in attendance.

Group decision-making techniques

There are many techniques available to assist bringing the stakeholders to a decision. These include unanimity, majority, consensus, plurality, and dictatorship.

Focus groups

As the name suggests these are carried out by a member of the project team meeting with a group of stakeholders to determine their requirements, needs and expectations for the project and its outcome.

Group creativity techniques

Generating a creative environment where people can openly discuss their ideas is a powerful and creative way to ensure the requirements are fully captured. Techniques can include; brainstorming, nominal group technique using votes and priorities, diagramming techniques such as mind mapping, and where a participant’s real unbiased opinion is needed, the Delphi technique.

Questionnaires and surveys

Using a standard questionnaire or survey allows requirements to be gathered quickly among large groups of people and because of the standard format, analysis is also quicker.


Put simply, an observer watches as a worker performance their job and note how the worker performance this last capturing less obvious requirements that would be missed by other methods.


A prototype’s use and style will depend upon the end product of the project and any methodologies being used for its creation. One or more part-functioning prototypes can be a powerful visualization aid when attempting to understand requirements.

Context Diagram

Typically a system diagram such as this example:


This is often done outside of the organization and project in order to establish best practices.

Document Analysis

This entails reading existing documentation in order to better understand the requirements.

Define Scope

This process uses the project charter, requirements documentation, and organizational process assets as inputs.

Here, the project requirements (from collect requirements), are more thoroughly understood and documented, and may be carried out in a simple informal manner or a complex formal and detailed manner.

This process is where the requirements which were collected in the earlier process now undergo more analysis including any additional and more detailed information. It may include approved changes.

If this were a construction project for example, then the define scope process will need to be done in detail as errors here can have huge cost, resource and schedule implications.

Because projects are progressively elaborated, the collect requirements and define scope processes will often be performed numerous times throughout the project.

Define Scope inputs

Project Charter

This is a vital input since it contains the project objectives, scope description, plus any assumptions and constraints.

Scope Management Plan

This is an input to all of the scope processes as it describes how scope will be managed and controlled.

Requirements Documentation

The requirements documentation is also an input as the define scope process translates these requirements into more detail.

Organizational Process Assets

Organisational process assets can take many forms, including project plans from previous similar projects, templates, policies procedures or guidelines, etc.

Define Scope outputs

There are two main outputs from the define scope process, the project scope statement, and project document updates.

Project Scope Statement

The project scope statement provides the baseline agreement among all of the stakeholders of the project and its deliverables.

The project scope statement includes the objectives of the project, the product description and requirements for the project, the constraints and assumptions, and the risks are have been identified relating to the project scope.

This document should also include the acceptance criteria for the end product.

Project Document Updates

Obviously this relates to any documents that may need to be updated as a result of defining the project scope, and typically includes the requirements documentation and the requirements traceability matrix, and the stakeholder register. Estimating data, issues and risk data may also need to be updated.

Define Scope tools

Expert judgment

This is the use of technical experts helping to develop relevant parts of the project scope statement.

Product Analysis

This involves detailed analysis of the project product service or a result and the output here is a better understanding of the requirements. Many tools are available to carry out products analysis and these may include; requirements analysis, value engineering, product breakdown, and systems analysis.

Facilitated Workshops

This is described in the collect requirements process, and is here used to further refine knowledge of the to the project scope.

Alternatives Identification

Brainstorming is the method here with the aim of helping the team to understand and consider all options relating to the project scope.

Create WBS

The work breakdown structure (WBS) and its component parts

The Work Breakdown Structure is created in the create WBS process and as such is a very important process.

The WBS is the hub of information for the project and is used later to determine the project activities, costs, risks, quality attributes, and procurement decisions.

It is a deliverable-oriented hierarchy, and the main inputs for its creation are the project scope statement, the requirements documentation, and the organizational process assets (which might include templates, tools, or previous project examples).

It uses the projects products derived from the project scope statement and decomposes them into logical and manageable units of work.  The lowest level of a WBS is called a work package.

The tool used to create it is called decomposition, and the WBS is accompanied by its WBS dictionary providing detailed information for each WBS node.

Another main output here is the scope baseline which represents the combination of the project scope statement, the WBS, and the WBS dictionary.

As with all baselines, once the scope baseline is created it is placed under change control as laid out within the scope management plan.

PMBOK calls the WBS the ‘hub of information’ for project and should be seen as the cornerstone component of the project plan, as it is used to identify the activities, costs, quality attributes, risks and procurement aspects within the plan.

Equally important is that you should see the WBS as the primary source for first verifying and then controlling the project scope.

Referring to the map of sequence between the process groups and knowledge areas, then this particular process is within the first three that need to be done, and forms part of the scope knowledge area.

Create WBS inputs

Project Scope Statement

This is the prime input as it describes the full scope of the project in detail and can hence the expanded in order to create the WBS

Scope Management Plan

This provides the strategy or ‘how’ the WBS is to be created and used.

Requirements Documentation

This is a key document because it links each requirement back to the specific business need or business benefit.

Organisational Process Assets

Although these are many and varied, the most useful and applicable to creating the WBS would be references to any project methodologies describing how to create a WBS.

Also any WBS templates or examples from previous similar projects could be used and adapted.

Other assets may be the use of software tools needed to create the graphical WBS diagram.

For example, even tools such as Microsoft project have an outline view which can stimulate the work breakdown structure and lead to the next steps of defining the activities.

Enterprise Environmental Factors

The packages of work and their activities will be influenced by the environment within which the project is taking place.

Create WBS outputs

Work Breakdown Structure (WBS)

Despite its name, the work breakdown structure is really a product breakdown structure, because current best practice of shows that first the products or deliverables should be identified, and only then, determine the activity is necessary to create such products.

A useful approach here is to remember that the product or deliverable would be described by a noun or outcome, whereas an activity would typically be a noun and verb.

An example would be ‘installed cabling’ or ‘new help desk’, whereas activity examples would be, ‘create report’ or ‘design software’.

The WBS consists of a graphical, hierarchical chart that is logically organized from the top downwards. Each ‘node’ on such a diagram, could be considered as a work package, and consists of a unique alphanumeric (or just numeric) code to uniquely locate and identify it.

A useful way to create such a WBS is to book a room with all key stakeholders who can contribute, and use Post-It notes to create the nodes. This is a very creative and efficient way of ensuring that the complete and accurate WBS diagram is created aligned to the project scope.

The discipline and rule, is that if it is not on the WBS, then it isn’t within the scope of the project.

The value of an accurate and complete WBS is that it helps clarify where each piece of work fits into the project, goes on to define activity responsibilities, and is an important communication tool due in particular to its easy to read graphical layout.

The manner in which a WBS is created is via decomposition, which consists of breaking down the product deliverables into progressively smaller and hence lower nodes on the WBS.

The approach here is to continue until the deliverables are small enough to be considered as a work package entity.

As a guide, a work package is considered small enough when it can be estimated for work effort, cost, and time. Additionally, a clue is that such a work package need not be composed any further, or that it may be assigned to a single person.

Each sub level accurately and completely rolls up to the level above it.

In order to create an accurate and complete WBS, it is important to ensure that each node is mutually exclusive with no gaps or overlap in each of the work packages.

Put simply, there are no duplication’s, and the WBS covers every part of the project scope.

Notice also, that reading from the top downwards, the WBS diagram indicates products or deliverables, but as these are decomposed downwards, they will depict activities.

WBS dictionary

The WBS diagram itself has limitations as it is not practical to capture all the node information on the diagram.

This is where the WBS dictionary plays a part, as it allows any additional information or attributes for each work package to be captured as a different document that points, or refers, back to the WBS. In this way, the WBS dictionary provides detailed information about the nodes within a WBS.

Scope Baseline

The term baseline is derived from the world of configuration management, and as such, a baseline may represent any agreed set of information at a certain point in time.

The key understanding here is that whenever a baseline is created, it is placed under change control, meaning that no changes can take place without the right authority and that such changes have been made according to the scope management plan.

There are four baselines contained within the project management plan; the scope baseline, the schedule baseline, the cost baseline and the quality baseline (although the latter is not explicitly stated within the sections of the project management plan).

An important PMBOK definition here is that ‘a baseline is the original plan plus all the approved changes’.

In the case of the scope baseline, we are referring to the combination of the project scope statement, the WBS, and the WBS dictionary

Project Document Updates

As in many of these processes as a result of carrying them out, the general understanding and detail of the project is refined and improved causing the need to update existing project documentation.

An example is that it is highly likely that new or modified requirements will be identified, needing an update to the requirements documentation that had previously been created.

Create WBS tools


As you might expect, the term of decomposition describes the breaking down of the project deliverables into the smaller activity based elements. As I have already mentioned, the top layers of the WBS normally represent products or deliverables, but as each lower level is identified these will describe the activity nodes rather than product nodes.

One of the major techniques used in estimating for example, is to take larger complex pieces of work and break them down into smaller chunks, then estimating such chunks in terms of work effort so that these can be aggregated to provide an accurate estimate of the larger complex piece of work.

The same is true when creating a WBS, that is, lower nodes on the WBS, must sum up to those above them.

Like all things in life, there is a balance required here in creating your WBS, and it can be tempting to decompose down to an over-detailed level. This adds unnecessary complexity, causes this process to take longer than is actually needed, and makes the project unnecessarily complex both to plan and manage.

A rule of thumb is a commonsense one of checking that the level of detail is adequate in order to provide sufficient information at an activity level, and is small enough to be estimated for time and cost.

Validate Scope

This verifies that the product, service, or result of the project matches the documented scope baseline.  Verify scope focuses on completeness and acceptance of the product by the appropriate stakeholders.

This is the process of formalizing the acceptance of the completed project deliverables.

It is important to understand the difference between validation and verification.

Verification means that the product complies with the requirements is a process to obtain customer acceptance whereas Validation means the product meets the needs of the customer.

Put another way, validate scope is concerned with the acceptance of the product by the project manager, the sponsor, or other key stakeholders.

By way of contrast, perform quality assurance focuses on adherence to the quality specification.

Validate Scope definition

Whereas the process perform quality assurance ensures that deliverables are technically correct, validate scope is there to obtain customer acceptance.

There may occasionally be situations where such deliverables are not those originally defined, but that the customer can agree and accept what has been delivered.

In short, validate scope determines completeness, and perform quality assurance checks correctness.

To summarize, validate scope is confirming that the product, service, or result of the project matches the scope that was originally documented and agreed.

Obviously the validate scope process will be used after some or all of the product components have been delivered, and for this reason may be performed several times during the project

Validate Scope inputs


Project Management Plan

This set of documents includes the scope baseline consisting of the work breakdown structure and the work breakdown structure dictionary accompanied by the project scope statement.

Since this is the agreement of what the project is to create, it acts as the benchmark against which the deliverable is measured.

Verified Deliverables

This process is the activity of comparing the actual deliverables against what was documented within the scope baseline, and to ensure that all products have been delivered.  Because of the nature of this process, verifying deliverables may need to happen many times throughout a project.

Requirements Documentation

This key document describes the stakeholder requirements for the product, and therefore provides reference information to be used when comparing what was originally documented against the actual product, service, or result.

Requirements Traceability Matrix

This identifies the source of each individual requirements and can therefore be helpful when performing the validate scope process since it provides background information on who requested the requirements and why.

Work Performance Data

This advises how the work to create the products was executed and is used in concert with the products. The way in which work is carried out also needs to be efficient, effective and fair.

Validate scope outputs

Accepted Deliverables

This is the main output and is performed by the project manager, the customer, the sponsor, and the operational managers.  The product of accepted deliverables is normally a formal written acceptance by the appropriate stakeholder.

Work Performance Information

This describes how a product was created as well as other supporting metrics such as time, cost work effort, the approach used, and so on.

Project Document Updates

As a result of verifying the project scope, there may be many updates to project documentation, possibly in terms of schedule, budget, or scope for example.

Change Requests

Since this process is all about validating the scope of the actual deliverables against what was originally planned, then change requests are highly likely to emanate from any such inspection

Validate Scope tools


This typically involves a detailed review of the actual deliverable to be compared with the scope. The actual inspection may use specific tools dependent upon the characteristics of the product

Group Decision-making Techniques

This one of the common tools already covered, and is obviously helpful here particularly when verification has an element of opinion, or that a mix of knowledge, skills and experience can bring about the best decision.

Control Scope

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.

It is 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 are an ongoing process that can start as soon as the scope baseline is created.

Control Scope inputs

Project Management Plan

This contains the scope baseline consisting of the WBS codes, WBS dictionary and 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 Data

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 include any issues, problems or risks that the development team are dealing with for particular deliverables or products.

Requirements Documentation

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 evaluate 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.

Control Scope outputs

Work Performance Information

This information will show how actual progress is different from the original plan and this data is collected and used by the report performance process.

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, as they will need to be further refined and  be updated for sue by future projects.

Change Requests

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 too must be decomposed down to the level of work packages, likely 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, etc.

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.

Control Scope tools

There is only one tool used within the control scope process:

Variance analysis

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.

Variance analysis is where the root causes of such variances and lessons learned are investigated and documented.

This may cause change requests possibly for taking corrective or preventative actions, or maybe defect repair. The result of this is that the scope baseline will need to be updated and that will in turn mean schedule and cost baselines needing to change as well.

If a variance exists then a change requests should be raised. As a result of this, work performance measurements will be created along with updates to the project management plan, documentation and organisational process assets.