Are you baselining? I know, it sounds like some drug-related crime, doesn’t it? It’s actually one of the most fundamental aspects of modern project management and a stunning percentage of project managers don’t do it. So this month I thought I’d dedicate the column to the elusive art of baselining.
So, what’s a baseline?
First of all, what is a baseline? Everyone agrees it’s a snapshot of your project which is frozen now for use as a comparison later but consensus ends there. A snapshot… of what? What does the snapshot contain? If it’s changeable is it really a baseline? All sorts of questions arise when we introduce the concept.
The most common kind of baseline is for the project schedule. Most project management tools include the ability to save the start and finish dates of each task into something called a baseline. Ok, we’re just into the schedule so far, but which start and finish dates are we talking about? The early dates? The late dates? The resource-scheduled dates? The constraint dates? The critical-chain late dates? Target dates that have been contractually agreed upon?
It’s enough to give you a headache, isn’t it.
The short answer is, it depends on how you want to manage your project. The most common dates that would be saved in a scheduling tool would be the early dates. But, if you’re doing resource-constrained schedules, then the resource-scheduled dates makes the most sense. If you need to do reporting to a client, then a target date will be more attractive. In short, you’ve got to decide before you start what you’d like to use as the basis for comparison.
Now, we’ve just talked about baselining the schedule but there are some organizations that will also baseline the costs. They will do planned vs. actual expeditures. Or, you can baseline the cash flow as you might for an Earned Value project in the defence sector or you can baseline the resource assignments vs. the resource usage showing how close your original plan was in the way you consumed your resources or you can baseline the risk for each task.
The point of all of this is to have something against which you can compare later.
Can you change it?
People who just get started with baselines often think of them as an inviolate set of records and that’s only partly accurate. What happens if a new task is added to the project? Should it be baselined? The obvious answer is, of “course” but here’s a harder question: What if adding that new task means that other tasks will now not be able to meet their original baseline? Should you be allowed to change the baseline on those tasks in order to avoid a task variance that’s sure to ensue when you only think about the original work?
It is very common in many project environments to have an authorized change of scope in mid-project. Even when the project is for an external client it isn’t uncommon for a client to ask for the project to change. So, what do we do with the baseline not only for the new tasks but also for the tasks which may be affected by the change? Most project management tools allow you to create a baseline only for certain tasks or to track multiple baselines.
If you are‘re-baselining’ in mid-project, then there are a couple of principles to think about. First, what will you do with existing tasks that have actual results? Will you use the actual as the baseline or keep the original baseline to compare later? Next, you want to be sure that the original, original baseline is maintained for comparison later. No matter how many ‘approved’ changes there are, it’s certain that one day down the road, someone will want to compare the completed plan with the original intent. By the same token you want to be able to identify each authorized change in scope separately. When management asks ‘what was the original plan of just the new scope?’ you want to be able to answer.
Finally, the process by which someone gets to change or create a new baseline should be understood by everyone. I can still remember one of my first clients who explained their re-baselining process. “Whenever we’re more than 10% variant, we rebaseline,” the project manager explained to my incredulous ears. Sure enough, while I was working at this company, senior management from the head office asked to see the current plan for a 4-year old project’s “original-original” baseline. The original plan had been $400,000 and the current plan was well over $4,000,000. It had creeped up a few thousand at a time every couple of months until it reached the current staggering number. The project was cancelled a day or two later.
Doesn’t everyone already do this?
There is a surprisingly high percentage of users who never baseline their project. They make a plan and then adjust and update the plan according to changing conditions. What they can’t do is compare the current plan to the original. There are many project management environments where the idea of comparing against the original plan is very unattractive because the corporate culture is to not be managed at all. Now, no one admits to that being the reason. Instead you get something like “We’re a design-build company so we are always changing the scope” or “The project moves too quickly to stop and take a baseline” or “It takes too much work to keep up with the variances in the project and it’s just a distraction”. Whatever the reason, without a baseline, these organizations are unable to compare their original project plan with how it ultimately turned out and so measuring project performance is close to impossible. These organizations will often have a recurring problem with projects enduring scope creep and missed deadlines and budgets.
Ok, I’ve got a baseline… now what?
The whole point of doing baselines is to compare them against the current plan later. Regardless of whether you’re comparing dates or costs or resources, what you should start with before you even record the baseline is an idea of what kind of report you’ll need on a regular basis to identify the variances and, much more important what you’ll do when one happens. The best practice is to define a series of thresholds and some kind of process that is triggered when the threshold is exceeded. It can be as simple as a project review by a senior manager but some kind of process should happen when the number is exceeded.
Let’s wrap up
The attractive displays that most project management tool vendors will show you are almost always based on some kind of baseline being established and that’s no accident. The variance reports that show the current plan vs. the baseline are exactly what both senior management and project managers look for when they want to intervene and make a difference. A few months ago I met with a company who regularly do a very repetitive project. The project is a little different every time but the basic elements are all the same and so they’ve gotten used to doing it the same every time. “Where is the baseline to compare against the last few times you’ve done the project?” I asked. They all looked at each other. There was no such data. The current plan had no baseline. “But it always takes the same amount of time,” grumbled one of the managers. “Why bother comparing?”
“Because using a baseline gives us something to target; something to push against,” I replied. “And, pushing against the target is the best way for us to be as efficient as possible.”
After all, isn’t that what project management is all about?
