In addition to the Project Charter, another key project management document is the Project Scope Statement. You may wonder why we need a Project Scope Statement since we already have a Scope section of our Project Charter?
Well, the scope section of the Project Charter is very brief and outlines the project scope only at the very highest level possible. The Project Scope Statement allows you to go further and specify the project’s scope completely but still in quite a high level.
In it’s simplest form, the information contained within a Project Scope document will include:
-
- Scope Description: list everything that is within scope, but also for the avoidance of doubt, lists those things that are out of scope.
- Acceptance Criteria: explains how it will be checked that the deliverables are to the right quality standard.
- Project Deliverables: lists the products that will be delivered by the project.
- Constraints: lists any known constraints facing the project.
- Project Assumptions: if we are planning the project based on any assumptions these should be listed here.
Project Scope Statement Example
An example of a simple project scope statement template is shown below. This template contains all the information described above plus some administrative fields.
As you can see an explanation of each element has been provided in the template.
Project Scope Statement Example
However, the easiest way to explain all this is via an example. Let’s return to the same example we used when creating our Project Charter and Business Case. That of a sales team that is struggling to cope with the sheer weight of sales calls they receive. To solve this problem the company has decided to create an interactive voice response (IVR) system to more efficiently handle incoming sales calls. A project scope statement example for this project is shown below:
In this example, you can see that we have very clearly defined what is in scope, as well as explicitly stating what is out of scope. Training for the sales team so that they can use the new system will be provided, but no other teams will be catered for in any way.
Notice that it’s not just the system itself that is a deliverable, but the training manuals are considered deliverables too. For our acceptance criteria, the project can’t be considered delivered until the sales team sign-off that they are happy with it. Because of this, it would be a very good idea to appoint someone from the sales team as our senior user.
Unfortunately, we do not yet have anyone dedicated to the project from the sales team and this is identified as a constraint on the project. You may also want to add this fact as a risk to your risk management process, as because you don’t have a dedicated person assigned from the sales team, there is a risk that the final system won’t adequately meet the needs of the sales team due to their lack of involvement.
The Project Plan
The project plan can’t be created directly from the project scope statement. Remember that the project scope statement simply defines the project scope at the highest possible level in a complete fashion. This means that there is another step before we are in a position to create the project plan and that is to create the work breakdown structure (WBS) for the project.
Once the work breakdown structure has been created the project plan can then be created directly from it.
Summary
The Project Scope Statement is created alongside the Project Charter and used to specify completely, but at the highest possible level, the scope of the project and the acceptance criteria for the deliverables. The document provides much more detail than the Project Charter but is still not enough detail for you to start to plan the project. For that, you will need to create a work breakdown structure.
Feel free to copy the Project Scope Statement template above and adapt it to suit your own projects.
