~ By Kenneth Darter
The baseline of a schedule is a set point in time that allows everyone involved in the project to look back and see the baseline. If the project's going well or ahead of schedule, you might be glad to show off the baseline. Other times, you may want to hide the baseline under a rock or bury it somewhere in the woods behind the break room.
Love it or hate it, though, it's an essential element of project execution - at least for any project you want to end well.
Setting the baseline and monitoring the project against the baseline may, at times, seem like you're trying to hit a moving target. A client often finds scope they missed or tells you that everyone is going to be on vacation next week the day or the hour after you hit save on the schedule baseline.
While this might leave you pulling out your hair and silently screaming in your mind, the target is still the target. In order to measure and execute the project, you must have a good baseline for the schedule.
The initial baseline of the project schedule should take place early on in the project lifecycle. It may be tempting to delay as much as possible. You might want time to gather more information. You might want time to facilitate more discussions about the scope or the risk plan, or to do whatever other item seems important.
Ignore the temptation. Determining the initial baseline of the schedule is a vital necessity. Without this baseline, the project cannot start measuring progress. It - and you - will simply be stumbling around trying to find footing.
The initial baseline gives you a point in time - a line in the sand - that lets you show the stakeholders and project team what the project lifecycle will look like based on the information you have.
Once you have the baseline, it's time to measure progress. The schedule should be updated with "actual" information on a regular basis. These "actual" updates will show when a task is started, how much progress is made, and when a task is finished.
As the project progresses, the schedule should also be capturing who's working on which tasks and how the overall project is progressing. This information means you should be able to quickly see which tasks are falling behind, which tasks are estimated incorrectly and which tasks are scheduled incorrectly.
A project's success hinges on capturing this information. It will identify failure points and identify what you need to change, from a scheduling perspective, in order to overcome the issues facing the project.
Once you have the baseline plan and you're carefully tracking the activities of the project team, the baseline, fairly quickly, becomes out of sync with what's actually going on. It may even be that tasks are slipping from their planned dates. Now is the time to evaluate whether a change in the baseline is needed.
You should be asking key questions at this point. How are these slippages going to affect the overall project? What can be done in order to make sure successor tasks are completed based on the original baseline schedule?
Whatever is going to be done should be documented in the schedule, with consideration given to a new baseline schedule.
If the baseline needs to be changed, the project manager must gain consensus on the changes before moving forward. Some team members will have input into the revised schedule. The client or customer should also be consulted, in addition to the leadership of the project.
Ultimately, all those involved should understand why the schedule is being revised. They should understand not only how it affects their jobs, but also how it will impact the overall project. This consensus should lead to renewed energy and an understanding of what needs to be done for the project to succeed.
From the initial baseline through to project end, the baseline might be a moving target - but it's one you need to hit the mark on every time, no matter how many times it shifts throughout the project lifecycle.
What about our readers? How do you make sure you hit your project baseline even when it's a moving target? Let's discuss.