This is good information but most of it is not actionable for the people building (I suppose it’s more a guide for the people who “threw it over the wall” this time).
The one that is actionable seems like it could be interpreted wrong to me…
“Breaking all the work down to the smallest details to arrive at a better estimate means you will deliver the project later than if you hadn’t done that.”
That may be true for estimates, but I seem to be most successful working in tiny pieces.
That said, I believe you can hit a date or you can hit a feature set, but you cannot do both (a slight modification on the saying that also adds money to the mix). Throwing additional money at a problem doesn’t seem to scale very well, in my experience.
It’s almost always best to hit a date and release what you’ve got. Hitting a feature set can drag and drag. In this articles case for more than a year.
Breaking huge tasks up is obviously necessary to make any real progress, regardless of whether you're trying to estimate anything - even if it was my job as an individual to do the whole huge task myself I'd want it in digestible chunks that I could feel I was making progress with, but more realistically it's going to be split between several developers anyway. Determining how to do that decomposition into subtasks that are genuinely independent (and ideally can be worked on in parallel) is obviously a key challenge of large-scale software development, and there almost never no "right" answers as to the best way of doing so.
Interestingly if I've noticed anything is that once you split a huge task up in little ones and give each of those estimates, the total is often far bigger than you might have considered for the original task. And is more likely to be closer to the mark.
Although it wasn't explicitly prescribed, one action that was taken was quickly delivering some truth to the stakeholders. The customer was informed the original schedule wasn't possible and given an alternative (more realistic) timeline.
I imagine many teams won't have that access or flexibility, so delivering truth may be first going back internal to the company and giving them a schedule, (and not just saying the original schedule won't work which in his story only elicited, "make it work").
The one that is actionable seems like it could be interpreted wrong to me…
“Breaking all the work down to the smallest details to arrive at a better estimate means you will deliver the project later than if you hadn’t done that.”
That may be true for estimates, but I seem to be most successful working in tiny pieces.
That said, I believe you can hit a date or you can hit a feature set, but you cannot do both (a slight modification on the saying that also adds money to the mix). Throwing additional money at a problem doesn’t seem to scale very well, in my experience.
It’s almost always best to hit a date and release what you’ve got. Hitting a feature set can drag and drag. In this articles case for more than a year.