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 renegotiations if it turns out that there were misunderstandings about the goal 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.
An Example from Real Life
A customer wanted to develop software for a graphical user interface for another mechanical and processor platform. Apart from the visual design, the software had the same functions as the interface we developed for the first platform at a fixed price. This second development was estimated massively cheaper and awarded as a near-shoring contract in an iteratively/ "agile" fashion.
In the end, the customer's CTO stated that the costs for both developments were the same: "A graphical user interface costs the same everywhere". And this statement did not take into account that our development included the entire electronics and process control, the actual graphical user interface accounted for only 60% of the "same size" development costs.
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.
How does one Arrive at a Cost Estimate?
Rarely a project is already so clear from the documentation that the estimation can just start. Therefore, a workshop with all stakeholders (product management, industrial design, mechanical development, marketing, service) is held first to discuss all the factors that determine the price.
This workshop is summarized in a document, the common understanding of the project, in which the project is described in the words of the software and hardware developers. This goes through a review with the stakeholders and is then adjusted if there were any misunderstandings.
Only then an estimate is created and documented. The customer receives this detailed documentation of the estimate (typically several dozen points), which is optimized in another workshop with all stakeholders. Then a commercial offer for the desired project scope is created.
Are you ready for a cost estimate? Contact me!