Skip to content
Getting Digital

Project Scope

Also: scope statement, scope baseline, in scope, out of scope, scope management

Project scope is the agreed description of what a project will deliver and what it will not, stated precisely enough that a change to it can be recognised as a change and decided rather than absorbed.

Assessment. The exclusions are the useful half of a scope statement and the half most teams leave out. Anyone can list what a project will do; the discipline is writing down what it will not, so that the request which arrives in month four is recognisably outside the line rather than a matter of interpretation.

Scope answers the question of what is being made and, at the same precision, what is not. The statement describes the deliverables, the acceptance criteria that say when each is done, the boundaries of the work, and the assumptions the description rests on. Once agreed with the sponsor it is baselined: it becomes the reference against which every later request is measured, so that a request either fits inside the line and is work already planned, or falls outside it and is a change to be estimated and decided. A project without a baseline cannot tell the two apart, and absorbs every request as if it had always been there.

StatementIn scopeOut of scopeWhy the exclusion matters
Customer portal rebuildLogin, account view, invoice downloadPayment processing, mobile appBoth were asked for in month three; both were recognisable as changes
Office relocationMoving desks, network, phonesRefurbishing the new spaceThe landlord's decorators are not the project's problem
Data migrationCustomer and order records since a stated dateOlder archives, marketing listsThe archive request arrived as an assumption; the exclusion made it a decision
  • Deliverables: what is handed over, named specifically enough to be counted.
  • Acceptance criteria: how each deliverable will be judged finished, agreed before the work rather than after.
  • Exclusions: what a reasonable person might assume is included and is not.
  • Constraints and assumptions: the conditions the statement depends on, so that a broken assumption is visibly a scope event.
  • The baseline: the version everyone agreed to, changed only through change control.

The professional certifications examine scope as process: how it is defined, how it is verified at acceptance, how a change is controlled. The agile methods handle the same problem differently, by fixing the time and the team and letting the scope of each iteration be decided at its start, which trades a fixed baseline for a fixed cadence. Both are answers to the same fact, which is that what a project delivers will be argued about, and the argument goes better with a written line to point at.

In practice

A team agrees to build an internal tool for the sales department and writes a scope statement that lists the screens, the reports and the integration with the customer database. Three months in, the sales director asks for the tool to send email campaigns, which seems a small addition to something that already knows who the customers are. The statement's exclusions list says, in one line, that outbound communication is out of scope. The request becomes a change: estimated at six weeks, presented to the sponsor with the effect on the end date, and declined in favour of a separate project. Without that line the team would have built it, been late, and been blamed for the lateness.

  • Inside the line: the screens, the reports, the customer-database integration.
  • Outside it, in writing: outbound communication of any kind.
  • Result: a six-week request became a decision instead of a delay.

Often confused with

Scope Creep
Scope is the agreed line; scope creep is the accumulation of small, unagreed additions that move it without anyone deciding to. A clear statement with exclusions is the defence; change control is the process that turns a creeping addition back into a decision.
Project Charter
The charter states scope at day-one precision and authorises the work. The scope statement is the detailed, baselined version produced once the project knows enough to write one.
Work Breakdown Structure (WBS)
The scope statement says what will be delivered; the work breakdown structure decomposes that into the pieces of work that produce it. The breakdown is scope made hierarchical and countable.

Key takeaways

  • →Write the exclusions; they are what make a later request recognisably a change.
  • →Baseline the statement so requests can be measured against something.
  • →Agile fixes time and team and varies scope per iteration; the line still has to exist, one iteration at a time.

Related concepts

Where this concept sits in the field

Certifications that test this

Vendor exams whose syllabus covers this concept: facts, cost and a preparation path on each page.

FAQ

How detailed should a scope statement be?
Detailed enough that a request in month four can be classified as inside or outside without a meeting. That usually means named deliverables with acceptance criteria and a list of the things a reasonable person might expect and will not get.
What is a scope baseline?
The approved version of the scope statement and its breakdown, frozen as the reference for the project. It changes only through change control, which is what makes the word baseline mean something: every deviation from it is visible and was decided.
How do agile projects manage scope?
By fixing the iteration length and the team and choosing, at the start of each iteration, what fits. Scope varies; time and cost do not. The product backlog is the scope statement rewritten as an ordered list, and the ordering is the ongoing scope decision.

Sources

The primary text this definition rests on. Read it before relying on this one.

  • Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide), Seventh Edition (2021)
  • PeopleCert, Managing Successful Projects with PRINCE2, 7th Edition (2023)

Last reviewed 13 September 2026 · Getting Digital