What Goes into a Good Project Scope Document?

There’s a long list of things that can make a project go sideways, and a poorly defined scope
document (or even lack thereof) is surely at the top of that list. 

Maybe you don’t know what a scope is, and that’s okay. In fact, not all organizations require
scopes for projects, so crafting project scope documents might not be a common practice for
you. 

But if you’re interested in setting project expectations and keeping your projects on a
manageable and trackable timeline, a scope can help.

What is a project scope document?

A project scope document—sometimes called a scope of work (SOW)—is a critical piece of

project paperwork that gets teams and stakeholders aligned on the boundaries of a project
before it even begins. 

A well-crafted scope document can save you from major headaches by defining the
following project elements: 
 Project goals
 Requirements
 Major deliverables
 Key milestones
 Assumptions
 Constrains

These critical scope aspects enable you to say more when new requests arise as you’re
trying to deliver a project on time and under budget. 

In the end, a well-documented scope statement gets everyone—team and stakeholders alike
—aligned around these important details that can make or break a project.

How to write a scope of work document

There’s no doubt that a lot of thought, discussion, and sometimes even debate goes into
finalizing a solid scope. But all that work is worth it because having a well-considered scope
document can increase your chances of leading a project to successful completion. 
There are lots of different ways to craft a scope statement. Let’s take a closer look at some
of the details that go into a solid project SOW. 

What’s included in the scope of a project?

Here’s a list of possible elements you should consider adding to your scope statement.

Business case and goals

Every project has goals, and this is where you’ll define them. This section typically includes
the reasons the project is being supported (or funded), along with a set of business goals or
intended project outcomes for your team to keep in mind while executing the project. 
These details are critical to document because there will be times when stakeholder (and
sometimes even team) requests creep in and put your timeline and budget at risk. But you
can push those risks away if change request don’t meet the documented business case. 

Project description and deliverables

This one is simple: a plain language overview of the project’s deliverables. Avoid confusion
by clearly outlining what will be delivered for approval through the course of the project, as
well as the final deliverable. 

Acceptance criteria
Your scope should help you come to an agreement on what will be delivered and leave no
question when the project is complete. Acceptance criteria can be measured, achieved, and
used to prove that work is complete. 

Limitations
Every project has its limits, and you need to be sure you’re not exceeding those limits to
complete a project on time and under budget. 

Limitations can come in many forms, but one example would be technology. For instance, if
you’re building an application that depends on a specific technology, be sure to mention
that. There may be several ways to code that website, but if you’re boxed into a complicated
technology, you can cover yourself by specifying those limitations in your scope. 

Doing so will help you when you run into a limitation and don’t have the time or budget to
explore alternatives. Think of it as an insurance policy for your project.

Assumptions
You know what they say about assumptions, and you probably know it’s true. If you don’t
outline them, you’ll end up with confusion, missed expectations, and project problems. So
take time to list out all the assumptions you’ve thought about that will affect the work you’ll
do or the outcomes of that work. 

Exclusions
You’ve already listed out the deliverables you will provide, but sometimes it’s just as
important to itemize what you will NOT deliver. This helps you avoid awkward “But weren’t
you going to…” questions or requests. Really, it’s about setting expectations and avoiding
any miscommunication around the work you have planned. 

Costs
This is an optional portion of your project SOW, depending on the type of organization you
work in. 

If you’re part of a consulting agency that charges external clients for your work, you’ll want
to outline project costs, possibly even on the phase or milestone level. 
You have to do what feels right for your project and organization. But the clearer you can be
about costs and the work associated with it, the easier it will be for you to manage it—and
make a case for more funds when additional scope creeps in.

Agreement
Scope documents create agreement by nature, but sometimes you need proof! So include a
signature field in your scope document and have your lead stakeholder or project funder
sign the document. 

Scope document example

A considerable amount of work goes into the creation of a scope document, but, remember,
there’s no single right or wrong way to write one. 

Tailor your scope document to your needs to get agreement on what will be produced. Just
be as detailed as possible to ensure your projects finish on time and under budget with a
happy team and stakeholders. 

PROJECT NO. DATE SUBMITTED

123456-78 MM/DD/YYYY

PROJECT OBJECTIVES

Describe the high-level goals of the project and how they relate to overall business objectives. Include
measurable success criteria. Cost, scheduling, and quality targets should list an absolute or relative
value.

Step 1. Project Deliverables

DELIVERAB
DESCRIPTION
LE NO.
1 List all project deliverables and briefly describe each. Do not list dates.
Deliverables should include outputs and ancillary results: PM reports,
2
documentation, etc.
3 The level of detail will be dependent upon the project objectives.

Step 2. List of Project Tasks

List all project tasks to be completed, based on the deliverables listed in the previous section. Do not
list dates. Add more rows as necessary.
Alternatively, you can attach your work breakdown structure (WBS) to the scope statement.
Work breakdown structure (WBS)
NO X YES
attached
Provide link, if applicable. N/A

FOR
DELIVERABLE
TASK NO. DESCRIPTION
NO. …
ENTER TASK #
1 Planning

2 Execution 1

3 Evaluation 1, 2

Step 3. Out of Scope

This project will
NOT accomplish List deliverables or tasks that you will not complete or provide as outputs of this
or include the project.
following:

Step 4. Project Assumptions

NO. ASSUMPTION

1 List any project factors that you consider to be true, real, or certain.

2 Assumptions generally involve a certain degree of risk.

3 Describe the potential impact of assumptions should they prove to be false.

Step 5. Project Constraints

PROJECT START DATE MM/DD/YYYY
LAUNCH / GO-LIVE
MM/DD/YYYY
DATE
PROJECT END DATE MM/DD/YYYY
LIST ANY HARD
DEADLINE(S)

LIST OTHER DATES /

DESCRIPTIONS OF KEY
MILESTONES

BUDGET Enter information about project budget limitations (total project budget,
CONSTRAINTS maximum budget for key project deliverables).

QUALITY OR
Enter any other requirements for the functionality, performance, or quality
PERFORMANCE
CONSTRAINTS of the project.

EQUIPMENT /
Enter any constraints regarding equipment or people that will impact the
PERSONNEL
CONSTRAINTS project.
REGULATORY
CONSTRAINTS
Enter any legal, policy, or other regulatory constraints.

Step 6. Updated Estimates

Estimate the hours required to
complete the project.
Enter total # of hours

Step 7. Approvals
DATE
DATE
STAKEHOLDER NAME ROLE OF STAKEHOLDER / SUBMITTED
APPROVAL
& TITLE APPROVER FOR
RECEIVED
APPROVAL