What does the detailed project scope statement include?

Of all the documents that get created, reviewed and shared over the life of a project—project plans, timelines, budgets, status reports and issue logs, just to name a few—the project scope statement may be the one that has the greatest influence over the project as a whole.

The scope statement describes the goals, deadlines and relationships that will shape the project from start to finish. Creating an accurate, complete project scope document can dramatically increase your project’s chances of success. By including the elements below in your scope document, you’ll be able to build an effective scope statement and minimize the risk that change orders or other disruptions will blow your budget or your timeline.

Six Items to Include in Your Project Scope Statement

1. The Business Case

Large organizations typically spend a substantial amount of time reviewing and analyzing proposals before giving approval for a project to proceed. The scope statement does not need to repeat the proposal in great detail, but it should include a high-level summary of the business needs that the project is intended to address. This can help place the project in proper context for stakeholders who were not part of the initial approval process.

2. Objectives

Following the description of the business case, the scope statement should clearly define the goals that the project is intended to achieve. While other aspects of the scope statement, including specific deliverables, may change over time, the basic objective of a project is usually not expected to change.

When stakeholders attempt to add objectives or expand the scope after the project has begun, PMs must exercise project scope management, and insist that all changes are made through a formal process.

3. Deliverables

A scope statement should list the products or services that are to be provided at the conclusion of the project, in order to meet the project’s objectives. Deliverables should be described in enough detail to avoid confusion or misinterpretation by stakeholders.

Although deliverables vary from project to project, you’ll likely notice the final list of products or services to be provided will be similar across many of your projects.

4. Acceptance Criteria

If a scope statement lists deliverables but does not define criteria that the deliverables must meet, the result is often problematic. Vendors may feel that they have delivered exactly what the scope statement calls for, while customers may believe that they have received something completely different.

Outlining acceptance criteria that must be met can help ensure that each project activity brings the team closer to its ultimate goal.

5. Exclusions

Just as the scope statement should define the items that must be delivered as part of the project, it should also list any products or services that are not to be included in the project.

Here again, the goal is to prevent confusion or miscommunication, so the list of exclusions should be as detailed as is necessary to define the project boundaries to all stakeholders.

6. Technology

Although not typically included in project scope statements, stakeholders and other members of the team may find an introduction or explanation of technology that’s associated with the project to be helpful.

Whether it’s information about which professional services you’ll use to find talent or which project management software you intend on using, it’s likely that stakeholders will appreciate the transparency and feel more comfortable with the project moving forward.

Increase your business agility with Planview AdaptiveWork’s project management software

Take a Product Tour

Good project scope management is all about visibility. Project management software can make it easier to get the high-level view you need into project progress. To learn more about Planview AdaptiveWork’s award-winning solution, sign up for a live demo today.

I was once part of a project which went behind schedule and over budget.  In response the project manager asked the project team to come up with reasons why the project was late.  Naturally the team produced several reasons, and a change in schedule and budget was approved.  Everything sounded like it was back on track.

This dance happens countless times at project-based organizations as well as with internal projects.

But it’s also a certain path to poor project performance. Scope defines the boundaries of the project, and if it is not actively defined and managed the project will undoubtedly go behind schedule or over budget.

Scope in Project Management

Because a project is defined as a temporary endeavor creating a unique product, service, or result, the project scope is foundational. It defines what work is part of the project and what is not. It establishes what the purpose of the project is, what it will accomplish and how it will accomplish it. Effectively, it defines the project.

Why Scope is Important

The Project Management Institute reports that adversarial scope changes are the single biggest cause of project failure.  Poorly defined project boundaries, or boundaries that move throughout a project, can be project and career killers. This is a common occurrence in almost every industry, thus strong project managers must learn to define, communicate, and control the project scope.

Scope Statement

To avoid the unpleasant possibilities that result from a poorly defined project scope, project managers need to write out good scope statements.  This will make it easy to gain acceptance of the project’s scope by the project’s stakeholders.  It will also put the project team in sync, but most of all it will prevent unauthorized tasks from popping up within the project, thereby sucking up the project’s time and money (the evil “scope creep“).

There really is no substitute to defining the boundaries of the project in writing, so it is clear to everyone what is part of the project and what is not.

How to Write a Scope Statement

During a marathon, runners must pace themselves in order finish at their best time. If they run too slow, they will run a poor race. But if they attempt to outrun the competition they run the risk of burning out and finishing poorly. In the same way, scope statements should contain as much detail as possible, but only to a point.

The most important thing is to be specific.  The more the better.  In a perfect world you could write out a list of all the work that is involved in a project, down to the last nail and screw, and have all stakeholders approve of it.  Unfortunately it’s not a perfect world, so the scope statement has to stop somewhere. However, every well defined project boundary represents a slightly more bulletproof project.

I don’t believe there is a maximum length of a scope statement, only that which is feasible to reduce risk.  The length is enough when the time being spent writing it is no longer reducing a corresponding amount of risk.

A good scope statement includes the following things:

1. Overall description of the work.  This is where you state that the project is to “build a fence.”
2. Deliverables.  What will be produced by the project, and what are its key features?  Also, what client need is the project satisfying?
3. Justification for the project.  In order to provide a complete understanding of the scope, sometimes it is necessary to dive into the justification of why the project was initiated in the first place.
4. Constraints.  If the project faces certain physical boundaries, these can be a source of risk and thus should be defined further.
5. Assumptions.  All projects have assumed certain conditions as part of their existence. For example, the fence building project has assumed good weather, availability of tools, etc. What are those assumptions and what impact does their inaccuracy have on the project?
6. Inclusions/Exclusions.  Many projects have items that are uncertain because projects of that type/size sometimes do and sometimes don’t include those things.  They need to be explicitly included or excluded from the project.

It’s also helpful to borrow from our friends in the corporate strategy department and concentrate on SMART goals:

• Specific.  The more specific the better.
• Measurable.  If you can’t measure it, you have no way of knowing if it was achieved.  Sometimes the best criteria is qualitative, but use quantitative descriptions whenever possible.
• Achievable.  It’s surprisingly easy to commit to something you don’t have the expertise to complete.
• Relevant.  The scope should focus on completing the goals of the client/owner, and avoid tasks that do not add value.
• Time Bound.  A project is by definition temporary and thus has a time limit.  I would consider this optional but it certainly doesn’t hurt in a scope statement.

Uncertainties

You probably don’t know all the project boundaries when you’re writing the scope statement. For example, in the fence building project you might not know how high the fence is to be. This is okay, but just like the marathon runner who must avoid the temptation to be in the lead during the race, the project manager must be aware of the risk involved in excluding this information from the scope statement.  The project manager must realize that all project uncertainties are risks to become cost or schedule issues. In an ideal world every project is completely defined, but this is an ideal that is not always possible nor necessary.  That being said, uncertainties can be dealt with in several ways:

1. Accept.  The project takes on the risk of the uncertainty.  For example, if the owner requires a bigger fence than anticipated, you must swallow the cost.
2. Transfer.  Let a third party assume the risk.  For example, approach the other neighbor to see if they will chip in over and above a certain cost.
3. Mitigate.  Perform actions that will reduce the risk of the uncertainty.  For example, ask the owner how big of a fence they would like to build.

When uncertainties are not defined in the scope statement they can be good candidates for inclusion into the project risk register.

Examples of Scope Statements

Here are a few examples of what I would consider good scope statements:

• This project involves building a fence between the house at 10 ABC Boulevard and 12 ABC Boulevard.  The fence will consist of steel posts within concrete-filled holes.  The fence will be built out of cedar and it will be 8 feet tall.  This is anticipated to keep the dog at 10 ABC Boulevard contained within the yard at a reasonable cost.  The fence will be located as close to the property line as possible and reach from the garage on the west side to the house on the north side.
• This project is for the creation of a construction safety app for cell phones.  There will be an app for iPhones and Android based systems.  The user interface will be designed as part of the project but will contain, as a minimum, the ability to create and edit tailgate meetings, field level hazard assessments, safety inspections, and audits.  Each of these will have a built-in checklist for typical projects in typical industries.  There will be a corresponding web application whereby anyone using the app can log in to view and print the reports.  The app must include a tutorial to make it easy to get started.

Write a Scope Statement

If you haven’t already, try writing a scope statement using the following checklist:

1. List the project’s stakeholders.
2. Write down, in point form, the boundaries of the project from each project stakeholder’s point of view.
3. Note the biggest risks to the successful completion of the project.
4. Write out the primary objective of the project.
5. Write out the important boundaries of the project as well as the most important risks.

Steps 4 and 5 are the scope statement!  Let me know how it goes, or if you have any other insight, in the comments below.