Hello there! Have you ever had to do a re-baselining of project status? That usually happens when a project is delayed or external conditions have changed so much that the original timeline is no longer feasible.
Many people who do the re-baseline ask me whether it’s necessary to keep a copy of the original timeline, or just overwrite it. Others ask if they should just show the new timeline as an “extension” of the old timeline.
In this article, I want to provide you with 4 tips for doing a re-baseline of project status. In general, if you’re doing a re-baseline, you should do five things:
- Do You Need To Re-Baseline?
- Check with Your Sponsors First
- Re-Baseline The Project
- Keep The Old Project Timeline Handy
- Document Lessons Learnt
Let’s look at each of these in turn.
1. Do You Need To Re-Baseline?
The first thing you should do is to ask yourself a fundamental question – do you even need to re-baseline the project? Many project managers I know are trigger happy and say that because stakeholders have changed, or the vendor has screwed up, then perhaps it’s best to do a re-baseline.
?Before you do that, I suggest that you look at whether there are ways to “salvage” the old timeline. Perhaps some activities can be run in parallel or more resources added to ensure the old timeline still holds.
For example, in one of my projects, a report development task was missed out in the original project plan. There were 20 reports to develop that we failed to include in the timeline!
Now, instead of throwing away the old timeline, I explored with my stakeholders if there was a way to overcome the problem. And we did find a solution – we asked some three resources from IT to help develop the reports as they were not assigned to any active projects.
That saved us from having to re-baseline and we even went live earlier than expected!
2. Check With Your Sponsors First
One of the key things you need to do before re-baselining your project is to check with your sponsors first. Your sponsor MUST know about any material change you’re doing to the project.
Very often, I find junior PMs withholding information from their stakeholders. They think that if there’s a delay of, say, two weeks in a project, they should just “re-baseline” and ignore the old project plan. And also not trouble their stakeholders.
I don’t think that’s a good idea. Many stakeholders are very sharp. They know the deadline of a project by heart. If you re-baseline the plan without their knowledge, even if it’s only for two weeks, they will know.
And you’ll have a hard time explaining why the latest project plan differs from what they had seen previously. The correct way to approach this is to discuss with your stakeholder, get his or her buy-in on the two week delay, THEN update the project plan.
That way, all communication channels are kept open and your stakeholder will even appreciate that you highlighted such a delay to him or her.
3. Keep The Old Project Timeline Handy
Before doing your re-baseline of the project plan, make sure you keep the old project timeline archived somewhere. You can’t be sure someone won’t come and ask what the original timeline was.
I always store a copy of my old project plans in an external hard disk drive.
Some of you may be aware that software like Microsoft Project can help you “baseline” a project (there’s a function in the menu to do that). Once done, the “actuals”, i.e. the date you actually finish a task is recorded by Microsoft Project.
Then, if the date the task is completed is past the “baseline” due date that has been saved, you’ll see a red line in the Gantt Chart view showing the task as delayed. That’s quite useful to apply when monitoring project progress.
Take note, however, that this “baseline” function in Microsoft Project is a little different from the “re-baseline” we’re talking about in this article.
When we mention re-baseline in this article, we mean totally wiping off the original project plan and replacing it with a new (and hopefully more realistic) timeline.
The “baseline” function in Microsoft Project is more for tracking actual project progress against an original timeline. There’s a difference there.
4. Re-Baseline The Project
When you do a re-baseline of the project, what you want to do is to go into the Microsoft Project Plan file and save a new version of the plan. Then, just adjust the due dates of the relevant tasks and move the timeline out by 2 weeks.
Make sure you record in a journal or decisions log somewhere why you added 2 weeks to the timeline, so there is an audit trail.
5. Document Lessons Learnt
One of the things I learnt in my experience as a PM is to document lessons learnt. It’s easy to forget this when you’re in the midst of a project crisis, etc.
However, I think it’s tremendously useful to you (and to other project managers in your company) that you record down lessons learnt as a project progresses.
Note that I said you record lessons while a project progresses. If you leave the lessons learnt list to the end of your project, chances are that you’ll have clean forgotten about what you learnt in the project by then.
So my advice is to record down lessons learnt as the project progresses. Then, when you do a re-baseline of the project timeline, you should already have a list of lessons learnt, which you can archive away safe and sound.
Don’t wait until you’re scrapping a project timeline and re-baselining it to document lessons learnt. Do it all throughout the project.
Wrapping Up …
I hope the above has helped you understand a lot more about how you can re-baseline project status. You should always check if you indeed need to re-baseline and get agreement from your sponsors before you do the re-baseline.
And hopefully, you only need to do a re-baseline once – if you re-baseline too many times, that’s a sign that the project is not going well at all, and you risk being fired!
So bear the above tips in mind when you’re next running a project. That’s all I have for now – until next time, have fun running that project!