Scope Management

What Scope Management Covers

A builder puts up a fence around a construction site to mark its boundaries. Scoping a project serves the same purpose. Scope management defines the work the project requires and makes sure the team completes all of that work and stays within the agreed boundaries.

Plan ahead for how you will determine, manage, and control scope. Gather requirements from all stakeholders and get formal approval of a clearly defined scope. Gathering requirements from just the sponsor or a small group can lead to the wrong scope. On large projects, gathering requirements takes more time, effort, and resources, which makes a clear definition especially important.

Use the approved scope to keep the work within the scope management plan. Gold plating, or adding extras, is prohibited. Monitor the scope continuously so everyone can tell which work is included and which is outside the project.

Evaluate scope changes for their effects on time, cost, risk, quality, resources, customer satisfaction, and other relevant areas. Use integrated change management to approve changes. The change originator updates the change request form, and the change is tracked in the change control register.

Open Full-Size Diagram ↗

Open Full-Size Diagram ↗

Product Scope

Product scope answers the question “What does the customer want?” An organization can run a separate project to define product scope or define it while gathering requirements for the current project.

For a software project, the product scope might be “a new workflow application that meets the requirements of our internal and external customers.” To see whether the project met the product scope, compare the finished application with the requirements recorded in the requirements documentation and the project scope statement.

Project Scope

Project scope is the work needed to deliver the product scope. In the software example, it includes the work of developing the application and the planning, coordination, and management activities that help deliver it, such as meetings and reports. These efforts are covered in the project management plan and its scope management plan. At the end of the project or phase, compare the completed work with the scope baseline in the project management plan to see whether it meets the agreed scope.

Scope Management Plan

The scope management plan covers scope planning, execution, and control. In the process framework used here, the team develops the scope management plan within the project management planning process and includes it in the project management plan. It addresses:

• How the project will achieve its scope.
• Which tools the team needs to accomplish the scope.
• Which enterprise environmental factors the team needs to account for.
• Which organizational process assets the team needs.
• How the team will manage and control scope throughout the project.

Organizations should have scope management templates, forms, or standards. They are critical to project work. Some parts of the plan can be standardized, and each project still needs its own plan. The project manager uses the scope management plan as a reference to guide and measure the project through closing.

The plan can be developed in stages and revised during planning. First decide how to define the scope. Once the overall project has been planned, decide how to carry out and control that scope and add those decisions to the scope management plan. Later planning work, such as human resource planning, can identify additional scope and require another revision.

The project manager needs a good understanding of scope to prepare the plan. Identify both product and project scope before starting work. Creating the scope management plan is a required part of project management.

Scope Management Process

1. Determine requirements. Use the business case described in the project charter to check whether each requirement supports the project.
2. Consider stakeholder needs when defining product and project scope.
3. Use a work breakdown structure (WBS) to divide the scope into smaller, manageable pieces.
4. Design the process from the customer’s point of view.
5. Measure scope performance and adjust as needed throughout the project.

Be prepared to say no to unnecessary work. Extra scope adds cost, time, and effort.

Collect Requirements

Requirements describe what the project or product needs to achieve its stated objectives. They can cover quality, business processes, regulations, compliance, project management, and other areas. Collect Requirements addresses both product and process requirements. Check each request against the objectives before including it.

During initiation, the project charter captures high-level project and product requirements. Collect Requirements gathers more specific information and any related assumptions from all stakeholders. Missing requirements can lead to failure, repeated changes, or conflict throughout the project.

Start by identifying stakeholders and recording them in a stakeholder register. A project can have several hundred stakeholders, and different groups may require different ways of collecting input. Set aside time and effort to collect requirements before project work begins. Incomplete collection can drive costly, labor-intensive changes. Historical information and lessons learned can help. Choose techniques that fit the project and stakeholders. You can also use these techniques to identify risks during risk management.

Review Historical Records

Historical records and lessons learned show what similar projects required and help identify relevant processes. They help someone new to the project understand what different teams expect. They can also reveal mistakes other project managers made when defining scope, so you can capture requirements those projects missed.

Interviewing

Interviewing, sometimes called expert interviewing, helps a project manager identify stakeholders’ product or process requirements. Interviews can take place one on one or in groups, by email, phone, or letter, or through other methods.

Focus Groups

A moderator or facilitator gathers opinions and requirements from a selected group of stakeholders or subject matter experts. The discussion may focus on the product or on one aspect of the project.

Facilitated Workshops

A facilitated workshop brings stakeholders with different perspectives together to define the requirements of a product or service.

Brainstorming

Brainstorming generates many ideas in a short time by having participants build on each other’s ideas. For example, one participant suggests a way to define scope, which sparks an idea from another person, which in turn prompts another idea. Invite people with different functions, backgrounds, and perspectives from inside or outside the organization.

Nominal Group Technique

After brainstorming, participants rank the strongest ideas.

Delphi Technique

In this consensus technique, experts participate anonymously and do not meet. Send them a request for information, compile their responses, and send the results back to them for further review. Repeat until the experts reach consensus.

Mind Maps

A mind map helps generate ideas and organize them into logical groups. Draw the main ideas as branches of a central idea, then branch related ideas from those.

Affinity Diagrams

Group ideas from other requirements-gathering techniques by similarity. Give each group of requirements a title.

Open Full-Size Diagram ↗

Questionnaires and Surveys

A questionnaire collects responses to a set of questions. Questionnaires and surveys can reach a large group.

Observation

Watch a potential user of the product at work.

Prototypes

A prototype is a model of the proposed product. Show it to stakeholders and ask for feedback. The team may need several versions to capture all the requirements and finalize and approve the model.

Group Decision-Making

Input from many stakeholders can generate competing ideas, confusion, or conflict. Review and analyze each idea, approve or reject it, and prioritize the approved ideas before recording them in project documents.

• Unanimity. Everyone agrees on the requirement, making the decision straightforward.
• Dictatorship. One person decides for the whole group. The decision is quick, and other stakeholders may disagree with it.
• Majority. The group adopts the decision supported by more than half its members.
• Plurality. If no option has a majority, the group adopts the option with the most supporters.
• Consensus. The group reaches a decision it can accept. Members who favored another option are willing to accept the decision most members support.

Requirements Documentation

Once the team has collected the requirements, document them clearly and unambiguously. Requirements documentation is an output of Collect Requirements. A poorly presented requirement can be misunderstood. Ask stakeholders to confirm that the documented requirements meet the stated objectives. Their feedback helps verify that the team has collected the right requirements and that the resulting deliverable will be acceptable.

Balancing Stakeholder Requirements

Prioritize requirements and resolve conflicts so the project can meet its objectives. When requirements cannot all be met, identify ways to balance competing demands involving scope, time, cost, quality, resources, risk, and customer satisfaction.

Continue balancing requirements after collection. Later, some stakeholder requirements may conflict with project requirements or with other stakeholders’ requirements. The project manager weighs those needs against the project’s interests and resolves conflicts.

Set clear project objectives and identify and prioritize all requirements from all stakeholders during Collect Requirements. Both are prerequisites for balancing those requirements.

Resolving Competing Requirements

Departments can have different interests in a project. For example, the risk team may want to slow the project down after identifying a risk, while the operations team wants to finish sooner. Find a solution both departments can accept.

Complex conflicts require management involvement. The project manager checks which requirements support the business case and reviews the project charter, scope statement, and constraints.

Reject requests outside the project objectives or outside the approved charter, even if they relate to the original reason for the project. Discuss any proposed charter change with the sponsor for approval. If cost is the top constraint, requests that raise costs are less likely to be accepted. Requests that contain costs without seriously affecting other constraints are more likely to be accepted. Requests outside these guidelines can be considered for a future project.

Requirements Management Plan

This chapter describes the requirements management plan as an output of Collect Requirements. The plan answers these questions.

• Which methods will identify requirements?
• What analysis will each requirement need?
• How will requirements be prioritized?
• How will they be managed?
• How will they be tracked?
• What information must the requirements traceability matrix provide?

Requirements Traceability Matrix

On a large project, poor documentation can cause requirements to be lost. One requirement can lead to several refinements or clarifications, making it hard to remember where each came from. Losing track of the reason for a requirement can keep the project from meeting its objectives.

The requirements traceability matrix is another output of Collect Requirements. It links requirements to project objectives and/or other requirements to support strategic goals. Use it throughout the project to analyze proposed changes to product or project scope.

Open Full-Size Diagram ↗

Define Scope

Use the requirements documentation from Collect Requirements, the project charter, and information about project risks, assumptions, and constraints to define product and project scope. Specify what is included and what is excluded from the project and its deliverables.

Planning is iterative. Once requirements are known, use them to develop a schedule and budget. If either falls short of management or sponsor expectations, review the project constraints and balance requirements against the budget and schedule. Give management options for meeting scope, time, and cost objectives. Options include compressing the schedule, finding alternative ways to do the work, and adjusting the budget or scope. The goal is a realistic schedule and budget for delivering the scope.

Product Analysis

Analyze the product objectives and description supplied by the customer and sponsor. Use the analysis to identify tangible deliverables.

Project Scope Statement

The project scope statement is a main output of Define Scope. Preparing it takes time and can require input from several stakeholders, including outside experts. Explicitly identify two kinds of exclusions:

1. Unapproved scope. Identify work people requested that was never approved for inclusion.
2. Unneeded scope. Clarify boundaries that people could easily misunderstand.

The project scope statement joins the WBS and the WBS dictionary to form the scope baseline, which is part of the project management plan. The statement can include:

• Product scope.
• Project scope.
• Deliverables.
• Product acceptance criteria.
• Out-of-scope activities.
• Constraints and assumptions.

Create the Work Breakdown Structure (WBS)

Every project, large or small, needs a WBS. It divides the complete project scope into manageable deliverables. Without a WBS, the project will run past its scheduled finish, and the project manager may also miss important activities.

Open Full-Size Diagram ↗

Most project managers make a list of action items. A long list can be cumbersome, can miss deliverables, and makes it difficult to break a large project into manageable pieces. Readers may struggle to understand the project or identify the one person who made the list.

A WBS accounts for every action item. Its hierarchy shows how the work is broken into work packages and how deliverables relate to one another. Stakeholder and team input helps secure their support and improve performance. Creating the WBS lets the team mentally walk through the project and improve the plan. That makes execution easier and less risky, encourages involvement, and helps people see the project as achievable.

The WBS may look like an organization chart. Its purpose is to break the project and the work required for its deliverables into pieces you can plan, organize, manage, and control. Start at the top and decompose deliverables and work into smaller units called work packages.

Rules for Creating a WBS

1. Involve the team.
2. Complete the first level before breaking the work down further.
3. Make each level a subdivision of the level above.
4. Make the full project understandable from all the WBS levels together.
5. Include only this project’s deliverables.

Work Packages and Control Accounts

A deliverable can be considered a work package when:

1. It can be estimated realistically and confidently.
2. It can be completed quickly.
3. It can be completed without interruption or a need for further information.
4. It can be outsourced or contracted out when appropriate.

Number the WBS levels after the WBS is complete so each work package has an identifier. Some projects manage costs at a higher WBS level, called a control account, instead of at the work-package level.

During planning, the team uses the scope statement, WBS, and WBS dictionary to break work packages into the activities needed to produce the deliverables. This activity list is developed during Define Activities in Time Management.

The WBS is the foundation for the rest of project planning. Its graphical hierarchy identifies every deliverable. For an activity to belong to the project, it must relate to work included in the WBS. The WBS helps the team think through every part of the project and can be reused for other projects. Use it to show the hierarchy and use the schedule network diagram to show activity dependencies.

The project manager uses the WBS to decompose the project. In this context, deconstruction and decomposition describe the same process.

Open Full-Size Diagram ↗

WBS Dictionary

The WBS dictionary describes the work for each work package. It is an output of Create WBS. It helps prevent scope creep and gives everyone a clear description of the deliverable. The dictionary can:

• Act as a work authorization system by showing when a work package starts.
• Record schedule milestones, acceptance criteria, and other work package details.
• Help control what work gets done.
• Help stakeholders understand the effort involved in a work package.

Open Full-Size Diagram ↗

Scope Baseline

A baseline is the final, approved version of part of the project management plan. The scope baseline consists of the scope statement, WBS, and WBS dictionary. Management and stakeholders must approve all three before work begins. Compare actual progress with the scope baseline.

Request a change for any deviation from the scope baseline. Process the request through Perform Integrated Change Control. If approved, update the scope statement, WBS, WBS dictionary, and any other affected documents or components. Meeting the requirements and the scope baseline measures project success.

Verify Scope

Verify Scope keeps the project on track against the approved scope. Talk regularly with the customer or sponsor and seek acceptance of completed deliverables.

Inputs to Verify Scope

• Validated deliverables from Perform Quality Control.
• The scope statement, WBS, and WBS dictionary.
• The requirements traceability matrix.
• Requirements documentation.

Outputs of Verify Scope

• Accepted deliverables.
• Change requests.
• Updates to project documents.

Verify Scope can take place at the end of each phase or throughout the project as part of monitoring and controlling. It provides formal customer acceptance of interim deliverables. Close Project or Phase provides final acceptance or sign-off for the project or phase as a whole.

Control Scope

Control Scope has two main responsibilities. Measure project and/or product scope performance and manage changes to the scope baseline. Check scope frequently to see whether work is proceeding as planned.

The two essential inputs are the scope baseline from the project management plan and the work completed so far. Requirements documentation and the requirements traceability matrix can also help. Identify any deviations from the baseline and recommend corrective or preventive action. If a change is needed, raise a change request, use Perform Integrated Change Control, and update the necessary documents.

The project manager proactively controls the project against the baselines in the project management plan. Follow the change management process for all scope changes.