Planning Project Scope and Requirements

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.

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:

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.