A project scope statement is a document that outlines the project's deliverables. It includes details such as project objectives, the scope of work, the project timeline, and the project budget.
Now, 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.
I'll teach you how to write stellar scope statements in less than 15 minutes, flat. Deal? Deal.
What is Project Scope?
60 seconds on keeping your project on track here:
Why are Scope Statements Important?
The project scope is important because it defines the extent of your work based on how much you are being paid to do it.
Stakeholders and 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 document. Similarly, if they’re paying less, typically, less will be included within the scope.
Project scope statements can be cooked up in various effective ways and are usually a key responsibility of digital project managers or producers.
A bulletproof scope statement 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.
Next, we’ll address some key tips and tricks to ensure you identify the best scope statements for your project and the processes to follow. Additionally, 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 will have 5 solid tips and tricks to make your scope of work statements bulletproof, example statements to re-purpose, and ultimately, confidence in developing this critical work document.
What's Included in a Project Scope Statement?
The scope statement defines what’s in, and what’s out of the project. The scope statements includes:
- 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 definitions of specific project deliverables. However, they can also be used to describe the individual components within a statement of work.
Types of Project Scope Statement
- What the project is, why it’s happening, and the project goal (overview)
- Who has approval (governance)
- How the project will be completed (approach + phases + tasks)
- What will be produced (project 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 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”
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.” 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 handled by your account person (if they exist). It defines all the terms of the relationship and sets up all future engagements. You need this before the SoW comes.
- ICA: Independent Contractor Agreement, an important legal document that DPMs often drive and own when negotiating with freelancers, professional services, or contractors. This doc explains that it’s not a full-time employee for tax purposes.
- SLA: Service-Level Agreement, the legal document that defines the hosting, domain services, and maintenance support commitments between your company and the client.
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 that cover these non-SoW items, I highly encourage you to check out the project templates in our Membership area and customize them how you see fit with legal counsel.
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 deals with all the terrible SoWs that come in through 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 lazy-written scope statement is a project requirement that you cannot afford. Otherwise, it can ruin your chance of project success before it even starts.
Why? Because it defines the grey areas in your project. If you don’t know the ins and outs of your project within the scope of work, you will be brewing tension the whole way and dealing with scope creep.
As a project manager, it’s usually the 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 alignment from clients and internal team members.
5 Tips and Tricks To Define Scope Statements Like a PRO
Let's dive into 5 immediate and actionable things you can do to have a bulletproof project scope document. Oh, and just for fun, I sprinkled in 28 scope statement examples.
1. Start Your Project Scope Statement With the ‘Why’ (an Overview)
This high-level scope statement defines what the project is, why it’s happening, and what it will achieve.
- Keep it short. 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!
Project Scope Statement Overview Examples
Bad Example of Project Scope:
The Digital Project Manager will create a new site for Aston Baby LTD. The site is to be live in 2020 and reflect the company's product offerings for purchase online.
Better Example of Project Scope:
- This SoW aims to align the Client’s website presence with the retail sales growth and business objectives (the “Project”).
- The Digital Project Manager will provide complete website discovery, comprehensive user experience (“UX”), creative redesign and development of the new Aston Baby LTD website.
- The project's primary goal will be to express the brand’s position and personality while enhancing visitor interactions and engagement.
- The Digital Project Manager will work with Aston Baby LTD to expand existing website functionality to include:
- - Ecommerce: Ability for visitors to purchase baby products directly on the website.
- - Expanded support for 3 product sub-categories.
- - Increase branded content presence on the Aston Baby LTD website, including the integration of social, video, photos, videos, etc.
Notice how this better project scope example already defines the project vision that can be used to align the project team and your client. I would circle back to this as you continue to search and ensure you’re providing value to your clients.
2. Define the Approval Process for Deliverables
It’s frustrating when clients don’t provide timely feedback or fail to consolidate all project stakeholder feedback.
Luckily, you can gracefully set expectations upfront in your SoW so that there are no surprises once the first round of reviews starts.
Typically, I include this language under the 'dependencies and assumptions' section. Then, I have a verbal conversation with the client(s) to ensure we have alignment on the expected feedback/approval process.
Approval Process Scope Example
Bad Approval Definition Statement:
(In an out-of-the-blue email to the client after the first round of review) “Any feedback for us?”
Better Approval Definition Statement:
Dependencies & Assumptions:
- All feedback from the client must be in a written and consolidated format and come from the single point of contact, [Name of contact].
- The client must ensure all necessary and appropriate stakeholders are available to participate in necessary creative and technical reviews.
3. Define What Will Be Delivered (Including Timeline + Milestones)
In general, this section will include the juicy details 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 areas. For example, if you’re providing wireframes—are you providing them for the entire desktop and mobile experience? Just tablet? How many templates? How many screens?
Another example involving design would be to validate how much design you’re handling. Does this mean all templates? Or are you designing up to 6 templates?
Are you handling content creation and entry? Are you not? Migrations? Hosting and configuration? Deployment? Will formal QA testing be completed? So many things to talk about.
Bad Project Scope Example:
The Digital Project Manager will provide up to 2 rounds of designs for the website.
Better Project Scope Example:
The Digital Project Manager will design the look and feel of the [Name of client] website through the following deliverables.
D02a. Design Directions (Meeting & InVision)
The Digital Project Manager will create 2 unique Design Directions evidenced through a single page of the [Name of client] website. Each direction will be designed in full for a tablet viewport. The client will choose (1) direction to move forward with.
(1 round of revisions)
D02b. Design Comps (Meeting & InVision)
Based on approved design direction, wireframes, and page tables, The Digital Project Manager will provide design comps for all key pages and modules as required for the [Name of client] website in the tablet viewpoint. This allows for rapid production and snapping of pages to begin in development. Please note that the designs presented in this stage will include lorem-ipsum copy as placeholder copy, representing suggested placement and length. The Digital Project Manager will include for placement only (i.e., FPO) imagery, representing the suggested style/tone/topic of imagery the page/module should contain. As appropriate, The Digital Project Manager will leverage existing imagery from the [Name of client] asset library and include it within design comps.
(Up to 2 rounds of revisions)
If you're clear from the start, you make your life a whole lot easier.
Sure, you may not be able to eliminate revisions entirely (what a world that would be...), but if you make sure everyone knows what's being delivered and when, you can track it passively from your project management software. Goodbye, one million check-ins.
4. Define Inclusions and Exclusions
This is by FAR my favorite part of scope statement writing. Essentially this is where you can dump all the things, the “what ifs” and the “not ever's.”
Here’s a project scope example with some of my favorite statements. Feel free to pick and choose from it. Obviously, curate this list to be unique to your project.
Project Scope Statement Examples
Here are 14 example statements that clarify generic dependencies and assumptions within your scope of project:
- All feedback must be written and consolidated by the Client and come from one point of contact (Name here).
- The Client must ensure all necessary and appropriate stakeholders are available to participate in necessary creative and technical reviews.
- Upon completion of the Discovery Work Session, [Your company] will evaluate objectives & key performance indicators against listed deliverables to ensure project requirements are met. If needed, [Your company] will issue a Change Order to this SoW reflecting the shift in deliverables for the Client’s signature.
- Any structural changes to design once the Development Phase has begun will constitute a scope change to both budget and schedule.
- The [Name of client] online store will leverage an existing third party such as Shopify. GoCart, etc to be mutually determined prior to development kickoff.
- This scope is based upon the understanding that there will be no more than 20-24 unique modules.
- A detailed timeline will be published upon signature to this work order.
- If Client elects to approach this Project with two or more deployments, a Change Order will be issued with additional costs for the additional QA & development staging time required.
- If Client elects to cancel the Project or put the Project on hold for longer than 60 days, Client will pay for work completed to date plus a 10% kill fee on the remainder of the Project scope.
- The client is responsible for all production design
- Agency retains the right to reproduce, publish and display project details in its portfolios and websites, and in galleries, design periodicals, and other media or exhibits for the purposes of recognition of creative excellence or professional advancement, pending written approval by Client.
- Full access to hosting environment(s) and technology platforms including related third-party services such as analytics tools.
- Access to all necessary functional specifications and/or data sources.
- Agency will build the site according to the WGAC 2.0 Level A accessibility guidelines. Although comprehensive audit-compliance is not in-scope, Agency will work alongside the client to ensure that any critical compliance issues are resolved within the approved timeline.
Project Scope Exclusion Examples
If you want to be able to use your resource management software properly (and avoid having a client-induced brain aneurysm in the process), you also need to clarify what you won't do.
Here are 12 sample exclusion statements that clarify out-of-scope items:
- Any deliverables, activities, core functionality, or rounds of revisions beyond what is outlined here will constitute a scope change and subsequent change request to both budget and schedule. This includes development collaboration endeavors if the levels of effort deviate outside the original estimate.
- Support of operating systems and browsers that is not explicitly stated above.
- CMS Training Documentation ([Your company] provides basic training for implementation and key leave-behind document).
- All branding and/or identity work explorations.
- Usability Testing.
- Support, maintenance, tracking and measurement of the live site once it has been deployed.
- Liabilities for third parties and service partners.
- Licensing and hardware costs.
- Photography, music, video production and talent costs.
- Hosting, font & service fees.
- Detailed Digital Style Guide or UI kit.
- Photo asset production and image post-production services (touch up and color correction).
- Product/lifestyle imagery production design.
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 if you need it—and sometimes, I do.
Make yourself a matrix of all formal client reviews and feature links to what was shared that tracks back to the SoW. You can use any spreadsheet software for it.
I usually make one matrix for Discovery, one for Design, and notes from demos during the development of a site.
Go Forth and Write Great Scope Statements
In conclusion, project managers are accountable for ensuring they write thorough and complete scope of work statements. Yes—you are the one fighting the good fight. 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 personal experiences.
Do you have a project scope statement horror story?
Guilty of writing a less-than-perfect scope?
Share it with the DPM family—and stay up to date with fresh resources like this in DPM Membership.