In our third and final post in the “Gantts, Lies, and Videotape” series, we’ll discuss the Mulligan. For those of you not familiar with the golf term, “Mulligan” is an unsanctioned do-over, usually with no regard to ever counting the first attempt. Historians disagree on whether the term originated with Canadian David Mulligan or American John “Buddy” Mulligan.

In the interest of not reigniting the War of 1812, we’ll turn our attention back to project management and how the Mulligan relates to our equally interesting (if not more so?), but not as often televised profession.

In project management, you are committing a Mulligan when you re-baseline your project plan. Below, you’ll see two versions of the same project plan. Both reports show a baseline in black beneath the actual delivery dates, but the project manager cheated:

Why the harsh accusation? Because the project manager re-baselined the project plan for the second report even though the delivery dates slipped by two months. Golfers don’t get a do-over when they miss a shot, and project managers can’t rewrite history to tell their stakeholders that things are on track when they aren’t.

Purists would say that once you decide to re-baseline, you might as well stop baselining altogether. We understand there are legitimate business reasons for re-baselining, but you shouldn’t report on it in the same way you would treat your original project baseline. Here, we’ll show you how baselines should be done, plus how you can show that you’ve re-baselined without flat-out lying:

 

Both of these options allow you some flexibility, while keeping you honest:

1. Show Baselines as Baselines: This is still our recommended approach. Unless you have a good reason to re-baseline, don’t. The original project baseline is the most accurate way to see if you are on track or not. In option 1 above, the black bars show the true, original project baseline compared to the revised schedule. It’s easy to see the project is behind.
2. Show Change to Baselines: If you must re-baseline, you still need to reference your original baseline so it’s clear you’ve pulled a Mulligan. In option 2 above, the black bars show a re-baseline, but the red triangles and dotted lines show the start/stop dates of the original baseline. We’ve chosen to show this only where the baseline has actually changed, which is why the red triangles don’t show up on “Task A”.

Project plans are fluid almost by definition. In keeping with textbook project management methodology, baselines are meant to show the fluidity by remaining constant. We agree with this approach. But if you have a justifiable business reason to pull a Mulligan, be sure you do it the right way so that you are keeping yourself and others honest.