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?”
