So far we've described the high-level components of the project scope document. Now we will go a little bit deeper and discuss some of the minutiae of the document. You will learn how to incorporate all of the background information you' ve gathered—your deliverable strategy, milestone and due dates, estimated funding, project priority rating within the organization, which tools and resources you' l l use, and even who will be available—right into your project scope document.
We cannot forget that the scope document arises out of the assemblage of the project ' s requirements—the requirements function as inputs to the scope. However, with any project, certain key elements will always be required. Of the ten scope elements mentioned above, you will always include the following scope elements in any document you write, regardless of size:
■ Project background
■ Estimated completion date (in some methodologies—others will require a separate project planning set of documents that calculate this date, a process you go through much later in the project)
■ Budget information
■ Project sponsor
You' l l formulate this document with a word processor and store it in the project book (it matters not whether the book is electronic or hard copy). When representing the document in word-processor form, denote each of the elements as a major heading.
You' l l present the scope document to stakeholders, the customer, and the project sponsor to obtain buy-in. A single meeting could be effectively used to discuss the scope document after you ' ve prepared it and are satisfied with its content. The sponsor will review the document and sign off on it—if it' s acceptable. Once the document is finished, it is up to the PM to maintain its congruity. Changes to the document are strictly disallowed without first going through a change-management process (which I talk about in Chapter 5) and being approved anew by the project sponsor.
Change is bad, bad juju for a project. By the time you get the scope document written and signed, everyone on the project should be very clear about what' s going to happen without any additional required changes. Changes implemented later in the project shouldn ' t be happenstance; they should be predicated on real factors you could not have accounted for at the project formulation time. Implementations and modifications that weren ' t in the original, project scope formulation dialog—especially "touchy-feely," "nice-to-have" ones—generally will not be available to you.
Furthermore, changes that don' t fall in line with a project' s requirements are not allowed at all. Recall all of the work you' ve done to build your project ' s scope thus far. At this stage, you will feel as if you' ve gone over mountains and swum through oceans to fully document and refine the requirements and the ensuing scope document, trusting that the sponsors, stakeholders, and customers are all in agreement. Change will not be easily tolerated.
However, unforeseeable changes will occur, and the entire team will have to bend and accommodate them. An example of a necessary change might be that you' ve selected a hardware vendor for a specific part of your project and, halfway through the project, when you ' re ready to go with the new hardware, you find that the company has suddenly gone out of business.
As the PM, you' l l maintain all changes to the scope document and post the information in the agreed-upon ways (intranet, e-mail, etc.) for stakeholders to see.
Was this article helpful?