# Planning Project Scope and Requirements

> Chapter 8 of the Courseiva PMI-PMP curriculum — https://courseiva.com/learn/pmi-pmp/planning-project-scope-and-requirements

**Official objective:** 2.2 — Plan and manage project scope and requirements.

## Introduction

Planning project scope and requirements is the act of defining exactly what the project will deliver and what it will not deliver, before any work begins. It matters for the PMP exam because the majority of project failures trace back to vague or uncontrolled scope. If you master this concept, you will understand how to prevent the single biggest cause of missed deadlines and blown budgets.

## The Kitchen Renovation Analogy

A kitchen renovation plan is the blueprint for every decision about cabinets, appliances, and work surfaces. 

 Before any demolition starts, the homeowner and contractor must agree on the exact scope of the renovation. The homeowner lists everything they want: new quartz countertops, a double oven, a farmhouse sink, under-cabinet lighting, and a specific tile backsplash. The contractor then documents each item, checks that the budget covers it all, and notes what is deliberately excluded, such as repainting the ceiling or replacing the flooring. This written document becomes the scope statement. 

 During the build, the homeowner cannot suddenly demand a built-in wine fridge that was never on the list without a formal change request. If the homeowner asks for the fridge, the contractor pauses, estimates the extra cost and time, and the pair sign an amendment to the scope. Neither party can claim surprise because the original plan and any approved changes are written down in black and white. 

 This process maps directly to planning project scope and requirements in IT. The homeowner is the customer, the contractor is the project manager, the scope document is the project’s scope statement, and any new request after work starts is a change request that must be formally evaluated and approved.

## Core explanation

Project scope is the sum total of all the work required to deliver a product, service, or result. Requirements are the specific conditions or capabilities that the project must meet. Together, they form the foundation of every project plan. 

 Let us start with a definition of a project. A project is a temporary endeavour undertaken to create a unique product, service, or result. Every project has a beginning, a middle, and an end. The scope is the boundary that separates what the project will do from what it will not do. 

 Requirements come in several types. Business requirements describe why the organisation is undertaking the project. Stakeholder requirements describe the needs of the people who have an interest in the project. Solution requirements describe the features and functions of the product itself. Transition requirements describe how to move from the current state to the future state. Project requirements describe the conditions under which the project must operate, such as compliance with regulations or internal policies. 

 The process of planning project scope and requirements follows a structured sequence. First, you collect requirements from stakeholders. Stakeholders are individuals, groups, or organisations who may affect, be affected by, or perceive themselves to be affected by the project. You use techniques like interviews, surveys, focus groups, and workshops to gather their needs. Second, you define the scope by writing a detailed project scope statement. The scope statement includes the product scope description, the deliverables, the acceptance criteria, and the project exclusions. Exclusions are just as important as inclusions because they prevent misunderstandings. For example, a project to build a mobile banking app might explicitly exclude a desktop version. Third, you create a work breakdown structure (WBS). A WBS is a hierarchical decomposition of the total project work into smaller, manageable pieces called work packages. The lowest level of the WBS is a work package, which can be assigned to a team, estimated for cost and time, and monitored for progress. 

 A concept called scope creep is critical to understand. Scope creep is the uncontrolled expansion of project scope without adjustments to time, cost, or resources. It happens when stakeholders add small requests that individually seem harmless but collectively derail the project. The tool to control scope creep is the change control process. Any proposed change to the scope must go through a formal review where the project manager evaluates the impact on the triple constraint: time, cost, and quality. Only after approval by the change control board can the new work begin. The change control board is a group of stakeholders who have the authority to approve or reject changes to the project. 

 Why does this exist? Before formal scope management, IT projects frequently failed because teams built the wrong product. Teams worked hard on features nobody needed while the real requirements went unaddressed. Requirements management replaced guesswork with a disciplined process that ensures that every feature in the final product traces back to a documented stakeholder need. Traceability means that each requirement has a unique identifier and can be linked to its source, to the design element that implements it, and to the test case that verifies it. 

 The PMP exam treats planning project scope and requirements as a core process group. The Project Management Institute (PMI) publishes a book called the PMBOK Guide (Project Management Body of Knowledge) which standardises these practices. The exam focuses on the inputs, tools and techniques, and outputs defined in the PMBOK Guide scope management knowledge area. You must memorise the sequence of processes: plan scope management, collect requirements, define scope, and create WBS. Each process has a distinct purpose and produces specific documents. 

 For example, the plan scope management process produces the scope management plan and the requirements management plan. The scope management plan describes how the team will define, validate, and control the scope. The requirements management plan describes how the team will analyse, document, and manage requirements. These plans sit inside the overarching project management plan. Every project manager must write these plans before any substantive work begins. Skipping them is a recipe for confusion and conflict.

## Real-world context

A real-world IT professional working as a project manager at a medium-sized company receives a request from the sales director to build a customer relationship management (CRM) system. The sales director says, 'I need a system that tracks leads and shows me reports.' This is too vague to build anything. 

 The project manager initiates the planning project scope and requirements process by conducting stakeholder analysis. She identifies every person who has a stake in the new CRM: the sales director, the sales team, the IT support team, the finance department, and the customer service team. She schedules a series of requirements workshops. 

 In the workshops, she uses several techniques to elicit requirements: 

 - Brainstorming sessions where the sales team lists every feature they want. 
 - Interviews with the finance director to understand budget constraints and reporting needs. 
 - Prototyping a mock-up interface to help stakeholders visualise the final product. 
 - Document analysis of existing spreadsheets and databases to identify current data fields. 

 After collecting all the raw requirements, the project manager performs requirements analysis. She groups similar items, prioritises them using a technique called MoSCoW (Must have, Should have, Could have, Won't have), and checks for conflicts. For example, the sales director wants real-time reports, but the IT team says real-time reporting will require expensive new infrastructure. The project manager documents this conflict and brings it to the project sponsor for resolution. 

 She then writes the project scope statement. The scope statement specifies that the CRM will track leads, manage contact information, log customer interactions, generate monthly pipeline reports, and integrate with the existing email system. The scope statement also lists exclusions: the project will not include a mobile app, will not include automated email campaigns, and will not replace the existing accounting software. 

 The project manager creates the requirements traceability matrix (RTM). The RTM is a table that links each requirement to its source, to the WBS work package that will deliver it, and to the test case that will verify it. For example, the requirement 'system shall generate a monthly pipeline report' links to the sales director as source, to WBS work package 3.2 'build reporting module', and to test case TC-045 'verify report accuracy with three test data sets'. 

 Finally, she builds the WBS. The WBS breaks the CRM project into phases such as design, development, testing, deployment, and training. Each phase decomposes further into work packages like 'design database schema', 'develop login screen', 'create pipeline report query', 'perform user acceptance testing', and 'write training manual'. The WBS ensures that every piece of work is accounted for and nothing is forgotten.

## Exam focus

The PMP exam tests planning project scope and requirements heavily. Expect roughly 10 to 15 percent of your total exam questions to come from this area. The exam loves to test the difference between scope and requirements and the correct sequence of processes. 

 Specific question types you will encounter: 

 - Process sequence questions: They ask 'Which process comes after collect requirements?' The correct answer is 'define scope'. The exact order in the PMBOK Guide is plan scope management, collect requirements, define scope, and create WBS. 
- Input-output questions: They ask 'Which document provides inputs to the define scope process?' The correct answer is 'project charter', because the charter contains the high-level project description and the project manager's authority. 
- Trap scenarios: They present a situation where a stakeholder makes a small request near the end of the project. The trap answer is 'just do it because it is small'. The correct answer is always 'submit a change request through the formal change control process', regardless of size. 
- WBS questions: They ask about the characteristics of a good WBS. Expect answers like '100 percent rule', which means the WBS must include all work required to complete the project, and no work outside the project. 
- Requirements traceability matrix questions: They ask why the RTM is important. The correct answer is that it links requirements to business objectives and to the final deliverable, ensuring nothing is lost. 

 Common traps the exam sets: 

 - Conflating the project scope statement with the requirements documentation. The scope statement is the formal definition of the project boundaries. Requirements documentation is the detailed list of all individual stakeholder needs. They are separate documents. 
- Assuming that scope creep is acceptable if the customer is happy. It is not acceptable, because it violates the baseline and destroys the project manager's ability to control cost and schedule. 
- Thinking that the WBS is the same as a schedule or a budget. The WBS is a decomposition of work, not a timeline or a cost spreadsheet. It comes before both. 
- Believing that you can define scope only once at the start of the project. Scope is defined early but is subject to formal change control throughout the project lifecycle. 

 Key definitions you must memorise: 

 - Scope baseline: The approved version of the scope statement, WBS, and WBS dictionary. You use the baseline to measure performance and control changes. 
- Validate scope: The process of formally accepting the completed project deliverables from the customer. It happens at the end of each phase or at the project end. 
- Control scope: The process of monitoring the status of the project and managing changes to the scope baseline. It happens continuously during the project. 
- Product scope: The features and functions of the product, service, or result. 
- Project scope: The work performed to deliver a product, service, or result with the specified features and functions. 

 The exam will ask situational questions where you have to choose the next step. The pattern is: identify that scope is not clearly defined, then choose the option that says 'collect requirements' or 'define scope'. If scope is defined but a change is requested, choose the option that says 'submit a formal change request'.

## Step by step

1. **Plan Scope Management** — Write the scope management plan and requirements management plan. These plans describe how the team will define, validate, and control scope throughout the project.
2. **Collect Requirements** — Use interviews, surveys, workshops, and prototypes to gather needs from every stakeholder. Document all requirements in the requirements documentation and the requirements traceability matrix.
3. **Define Scope** — Write the project scope statement, which includes the product scope description, deliverables, acceptance criteria, and exclusions. This statement becomes the authoritative reference for what the project includes and excludes.
4. **Create Work Breakdown Structure (WBS)** — Decompose the total project work into smaller work packages. Organise them hierarchically. The WBS dictionary provides detailed descriptions of each work package, including associated costs, resources, and duration estimates.
5. **Validate and Control Scope** — Present completed deliverables to the customer for formal acceptance (validate scope). Simultaneously, monitor the project for any deviations from the baseline. Any change request goes through the integrated change control process before the scope baseline is updated.

## Comparisons

### Project Scope vs Product Scope

**Project Scope:**
- Describes the work needed to deliver the product
- Measured against the project management plan
- Included in the project scope statement

**Product Scope:**
- Describes the features and functions of the product
- Measured against the product requirements
- Included in the requirements documentation

### Validate Scope vs Control Quality

**Validate Scope:**
- Focuses on acceptance by the customer
- Occurs at the end of a phase or project
- Involves formal sign-off from stakeholders

**Control Quality:**
- Focuses on correctness of the deliverable against specifications
- Occurs throughout the project
- Involves inspection and testing by the team

### Requirements Traceability Matrix vs WBS Dictionary

**Requirements Traceability Matrix:**
- Links each requirement to its source and test case
- Created during collect requirements process
- Used to verify that each requirement is delivered

**WBS Dictionary:**
- Describes each work package in detail
- Created during create WBS process
- Used to understand what work each package includes

### Project Charter vs Project Scope Statement

**Project Charter:**
- Authorises the project manager to start the project
- Contains high-level project description and business case
- Created by the project sponsor

**Project Scope Statement:**
- Defines the detailed scope of the project
- Contains deliverables, acceptance criteria, and exclusions
- Created by the project manager with stakeholder input

## Diagram

_This flowchart shows the sequence of processes from collecting requirements through to establishing the scope baseline and controlling changes._

```mermaid
flowchart TD
    A[Stakeholder Needs] --> B[Collect Requirements]
    B --> C[Requirements Documentation]
    B --> D[Requirements Traceability Matrix]
    C --> E[Define Scope]
    D --> E
    E --> F[Project Scope Statement]
    F --> G[Create WBS]
    G --> H[WBS + WBS Dictionary]
    H --> I[Scope Baseline]
    I --> J[Control Scope]
    J --> K[Change Request]
    K --> L[Integrated Change Control]
    L --> M[Approved or Rejected]
```

## Common misconceptions

- **Misconception:** Scope and requirements mean the same thing, so you can use the terms interchangeably. **Reality:** Scope is the total work of the project; requirements are the specific conditions or capabilities that the product must meet. Scope is about the work; requirements are about the product. (Beginners hear these terms used loosely in conversation and assume they are synonyms. The exam specifically tests the difference.)
- **Misconception:** You should collect all requirements at the very start of the project and never change them. **Reality:** Requirements are collected early but are expected to evolve. Changes are managed through the formal change control process. Rigid requirements gathering without iteration causes project failure. (Many beginners come from environments where 'requirements are fixed' is treated as a virtue. In IT, requirements change as stakeholders learn more about what they need.)
- **Misconception:** A detailed WBS is only needed for large, complex projects. Small projects can skip it. **Reality:** Every project benefits from a WBS, regardless of size. Even a small project has tasks that need to be identified and estimated. Skipping the WBS leads to forgotten work and inaccurate budgets. (Beginners think the WBS is bureaucratic overhead. In reality, it is the most effective tool for ensuring no work is missed.)
- **Misconception:** The project manager should define the scope alone because they have the expertise. **Reality:** Scope definition requires input from stakeholders, the project sponsor, the team, and subject matter experts. The project manager facilitates but does not dictate scope. (New project managers often misunderstand their role as a decision-maker rather than a facilitator. The exam emphasises collaboration.)
- **Misconception:** Scope creep is acceptable if the customer pays for the extra work. **Reality:** Even if the customer pays, uncontrolled scope changes still damage the project baseline. The formal change process exists to evaluate the impact on the whole project, not just the cost. (Beginners think that budget approval alone solves the problem. The exam expects you to recognise that process trumps ad hoc decisions.)

## Key takeaways

- Project scope is the work required to deliver the product; product scope is the features and functions of that product.
- Requirements must be documented, prioritised, and traced to deliverables using a requirements traceability matrix.
- The work breakdown structure (WBS) follows the 100 percent rule: it must include all project work and only project work.
- Scope creep is any unauthorised change to the project scope and must be controlled through the formal change control process.
- The four processes in planning project scope are: plan scope management, collect requirements, define scope, and create WBS.
- Validation of scope occurs when the customer formally accepts deliverables; control of scope occurs continuously to manage changes to the baseline.

## FAQ

**What is the difference between project scope and product scope?**

Product scope is the features and functions of the product itself. Project scope is the work required to deliver that product. A change to product scope almost always changes project scope.

**What is a WBS dictionary and why do I need one?**

A WBS dictionary is a document that provides detailed information about each element in the work breakdown structure, including description, budget, resources, and acceptance criteria. You need it because the WBS alone does not contain enough detail to manage the work.

**How do I handle a stakeholder who keeps adding small requests?**

Follow the change control process. Document each request, evaluate its impact on time, cost, and quality, and submit it to the change control board for approval. Do not implement any change without formal authorisation.

**What is the 100 percent rule in the WBS?**

The 100 percent rule states that the WBS must include 100 percent of the work defined by the project scope and must exclude any work that is not part of the project scope.

**When should I validate scope versus control scope?**

Validate scope happens at the end of a phase or project when the customer formally accepts deliverables. Control scope happens continuously to monitor the scope baseline and manage changes throughout the project.

**Can I change the scope baseline after it has been approved?**

Yes, but only through the formal change control process. The change must be evaluated, approved, and then the baseline is updated. You cannot change it informally or unilaterally.

## Check your understanding

1. **What is the primary purpose of the work breakdown structure?**

   Answer: The WBS decomposes the total project work into manageable work packages to ensure that all work is identified and can be estimated, assigned, and monitored.

2. **A stakeholder requests a new feature two weeks before the project deadline. What is the correct action?**

   Answer: The project manager should document the request and submit it through the formal change control process for evaluation before any work is done.

3. **What document links each requirement to its source and to the test case that verifies it?**

   Answer: The requirements traceability matrix (RTM).

4. **What is scope creep?**

   Answer: Scope creep is the uncontrolled expansion of project scope without adjustments to time, cost, or resources, often caused by informal requests from stakeholders.

5. **Which process occurs after 'define scope' in the PMBOK Guide sequence?**

   Answer: Create WBS.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/pmi-pmp/planning-project-scope-and-requirements