What does it Mean when Estimates Differ Substantially?
It often happens that different estimates turn out to be diverging significantly. This can happen for various reasons.
The task was Not Understood (the Same)
This is the most common reason, the project and its requirements have not been fully understood, or certain factors have been forgotten, for example:
- Certification effort (CE, UL, EMC, Machinery Directive...) incl. related documentation and third party costs
- Product quality (robustness/stability), i.e. error handling is omitted or is minimal and only the standard case is implemented: so user input errors, errors in connected systems, assembly errors, aging, component tolerances, etc. lead to "unexpected behavior" and thus to additional costs as modification and service costs or even worse as warranty claims
- Integration into the device to be controlled, i.e. the cost of debugging the entire system together (no specification is so clear and unambiguous that integration runs smoothly)
- Quality assurance of the hardware and especially the software through meaningful, risk-based testing (automated if possible) and review of critical designs
- Documentation and design to a reasonable extent that allows maintenance and extension of the product without great cost trough its life
The Charging Models are Different
On the one hand, a cost estimate can start from the minimum project scope and unclear requirements and then be done on a time and effort/ iterative/ agile basis. This can lead to surprises and renegotiation if it turns out that there were misunderstandings about the goals between developer and the other stakeholders.
On the other hand, all stakeholders can be clear about the requirements that the project can be done at a fixed price. As long as there are no new requirements, this will not lead to any surprises.
A example from real life shows that agile near-shoring can be more expensive than fixed price in Switzerland.
There are Other Underlying Business Models
On the one hand there is lock-in (cost trap/dependence), where a "political" price is offered below the real cost of development. The profit is more or less hidden afterwards by increased margins for the production of the electronics or for technical changes to software and hardware. The customer remains dependent on the supplier, since he gets only the finished product or the compiled binary code for his price.
If a control system has manufacturing cost incl. manufacturing margin of 100 CHF and a hidden margin of 20% is added, then the hidden margin can already amount to 200,000 CHF for a moderate annual number of 1000 units, over the lifetime of the product of ten years. This hidden margin can be half of the development costs of 400'000 CHF, with only 2000 units per year it would already reach the entire development cost.
The other model is the open business model, in which the customer gets all the intellectual property and in which the costs for development are shown transparently. This reduces lifetime costs, as no hidden margins can be forked out. This is because the customer can use the source codes, schematics and layout documents plus associated documentation to produce, operate and further develop the product themselves or with any partner.