Project Product Descriptions and Scope Statements

The product description document, which is an important input to project quality planning, does just what you would expect—it describes the product. Specifically, it describes the product characteristics a project will create. It contains technical information as well as other issues that affect quality planning.

At the beginning of a project, the product description document will be vague. However, as the project evolves and the product characteristics become more complicated, more details will be added to the product description. Some points to keep in mind about the product description documents are listed below.

• When a supplier does work under contract for a client, the initial product description is provided by the client.
• The product description needs enough detail to support project planning in later stages.
• The product description should state the relationship between the product or service and the business need, opportunity, or problem that initiated the project.

Throughout the project, the product description document will be modified to add the details that were unknown when the project first began. This process assists with the development of the quality outputs.

Parts of the product description may be included in the scope statement, which is another important input to quality planning. Scope statements include information on project deliverables and objectives. Specifically, a scope statement is a description of what the stakeholders want. Details about the scope statement are provided below.

• The scope statement is a written source for making decisions later on in the project.
• The scope statement confirms that the stakeholders all have the same expectations of the project.
• The scope statement is a written source for making decisions later on in the project.
• The scope statement confirms that the stakeholders all have the same expectations of the project.

Just like the product description, the scope statement may need to be revised as the project changes. A scope statement should refer to, or include a description of, the project justification, project product, project deliverables, and project objectives. These four elements of the scope statement are described below.

• Project justification. The project justification can be taken directly from the product description document. It states the business need that initiated the project.
• Project product. This is the actual product description. This portion of the scope statement can be taken from the product description document.
• Project deliverables. The project is considered complete when all the products that make up the project are delivered. If you discover that something has been excluded, you should immediately add it to the scope statement.
• Project objectives. These are the criteria that mark the success of a project. Project objectives detail costs, schedules, and quality measures.

A clear product description and scope statement confirm that everyone involved in a project has the same expectations. You have to know what your customers really want. Your project's success depends on it.

The Components of a Project Scope Statement

Project scope is defined in a document called a scope statement. The scope statement directs and focuses the project and provides a documented basis for making future project decisions. A scope statement promotes efficient decision making and planning by ensuring that stakeholders have a common understanding of the project.

The scope statement combines various components, four of which are essential to resource planning: justification, objectives, product description, and deliverables.

• Justification
  The first component of the scope statement necessary to resource planning is the project justification. Project justification is the need that the project was undertaken to address.
  
  The project justification also provides the basis for evaluating trade-offs. Trade-offs are made between the cost of a project and the benefit of completing it. Unforeseen future issues may have a negative effect on this cost-benefit analysis, and new decisions will have to be made.
  

• Objectives
  Project objectives are the second component of a scope statement. To be of value, project objectives must be quantifiable, that is, they should have a numerical value associated with them (dates, percentages, financial figures, etc). This will enable you to determine when those objectives have been met.
  
  At the very least, your project scope statement should include measurable cost, schedule, and quality objectives.
  

• Product description
  Another component of the scope statement necessary to resource planning is a description of product of the project.
  
  The scope statement should include a summary of the product description that includes the features of the product or service and the relationship between the product or service and the need that gave rise to it.
  

• Deliverables
  The last component of the project scope necessary to resource planning are the deliverables. The deliverables are subproducts whose delivery marks the completion of the project. The subproducts are important because they must be completed fully and to the client's satisfaction before the project is considered finished.
  

Every project needs a scope statement which includes the project justification, objectives, product description, and deliverables. Furthermore, every stakeholder should have a copy of this important document to ensure that everyone involved in the project has a common understanding of the project's scope. This common point of reference is essential as the project progresses and the scope is revised and updated.

The Inputs to Project Activity Definition

When a project reaches the activity definition phase, certain documents or documentable items have already been established. These "inputs to activity definition" include the Work Breakdown Schedule (WBS), scope statement, historical informaiton, constraints, assumptions, and expert judgment.

• Work Breakdown Schedule (WBS)
  One of the principle inputs to activity definition is the WBS. This document defines project tasks and deliverables.
  

• scope statement
  The scope statement refers directly to project justification, project objectives, project deliverables, and project product description.
  

• historical information
  Historical information is another important input to activity definition. Consider activities required on previous, similar projects in defining current project activities. After all, if something works, why not repeat it?
  

• constraints
  Constraints are also an input to project activity definition. A constraint is anything that can limit the project management team's options.
  

• assumptions
  Assumptions are the fourth input to activity definition. For planning purposes, assumptions are factors that are considered to be true. Over the course of the project, these factors may turn out to be true or false.
  
  Assumptions always carry a degree of risk. For example, if assumptions about materials or costs are false, a project may be delayed or exceed its budget.
  

• expert judgment
  The final input to activity definition is expert judgment. Expert judgment is advice from people with specialized knowledge or training that directly relates to your project. Some sources of expert judgment are:
  

experienced employees in the organization
outside consultants
professional associations
industry watch groups.

The inputs to activity definition are an important part of any project. These documents and documentable items help the project manager and team to determine project deliverables and the tools and techniques needed to achieve the deliverables.

What is the Final Output of Project Scope Verification?

Someone once said that "Happiness can exist only in acceptance." Although the statement wasn't referring to project management, project managers are certainly happy when the client accepts the project work results.

The final result or output from the scope verification process is formal acceptance. Formal acceptance happens when the client or sponsor of a project accepts and acknowledges the project phase or major deliverable of the project. Formal acceptance is usually in the form of written documentation.

Formal acceptance may be conditional or complete.

• Conditional acceptance is usually offered when minor adjustments are necessary. Conditional acceptance is dependent on correcting the work results that don't match the project scope.

• Complete acceptance occurs when the work results of the project match the scope plan and client expectations. The project requires no changes.

Whether formal acceptance is conditional or complete, you should gather the documentation that reflects the formal acceptance of each phase or deliverable. This documentation includes:

• The scope statement
  The first component of the formal acceptance documentation is the scope statement. The scope statement is an output from the scope planning process. It is important to include this document because it outlines what the project was supposed to do.
  
  The scope statement typically has four sections: project justification, a description of the project's product, project deliverables, and project objectives.
  
  Project justification describes the business need that the project was undertaken to address. It provides the basis for evaluating future trade-offs within the project.
  
  The description of the project's product is a brief summary of the final outcome of the project. It should present all major aspects of the final product.
  
  Project deliverables are usually presented in a list of phases whose satisfactory delivery mark the project completion. For example, major deliverables for a computer software project may include a working computer code, a user manual, and a tutorial.
  
  Project objectives are the quantifiable criteria that determine if the project is successful. They must include at least cost, schedule, and quality measures. Unquantifiable objectives, such as customer satisfaction, involve a great deal of risk.
  

• A description of the work results
  The second component of the formal acceptance documentation is a description of the work results. This section outlines exactly what was presented for formal acceptance. It describes what the project produced. The description of the work results will most likely be the largest part of the documentation. This section should include both tangible and intangible items.
  
  Tangible work results include deliverables such as buildings, roads, computer software programs, or new products. Intangible items are deliverables such as people who are effectively able to apply new training.
  

• The details of inspection procedures
  The third component of the formal acceptance documentation includes the details of the inspection procedures. The documentation should explain what you have done to ensure that the project's product meets the original scope. As a PM, you need to provide verification that the project has been properly assessed. In this section of the formal acceptance documentation, include information from the inspection meeting, such as who attended the meeting, what areas were inspected, and the outcome of the meeting.
  

• The product acceptance form
  The final component of the formal acceptance documentation is the product acceptance form. This is usually a one-page document that acknowledges the client has signed off the phase or deliverable and accepted the work results. This form should bear the signatures of the project manager and the client.
  

After gathering the inputs to scope verification, completing the scope verification inspection meeting, and gaining formal acceptance by the client, you need only gather the necessary formal acceptance documentation to complete the process of project scope verification and work results acceptance.

Updating the Project Scope Statement

Heraclitus, the ancient Greek philosopher, once said, "Nothing endures but change." Changes to the elements that make up a project's environment will inevitably occur. Oftentimes, these changes are related to the project scope.

When changes take place that either increase or decrease the project scope, you will have to decide whether or not to update the project scope statement.

How do you know if you should update the project's scope statement to account for changes in a project's environment? You will need to analyze most changes to a project environment in order to determine if they warrant an amendment to the project's scope statement.

An update to the project's scope statement is essential if the change will result in an addition, deletion, or modification to the end product or service specified in the project objective. There are five common sources of change in a project environment.

1. Project specification change
Project specification changes are the most common source of change in a project environment. These types of changes reflect additional capabilities or features that were not included in the original scope specifications, but are considered crucial enough by the client to be included. Because they are at the client's request, project specification changes always require an update to the scope statement.

2. Design change
Design changes occur when a member of the project team identifies a better way to produce or provide the end product or service. Unlike specification changes, design changes do not result in a new feature or capability. They simply offer a way to enhance the product or service.

A design change is implemented only if the entire project team agrees that it will improve the end product or service. If an agreement is reached among the project team members, the design change is submitted for client review. Only upon client approval is the design change updated in the project scope statement.

3. Technological change
Technological changes are another source of change in a project's environment. These changes occur when new types of technology in equipment, material, communication, or expertise become available.

Technological changes are always reflected by advances in technology. These changes have to be updated in the scope statement if the new technology will be implemented in the project. They also require the client's approval.

4. Business cycle change
Business cycle changes occur when circumstances within the business industry change. Announcements by competitors and extreme changes in exchange rates are two sources of business change. These changes need to be updated in the scope statement only if the change has a direct impact on the project's delivery dates.

5. Personnel change
Personnel changes occur when key people involved in the project leave or are added to the project team. As a project progresses, the lead designer may leave, the project manager may be moved to another project, or a key expert may be added to the project.

When these changes occur, the project schedule may be affected. These changes need to be updated in the scope statement only if the person is a direct member of the project team whose presence or absence will have an impact on one of the project's deliverable dates.

Project environments can endure change. Knowing how to identify and analyze the sources of change will help you to update your project scope statement accurately and appropriately.

Components of the Project Scope Statement

Matt, an experienced project manager, is ready to begin scope definition, but he wants his key project team members to have a common vision for defining the scope of the project. How can he ensure they're all starting on the same page?

As an input, the scope statement must contain certain components to define the scope of the project. Although these components may vary somewhat from project-to-project and from client-to-client, the scope statement must contain at least the following four components.

1. Project justification
The project justification is used during scope definition to help team members understand the business need that the project must meet. Since it is important for the project manager to ensure that the scope of the project meets that need, project justification can be used to provide the basis for evaluating future trade-offs.

2. Product description
The product description is used during scope definition to help team members understand the defining characteristics of the product or service to ensure that the scope will meet the client's expectations.

3. Project deliverables
The project deliverables are used during scope definition to present a summary-level list of the project activities whose delivery marks the completion of the project. Project managers must understand what is involved in each activity so they can break activities down into smaller, more manageable components.

4. Project objectives
The project objectives are used in scope definition to provide quantifiable objectives that must be met for the project to be considered successful. At a minimum, the project should meet cost, schedule, and quality measures.

Never underestimate the importance of scope statements when defining the project scope. If you clearly define the scope up-front, your project will progress as smoothly and as efficiently as possible.