The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner. Please visit their site for more information.
The Scope Document
Once the project scope is defined, it must be documented to ensure that everyone assigned to the project will address the right tasks and work toward the same project goals. A formal scope document is essential to keeping a project on track. The order that these scope items are covered and the amount of space devoted to each in this document will depend on the type and size of the project and the number of scope items that need to be covered. On small projects, needs, goals, objectives, and missions will often be the same thing – easily described in a few statements. Distinguishing between these things is not that important, but establishing a flow from less measurable statements of need to more measurable ones truly is important.
The scope document should be short, succinct, and available to everyone involved with the project. All of the scope information does not have to be in a paper document. A videotape contrasting current operations with the envisioned operational concept may be more effective than a written description in communicating the ‘to-be’ versus ‘as-is’ vision to the project stakeholders. There definitely should be a paper, or electronic scope statement, but things like the aforementioned videotape would provide very informational addendums to the scope document.
Review Scope Regularly
However you document scope, you must review it regularly to remind you of your own focus as well as to bring it up-to-date. As time goes by and your team conducts design studies, the initial scope definition will need revisiting. For example, your team may be unable to meet an objective; the customer may provide a new objective; you may find that you don’t have the budget to meet all of the goals; or new technology may present new possibilities and affect your operational concepts. The revised scope document must be available to everyone on the team to help them stay on the same track.
Another reason, of course, to continually review the scope document is to help you, as the project manager, manage the scope of the project. Issues will arise and customer needs will change necessitating a review of project scope. If it falls outside of the original scope, then change orders should be originated with the customer. Otherwise, the project is constantly in danger of falling out of budget and out of time.
Trace Requirements
Once you have defined the scope of your project, and move on to writing the actual requirements, trace the requirements back to your scope definition. We’ve discussed this previously in the form of the requirements traceability matrix. This trace will help ensure a complete requirement coverage as well as helping to prevent gold-plating…or adding more to the system than specified in the requirements.
Note: This article is based on information obtained from the book "Customer-Centered Products" by Ivy Hooks and Kristin Farry.