Knowing When to Re-baseline Your Project

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.


About donmcalister

I retired at the end of 2011, after a 39 year career in the Aerospace industry as a Propulsion Engineer, Engineering Manager and Program Manager. My professional interests and expertise are in the areas of Program, Risk and Knowledge Management. I'm passionate about life-long learning in a wide variety of topics and I'm committed to sharing my knowledge and ideas with those who are interested. I'm an Aerospace Industry Consultant. I serve my community as a Rotarian. My hobby is playing as a jazz keyboard.
This entry was posted in Program & Knowledge Management and tagged . Bookmark the permalink.

5 Responses to Knowing When to Re-baseline Your Project

  1. Tino Antonini says:

    Often this dilemma is more moral then professional issue.
    If PM with his team can stick to the plan then its stupid to expose his project to this cosmetic makeover and in a fact to risk to lose the job.
    If PM and his team cant deliver then its in best interest of the client to be informed about situation whoever might be responsible for overrun. In this case realistic analysis should be made and client should be involved in making clean cut considering that he deserves to know what risks project is facing.

  2. kevtr6 says:

    All good points Don and similar to my experience. It really should be about managing and radiating project accurate project information from a point of the discussion and going forward. As you and Tino point out, it is about the project plans for moving forward and being set up for success. There is always some precision allowance in every execution, it is only wise to rebaseline when there is agreement that the original plan is too much removed from the work remaining in the project. Thanks for sharing.

    To your continued success and happiness.

  3. tonyadams1969 says:

    I don’t have an issue with rebaselining, if it is used correctly…by which I mean with the support of Sponsor and Steering Committee. On large, complex projects, this technique can be effectively used as a Communication/Stakeholder Management technique.

    I must disagree with Tino.

    Large Projects that use a staged funding/gateway approach will often establish a meta-budget/schedule and then iteratively establish detailed plans for the next funding/gateway period.
     In such cases, funding may need to be re-baselined as detailed plans evolve and gateways are successfully negotiated.  This is appropriate where the Program/Portfolio takes an increasingly detailed view of the Project as plans develop, work progresses and expectations around funding, schedule and resource contingency progressively change.

    Further, a Portfolio approach may well require that the Project re-baseline at defined times as pipeline funding requirements are balanced against portfolio capacity, projected run rate etc.

    Tanks for the post, I certainly enjoyed it!

  4. AJ says:

    Considering you believe estimation accuracy is truly a function of percentage of design completion then re-baselining is inevitable without very mature risk and contingency funding.

  5. VJBaskar says:

    Nice article. I am conflicted on how to create a baseline for a project. Which of the following scenarios would be considered a “best practice” for creating a project baseline in which to measure progress and get some schedule-related EVM metrics? Is Primavera Really usefull for this process, What you did was exactly what I suggested???

Leave a Reply to AJ Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s