The work is never just “the work” (2022)

Also, if you don't know WHO will build it, and their capabilities, any accuracy is impossible. When people approach the limit of their abilities, time spent on tasks goes up exponentially.

However, if someone has a very good understanding of what they're supposed to build, the team that will build it, reasonble estimates can often be produced quite quickly. Obviously, there can be risk factors, such as customers or managers with unreasonable expectations, but those can typically be managed by experienced teams.

Anyway, raw estimates should never be seen as budgets. Budgets should be much larger, especially if they can be kept hidden from the developers, since budgets need to take all sorts of risks into account. But most team if they know what the budget is (and it's big enough), may tend to relax a bit too much early on in a project.

Most software projects go a bit (or sometimes quite a lot) over estimates. Which is often fine. The estimate may still have been a useful exercise, in that it forced someone to think about most details of the deliverable early on, and also provided something to track progress against.

I did not expect that plot twist to your story. Sounds about reasonable. Proper project management takes alot of time and need to engage the actual implementors.

I've seen it done, and it's more than double. You have to have most of the work done before you deliver the estimate. The thing is, you have to deliver an estimate that is at least as long as the time you spent producing the estimate, but you're already mostly done, so towards the end of a project there's a lot of gold plating and general screwing around. It's a silly way to work.

And everybody knows what's going on, because people talk. You can't keep it secret. You can only do it as long as upper management thinks it benefits the company. The customer-facing side of the business (sales, customer success) makes a very strong case that faster delivery means happier customers, and more optimistic timelines mean more sales. As much as accurate estimation is an eternal management dream, there's not much benefit to it other than a little bit of dubiously valuable trust and credibility with customers. The idea that "if only we could estimate accurately, we could execute grand strategic visions" is mostly bullshit. You're slowing yourself down, and the only thing you get out of it is that engineering management gets to pat themselves on the back for hitting estimates.

Microsoft Press' "Software Estimation: Demystifying the Black Art" is a good deep dive into the subject.

Found it via a talk by Jakob Persson at Drupalcon many years ago, he recommended a template-based spreadsheet approach where you estimate a project by splitting it into components and giving each a "confidence" level from 1-5, then adding fixed padding for various items like project management (20%), deployment (5%), buffer for unforeseen problems (20%) etc that essentially came down to "2-3x the initial estimate" but with some calculations to back it up, and made estimations systematically easy.

His slides are here: https://www.slideshare.net/jakobpersson/the-science-of-guess...

The sheet template is here: https://docs.google.com/spreadsheets/d/13MGHIxFOtbJ2Qxygc_Gx... - have used variations of it with great success for many years beyond when I shifted away from Drupal work.

Noting that his more recent blog articles now recommend a value-based pricing approach for the consulting model (which I agree with and also shifted to in my freelance days).

Good to see more writing on estimation for engineers, Agile's story points model is nice for teams doing the work, but in many kinds of work when you're running a team there's someone above you who signs the checks that wants to know what something's going to (approximately) cost before they sign off on it.