Baselining Fundamentals discussed how schedules, which are fluid, use baselines to track the project against its original plan. However, this does not mean that baselines remain fixed. While the monolithic perception of schedule baselines still casts a shadow, a schedule baseline reflects stakeholder consensus regarding what the plan should be, nothing more. When stakeholders shift their project goals, the schedule baseline should shift as well.

This article overviews how to establish a consensus driven baseline change management process. It will then discuss why some schedule baseline changes are more valuable to the project than others, when to rebaseline, and when not to rebaseline.

Establishing Schedule Baseline Change Management

Whatever their methodology, project teams need to organize around formal project management processes, including a process for establishing and revising the schedule baseline.¹ Like any formal project process, the schedule baseline management process should be as straightforward and frictionless as possible.

Nascent project teams may not know why they must formalize baselining the schedule, let alone how to do it. It is extremely difficult to establish a baseline management process without project leadership championing the process. Pushing to maintain a schedule baseline encounters the heaviest resistance from project teams because it adds bureaucracy and drives accountability. Additionally, the return-on-investment can be hard to notice. This is a little like saying kidneys are the least important vital organ. Project teams who don’t maintain a schedule baseline suffer chronic headaches from constantly having to revisit and reanalyze the schedule. They may not even realize the added burden they are shouldering if they’ve only known schedule management without the benefit of a well-maintained baseline. Schedule Managers have a responsibility to advocate for an effective, sustainable baseline management process, and must be prepared to persuade project leaders why establishing a schedule baseline will ultimately save time and improve the likelihood of success.

Schedule Managers have a few substantive arguments for persuading leadership that they should baseline the project schedule. First, any project that is subject to standards compliance must be baselined.² This usually convinces managers that they must baseline their schedule despite their own inclinations. The second argument expands upon the compliance justification. If a project has major deadlines, basic risk and customer management practices dictate that the project team track whether they can make those deadlines. Any project significant enough to justify a budget (i.e., a cost baseline) also deserves a baselined schedule. Tracking the deadlines of only a few major events limits schedule forecasting to a one-dimensional view of the project. But tracking every line of a project schedule against a baseline allows a skilled Schedule Manager to foresee obstacles months in advance and spot opportunities to navigate around them.

The third argument stems from contemporary project management concepts of collaboration and team building. Using the schedule baseline to create consensus about the project’s scope, plan of attack, and deadlines, gives all stakeholders opportunity to voice questions or issues during the process. Even if stakeholders have concerns about the schedule, they are more likely to support the project if they have participated in the planning, versus being handed a set of requirements and a due date.

If Schedule Managers cannot establish support for a baseline management process, they may need to take matters into their own hands. Going it alone is the least desirable approach to maintaining a schedule baseline. It puts extra responsibility and workload on the Schedule Manager. But a siloed baseline management process is possible with caveats, and far preferable to having an unbaselined schedule.

Under no circumstances should a Schedule Manager acquiesce to not baselining the schedule. An unbaselined schedule connotes a project team that has no agreed plan. Every argument against maintaining a schedule baseline boils down to not wanting to exert the effort or have mechanisms for accountability. Counterintuitively, a sound schedule baseline makes the pressures of accountability easier to bear. Regular revisions to the baseline, when done properly, add value to the project by preserving the baseline’s relevance.

The Value of Rebaselining

Goalposts move. Plans change. When the project team makes a strategic decision to change the plan, the schedule should reflect the new consensus. If a hardware system requires a redesigned widget, or software calls for a new feature, the value in revising the schedule baseline is clear. However, not all schedule rebaselines are created equal. Figure 1 depicts a few examples of the comparative value that various rebaseline decisions add to the project schedule.

Figure 1: Some qualitative examples of high value and low value changes to the schedule baseline. A planning package is a high-level placeholder estimate of resources, effort and duration that is used to budget more detailed tasking once the work is understood.

Revising the schedule baseline to reflect changes in scope, or consensus on a revised deadline have high value because these changes are necessary to reflect reality. But rebaselining a task’s finish date merely because it is running late is far less useful. For example, consider the scenario where an outside vendor who promised delivery in June now says they won’t deliver until October. Impacted project teams unavoidably must replan their work. These replanned efforts are good candidates for rebaselining. But should the vendor delivery milestone be rebaselined? Not necessarily. The vendor didn’t seek the project’s blessing to shift the delivery, and contractual obligations don’t change just because they can’t be met. Rebaselining the vendor’s delivery date may serve only to hide the vendor’s unreliability.

Change management processes are unavoidably time consuming. It is not worth the effort to revise the schedule baseline unless the change contributes to the project’s success. Schedule stakeholders who paper over too many of a schedule’s warts with baseline changes are decreasing the schedule’s worth and wasting time. So how can project teams identify which proposed baseline changes are valuable to the project?

Business writers distinguish goals as being achievements which are worked towards, whereas expectations are more akin to assumptions. By those definitions, schedules are goal-oriented documents. Changes to the schedule baseline should reflect changes to the project’s consensus goals. Figure 2 lists a few general justifications which may be brought before a change control board. The justifications at the top of the figure are responses to new or revised goals. The bottom justifications are reactions to missed expectations.

Figure 2: Justifications for revising the schedule baseline often boil down to one of these reasons, which the change control board must decide to accept or reject.

The schedule’s primary purpose is to reflect reality, not portray that work is proceeding as “expected”. When work falls behind, the schedule baseline counters any initial assumptions or expectations about how the work would unfold. In a sense, rebaselining tasks which are three weeks late, because they are late, reaffirms the dashed expectation. That is considerable effort to invest only for the sake of acknowledging something which is already known.

The change control board’s most valuable contribution to the project is their willingness to say no. Just as earlier generations insisted on protecting the baseline at all costs, changing the baseline at no cost can be equally damaging to project success. Sometimes, the right course of action is to let things be late.

When to Baseline/Rebaseline

In a properly planned schedule, all work should be baselined before it is started and before it goes into the Live Plan.³ This means that a brand-new project should be reviewed and approved before work on that project begins. However, even in small projects it is rare that the entire project can be planned from the beginning. New work almost always needs to be added to a schedule while the project is underway.

Figure 3: The process for approving a new project schedule should be the same as the process for approving new or revised work.

The new work may or may not increase the project’s length. It may or may not add to the project team’s resource loads. Even if the amount of work being added is small, it should be approved using the same consensus driven approach by which the original schedule was built.

Importantly these steps must be taken before work begins. Retroactive baselining — that is, approving project changes after the work has started — is much more tedious for Schedule Managers implementing the change. It also spreads contempt for the process. When project teams feel comfortable simply explaining what happened rather than planning, they make a habit of allowing circumstances control their work and expectations.

When NOT to Baseline/Rebaseline

We’ve already talked about how some baseline changes have greater and lesser value to the project. Irrespective of value, some baseline changes cannot be made without ruining the schedule. The most destructive of these is rebaselining past history.

Figure 4: Project planning and execution can only flow one way.

In project and schedule management, there is an assumption that work is planned and then it is done. Any number of problems may wreck the plan. But work is never done first, and then planned. Even the most innocent justifications for planning in arrears blemishes credibility. Baselining, or rebaselining completed work usually attempts to accomplish two things. First, it creates the false impression that the work was perfectly executed.⁴

More nefariously, it creates the impression that work was planned when it was not. The principal problem with this strategy is that it does not work!

Manufactured results fool no one. Any part of the schedule that is posthumously baselined to the claim that work happened as planned faces contradiction by electronic messages, contemporaneous project documents, and troves of individual knowledge. Everyone knows when deadlines were missed, especially the client.

The second most destructive baseline change which a Schedule Manager should never allow is impossibilities. Suppose a software development team needs 2,400 hours to complete a major feature, and they plan to get it done in two weeks. That’s technically possible if the team includes thirty people with heroic motivation. But anything less is simply not possible in a forty-hour work week. Don’t allow your team to architect their failure. Even if all stakeholders buy-in, even if the team says they can handle it, don’t allow them to lie to themselves or others. Insist they explain how all six developers are going to work a 200-hour work week. Numbers that don’t work on paper, cannot work in practice.

Project teams that baseline impossible project targets are gambling they can beg for forgiveness in lieu of asking permission. That may succeed for certain classes of projects and clients.⁵ But there is every prospect that the adage won’t hold. As above, the best justification for holding fast on this ethical question is practicality. Well-planned projects can still go awry. When they do, the original plan is often thought out enough that teams can replan with confidence, or at least clarity. Projects that are optimistic beyond reason start the replanning process in a far deeper hole because they first must come to terms with their unrealistic expectations.

The third and final category is a catchall. Never baseline work that is provably unachievable. Don’t add scope the project team knows they are not going to do. Don’t baseline dates the team knows they will miss. Besides not being worth the effort, baselining falsehoods devalues the entire project schedule. How can stakeholders take any of the schedule seriously when they know misinformation was deliberately sown?

Holding one’s ground against managers determined to mislead is difficult. Managers who are naive or desperate enough to ignore the laws of time are unlikely to be intimidated by a mere colleague. Remember that baseline change management is consensus driven. It’s one thing to threaten a single Schedule Manager. Coercing an entire team to forsake tomorrow in favor of looking good today is an entirely different proposition, though it can happen.⁶

Next Steps

When driven by realistic consensus, both a new schedule baseline and a revision provides stakeholders with a plan for teams to complete their project and gauge its achievements. Facilitating the baseline change process enables teams to regain control of their project rather than being perpetually controlled by winds of fortune. But consensus driven change management processes only last if the Schedule Manager can follow through on executing the change in the schedule. Baselining Techniques teaches the meticulous detail necessary to effect changes to the schedule baseline, and how to implement those changes quickly and cleanly.

Related Case Study: Tracey’s Past