‘Baseline’ is a term you might have heard in relation to projects (project baseline), but did you know there were three different types?
We will give you a detailed understanding of the different ways you can use baselines on a project but for now let’s cover some of the basics and explain what they are.
WHAT IS A BASELINE?
A Guide to the Project Management Body of Knowledge – PMBOK® Guide (Sixth Edition) defines a baseline like this:
The approved version of a work product that can be changed only through formal change control procedures and is used as a basis for comparison to actual results.
In other words, once the planning work is done, the team can draw up a version of the project by which to measure progress. Consider the baseline as a marker for how you plan for the project to be carried out.
Think of a recipe. Your baseline is the recipe itself. It tells you the ingredients, the oven temperature, and the time it will take you to prepare. You align your expectations to this, and ultimately hope that your meal turns out like the recipe.
Then you start cooking. You realise you don’t have onion, so you throw in extra garlic. You know your oven runs hot, so you adjust the temperature from the recipe accordingly. And chopping all those veg took you far longer than the prep time written in the recipe.
At the end, the meal turns out just fine. It’s not exactly as the recipe said, but you are happy with the end result.
Your project is just the same. You set expectations and define the baseline as the starting point for what you want to achieve. You know that there will be changes on the way and the process might not go according to plan. That’s OK; that’s the change control procedure is for! Updating your baseline goes hand-in-hand with the change control process.
The different project baselines give you a way to measure progress and record the changes from the agreed position at the start of the project.
There are three types of baselines you will commonly use on projects: scope, schedule and cost. We discuss each of them below.
1. SCOPE BASELINE
The scope baseline is created from the scope statement. It’s the full set of requirements – a comprehensive view of what the project is going to deliver.
Scope might change along the way as new features become possible or the customer’s priorities change. You may need to make savings and choose to do so by cutting some items from the scope.
For each change, the change control procedure is followed. The scope baseline provides that original view of what the project will deliver, and you can compare back later. You can also take another baseline at regular points in time to give you multiple comparison points.
2. SCHEDULE BASELINE
When we think of baselines, most project managers will instantly think of the schedule baseline. Most modern project management software tools will store baselines for you. The schedule baseline is a version of the project schedule at any given moment in time.
Take a snapshot of your schedule by saving it as a baseline. Then later on in the project, call up the baseline and compare it to the current forecast. There should be a change request every time the schedule changes significantly, so deviations can be formally approved.
Again, it’s useful to take several baselines during the life of the project so you have multiple reference points. You can use these during lessons learned discussions or when thinking about how to best improve scheduling for future projects.
3. COST BASELINE
The final baseline you will come across is the cost baseline. This is a record of the project budget and forecasted costs at a particular point in time – normally at the point when the budget is first approved.
Changes to scope and schedule will affect your budget, so integrated change control will ensure your budget is updated accordingly. A change that adds in extra features, for example, may require additional staff or resources, and there will be an implication for your budget.
The cost baseline provides that original view to compare back to. The baseline, combined with the set of change requests, is a good way to explain why costs have increased on a project.
UPDATING THE BASELINE
You can set as many baselines as you like, but it is worth keeping the previous versions so you can do a true comparison later on. Even if your ‘new’ accepted schedule baseline has a different delivery date, and that is now how you are measuring project progress, knowing the original plan gives you valuable information for estimating and scheduling in the future.
The best way to store baselines is inside your project management tools, where your tools give you this functionality. Otherwise, keep a copy of your project documentation as a reference and don’t update that version! As you need to make changes and flex from your original position, make a copy of the project documentation and edit that. Then you’ve always got a copy of the original to compare back to.
You don’t have to use baselines on projects, but they are very useful tools for understanding project performance during the execution phase. The PMO in your organization may have guidance for when to use them, how to set them in your tools and how to use them for analysis as the project moves forward.
