2 Scope Planning and Control

Define the project boundaries

Project scope defines the work and deliverables required to meet project objectives, as well as work that is excluded. Clear boundaries help stakeholders agree on what success means and give the team a basis for estimating, scheduling, assigning responsibility, and controlling changes.

A Scope statement translates broad goals into a description of the work. It identifies measurable objectives and deliverables, in-scope and out-of-scope work, acceptance criteria, assumptions, and constraints. Assumptions are planning beliefs; constraints are limits, such as a fixed budget, deadline, or required technology.

For example, a clinic appointment-booking project might include a patient booking website, staff training, and launch support, while excluding replacement of the existing medical-record system. Stating exclusions explicitly helps prevent misunderstandings.

Gather and clarify requirements

Requirements describe stakeholder needs and the conditions deliverables must satisfy. Identify affected stakeholders and gather their needs through methods such as interviews, workshops, observation, document review, and surveys. Clarify conflicting requests, confirm priorities, and make each requirement clear and testable.

“A site must be easy to use” is difficult to verify. A more useful requirement might state that a patient can book an available appointment in no more than four steps. Record requirements in a requirements document. A Requirements traceability matrix can link each requirement to its source, related deliverable, and verification or acceptance method. This helps the team check that requirements are addressed and assess proposed changes.

A stakeholder request that the booking system be “fast” needs follow-up: clarify the need and agree on a measurable performance requirement and a way to test it. Until then, the request is ambiguous and cannot reliably support verification or acceptance.

Decompose scope into deliverables

A Work breakdown structure (WBS) decomposes the project’s total scope hierarchically into manageable components. Organize it around deliverables—what the project produces—rather than making it merely a list of activities or a timeline. Decompose each deliverable until its work can be estimated, assigned, and controlled as a Work package. A WBS dictionary can clarify an element’s content, boundaries, owner, and acceptance conditions.

The 100-percent rule means the WBS includes all work required by the approved scope and no work outside it. At each level, the child elements together represent the full work of their parent. Include necessary project work as well as product deliverables.

For the clinic appointment-booking project, a WBS could be organized as follows:

1. Appointment-booking solution
   1.1 Approved requirements and design
   1.2 Booking website

   • 1.2.1 Patient booking interface

   • 1.2.2 Appointment availability function
     1.3 Verified and accepted solution

   • 1.3.1 Test results

   • 1.3.2 User acceptance
     1.4 Deployment and handover

   • 1.4.1 Production launch

   • 1.4.2 Staff training and handover

The WBS does not specify activity sequence or dates. Those are developed in the schedule using the work and deliverables identified through scope planning. If staff training is an approved deliverable but is missing from the WBS, the WBS is incomplete; add and decompose the training deliverable before using the WBS as the basis for estimates and assignments.

Establish the baseline and control changes

Once reviewed and approved, the Scope baseline is the reference for judging whether work or a request changes approved scope. It typically includes the approved scope statement, WBS, and WBS dictionary.

Use the agreed change-control process to manage requests:

1. Record the requested change and its reason.

2. Assess effects on requirements, deliverables, WBS, schedule, cost, resources, quality, and risks.

3. Have the authorized decision-maker approve, reject, or defer the request.

4. If approved, update affected plans and baselines, communicate the decision, and authorize the work.

5. Verify deliverables against requirements and obtain formal acceptance.

Do not begin requested extra work simply because someone asked for it. An unreviewed addition can cause Scope creep. Adding features that were never requested or approved is sometimes called Gold plating. Change control does not prohibit changes; it makes their consequences visible and ensures authorized changes are reflected in the plan. When impacts warrant it, cost and schedule plans should be updated.

Apply scope controls to project decisions

If an executive asks the clinic team to add text-message reminders that are not in the approved scope, log the request, clarify its requirements, assess effects on cost, schedule, resources, and risks, and seek approval through the agreed process. Add it to the plan only if authorized.

Across these decisions, define scope and acceptance conditions, make requirements verifiable, ensure the WBS contains all and only the approved work, and assess and authorize changes before changed work begins.