Project baselining is a set of stored values — such as estimated budget, planned schedule and anticipated effort — that serve as a reference to help determine whether a project is on or off track. Here are four vital best practices to ensure that project baselining is an asset vs. a liability:
- Don’t wait until you have all of the available information before baselining — because that will never happen.
Obviously, it’s wise to incorporate an appropriate amount of reliable data, and ultimately create a robust project baseline that is worthy of the label. However, if you keep putting off the task to get “yet more information,” then you’ll get stuck on a staircase to nowhere: because the pursuit never ends.
There is always going to be more information to gather, because projects are inherently iterative. The more they unfold, the more they reveal. As such, at some point before the project starts — not after — it’s necessary to do a gut check and hit the baseline button. Otherwise project baselines won’t and can’t do what they’re supposed to.
- Decide ahead of time what baselining reports will be used to track progress, who will get them, and what recipients should and shouldn’t do.
Organizations can generate several project baseline reports to monitor scheduling variables, including many that dig far deeper than “X amount of work completed by Y date.” Deciding what reports to generate, when to generate them, who should get them, and what recipients should — and shouldn’t do — should all be formally captured by an agreed-upon policy and workflow.
This is especially important when customers receive baseline reports. Without context, they can (and often do) jump to the wrong conclusions. For example, if the project is spending less than anticipated, they may think that efficiencies have been found or that the original budget was wrong, when in fact neither may be the case. Or if they see that the schedule is two weeks behind the baseline prediction, they may panic and make rash decisions — when in reality this development may not be bad news at all.
- Be prepared to change the project baseline — but only if necessary.
In project management school, the subject of project re-baselining is often approached with immense consternation; like on Star Trek when the enemy has ship surrounded, shields are at zero percent, decks 6-14 are floating off somewhere in space, and the captain says in a voice wracked with dread: “engage emergency plan zulu zulu zulu” (and the screen goes dark and we must wait a week to see what happens!).
Well, in down here on earth, while project re-baselining is a serious step, it shouldn’t be thought of as last resort that is one step removed from total project annihilation. Things change — and it’s not always bad things, either. And when those changes are big enough, then re-baselining isn’t just smart, but it’s necessary.
The key, however, is to make sure that re-baselining follows a clear change management process that includes getting buy-in from all applicable stakeholders. Otherwise, some people will be OK with the new baseline, and others won’t — and that’s when things get really scary.
- Dig deeper to find out the WHY — and separate it from the WHAT.
Like a lot of things in the project management world, project baselining seems simple and easy from the outside. After all, what’s so challenging about taking a snapshot before a project begins, and then comparing numbers on an ongoing basis?
Well, if you talk to any seasoned project manager — or any new project manager in a few months after they’ve had a few baseline battles — the reality is quite different. Project baselining isn’t a clerical process, and neither is baseline evaluation; especially since it’s not automatically or necessarily good news that a baseline is on target.
For example, let’s say a project’s cost baseline is in alignment (i.e. actual spending matches expectations), but the schedule baseline reveals a 7-day overrun. On the surface, it’s tempting to conclude that spending is fine, but team members need to gear-up get more done in less time. But what if the estimated costs were too low to begin with, and that forced team members to work slower? If so, then the problem isn’t the schedule or the team: it’s the budget.
Obviously, this is an (extremely) simplified example. But it does reveal something very important about project baselines that organizations neglect or forget at their peril: baselines can reveal WHAT is going on with a project, but they don’t reveal WHY — and they certainly don’t provide guidance on whether developments are positive or negative. That insight only comes from additional analysis, and in many cases, the project manager’s best judgement.
- Use the project baseline as a motivational tool.
Some of the world’s best project managers get even more value out of baselines by using them as motivational tools, since they can help teams come together and strive to achieve targets (either internal or against industry norms).
What’s more, rather than being unnecessary in environments where projects are fairly repetitive, baselines can be even more useful here since they can drive teams to be innovative and efficient. Instead of having a fuzzy gut feel that they’re doing things better now than they did in the past, they can compare baselines and definitively know that they’re making progress and raising the bar.
The Bottom Line
Project baselines are valuable tools, and when they’re created, monitored, tracked and optimized with the right project management software they can — and frankly, should — be used to keep projects on-track, portfolios healthy, customers happy, and enterprises headed in the right direction. That means plenty of success stories, and few (if any) activations of emergency plan zulu zulu zulu.
