The project scope statement is a document that defines what the project is, the project deliverables, and the work that the project team (and likely contractors) will have to do in order to create the identified project deliverables. The major purpose of the document is to communicate with the project team, the project customers, and the project stakeholders a common understanding of the project’s purpose, goals, and objectives. The project scope statement, as I’ll dive into one moment, also serves as a launching board for additional planning by the project team and the project manager.
The project scope can be a large document or a simple one or two-page manifesto. So how big does this thing have to be? Here’s a heuristic you can rely on: larger projects typically require more detail than smaller projects. In other words, the bigger the project the longer it’s going to take to create the project scope statement, and the more information you’ll need to include in the document.
Real World Note: I admit I’m painting some large brush strokes here. Most organizations are going to have project scope statements available from past projects – that’s part of your organizational process assets. There’s nothing wrong with using a past project’s documents as templates for your current project – work smart not hard. And if your organization has never, ever completed a scope statement before? You’ll need some additional planning time to create the project scope statement. Don’t be surprised if your project scope statement goes through several rounds of revisions – it should.
So what exactly does a project scope statement include? I’m glad you asked, otherwise this list would be just silly. Here’s all the stuff that a project scope statement should include:
- Project objectives. Objectives are the goals of the project – the measurable, quantifiable goals of the project. Think of time, cost, quality, technical requirements, blueprints, and product acceptance criteria. I stress the word quantifiable – avoid loose terms in your objectives such as fast, good, satisfaction, and other subjective terms. What’s fast to you may be slow to your customer. If you can attach a metric to it you need to.
- Product scope. < Remember the product scope – the vision of what the project will create? The product scope and all of its features and functions are included here.
- Project requirements. Let’s face it, your project will have some requirements. You can identify a project requirement as anything that “must” be met, kept, or deliverabled. The project must not exceed $750,000. The project deliverable must be able to interface with SQL, Oracle, and Access. The project deliverable must be blue. Requirements are often, if not usually, tied to the product scope and the project objectives.
- Project boundaries. These are things that are considered out of project scope. For example, we’ll create and compile the new software for you, but we will not create the CD image and ship the software around the world for you. A project boundary may also identify areas where the project should not overlap with other lines of business or projects. For example and electrician may have a boundary created for him to install the high-voltage wiring, but not the low-voltage wiring – such as network cable and home security systems.
- Project deliverables. Isn’t this obvious? It’s the product that the project will be creating. But wait a minute professor, there’s also ancillary deliverables – the project documentations, the project management plans, the project communications, contracts, and all the other historical information the organization reaps as a result of the project. Bonus!
- Product acceptance criteria. You want it when and it has to do what? Easy enough – it’s the criteria the project manager and the project customer both may use to determine the success of the project.
- Project constraints. A constraint is anything the limits the project manager’s options. You must be done in two years. You must not exceed four million dollars. You must use COBOL. You must use Indiana limestone. Anytime you see the word “must” or “demand” then you know you’re dealing with a project constraint. Technically, all projects have at least three constraints: time, cost, and scope.
- Project assumptions. An assumption is anything that you believe to be true, but you haven’t necessarily proven to be true. For example, in construction an assumption is often made that summer months are better than winter months for building. Or you may assume that the software you’re creating will work just peachy with Windows Vista. Or you assume that all of your project team members are happy to working on your project. As you can imagine, assumptions can become risks.
- Initial project organization.Who’s who in your project. This portion of the project scope statement defines the project manager, the project team, the project customers, and any other project stakeholders. You may also identify the reporting structure in this portion of the project scope statement.
- Initial defined risks. A risk is an uncertain event or condition that may have a negative (or sometimes a positive) effect on the project. I’ll talk a bunch more about risks later in this section. Hold your horses!
- Schedule milestones. A milestone is a non-timed condition or event that shows that the project is making progress. For example, finishing the foundation could be a milestone. Milestones often end a phase of the project and allow the next phase of the project work to begin.
- Fund limitation. Unless you work for some wonderful organization, your project is going to have a funding limitation and a reconciliation process to identify where the monies for the project have gone.
- Cost < span style=”font-family: Arial;”> estimate. Everyone wants to know how much your project will cost. The cost estimate and the supporting detail for that cost estimate is included in the project scope statement. I’ll address the process of creating a cost estimate in just a bit. I promise.
- Project configuration management requirements. Remember the phrase “features and functions” and the product scope? This section of the project scope statement defines the level of control the project manager (and often by proxy the organization) will place over the project change control requirements. Changes to the product scope will result in changes to the project scope.
- Project specifications. This section of the project scope statement identifies any of the specification documents such as regulations, requirements sheets, blueprints, or the like that the project must comply with.
- Approval requirements. Someone, an individual or a committee, must sign off on the project when it’s completed. This section of the project scope statement defines the requirements for the project to be approved.
The project scope statement is a cornerstone of the project. It serves as a guide for all future project decisions, and the project manager and the project team must protect the scope from unapproved changes as the project moves through execution. The project scope statement is the written version of what’s commonly called “the project scope” or just “scope.”
