Did someone say: Baseline?

---

In one of my past Agile classes I facilitated this discussion re baselines:

Student 1:
 "I have a new Operations Director, and he says once you've missed a date, you re-baseline, and the item is no longer indicative of a bad/out of date status.
In previous positions, we didn't always or weren't allowed to do that, so that they could track the original dates vs. current progress.
Just wondering how others handle this."

Student 2, in reply:
"When I baseline a project, it is once and done. How can one measure truly the progress and planning of a project if the baseline is reset every time a date is missed? I agree that this would indicate a false sense of progress, a false green.

The only exception I can think of is if the project plan introduces a significant change that is approved by the project board and sponsor that impacts greatly the objectives and especially the schedule.... "

My facilitation:
Not exactly!
Re Student 1: if  you've missed a date, that's a variance. The baseline is still the plan you are managing to so long as you are trying to recover the schedule.

Re Student 2: "once and done" doesn't work either. There may be many reasons to rebaseline as the project goes along. It's not like you have a budget of 're-baselines' and you can only use so many. However, the key to the whole thing is the second point: "... significant change approved by the [controlling authority..]"

So here's the thing: first common sense always applies. In most non-trivial situations you have two plans at all times:

1. The baseline which is the agreement between the sponsor (business) and the project
2. The operating plan which is the day-to-day plan derived from the baseline

As project manager, you must have a strategy to merge or bring together the operating plan and the baseline so that at the end of the day, the baseline is the plan of record... all variances of record are measured against the baseline.

Now, if it becomes the situation that the baseline is no longer valid -- approved changes, etc -- such that there is no practical way to merge the ops plan with the baseline, then you rebaseline:

1.  Record and archive all variances to the baseline -- B1
2. Replan the project; this replan becomes the second baseline -- B2
3. At the project conclusion, sum the variances. Add the variances from the former baseline B1 with the variances accumulated in B2. These become the cumulative variances of record.

To wit: you get no free lunch on variances just because you re-baselined. And, this is the deal in Agile or traditional... no escaping there either.

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog