[badbanana]

Customer: What will this project cost? You: Five XL T-shirts.

Excuse the snark, but a lot of business decisions are made based on how much Project X will cost. You likely get paid based on time, so it's quite natural to gravitate toward time units - any intermediary unit is just an abstraction.

[ohthehugemanate]

Maybe you missed the part where I explain how PMs translate to time for business planning. Yes that is absolutely necessary.

And yes it is an abstraction, which is the whole point.

Human brains are extremely bad and inconsistent at estimating time, and much better at estimating effort. So you abstract and let them estimate in the terms they're better at. Not to mention, the abstraction means you average in unpredictable disruptions like illness, windows updates, and other events. Abstracted unit estimates are demonstrated to be much more accurate than (not-abstracted) time estimates.

[midasz]

People sell projects for a fixed price? How does that work? You either overpay a ton of underpay right?

And how would you even say what a project will cost? Projects change all the time, and there is no way to know the entire scope beforehand unless it's really really small. Otherwise you're just lying.

Genuinely how does this work?

[another-dave]

But you do this in the non-software world all the time — if you leave your car in for a service, you'll get charged £X base on it taking them Y amount of time. Some cars will take them ±10% but it balances out in the end.

Or if you're getting building work on your house, they'll caveat that it'll cost you £X, saving any unforeseen circumstances that arise (if you've asbestos in your attic, they're not going to stick to the original price and just eat the cost)

In consulting, most clients want a fixed cost for a fixed scope, with any deviations coming as change requests & billed accordingly. Generally people are hestitant to agree to an agile model unless you've already got a lot of trust built up.

[chasd00]

It's very touchy and all about the contract. The scope has to be very clearly defined as well as what an expansion of scope is and then what happens next. Basically, how the change order process works and what qualifies as requiring a change order. So, in a way, it's not literally fixed price. Or maybe "fixed price with an escape hatch" is a better term.

A sophisticated enough client can design a fixed-price deal that can completely devastate a software development firm if the guardrails are not in place. On the other hand, a sophisticated dev firm can design a fixed-price deal that will nickle and dime a client in perpetuity if the client doesn't recognize the trap.

Fixed-price is like handling dynamite, you have to know what you're doing.

[runlaszlorun]

Personally, I’ve never seen one go well though all of the projects have been relatively complex with no repeatability.

The vendor ends up losing money and the client gets a deal on paper but not in reality when you realize the corners that were cut to shove a product at the door.

You could generally go back and look at the emails on the project and see the exact point in time (often about 2/3 in) were the vendor realized they were losing money and started cutting whatever possible to not lose their shirt on the project.

I suppose that if projects were relatively straightforward like “we’re building you a wordpress site with X number of templates” one may have a chance at estimating upfront- but I’ve never worked on projects that predictability.

[sigstoat]

fixed cost projects either don’t change, or more likely have a very specific change procedure written in to them, so the customer knows changes aren’t free.

(of course changes are never free, but we all seem to want to brush that away, to the detriment of the customer.)

there are a lot of software projects out there where the customer isn’t chasing some shiny new toy. the folks who wrote the firmware for your microwave had a really good idea what the entire feature set was going to be before they started.