Paradoxes

Paradox 1: If you want to Develop Faster, take More Time

...more time for specification and finding the appropriate technical solution (the "architecture").

A Short Story

which illustrates this. "Help, the standard comes into force at the end of the year.... And none of our 12 control systems meet the new requirements." We then invested a total of four (4) months in specification, the first two months until we had an optimal technical solution and four control variants remaining. Then another month each with product management to dump one control variant each.

During this time, very clear and detailed specifications and a clear architecture were created, which documented the consensus between product management, mechanics and production. We were then able to bring the remaining two variants to production maturity within six (6) months, on schedule by the end of the year. And by the way: the controllers are still being produced today, after thirteen years, without any significant changes.

What Happens when one Starts Fast?

If you start with a product development based on unclear requirements, in embedded development this has the disadvantage that the developers have to make assumptions when selecting the processor, the operating system, the interfaces, etc. If these then turn out to be wrong in the course of clarifying the requirements, e.g. the processor is too weak, the result is a huge effort for redesign or for development around "bad technical decisions".

And What about Agile?

The agile processes and work methods of generating specifications during the project usually do not solve the problems and can increase the risks.

Conclusion

Fast and smooth development must be bought with early clarification of the requirements.

Paradox 2: If you want to Develop Cheaper, take the Higher Hourly Rate

...just as your high-quality products are not the cheapest, high-quality engineers are not the cheapest.

A Short Story

A customer contracted the software for a graphical user interface as a near-shoring project in an iterative/ "agile" way. Except for the visual design, the software had exactly the same features as the user interface we developed for another platform at a fixed price. This near-shoring development was initially estimated to be massively cheaper.

Two years after the start of production, the customer's CTO said: "A graphical user interface costs the same everywhere". The costs for both developments were the same after all changes in the near-shoring project. And not even just the same: our development additionally included the entire electronics and sequence control, the graphical user interface accounted for only 60% of the "same" development costs.

What happens if one Only Looks at the Hourly Rate?

For a first iteration a simple case is estimated, out of ignorance or to show low effort, so that one can start with the development. Then the immature requirements are assigned to inexperienced developers, who fulfill the requirements to the best of their knowledge. The subsequent iterative changes and elimination of misunderstandings eat up the entire cost advantage again.

Conclusion

The savings that result through development and over the whole product lifetime stemming from the experience of the engineers, from clear, lived processes and from continuous training must be bought with an increased hourly rate.

Paradox 3: When it Works, Only Then does the Work Begin

...because then the non-functional requirements and regulations come your way.

A Short Story

A research team had spent years developing a sensor until it worked accurately. The excitation, control and readout was based either on a rack full of sources and measurement devices or then on an integrated device, which on the one hand was outdated and not powerful enough, and on the other hand did not offer up-to-date interfaces to the outside.

In a startup, the sensor was then to be commercialized for the process industry. Since it was "already running", no significant budget was planned for the development of a control system that met the requirements of an industrial environment in terms of reliability, safety and interfaces. Instead of hitting the market, it took several years to win a few customers in a few industries.

If a device works, then the effort only begins, especially if functional safety (e.g. the machine directive) still has to be considered: Innovation Pareto hits.

Conclusion

Fewer redesigns in product development must be bought with early consideration of customer requirements (interfaces, operation, environmental conditions...) and especially regulations.

To get a clear picture of the remaining effort after "it works", the development must be realistically planned for customer requirements and laws and standards (safety, functional safety, data security...).

Paradox 4: If you have Technical Problems, Solve the Human Problems

...because many technical problems are communication problems.

A Short Story

For a customer we had to adapt a software for a radio communication system to the new hardware and to the requirements of the customer. The effort and schedule of the project exploded because of the many technical problems. Really? The software group was reluctant to talk to the hardware engineers, "those on the other side of the aisle." And certainly not with the high-frequency group, which in turn felt snubbed by the external supplier of the transmit/receive module.

In the end, the external development partner was the hub of all information and the "technical" problems could be solved rather quickly. This was because the external partner, as the "hub", also took responsibility for communication between the silos and between the technical specialists.

The quote from Gerald Weinberg fits this: "No matter how it looks at first, it's always a people problem" or a bon mot at my first employer: "There are no technical, only human problems". Of course there are also real technical problems, but in my experience those in product development are mostly of the human type.

Conclusion

Technical problems that delay projects are often interface problems, i.e. problems between people, groups and cultures, even within the same organization. Efficient projects have to be bought by first investing time and energy in bringing people together, to communicate.

Paradox 5: If you Develop Hardware, Ask the Software Engineers

...because the hardware requirements are mainly determined by the software.

A Short Story

An advanced technology department had developed a functional model. It made sense to oversize many components, just to be sure. The converter was ten times too fast and four times too accurate, the processor had several cores, it had memory in abundance. The functional sample ran to full satisfaction, so a product development project was set up.

Because it worked in the functional sample, for product development this "good" hardware was simply taken over. But then it turned out that the software only needed one core. That not the whole resolution of the converter was used and also only at a fraction of its sampling rate. In return, several features for data security were missing and the memory was dropped because it "didn't fit on the layout".

Conclusion

Although it seems obvious, it's always a problem: As hardware and software developers, talk to each other. Define the architecture so that it is optimal for the task. I.e. it is not able to do to many things (high unit cost), but especially not too few (high development cost due to changes and software development "around the hardware").

Paradox 6: If You Develop Hardware, Use Agile Methods, even if this is Not Possible for Hardware at all

...because if every prototype is already a release candidate that goes through all the "pre-compliance" tests, then you save the industrialization phase.

A Short Story

We repeatedly have customers who have developed a technology, for example, from research project to series production. Then they ask us for CE and UL certification, for industrialization. Usually, as soon as the product is "ready for series production".

Often, during the certification process, minor and, unfortunately, major changes to PCB, connectors and components arise. Sometimes whole grounding concepts or mechanical designs (clearances...) have to be rethought. This leads to additional delays (market entry!) and expenses.

Conclusion

Already look at the first prototype as "zero-series/ pre-production", just as software engineers look at each sprint release as "product". Perform "pre-compliance" tests with them, in addition to purely functional testing. Then you can easily incorporate the customizations into the next prototype. This can lead to the fact that you have to generate only two layout versions until series production!

However: Just to be "agile" deliver a PCB every two weeks as a result of the sprint definitely does not make any sense in my opinion. This is because the costs and delays for a "release" are massively greater for hardware than for software, where they are negligible.

Paradox 7: If you want to Succeed Faster, make More Mistakes

...because if you develop functional prototypes and MVP (Minimum Viable Product) faster and less "accurately", if you take more risks, then you have faster feedback on what you can improve (also called "mistakes").

A Short Story

A mechanics company has an idea how to market their products for whole new areas thanks to Internet of Things (IoT) add-on features. There are many workshops, concepts, ideas, but no models, no Minimum Viable Product... "Since it is not quite clear yet which of the markets, which functions to tackle exactly. Because we don't want to make any mistakes with the first new product..."

Would the MVP not just be there to complement the analysis with real market clarification? To add real user needs to the now two-year internal analysis phase?

Conclusion

You cannot win back the time you lost to clarify the last ambiguities in your innovations. But you can immediately correct mistakes you made in your first prototypes or MVP.

And then do all the concerns in the analysis really manifest as mistakes in the market? Maybe in the workshops you invest time in something much less important than the things you did not even think of, but which customers tell you about the MVP?

Paradox 8: If you Search Well-Known Partners, How Well do You Know What You Get?

..because even well-known partners can provide you with unknown specialists.

A Short Story

A Swiss startup makes the first product with a small, fast engineering company, it becomes a market success. Now that there is enough money, it develops the next "wireless" version with a "well-known partner". Unfortunately, he gets the wrong team there: it takes twice as long, a bad solution is created which, to make matters worse, is also difficult to produce...

Conclusion

What makes a company well-known? Is it the employees (all hundreds?, also those in the "near-shoring office"?), is it the processes (only ISO 9001 or CMMI Level 3?)... Or is it other reasons: our CEO knows the division manager or is it FUD (Fear, Uncertainty, Doubt: "Nobody was fired because he bought ...") or peer pressure ("others also select...")?

Do you read the partner you trust according to objective criteria?

Paradox 9: If you want to Develop a Low-Cost Product, Expect High Development Cost

...because finding the most cost-effective solution requires a lot of effort.

A Short Story

A manufacturer wanted to add a simple IoT node to the product portfolio. The many interfaces made the device more expensive than the existing, simple solution. To get a low-cost solution, optimized over the manufacturing costs of electronics and mechanics, many solutions had to be evaluated. The chosen, lowest-cost solution was then not the one that minimized the software effort. The management was initially shocked by the effort required for this optimization.

Conclusion

If you want to find the optimum manufacturing cost, then you must be willing to invest more in finding solutions and developing with non-ideal platforms. Or the other way around: the simplest solution (e.g. maker boards) may be the fastest in development, but depending on the numbers produced, you pay the price for the savings in development cost with the manufacturing cost and over product lifetime.

By the way, it makes sense to have the discussion about "low manufacturing costs" at the very beginning of the project, because depending on the number of units, the development costs will eventually come into play. The prerequisite for such a consideration would then be an estimate of the development effort that is as reliable as possible.

Paradox 10: If you Manage an Overall Project, Manage the Interfaces First and Foremost

...because in the interfaces (hardware, software and mechanics!) you can minimize problems and expenditure in a future-oriented way ("frontloading"). Future-oriented, so that the interface is clear the moment someone starts its implementation.

A Short Story

A manufacturer set up a complicated project with IoT, cloud and apps. Unfortunately, the interfaces emerged during implementation on-the-go or during integration, on the one hand protocols and graphical operation, but also comparatively simple mechanical fits. Then, during the integration phase, a lot of energy and effort was invested in correcting errors in the interface description, in unnecessary "known unknowns". Not only in correcting implementation errors and misunderstandings, i.e. "unknown unknowns".

Conclusion

As project manager or client of a development project, make the interface definitions available to the respective "affected parties" at an early stage, i.e. define the "unknowns" that you can already be resolved at system level. This massively reduces the integration and troubleshooting effort.

Andreas Stucki

Do you have additional questions about these paradoxes and contradictions? Do you have a different opinion? If so, email me  or comment your thoughts below!