It's been several years since my colleague put this post together, but I think for us it's proven to be a very constructive framework for talking to clients.
It's probably worth calling out that we are, specifically, outside contractors providing estimates for clients --- usually clients at the start of their software development journey. I think a lot of our framework holds for developers working on in-house engineering teams, but there are bound to be some differences.
That said, I'll be curious to read your post whenever it goes up. Namely because I don't know what the conclusion of your comment is. Whether it's as a vendor or as an engineer on staff, estimates are a hard requirement of software development. Most stakeholders are not developers, and you can only educate the recipients of your estimates so much on the nuances of what is and isn't hard to accommodate. I don't really disagree with any of your assertions --- but isn't the re-evaluation process simply... more estimation? Aren't accounting for project risks --- like which developer is going to pick up the task, what requirements are likely or unlikely to change --- part of producing a quality estimate?
Communicating expectations is hard, and to me, one of the defining lines between junior and senior developers is the ability to clearly account for expected risks, and identify plausible but unlikely risks, and to incorporate mitigation into the plan of attack.
I agree, and in general I am very pro-estimates (they switch your team from cooperative scheduling to preemptive scheduling, and they’re an important tool for managing the chaos of development), but the statement “we expect this project to take eight weeks, but it could take 24 weeks in the worst case” is one I would be very loathe to make.
Granted, I’m coming from a B2B startup rather than a consultancy, so I was working with a mixture of internal (product, sales, support) and external (customers) stakeholders. The perspective I would try to give people, though, was this:
If we discover a bomb partway through the project (oops, groups are limited to 100 members in this auth system, so we will need to find a new system and migrate or else not support groups) then 8 weeks will no longer be enough, but maybe neither is 24. The right thing for us to do in that situation, IMO, is go back to the stakeholders and align on a new plan. Maybe groups will come in v2, or some groups will work and some won’t, or maybe we do the migration and add it to the estimate, or whatever. One shouldn’t use the 16 buffer weeks between 8 and 24 to sneak in a backend migration (which itself might be a 16-week project, or might not), but to pause and re-align on a plan everyone likes.
When I was giving estimates, I would try to frame them as “we’ll spend eight weeks trying to accomplish this list of things. If we discover an issue that prevents us from finishing the list for any reason, we’ll come back to you as early as possible with some alternative proposals and re-assess”. Sometimes people felt that this meant we just weren’t willing to commit to our estimates, and this idea of “software development is chaotic” is what I would say, to explain that the issue wasn’t a lack of motivation, but an inescapable knowledge risk that needed to be managed.
Totally agree, and I think your example is a good one at demonstrating the importance of communicating an estimate across a range so that stakeholders aren’t caught off guard when something blows up, and also of distinguishing between the estimate and a commitment.
The process for what happens when something does blow up (we both know something will) is a good thing to establish, and as you say, re-communicate instead of trying to sneak in a fix.
It's probably worth calling out that we are, specifically, outside contractors providing estimates for clients --- usually clients at the start of their software development journey. I think a lot of our framework holds for developers working on in-house engineering teams, but there are bound to be some differences.
That said, I'll be curious to read your post whenever it goes up. Namely because I don't know what the conclusion of your comment is. Whether it's as a vendor or as an engineer on staff, estimates are a hard requirement of software development. Most stakeholders are not developers, and you can only educate the recipients of your estimates so much on the nuances of what is and isn't hard to accommodate. I don't really disagree with any of your assertions --- but isn't the re-evaluation process simply... more estimation? Aren't accounting for project risks --- like which developer is going to pick up the task, what requirements are likely or unlikely to change --- part of producing a quality estimate?
Communicating expectations is hard, and to me, one of the defining lines between junior and senior developers is the ability to clearly account for expected risks, and identify plausible but unlikely risks, and to incorporate mitigation into the plan of attack.