There is much debate over when, and even if, it’s appropriate to “re-baseline” a project.  For the purpose of this blog, I’ll define re-baselining as actions taken by the Project Manager, with the customer’s concurrence, that result in the elimination of previously accumulated earned value cost and/or schedule variances.  Some Project Managers use re-baselining as a common strategy, while others argue that Projects should never be re-baselined once execution has started.  In this blog I’ll offer my experience and opinions on the pros and cons of project re-baselining and some thoughts on how and when to implement them.

In my experience, the option to re-baseline must be a tool that is available in every Project Managers toolbox.  It is however a tool that must be used wisely and sparingly.  In some ways, it’s like declaring bankruptcy.  It’s an option that people and businesses must have available to them to enable survival in extreme financial situations.  However, the decision to declare bankruptcy has serious and lasting consequences and should not be taken lightly.

Earned value management process cost and schedule variance data provide valuable information to the Project Manager, the business, and the customer on the effectiveness and efficiency of project execution to the baseline plan. Variances can be created by actions, or lack of action by either the contractor, or customer.  Contractors create variances through poor estimating, poor performance, poor risk management, and poor resource management.  Customers can create variances by flowing down incomplete or unstable requirements, by adding new constraints, or through lack of timely decisions, work authorizations or contractual funding.

Poor contractor estimating, performance, risk or resource management is not a justification for earned value (EV) variance re-baselining.  Hiding the consequences of sins of the past may make the short-term metrics look better, but it offers no incentive or help in finding the causes of the variances and fixing them.  I understand that it’s frustrating for Project Managers and their teams to continue to carry and explain variances created by problems long-since fixed.  However, if those variances/problems were caused by the kinds of contractor execution inadequacies described above, then it’s important that that knowledge be carried through the full period of performance of the contract and used to inform others in similar situations.  In addition, the learning/knowledge expressed by the variance reports on the current contract must be captured in the historical databases and considered when planning, estimating and executing future projects.

On the other hand, variances created through the actions or lack of action by customers, should in most cases, be reasonable grounds for Project Managers to propose updates to the contract scope, schedule and cost baselines.  I have planned, proposed, negotiated and implemented such re-baseline proposals on a number of occasions.  In my experience, the customer viewed those proposals as both appropriate and helpful, because the action eliminated irrelevant, distracting and misleading variances that could hide new, real emerging execution issues and risks.

So, if you’re a Project Manager contemplating a contract re-baseline proposal request to your customer I recommend:

1. Take a hard look at you motivation.  Make sure it’s not for the purposes of a metric makeover that would hide execution failures, even if they were old failures that were found and fixed long ago.  You owe it to yourself, your team, your customer and future Project Managers, to be an honest knowledge broker.
2. Talk to your boss or internal project sponsor and state your case.  They’ll sometimes be reluctant because they want to hold your “feet to the fire” so to speak to improve performance and close the variance gap.  If you’ve done your homework and can show them case for the variance being customer driven you’ll likely be given the green light to approach the customer.
3. If you’ve convinced yourself that variances are customer driven, then start a conversation with your counter-part to explore the idea of a contract re-baseline and objectively evaluate the benefits and risks.  If you approach it correctly, they’ll most likely agree that a re-baseline is value-added for both parties.
4. Once everyone agrees to the idea of a re-baseline, take the time to put together a well-substantiated proposal.  Make it clear to the team that this is not an “earned value get-well” activity.  Clearly separate any execution inadequacy variance and continue to own and address fixing that.
5. Finally, after the customer has agreed to accept a re-baseline proposal and the guidelines under which it will be prepared, move out swiftly to make it happen.  The longer any real execution variance problems are obscured by the irrelevant variances, the bigger the risk to the project.