Baselining is the act of recording your original project estimates so you can compare them to actual results at a later time. It is also the platform from which the project is conducted. In other words, the baseline contains schedule and cost numbers used by the project team throughout the entire process. By baselining the project, you are laying the foundation on which the project will rise. That’s a nice thing to have. Employees want a good solid plan that doesn’t wander from whim to social whim. They want a visible goal that isn’t ducking and weaving out of sight every week. Such a goal offers reassurance and confidence for success. A moving target is the worst motivation killer known to man.
But sometimes you just need to start over.
Yes, a moving target is a sure killer. But there are times when the baseline is just crap. The schedule has become irrelevant, costs are laughable, and the project team is floundering in a sea of mud. Nothing is going as planned. Designers are throwing in new requirements that were heretofore unheard of. Executives are MIA. And managers have you working 80 hour weeks to hit a target they have no clue of the purpose of. Nobody’s admitting they’re stupid, but it’s obvious everybody is. It’s only years later that everyone can look back and shake their heads at the calamity. But while you’re in the midst of it, you just keep buggering on.
It is those times that executives, or maybe a strong-willed project manager needs to step in and call a hiatus. But who’s got the guts for that. Again, you’ve got to be a strong person to blow the whistle and wave your arms. But if you can recognize the signals, a re-baselining during a mess like this may be your only option.
I was on a two-year software death-march like this. It was a disaster. Nobody knew the warning signs. Nobody blew the whistle. Nobody re-baselined. The product failed six months after release, which was at that time a year overdue and marketplace irrelevant. It was the worst project I was ever on.
Here is a good rule of thumb for knowing when to rebaseline:
Baseline the project if you have missed over half your scheduled targets in the last six months.
Have you missed a few end-to-end tests? Missed a customer drop or two? How about a major milestone? Missed a target feature? These are the warning signs. Again, if you have missed over half your targets in the last six months, rebaseline. Don’t try to figure it out, just baseline the project again.
In fact, in cases like that above I would suggest cutting the scope in half. Cut the project into smaller phases. Get the schedule down to visible goals. And if anybody disputes them, cut them again. And then again. You must have realistic goals or you will fail every time.