Managing Changes to the Project

Managing Changes to the Project

Ideally, Perry would like the Smythe Project to proceed as smoothly as possible that is, according to plan. Yet he knows that nothing goes exactly according to plan. A project environment is dynamic, not static, and changes will have to be made.

Managing Change

The key to handling project changes is to not resist them but to manage them. Perry puts in place good change management disciplines that will help him determine whether to implement contingency plans to deal with unanticipated events, take corrective action to get back on schedule, or make new plans for part of the project. Each action he will take significantly impacts project execution.

Managing change makes good practical sense. It helps Perry focus on the plan by identifying variances. It helps him maintain control by providing feedback on what is and should be happening at each step. Finally, it allows him the opportunity to adjust or modify plans so the goals remain realistic.

Of course, Perry knows that managing change is not easy. The project is constantly moving ahead, making it difficult to get an accurate snapshot. The right information in the right form at the right time is not readily available and in some cases is nonexistent. It takes time to develop and implement an infrastructure to detect, review, evaluate, and respond to changes. To deal with these obstacles and challenges, Perry must meet certain requirements.

He must have reliable, valid information. Bad data lead to bad information, which in turn can result in bad decisions.

He must have baselines to measure against. The baselines typically relate to cost, schedule, and quality. The baseline is the criterion against which to judge actual performance. The variance is the difference between what is supposed to be and what is. Perry must make decisions regarding any variance. Those decisions might be to do nothing or to make changes.

He must have people who are adaptable to change. They should not be reactionaries or revolutionists, but realists. Presumably he has chosen such team members, but if not, he must determine how to deal with anyone who is overly resistant to change.

He must establish an infrastructure to manage change. He must institute policies, processes, and procedures for reviewing, analyzing, and responding to change. He must communicate these policies, processes, and procedures to team members. This infrastructure should also include people who are responsible for identifying, reviewing, analyzing, and responding to changes. If necessary, these people should help with scheduling, tracking, and monitoring the implementation of changes.

Perry will need to have a medium for capturing changes and tracking their fate, from identification to disposition. The medium, typically an electronic or hard copy form, is shown in Exhibit 17-1.

Exhibit 17-1. Approved request form.

Types of Changes

To identify whether a change is necessary, Perry establishes a series of baselines. Baselines are agreed-upon points of reference. In the project environment, baselines are set for schedule, budget, and quality.

Ideally, a project proceeds according to its baselines. However, variances can occur, and the project manager must decide how to respond to those variances. First, however, the project manager analyzes and evaluates the nature of a change. Many changes are internal, such as adjusting how a task is done because of an unrealistic specification. Other changes originate from external sources. The customer or senior management may, for example, arbitrarily reduce funding or change scope.

Perry develops a classification scheme for such changes. He classifies them as major, minor, or corrective.

A major change dramatically affects schedule, cost, or quality. Examples include across-the-board cuts in budget, expansion of the scope of the project without increasing the budget, or acceleration of the scheduled completion date.

A minor change is one that does not fit in the major category. Examples include a small change in the specifications or requirements.

A corrective change is nice to have but unnecessary. An example might be addressing an overlooked nice-to-have specification.

Whether major, minor, or corrective, Perry assigns each change a priority. A priority can be either major, minor, or deferral.

A high priority change demands immediate attention. It is a show stopper. Generally, such changes are major changes, too, but not necessarily. The customer, for example, would like to significantly change the specifications, but the change is not doable without substantial changes to the schedule, budget, or quality of the desired result.

A medium priority change does not require immediate attention. However, it must be addressed before the project ends. An example is an important but small change to the specifications.

A low priority change is addressed, if time permits. These changes include nice-to-have features or offers in a product or service, respectively.

Perry, of course, does not alone make decisions or change categories and priorities. He forms a change board, which consists of people responsible for classifying and prioritizing changes. The people on the change board are typically the project manager, selected team members, and customer representatives.

The change board does more, however, than just categorize and prioritize changes. It also analyzes the impact of such changes on cost, schedule, and quality. It approves or disapproves the changes, and it assigns responsibilities for executing these changes.

Corrective Action

Sometimes the contingency plans do not work or an unanticipated event occurs. Either case, it impacts cost, schedule, and quality and requires corrective action. This means taking steps to get the project back on track.

To take corrective action, Perry must address some challenges.

He must have sufficient data to define the problem and determine a solution.

He must distinguish between causes and symptoms. Using good analytical techniques can help, but so will good data, especially if it answers the who, what, when, where, why, and how of the situation.

He must respond quickly. Procrastination and indecisiveness can convert a problem into a crisis.

He must recognize that corrective action occurs throughout the project cycle. There is a tendency for project managers to think that ever-thing is fine up front, only to be surprised toward the end that corrective action should have been taken earlier.

He must seek feedback on the corrective action taken. The feedback should indicate whether the problem disappeared.

Replanning

If corrective actions are inadequate, Perry knows the next step: replanning. Replanning is redoing the project plan by making wholesale changes to cost, schedule, and quality factors.

There are several reasons for replanning. First, it makes more sense to follow a realistic plan. Likewise, the team works more efficiently because the changes have reduced confusion. The team is also more effective in achieving the project goal.

To replan well, Perry must address certain prerequisites.

He must have reliable and valid data to determine whether replanning is necessary.

He must act quickly. If not, replanning will break synergy. It will also detract from productivity, even under the old plan.

He and everyone else must have patience. Replanning takes effort and diagnosing past performance can be sensitive. Some people do not want to replan; it only adds frustration. Other people fear being blamed for the circumstances that led to the replanning.

He does replanning as early as possible. During the early phases of a project, replanning is easier. Many unknowns are expected and the momentum is just beginning. However, it is more difficult to replan during the latter phases. The momentum is faster, people are rushing to accomplish major milestones, and it becomes more costly to do any rework.

He understands the impact that replanning will have. Will the replanning be expensive? How much time and other resources will be required to replan? When must replanning be complete? What impact will replanning have on cost, schedule, and quality?

When replanning, Perry remembers that there is no such thing as a free lunch. If he decides to schedule, there will be negative and positive effects. The same can be said for cost, quality, and people factors.

Perry, for instance, decides to change the logic of the network diagram because the Smythe family wants to have the bridal shower two weeks earlier. The Smythe family also wants to increase the number of attendees by 20 percent and add more events. All this affects the schedule, of course, but also the scope of the project. The changes also have positive and negative impacts. A positive impact is satisfying the customer; a negative impact is temporarily slowing the momentum of the project, which in turn reduces productivity.

Contingency Planning

Ideally, risk assessment (see Chapter 12) provides the basis for good contingency planning. Contingency planning involves developing responses to situations that have a good probability of occurrence and could impact project performance.

Exhibit 17-2 Contingency plan form.

For the Smythe Project, Perry develops a contingency form, shown in Exhibit 17-2. He records the description of the event; its probability of occurrence; its impact on cost, schedule, and quality; and the appropriate response.

Reliable contingency plans dont just happen, as Perry well knows. They require having information about possible events, including their potential impact; time preparation; and feedback indicating when the events do occur.

Summing Up Change Management

The project environment is not static. No matter what plans or baseline he establishes, Perry knows that he will have to evaluate and implement changes. He also knows that change affects costs, schedule, quality, or a combination of them. He is determined to manage change; otherwise, change will manage him and he can quickly lose control.

Questions for Getting Started

If you decided to take corrective action, did you:

Determine exactly what caused the need for corrective action?

Determine the most appropriate corrective action and implement it?

Receive input from the people affected by the corrective action?

Set a blockpoint date for the corrective action to be implemented?

Communicate the corrective action in advance?

Seek feedback after the corrective action was implemented?

If replanning, did you:

Determine what is the cause for replanning?

Determine what areas (e.g., cost, schedule, quality) of the project are affected by the replanning? The negative and positive impacts?

Determine resource requirements and their availability for resource planning?

Determine the data and information requirements for replanning?

Obtain input from all of the people affected by the replanning?

Obtain feedback from all the affected people once the new plans went into effect?

If doing contingency planning, did you:

Determine and document the possible events using the risk assessment?

For each event, determine and document the probability of occurrence, the projected impact, and the appropriate response?

Make sure the plans are readily available?

Assign someone responsible for upkeeping and executing the contingency plan?

Receive input from the people affected by the contingency plan?

Obtain and assess relevant feedback from the individuals affected by the contingency plan after it has been implemented?

Did you establish a change management infrastructure that includes a means for:

Classifying changes?

Prioritizing changes?

Evaluating changes (e.g., change board)?

Documenting changes?

Tracking, monitoring, and addressing changes?

Communicating changes?

Following up on changes?