Project scope is the description of all the work your team must do to create the project deliverables and reach the project objectives. You document it in three parts: a Project Scope Statement for the customer, a Work Breakdown Structure (WBS) for the team, and a WBS Dictionary with the details. Below is a full project scope example from an IT project, with all three documents in PDF.
Key takeaways
- Write the scope statement for the customer. Seven short sections in plain language: justification, product scope, acceptance criteria, deliverables, exclusions, constraints, and assumptions.
- Trace every line back to an objective. If an acceptance criterion doesn’t prove the business goal, either the criterion or the scope is wrong.
- Exclusions save you the most arguments. One clear “out of scope” line kills a change request months before anyone writes it.
- Show your WBS to the customer. An estimate without visible scope is a silent agreement, and silent agreements turn into scope creep.
Here’s the secret! Scope management is the most important knowledge area on any project, in any industry, at any size. Everything else is built on top of it:
- To create an accurate project budget or schedule, you need to identify 100% of the project scope.
- Risk identification depends on how clear the scope of work is.
- Quality management is part of the scope.
- The Work Breakdown Structure is the central piece that ties the whole plan together.
You get the point. Scope is the King of project management.
And when the scope is vague, you spend your days arguing about what was “obviously included”, chasing people for decisions, and putting out fires. That’s managing chaos, not projects.
I’ll show you a project scope example first. Then I’ll walk you through how to write each part, and how to keep it aligned with your project objectives.
Project Scope Example (IT Project With PDF)
Below is the scope of a small IT project: an upgrade of a stock photo website called Stock Alpha Bank. The project adds better search filters, AI image tagging, a new UI, a feature that lets photographers upload and sell their photos, and a responsive design.
It’s a small project. A big one has the same components, only more of them.
So don’t overcomplicate scope management.
Project Scope Statement Example
Many IT project managers skip this document. They call it bureaucracy. But the exercise takes an hour or two, and it lowers your chances of project failure more than most things you’ll do that week.
Notice that it’s a simple, narrative description written for the customer. No jargon, no task list. Here’s what each section says in this example, and why it’s there:
| Section | What the example says | Why it’s there |
|---|---|---|
| 1. Justification | The site needs better search and AI features to stay competitive. | One sentence links the work to the business objective. The rest stays in the project charter. |
| 2. Product scope | Five enhancements: search filters, AI tagging and suggestions, new UI, photographer uploads with verification, responsive design. | This is where stakeholders see everything they asked for in one place, and how much work it takes. |
| 3. Acceptance criteria | Over 85% user satisfaction with search after release. At least 90% accuracy in AI tagging. Usability tests with no major issues. | Numbers let you and the customer agree on what “done” means. |
| 4. Deliverables | The redesigned site, the AI tools, the upload feature, project documentation, and training materials for internal teams. | Documentation and training are deliverables too. Leave them out, and nobody plans the time for them. |
| 5. Exclusions | No standalone mobile app, no video content, no languages other than English in this phase. | These are the three things a stakeholder was most likely to ask for in month four. |
| 6. Constraints | Six months. A limited budget for custom development. Third-party vendors for some AI features. | Anything that limits how you can deliver. |
| 7. Assumptions | The current servers can handle the new features. Third-party integrations arrive on time. | If an assumption proves false, you have the right to revisit the plan. |
The last page is the customer approval. The Product Director signed it, and any scope change after that requires an amendment.
Work Breakdown Structure Example
The WBS breaks the same scope into eight branches: Project Management, Requirements Analysis, Design, Development, Testing, Deployment, Training and Support, and Project Closure.
If you want to go deeper, read my guide to the Work Breakdown Structure with examples next. It’s the most powerful tool you have to define project scope.
WBS Dictionary Example
Look at the columns. Every WBS element has a code (1.1, 2.1.1), a Jira ticket (PM-002, RA-003), a one-line description, and a link to its specification or test cases.
So the WBS dictionary doesn’t repeat the details. It points to the tickets and documents where the details already live.
Now look at branches 7 and 8. Training materials, post-release support, lessons learned, handoff documents. Even a celebration for the team. Nobody puts these in a requirements document, and they still take days of work. If they’re not in your scope, they’re not in your estimate either.
This whole scope took little effort. The scope statement, the WBS, and the dictionary were built together in one project management app. And you can use rolling wave planning: add details to a deliverable when the team gets closer to it.
It’s also simple. You don’t need everything the PMBOK® Guide lists. The scope baseline has one job: help your stakeholders understand the project scope the same way you do.
Want help finding the deliverables nobody asked for? The Hidden Deliverable Detective prompt in my free AI Prompt Pack does that for you. You describe your project type, size, and industry, and who takes over after the project ends. AI lists governance, compliance, transition, communication, and technical deliverables, plus the ones no one asks for, each with a rough effort estimate and what happens if you skip it.
If you prefer video, here’s what happens when you get your project scope right:
Project Scope vs. Requirements vs. Objectives
People mix these three up all the time. Let’s clarify the difference.
“Requirement is a condition or capability that is required to be present in a product, service or result to satisfy a contract or other formally imposed specification.” – PMBOK® Guide
“Project Scope is the work performed to deliver a product, service, or result with the specified features and functions.” – PMBOK® Guide
What does that mean?
- The objective is why the project exists. Stock Alpha Bank wants to stay competitive and keep its users.
- A requirement is what the product must look like or be able to do: its features, behavior, performance. “AI suggests tags for every uploaded image.”
- The project scope is the work your team performs to meet those requirements: design, build, test, deploy, train.
There’s one more critical definition:
“Quality is the degree to which a product complies with the requirements.”
Agree on the quality level early. It changes the scope and the timeline a lot.
A zero-defects approach is too expensive for most IT projects. It takes a lot of extra effort and a heavy process. So you agree on an acceptable level of quality, like the 90% tagging accuracy in the example, and you include the effort to reach it in your scope.
How to Write a Project Scope Statement
The Project Scope Statement is a narrative description of the product scope and the project scope.
It’s the written confirmation of what your project will produce and how.
The key to a useful scope statement? Use words every stakeholder understands. The scope statement is mainly for the customer. The WBS is for your team.
Here’s what to include.
1. Justification of the project
A short description of the business need. One sentence is often enough. The rest stays in the project charter.
2. Product scope
A description of the features and functions of the product or service you’ll deliver.
You collected requirements from different stakeholders. Don’t assume each of them keeps track of every requirement. And it’s not always clear how much work a single requirement takes.
This section is where you align expectations. Show the amount and complexity of the work behind each group of requirements, and put most of your effort here.
3. Acceptance criteria
The conditions a deliverable must meet before the customer accepts it.
You can also include the acceptable number and severity of defects.
4. Deliverables
Everything your project will produce: the product or service itself, project documentation, user manuals, training materials, and so on.
5. Project exclusions
What is out of the project scope.
Some stakeholders often want something the customer or other stakeholders don’t support. That’s a conflict. Once you resolve it and the feature leaves the scope, write it here.
Be specific. It saves you time twice.
First, you won’t have to discuss these exclusions again. Stakeholders will try to bring them back during execution. Unless something dramatic changes, point to this section and move on.
Second, if you don’t write it down, someone will still expect you to deliver it. Don’t feed false expectations, and the handoff at the end gets much easier.
6. Constraints
Anything that limits your ability to deliver: a fixed deadline, a budget cap, a vendor dependency, a technology you must use.
7. Assumptions
The uncertainties you can’t clarify yet.
You accept some of them during planning and throughout the project. If an assumption turns out to be false, you have the right to change the project plan.
The customer approves the scope statement. It’s a formal, mutual agreement: you commit to deliver the described result under these assumptions and constraints, and the customer agrees to accept it.
It doesn’t mean you can’t change the project scope. It means that to change the scope, you amend the agreement.
How to Align Project Scope With Project Objectives
Run one test before you send a scope statement for approval. Take each acceptance criterion and ask: “If we meet this, will the customer get the result from the justification?”
In the example, the objective is to stay competitive and keep users. The criteria answer it with user satisfaction with search, AI tagging accuracy, and usability tests. Each one proves part of the objective.
Then ask the opposite question. Is there anything in the product scope that no objective explains? That’s gold plating, or a stakeholder’s pet feature. Ask about it now, while saying no is still cheap.
What if nobody can tell you the real business objective? It happens more often than you think, especially when a client sends you a list of features. The Business Objective Reverse-Engineering prompt in the AI Prompt Pack takes your requirements and suggests 3 to 5 possible objectives. It explains what each one means for scope and success criteria and gives you the questions to find out which one is real.
How to Define Project Scope Step by Step
Before you start defining the project scope, imagine the END of the project.
Ask yourself how you’ll hand off the final delivery to your stakeholders.
Looks easy, doesn’t it?
What if the stakeholders say it’s not what they expected… at all?
A project manager delivers what customers perceive they asked for.
Read it again!
Customers think they explained clearly what you need to do. You think you understood them correctly. That’s almost never the truth.
“The single biggest problem in communication is the illusion that it has taken place.” – George Bernard Shaw
To stay in line with what the customer asked for, you need a process that covers at least these steps. You describe it in your scope management plan.
Step 1: Collect project requirements
By this time, you need an approved project charter that states the project objectives and high-level requirements.
You also need to identify the stakeholders who can expand on those requirements. They may have extra ideas or related experience.
Then you talk to all of them. Here’s an example of requirements gathering on a real software project from the project manager’s side.
On large and complex projects, the project manager shouldn’t collect requirements alone. You need a Business Analyst, who is trained to collect business requirements, describe them, and tie them to the project objectives. A good BA is one of the keys to project success.
Your job during planning is to make sure the BA collects the requirements on time, according to the project timeline.
On bigger projects, I recommend a Requirements Traceability Matrix. It links every requirement to the deliverable that meets it.
Step 2: Turn requirements into project scope
Here’s a requirement from one of my own projects:
“The pmbasics101.com website should have the capability to collect emails and send out a PDF document in return.”
What does it take to meet it? Here’s the list of actions a team would write first:
- Select a mailing service provider.
- Create an account.
- Design the email form.
- Implement the form.
- Install the mailing service plugin.
- Upload the PDF document.
- Activate the form.
- Test the form.
That’s a to-do list. Written as a deliverable with work packages, it looks like this:
| WBS code | Deliverable or work package |
|---|---|
| 1 | Email opt-in form |
| 1.1 | Report on mailing service providers |
| 1.2 | Approved form design |
| 1.3 | Opt-in form on the testing environment |
| 1.4 | Test report |
See the difference? Each work package is a result someone can check and accept, not an activity. That’s what makes a WBS useful for estimates and for change control.
So how do you get from a one-sentence requirement to the actual scope of work? I use three techniques.
A) Find someone with relevant experience
It can be stakeholders, customers, external consultants, or subject matter experts. Bring them onto the team or just book a call. They may already have a solution. If not, they’ll point you in the right direction. You’ll use this technique on every project.
B) Perform product analysis
It works when you build a product rather than a service or a result. You break the product down into its parts and functions, the same way the WBS breaks down the project scope. Then you decide on the components and approaches that meet the performance requirements. The goal is tangible deliverables.
C) Generate alternatives
This works when your team has expertise in the subject. You look for the best way to meet the requirements, usually through brainstorming, and you compare the options.
The goal of all three? Clearly define what is and what is not part of the project scope, and understand the constraints on the work.
AI can save you hours on this step. Two prompts in my free AI Prompt Pack fit this step. Transcripts to Epics reads your project file and your meeting transcripts with the client and lists the Epics for each deliverable, flagging every gap with the exact questions to ask the client. Requirement Conflict Detector cross-checks your raw requirements and flags the ones that contradict each other, like security vs. usability, before they turn into rework in the middle of a sprint.
Step 3: Keep the scope in your project management software
You can keep the project scope in any app: Google Drive, Notion, or MS Word will do.
But an integrated project management tool gives you something documents don’t. You link requirements to deliverables, and deliverables to tasks with estimates, risks, and defects.
You can build a Work Breakdown Structure in any PM software. You don’t need a special tool. For small projects and personal use, I like Paymo. It also has good time tracking and invoicing.
Step 4: Control the project scope
Identifying 100% of the scope at the start isn’t enough. That 100% WILL change during the project. Uncontrolled change is scope creep.
So you need a way to monitor the scope and change it on purpose. The cure every great project manager knows is the Work Breakdown Structure.
You also need a clear workflow for changes, because every change in the amount of work affects the schedule, budget, and risks. That’s the job of an integrated change management process. I cover the day-to-day side in how to control project scope and avoid scope creep.
So what’s the catch? You need a good WBS. And you need a non-nerdy way to describe the scope to the customer. That’s the Project Scope Statement.
On an agile project, a clearly defined scope for each increment matters even more. Agile doesn’t save you from describing the work. Keep your Sprint Backlog and User Stories neat, and apply a simple rule: “A newcomer should understand what needs to be done from the User Story description.”
Step 5: Validate the scope and the deliverables
From time to time, you need a formal sign-off that a deliverable meets stakeholder expectations.
Do it continuously, not once at the end. Even on a plan-driven project, nothing stops you from showing product increments for review.
Why bother? Because you don’t want all the change requests, all the defects, and all the “minor changes” to land at the end of the project.
The closer you get to closure, the less time and money you have left. Stakeholders are less willing to negotiate scope, timeline, or budget. And they put more pressure on your team to get what they need.
That’s why you need a clear, approved project scope from the start.
When a deliverable misses expectations, there will be corrections. It’s your job to prove whether a correction is a change request, which goes through change control, or a defect, which you fix. Sometimes at your own expense.
How do you validate scope with customers in practice? Use a Scrum-like demo meeting on any project. Prepare a short demonstration of the deliverable. Explain the current project status and progress. Point out known defects and work in progress. Then collect the customer’s feedback. You can send supporting documents and reports later, if your policies require them.
Collect feedback from stakeholders continuously. Negotiate how new change requests come in. Keep the scope baseline up to date.
Why the Scope Baseline Matters: The Silent Agreement
“Scope baseline is the approved version of a project scope statement, work breakdown structure (WBS), and its associated WBS dictionary, that can be changed only through formal change control procedure and is used as a basis for comparison.” – PMBOK® Guide
Here’s how most IT projects I’ve seen start.
The requirements come in all forms: emails, PDFs, meetings, mockups, bug reports.
Nobody prepares a project charter. Nobody discusses the business case.
The team does create a Work Breakdown Structure. But it stays internal and never goes to the customer. The team breaks the work into activities and makes a bottom-up estimate.
Then comes the first expectations check: you present the estimate.
The customer doesn’t know what work you estimated. If the number is close to what they expected to spend, they won’t dig into the details. They’re ready to spend that money and time, and they don’t want to waste theirs on your WBS.
Here’s the truth:
A lot of organizations and project managers hide inefficiencies behind such silent agreements.
What happens next? You start execution. Sooner or later, the customer asks for another piece of work. Then your team finds work nobody identified. Then quality problems show up and eat your time.
You hand off the delivery and find out you built something wrong. And that’s when the customer remembers something they forgot, and it has to be added ASAP.
Believe me, you’ll go through this more than once. I did, early in my career, when I ran projects with no process at all.
The fix is simple. Show the customer the scope behind the number: the scope statement, and the top levels of the WBS. A disagreement you find in a planning meeting costs you an hour. The same disagreement found at the handoff can cost you the project.
Looking for a Project Scope Template? Why the File Is the Easy Part
If you came here for a project scope template, I get it. You want something you can fill in today.
But look at the example above. You’ve already seen everything a template would contain: seven headings, a tree, and a table with codes. You can set that up in ten minutes.
The hard part is what goes under the headings. Which requirement hides three weeks of work? Which feature does the sponsor expect without saying so? What will you write under “Exclusions” that a stakeholder will fight you on? A blank template answers none of that.
When I got my PMP, I tried to bring textbook processes to a company that had none. Nobody followed them, and I was back to managing chaos. What worked was just enough process to stay in control, light enough that the team actually follows it. A one-page scope statement your customer reads and signs beats a 30-page template nobody opens.
And today, AI drafts a scope document faster than you can fill in a template, as long as you give it your project’s context. Ask ChatGPT for “a project scope statement” with no context, and you’ll get a generic document that fits nobody’s project.
I put together a free AI Prompt Pack for project managers to fix that: 27 copy-paste prompts for real IT project work. A whole category covers scope and requirements. These three fit this article best:
- Project Context File Builder. AI asks you targeted questions, including your key deliverables and what is in and out of scope, and builds one file you attach to every other prompt. From then on, AI answers about your project instead of a generic one.
- Hidden Deliverable Detective. It lists the deliverables you haven’t thought about yet, in six categories, with effort estimates and the cost of skipping each one.
- Statement of Work (SOW) Scaffolder. It drafts a formal SOW from your charter and notes, with Out of Scope, Acceptance Criteria, and Assumptions sections. It flags every missing boundary and gives you the exact question to ask the client.
Get the free AI Prompt Pack and run the Context File Builder on the project you’re managing now. You’ll write your next scope statement around your real project, not a blank form.
Project Scope FAQ
What is an example of a project scope?
The Stock Alpha Bank upgrade above is one. Its scope covers better search filters, AI image tagging, a new UI, photographer uploads, and a responsive design, and it excludes a mobile app, video content, and translations. You can open the full scope statement, WBS, and WBS dictionary as PDFs.
What does a project scope statement look like?
It’s a short narrative document, often one to three pages, with seven sections: justification, product scope, acceptance criteria, deliverables, exclusions, constraints, and assumptions. It ends with the customer’s approval. The example in this article has all seven.
How long should a scope statement be?
As short as your stakeholders can read in one sitting. For a small or medium IT project, one to three pages is enough. The details belong in the WBS dictionary and the linked tickets, not in the scope statement.
What is a project scope document?
It’s a general name for the documents that describe the project scope. In PMBOK® terms, that’s the scope baseline: the Project Scope Statement, the Work Breakdown Structure, and the WBS Dictionary. Some companies use one document; others split it into these three.
What is the difference between project scope and project objectives?
The objective is why you do the project, like “keep users and stay competitive.” The scope is the work you do to get there. Every acceptance criterion in your scope should prove part of an objective, and anything in the scope that no objective explains is a candidate for removal.
What is the difference between a scope statement and a scope of work?
A scope statement describes the product and project scope for stakeholders, inside your project. A scope of work, or Statement of Work (SOW), is usually part of a contract with a vendor or client. It adds commercial terms like milestones, payments, and resource allocation.
How do you write a project scope?
Start with the objective and the requirements. Break the requirements into deliverables and work packages in a WBS. Then write a short scope statement for the customer with the seven sections above, list the exclusions clearly, and get it approved before you commit to an estimate.
Conclusion on Project Scope
Project scope sits under every other part of your plan. Write a short scope statement your customer understands, back it with a WBS and a WBS dictionary, and check every line against the project objectives. Then keep it up to date through change control and regular demos.
When the scope is clear, your estimates hold, you settle change requests by pointing to a signed page, and the handoff brings no surprises.
Get it right, and your project runs on a system, not on overtime. That’s how you stop managing chaos and start managing projects.
You’ll find the rest of my articles on this topic on the Scope Management page. Read the real example of decomposing a project into tasks next.
Before you write your next scope statement, grab the free AI Prompt Pack and find the hidden deliverables first.