Example #1:
- a company in the industry asks your company to implement $FOO, they want to know how much it'd cost
- the sales people talk to the engineers, who come up with a certain amount of time it could take
- the sales people turn this into a monetary figure of $X
- a contract is made, the project proceeds to be developed, probably with some delays and overruns, but works in the end and is profitable
- a different company in the industry asks your company to implement $BAR, they want to know how much it'd cost
- the sales people decide that $BAR is similar enough to $FOO and that there's no need to consult the engineers, they just give a similar estimate
- turns out that the project MUST be made for JavaEE, since that's what the company is using
- turns out that the project MUST work on Java 8, since that's what the company is using
- turns out that the project MUST use Oracle DB, which then requires licensing and particular setup for the environments
- turns out that the project MUST use GlassFish and instructions must be written for it, because deployments will be done by the clients' Ops person
- turns out that the project MUST be deployed as a .war file, because of the above
- turns out that the project MUST work in RHEL 7 because that's what the clients are using, same situation as with Oracle
- turns out that the project MUST have both a test coverage of >80% and integration tests, which weren't a consideration in the previous project
- turns out that the project MUST support IE because for some reason that's what the employees of the client company are using
- as a consequence, the technical implementation takes about 200-300% longer than previously estimated
- the project is no longer profitable and is a net loss for the company
- there's yet another company that asks for $BAZ, they want to know how much it'd cost
- the sales people had a really bad time with that last project, so this time they decide to increase the estimate
- turns out that this new project does not have any of those constraints
- because of this, the estimate is really large
- the company looks at this and decides to go with your competitor instead
- your company loses out on the opportunity of working on the project entirely
Of course, the above happens when you're in a market that requires estimates as a part of BOMs, which is a lot like bidding on projects and is just a race to the bottom for the most part.
Deliver working software? Perhaps.
Deliver quality software? Almost certainly not.
Now, whether people actually want quality software, given that its development would take a lot of time, is debatable. Many times being the first to market is good enough, though saying that leaves a sour taste in my mouth as an engineer.
Yeah this, to me, totally invalidated the rest of your example. Pick a low number to win the bid, blow the timeline/estimate, require more money to do anything at all. It is not clear to me that any "estimation" changed this calculus at all.
Except that there are penalty mechanisms in place to prevent this from happening.
So your company was slow to deliver the product and needs more time? You better be prepared to work for your own resources, otherwise the escrow won't get released, as per the contract.
Or perhaps you cannot finish it at all? Get ready to either not receive a large portion of the money at all, or to be sued outright. For an example, see here: https://www.consulting.us/news/2197/accenture-sued-for-32-mi...
Disclaimer: i have nothing to do with Accenture or consulting in the US, though consulting, government contracts etc. all share certain similarities and bureaucratic processes in most countries that don't always align with the realities of actually developing software.
If you can, steer clear of all of that and instead work for a technology oriented company that develops a product that they also sell themselves. One, in which the developers are viewed as a profit center, instead of a cog in a ROI generation machine. Ideally, an engineering led company.
A CTO of an American company, to get a bonus of $7 million, lays off a ton-load of the company’s CRM people who knew how 20 years of architecture duct tape that ran the company was strung together.
CTO then proceeds to hire a cheap, offshoring body shop to design the company’s new website, which talks to the CRM. However, there’s no more CRM people at the American company because they’ve all gotten laid off and the offshore web contractors also now have to become customized CRM experts, which is insane scope creep.
The outsourcing company can’t deliver and litigation is sought, while the US company takes zero responsibility for the fact that all the CRM people were let go and there’s no chance in hell that web developers at the outsourcing can ever learn the highly customized domain-specific logic that fast that extensively. Meanwhile, CTO gets fired and a severance of $1 million for all the extreme damage he did to the company.
And what do estimates provide here, that sales just picking a number doesn't? Estimates are made up numbers. They're estimates.
Also this line that you omitted answers your question more directly:
> If you're a sales driven/feature factory company, the estimates won't matter anyway as you'll demand to meet your obligations regardless of estimates.