Follow our illustrated blog on Embedded Software Architecture

How to build a hybrid solar/wind energy harvester?

5 reasons why embedded device development projects fail

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)

Missing stakeholder support

 “The project is defined, so implement it and roll it out” does not work well in human organizations. Every entity and person has its own target, purpose and agenda. That is the way the world works, so one must take into account the process (and the time) it takes to get all the noses in the same direction. A project team needs to create the platform and develop the support to undertake the task of building a product or service. Everybody involved must perceive to have had input. Unfortunately, in past years, I have sometimes observed projects where war was waged between departments. This has had a serious negative impact on the outcome.

Unrealistic planning

When pressure is high and time is limited, there could be a tendency to adapt the planning to fit the “wishful thinking”. But embedded developers are no masons: When a project is late, most of the time, it does not help to add additional developers: It is not always easy to parallelize tasks. The only right thing to do is check the requested targets and features, and decide which can be dropped in the current iteration. An agile method might help to define clear target iterations and demonstrable progression, but – that on itself – does not guarantee success. However, it is widely accepted that the input of (more experienced) developers is essential in getting better task duration estimations. Only then, planning – regardless of the used development methodology in the organization – can become more realistic.

Scope creep

Too vague project milestones are a recipe for disaster, and so is continuously changing the (end) target of the development. Steering an embedded (device/software/hardware) development project can be compared with steering an oil tanker. It does not change course easily. So, course changes should be limited in frequency and direction. This is the most important reason for cost explosion and not-in-time projects (if they ever finish).

A technological bridge too far

Genetic product evolutions should preferably imply product changes that are understandable by marketing department and customers in general. New technologies present new possibilities, but not every organization or customer is ready for them. Most successful innovations are combinations of simple already existing technology. Only on rare occasions, a new product revolutionizes the market. The new technology might be “cool” and innovative, but a product must always fulfill a customer need. If that is not the case, it fails in purpose regardless of how clever it is. Then again, some marketing guy can explain that ‘needs or markets can be created’. I have witnessed more than once in the past that a company developed a really new and useful product, but the market was not ready for it (yet). And when the market for that product did develop a few years later, it was already too late for the initial innovator.

Premature optimization

An exaggerated and premature focus on cost during development can also kill a project. Of course, it depends on the product life cycle. Usually, there are several optimization phases from product generation to product generation. It does not make sense to stringently limit the possibilities in the beginning of the development cycle. And then, there is also always price evolution. When selecting electronic components and modules, it might be beneficial to look at the component age versus cost graph. I remember a particular case of ARM7TDMI micro-controller that was “too expensive” at first, but one year later – at the time of product launch – was dirt cheap and great bang for buck. HINT: The same is happening right now with the ARM Cortex series…

Another pitfall is a too early focus on algorithm, processing and code optimization in general. One should only optimize when and if required: One should be able to measure efficiency of critical path code, and (hand-)optimize only when absolutely necessary. Of course, that does not mean that code and algorithms should not be efficient-by-design, but they should also be kept as generic as possible for as long as possible.

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
Share
About rtos.be

rtos.be is a joined initiative from Gert Boddaert and Pieter Beyens.
More info: about us, our mission, contact us.

Comments

  1. …completely recognisable, and not only in embedded developments…

Speak Your Mind

*


+ 2 = four