UPI Study › Courses › Project Management › Free lessons › Lesson 3.2 Free with a free account
Writing an Effective Project Scope Statement
Project Management · Chapter 3: Building a Comprehensive Project PlanSection 3.2 · lesson 16 of 7313 min · free with a free account
Free preview
Create a free account to keep watching
It takes a minute and costs nothing. Your free account unlocks all of Chapter 1 and 3 more lessons of Project Management.
Lesson complete
Earn the 3 college credits for Project Management
Enrolling adds a quiz after each lesson, the graded work and the official transcript. Recommended for credit by NCCRS.
Next lesson: Resource Management Planning and Allocation →← Foundational Steps in Developing a Project PlanNext lesson: Resource Management Planning and Allocation →
In this lesson
Turning requirements into a clear, testable and bounded scope statement.
- Sort requirements into needs, wants and constraints and test their quality
- Distinguish product scope from project scope
- Write measurable objectives, deliverables and reasoned exclusions
- Rewrite vague scope language into testable commitments that limit scope creep
Free study notes
Get this lesson's notes by email
The key points and 4 practice questions with answers, in your inbox. One email, free.
One email. Unsubscribe in one click.
Transcript
Everything said in the video, section by section (1,898 words). Read along, or search it.
Opening Question
The Missing Reply-to-Reschedule Button
Six weeks into testing a new text-reminder service for Marrowfield's community clinics, the front desk has a question. Ravi Mehta, the front-desk supervisor, asks Dana Reyes, the project manager, where the reply-to-reschedule button is. He'd assumed from the start that patients could answer the text to move their appointment. The scope statement never said they could. It never said they couldn't, either. Adding it now needs a pricier service tier, scheduling links and more testing. It would break the budget. So who's right? And what single sentence would have prevented this?
Requirements
Needs, Wants and Constraints
Rewind to week one. Dana's raw material is requirements: statements of what the people affected need the result to do, or to be. Those people are stakeholders, and each wants something different. Ravi wants fewer morning calls to the desk. Marcus Bell, the director sponsoring the project, wants fewer missed appointments. Billing wants no cost beyond the budget. What stakeholders say falls into three kinds. A need is something the result must provide, or the problem isn't solved: the desk must see which patients were contacted. A want would make the result better, but its absence wouldn't defeat the purpose, like a favorite color scheme. A constraint is a limit imposed from outside: a fixed budget, a legal rule, or a date that can't move. Needs and constraints are almost always carried in. Wants come in when there's room, and leaving one out should be a visible decision.
Requirement Quality
Six Tests for a Usable Requirement
A raw requirement isn't usable yet. A common teaching checklist asks six things of each one. Is it necessary: does some stakeholder actually need it? Is it unambiguous: would two careful readers understand it the same way? Is it verifiable: could someone examine the result, and say definitely whether it's met? Is it singular, stating one thing? Is it consistent with the other requirements? And is it traceable, back to whoever raised it, and forward to the part that satisfies it? Ravi's first version was: the reminders should be timely. One reader hears the day before. Another hears two hours before. The rewrite: each patient with a mobile number on file receives one text reminder, forty-eight hours before the appointment. It passes all six. Requirements are the input. Scope is the output: the full extent of what the project will produce, and the work it will do. And scope is a decision, not a discovery. Stakeholders ask for more than any project can deliver, so someone must decide, and write it down.
Key Terms
Product Scope Versus Project Scope
The word scope means two different things, and mixing them up muddles plans. Product scope is the features of what's delivered: what the result is, and what it can do. For the reminder service, one text to each patient, forty-eight hours ahead, naming the clinic, date and time, with a record of delivery. Project scope is the work needed to deliver that result: building, testing, training, and handing over. Here, configure the messaging software, write the templates, test delivery with twenty volunteer patients, train the front desk, and hand over to clinic operations. The two can fail independently. A team can do all the work and still miss a required feature, or deliver a fine service and skip the training. Product scope is judged against the requirements. Project scope is judged against the plan: was all the agreed work done, and no other?
Quick Check
Spotting the Product Scope Item
Quick check. Here are three items from a later version of the plan. Which one is product scope? Pause, and decide. The language switch. It's something the delivered service does, so it's product scope. Writing a test plan and training staff are work the project does to deliver it. Those are project scope.
Scope Statement
From Charter Sentence to Agreed Detail
Dana starts from the charter, which authorized the project. Its scope was one sentence: remind patients of upcoming appointments by text message. A charter holds scope at a high level. It answers: should this project exist, and roughly what is it? The scope statement comes after the requirements. It describes, in agreed detail, what the project will deliver, what it won't, and the conditions around that agreement. It answers a sharper question: exactly what are we committing to? It's more detailed than the charter, but it isn't an activity list. It says a set of four message templates, not who writes each one, or when. Detail flows down in layers: the charter, then the requirements, then the scope statement, then the work breakdown structure and schedule. So the statement can stay stable, while the detailed work plan is revised.
Components
Measurable Objectives and Deliverables
A scope statement has a few standard parts. It opens with objectives. An objective is what the project is meant to achieve, written so success can be measured. It's the effect the sponsor wants, not the thing produced. The reminder service is a deliverable. Reducing appointments missed without notice is the objective. Improve attendance can't be checked. A measurable objective names a quantity, a way to measure it, and a point in time. Dana writes: by the end of the third month after launch, the share of appointments missed without notice will be lower than in the three months before. Then come the deliverables, each with an identifier, a name, and a description saying what it is, how many, and in what form. D3, staff quick-reference guide: one guide, at most two pages, printed and electronic, showing how the desk views a patient's reminder status.
Exclusions
Stating What Is Out and Why
Then the boundary: the edge between what the project is responsible for, and what it isn't. An exclusion is an item explicitly stated to be outside the project. It's tempting to think the inclusions imply the rest. They don't. Readers fill gaps with what they expect, and expectations differ. And the items most likely to be wrongly assumed sit right at the boundary: features that sound like natural neighbors of a listed deliverable. A good exclusion gives its reason. Reminders by voice call are excluded, because the budget covers one channel only. The reason helps a future reader judge whether the exclusion still stands, if conditions change.
Assumptions and Constraints
Tested Versus Respected
The statement also records assumptions and constraints, and the difference matters. An assumption is taken as true for planning, without proof: that the clinics keep patients' mobile numbers up to date. Each one links to the assumptions log, with an owner, a date, a check, and what changes if it's false. If half the numbers are wrong, the deliverable reminders to all patients can't be met as written. A constraint is a given that the team must work within, and can't validate away: the budget is fixed at the amount in the charter. Assumptions are tested. Constraints are respected. When law bears on scope, like rules on patient information or automated texts, the statement records it as a constraint, and the legal question goes to counsel.
Writing Rules
One Testable Commitment per Sentence
Now the language itself. A scope sentence is testable when someone who didn't write it could check the finished work, and reach a definite yes or no. Four habits get you there. Avoid vague words like fast, user-friendly, robust or support. State the number, the method, and the conditions. Avoid open-ended lists that end in and so on, or as needed. The reader decides what they contain. Avoid compound sentences that join several commitments with and, so one can fail while another is met. Which gives the last habit: one commitment per sentence, so each sentence has one test, and one result. Then ask three questions of every sentence. Could two readers disagree on its meaning? Could I check it by counting, measuring or inspecting? Does it show its edge? Take this: the website will be fast and user-friendly. It fails all three. The rewrite splits it in two. Each of the five core pages loads within three seconds, on the agreed test connection. And five test users who've never seen the site each place a sample order, without help, in under four minutes. Now a stopwatch gives a yes or no, and a sixth page simply isn't covered.
Quick Check
Which Sentence Is Ready to Sign
Quick check. Dana's draft has three candidate sentences, and one is written well enough to sign. Which one? Pause, and decide. The poster. You can count the posters, and measure their size. Promptly and as needed have no measure and no edge. Friendly and modern let each reader supply their own meaning.
Scope Creep
Preventing Creep Through Writing
Scope creep is the gradual growth of scope through small additions, accepted without a deliberate decision to change cost, time or resources. Gradual is the key word. No single addition looks large, so creep goes unnoticed until the budget or schedule is already strained. Handling change requests after baselining is a control process, covered later in the course. But much creep is prevented by how the statement is written. Explicit exclusions close the gap between what the sponsor assumes and what the team intends. Sponsor sign-off turns a document the team believes into one both sides have agreed. It works best when the sponsor reads the exclusions too. Removing ambiguity closes the gap between a narrow and a wide reading, which is where unplanned work gets in. And traceability links each deliverable back to a requirement, and each requirement back to the stakeholder who raised it. It works both ways. A requirement with no deliverable is an oversight, or a candidate for exclusion. A deliverable with no requirement is hidden, or an invented extra.
Debate
How Much Detail to Fix Early
How much detail to fix at definition is disputed. One view: make it as detailed as can be agreed before work begins. Ambiguity costs least to resolve on paper, and a signed reference gives both sides something firm. The other: much early detail will be wrong, because people learn what they want by seeing partial results. Fix scope coarsely, and refine it as the work teaches. The empirical part is about circumstances: how stable the requirements are, and how costly later change is. The normative part is about values: predictability or responsiveness, and who carries the risk when scope proves wrong. Evidence on the first can't settle the second.
Case Resolution
One Sentence That Would Have Settled It
Back to Ravi's question, six weeks into testing. The statement was clear about what was delivered, but silent about the neighboring feature, and the silence produced the gap. Dana decides not to add two-way replies. She records them as a proposal for a later project, and explains the budget constraint to Ravi. Then she adds an exclusions section: patient replies and self-service rescheduling are out of scope, because the budget covers one-way messages. The launch delivers less than Ravi pictured, in exchange for holding the budget and the date. That exclusion would have taken one sentence to write, and one conversation to settle, in week one.
Scope Baseline
Signed Statement Becomes the Foundation
Once Marcus signs the scope statement, it stops being a draft, and becomes the foundation of the scope baseline. The scope baseline is the approved scope together with its breakdown into pieces of work, held as the fixed reference for performance and change requests. The statement supplies the agreed words and boundaries. Its deliverables are then broken down into the work breakdown structure. So the statement's quality sets a ceiling. A vague deliverable is decomposed, estimated and scheduled vaguely, and the vagueness surfaces late.
Key Takeaways
Requirements, Boundaries and Testable Sentences
To recap. Needs and constraints are carried into scope. Wants come in only when there's room. Product scope is what the result is and does. Project scope is the work to deliver it. Name the exclusions at the boundary, each with its reason. And write one testable commitment per sentence.
About Project Management at UPI Study
Project Management (Business 230) is a self-paced online course of 73 video lessons in 12 chapters, from starting and defining a project to planning, budgets, scheduling tools, proposals, contracts, execution, monitoring, closure, teams and certification. It carries a NCCRS credit recommendation for 3 semester credits.
Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Enroll now → Course details Download the syllabus All Business courses Every course with PRO →
Why take it here
Why students take Project Management with UPI Study
Where the credit goes
Universities that work with NCCRS
Project Management carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.
FAQ
Questions students ask us
About Writing an Effective Project Scope Statement
What is the difference between product scope and project scope?
What should a project scope statement include?
Why should a scope statement list exclusions?
How do you write a testable scope requirement?
About the Project Management course
How many college credits is Project Management?
How much does Project Management cost and what is included?
Which universities accept UPI Study credits?
How long does Project Management take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in Project Management.
73 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →