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.
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.
The minimum length of a scope statement is that which reduces the primary risks to the project. For example, stating that your project is to “build a fence” will communicate the basic information, but it is not enough. Everyone already knows this information – there is no value. It would be better to define start and end points, fence height, post depth, fence type, weather assumptions, etc. which could serve to reduce the risk of adverse changes in scope later on.
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:
- Overall description of the work. This is where you state that the project is to “build a fence.”
- Deliverables. What will be produced by the project, and what are its key features? Also, what client need is the project satisfying?
- 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.
- Constraints. If the project faces certain physical boundaries, these can be a source of risk and thus should be defined further.
- 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?
- 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.
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:
- 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.
- 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.
- 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:
- List the project’s stakeholders.
- Write down, in point form, the boundaries of the project from each project stakeholder’s point of view.
- Note the biggest risks to the successful completion of the project.
- Write out the primary objective of the project.
- 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.