When I started in the project management industry in 1984 the concept of a baseline was nothing new. Indeed, it was a critical element of the first major client deployment of project management software that got my business and my career underway.
Even in 1984 baselines were not a big favorite of those in project management. It was something over the years that I continued to promote. These days we hear less and less about baselines for reasons I’ll discuss below. They are just as powerful a tool now as they ever were so perhaps it’s worthwhile to revisit those early lessons I had from years ago.
What is a baseline?
Let’s start with the underlying concept. A baseline is the expected plan for a project. At its most basic, it might be just the dates for the project and that already brings questions. In a project scheduling tool like Microsoft Project or Primavera, you’d be asked which dates you’d like to make the baseline from. Should it be the early dates, the late dates or the resource scheduled dates? Some product might have promise or commitment dates that would be separate from those first three choices. Once you make that choice, the dates for every activity are stored and set aside.
This is already phenomenally powerful as a tool. Now, as the project moves forward, you can always compare your progress to what you expected would be happen for tasks that are completed, tasks that are in progress and tasks that are yet to come. If you imagine this on a bar chart, the most common display would be to show the baseline as a bar in one color and the actual/projected in another either above, below or in front of it.
Why bother showing a baseline for tasks in the future? You might ask. Well, as the project advances, there may be an impact on future tasks and you’ll be able to see that right away.
Baselines can be quite a bit more involved however. Most project scheduling products allow you to also track the original resource assignments or allocations. This too might be very valuable in the future as you compare what resources were originally assigned and at what level alongside what resources and level of effort were ultimately required to complete the task.
Costs too can be part of or the definition of the baseline. This too could be critical in the future as you compare the amount you expected to spend on a feature or in a given period of time against what you’re actually spending.
But what if things change?
One of my favorite project management quotes is from Napoleon Bonaparte who once said “A battle plan lasts until contact with the enemy,” and, so it is with project management. Life will happen to your project. That’s one good reason to are a baseline in the first place but there may come a time when you need to add tasks or change the scope of the project to accommodate those life changes. You could, of course, just re-create and overwrite the baseline again once you’ve done those changes but then you’d lose the original budget; the original plan. (That might be very desirable for some project managers if the project isn’t going well but it’s not a great business practice.) So, how do we keep the original plan and make a new plan to work from? Most project management tools are pretty good about that, allowing you to create a new version of the baseline and keep the original. Alternately you can usually add new tasks to your baseline and baseline only those that haven’t been baselined before. You can then manage any variances moving forward against the current official baseline. One thing to watch for is when tasks are deleted. In many project management systems, this means the baselines disappear as well and therein a lot of mischief can occur. Often a better practice than deleting tasks is to deactivate them.
This can get out of control in a hurry so it’s a process that should have some structure to it. At one client we had in the 1980s we asked about how they’d like to manage their baseline.
“Baselines” they corrected us. “We have four.”
“Four?” I said cleverly. “Why four?”
“Ah, you don’t understand real project management in a real business,” they replied. “We have the ‘Original-original baseline’. That’s the one we got our original project funding from. Then we have the ‘Current-official baseline’. That’s the one that is in our official variance reports to management. Then we have the ‘Engineer’s-baseline’. That’s the one our team leaders are working against because they consider that their realistic yardstick. Finally we have the ‘Expected-to-be baseline’ which is what we expect will soon be the baseline when we make an official change.”
“Um, who uses them for what?” I asked.
“Well, different people use the variance reports for different things,” they replied, “but every once in awhile our senior management asks for variance reports against the Original-original baseline and that often heralds the cancellation of that project.”
This wasn’t the most effective concept but to be fair, the management at the project level worked very well and variances were reported weekly and monthly so project managers could jump in and help right away when things went awry.
What happens when the project progresses?
As the project progresses, some tasks will go earlier, some later. Some will be completed with less effort than expected some will require more. As a project manager, having the original expectation available to compare will allow you to see when if at all, you need to intervene. Many team members will work on a day-to-day list of assignments so interrupting people multiple times a day is usually not productive. But, checking every week or every few days can allow a project manager to see where things might be going off the rails.
In my own firm, during the pandemic, we let our concentration on baselines lapse. We had always been an Agile-based development team and that continued to work just as it had before as we shifted to working away from the office. But there would be consequences for us. In one instance, a developer was given work that they were ill-suited for but was uncomfortable explaining that they didn’t have the particular skills to deliver. The task was originally expected to take 3-5 days but at the team member level that original expectation was quickly forgotten about. All that we usually ask in an Agile progress meeting is “done or not done?” If the answer is “not done”, then the task would roll over to the next week. In this case it took over a month before a different internal report about hoped for features in our next version showed the incredible discrepancy. We had budgeted 24-40 hours, we were up to almost 200 hours when we caught the problem. We’ve reinstituted our baseline process now and keep an eye on it as part of our regular project management progress reports.
Why are baselines at risk?
We hear about baselining less and less these days. The baseline concept might sound like a great idea if you’re just reading what’s above but to be clear, the baseline concept has always been at risk. Most people don’t like the idea of being held to account. I’ve met numerous people in the project management industry who would prefer to insert their narrative as part of a progress report rather than rely on just data. This is particularly true when a project starts to run later than expected or cost more than expected.
In an Agile world the concept of baselines is somewhat foreign even if Agile tools include the functionality to support them. This isn’t wholly inappropriate. At the tactical level of a team member, is there any reason they should have to stress over the overall project budget? Will it have them work faster or work harder or perform more effectively? Probably not. But, when an Agile task starts to vary greatly from what was originally expected, the team leader and the project manager should be able to take notice. Perhaps the task was incorrectly scoped. Perhaps the task has taken on a life of its own with functionality that was never expected. Perhaps, as we discovered in our own organization, the task was assigned to someone who didn’t have the particular skill or experience to deliver it in a timely fashion. All of this will surface in a baseline report and intervening can be positive for everyone. Getting the right person onto the right job and making sure the request that was made is what is being delivered on can allow the project to move forward.
Does management actually care?
Do you imagine for a moment that management forgot the original baseline they used to decide on funding for the project? It’s more likely that senior management is working from only the original promise. One aspect of project progress that causes the most friction between senior management and project management is being surprised and disappointment when a project comes to an expected completion date and when asked when it will be delivered, the answer is nowhere close to what was expected. At the project management or even team member level this was probably known for some time but shocking management often comes at a price.
Many years ago I was coached in a business formula that I have used to this day.
No results + Good story = Results, my mentor wrote on a white board.
It’s a popular formals to be sure, “I didn’t get done what I promised but let me explain why. I have a super good story.”
I’ve encountered people who have embraced this formula my entire career.
“You said this would happen,” I will say.
“Sure, but you don’t understand. We had all these circumstances,” I hear as a reply.
Whatever I write here won’t change the popularity of that formula. But when it’s used on me I often reply with this: “Have you noticed that Christmas is never late? All kinds of people have all kinds of circumstances but somehow Christmas gets delivered on the right day. It might look differently than you planned but we never say to our kids ‘Sorry kids. I had circumstances so we’ll do Christmas another day.”
What management does understand is that things happen and things can happen to projects. Where you’re likely to find a significant ally in senior management is when you can communicate that things are not going as expected. No one at the strategic executive level needs or wants every detail of every task and they’re almost certainly not interested in the story why something isn’t going as planned. But, at the most summary level, knowing that the project will likely cost more or take longer or even that it is going to be completed earlier will be of great interest. And, the earlier that news makes it to the top of management structure, the better management can adjust.
Some baseline good practices
Every organization has its own structure and needs but there are some basic baseline practices that are useful for almost everyone.
Baseline
Start keeping a baseline and updating one on a regular basis. It doesn’t have to be complex. Use planned dates or just planned level of effort for comparison later. If you’ve not ever done this before, do it for awhile before publishing your results to everyone. You’ll get a better sense of how close to the mark your project estimating is.
Reconnect management to the project
Including summary updates to management on a regular basis will start to open the door to expectations of changes. Management won’t want weekly reports. Think of monthly or even quarterly reports at that level.
Don’t forget to project manage
With the incredible rise and popularity of Agile, some organizations have forgotten that an operational perspective that management at one level higher where project planning and tracking occurs is critical. If there is no plan and no thought to keeping to it, ultimately there will be upset.
You don’t have to abandon Agile
Nothing we’ve said above indicates that Agile isn’t an effective method for teams to function with. And, it’s fair to say that individual team members won’t have a real interest in what a baseline is but as a team leader, you can still empower team members by letting them know the expected level of effort for an assigned task and making sure that the scope of the task is was ell defined. What is critical with all project management methodologies is to ensure that the right tools are in use at the right level.
Wrapping up
Project management has many tools in the tool box. Baselining is only one albeit a potentially powerful one. As I say about so many project concepts, look through the tool box and use the tools that are right for your particular situation.
