Scope is one of the major components of project management planning. The project scope defines the boundaries of the project, that is, what is included and what is not.
Scope is also one of the primary areas of project distress. Project sponsors and executives assume the scope broadly includes everything that is reasonable to produce the deliverables, but project managers want to account for every resource and assume a scope change when there are small overruns. When the parties do not want to confront the issues regarding the project boundaries at the outset, it is a formula for problems.
The PMBOK defines scope as the process of developing a detailed description of the project and product. This process is part of the planning process group, and the result is a project scope statement.
The length of the scope statement has no strict guideline. I believe it should be long enough to limit the risk of scope change as much as possible, to a reasonable limit. Although you can’t define the scope perfectly, when all stakeholders should have a good idea of the project’s boundaries the scope statement is detailed enough.
Scope should be defined to an extent that provides a good indication of when scope creep is happening. Also, consider external processes or system interfaces that are affected by the project, organizational or geographic boundaries, or process workflow between business units.
A good project scope statement contains:
- Scope description
- Acceptance criteria
- Scope exculsions.
The scope statement must include a detailed description of the product, service, or result. This statement is critical to project success and must describe the project in sufficient detail to allow all stakeholders to draw clear boundaries around the project.
The primary work of the project is generally obvious and does not need to be specified in great detail. For example, the scope statement for a subdivision development does not need to spend time outlining the technical details of site grading, sewer installation and road paving. This is the natural tendency, but it is better to focus on the boundaries of the project, such as how far the grading will extend, who will determine the sewer sizes, expected environmental monitoring, and the like. Constraints and assumptions make fantastic parts of a scope statement, because they reduce project risk.
Deliverables include everything the project produces for external consumption, such as interim reports, test results, and design details. They can also include internal products, but the project scope statement should list the items that the project will produce for all stakeholders. Sometimes the deliverables are not known or not well defined at the outset, but the obvious, non-negotiable ones should be specified in the scope statement to make it clear what the project is producing.
The scope statement should identify the criteria for acceptance of the project. Often there is testing required to determine completeness, which can be written into the scope statement, or a completion certificate can be issued. These are integral to the project and if not defined explicitly with the scope, it can lead to problems.
If the organization has a single final authority, it might be prudent to state their name, timeline for acceptance, and other criteria such as site visits, funding sign-offs, etc.
It is a good idea to specifically exclude items that are not part of the project’s scope when they are open to interpretation. In our subdivision development example, final utility hookups might not performed until well after the project is complete, but a landowner who is affected by the utilities might not be aware of this. Thus, specifically excluding items can make the difference between successful and unsuccessful projects, even if it isn’t intuitive when brainstorming the complete project scope.
All projects work within constraints, and stakeholders might not be aware of them. By listing the contraints explicitly, the stakeholders can understand what has been assumed and this can result in a listening ear when problems arise.
For example, a renovation project that will release fumes which might concern the neighbors might plan for a fan and piping system to send the fumes a sufficient distance away. It might be easy to say in the scope statement that the fan will send the fumes away, but if it goes a bit further and describes the constraints, i.e. how far the residences are away, how many windows there are, and how easily the fumes might travel, the stakeholders who read the scope statement might understand if it ever becomes difficult to contain the fumes.
Similar to constraints, the assumptions provide background information that will allow for stakeholders to understand when problems arise. Assumptions often fly under the radar, particularly for experienced professionals.
In our renovation project example, the project manager will have to assume a certain size fan. If the fumes begin to leak out of the building and get to the neighboring properties, problems could result. Stating the assumption that a certain fan size will be sufficient would reduce project risk.
Scope Statements Reduce Risk
Scope statements are essentially excercises in risk reduction. It is important that the boundaries of the project be defined in sufficient detail to reduce the risk of scope changes throughout the project. If it is not possible to define certain areas of the project scope, the uncertainties should be stated and contingencies included in the cost and/or schedule.
How to Write a Scope Statement
The PMBOK identifies four tools and techniques to writing a scope statement:
- Expert Judgment. It is indeed a huge advantage to have resident experts to consult when defining a project scope. Subject matter experts can identify the expected pitfalls and potential issues that can be defined at the project planning stage, and their input is invaluable.
- Product Analysis. Focus on the deliverables. What do they look like? How long/high/wide/strong/capable must they be? What functions will they have, and how must they perform under various conditions?
- Alternatives Generation. Determining alternative products and services can be extremely eye opening. This can identify different approaches to performing the work, which can be instrumental in defining the scope.
- Facilitated Workshops. When you have many grey project boundaries (or worse, conflicting ones), consulting the project stakeholders and putting them together in one room or conference call can be essential to defining the project scope.