Baseline your plan

You know that the plan you put together at the start of the project is going to bear little resemblance to the same document at the end. So what is the point of doing a plan at the early stages of a project at all? Taking a snapshot at the beginning of your project is known as a baseline and can prove to be useful later on for many reasons.

B A S E L I N I N G C O H E R E N C E

David Schmaltz’s position as founder of strategic project management con­

sultancy, True North, has seen him work on many pressurized projects. One assignment, a hardware and software project for a high-technology firm, found him working with, in his words, ‘a dizzyingly broad community of contributors, suppliers, layers of arguing executive management, and cus­

tomers’. With a seven-figure budget and a global team numbering several dozen, significant effort was put into the planning in the early days.

The team covered a wall with sticky notes to create their plan to design and deliver the blueprint for a laptop computer. ‘We were baselining coherence, which allowed everyone in the community to think about the project in a similar way, whatever the plan and schedule might say.’ Schmaltz is clear that the project’s original plan was the result of this effort to ensure everyone involved was talking about the same thing – or, where they were not, that this potential contradiction was recognized.

A detailed project baseline was drawn up only for the foreseeable future, with the rest of the nine-month plan sketched in behind. The effect of the planning meetings early on ensured that everyone knew what was required to deliver the project successfully and also who would be responsible for each critical delivery. ‘Most of the planning energy was focused upon creating relationships between the people involved,’ Schmaltz says. ‘We wanted to identify where critical relationships might exist and provide an opportunity for the people involved in these relationships to get to know each other, to get familiar with their working preferences, and to work together to achieve initial understanding and agreement.’ He adds: ‘By the end of the planning, we were reasonably confident that everyone in the room was on a similar page. And where people were on different pages, we understood that too.

Everyone in the room, and, later, everyone in the community, was clear that we had not created the roadmap we would follow to a successful conclusion.’

Schmaltz firmly believes that the level of change involved in projects means they should not be a scripted performance but a fluid conversation between the stakeholders. ‘The greatest danger any project faces at the beginning is mistaking unknowables for knowables, so we spent time identifying con­

tradictions within the plan and almost no time attempting to resolve them into knowables,’ he says. The team did not see any value in attempting to

Baseline your plan

plan activities they did not as yet have all the details about. However, for the purpose of satisfying the funding authorities, they prepared a summary including a list of proposed milestones with a caveat stating these would probably change, given the project’s environment. In the event, the project stretched to 12 months.

The baseline plan was never formally captured and used to track changes, but in practice much of it was not modified. The sticky notes were simply moved around as soon as a member of the team had better information about how a task would be achieved. ‘This made the baseline a powerful medium for communication, rather than something that measured the goodness or badness of the effort,’ Schmaltz explains.

The focus of the project was not on picking up and focusing on why the hardware was not delivered to the original plan, but on the end goal itself.

Schmaltz was fortunate to be able to enthuse the senior management with this approach, but he acknowledges it was helped by the project’s strong business case. ‘I have not seen many projects that have been successfully managed by measuring deviation from initial baseline. Focusing on why it didn’t turn out as planned can at best be a distraction from achieving the strategic purpose of the effort. This project, and many others like it, stayed focused on the prize.’

Setting a project baseline means taking a snapshot in time of your schedule.

At the beginning of the project, all things being equal, this is how long you think the work will take. It’s a target, a frozen view of a schedule, which will no doubt change as the project unfolds.

D E F I N I T I O N

Willie Herroelen and Roel Leus describe the baseline version of the schedule as ‘a basis for planning external activities such as material procurement, preventative maintenance and deliv­

ery of orders to external or internal customers. Baseline sched­

ules serve as a basis for communication and co-ordination with external entities in the company’s inbound and out­

bound supply chain.’⁷³ In another study by the pair, they explain that ‘booking’ personnel to work on the project is another reason to have a realistic and stable baseline sched­

ule.⁷⁴

Your baseline schedule should be approved by your sponsor. However, this is just the first step. Just because you have a signed-off, baselined schedule does not mean that it is now set in stone. It would be unrealistic to expect it not to change at all. If you have discussed and agreed a time tolerance with your sponsor, then it will not be necessary to go back for each tiny change

Project Management in the Real World

provided you are within your agreed tolerance. For more on tolerances, see Chapter 3.

H I N T

Make sure your baseline plan is linked to a particular ver­

sion of your project documents. If you’re going to baseline your plan, baseline your other documents too. Your scope statement, design and requirements documents should all be under version control (see Chapter 17), so associating the rel­

evant version to your baseline plan won’t be difficult. This is useful because updates to the schedule normally result from the change-management process. A new requirement, for example, will create a need to change the plans and have an impact on your schedule. When you look back during your post-project review, you will be able to see easily how your baseline schedule was adapted following other changes.

Your baseline schedule provides a useful tracking mechanism so you can see how much has changed, which will help you monitor accurately. There are mathematical models for predicting the impact of change on your sched­

ule,⁷⁵ but it is more likely that you will use your time tolerance, contingency, the risk-management process and common sense to accommodate changes to the schedule as your project progresses. The US Civil Engineering Research Foundation concluded in a study of Department of Energy projects that ‘a rigorous risk assessment of alternative solutions under various scenarios provides a means of raising the confidence level that can be placed in early estimat estimates’.⁷⁶ They also looked at rebaselining – that is, presenting a new, adapted (and normally longer) schedule to the sponsor and having that accepted and signed off as the new target timeline – and found that frequent rebaselining ‘masked the true state of some projects’. Rebaselining is possible for your projects, but always keep a copy of the original sched­

ule, however ‘wrong’ it has turned out to be. There are useful lessons to be learned from why the original schedule was so inaccurate, even if for project-reporting purposes you now report on progress against the new schedule.

This document will inform your post-project review and can be used to help improve estimating on projects in the future.

G O L D E N R U L E S

Get your schedule approved and baselined at the beginning of the project as it will help you book resources and monitor progress.