[humanrebar]

> ...customers that require pretty accurate (cost) estimates prior to even getting the contract.

If you require that accurate of an estimate, your business model cannot handle the risk of software development. Really, really wanting an accurate estimate does not make risk go away.

[ams6110]

That's not exactly true, but it means holding the customer to exactly what they asked for, and having a formal "change request" process for any deviations. The track record of that model of development is not one of successful on-time delivery, but it does seem to make some types of customers more comfortable, even if it shouldn't.

[HillRat]

Unfortunately, that doesn't change the fact that customers want estimates, and the more complex the project the more they need it for budgeting and scheduling purposes.

In the end, you have a few options for estimating:

1. Estimate the most optimistic scenario, knowing you'll end up using change requests and extensions to deliver (one of the worst options, but if you're responding to a proposal that's what the opposition is assuredly going to be doing);

2. Propose an initial phase to nail down requirements and deliver a schedule using traditional estimation tools (an easier sell if you're an internal team, tough if you're a vendor);

3. Use experience with similar projects to estimate, and then refine your assumptions with the client, using change orders to account for unexpected problems (roughly accurate to the degree of imported ambiguity, but now you have to risk going to war to get your change orders signed off on);

4. Use a top-down estimation model such as function points-based estimation to get in the ballpark, and then add buffer (and pray you aren't going to either lose money or blow the top off the client's budget levels -- or both);

5. Delphi the problem and get a bunch of developers and PMs to estimate the effort, then refine from there (useful for sanity checks, not useful as a real estimation process, yet one of the more common ways small shops build their numbers).

As you say, you can't make risk go away, you can only try to segregate it within your estimation. In my experience, clients really need stability in proposal numbers -- they're often willing to accept a significant embedded risk buffer in a proposal if it means they can limit unexpected costs. Conversely, you should also have a rough idea going into a project of what functionality can be cut and when so you can go/nogo those pieces when necessary.

[humanrebar]

> ...they're often willing to accept a significant embedded risk buffer in a proposal if it means they can limit unexpected costs.

So if they want 95% confidence in estimates, you need to pad the estimate a lot. It doesn't make risk go away. It just offloads risk onto the contractor.

That just means the contractor is assuming the risk of missing the 95% estimate. It also means the head of the contracting operation needs to be diligent about backing up the estimates of his employees. Or mitigating risk some other way (making sure each contract is a small fraction of the business, having enough cash to absorb risk, owning lots of other businesses, etc.).

Now, realistically, the risk is also absorbed by the developers in the form of unpaid overtime, stress, lost bonuses, and in other ways. That's just all the more reason for individual contributors to insist on honest estimates. Or find bosses that understand business models better and don't offload risk onto employees.

[] I understand that this is complicated and bosses don't typically mean to make employees miss bonuses and have terrible work/life balance. But to some degree it doesn't matter. Intentions don't make down payments on houses, make sure kids do their homework, or get us a full night of sleep.

[true_religion]

Estimates can be fairly accurate if they're made for software that's a composition of previously iterated work.

If someone asks for a login system with X,Y,Z and you've done that 1000 times, you can be fairly accurate in stating what it will take to do it 1001 times.

The issue is when a piece of software is custom, and there's no domain expertise available for the custom bit then you cannot accurate estimate how long it will take because the developers will be learning while doing.

[ams6110]

And some developers bring this on themselves. They could use the boring conservative technology that they know inside and out from the last project, or they could use something that's new and hot this month, which they have never done or have much less experience with (but is exciting).

Double whammy if it's an unfamiliar domain and a cutting-edge tech stack.

[Scarblac]

And it takes longer, so more billable hours.