Baselines, baselines…it is one of those terms that many people feel they have a grasp on, but might not know exactly what it is or why it matters, and for some of us the way we use it in “everyday speak” is different from how we use it in a project context. Perhaps you’re thinking the baseline is our starting point or our comparison point, perhaps you’re thinking it is something you will hear in a nightclub in Ibiza (here is a clue: this article will not involve going clubbing) perhaps you have no idea at all. Fear not: this article will clarify what a project baseline is and why it matters.

Project baseline: what is it?

The Association for Project Management (APM) defines it as:

The reference levels against which a project, programme or portfolio is monitored and controlled.

What does that mean? In the simplest possible terms: the baseline is the version of the project plan that has been signed off, and that we will use to compare progress against as the project is being implemented.

The baseline is therefore not a separate entity, or an additional thing you find or create or purchase, it is there all along – the key is that it needs to be formally recognised. It is the formal recognition that brings it into existence.

Sign off/approval process in a baselined plan

What is a “Deployment” baseline?

This is a term you are most likely to have come across if your organisation is aligned to the APM, or perhaps you are preparing for a project management certification exam like APM’s PMQ.

The APM defines it as:

“The reference levels created as an output of integrated planning and development of the project management plan”.

In a project, there are several things that can be baselined: you can have a separate baseline for the schedule (that means the version of the schedule that has been signed off), a budget baseline, a scope or requirements baseline etc.

Some organisations use the term Deployment Baseline and this simply refers to the overall Project Management Plan (so all plans, including schedule, budget, scope, risk, procurement etc) combined.

Ok, so what is the point – why should I have a baseline for my project?

There are several reasons why a baseline is important and valuable:

1) It fosters commitment and accountability

You could think of the baseline as a promise of what will be delivered by the project, how and when. Effectively, getting sign off on a plan is the same as the project manager saying “I promise I will deliver the defined scope, according to this schedule/timeline and using this budget” and the approving body is effectively saying “I/we promise that if the project aligns to this plan I will grant you the requested time and resources and approve the output once it is done”.  The baseline is a formalised version of this promise so therefore it fosters commitment and accountability. The project manager must ensure they present a plan that can be baselined and that they will stand by and commit to delivering. The approving body must consider the plan carefully and commit to its role in ensuring project success.

2) It protects the project from an uncontrolled change

Continuing to think of the baseline as a promise – once both the project manager and the approving body have made the promise about what the project should do and deliver, how and when, and there is a formalised process for how the promise can be changed, the project is better protected from uncontrolled change.

The baseline gives visibility to what has been agreed upon for the project and therefore gives something very tangible to compare against when potential changes are raised. This can empower the project manager and give them a way of saying “Thank you for suggesting this change, let’s check it against the baselines and then decide how to act on it” rather than committing to the change right away.

3) It supports planning and control at the portfolio level

If an organisation established the practice of baselining across a portfolio and each project plans to sufficient detail to be able to baseline this creates a very good starting point for the organisation to be able to view and control timelines across the portfolio, and this, in turn, enables better forward planning and resource management.

Control timelines in Project Baselines

4) It gives meaning to progress reports

You have probably seen reports or news stories that mention a statistic or other “we are halfway” or “50% of work has been completed” etc. The demeanour of the person reporting will often indicate if they think the statistic is good or bad, but we do not have anything objective to compare to. UNLESS, that is – we have a baseline!

The baseline will tell us what should have been achieved and when. It makes it possible to look at a baselined plan and say “by this date, I should have achieved X, or I should be 25% done etc”.

The baseline, therefore, gives meaning to statements such as “I am 25% done” because it will tell us if we should be 25% done at this point, or if we should be 20%, 30 % etc.

Does the baseline, once set, stay the same throughout the project?

Let’s stick to thinking of the baseline as a promise. Say you promised your buddy to go to their house at 12 to help them with some important work. 12 o’clock is your baseline.  At 9am your kitchen sink springs a leak and you have to call a plumber, wait for them to show up etc. There is no way you can make it to your friend’s house by 12 o’clock.

What do you do?

Some people might just let it be, thinking “I’ll get there when I get there” and say nothing to their friend. This has the side effect that they are not managing our friend’s expectations and therefore they do not enable the friend to make other arrangements (perhaps there is another friend who could help?) or move things around (maybe they can do another task at 12 while they wait?).

The more reasonable thing to do is therefore to let the friend know we will be late and update our promise. “Something happened that is out of my control, it has set me back 2 hours so I will be at your house at 2pm”. 2pm, therefore, becomes the new baseline.

In a project, we have to do the same thing. Things will happen that are outside our control that might make it impossible to deliver to the original baselines. If we ignore that a few things happen:

  • On paper, we are still committed to delivering to the previous baseline o for all intents and purposes the rest of the organisation and stakeholders believe we will still deliver as promised
  • Our status reports (which should report progress against the baselines) will show that we are behind schedule/ over budget every month and therefore the value of the reports will be diluted over time
  • The organisation is not able to make realistic plans outside the project. For example: lining up resources to receive the output at the project end, re-deploying team members to other projects, or investing in other initiatives

So there has to be a practice of baselining in the first place, and then there has to be a robust process for re-baselining, i.e how the baseline is reviewed and updated to reflect changing conditions for the project.

Of course; just like with any other kind of promise – if you need to change the baseline it is important that you do not do so willy-nilly. It is possible (and necessary) to re-baseline, but it must be done through a formal process with the right level of decision making – this is where your change control comes in!

Want to learn more about baselines? Why not check out our resources on how to manage baselines in Project Online and Project for the Web.