Skip to main content
Managing Scope
How To Write A Project Scope Statement (+ Steps & Examples)

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.

We won’t be addressing how to write a Statement of Work or any of the project estimation that feeds into it because we’ve covered those in other guides already.

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:

  1. What’s being delivered (or in scope)
  2. What’s not being delivered (or out of scope)
  3. Assumptions to clarify the deliverables
  4. 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

  1. What the project is, why it’s happening, and what it will achieve (overview)
  2. Who has approval (governance)
  3. How the project will be completed (approach + phases + tasks)
  4. What will be produced (deliverables)
  5. When it will be delivered (timeline + milestones)
  6. What it will cost (estimate + payment schedule)
  7. 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”

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 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 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!

Project scope statement overview examples

A bad project scope overview: will create a new site for Drake’s Bacon Co. The site is to be live in 2020 and reflect the tasty offerings of the company for purchase online.

A better project scope overview:

  • The objective of this SoW is to align the Client’s website presence with the retail sales growth and business objectives (the “Project”).
  • will provide complete website discovery, comprehensive user experience (“UX”), creative redesign and development of the new Drake’s Bacon Co. Website.
  • The primary goal of the project will be to express the brand’s position and personality while enhancing visitor interactions and engagement.
  • will work with Drake’s Bacon Co. to expand existing website functionality to include:
    • - Ecommerce: Ability for visitors to purchase bacon products directly on the website.
    • - Expanded recipe and food content.
    • - Increase the presence of branded content on Drake’s Bacon Co. website including the integration of social, video, photos, videos, etc.

Notice how this better project scope overview example already defines the project vision that can be used to unite the internal 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. 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.

Project deliverable approval definition scope statement example

A bad project deliverable approval definition scope statement:

(In an out-of-the-blue email to the client after the first round of review) “Any feedback for us?”

A better project deliverable approval definition scope statement:

Dependencies & Assumptions:

  • All feedback must be in a written and consolidated format by Client and come from one point of contact (Name here). 
  • Client to ensure all necessary and appropriate stakeholders are available to participate in necessary creative and technical reviews.

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.

Bad Example:

The will provide up to 2 rounds of designs for the website.

Better Example:

DO2. DESIGN will design the look and feel of the Drake’s Bacon Co website through the following deliverables.

Deliverables of Design are:

D02a. Design Directions (Meeting & InVision) will create 2 unique Design Directions evidenced through a single page of the Drake’s Bacon Co website. Each direction will be designed in full for tablet viewport. The client will choose (1) direction to move forward with.
(1 round of revisions)

D02b. Design Comps (Meeting & InVision)
Based upon approved design direction, wireframes, and page tables, will provide design comps for all key pages and modules as required for the Drake’s Bacon Co 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 place holder copy, representing suggested placement and length. will include for placement only (i.e., FPO) imagery, representing the suggested style/tone/topic of imagery the page/module should contain. As appropriate, will leverage existing imagery from the Drake’s Bacon Co asset library and include within design comps.
(Up to 2 rounds of revisions)

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.

Project Scope Statement Example

Sample Scope Statements To Clarify Generic Dependencies And Assumptions

  • All feedback must be in a written and consolidated format by Client and come from one point of contact (Name here).
  • Client to ensure all necessary and appropriate stakeholders are available to participate in necessary creative and technical reviews.
  • Upon completion of the Discovery Work Session, will evaluate objectives & key performance indicators against listed deliverables to ensure project requirements are met. If needed, 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 Change Order to both budget and schedule.
  • The Drake’s Bacon Co. 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.
  • The Drake’s Bacon Co. website will be restricted to compatibility with the following browsers/devices in desktop, and mobile views. Please note that browser and OS versions, including devices, are subject to change every 6 months. When appropriate, will edit this list and provide it to the Client for prior written approval. will provide an updated list prior to the start of the development phase.
    • - Desktop: Chrome | Latest version, Firefox | Latest version, Safari | Latest version, IE + Edge | Latest version
    • - Mobile: Chrome, Android | Latest version, Chrome, iOS | Latest version, Safari, iOS | Latest version

Project Scope Exclusions Statement Example

Sample Statements To Clarify Out of Scope Items

  • Any deliverables, activities, core functionality, or rounds of revisions beyond what is outlined here will constitute a Change Order 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 is not explicitly stated above
  • CMS Training Documentation ( to provide 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, color correction, etc.)
  • 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 when you need it—and sometimes, I do.

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.

By Robyn Birkedal

I’m Robyn, a Portland, OR based digital project manager. I’ve been in the industry for the past 10 years and have produced a wide swath of digital efforts including websites, product UX/UI, digital experiences, social, and even a national broadcast spot. I hate bitmojis and pickled herring. I love memes and charcuterie. Outside of that, I’m a mom and probably the world’s most lazy crossfitter.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.