What is a scope statement?

The scope statement is the defining statement of the project. It is the document that defines the project and is the basis for making decisions about the project. The scope statement is a dynamic document in that in the beginning it contains the information available, and as the project progresses, it is changed and added to. It is the primary document used for understanding the project and its nature. The scope statement includes the goal statement, the project justification, the products that the project will produce, the deliverables, and the success criteria of the project. The scope statement should also include the things that the project will not do. These statements should include exclusions from the project deliverables and any identified constraints and assumptions that have been made.

Tell me more …

The goal statement is a short statement of what this project is about. Goal statements are not strictly required but help to give a short description that people can use to recognize the project where the name of the project would not be sufficient. The goal statement should be written by the project manager but must be approved by the manager above her. Goal statements can also be included in the project charter that was discussed elsewhere. If a goal statement is included in the project charter, there is the danger that the project charter approval and the official start of the project will be delayed while people struggle over the wording of the goal statement. For this reason we think it is a good idea to include it in the early documents of the project like the scope statement rather than in the project charter.

The project manager has some control of the overall direction of the project with the goal statement. For example, a company wanted to develop a computerized system that would control the fire and burglar alarms in a building. The system would automatically call for help if the alarms were breached or if the sensors detected heat, light, or smoke where it should not be.

One project manager wrote a goal statement that said, "The goal of this project is to install a fully operational automated alarm management system in the XYZ Company's facility by January 2004". Another project manager said, "The goal of this project is to make a prototype automated alarm management system that can be brought to the consumer electronics trade show in October 2004".

Notice that the work that has to be done in either of these projects is quite different. The two goal statements indicate completely different ways of introducing the new product. In the first statement the project manager feels that the best approach is to build a complete prototype system that will be a showcase for customers to see. In the second statement the project manager feels that the best approach is to breadboard a model of the system that can be shown to a large number of customers. As these goal statements are reviewed by the stakeholders, they will be refined and the project will move forward.

To show how short goal statements can be, we will give one more example of a short goal statement for a gigantic project. To launch the Apollo Project, then president of the United States John F. Kennedy said, "I believe this nation should commit itself to the goal of sending a man to the moon before the end of the decade and returning him safely to Earth". This statement launched a project that lasted for more than ten years and cost well over $50 billion.

The project deliverables were discussed above. They are the specific items that will be delivered as a result of doing this project. The detail of the deliverables should be such that there will be no disagreement as to whether or not the deliverable was actually delivered. Disagreements with the stakeholders about the description and nature of the deliverables should be settled at this time rather than when the deliverable is actually delivered. The stakeholders need to understand that any item that is not on the list of deliverables will not be delivered.

The project success criteria are the tangible objects by which the project will be judged in order for it to be considered successful. We can consider the success criteria for both product and project. The fundamental success criteria of any project are those related to the items specified in the project management triangle—cost, schedule, and scope—but may include other tangible and specific measures as well. It is important that we are as precise as possible in describing our success criteria according to our performance against budget, schedule, and scope. We need to choose measures that would be easy to verify in order to clearly demonstrate our project success. For instance, using "Being on Schedule" as a criterion is a bad thing to do because it does not give us actual figures to measure. Also, does that mean that being late or early is bad for project success, or is it just being late that is bad? Is it missing a schedule by ten months or by ten hours that is bad?

The product success criteria, unlike the project success criteria, may have to be measured long after our project is over, but it is still important in the long run from the business point of view. In learning how we will manage our projects for the best customer relations development, our overall company development, and our own project portfolio management improvement, product success criteria may and will involve things that are outside of the scope of the project. This criterion must be considered if reaching customer satisfaction is one of the important goals in our projects. Product success criteria must be described with the same precision as project success. Do not say, "We want to increase productivity of our employees by having them attend certain technical skill improving training courses". Instead, say something like, "One of the product success criteria for a training project will be for us to increase the productivity of our software development department 15 percent within the two months after training is completed". We should also have the actual method of measurement in hand to demonstrate the change in productivity.

Just as we need to identify all the stakeholders for our project, we also need to understand how the stakeholders will measure our product and our project success. In many cases, this will give us important insights into how to manage our project better. For example, if we understand that the product success criterion our customer will use in a training project is the ability of IT managers to manage their projects in a unified way, then we need to make sure that our client understands her responsibility to ensure all of the managers' presence in class along with providing other measures to make what was learned applicable to their practical activities. If we understand that the real project success criterion for our client is for us to not overrun our budget by more than 20 percent, we could then be more conservative with the need for taking risks in the project.

The final comment to be made in this section is that there is an important need to keep success criteria from different areas balanced. In measuring project success, we have to make sure that we have thought about schedule success criteria as well as budget and scope. With product success criteria, we have to make sure we did not leave out important stakeholders whose satisfaction will have a large impact on overall project success.