The Most Common Reasons for Change Requests

Change is inevitable. As a project manager, you will probably encounter many changes as you plan and execute your project. At least some of these changes will affect the project's scope, either increasing it or decreasing it. To better manage and control these kinds of changes, you should know what changes are most often requested.

A change request may be initiated internally or externally. It may be written or verbal, legally mandated or optional.

There are five common reasons for changing the scope of your project.

1. an external event - The first reason for a scope change request is an external event. These are factors outside of your control that impact the scope of the project. External events can be general or project-specific.
   
   A general event, such as a state-wide power failure due to a violent hurricane, does not directly relate to the project, but could force a change request.
   
   A project-specific event could be a change in local zoning regulations that require immediate changes to the project. While this is out of your control, it affects the project.
   
   
2. a "product" scope error - The second reason for a scope change request is a product scope error. This includes any omissions, inaccuracies, or miscalculations relating to the product of the project. Any of these errors could prompt a change request.
   
   Think about a software development project. An example of a product scope error would be the failure to include a required feature in the original design. Without a change request, the final product would be missing a desired feature.
   
   
3. a "project" scope error - A project scope error is the third reason for change requests. A project scope error usually results from an error in estimating or planning the work in the initial phases of the project. This could include anything from underestimating the time it takes to complete each task to not properly defining the work in each phase. Although most project scope errors cause the project to run behind schedule, they can also result in phases or deliverables being completed ahead of schedule.
   
   Using an incomplete WBS for a telecommunications project would prompt a change request due to a project scope error. Since the project manager did not properly define some activities, activities were duplicated, causing schedule and budget problems.
   
   
4. a value-adding change - The fourth reason for changing the scope of your project is a value-adding change. Value-adding changes are caused by factors that cannot be considered when the original scope is defined, but if implemented into the project scope, will improve the project or make it more cost effective. In a software game development project, a value-adding change could be new technology that enables players to play against other competitors online. This situation would require a change request due to a value-adding change.
   
   
5. a contingency plan implementation - The final reason for a change request might occur if you implement a contingency plan to handle a risk on your project. A contingency plan is applied to the identified risks on a project to reduce the cost and impact if the risk does occur. If the risk has a higher impact than anticipated, a change in project scope may be required. Tom, a software engineer, is working on a software development project that will allow a home entertainment system to be activated by both remote control and a human speaking a command. Tom needed to implement a contingency plan—human voice recognition—because the project manager learned a competitor was developing a similar product with voice recognition capabilities. Without this change request, the company risked losing sales to the competitor once the project went to market.

Change requests act as a record of the project's evolution and progressive elaboration. Since change requests explain the reason for change, they help ensure that all stakeholders understand and agree to the proposed change.

Whether changes to your project come in the form of federal laws or an error in judgment, one thing is certain—change will happen. Familiarizing yourself with the most common reasons for changing the project scope will allow you to manage and control these kinds of change requests.

Ensuring that Scope Changes Are Properly Implemented

Do you find it easier to manage a huge task by organizing it into smaller tasks? Project managers manage a huge task—the project—by organizing it into activities using a work breakdown structure (WBS).

The WBS is a framework that defines the scope of the entire project; work not in the WBS is outside the scope of the project. The approved WBS represents all of the work packages and activities that must be completed in order to finish a project.

To effectively control scope change throughout your project, you have to review the approved WBS. By reviewing the approved WBS, you ensure that the change will be properly implemented. At this review stage of the project, you should be looking at the activities and any resulting changes and impacts.

• the activities - The first thing to review is the activity level of the WBS to ensure that all activities resulting from the change have been included so that the corresponding deliverable can be met. A forgotten activity can result in a missed deliverable or non-acceptance by the client, so this is a very important step.

• any resulting changes and impacts - The project manager must also review the WBS to ensure that the resulting changes to the activities and their impacts on the schedule and budget have been considered. The project manager should ask himself if the change to the activities could cause the starting or ending date of the corresponding deliverables or final products to be delayed. He should also determine if the budget will be sufficient. If the answer to either of these questions is yes, the project manager can then use the tools and techniques of scope change control to assess the impact.

Project managers and the project team frequently refer to the WBS throughout the project. The WBS is the key to scope change control because it defines all the work in the project.

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.

A 4-step Approach to Scope Verification

As a project manager, you will need to prepare for a critical inspection of the project work. The inspection of the work results usually occurs at a meeting with project team members and key stakeholders. When conducted properly, this critical inspection verifies that all deliverables and work results are completed according to the project plan.

The project manager is frequently asked to facilitate the inspection meeting. There are four steps for facilitating a scope verification inspection meeting.

1. First, you need to choose the appropriate reviewers who will attend the inspection meeting.
2. Next, revisit project goals so that all of the reviewers are aware of the direction of the project.
3. Then you should review the work results to compare the project's product to the expected deliverables as outlined in the WBS.
4. Finally, you need to decide on appropriate action as a result of the scope verification.
   

Even before the actual inspection meeting begins, the project manager needs to choose appropriate reviewers. In addition to the project manager and at least one project team member, you may want to ask the following people to attend the meeting:

• Subject Matter Expert (SME) - An SME acts as an adviser to the project team when the team needs external expertise. SMEs should attend the inspection meetings to provide the team with the necessary advice and to verify the results of the work.

• Project Sponsor - The project sponsor is the individual or group that provides the financial resources for the project. The project sponsor should attend the inspection when the project is a new or risky venture. It is not necessary to include the project sponsor for projects that are repetitive or recurring.

• Customers - The customer is any individual or organization that will use the project's product. It could be the client or outside consumers. Customers should attend the inspection meeting when their cooperation is essential for the project.

The next step in facilitating a scope verification inspection meeting is to revisit the project goals. The meeting facilitator needs to ensure that all reviewers are aware of the original purpose of the project and of the goal of the inspection meeting.
As the meeting facilitator, you need to explain to the inspection team members that they will compare the actual work results to the planned scope of the project to ensure that project results are acceptable.

Once all of the reviewers are aware of the purpose of the project and the inspection meeting, the inspection team should review the work results and do the following:

• Identify any omissions in the product that were in the original plan.

• Verify whether the omissions, if any, were approved through a scope change.

• Note any oversights in the work results.

• Ensure that all documentation is available.

• Note any exceptions or deviations from the project baseline.

• Note any discrepancies (variances) between the work results and the scope baseline.

• Note any violations of industry or client standards.

After reviewing the work results, the inspection team needs to decide on appropriate action. In a scope verification inspection, there are three actions that you may choose from, depending on the outcome of the meeting.

1. The inspection team can accept the work results if the planned scope and the work results match. There should be no unapproved deviations from the plan when you accept the work results.
   
   
2. The reviewers at the inspection meeting should request minor changes if it won't affect the project budget or schedule. Minor changes could include asking for slight product modifications or for more detailed documentation.
   
   
3. The inspection team should reject the work results if there are obvious and substantial deviations from the planned scope. If the changes required to fix the deviations cause cost overruns or put the project behind schedule, the reviewers should reject the work results.

Before presenting your project to the client for final acceptance, you can use the tools and techniques for scope verification to ensure that the work results are acceptable. Remember to perform a careful and thorough inspection.

What Inputs Will You Need for Project Scope Verification?

Have you ever facilitated a meeting or given a seminar without being fully prepared? If you have, you understand how important preparation is. Preparation is the key to the success of any venture, including project scope verification. It is important to start off well when preparing for scope verification. This means gathering all of the necessary documentation (inputs) in advance of the verification process.

The inputs to scope verification are:

• work result
  
• product documentation
• work breakdown structure (WBS)
• scope statement
• project plan.

The first two inputs to scope verification—work results and product documentation—are directly linked to the work that has been completed on the project.
Work results are tangible or intangible outcomes of the activities performed to complete the project. Product documentation is the paperwork produced that describes the project's product.

The next three inputs to scope verification—the work breakdown structure (WBS), scope statement, and project plan—are all used to compare the product to the original plan.

The WBS contains the entire project scope or all the work that you need to complete in order to deliver the product. It is a hierarchical diagram that allows you to see the project scope at a glance. Since the WBS aids in the definition of the project scope, it should be used to develop and confirm an understanding of the project scope and deliverables.

The first level of the WBS contains the major elements or phases of the project. Many of your projects may look the same at this level if they have common deliverables.

The lower levels of the WBS show the continued breakdown of the phases. Each descending level represents an increasingly detailed description of project deliverables. A complex project will have several levels in the WBS.

In the scope verification process, the scope statement has a similar function to that of the WBS. It provides a documented basis for project decisions.

The scope statement usually has four main sections.

1. Project justification - This section of the scope statement identifies why the project exists. It describes the business need that the project will address. You can use this section of the scope statement to verify that the project's product satisfies the business need it was intended to fulfill.
   
   
2. Project's product - The project's product describes what the project will produce. It is a brief summary of the product's attributes and characteristics. During the scope verification process, you should compare this section of the scope statement to the actual work results of the project.
   
   
3. Project deliverables - The project deliverables is a list that summarizes the subproducts whose satisfactory delivery marks completion of the project. This list should also tell you when the deliverables will be completed. You can use this section of the scope statement to ensure that all project deliverables were produced.
   
   
4. Project objectives - Project objectives are the quantifiable criteria that must be met for the project to be considered successful. This section answers the question of "How do you know that the project is a success?" You should evaluate the degree of success of the project during scope verification.

The last input to scope verification—the project plan—acts as a road map. The project plan shows you how to arrive at the final destination. In scope verification, you use the project plan to ensure the team follows all the necessary steps.

When it comes to ensuring product acceptance and achieving project goals, scope verification is one of a project manager's greatest assets. Understanding the inputs to scope verification will help you to gain the acceptance you need to move forward with the project.