How to Develop a Project Scope Statement (+What to Include)

Grace Pinegar
Grace Pinegar  |  October 3, 2018

Modern dating is a minefield of missteps and confusion.

In a new relationship, it’s difficult to know what the other person really wants. Are they looking for something long-term, or just dating around to pass the time?

Is marriage on their mind? Will they like my dog? How will their mother feel about someone (me) who can’t cook?

I’m getting ahead of myself. My point is, I wish we could have all of that information up-front, in a binder that details who we are and what we’re hoping to get out of our time with another person.

Unfortunately, humans don’t work that way. We’re complex, nuanced, and don’t always say what we’re really feeling, even when given the opportunity to speak openly. We have to figure each other out slowly, on a trial and error basis.

However, with project management, and particularly a project scope statement, it is a different story. (Oh, did you think I wasn’t going anywhere with this?)

If you’re unfamiliar with the term project scope statement, let me break it down for you.

The term “scope” describes the extent of the area or subject material that something deals with or relates to. Synonyms of scope are: extend, breadth, range, or width.

So essentially, a project scope statement has to answer the question of how far-reaching a project is. What are its deliverables? What does that project aim to accomplish? What are the boundaries of said project?

You see? It’s everything we wish we could answer about people before becoming overly-involved.

But because people are unpredictable and appear without deliverables or due dates (unless of course, you’re talking about an actual due date, which is a whole different article), we’ll focus this article on what can be explained: project scope statements.

What is a project scope statement?

As we mentioned earlier, a project scope statement is sort of the “about me” of your project. It answers a couple of key questions prior to the start of a project, ensuring all members begin working to meet their goals with clarity and cohesion.

More specifically, a project scope statement is documentation that outlines a project’s reach and what deliverables it aims to accomplish. This statement also outlines blockers, or any constraints that might impede a team’s immediate success.

With reach, comes boundaries. A project scope statement should communicate the boundaries or blockers surrounding that particular project as well.

A project scope statement is essentially an all-inclusive introduction to what a project will be. It outlines not only deliverables but the criteria for acceptance, as well as project objectives, among other things.

Why write a project scope statement?

If you’re a project manager, you understand the importance of documentation. Every possible aspect of your project is written down. This includes, but is not limited to, the due dates, cost and budget concerns, names and roles of key players, workflow information, etc.

A project scope statement is another vital part of project documentation. It is also a vital piece of insurance. This documentation proves that both parties were well aware of the agreements before work began. In the event of a disagreement, parties can point to the project scope statement to prove that which they agreed upon before work even began.

Writing a project scope is another way to ensure your project stays within its means and is completed in the allotted amount of time. In other words, a scope statement keeps you under budget and under time.

That explains why it’s so important for team leads, project managers, and other stakeholders to sit down and hash out the project scope statement before beginning work on the project. As with most professional initiatives, it’s important for those in leadership roles to agree on the parameters beforehand.

Project scope statements get employees on the same page. By agreeing on deliverables and boundaries, you’re able to split up with the same end-goals in mind.

You know how a football team huddles and decides on a play before the start of that down? Well if every player left that huddle with their own idea of what play they were going to do, there really wouldn’t be a chance at success. Having team members run in opposite directions — on or off the field — is counter-productive and a waste of time.

So managers all agree on a project’s scope, and a project manager documents the results.

Projects typically fail for a number of reasons:

  • A lack of support from executive members of management
  • Poor planning and foresight
  • Unclear communication of requirements
  • A lack of end-user involvement or input

Writing a proper project scope statement can have a decent impact in combating these project ailments.

However, this must be said: While project scope statements help keep project managers to their promised deliverables as much as possible, they can fail to intercept scope creep. Scope creep has the unfortunate potential to impact any project, even with the most well-intentioned project manager. On the bright side, scope statements are a handy resource to bring everyone back to the same page. 

How to write a project scope statement

You know why a project scope statement is important, but how are you supposed to write one? I’ve compiled a list of elements and information that should be included in every quality project scope statement.

Before we begin talking about those elements, let’s go over a few quick writing tips:

  • The statement should be written prior to beginning the project. This is done so that all parties are starting the project with a unified mindset and a clear understanding of expectations.
  • It’s important a project scope statement not go on any longer than it has to. Practice brevity when writing a scope statement so as to respect the time of all involved.
  • It’s possible your project’s scope will change over time. This is an especially reasonable idea for teams which operate off of SCRUM or agile project management methodologies. When the theme of the team is flexibility, changes are bound to happen. For that reason, it may not behoove your team to write out an extremely detailed scope statement. More flexible teams might benefit more from writing their project scope as an outline or rough draft of what the project’s deliverables and boundaries should look like.
  • Keep in mind that by using a mind map or other type of flexible planning strategy, you might be compromising some of the most important aspects of a project: remaining under budget and hitting a certain due date. If these elements are non-negotiables, forego the mind map and make sure your project scope statement is tight.

Elements of a Project Scope Statement

The following elements should be included in every project scope statement:

  • Project Reasoning or Justification: This portion answers the question of what business problem your project hopes to solve. For what reason are you taking on a project of this scope?

    This doesn’t have to be an incredibly in-depth explanation, as there’s ample opportunity to do that in further documentation. But it should, again, be agreed upon by members of the management team so everyone begins the project on the same page.

  • Product Scope Description: After justifying the need for this project, you’ll write a description of the results you’re hoping to accomplish. This description will cover the products, services, goods, etc that this project will generate.

  • Conditions of Acceptance: This part of a project scope statement protects you from receiving work that is not up to par with your expectations. By writing out your conditions of acceptance, you’re creating a sort of rubric for the project by which to judge its deliverables.

    This clause is especially important if you’re working with an external vendor. Say a graphic designer returns their work and it’s nothing like what you had originally discussed. You can return to this aspect of the project scope statement to clarify why the work they turned in is out of alignment with your predetermined standards.

  • Deliverables: We’ve talked a lot about deliverables already. They’re the whole reason for a project scope statement in the first place. Explaining the deliverables of a project outlines exactly what result you’re aiming to achieve within the project. Is there a certain product you’re creating? A certain ROI you’re hoping to see within a marketing campaign? A certain increase in sales? Include those here.

    Deliverables are also referred to as your objective. This part of the scope statement should be clear as day. As with your conditions of acceptance, there should be no confusion as to what the specific deliverables of your project are. If a project ends and one party feels as though the other party did not “deliver,” they can revisit this section and discuss exactly where the other party fell short.

  • Exclusions: Exclusions are opposite deliverables in that it outlines the results your project is not aiming to produce. This is another strategy that helps clarify any confusion and decrease the likelihood of miscommunication.

    For example, say you’re a graphic designer who has been hired to create a new logo for a restaurant. In the “exclusions” clause, you may clarify that, while you are in charge of creating the designs, you are not responsible for printing the designs onto materials such as menus, t-shirts, and brochures. By communicating this, the restaurant is able to understand their responsibility in finding a third- party company to print supplies.

    You, as a designer, are also able to protect your reputation by side-stepping what could have been a major issue. Communicating exclusions is a precautionary step that should further outline the boundaries of your responsibilities. Because all parties agree upon a project scope statement prior to starting the project, you as the designer would be protected from having to do more work than was agreed upon.
  • Boundaries: This is your place to include blockers, or anything else that might limit your performance throughout the duration of a project. For example, is there legal red tape that might block you from completing a certain project within the pre-approved deadline? This could be true of, say, a construction project. Being that construction managers often need permits or other types of permission to move forward with their builds, that may need to be listed in a project scope statement.

    What kind of boundaries might appear throughout the duration of your project? This applies to timeline constraints, budget restrictions, and even restrictions against the methods you can use to accomplish your goal. Predicting these boundaries and constraints ahead of time gives both parties an idea of what kinds of issues may come up throughout a project’s life cycle.

    By predicting issues, you can preemptively brainstorm solutions. Additionally, tensions tend to run lower when both parties are aware of what issues may arise in advance.

  • Assumptions: Assumptions relate to boundaries in that they are the preemptive solutions to problems that have not yet arisen. When you include assumptions in your project scope statement, you’re taking the potential constraints that may pop up and planning what methods you’ll take to solve them.

    The assumptions part of a project scope statement is your way of responding to the forecast you’ve already predicted. If you think you might have issues remaining under budget, then in this section, you’d include a few places you could cut corners to save a few dollars.

    If you think you’ll run into legal issues, then the assumptions paragraph would outline the ways you intend to remain productive as a team while sorting out your permissions and licenses. 
  • Technology: Not every project scope statement has to include this, but many find it helpful for a team to outline the various technology and/or software-as-a-service (SaaS) solutions they plan to employ throughout the duration of a project.

    This section is mainly for stakeholders, or anyone else who may have a vested interest in the project. In order for others to understand how you intend to keep to a certain timeline or budget, it may help to further explain the solutions or services you intend to deploy. 

Scoping out new territory

Now that you know just what goes into a project scope statement, you should be ready to begin some projects of your own. 

If you’re a project manager, or you’re looking to take on a few challenges at work, you’re well aware that there’s a lot of work that goes into manning the project. Sometimes it seems like the project is only part of the challenge, and it’s the work surrounding it that really sucks up your time and energy.

Luckily, you’re in a good era and age to be in charge of a project. There are plenty of project management software out there to help you manage time and delegate tasks. There are also plenty of service companies in existence to help you hire the necessary personnel, should you need contract or freelance employees.

Regardless of the route you take, remember that communication and documentation are two required keys to the success of any project. So long as you go forward with these necessities, you should be on the right track to delighting with your deliverables.

For more on productivity and project management, be sure to check out our time management guide to help you become a better, more efficient employee. Additionally, read up on effective time management strategies

Grace Pinegar
Author

Grace Pinegar

Grace Pinegar is a lifelong storyteller with an extensive background in various forms such as acting, journalism, improv, research, and now content marketing. She was raised in Texas, educated in Missouri, and has come to tolerate, if not enjoy, the opposition of Chicago's seasons.