Home›Blog›Project scope: what it covers, and what it leaves out
FundamentalsBeginner
Published September 6, 2026 · By Vincent KENNEL
Project scope: what it covers, and what it leaves out
Standards spent twenty-five years moving from what a project includes to what it excludes. Where that boundary actually sits, why two legal systems put it in the same place, and what a scope statement has to carry to hold under a contract.
In brief
Project scope is all the work required to deliver a project, and only that work, as the PMBOK Guide has put it since its 1996 edition. Standards have since added the other half: the exclusions. Anything not explicitly included is implicitly excluded, so an expectation nobody wrote down surfaces only in execution, when the contract alone can settle it.
A badly written scope is not paid for at the moment it is written. The 2008 Scope for Improvement survey, run on 183 usable responses covering Australian construction and infrastructure projects worth more than 20 million Australian dollars, found that scoping defects surface most often during execution, at 64 per cent, against 27 per cent during project definition, 31 per cent at market request and 38 per cent during contract negotiation. By execution the parties are bound by a contract. The same report puts the consequence plainly: fixing a scope problem at that stage takes a great deal of goodwill, because the parties fall back on their contracts rather than adjusting, the correction costs money, and it is often paid for in quality.
What project scope covers
The founding sentence has not moved in thirty years. The PMBOK Guide, 1996 edition, chapter 5 page 47: project scope management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully, and it is primarily concerned with defining and controlling what is and is not included in the project. Identical in the 2000 edition, page 51. One word apart in the Third Edition of 2004, page 103. Carried unchanged into the 6th Edition of 2017.
Every other referential adds exactly one thing to it.
ISO adds authorisation. ISO 21502:2020, clause 3.25: project scope is authorized work to accomplish agreed objectives. Two words carry the definition, work and authorized, and the second is the hinge. The same standard defines project governance, at clause 3.22, as the principles, policies and procedures by which a project is authorized and directed to accomplish agreed objectives.
PRINCE2 adds the agreed products. PRINCE2 7 (2023), clause 2.6 page 26: the set of agreed products defines the scope of a project and provides the basis for planning and control. Clause 7.1.2 page 104 casts the same idea as a definition, the sum of the product, delivery and management activities represented by an approved plan.
The IPMA adds the exclusion, inside the definition itself. IPMA ICB 4.0 (2015), competence element 4.5.3 page 109: scope also describes its counterpart, what is not contained in or part of the project. It is the only referential here that writes the exclusion into its own definition, and it lists scope definition with exclusions among the knowledge a practitioner is expected to hold.
The APM adds the widest aggregate. APM Glossary, consulted 19 August 2026: scope is the totality of the outputs, outcomes and benefits and the work required to produce them. It is the only definition that holds all four in one word.
And one source frames it as a contract. Scope for Improvement 2008, page 4: the scope of a project is the contractual expression of a principal's requirements. No normative referential puts it that way, and it is the sentence that turns this article towards the contract.
Product scope, project scope
One word covers two objects, and the standards have separated them from the start.
The PMBOK Guide, 1996 edition, page 47, separates them: product scope is the features and functions to be included in a product or service, project scope is the work that must be done to deliver a product with those features and functions. The word result enters both definitions in the Third Edition of 2004, page 104, and the pair holds through to the 7th Edition of 2021.
They are not measured against the same thing either. Same 1996 edition, same page: completion of the product scope is measured against the requirements, completion of the project scope against the plan. A project can therefore deliver exactly the specified product and still sit outside its scope on the work, and the reverse.
The supplier adds a third asymmetry, and it is written into the standard. ISO 21502:2020, clause 4.2.3: in most cases the supplier's project scope is a portion of the customer's project scope. Two organisations bound by one contract are not describing the same scope, and both are correct.
The work breakdown structure is not the scope. It is one possible representation of it, and since 2021 not even the only one: ISO 21502:2020, clause 7.4.2, states that the authorized work forming the project's scope can be defined in terms of the project's objectives, mapping, or in a work breakdown structure. What a breakdown does give is a container that settles the question. The PMBOK Guide, 1996 edition, clause 5.3.3.1 page 54: work not in the WBS is outside the scope of the project. The NASA Work Breakdown Structure (WBS) Handbook, revision E (2025), section 2.1, says the same from the other side, that work scope not contained in the project WBS should not be considered part of the project. How that breakdown is built, and how far down it goes, is a separate subject.
Why the boundary is a legal line
Once the scope is under contract, its boundary stops being a team convention. It is the point at which the legal regime changes, and two independent systems of law put it in the same place.
American acquisition doctrine states it outright. MIL-HDBK-245D, revision D of 3 April 1996, clause 3.4: the statement of work defines the contract and is subject to the interpretations of contract law, and the language detailing the contractor's effort may be pertinent to legal questions concerning the scope of work. Clause 3.6.1 of the same handbook adds that the scope paragraph defines the breadth and limitations of the work to be done.
The buyer's power to change that work stops at the same line. FAR 52.243-1, Changes, Fixed-Price, August 1987 edition: the contracting officer may at any time, by written order, make changes within the general scope of this contract, and any resulting increase or decrease in cost or time is settled by an equitable adjustment. FAR 43.201(a) states the principle plainly, that the unilateral power to modify is exercised in designated areas, within the general scope of the contract.
French public procurement law reaches the same boundary in different words. Code de la commande publique, article L2194-1, in the version in force consulted on 20 August 2026: modifications, whether agreed or imposed unilaterally by the buyer, may not change the overall nature of the contract. Article R2194-7 lists four tests of a substantial modification, and the third is the one a project team can actually use, that it considerably alters the subject matter of the contract.
Below that contractual boundary sits an ordinary amendment. Above it, this is no longer a modification of the contract, it is a different contract, with everything that implies for the competition that awarded the first one. That is what stops a scope statement from being an internal method document, and it is where the ISO word authorized takes its full sense: authorised by an act that binds, not approved by a committee.
The two sides of that contract do not see the same scope, and the gap has been measured. In the same 2008 survey, on 183 usable responses covering Australian construction and infrastructure projects worth more than 20 million Australian dollars, 38 per cent of principals judged their own projects inadequately scoped before going to market, against 65 per cent of the contractors. The useful fact is not either number, it is the distance between them.
Written in, written out, and never written
A scope boundary looks as though it has two sides. It has three.
The first is what is written in, the scope statement and the deliverables. The second is what is written out, the explicit exclusions. The third is what was never written, and it behaves unlike the other two.
The default rule for that third zone is old, and it is hard. The PMBOK Guide, 1996 edition, clause 5.2.3.1 page 52, in a two-line aside inside the project deliverables component: when known, exclusions should be identified, but anything not explicitly included is implicitly excluded. Strictly unchanged in the 2000 edition, page 56. PRINCE2 7 (2023) states the same rule from the other end, clause 8.2.1 page 132: needs and expectations that are not captured in an approved management product are not part of the project scope, and that distinction is what makes monitoring and control possible.
In law, then, the third zone is already outside. The problem is that it is inside people's heads.
Which is why the PMI added a test in 2004. The PMBOK Guide, Third Edition (2004), clause 5.2.3.1 page 111, under a component named project boundaries: state explicitly what is excluded from the project if a stakeholder might assume that a particular product, service or result could be a component of it. The test is not administrative, it is cognitive. What gets excluded is not what looks doubtful to the project team, it is what somebody else could reasonably believe is included.
Written in, written out, and the never-written stratum
The never-written stratum is not a third legal status: it is the gap between what the contract excludes and what stakeholders assume is included, and the contractual boundary above it moves only by amendment.
Writing the second zone is how the third gets emptied, and four sources show what that looks like on the page.
Contractual. Dictionnaire de management de projet, AFNOR and AFITEP, 3rd edition (1996), chapter 1 page 20, under limites de fourniture, which the dictionary's own English lexicon renders as scope of work: it is useful to complete the limits of supply with a list of exclusions, setting out the goods or services on which disputes could later arise because working habits differ.
Normative. ECSS-M-ST-10C Rev.1 (2009), normative Annex D, D.2.1 a., pages 42 and 43: the mandatory description of a work package carries eighteen elements, and the eighteenth is excluded tasks. It is the only explicit normative requirement to document exclusions in this corpus, and it sits at work package level rather than project level.
Editorial. Mosaic Projects, Statement of Work (SoW), first published 30 July 2011 and revised since: a true boundary statement has an in-scope element and its out-of-scope counterpart, and the most important part of the exercise is writing the out-of-scope statement. Their example runs to one sentence, that this SOW does not include training.
Institutional. NASA Work Breakdown Structure (WBS) Handbook, revision E (2025), Appendix C: the WBS dictionary pairs an includes clause with a does not include clause, systematically. Four level 2 elements carry the pair on a single page.
And then the part that changes the status of the whole exercise. Written exclusions are not drafting hygiene. Three independent bodies treat them as a checked conformity criterion.
Body
Document
What it requires
NASA
Standard Operating Procedure Instruction, revision 6.0 of 23 May 2017, clause 12.1.2.1 and Appendix A
Ground rules and assumptions must show what is included and, often more importantly, excluded from the estimate and scope. The grading table for a basis of estimate runs from all exclusions provided down to none provided
GAO
GAO-09-3SP, Cost Estimating and Assessment Guide, March 2009, page 182
The reviewer must establish that all assumptions and exclusions the estimate rests on are clearly identified, explained and reasonable
AACE International
Recommended Practice No. 17R-97, revision of 6 March 2019, page 8
A basis of estimate documents the assumptions and exclusions made, and an estimate is incomplete without a documented basis of estimate
Two government agencies and a professional association, three documents with no editorial link between them, one identical control point. At NASA, unwritten exclusions are a graded non-conformity.
Where the exclusion came from
Scope is one of the oldest named functions in the discipline. The exclusion is not.
Scope enters the PMI body of knowledge in August 1983, with Oliver's Scope Management in Project Management Quarterly, volume 14 number 1, pages 31 and 32, which defines the function as controlling the scope of the project in terms of the sponsor's aims, goals and objectives. By August 1986 the corpus has seven functions and scope is the first of the series (Woolshlager, Scope Management, Project Management Journal, volume 17 number 3, 1986). In 1987, once risk is added, there are eight, and scope is still cited first (Wideman, The Framework: Part 1: The Rationale, PM Network, volume 1 number 3, August 1987).
Here is the fact that makes everything after it legible. The Scope Management article of that same 1987 issue (Cockfield, PM Network, volume 1 number 3, 1987) prescribes nothing at all about stating what is excluded. Scope is established by inclusion only.
What follows is a twenty-five year drift in a single direction, edition by edition.
1996 and 2000. A two-line aside, lodged inside the project deliverables component, identical in both editions (PMBOK Guide, 1996 edition, clause 5.2.3.1 page 52, and 2000 edition, page 56).
2004. The exclusion leaves the aside and becomes a named component, project boundaries, carrying the cognitive test (PMBOK Guide, Third Edition, 2004, clause 5.2.3.1 page 111). The term project exclusions exists in none of the 1996, 2000 or 2004 editions.
2008. Project exclusions becomes a named component in its own right (PMBOK Guide, 4th Edition, 2008, clause 5.2.3.1 page 115), and it is carried into the 5th Edition of 2013.
2017. The most telling step. The list of scope statement components falls from sixteen in the Third Edition of 2004 to four in the 6th Edition of 2017, clause 5.3.3.1 page 173. Constraints and assumptions leave the list. The exclusions stay. The same edition adds seven words that had never been there: stating explicitly what is out of scope helps manage stakeholder expectations and can reduce scope creep.
2021. The exclusion enters the definition itself. In the glossary of the 7th Edition (2021), a project scope statement is the description of the project scope, major deliverables and exclusions. In the 5th and 6th Editions the same entry read major deliverables, assumptions and constraints.
Eight editions, twenty-five years, and the exclusion travels from optional to definitional without a single edition weakening it.
In short
The move is one paragraph long, and it does not depend on the sector.
Write the out-of-scope lines, and write them with the 2004 test rather than with a sense of what seems obvious from inside the project. Not what looks doubtful to the project team, but what a stakeholder could reasonably believe is included. Three forms already exist and none of them needs inventing: a list of exclusions annexed to the limits of supply (AFNOR and AFITEP, 3rd edition, 1996), a plain sentence of the form this SOW does not include (Mosaic Projects, 2011), and the paired includes and does not include entries of a WBS dictionary (NASA, revision E, 2025).
The reason to do it now rather than later is the one this article opened on. A scope defect shows up in execution, not in definition, and by then the correction runs through the contract.
Stop guessing. See the real impact.
Frequently asked questions
Q.Is a statement of work the same thing as a scope statement?
No. A statement of work is a contract document; the APM Glossary defines it as an annex to the contract detailing deliverables, timescales and management procedures. Mosaic Projects sets a hierarchy: the contract references the project SOW, which in turn details the applicable scope statement.
Q.Are assumptions and constraints part of the scope statement?
Not any longer, in PMI terms. They were listed among its components in the Third Edition of 2004, dropped from the list in the 6th Edition of 2017, and removed from the glossary definition in the 7th Edition of 2021, where the exclusions took their place.
Q.Is the scope statement the same as the scope baseline?
No. The statement is a document, the baseline is an approved set. In the PMBOK Guide, 1996 edition, the WBS alone defined the baseline; from the Third Edition of 2004 it is the approved scope statement, the WBS and its dictionary together, changeable only through formal change control.
References
AACE International - AACE International Recommended Practice No. 17R-97 - Cost Estimate Classification System (révision du 6 mars 2019) - Revision of 6 March 2019
AFNOR, AFITEP - Dictionnaire de management de projet français-anglais-espagnol - 3e édition, 1996
Blake Dawson, Australian Constructors Association, Infrastructure Partnerships Australia - Scope for Improvement 2008: A report on scoping practices in Australian construction and infrastructure projects - 2008
DoD - MIL-HDBK-245D - DoD Handbook for Preparation of Statement of Work (SOW) - Revision D, 3 April 1996
ECSS - ECSS-M-ST-10C Rev.1 - Space project management, Project planning and implementation - 2009
Federal Acquisition Regulation - FAR 52.243-1 Changes - Fixed-Price, and FAR 43.201 Authority to modify contracts - August 1987 edition
GAO - GAO-09-3SP Cost Estimating and Assessment Guide: Best Practices for Developing and Managing Capital Program Costs - March 2009
ISO - ISO 21502:2020 - Project, programme and portfolio management, Guidance on project management - 1st edition, 2020
Légifrance - Code de la commande publique - modification du marché en cours d'exécution (L2194-1, R2194-1 à R2194-9) - Version en vigueur consultée le 20 août 2026
Mosaic Projects - Statement of Work (SoW) - 2011
NASA - Standard Operating Procedure Instruction - SRB Programmatic Assessment Process - Revision 6.0, 23 May 2017
NASA - NASA/SP-20250006071 - Work Breakdown Structure (WBS) Handbook - revision E, 2025
PMI - L. C. Woolshlager - Scope Management - 1986
PMI - Scope Management (fonction du PMBOK, ligne de base ESA 1983) - 1983
PMI - Richard W. Cockfield - Scope Management (numéro spécial PMBOK 1987) - 1987
PMI - R. Max Wideman - The Framework: Part 1: The Rationale - 1987
PMI - A Guide to the Project Management Body of Knowledge (PMBOK Guide) - 2000 Edition - 2000
PMI - A Guide to the Project Management Body of Knowledge (PMBOK Guide) - 1996 Edition - 1996
PMI - A Guide to the Project Management Body of Knowledge (PMBOK Guide) - Third Edition - 2004
PMI - A Guide to the Project Management Body of Knowledge (PMBOK Guide) - 4th Edition - 2008
PMI - A Guide to the Project Management Body of Knowledge (PMBOK Guide) - 7th Edition - 2021
PMI - A Guide to the Project Management Body of Knowledge (PMBOK Guide) - 5th Edition - 2013
PMI - A Guide to the Project Management Body of Knowledge (PMBOK Guide) - 6th Edition - 2017
