This book is licensed under a Creative Commons by-nc-sa 3.0 license. See the license for more details, but that basically means you can share this book as long as you credit the author (but see below), don't make money from it, and do make it available to everyone else under the same terms.
This content was accessible as of December 29, 2012, and it was downloaded then by Andy Schmitz in an effort to preserve the availability of this book.
Normally, the author and publisher would be credited here. However, the publisher has asked for the customary Creative Commons attribution to the original publisher, authors, title, and book URI to be removed. Additionally, per the publisher's request, their name has been removed in some passages. More information is available on this project's attribution page.
For more information on the source of this book, or why it is available for free, please see the project's home page. You can browse or download additional books there. To download a .zip file containing this book to use offline, simply click here.
The project scope identifies the total work of the project.
The scope documentWritten description of what activities are included in the project and some of those that are specifically not included. defines 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, such as a project to design an offshore wind-turbine farm, the scope would include a significant amount of technical specifications, with a focus on the electrical output from the wind turbines. 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.
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 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 methodology that will effectively and efficiently develop the identified knowledge, skills, and abilities (online, classroom, hands-on). 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. The plant will be a typical assembly operation working three shifts. 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.
The labor cost was estimated at fifteen dollars per hour for cleaning the project office once per week. The winning bid for the contract was at sixteen dollars per hour. 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 contract was covered from the project contingency reserves, and the budget was revised to reflect the changes.
Installation of a fence around the project site was delayed when the truck delivering the fence was wrecked on the way to the job site. The fence project was delayed by one week and the delay did not affect any other activity on the project. This deviation from the original schedule did not cause a delay in the project, and the schedule was adjusted as a deviation to the schedule—not a change request.
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 by Tom Mochal,Tom Mochal and Jeff Mochal, Lessons in Project Management (Berkeley, CA: Apress, 2003). and they have the necessary components of a change documentation process:
Changes to the original scope of work must be documented.
© 2010 Jupiterimages Corporation
Internalize your learning experience by preparing to discuss the following.
Describe a situation where the elements of the project scope did not specifically exclude an activity that caused a misunderstanding.