Lesson 3: Fundamental Project Concepts: Part 2
Baselines
Project management language can seem so odd sometimes that when we come across a term that is starkly straightforward, it is not unusual to pause and look for some kind of hidden meaning.
Behold the term: baseline. It really does mean the line at the base of something.
Line at the base of what, though? Well, that depends on what you're measuring. If you're looking at how much cash you've spent, then you'd be looking at the cost baseline, or if you want to see how much time you've spent on something, you'd consult the schedule baseline.
PMFORUM's glossary gets us on our way to understanding what baseline means:
A planning and control instrument in the form of a summary of attributes such as quantity, quality, timing, costs, etc, that establishes a formal reference for comparison and verification of subsequent efforts, progress, analysis and control. Can be for project, business or technical management control.
Oooooooook.
Let me elobrate by way of mythic tale.
Let's say ORK, a proud caveman, decides he wants to carve 3 drawings on his cave, per day, for 40 straight days.
ORK decides to create a schedule. Since he expects to carve 3 drawings per day for 40 days (for a total of 120 drawings), he notes all of this data down on his schedule. His schedule tells him not only how many drawings he's planned to have carved by the time he's done (120 in total), it also tells him how many he'll hit at the halfway point (60 drawings in 20 days), and any other point between when he starts his project, and when it is planned to end (which will be 40 days from the start date).
Once ORK is ready to start his project, he looks at his schedule and baselines it. That is, he freezes it and names it the schedule baseline.
Now let's fast forward 20 days. ORK has been busy drawing on his cave walls. At the end of day 20, he counts his drawings and sees that there are 65.
Stay with me, this is going somewhere.
This data has project management-related meaning to ORK because he can compare what is happening in reality to the baseline. In other words, he can see that according to his schedule baseline, he thought he'd complete 60 drawings by day 20. But in reality, he's at 63.
By being able to reference the schedule baseline, ORK was able to see that he is ahead of schedule.
Is this good? Maybe, maybe not. Maybe ORK is ahead of schedule because he is spending more caveman money than he had anticipated (a look at realty vs. the cost baseline would tell him if this were the case). Or maybe he is ahead of schedule because another activity (such as painting each drawing a nice banana yellow) was not taking place, and was therefore artifically speeding up the drawing part of the project (but neglecting the painting part).
Checking reality against the baseline thus tells the Project Manager if things are devitating from what was originally forecasted. If they aren't, then that's fine. But 99.9% of the time, something will deviate, and it's the Project Manager and her/his team who will decide what course of action (if any) should be taken.
A final note, most baselines are created at the outset of the project and remain stable for the entire life cycle. However, there are some extreme cases where something so unexpected (either negatively or positively) has happened to the project that renders the original baseline useless. When this happens, sometimes the project team will be forced to rebaseline whatever things it had originally baselined (cost and/or schedule). In other words, the first baseline was so totally whacked, that it made no sense to compare things to it anymore, and so a new standard had to be created.
Rebaselining is a rare occurance (thankfully), and is almost always a last resort contingency for a project that is spiraling out of control due to an unforeseen event.
References used in this section
PMFORUM: http://www.pmforum.org/library/glossary/
