Recall from Chapter 1 that the scope document (also called the scope of work document) defines the project scope—what tasks the project team is expected to accomplish and, just as importantly, what is not part of the project. Depending on the complexity level of the project, the scope document can be as short as one page or as long as several hundred pages. On more technical projects (like the submarine project described in Dr. Gibbons’ video), the scope would include a significant amount of technical specifications (such as focusing on the equipment used to find the submarines). The size and character of the project scope document is related to the project complexity. Higher scores on the Darnall-Preston Complexity Index indicate the need for more detailed scope documents.Image by World Economic Forum
A well-developed project scope statement provides the project team with information the team needs to design and implement the project execution plan. The well-developed project scope also provides the team with an understanding of the purpose of the project and the basis for defining project success.
An automotive company is building a new plant to produce electric passenger cars in the southeast United States. As the plant nears completion, the plant’s manager issues a contract to an instructional design firm to train the new plant workers. The training of workers who will be maintaining the production equipment will be done by the equipment suppliers and will not be in the scope of the training contract.
The scope of work for the training project will include the identification of the knowledge, skills, and abilities needed by each classification of worker and the development of the delivery methods (online, classroom, hands-on) that will effectively and efficiently teach the identified knowledge, skills, and abilities. The scope will also include delivery of the training, evaluation of the workers after training, and the development of training records. Items not included in the project scope are items that will be the responsibility of the automotive company, such as the selection and hiring of the workers and the provision of the automotive tools and equipment needed for training. These exclusions are specifically stated in the scope document.
During the design of the plant, the Human Resources Division of the company explored different workforce models. Experience in other plants indicated that a team-based approach combined with a lean manufacturing philosophy produced the highest productivity. This information was included in the documents provided to the team developing the training project’s scope. The plant manager, the human resources manager, and the plant engineer reviewed and occasionally made changes to the draft training scope.
The scope of work for the training project was developed from a combination of information from experts with previous experience, documents that reflected the plant operation philosophy, and selected managers from operations and human resources. All the knowledge needed to develop the scope was within the automotive project team. Sometimes outside consultants are needed to develop a complete project scope. For example, if the team in our automotive training example did not have experience in the start-up of another automotive plant, then the hiring of a consultant with that experience might have been required to understand the entire scope of activities needed for training the automotive workforce.
The automotive project described above is a typical example of the types of information and the people involved in developing a project scope. From the information in the project description, the project team could develop a project scope document.
The project manager will often develop the first draft of the project scope and then solicit feedback and suggestions from the project team, client, and sometimes key vendors. The project manager will attempt to develop consensus around the project scope, but the final approval belongs to the project client or sponsor. Depending on the complexity profile of the project, the development of the project scope document can be a short discussion between the project manager and the client, or on a large, complex project, the process can take weeks.
The project scope is not a stagnant document, and changes are to be expected. Changes to the project scope are necessary to reflect new information. Changes to the project scope also create the opportunity for new purposes to emerge that will change the end results of the project. In some cases, these new results represent a positive outcome for the chartering organization.
If a minor change is made to the schedule that does not affect the completion date of the project, it is a deviation from the schedule. As long as the end date of the project or major objectives are not delayed, a formal change request to the client is not needed. Recording and communicating these schedule deviations is still important for coordinating resources and maintaining the client’s awareness of the project’s progress.
It is important to have a written record of changes to the scope of a project. On the least complex projects, an e-mail message can be sufficient, but on larger projects a standard form is normally used. The following steps are paraphrased from Tom Mochal,1 and they have the necessary components of a change documentation process:
 Tom Mochal and Jeff Mochal, Lessons in Project Management (Berkeley, CA: Apress, 2003).
CC BY-NC-SA: This work is released under a CC BY-NC-SA license, which means that you are free to do with it as you please as long as you (1) properly attribute it, (2) do not use it for commercial gain, and (3) share any subsequent works under the same or a similar license.