Of Schedule Management’s nine major facets, baselining arguably provides the least visible return on investment. Baseline change management processes are time consuming and can feel like admitting fault, even in the face of unforeseeable or uncontrollable circumstances. Worse yet for the Schedule Manager, implementing baseline changes requires meticulous attention to detail to ensure the change is made correctly and that trust in the schedule is preserved.

This article will discuss the step-by-step mechanics of adding, changing, or removing work that has been approved for rebaselining, and some pitfalls to avoid.

Minimizing Change to Maximize Baseline Quality

Always keep in mind that baselines are fragile. Baseline data does not obey schedule logic, and in many schedule management applications, careless hands can make unintended edits. So, when changing the schedule baseline, make the change minimally invasive. Don’t do reconstructive surgery if you don’t need to. The less radical the change, the less damage to the surrounding schedule, and the less opportunity for error.

Key to minimizing the impact of baseline changes on data quality is preserving original data whenever possible. All serious schedule management applications assign every line item a unique identifier so that line items can be audited throughout the schedule’s life. Suppose you are managing a simple baseline change request to reschedule an unstarted task and increase the effort by thirty-five hours. This is a straightforward edit to make by hand. It might be even faster to replace the line item with one that is already formed exactly the way stakeholders want it. However, this convenient shortcut creates a serious structural change.

Figure 1: Deleting and replacing a line item may be faster than making revisions by hand, but it destroys the task’s audit trail.

Figure 1 illustrates that while the two Write Installation Manual tasks may have the same name and may convey the same intent, the new line item is not the original line item. Returning to the anatomical analogy, replacing a line item is akin to replacing an appendage. You are probably better off not doing it if you don’t have to. How relevant is data integrity to the health of your project schedule? For nascent project teams and short duration schedules, the answer may be “not very”. But discovering that long lost little details should have been tracked translates to a very bad day.

The lesson is this. Deliberate attention to detail matters. If schedule data integrity is not important, make that decision a conscious one, and prepare for the consequences. If data integrity might matter, make changes to the schedule with deliberate care. Fortunately, the steps for implementing baseline changes almost always start and end the same way. When you follow a process and check your work you need not fear making mistakes.

Steps for implementing a Baseline Change

What follows is a methodology for making changes to a project. While it’s difficult to cover every scenario, the steps below should allow you to work through the most common baseline change scenarios while providing a framework for handling the rest. Modify as necessary to match what works for you and your project. Any consistently followed framework reduces the tedium and the opportunity for errors.

Step 1: Gather Your Documentation

Formal change management processes generate plenty of documentation to include the description of the change, the requestor, the reason for making the change, and maybe even a draft schedule. Collect and review all this information. This data is important both for correctly implementing the baseline change and proving that the change was correctly implemented down the road.

Step 2: MAKE A BACKUP

Before doing anything else, make a backup copy of the schedule, and save it in the project archives. This is good practice anytime the schedule is being changed, though it is especially important when changing baseline data. Keeping backups ensures that you can always inspect or redo any crucial steps in the schedule’s life. Unlike typical documents and spreadsheets, the unique properties of schedule files mean that starting over is sometimes the easiest or only way to fix a mistake.

Step 3: Isolate What Is Being Changed

Schedule logic can cause rebaselined tasks to shift their dependent tasks unintentionally. Figure 2 depicts a simple construction project in progress. The client has approved the contractor’s request to crash the schedule.¹ To effect this change, the Schedule Manager must remove the dependency between Installing Sinks and Toilets, and Paint Locker Room. Changing schedule logic to reflect changed plans is common, and perfectly acceptable. The fluid nature of projects and schedule logic is one of the reasons why task dependencies are not baselined.

Figure 2: In the proposed baseline change, Paint Locker Room will start early, and end as originally planned. Making this change to the baseline necessitates isolating the task from Install Sinks and Toilets.

Step 4: Make the Change to the Schedule

Before revising the baseline, the schedule itself must be revised. This requires great care. Below are a few common examples of changes made to the schedule.

Adding New Work

Inserting a new section of schedule is usually straight forward. The addition is accomplished either manually, or by inserting a previously created schedule fragment (sometimes called a network fragment or “fragnet”) into the existing file. This new section of schedule should be logically connected to the rest of the project. New work rarely happens in a vacuum.

Figure 3: If newly authorized work cannot be logically connected to existing tasks, an “Authorization to Proceed” milestone may be useful for denoting when a change to the project plan was approved.

Sometimes no simple logical connection can be made. Figure 3 depicts a scenario where new work is added to a large software development effort. The client wants work on the new module to begin right away. The Schedule Manager could connect the first task, Design New Module, to Module Development with a start-to-start dependency plus lag, or to the project start with even more lag. However, these logic pretzels confuse the evolutionary history of the project with no real benefit to horizontal traceability. Reality can be more accurately reflected by prefacing the new work with a milestone marking the Change Control Board’s approval.

Removing Unstarted Work

Justifying the removal of unstarted work is usually a simple case of the work being no longer in scope. Removing tasks always carries a risk of creating hanging logic. It is also important to understand how removing tasks will affect the project’s outline structure. Figure 4 depicts a kitchen remodeling activity which is part of a larger home renovation effort. Depending on any date constraints for scheduling the contractors, the activity’s start date may shift as well as its end date.

Figure 4: The client’s decision not to install a new kitchen sink and counter will affect the Kitchen Remodeling activity’s end date, and possibly its start date.

Modifying Existing Work

Modifying existing work in one sense is easier then adding or removing work because you usually don’t have to make structural changes to the schedule. The largest concerns are usually accounting for knock-on effects of dependencies, or resource loads. When revising a line item, pay attention to what variables are changing, what variables are remaining fixed, and which subsequent line items should and should not be impacted.

This is a circumstance where schedule management software sometimes tries to be too helpful. Suppose a new senior tester needs to be added to an integrated software testing task as in the left side of Figure 5. When attempting to balance the work equation, the software may assume that the user wants to change the task duration or redistribute the assigned work. Take care to ensure that the change is made exactly as intended.

Figure 5: The chart at left shows a plan to add a new Senior Tester for thirty-two hours to support a previously planned integrated testing effort. The chart at right shows the same effort with work logged against half of the integrated testing task.

Schedule management software can also struggle when rebaselining work that is partially done. Suppose the same integrated testing task is well underway. Unless the work to date has executed perfectly according to plan, the task’s actual and baseline timephase data will not match. The act of rebaselining the task means that any effort and duration variances recorded to date will be set to zero. In effect, rebaselining a started task retroactively claims that the task was planned to account for the idiosyncrasies encountered all along. This equates to changing the past, and that is not allowed.

Unfortunately, the only remedy is to remove all progress from the task, update the baseline (see Step 5), then restore the progress recorded to date. These added steps are tedious, but necessary to ensure accurate record keeping. The best way to minimize this chore is to keep tasks small during project planning and help the project team clearly see any changes they will need to make in advance.

Decomposition

Sometimes, project teams don’t know what they will be doing halfway through a very large project. But they must estimate how hard the work will be. For example, an urban consulting firm may not know what the client’s priorities will be in a year. But knowing that their team of six will have two or three requests to research new projects, they can confidently put a three-thousand-hour, eight-month planning package task on the schedule with the expectation that this planning package will be broken down into defined work when the time comes.

Decomposition combines two distinct baseline changes. The first change modifies existing work by withdrawing a collection of hours from the planning package, like a bank account. The second change adds new tasks equal to the total effort withdrawn from the planning package. These new tasks are often called a work package.

As with accounting, the proverbial dollars and cents must always add up. Figure 6 demonstrates how a work package’s baseline efforts, plus what’s left of the planning package must equal the original planning package estimate. Also, each work package period of performance must fall within the planning package’s period of performance.

Figure 6: In March, an urban development firm was allocated eight months and three thousand hours to support various city improvement projects. One month into the period of performance, two work packages totaling 2,400 hours have been planned. Six hundred hours remain for a small project between mid-July and next February.

Work packages can be created from the planning package at any time, so long as they are approved before the end of the planning package, and the planning package has enough hours left to create the work package.

Archival (Removing Completed Work)

On very large projects, it may become necessary to remove completed work which no longer plays a part in ongoing activities. In the vast universe of projects, this is uncommon. But software applications have their limits. The complexity of a multiyear project with tens of thousands of resource loaded tasks can overtax schedule management applications resulting in sluggish performance and calculation errors.

If software performance considerations make it necessary to remove a section of completed work from the schedule file, below are the conditions which make removal acceptable.

All line items have been complete for at least a year.
The line items are contained within a large summary activity (high level outline number) which is complete and can be removed in its entirety.
All successor tasks and milestones are complete.
Major project events or milestones (e.g., groundbreaking, a major software release, deployment) which the line items lead up to are complete.
The Project Start Date does not shift. (i.e., don’t delete the Project Kickoff milestone)

These impacts to the schedule presented to the change control board demonstrate that future and in progress work will not be impacted by the work’s removal. Once approved, the actual deletion of the completed tasks should be straightforward.

Step 5: Set the Baseline

Once the schedule has been modified, use the schedule management application’s baseline management tool to set or reset the baseline. Make sure to set the new baseline only for tasks which have changed. Additionally, make sure that the schedule management application rolls the baseline change up to the appropriate summary activities. The schedule management application should have a setting within the baseline tool to perform this function.

Step 6: Verify you changed what you wanted to change.

Check the approved change request documents and make sure that what is described in the documentation is what is reflected in the schedule file. If the change isn’t correct, start over.

Be careful about consulting with project managers and team leads after the change has been submitted. Within the bounds of what was agreed upon, they may have some input regarding how the change is implemented. However, their real opportunity for input comes before the change control board reviews and approves the baseline change. The letter of the change must be adhered to.

It is also important to check the summary activities. When revising the schedule baseline, sometimes the summary activity baseline data will not update correctly. Careful use of the schedule management application’s baseline utility, or a good third-party repair tool are the best options for fixing summary activity baselines. While it is technically possible to fix summary level baselines by hand, this is not recommended.

Finally, if any actual work has been removed from the schedule to rebaseline in progress tasks (see Figure 5) that work should be re-recorded against their respective tasks exactly as before.

Step 7: Document the Change in the Schedule

You know your insurance age bracket because someone made a record of your birth. Schedule baseline notes describe project life events of comparable importance. These notes can be invaluable, both for the historical knowledge they hold and the timeliness with which that knowledge can be retrieved.

Figure 7: The customer who is getting their kitchen remodeled has requested two changes to the initial plan, according to the baseline change notes.

Figure 7 shows a kitchen remodeling project which has been replanned twice before the work started. The baseline change notes show that work was added and rescheduled on February 20^th. Additionally, the Kitchen Remodeling summary activity shows that previously planned work was removed from the schedule on February 15^th.

This pedantism is unlikely to add value to a 200-line schedule. It has a better chance of saving you time on a 2,000-line schedule. On a 20,000-line schedule documenting changes becomes essential.

Step 8: MAKE A BACKUP

Last of all, make another copy of the schedule and save it to the project archives. The original copy of the schedule, and the rebaselined copy serve as a record of the change and can be revisited in case of an audit. Schedule Management can create a heavy paper trail, so it is important to have a good file management process.

Unapproved Baseline Changes

In rare circumstances, a Schedule Manager will use their authority to revise or repair a schedule baseline. These revisions must not change the scope, effort, duration, or number of tasks in the schedule. The Schedule Manager isn’t authorized to make such revisions alone.²

However, the owner of the schedule does have the authority to make changes to correct the readability, reliability, and accuracy of the schedule. Here are a few examples of changes which a Schedule Manager may make on their own initiative.

Adding a milestone which recognizes completion of an existing summary activity to consolidate schedule logic.
Moving a task into or out of a summary activity or revising the schedule outline structure.
Repairing parts of the schedule baseline, especially summary activities.

When making such a change, the Schedule Manager should follow the same documentation steps which they would follow for any approved baseline change.

Next Steps

The length of this article underscores the high cost of maintaining a schedule baseline. Successful schedule baseline management forces project leads to plan the small details, respect business processes, and react deliberately. Project managers resist this level of control because they don’t see the payoff. Long-term investments often yield high, albeit quiet, returns. Floodwaters are far less noticeable when dams and levees do their job.

In effect, proactive baseline management redraws the lines of success for project teams. The schedule baseline is no longer a manager’s castle to defend, but their watchtower. A well-built schedule, and a well-maintained baseline make possible the quality schedule analysis that project teams can use to change their project’s outcome with minimal heroics.

Related Case Study: Tracey’s Past