Integrated Change Control

At this point you probably are thinking that with all the time and effort that went into planning, you should not have to worry about any changes. Everything is documented in the plan and the stakeholders signed off, so it should just be a matter of execution. That would be nice, but in the real world things change: a new business strategy, a competitive threat, or a new technology that was not available when you did project planning.

All aspects of the project plan are subject to change as the project progresses; the key to avoiding chaos is to manage any change in an organized fashion with an integrated change control system that looks at the impact of any change across all aspects of the project plan. A lot of time is spent in the planning phase developing estimates and plans for managing the project. Unfortunately, some project managers tend to forget all of that and just shoot from the hip if things go astray. You need to keep referring back to your planning documents and the management processes you put in place to update the plan.

Depending on how your change control process is set up, there may be a change control committee including the sponsor, the client, and other executives that reviews all changes, or the changes may be worked though the project team. Typically, larger and more complex projects have more formal change control. Regardless of who is involved in reviewing and approving changes to the project plan, changes that go outside established limits need to be presented to the stakeholder team. We will discuss stakeholder action later in this chapter.

Let's take a look at what is involved in controlling changes to scope, schedule, cost, and other elements of the plan.

Scope Change Control

As part of Scope Planning in Chapter 3, we discussed the need to define and document a scope management plan. As your project work progresses, you will implement this plan to control the scope of your project. Scope change control is the management and documentation of any changes to the project scope.

The following are some of the events that can trigger the need for the scope change process:

• A review of a major deliverable determines that there have been additions to what was defined in the project plan.

• Project team members indicate that they have made changes to a requirement.

• There is a formal request to add to the project deliverables.

• There is a design change.

In an ideal world, no change would be made to the project scope without going through a formal scope change approval process. In the real world, developers have conversations with end users or someone comes up with a different way of doing things and suddenly your scope has changed. If you discover that you are a victim of scope creep and a change has already occurred, you should still run the change through the scope change process to analyze the impacts to the other parts of the project plan and to secure formal approval for the change.

Let's review the key steps of the scope change process:

• Use a standard scope change request form with a description of the change, the reason for the change, and the originator of the request.

• Analyze the impact of the scope change request on the budget, schedule, and quality of the project.

• Use an approval process to accept or reject requests .

• Communicate results of scope change requests to all stakeholders.

• Incorporate approved changes into the project plan.

Scope changes may require corrective action and/or changes to the baseline.

Corrective Action If your project has become the victim of scope creep, you may or may not want to continue down the path that has created the scope change. You may need to determine what action is required to get the project back on track. It may take time to undo what has been done. In addition, you will want to investigate how the scope creep occurred and take steps to prevent future scope creep, such as educating team members on the scope change process.

Baseline Adjustments Any scope change, either planned or unplanned , will require updates to at least a portion of your baseline planning documents. At a minimum, you will update the scope statement. You may also make changes to the schedule baseline and the cost baseline, depending on the magnitude of the change.

Scope change control results may have a significant impact on schedule control, as you will see in the next section.

Schedule Control

As you review progress reports from project team members and the updates to the project schedule, your goal is to confirm that activities are on track or that any changes have been analyzed for impact to the critical path. Changes to the project scope will also require analysis regarding impact to the schedule. Schedule control is the process of managing and documenting any changes to the project schedule.

Project management software is an extremely useful tool for schedule control. Software packages can provide an individual task view of planned start and finish dates compared to actual dates, as well as forecast the impact of any changes from the baseline schedule to linked tasks, the critical path, and the project end date. You can also do what-if scenarios, to show the impact on a particular phase or even the project end date if task duration is changed or new tasks are added due to an approved scope change.

The key to making the best use of team member progress reports and the various reports and views using project management software is to focus on the critical path tasks. Remember that the critical path tasks are on the longest path of your network diagram and drive the end date of the project, so any delay to one of these tasks may lengthen the total project time.

Schedule control results include schedule updates, corrective action, and lessons learned.

Schedule Updates A schedule update is any change made to the project schedule as part of the ongoing work involved with managing the project. Schedules are typically updated weekly based on the team member progress reports to provide a current view of schedule progress and a comparison of status of the completed project work to the schedule baseline. Schedules are also updated to reflect new activities.

You may hear two terms in relation to schedule update. A revision is an update to the approved start or end date of the schedule baseline. Revisions are typically a result of approved scope changes. If a schedule change is substantial and impacts dates for multiple milestones or major deliverables, rebaselining may be required to provide a new means of measuring performance. Rebaselining should not be done lightly, as it distorts the accuracy of your original plan.

Corrective Action A number of factors come into play when considering whether corrective action is required as part of schedule control. Activity duration estimates are not expected to be perfect, so don't think you need to do something every time the actual time required to complete a task does not match the estimates. If an activity has a delayed start or is taking longer than expected, but has float time such that there is no impact to successor tasks, you don't need to take any action at this point. Your emphasis on corrective action should focus on critical path tasks.

Performance indicators can tell you that things are going wrong. Let's take a situation where critical path tasks are taking longer than planned and a major milestone may potentially be missed and/or the project end date is in jeopardy. The performance of critical path tasks impacts your ability to complete the project on time, so you need to look at what can be done to get the project back on schedule. Your first course of action should be to determine why the critical task is behind schedule and work with the person(s) assigned to the task to get it back on track. If you have a part-time resource, you should investigate bringing that person on full-time until the task is complete.

If nothing can be done about the activity creating the potential delay, your analysis will need to encompass the rest of the project work. You may implement fast tracking by having some tasks worked in parallel or crashing by bringing on additional resources to complete the remaining work in less time. If you choose to implement either of these techniques, be sure to document the risks associated with this course of action.

Lessons Learned Major changes to the project schedule should be analyzed to determine what caused the deviation from the plan so that steps can be taken to prevent the situation from happening again. These lessons may apply either to the remaining work on your project or to future projects. If all of the tasks assigned to a particular resource or group require more time than planned, you may want to have the people involved revise estimates for any future tasks or have the remaining estimates reviewed by a third party with experience completing similar tasks.

Changes to your scope or schedule may involve extra costs that need to be managed.

Cost Control

Another key project result is the tracking of project spending. Formal reports from the finance systems, project team member time reporting, and requests for purchase approval all provide a picture of how the project spending is tracking with the budget. The budget impacts from scope changes also need to be analyzed. The cost control process includes being aware of the project spending to date, determining that a change to the cost baseline has occurred, and taking appropriate action to deal with the change.

Project management software is also useful in tracking project spending, if cost figures have been loaded. You can run reports that show spending to date and projected spending. You can also look at the impact of adding new tasks using what-if scenarios.

Any major change to the project plan that will impact cost should include securing additional funding as part of the approval process. Adding requirements to the project and starting work on new tasks prior to securing funding is a sure way to overrun your budget.

Cost control results include revised cost estimates, corrective action, and lessons learned.

Revised Cost Estimates As actual costs are incurred and tracked, you are able to project how the actual costs for a particular project phase or even the entire project will differ from the original estimates. As with any deviation from the project plan, you should review the revised cost estimate to determine any impacts to other aspects of the project plan. An increase in overtime hours, for example, may be an early warning that a task is taking longer than planned. Frequently, revised cost estimates are the result of changes originating in other parts of the project plan, such as a scope change or schedule change.

Just as with schedule updates, there can be revisions to the cost baseline, typically in response to a scope change, or there can be rebaselining if the cost variances are so extreme as to make a change necessary in order to track performance

Corrective Action General cost overruns that are not tied to a change in another part of the project plan such as a scope change or a schedule delay may not require any further action if they are below some predefined level. Many organizations consider projects on track if the actual spending is plus or minus a predefined percentage of the overall project budget. If you have a 10 percent leeway on a project budgeted at $1,000,000, an extra $50,000 spent will be acceptable; an extra $200,000 would require the approval for additional funding.

If the problem rests with the accuracy of the initial cost estimates and there are no additional funds available, you may need to discuss trade-offs with your stakeholders, such as reducing the scope or lowering the quality. We discuss trade-offs in more detail later in this chapter.

Lessons Learned Major deviations from the cost baseline need to be analyzed to determine what caused the difference so that steps can be taken to prevent the situation from happening again. These lessons may apply to either the remaining work on your project or to future projects. If a number of work effort estimates from the same resource or group are not being met, you may want to have revised work effort estimates for any remaining tasks.

Now let's look at controlling change for some other aspects of the project plan.

Other Plan Changes

Scope, schedule, and budget are the items that are most frequently mentioned targets of change control, but these are not the only components of the project plan that may change. Let's take a brief look at four other elements: resource changes, requirements changes, infrastructure changes, and configuration changes.

Resource Changes Whenever a project team member is added or leaves , it is important to document the reason for the change, the name of the replacement (if any), the person requesting the change, and any impact the change will have on the project.

Requirements Changes This can be a tricky area to manage. As detail is added to a requirement or it is updated to clarify expectations, you need be taking a look at these changes to make sure they do not involve a scope change. Any new requirement should always go through the change control process.

Infrastructure Changes Infrastructure is the elements of a project that will remain permanently after the project is completed. As an example, a team member may have planned for a Sun server running UNIX for your database, but as the project moves forward, the network team requests that you change this operating environment to Windows 2003 Enterprise Server. Infrastructure components that may change include:

• Computing systems

• Software development environments

• Server operating system platforms

• Networking infrastructures

• Delivery methodologies

Infrastructure changes can have a major impact on your overall project plan, particularly if your project includes equipment orders that were based on different infrastructure assumptions.

Configuration Changes Frequently, the design team will make a decision about a software or hardware configuration only to find out as the software is installed that another configuration would work better for the requirements or that the suggested configuration won't work with another system in an integrated system environment. One of the more frequent examples of a configuration change is when the database design team determines that a given set of indexes is required for the database being designed. But then, as the programmers begin to write code that runs against the database, they may decide that another type of index would be useful and effective as well. So a configuration change is required to add the new proposed index.

Configuration changes can be very simple or quite complex-it just depends on the nature of the configuration and what is expected of the software or hardware. However, generally speaking most configuration changes don't require a lot of time and can be accomplished within a couple of hours, so they're really not project showstoppers. Keep in mind that some configuration changes will require a reboot of the equipment and thus may not be able to be put into effect until after hours.

As your project moves forward and major deliverables are produced, you will start implementing your quality management plan.