Processing Project Change Requests

Imagine that your project has just encountered a risk. You have implemented a workaround to control the risk, but the cost of the workaround will affect the project budget. What should you do to ensure that this change is incorporated into the project plan?

When the members of the project team determine that changes must be made to compensate for controlling risks, they issue a project change request. Project change requests are used to recommend changes in project scope, budget, schedule, or quality. There are various types of change requests including oral or written, direct or indirect, externally or internally initiated, and legally mandated or optional.

Regardless of the type of project change being requested, either the person requesting the change or a project team member will have to fill out a project change request form. The form should include the project name, client name, who requested the change, a description of the requested change, the reason for the change, the impact of the change, and whether it is accepted or rejected.

Project change requests are processed using integrated change control. Integrated change control is concerned with maintaining the project scope and the project's integrated performance baseline. Its ultimate goal is to accept or reject project change requests.

Integrated change control is achieved in a series of five steps.

• Step 1: Submit the change request.
  The process is initiated by the submission of a project change request. The person requesting the change, or a project team member, should fill out the project change request form.
  
  
• Step 2: Record the request in the project change request log.
  Once the project manager receives the change request, he records it in the project change request log. This log keeps track of change request submissions and the status of those requests.
  
  
• Step 3: Assess the impact of the proposed change.
  One or more of the project team members must assess the impact that the proposed change will have on the project as a whole. Project changes may affect many project areas, such as the scope, budget, schedule, quality, and objectives.
  
  
• Step 4: Make recommendations whether to accept, reject, or modify the request.
  The people who were in charge of the assessment will make recommendations about whether to accept, reject, or modify the change request. They will base these recommendations on the validity of the request and its impact on the project.
  
  
• Step 5: Decide whether to accept or reject the request.
  The project authority will use the recommendations to decide whether to accept or reject the project change request. Rejected requests will be closed and filed. Accepted requests will be incorporated into the project plan.

Project change requests are processed through the integrated change control process. This process leads your company to make informed decisions on whether or not change requests should be incorporated into the project plan.

Managing Additional Risks and Scope Changes

Since you never know when a situation will arise that will cause you to reevaluate your project risks, you should prepare for unanticipated situations by knowing what to do when they occur.

There are two ways to recognize new risks. The first is identifying additional risks during project management processes. The second is identifying new risks caused by changes to the project scope. Your initial risk management plan and risk response plan will not account for these new risks, which is why additional risks and scope changes are important inputs to the risk monitoring and control process.

As the project team members go through their normal project management processes like weekly meetings or status reporting, they may identify additional risks. You must add these additional risks to the risk log. The risks listed in the risk log are inputs to the risk monitoring and control process.

Once a project scope change has been approved, the change log becomes the input. The project team will then review the approved changes to see if any new risks emerged as a result of the scope change.

To identify priorities and triggers and to plan responses, you must input the information about additional risks and the approved scope change into the cycle of risk management processes. There are six main risk processes.

1. risk management planning
2. risk identification
3. qualitative risk analysis
4. quantitative risk analysis
5. risk response planning
6. risk monitoring and control

As you implement the six processes, you will find that often the information from one process is needed to drive the next process. For example, you must complete risk management planning before risk identification can occur.

Risk management planning addresses how the additional risks and scope changes will be approached in regards to risk management. Depending on the magnitude of the risk or scope change, it may or may not affect how you conduct risk management for the project as a whole. For example, a new risk or scope change may be important enough that the budget for risk management of the project is increased.

A project team should consider any changes that may need to be made to the risk management plan before moving on to risk identification.

Risk identification determines which risks are most likely to affect the project. The project team will examine scope changes to identify any new risks that may threaten the project. The team will then take these new risks, or the additional risks that were already identified, and document their details and characteristics. From this point on, new risks will refer to both additional risks and risks identified from scope changes.

After examining the risk management plan and identifying new risks, the next logical step is to find out the potential impact of each risk and how likely it is that each new risk will occur. To do this, you must implement the next two risk management processes: qualitative and quantitative risk analysis.

Qualitative risk analysis assesses the potential impact of new risks and determines the likelihood that each will occur. Qualitative risk analysis prioritizes the new risks based on their potential impact on project objectives. This helps determine which risks are most likely to threaten the project.

Quantitative risk analysis is a numerical analysis that determines the probability that the new risk will occur. It also explores the consequences that the new risk will have on project objectives and on the project as a whole.

The first four processes direct the project team to the risks that are most likely to threaten the project. Risk response planning is the process where specific actions are planned in response to these new, threatening project risks. During this process, project managers assign individuals or groups ownership of particular risks. Common risk responses include avoidance, transference, mitigation, and acceptance.

Risk management planning and risk response planning will help you monitor and control risks effectively. The risk management plan and the risk response plan provide the details that a project team needs to carry out the risk monitoring and control process.

By inputting additional risks and scope changes into the cycle of the risk management process, you will be able to identify priorities and triggers and plan responses. This will help you monitor and control your project effectively.

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.

Revising Project Cost Estimates and Budgets

Projects need to have parameters. It only makes sense that there should be a set duration of time in which to produce what the customer has asked for, and a limited amount of money to spend doing it. But what if early measurements of cost efficiency reveal that you are going to have trouble remaining within the cost and budget boundaries?

Revising cost estimates and making updates to the overall budget through the course of the project as more information becomes available is a part of the project cost control process. Preliminary estimates that were set during the planning stages of the project may need to be revised for the following reasons.

• Real costs for certain resources have changed.
• The original estimates contained errors.
• There has been a change in the project or product scope.
• Vague estimates can now be refined.

Cost revisions are justified when it becomes apparent that cost variances to date are not due to isolated causes. A poor rating of cost performance to date may show that your total costs at completion are going to be outside the permitted range. The sooner you can bring variances into line, the better. Revising cost estimates can result in the following benefits.

• Revised cost estimates ought to be much more accurate.
• You will have more confidence in the estimated costs at completion.
• You will know better if the project will come in on budget.

Cost revisions that lead to a change to the budget must be approved as outlined in the project's cost change control system. The person making the change should indicate in the change request the reason for the proposed revisions and await final approval before making any changes.

To revise cost estimates, you simply go back to your original estimates, isolate the specific items that are causing the variance, and then update the estimates based on the more accurate information.

Not all revisions to cost estimates will necessarily lead to updates to the budget. Offsetting revisions to cost categories may not affect the overall budget for a certain time frame or task. Budget updates involve a change to the approved cost baseline and should only be done under certain circumstances.

A change to the budget is considered to be one of the "last resorts" of project cost control. Cost variances should be assessed to see if there is any other way to correct them before re-baselining the entire project.

When you have determined that revised estimates will lead to a budget update, you must follow the approval process laid out in your cost change control system. Any changes to the product or project scope must be analyzed to see how they will affect overall costs. You will want to consult the project's scope management plan and integrated change control system as well. Additional details are provided below.

• Cost management plan (CMP). If your CMP states that the project budget will have a 25 percent contingency on top of the original estimate, a 5 percent variance might be easy to accept. If there is no contingency, or the variance is more significant, you would update the budget.
• Product scope. Changes to the features and functions of the product or service you are delivering, whether imposed or optional, will likely affect costs. You need to determine if the changes in cost are great enough to warrant altering the budget.
• Project scope. Changes to the work that must be done in order to deliver the specified product or service, whether imposed or optional, may also affect costs. You need to determine if the budget should be altered to compensate for these prospective variances.

Remember, cost estimates and budgets need to be updated so that at any point in time the project plan continues to be a valid tool for predicting the future of the project. By keeping in mind the information discussed above, you'll know when and how to revise cost estimates and update budgets.

Supporting Detail for Cost Estimates

A civil engineer will tell you that the supports that uphold a bridge and keep it in place are as important as the structure itself. For project cost estimates, the same holds true. Your estimates must be accompanied by supporting detail, which is an output of project cost estimating.

Any additional information that accompanies a cost estimate provides supporting detail. You did not establish your cost estimates in a vacuum. Supporting detail provides context for your estimates, and should include the following documentation.

1. A description of the scope of the work estimated
Every project file should contain a description of the scope of the work performed. You could include the project's entire work breakdown structure (WBS), or simply a written description of the work for which you have estimated costs.

This information will be useful in the future if you want to use the cost estimates in another project. Use project or product scope statements to assess the similarity between projects when you want to use analogous estimating.

2. A description of how the estimates were developed
You also should record how the cost estimates were developed. Which of the estimating techniques did you use? Perhaps you used one method for a particular phase or task of the project and a different method for another phase.

If the estimates prove to be off, you may want to revisit the process you went through in developing them to check for problems in your methodology. Provided below are examples of supporting detail you may want to provide when using specific estimating techniques.

• Analogous estimating. You'll want to know exactly which former project or projects were used as a basis for establishing cost estimates for the current project. Record how costs were established for aspects of the project that differ from the others.
• Parametric modeling. List all of the activities or resources for which you used a mathematical formula in estimating costs. If any resource rates change drastically during the project, this list will enable you to quickly pinpoint the estimates affected and make the necessary revisions.
• Bottom-up estimating. If you estimate project costs "from scratch," or from the bottom up, hold on to notes about the sources you used. This would include names, phone numbers, prices, and other information that would form an audit trail.

3. Any assumptions that were made about costs
Assumptions are factors that, for planning purposes, are considered to be true. Keep a record of assumptions that you or team members make during cost estimating in case they turn out to be false. You make assumptions about such things as resource rates, resource availability, and activity durations.
False assumptions usually cause cost variances because your actual costs will deviate from the planned costs. Hold on to the assumptions upon which estimates are based in case you have to account for discrepancies later on.

4. The range of possible results
The supporting detail for a cost estimate also should include an indication of the range of possible results for each resource, activity, or task. For example, an estimate of $10,000 plus or minus $1,000 indicates that an item is expected to cost between $9,000 and $11,000. The relative size of the range indicates whether it is a rough estimate or if it is accurate enough to be considered a finalized estimate (that is, with an accuracy of plus or minus five percent).

There are two other ways to express the accuracy of an estimate besides "plus or minus" a certain dollar figure. Sometimes you see the accuracy range for an estimate given as a percentage. Other times, estimates are tagged with a range that shows the probability that actual costs will under- or overrun the estimate.

• If you had an estimate of $1,000 plus or minus 15 percent, the range for the estimate would be plus or minus 15 percent of $1,000, or plus or minus $150. You are estimating that actual costs will fall between $850 and $1,150.
• When you express an estimate as $1,000 -10 percent, +25 percent, you are saying there is a 10 percent chance the estimate will be less than $1,000, and a 25 percent chance of it being more than $1,000. This risk factor is considered during the cost budgeting stage.

The amount and type of supporting detail varies by project application area. Keeping even rough notes may prove to be valuable by providing a better understanding of how the cost estimates were developed.

The Analogous Estimating Technique

One of the most common methods of estimating project costs enables you to take advantage of the similarities between a current project and projects that have been performed in the past. This technique is called analogous estimating.

An analogy is a set of comparisons you draw between two things with similar characteristics. Analogous estimating is also known as "top-down" estimating because you apply the total costs from a previous project in order to estimate the total costs of a new one. Just keep breaking the budget down according to the new work breakdown structure (WBS).

The main benefit of using the analogous estimating technique is that it is less costly than other estimating techniques. The down side of using this technique is that it is also generally less accurate.

You may be wondering, "If analogous estimating is not considered to be accurate, why would I use this technique?" However, before you disregard analogous estimating altogether, you should be aware of the circumstances under which it is most reliable. It is particularly beneficial when the following conditions are present.

1. The new and previous projects are similar
There are two situations in which analogous estimating is used. One is when your project is similar to other, previous projects. The more similar the projects are, the more accurate the estimates will be. You also can base estimates on a similar project when you don't have detailed information about a new project. More details are provided below.

• Are they similar? To determine the degree of similarity between the past and current projects, examine the scope and purpose of the former project to ensure the projects are alike in fact, and not just in appearance.
• Not enough detail. Sometimes important costing information becomes available only after a project has begun. A similar project's budget will provide a general baseline to go by.

2. The individuals preparing the estimates have the necessary expertise
Knowledge about, and experience with, the subject matter determines whether the individuals preparing the estimates have the needed expertise. You may want to hire one or more external experts to help with cost estimating.

3. The estimating team has access to adequate information about the previous project
If your current project lends itself to the analogous estimating technique, you'll want to furnish your cost estimating team with everything they will need to produce accurate results. Listed below are some types of information they should have on hand when they are developing cost estimates using analogous estimating.

• Scope statements. The team will not know whether two projects are in fact similar unless it can compare descriptions of the project and product scopes.
• Work breakdown structure. The work breakdown structure from the previous project is also necessary to ensure that similar processes and steps will be followed in the current project. Differences in the two projects could affect the accuracy of cost estimates.
• Performance reports. Actual costs are the most important information from the old project. Your team will use them to determine which of the previous estimates were accurate. It should use the actual costs to revise any inaccurate estimates before copying them into the new project.

Remember the analogous estimating technique as a less costly way of estimating project costs when your team has the needed information and expertise to effectively compare the current project to previous, similar projects.

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.

Updating the Project Schedule

To accurately reflect your project's progress, project schedules must be continuously updated. This process enables stakeholders to evaluate impacts to the project as they occur. This provides better control over the project and reduces the impact of required changes.

A schedule update is any modification to the schedule information used to manage the project. Schedule updates are required when variances from plan are higher or lower than the previously approved limit. Schedule updates may or may not require adjustments to other aspects of the overall project management plan.

There is a special category of schedule updates called revisions. Revisions are changes to the scheduled start and finish dates in the approved project schedule. Typically, start and finish dates are only revised in response to scope changes. In cases where schedule slippage is severe enough to warrant revision, rebaselining may be required to provide realistic data for performance measurement.

Palmcom Computers is developing a new palm-sized computer. The company has planned for the product to be introduced at the Fall Buyer's Show. It has decided to strive for this date, to get the heads-up on the competition. Reaching this goal allows for very little flexibility. At the end of the second phase, the management team notices that the schedule is slipping, resulting in a variance much larger than the acceptable range. If this trend continues, the company will not have the originally planned two weeks for quality testing.

In this example, the company has two choices—alter the project scope, or change the project schedule. After careful examination, the team has decided to maintain the current completion date and adjust the allotted testing time to one week to give the team an extra week for production.

Ongoing monitoring and updating are essential components of project schedule control. Adjustments to the project start or finish date (revisions) require special attention. In the event a revision is necessary, the schedules need to be accurately revised for the key stakeholders to continue to have a valid means of measuring the project's overall progress.

Managing Schedule Changes

A schedule management plan is an outline of how schedule changes will be managed. The schedule management plan can be either formal or informal, depending on the nature of the organization. The level of detail the project stakeholders require will determine whether the plan is detailed or broadly-based.

A schedule management plan is an important input to schedule control and can be used as a guide for your entire project. Project managers use a schedule management plan:

• to summarize how schedule changes will be managed
• to direct the management team on change processes
• to ensure that WBS responsibility assignments are controlled
• to make schedule changes traceable

The schedule management plan is just one of the components of the overall project management plan. Other management components include: scope, cost, risk, quality, and communications plans. To adequately assess the schedule impact of actual or proposed changes in all areas of the project, you will want to integrate the schedule management plan with the risk, quality, scope, and cost management plans.

One of the primary reasons for using schedule management plans is to determine how to manage schedule variances. During the project's planning stage, companies determine the acceptable range of variance from the schedule plan. The allowable deviation may be dependent on factors such as a project's life-cycle and accuracy of the original estimate.

For true variances to be realized, input from the risk, scope, quality, and cost control processes are essential. Once the information is incorporated into the plan, it is important to continually track "actual" against "planned" progress.

When it comes to decisions about how variances should be managed, there are four basic options to choose from:

• Dismissal - Dismissing the variance is appropriate when the variance is within the allowable range as stated in the schedule management plan. In this case, no corrective action is required, so the variance can be dismissed.
• Functional modification - Functional modification is called for when the variance is small and within the allowable range, but has the potential to become more problematic in the future.
• Replanning - Replanning is required if the variance is large enough to fall outside the allowable range. Replanning involves reviewing project requirements and redefining project goals. In replanning, less critical activities may be sacrificed to meet time and budget constraints.
• Redesign product - Redesigning the product is required if the variance is way out of range. This is the worst case scenario. In this case, the product description will need to be reconfigured which may result in lower grade performance.

As an input to project schedule control, a schedule management plan is an important component of project management. A schedule management plan helps you manage schedule changes, identify the level of variance, and determine appropriate corrective actions.

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 Are the Outputs of Scope Change Control?

How do you know if you have successfully conducted the scope change control process? The success of the scope change control process will be demonstrated by the accuracy and completeness of what it produces—its outputs, which are:

• approved scope changes
• corrective action
• lessons learned
• adjusted baseline

Scope changes are any modifications to the agreed-upon project scope as defined by the approved work breakdown structure. These changes often require adjustments to cost, time, or project. When the changes occur, project managers need to update planning documents and notify stakeholders as appropriate. These changes can be minor, such as making small changes to project limits or eliminating work that is not required, or major, such as adding work that was not in the original project plan or changing the project design.

Approved scope changes usually lead to corrective action. In general, corrective action is anything done to bring expected future project performance in line with the project plan. It often requires a root-cause analysis to identify the cause of the variances. Once you identify the cause of the variance, you or your team members can take appropriate corrective action.

Examples of corrective actions include narrowing the project scope to deliver the work results on budget or on time and adjusting resources by adding project team members or substituting project supplies.

Have you ever finished a project and wished you had done something differently? One of the outputs from scope change control is lessons learned. You can keep information about closed-out projects and use it to save time and money on future endeavors. The lessons learned during scope change control should become part of a project's historical database.

As you document the lessons learned, you could include the main causes of cost or schedule variances, the reasons behind the corrective action chosen, and any actions you will perform differently in future projects.

The final output from scope change control is an adjusted baseline. A baseline is the original approved plan for the project or particular project phase. On a project, there are often several separate baselines, such as the cost baseline, the schedule baseline, or the performance measurement baseline. Depending on the nature of the scope change, the corresponding baseline document may need to be revised or reissued to reflect the approved change. The adjusted baseline becomes the basis for determining future changes.

Approved scope changes, corrective actions, lessons learned, and adjusted baseline are the outputs of the scope change control process. To ensure your project's success, you will want to be certain these important and necessary elements are not overlooked and become part of the project process and final report.

Should You Approve, Endorse or Reject a Change Request?

Knowing how to manage scope changes can make the difference between project success and failure. To increase your chance of success, you need a technique that enables you to track and manage changes as they occur.

Some changes to project scope, such as legislative changes or new safety standards, are mandatory. By definition, mandatory changes must be implemented. Other requests for changes are not mandatory but may be beneficial. If implemented, these changes can impact the project schedule, budget, or both, so they must be effectively managed.

Scope change control defines the procedures by which the project scope may be changed. It includes the paperwork, tracking systems, and approvals necessary for authorizing changes.

Before authorizing changes, a project manager must:

1. assess the impact of the requested change
2. choose the appropriate status for the change request

Since the opportunity to add value decreases and the cost of change increases as project work progresses, you need to consider the work effort and the associated cost when assessing the impact of proposed scope changes.
The more time a scope change requires, the more it will affect the project budget. You need to assess the length of time, or work effort, it will take to implement the proposed change.

The most common method for calculating the work effort in relation to a specific scope change request is the resource profiling method. The resource profiling method uses the Baseline Effort, Skill Factor, Work Interruption Factor, and Part-time Effect to calculate Normalized Effort (NE)—a real-world estimate of work effort.

• Baseline Effort (BE) - The BE assumes that the task will be worked on full-time, without interruption, by a team member with a high level of technical skill and knowledge. To determine the BE, determine the ideal length of time it will take to complete the task in a perfect world.

• Skill Factor (SF) - The SF represents the proficiencies of the team members who will complete the proposed work. A value of one indicates expert knowledge in the area. A value of two indicates a proficient and acceptable skill level. A value of three indicates little or no knowledge.

• Work Interruption Factor (WIF) - The WIF takes into account reasons for temporary work stoppage. The most common type of interruptions are idle time, meetings, breaks, and communication. To calculate the WIF, add ten percent per interruption type and one percent for each team member.

• Part-time Effect (PTE) - The PTE compensates for the fact that the team may work on more than one activity at a time. To determine PTE, assign a 0 percent loss for full-time work, a 10 percent loss for three quarter time work, a 15 percent loss for part-time work, and a 20 percent loss for one quarter time.

Once you know how to calculate the factors used in resource profiling, you can calculate the Normalized Effort (NE).
To calculate NE, subtract the WIF from 100. Then divide 100 by this value. Next, subtract the PTE from 100. Then divide 100 by this value. Finally, multiply these two values with BE and SF.

In addition to determining the work effort, you need to determine the associated costs of the proposed change. There are many direct and indirect costs associated with implementing a scope change. Some of these costs include:

• overtime payments
• late completion penalty
• lost business opportunity
• rework
  
• new equipment
• insurance requirements
• changes to guarantee or warranty.

The associated costs of a proposed change should be expressed in a cost estimate (CE). To produce an effective cost estimate, you need to include all of the resources required for the task, including the time it takes to complete the change. The more resources you include, the more accurate your cost estimate will be.

There are some situations in which you won't have enough information to assess the impact of a requested change. The change request form could be missing vital information or be improperly filled out. In these situations, you should request more information from the person who originally requested the scope change or from other members of the project team who would be able to supply supporting details. You must then reassess the impact of the change.

Once you have all of the required information, you need to choose the appropriate status for the change request. The three status options are: approve, endorse, or reject.

You should base your scope change control decision on the results of comparing the estimated effort and the associated costs to the contingency reserve for your project.

• You should approve a change request if the contingency reserve is greater than the effort and cost estimate. For example, if the estimated effort is 12 hours, and the contingency reserve is 40 hours, you should approve the change.
• You should endorse the change request to the project steering committee if the estimated effort and associated cost are less than ten percent above the reserve. The project steering committee would need to approve the discrepancy.
• You should reject a change request if the contingency reserve is less than the effort and cost estimate. Approving a change in this situation would cause deviations and overruns not approved by the project steering committee or the client.

By using accurate work effort and cost estimates, you will be able to assess the impact of project changes and determine the status of the changes. These methods of scope change control will help your project stay on the right track.

Two Other Important Inputs to Scope Change Control

Your project scope is a dynamic entity. If you don't keep an eye on it, it can spin out of control and wreak havoc on your project. Project scope verification and change control are the processes used to keep your project on target, on schedule, and within budget. The main inputs to these processes are the work results, product documentation, work breakdown structure (WBS), scope statement, and project plan. Two other inputs to scope change control are also invaluable in scope verification and change control. These "other" inputs are the scope management plan and performance reports.

• Scope management plan
  
  The scope management plan is a basic high-level plan for scope change control. Developed during the scope planning process, it is actually a part of the scope statement. It will help you rate how proposed changes will impact the project.
  
  High-impact changes are the most severe and affect the whole company. Scope changes of this type affect the revenue and schedule of a project. For example, a delay in supplies could be rated as a high-impact change if it will impede the project schedule.
  
  Medium-impact changes affect the project team members. These scope changes could alter how the team approaches the project, but shouldn't add time or money to the project.
  
  Low-impact changes affect individual members of the team. Team members may need to modify a particular task within a project phase. Low-impact changes should not affect project baselines.
  
  Another component of the scope management plan used as an input to scope change control is the description of roles and responsibilities in relation to scope changes. Clearly defined responsibilities make the change process smoother because the team members will know exactly what they are expected to do.
  
  The requester is any project stakeholder who submits a change request. It is his or her responsibility to fully complete the change request form and forward it to the change coordinator for the project.
  
  The change coordinator receives new change requests and ensures they are complete. The change coordinator is responsible for requesting clarification of any confusing information and forwarding the change request to the assessment team. This person may also lead the assessment team.
  
  The members of the assessment team are responsible for determining the impact of the proposed change on the scope of the project. They also provide an estimate of effort to implement the change.
  
  The project manager reviews the assessment information and determines the impact on project schedule and budget. It is the responsibility of the PM to approve or reject any change request that is within his threshold of acceptance. He passes any other changes to the project steering committee.
  
  The project steering committee reviews change requests only when asked by the project manager. The steering committee has the authority to approve or reject these changes.
  

• Performance reports
  
  Performance reports are also inputs to scope change control. One of the duties of the project manager is to provide stakeholders with periodic project updates. Performance reports provide the project manager with a means to provide accurate, periodic reports. The reports include values of planned, actual, and earned costs, which show project performance at the present time as compared to the baseline or objectives. You can use these values to measure performance after making a change.
  

"Other" inputs to scope change control help to ensure that changes to your project's scope are adequately controlled. Together, the scope management plan and performance reports provide additional information to help you manage scope changes and incorporate them more easily into your project.

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.

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.

Historical Information and Scope Definition

Norman Cousins—writer, editor, and renowned Federalist—once said, "History is a vast early warning system."

Information from past projects can serve as an early warning system for your current project by giving you considerable insight when you're defining project scope. This type of scope definition input is referred to as historical information. Information from past projects that will be helpful in defining the current project scope includes the following.

1. Previous project documentation
You can find previous project documentation in the form of outputs from other planning processes. When collecting historical information, you should limit your search to documentation generated from similar projects.

The emphasis should be on identifying areas in which other similar projects were particularly successful. This information is easily found in the project development data that is included within a project's scope specifications.

You also should look for information that may have caused problems, such as scope omissions. This information is commonly found in the lessons learned output created during project wrap-up.

2. Personal experience
You also can gather historical information from personal experience. For example, the first working experience with a client provides insight into that client's preferences. Since you already know the client's likes and dislikes, you can apply this knowledge to your next project and make scope definition changes in advance.

You also can draw on the personal experiences of your co-workers. For example, a person who has worked on a project similar to the one for which you are defining the scope may provide you with useful information.

The lessons learned from previous projects provide early warning signs for potential project scope problems. Using historical information as an input to scope definition will result in more successful projects and happier clients.

Other Inputs to Project Scope Definition

When defining project scope, you may find that the formal scope planning documents are not always a sufficient source of information. What other sources can you tap into to get the information you need, so you can accurately define project scope?

One source of additional information that contributes to scope definition is outputs from other project planning processes. Outputs of the planning processes in the other knowledge areas can be inputs to defining project scope.

Typically, other planning processes are underway simultaneously with scope planning. The outputs that result from many of these planning processes should be reviewed during scope definition because they often contain valuable information that can be used when defining the project's scope. Oftentimes, the outputs from other planning processes have an impact on the defined scope for a project.

Although you can review other management areas when defining your project scope, you should review four key areas that produce outputs to determine if these outputs have an impact on project scope definition. The four areas you should review are listed below.

• Project cost management. This area ensures that a project is completed within the approved budget. Since scope definition involves cost estimating, outputs from this area that should be used as inputs to scope definition will focus on resource planning, cost estimating, and cost budgeting.

• Project time management. This area ensures timely project completion. Since project scope definition requires duration estimates, outputs from this knowledge area that should be used as inputs to scope definition focus on activity definition, activity sequencing, and schedule development.

• Project human resource management. This area helps a project manager make the most effective use of team members. Since scope definition requires resource projections, outputs from this area that should be used as inputs to scope definition concern organizational planning and staff acquisition.

• Project quality management. This area ensures that the project will satisfy the needs for which it was undertaken. Since scope definition requires defining deliverables for client satisfaction, outputs from this area will focus on quality planning, quality assurance, and quality control.

Given the importance of the scope definition process, you should seek out all available supporting information. Outputs of the four project management areas described above are excellent inputs that can help you accurately and efficiently define your project scope.