Updated: May 11
Here’s a question we recently received from a Project Manager:
“We've created a project schedule with estimated start dates and actual start dates. Our client's scheduler keeps sending it back to us saying we need to rebaseline our planned dates if we miss them. I argued that doing that makes them irrelevant. What is your opinion?”
And here’s the answer from the PM-Pros:
“This is very common problem where your good PM practice and how the client wants the project run can clash. The best answer is to refer them to the Schedule Management Plan that they signed off on agreeing to the practices you would you use to manage their project schedule. If you don’t have a Schedule Management Plan that addresses the practice of how to manage planned and actual dates, then you can certainly run into this problem. Best practice would be to define all your "How to's" for each area of your project, like the schedule, and get agreement from the client up front. But, when you run into one of these situations where something is not covered in an agreed-to plan, you must discuss it with them to establish a new PM practice everyone agrees to moving forward.
I would ask them why they feel that rebaselining the planned dates is a good idea? It's hard for me to provide perspective on what to do without understanding the client's needs or how they understand the concept of schedule management.
Ideally, planned dates should be kept as the original baseline, so that you can capture schedule variances once you enter the actual dates, and work to understand why the variances occurred. That may turn into lessons learned that you could use later in this or other projects. If you change the original baselined dates, then you eventually forget about the variances that did occur, because you aren't tracking them anymore, and you are destined to make the same mistakes without being able to incorporate the lessons learned in future decisions.
If you are using MS Project, you can actually set and save multiple baselines. So, what I've done on my projects is keep the original dates and label them as Baseline 1, and then when we determine the dates need to be changed, I just added another set of dates and labeled it Baseline 2. So, I kept the original dates, and captured all changes to the planned dates as a new Baseline version. That allows you to track variances against whichever Baseline is the current one, and still be able to go back and see how far off you are from the original plan of Baseline 1.”
We love discussing your project questions and helping to apply good standard practice to non-standard real-world problems! Please submit your questions to us at email@example.com!