Another key element of a project scope document is the requirements section. In this section you specify some very definite items: a negotiated set of measurable customer wants and needs, that is, user requirements, system requirements, operational requirements, contract requirements, test requirements, and so forth.
Start with the differentiation between mandatory requirements and optional ones. While the idea of "optional requirements" might be oxymoronic to you at first, what you ' re trying to determine are the "nice to haves," things that might take too much development time and effort given the deadline of the project, versus those things that are absolutely essential. For example, suppose that your project is developing software that will be used by orthopedic surgeons to help them perform more exact knee surgeries through robotic cable mechanisms that are inserted in the knee. A mandatory requirement is that the software always provides a method whereby the doctor can take over control of the surgery at any point. A "nice to have" might be that the surgeon can use the software to precisely measure the length of cartilage that is involved in the surgical removal process. Tip A way to incorporate "nice to haves" is through the deliverable revision strategy, where you revise and upgrade deliverables in a second project but don't attempt it in the first.
Also include success criteria upon which people can measure the outcome of their project. This involves a dialog between you and the stakeholders that answers the question, "How can we measure, after the project is completed, how well the deliverables work—thus measuring, at least in part, the success of the project?"
Additionally, state the completion criteria. Ask, "What signals that the project is finished, whether successful or unsuccessful?" You may decide to not call a project complete until several months have elapsed after go-live. Just because a project has gone live does not mean it' s fully functional; minor alterations may be needed to make a deliverable more functional. So it' s reasonable to stipulate that the completion criteria are evaluated several weeks or months after deployment. Completion criteria might, optionally, simply state that a project is complete when x happens—whatever that outcome may be. However, it is important to stipulate clearly what x is, so that when it happens, it ' s recognizable by all and signals the end of the project. Completion criteria differs from success criteria in that the former signals the end of the project (or activity within a project) but the latter denotes the successfulness of a given activity.
Finally, in the requirements section, list aspects that are purposely excluded from the project. Some "requirements" fit the "A Miracle Happens Here" scenario from earlier in this chapter—wishful thinking. Others simply aren' t feasible within the budgetary or resource constraints. It' s often wise to note some things that the project does not require and communicate them to stakeholders so that no one ' s surprised when you declare the project complete.
Was this article helpful?