One of the funnest tasks we have as project managers is getting estimates from developers. You know — because they’re so cooperative about it. To be fair, estimating is hard. Studies have shown that as a rule, we’re all pretty terrible at it. So it’s understandable why they would hesitate to provide something they’re pretty sure will be wrong.

In order to accommodate their concerns, I switched to the the three-point estimation technique. This is where you estimate the best-case, worst-case, and most likely scenarios and do a bit of math to come up with a <sarcasm>perfectly accurate</sarcasm> estimate.

When I presented this new approach to the team, one developer pulled out our planning poker deck and said, “This will be easy — I only need three cards.” He then proceeded to tell me that his best-case estimate for anything was “0” because we might be able to buy something off the shelf or re-use existing code. Done. His worst-case estimate was “infinity” because maybe what we were trying to do would prove impossible and we’d spend eternity working fruitlessly. And for anything in between (most likely case), he’d just use the question mark because, well, “who knows?”

I recently told this story to my incredibly wise and outspoken friend Dave Prior, who had experienced the same situation himself. So I asked him why we all seem to end up in this place. His enlightening response:

The issue is trust.

The developer in the example above doesn’t trust the PM… and given the history of how we (as PMs) have handled things, they’re probably right not to. When anyone who will be working on the project agrees to take on a task, and provide an estimate, they are taking a guess as to how long it will take to do something they have a marginal understanding of. But, we push, and they offer a guess. Then we collect all the imperfect guesses from all the people on the team who did not have enough information to start with. We wrap all these guesses up into a giant house of cards that we call a project plan. We then deliver the house of cards to people who look at the house of cards, see all the detail that has gone into it and accept it as a real house… or the reality they can expect to unfold before their eyes. Which never happens.

People begin working, they realize their estimates were off because they didn’t have enough information. We push back and try to find ways to get them “back on track.” They have learned over time that when they give us an estimate, they are really just handing us a stick to hit them with. So, the resistance to estimates… it makes total sense to me. We’ve been (historically) irresponsible with the trust placed in us.

But there is another side to this. Each of us, on an individual level plans stuff. We guess how long stuff will take — from cooking spaghetti to driving to work during rush hour. We guess, and we are wrong and we internally reconsider our guess next time to make sure we are accounting for the variables we know of that may come into play. If we want people to be okay with giving estimates, we need to first make it okay for those estimates to be wrong. If they know they don’t have to fear being wrong, and they know they’ll be given the chance to learn and improve… then the argument for not producing an estimates crumbles a bit.

Easy, right? Give people the freedom to be wrong (because they will be) and slowly win back their trust. But then we have to take that up the chain a bit. Will your bosses and stakeholders accept this? How can we communicate the inaccuracy of our project plans without looking incompetent? Sounds like I might need another chat with Dave…

Companion Content:

book: Software Estimation by Steve McConnell
link: ‘No Estimates’ in Action
song: Sparks – I Predict