ON THE EDGE
Baseline? I'll do that LATER!!
By Carl Pritchard
In my consulting practice and my classroom teachings, I'm finding a common theme regarding the power of (and lack of insight regarding) the simple project baseline. Where do we start? What constitutes "underway"?
By way of definition, the baseline is the agreed-upon version of the project plan, including the timing, cost, resources and scope. It's the snapshot of the project against which evaluations are conducted and reviews are built. It's a snapshot that's extremely difficult to take.
Why We Avoid Setting Baselines
In Microsoft Project, the first time a project file is saved, a fateful box invariably appears: Do you want to save with a baseline? For many project managers, that's the single most vexing question the tool ever puts to them. If they say "yes," are they locking themselves into a project lifetime of misery and woe? If they say "no," will the project slowly spiral out of control without warning? Most opt for the "no" answer, assuming that they'll come back and add data later or come back and finalize the project plan at some future date.
We avoid setting baselines because there's always more data to be had. Management approvals, customer signatures, and team agreements all have the potential to amend the project plan, which (if the baseline was saved) means variance. The yearning for all the data, coupled with a fear of variance often inspires a near-phobic perspective regarding the baseline. The fear of being tied down to a single set of numbers in some organizations is too much to bear.
In a recent project planning class, I asked a student if he had baselined his network. "No!" he replied defensively, "I'm not ready".
"When will you be ready?" I asked, expecting an answer in terms of classroom minutes remaining. Instead, I got a somewhat philosophical reply.
"We don't have signature from the client on the latest change order and there's still some dissension on whether we'll get third-quarter funding. Should I have a baseline already?"
While the classroom answer was "yes," I began to ponder the deeper issues this raised. And having had several weeks to think it over, I believe the real-world answer was "yes," as well.
When to Save the Baseline
It's time to save the baseline when we have agreement. While no project ever achieves total agreement, the key here is consistency. Pick a document, a signature, an approval, anything. But select some project landmark that is consistent from project to project within the organization. And use it. Make it the marker. Make it the line in the sand that tells us when we're on-target and when we're off. And use the same marker for all of your projects (and if you're in the project office, all of the organization's projects).
Once you select that marker, establish that you will tolerate variance. It doesn't have to be consistent from project to project, but there has to be some tolerance for variance. If the baseline is set very early, that tolerance level must naturally be higher than if the baseline is set only after the WBS is built in excruciating detail from end to end.
If we're going to have variance and we know it can be different from project to project, why bother with a baseline? We need to have a metric by which we can determine if there are significant deviations. We need to have a tool we can use to identify to the customer what is inside and outside the existing project scope. We need to have the ability to discern if the project is out of control (or more positively, if it's complete).
How to Sell Baseline Practice
Why should management or a customer commit to a baseline? Other project managers within the organization may not be as rigid about it, and other contractors may not force the customer to sign off at all. That sometimes makes the job of identifying why we should do best practice more challenging. The rationale for the baseline is that it's in the customer's best interest and provides them a defense from the project team!
Most project teams have at least one team member (sometimes the PM) with vision. You know the person I'm talking about. It's the individual who sees a project as a learning opportunity with new strategies and tactics to be deployed and new technologies to sample. Vision is not a bad thing, if it's tempered by the customer's wishes and aligned with the project plan. But it can drive a project out of control. And it can do it without anyone being aware of it…unless there's a baseline. As new tasks are added to facilitate the new "vision," a baselined plan should set off alarm bells that there's new work without the authorization to justify it.
As for management or customer "vision," the baseline facilitates that through a controlled, documented change process.
Baselines versus Change
The toughest thing for many organizations to reconcile when setting a baseline is establishing how they'll cope with change. Should they change the baseline? Should they adopt a new baseline? Should the contractor be expected to "eat" the additional expense and squeeze it out of the original baseline?
In preparing for the old Project Management Professional's® exam, administered by PMI® in the early 90's, there was a question regarding what to do about change in the cost-plus (or cost reimbursement) contract environment in terms of the baseline. These same types of questions were addressed. The answer at that time (and I don't know if it holds true today, but it should) was that major change should be rolled into the project on a firm, fixed-price basis. It should not become part of the new baseline, and it should not become an administrative tracking nightmare as we try to track the original baseline and "Baseline II".
Granted, the project planning software now will track up to nine different "baselines", but that's not terribly helpful when you're trying to apply metrics to determine if we're ahead of or behind schedule, or over or under cost. That old practice (of using FFP to cope with baseline change in the cost-plus environment) eases the headache of project tracking, minimizes the hue and cry for baseline changes and assures some level of consistency. Also, from a practical perspective, if there's a new contract (even a simple FFP) each time the customer wants a change, it will minimize the frequency of such changes. And when they're in place, we'll be able to track them as their own separate entities.
Save WITH a Baseline?
The answer is "yes." Once you establish the official organizational benchmark for setting down the tracking practices, and once you clarify how you will handle major change, the "yes" answer to Microsoft Project's question should be rote. And the more we can consistently set down baselines as an organizational practice, the more we can assure customers (internal and external) that they'll get fair warning when we're straying from the baseline and a clear understanding of what they're getting for what they're investing.
Related Items on ProjectConnections
Baselining isn't the only sticky question on your WBS (though it's definitely in the top five). Oftentimes, the worst part is figuring out how to organize it all. Many of our members have asked for examples, so we collected
several different example schedules for you to review.
©Copyright 2000-2008 Emprend, Inc. All Rights Reserved.
About us Site Map View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy