About Johanna Rothman

Johanna consults, speaks, and writes about managing product development. She helps managers and leaders do reasonable things that work. You can read more of her writings at jrothman.com.

Estimation and the Sunk Cost Fallacy

I’m not a fan of using schedule or cost estimate as a way to value the projects in your project portfolio. If you do, you are likely to miss the potentially transformative projects or programs.

In Manage Your Project Portfolio, I have an entire chapter devoted to ways to evaluate your project portfolio: business value points (not story points), waste, risk, to name just three. I wrote about cost of delay on this blog a while ago.

Last night, I heard Jutta Eckstein give a talk about Beyond Budgeting. That talk was the genesis for our Agile 2014 workshop, Diving for Hidden Treasures: Finding the Real Value in Your Project Portfolio.

Last night, I realized something while Jutta was speaking about estimation and sunk cost. One of the attendees asked about estimation. A paraphrase of that question is, “How can we start if we don’t know how long it will take?”

The projects that are worth doing have risk and are complex. What do you know about these projects? You can’t predict them. You cannot know how long they will take.

Remember the post Why Cost is the Wrong Question for Evaluating the Projects in Your Project Portfolio? If you don’t do the risky projects, if you only do the safe projects, you might maximize short-term gains. You lose the long-term market share, because you don’t do the risky projects.

Many managers find themselves in this position. The Operations committee or the PMO or “someone in charge” wants an estimate of the budget or when this project will be done. You provide a 3-point estimate: optimistic, realistic, and pessimistic estimate. Or, you provide an estimate with a percent confidence. (You have read Essays on Estimation.)

They don’t like that estimate, so they take the optimistic estimate, or they remove the percent confidence. That’s the first date you can’t prove you can’t make the project.

Never mind that the estimate is a guess. Never mind that you had caveats. Never mind that you had assumptions. Your estimate is now a commitment.

That date arrives. You are not done. You are in a variant of the 90% done schedule game. Why? Because you had an estimate. If you did not re-estimate, and update your estimate. Even if you did, your “in charge” people might not have wanted to hear your updated estimate.

Now, you might be in the sunk cost fallacy. The sunk cost fallacy says, “We have spent so much money on this, we may as well finish it. We can’t recover that cost. Our estimate says we only have xx much left to go.”

The difference between evaluating the project portfolio on value and estimates is that when you look at the business value, you ask this question first:

Should we do this project at all?

You always ask that question. It’s the zeroth question. Even if the project has been proceeding for a year. Because sunk cost doesn’t matter. You still have to support the system after you release it. Repeat that sentence: you still have to support the system after you release it.

If you evaluate the project portfolio based on estimates, you don’t ask the “Should we” question. You ask about the estimates. You don’t ask about follow-on after the release. You don’t go meta, which is the point of the question.

Sunk cost will catch you every time. Can you avoid the sunk cost fallacy? Of course. Do estimates cause the sunk cost fallacy? Of course not. They contribute to it.

In my experience, you are more likely to be caught by the sunk cost fallacy if you use estimation, because you are less likely to go meta on the value of your projects.

Is it okay to know if this project is bigger than a bread box? Of course. Should you use those estimates as a way to hold a project’s commitment to dates? No. Not if you want to work in an agile way and update the backlog as you work through iteration or flow the work. See Trust, Agile Program Management, & Being Effective for why you want to vary the backlog.

If you use estimates as a way to evaluate the projects in your project portfolio, beware of the sunk cost fallacy. You would be better off to ask, “How much value does this project have for us, compared to the other projects we have to do?”

 

Related Whitepaper:

The Principles Of Project Management

Learn how you can deliver projects on time and on budget, again and again.

Every project you manage will be unique. Scope, budgets, team dynamics, and timeframes will differ. As a project manager, the most important factor in achieving project success will be your understanding of The Principles Of Project Management. This book will show you that project management isn't rocket science.

Get it Now!  

Leave a Reply


+ three = 11



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books