When I ask project managers what a baseline is and why it’s important, they tell me that it is an approved starting point against which project performance is measured.
They are right, of course. But when I ask them if they use baselines, as often as not, I find that baselining is a fundamental project management practice that is neglected by many project managers and organizations.
Lack of good project discipline or good tools probably explains why many projects don’t get baselined. Understanding project performance and providing input into lessons learned are two obvious reasons for utilizing baselines.
One perspective about baselines, however, sheds light both on why it is often not done and why it should be.
As the approved starting points, baselines are the definitions of cost, time, and scope against which the project will be measured and evaluated. The source of consternation for many is that those definitions will change. Planning for most projects is a process of progressive elaboration. Sometimes it feels like we could plan forever, because we are constantly encountering new information, gaining new understanding, even encountering new stakeholders.
So if a baseline or snapshot of the plan is what we’re going to measure against, then it’s pretty tempting to wait just a bit longer so we have a little more information and feel a little more certain about the definition of those project objectives. That way we will be more likely to meet them and less likely to need to change them.
But consider this: The purpose of a baseline is as much about recognizing change as it is about preventing it. In the absence of a baseline, how do we even know if what people are asking for is different than what we’ve already done or planned?
Why, for example, do scopes creep? Often it’s because they were never baselined in the first place. How is it that we get into these battles with stakeholders about whether or not what they’re asking for is different than what they’ve already asked for? Maybe it’s because we don’t have anything to compare it to!
Baselines enable us to recognize change and respond appropriately. In order to control the project, we need to know the relative size of a change request or deviation from the plan baseline. Is it small? If so, then maybe we can make some adjustments to how we’re executing to bring ourselves into alignment with the plan. Is it substantial? If so, then we know to go through a process to get approval as to whether or not we will update the baseline and manage to the new plan.
But without something against which to compare changes, we are really guessing as to whether or not it’s even a change. That is likely to result in a creepy scope and a project manager with very little in the way of negotiating leverage.
It’s not enough to just monitor the project if we don’t have a means of controlling it. Without baselines we can’t do either.