I was once part of a project which went behind schedule and over budget. The project manager asked the project team, which included me, to come up with reasons why the project was late. Naturally the team produced several reasons, and a scope change request, along with a new budget was sent to the client. Everything sounded like it was back on track.
This sequence of events happens countless times in every consulting practice, and it has an equivalent with internal projects.
It is also a certain path to poor project performance. The project initiator (sponsor) has a high level vision of what the project entails, for example, to design a web site, or build a building. The project team, however, sees only individual tasks that might not have been included in the scope.
Why Scope is Important
In my business, scope is easily the #1 reason for project distress. I’ve seen many surveys that corroborate this and I’ve seen it firsthand on projects over and over again.
Poorly defined project boundaries, or ones that move throughout a project, can be project and career killers.
That’s why we’ll start with it.
Scope Defines the Project
Project scope is the work which is required to deliver a project. It defines the project’s boundaries and is foundational to the project.
Usually there are budgets and schedules associated with projects. If the scope is vague or subject to change there will be cost and schedule ramifications.
Scope Statement
To avoid the unpleasant possibilities that result from a poorly defined project scope, you should learn to write out 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
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” is not enough. Everyone already knows this – It does not define any boundaries that reduce risk. It would be better to define start and end points, fence height, post depth, fence type, weather assumptions, etc.
I don’t believe there is a maximum length, only that which is feasible to reduce the risk. The length is enough when the time being spent writing 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 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 face certain assumptions as part of their existence. 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 certainly doesn’t hurt in a scope statement.
Uncertainties
You might not know all the project boundaries. In the fence example, you might have agreed to build a fence without establishing the type or height. Although this seems harmless enough, all project uncertainties are risks to become cost or schedule issues. In an ideal world every project is completely defined, but I realize 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 if how big of a fence they would like to build.
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 founded on 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 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.
Today’s Task
Today’s task is to write out a scope statement for the project you chose in the introductory post. Make sure it is thorough and use the checklists I have provided above, because this will define the project to you and all the stakeholders.
- Spend a few minutes thinking about the boundaries of the project from the stakeholder’s point of view.
- Make sure there are as few as possible grey areas.
- It can be in paragraph or point form, and there’s no limit to the length or size.
- Write it in the comments below or post it to our facebook page to give others a great example to work from.
