5 ms·

The classic cognitive trick--people, unless specifically trained not to, will always estimate the best possible scenario, even if past experience has told them

The classic cognitive trick--people, unless specifically trained not to, will always estimate the best possible scenario, even if past experience has told them that the best possible scenario never happens. I'm dealing with this at my company right now. Our clients, and even our internal teams, will always refuse to estimate according to our past behavior. Us: "We estimate your build will be functional in prod in five months." Client: "Unacceptable. That's way too long. We need it in three." Us: "Okay, we technically can do that, but that relies on a big internal release that we think is risky to base estimates on." Client: "All I'm hearing is that you can do it in three." Then we get to three months and hit delays over and over again until finally, five months later, the build is functional in prod. The thing that really frustrates me is that when we deliver the initial estimate, the clients always refuse to accept our medium-case estimate, with the implication that they'll drop us as a vendor if we follow that. So we give them our best-case estimate, fail to hit it, and then they buy more from us anyway, complaining the entire time. Why don't we all just look at the past 10 builds we delivered for them, admit that the best-case never happens, and stop pretending like it's unacceptable to take longer? The point here is that they keep accepting it. Everyone complains, but we all keep selling and buying to and from each other. Let's just admit it's harder than we're saying to get software built and accept longer estimates, given that we're all going to keep selling and buying anyway.

wpietri 5y ago
Totally. In most places what people call "estimates" are just wishful thinking. And that client behavior you describe is what I think of as "Kirk-style management". An executive thinks that the way to get technical things done is to be demanding and shouty toward the technical person, insisting that the number given isn't good enough. Scotty's pathological response to the pathological situation was to lie his ass off about estimates: https://wiki.c2.com/?ScottyFactor https://wiki.c2.com/?ScottyFactor
- quacked 5y ago
  Thanks for that article--bookmarked.
mgkimsal 5y ago
> Why don't we all just look at the past 10 builds we delivered for them, admit that the best-case never happens, and stop pretending like it's unacceptable to take longer? The point here is that they keep accepting it. It's theater, mostly. I think some people think they have to do this. How did they get you to keep delivering when you did? It was their threats/complaining! If they stopped doing that... there's no telling how long it might take you to deliver. Given that every project you've called at 4 months has delivered in ... 4 months, for the past 7 years... your estimating/delivery ability is still tangential to their managing of the delivery by regular barrages of threats, complaints and haranguing.
- wpietri 5y ago
  Wow, great insight. It reminds me of the dynamics with walking down the sidewalk past a dog. If I walk too close to his yard, he decides I'm a threat. He barks! I walk away. It's easy for him to do post hoc ergo propter hoc and conclude that his barking chased away a dangerous threat. In reality I didn't do a thing different, but his lesson is that barking works!
- quacked 5y ago
  It's a great point, and one that could be rectified by their teams actually having standards. Threats can't be empty. "Deliver early, we'll give you a bonus. Deliver on-time, we'll pay. Deliver late, we'll hold you accountable and pay less according to this attachment. Deliver really late, and you get a strike. Three strikes and we drop you." Of course, that would require backbone, fortitude, accurate forecasting, integrity, and management support.
ianmcgowan 5y ago
I've had arguments with PM's about this. After a few years of doing similar projects you can sort of squint sideways at something similar and have a gut feel (if it's completely different from anything ever done, that doesn't work of course). But every PMP (tm) certified PM I've worked with thinks if you can just break the project into granular chunks, estimate those, then sum the estimates, there's your final deadline. The fact that it never works doesn't dissuade them on the next project is the depressing part, it's all just theatre for the execs.
myohmy 5y ago
All I'm hearing is that the client signed the contract, which means you won. Whether your company makes money on the change order is a matter for your boss.

wpietri 5y ago

Totally. In most places what people call "estimates" are just wishful thinking. And that client behavior you describe is what I think of as "Kirk-style management". An executive thinks that the way to get technical things done is to be demanding and shouty toward the technical person, insisting that the number given isn't good enough. Scotty's pathological response to the pathological situation was to lie his ass off about estimates: https://wiki.c2.com/?ScottyFactor https://wiki.c2.com/?ScottyFactor

quacked 5y ago
Thanks for that article--bookmarked.

mgkimsal 5y ago

> Why don't we all just look at the past 10 builds we delivered for them, admit that the best-case never happens, and stop pretending like it's unacceptable to take longer? The point here is that they keep accepting it. It's theater, mostly. I think some people think they have to do this. How did they get you to keep delivering when you did? It was their threats/complaining! If they stopped doing that... there's no telling how long it might take you to deliver. Given that every project you've called at 4 months has delivered in ... 4 months, for the past 7 years... your estimating/delivery ability is still tangential to their managing of the delivery by regular barrages of threats, complaints and haranguing.

wpietri 5y ago
Wow, great insight. It reminds me of the dynamics with walking down the sidewalk past a dog. If I walk too close to his yard, he decides I'm a threat. He barks! I walk away. It's easy for him to do post hoc ergo propter hoc and conclude that his barking chased away a dangerous threat. In reality I didn't do a thing different, but his lesson is that barking works!
quacked 5y ago
It's a great point, and one that could be rectified by their teams actually having standards. Threats can't be empty. "Deliver early, we'll give you a bonus. Deliver on-time, we'll pay. Deliver late, we'll hold you accountable and pay less according to this attachment. Deliver really late, and you get a strike. Three strikes and we drop you." Of course, that would require backbone, fortitude, accurate forecasting, integrity, and management support.

ianmcgowan 5y ago

I've had arguments with PM's about this. After a few years of doing similar projects you can sort of squint sideways at something similar and have a gut feel (if it's completely different from anything ever done, that doesn't work of course). But every PMP (tm) certified PM I've worked with thinks if you can just break the project into granular chunks, estimate those, then sum the estimates, there's your final deadline. The fact that it never works doesn't dissuade them on the next project is the depressing part, it's all just theatre for the execs.

myohmy 5y ago

All I'm hearing is that the client signed the contract, which means you won. Whether your company makes money on the change order is a matter for your boss.