Let’s get real—this is an article on how to write a project scope statement. You’re probably not reading this for fun, or by pure chance. It’s okay.
You like control. You like boundaries. You know constraints for the project are important. You’re here because you’re in the business of protecting yourself from misunderstandings with project stakeholders and participants later in the project. Maybe you’ve started work on a plan, or the WBS (work breakdown structure) but you’re nervous. You’re looking for alignment with stakeholders, to make sure everyone’s clear about what’s going to be delivered. You’re the facilitator for project success.
But you’ve probably discovered this key fact by now:
It’s easy to write a bad scope statement.
(And it’s hard to write a good one!)
So right now, you’re trying to write a good project scope statement and stumbled upon this article in attempts to find some clarity.
If you want to write a good scope statement, I’ve got you. Read on.
What is project scope?
Project scope is simply a way to describe the work you’re agreeing to deliver. It describes the constraints or limitations of the project.
Why are Scope Statements important?
This means project scope is important to understand and get right, because based on how much you’re being paid to do that work, the extent of (the scope of) that work will differ.
Stakeholders or clients want to know what they’re paying for. Projects, by their very nature have constraints. Stakeholders want to know the boundaries of the project, the process that will be followed, the participants, and how the WBS (work breakdown structure) translates into actual work delivered, and the deliverables.
If the client or stakeholder pays more, then more will be included within the scope, and if they’re paying less, typically, less will be included within the scope.
Project scope statements can be cooked up in a variety of effective ways and are usually a key responsibility of digital project managers or producers.
A bulletproof scope statement not only saves your bacon but can save your business’ bacon. It can be your saving grace if things go off the rails.
Let me edit that.
Your scope statements will be your saving grace WHEN things go off the rails.
In this article, we’ll address some key tips and tricks to ensure you identify the best scope statements for your project, the processes to follow, and we’ll furnish you with loads of project scope statement examples for you to use in your project.
By the end of this article, you’ll have 5 solid tips and tricks to make your scope of work statements bulletproof, example statements to re-purpose, and ultimately, you’ll be proud and confident of this critical legal document.
What Is A Project Scope Statement?
A project scope statement defines the work to be done, and the parameters of that work.
The scope statement defines what’s in, and what’s out of the project. The scope statements define:
- What’s being delivered (or in scope)
- What’s not being delivered (or out of scope)
- Assumptions to clarify the deliverables
- Clarifications needed for any of the above
Project scope statements are usually found within a Statement of Work (SoW) but can also exist independently to provide detail for an estimate.
Scope statements typically provide definition to specific deliverables, but can also be used to describe the individual components with a statement of work.
Types of Project Scope Statement
- What the project is, why it’s happening, and what it will achieve (overview)
- Who has approval (governance)
- How the project will be completed (approach + phases + tasks)
- What will be produced (deliverables)
- When it will be delivered (timeline + milestones)
- What it will cost (estimate + payment schedule)
- What is and isn’t included (assumptions)
If you’d like more on Statements of Work and how to write them well, I’d suggest this complete guide on How To Write a Statement of Work. The guide provides an overview for developing not just scope statements, but the entire statement of work.
Other Names For Scope Statements
There are a few of the other names people use to talk about the scope statements that are usually found in a statement of work. They’re all slightly different, but whether they’re 5 or 50 pages, all of these documents generally do the same thing: define the parameters of the project.
Documents That Are Not The Same As “Scope Of Work”
And here are some related documents that are NOT equivalent to our scope statements —typically the other legal documents you complete before, after, or while landing your SoW:
- NDA: Nondisclosure Agreement, the contract that both parties sign before you start talking “shop”. Likely you’re familiar with this already and you’ve signed a few in your day. If you don’t have one in place right now I don’t want to know… go fix that :)
- MSA: Master Service Agreement, usually a really long and dry legal document mainly shepherded by your account person (if they exist). It’s a super important document that defines all the terms of the relationships and sets up all future engagements. You need this before the SoW comes.
- ICA: Independent Contractor Agreement, important legal document that digital project managers often drive and own when negotiating agreements with freelancers, professional services, or contractors. This doc explains that it’s not a full time employee for tax purposes, which saves your butt when they do things like fail to deliver or show up on time.
- SLA: Service-Level Agreement, the legal document that defines your hosting, domain services, and maintenance support commitments between your company and the client. Client demanding you at all hours of the day? Put an SLA in place ASAP and create some legal boundaries!
NOTE: None of the above are intended as professional legal advice, and I’m not qualified to give any kind of legal counsel. If you do not have templates in the house already that cover these non SoW items, I highly encourage you to check out the project templates in our Membership area and customize how you see fit with legal counsel.
Expert Tip: It’s a best practice that you champion and set a precedent that clients (and outsourced freelancers/contractors etc) always sign YOUR documents (NDA, MSA, ICA, SLA, SoW, etc) and not the other way around. This avoids headaches from your legal counsel and usually speeds up the process on both sides.
Why Well-Written Scope Statements Matter
Not to get weird and heavy, but these statements, and the documents they live in, can make or break a lawsuit.
It can make or break a client relationship—or your job.
I have a legal counsel friend who has to deal with all the terrible SoWs that come in the door. Here are their SoW words of wisdom:
A vaguely worded scope can, at best, lead to scope creep and, at worst, lead to withheld payment, accusations of breach of contract, and legal proceedings. With clear and precise terms identifying deliverables and timing, the risk to a project’s success and happiness of a client is reduced.
In other words—A half-assed scope statement can ruin your chance of project success before it even starts.
On the less extreme side, scope statements determine what is and isn’t out of scope.
It defines the “grey matter” and rules out assumptions and items that will be considered out of scope. If you don’t know the ins and out of your project within the scope of work—you’re going to be brewing up tension the whole way and dealing with scope creep.
To be brutally honest, from a project management perspective it’s usually part of my job that is the most involved, least appreciated, most critiqued—but ultimately most rewarding. I feel like I get to own the project scope statement and seek out alignment from clients and internal team members.
Ultimately after all of the suffering, you’ll have something you’re both in legal agreement on.
The Top 5 Things You Can Do To Save Your Bacon In A Project Scope Statement
Now that I’ve rambled on verbosely about the importance of scope statements —let’s dive into 5 immediate and actionable things you can do to save your bacon.
We’re going to use examples based upon a fake company named…
Drake’s Bacon Co.
Very um…crispy…. Let’s dive in.
1. Project scope statement to define: The project’s ‘Why’ (an overview)
This is a high-level scope statement that defines what the project is, why it’s happening, and what it will achieve.
- Keep it short and concise. You’ve sold the project—now we’re just teeing up the details.
- Add in any KPIs accountable within this agreement.
I suggest having your account manager or salesperson write this part if they are in the picture. #delegate!
2. Project scope statement to define: The approval process for deliverables
It’s frustrating when clients don’t provide timely feedback or fail to consolidate all stakeholder feedback. We all usually have a few stories about this type of scenario and understand and it’s the nature of our work.
Luckily, you can gracefully set expectations upfront in your SoW so that there are no surprises once the first round of review starts cranking out.
Typically, I include this language under Dependencies and Assumptions and then have a verbal conversation with the client(s) to ensure we have alignment on the expected feedback/approval process.
3. Project scope statement to define: What will be delivered (including timeline + milestones)
In general, this will be the “meat” of your SoW. It lists exactly what people are getting when they’re getting it, and how they’re getting it.
My recommendation here is to do your best to avoid ambiguity and grey area. This means for UX, if you’re providing wireframes—are you providing wires for the entire desktop and mobile experience? Just tablet? How many templates? How many screens?
Another example involving design would be to validate in fact that you’re handling design. Does this mean all templates? Or are you designing up to 6 templates?
Are you handling content creation and entry? Are you not? Migration? Hosting and configuration? Deployment? Will formal QA testing be completed? So many things to talk about.
4. Project scope statements to define: What Is And Isn’t Included
This is by FAR my favorite part of scope statement writing. Essentially this is where you can dump all the things, the “what if’s” and the “not ever”.
Here’s a project scope example with some of my favorite language I dumped below you can pick and pull from that you can reference. Obviously curate this list to be unique to your own project.
5. Make a Scope Statement Matrix
This is where PMs will differ in style. Some will say this is overkill, which it certainly is. But it’s there when you need it—and sometimes, I do.
Here’s an example of what I do:
Approved UX Link
Design R1 Date
Round 1 Links
Round 2 Links
Round 3 Links
Documented Feedback Location
Documented Feedback Location
Documented Feedback Location
Make yourself a matrix in a spreadsheet of all formal client reviews and feature links to what was shared that tracks back to the SoW.
I usually make one matrix each for Discovery, Design, and notes from demos during the development of a site.
Go Forth And Write Great Scope Statements
In conclusion, project managers are accountable to ensure they write thorough and complete scope of work statements. Yes—you are the one fighting the good fight. Yes SoWs can be a painful initial start to any project—but a necessary evil to ensure a smooth project and mitigate risk. I hope you find these tips helpful—and if there are any others you’d like to suggest—let’s hear ‘em!
Beyond that—I’d love to chat more about your own personal experiences.
Do you have a project scope statement horror story?
Guilty of writing a less than perfect scope ?
Come clean and share it with your DPM fam—and stay up to date with fresh resources like this in DPM Membership.