Definition of Scope and the Effects of Complexity
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
Uses of a Scope Document
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.
Development and Management of a 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.
Deviation versus Change
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.
In our example above, the cost of educational materials for employee training was estimated at fifteen dollars per training packet. The winning bid for the printing contract actually quoted a cost of sixteen dollars per packet. The cost deviated from the estimate and a change was made to the budget. This was a cost deviation, not a change in scope. The additional cost for the materials was covered from the project contingency reserves, and the budget was revised to reflect the changes.
The client hired a new boss who wants something completely different from what was decided upon under the old management. This is an actual change of scope that requires a change request because it changes the budget, the timeline, and the materials needed.
Documenting Changes
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:
- Inform project stakeholders of the change request process.
- Require that the change request is made in writing, including the business value of the change to the project.
- Enter the request into a scope change log, a record that should be kept to track changes (remember – “Document, document, document!”).
- Estimate the time needed to evaluate the change. If the evaluation process is time consuming and would affect activity completion dates by diverting management resources, get approval from the project sponsor to evaluate the change request. If the evaluation is not approved, record the decision in the scope change log.
- Evaluate the change and its impact on the schedule and budget if the evaluation is approved.
- Present the change request to the project sponsor for approval. Record the decision in the scope change log with the recommended course of action.
- Distribute the scope change log periodically to team members so they know what changes are being considered and what happened to those that were not approved or evaluated.
- If the change is approved, update the project charter or other initiation documents.
- Update the work plan.
- Distribute the revised work plan to stakeholders and team members.
[1] Tom Mochal and Jeff Mochal, Lessons in Project Management (Berkeley, CA: Apress, 2003).