5 common risks in device development projects
When you want to develop a cool new product, you must eliminate lots of risks before launch. To illuminate this, we picked five different risk areas such as balancing between hardware and software, maturity of technology, or estimation of costs. How can these affect a development project?
Developing a modern device with embedded electronics and a nice user interface is a complicated task. Success requires a wide array of skills, great teamwork, experience, and luck. Many challenges need to be tackled along the way to reach the goal. In worst case scenarios, the project is badly delayed, development costs shoot through the roof, or the project is put on hold indefinitely. The management needs to be aware of all possible risks.
1. Poorly defined requirements
“The most common risks are related to poorly defined product requirements. If they are unclear nobody really knows what should be done,” says Kari Viitala, Sales Account Manager of Etteplan’s Embedded Business Unit.
For instance, business representatives may come and talk to internal developers about a brilliant device idea but fail to communicate it properly. Consequently, the development team misunderstands something important. “To prevent such risks, it is essential to be proactive in the definition phase. You need to help everyone verbalize their thoughts and keep asking, what is the purpose of the device, who will use it, where will it be used, and so on,” Viitala tells.
2. Clash of software and hardware
Modern devices are packed with software, which has caused fundamental changes to traditional hardware development models. Software developers use lean agile practices, and the “material” in their hands is easy to mold quickly. Hardware engineering depends on the physical limits dictated by processors, chipsets, sensors, dimensions – everything is inflexible.
“Hardware and software developers live in very different development cultures. Their ways of thinking and communicating are so incompatible that it may even cause a cultural conflict,” says Director Juha Nieminen from Etteplan, in charge of Services Development, Service Product & Portfolio Management. Still, there is no point in trying to turn back the clock. Lean agile just needs to be adapted carefully to suit the domain of hardware. “Most importantly, there must be a well-defined architecture of the device. It provides a common basis for everyone when developing incrementally,” Nieminen remarks.
3. Immature technology
The maturity of technology is a typical risk factor. The newer the technology is, the bigger the technical risks to expect. “Often, companies find it tempting to use bleeding edge technology in new devices. Technically, the component can be all fine, but still unavailable when the production should begin. Also, the development environment can be immature. These sorts of risks must be identified and documented in advance,” says Kari Viitala.
4. Poor manufacturability
When development begins, it is necessary to consider the manufacturing process. “Ensuring manufacturability must be included in the development process early on. If the vision is to produce copious numbers of the device, lots of production costs can be saved with optimization of manufacturability,” Viitala says. He also recommends selecting the manufacturing partner earlier than after the first prototype. “A manufacturing partner is able to validate that the device is manufacturable in the first place. It can also check that suitable testing equipment exists and plan the testing process. A valuable bonus is that the partner can preorder components,” Viitala describes.
5. Price tag of human resources
How much will device development cost? Because modern devices depend so much on software, budgeting is more complicated than before. Software development takes human resources and putting an exact price tag for them can be hard. Basically, everything comes back to requirements. Sometimes, just one change in them requires doubling the size of the software team. Cost estimates can be made only after the requirements are ready.
“In the end, companies need to understand that a modern device is never really ready. However, they must get to the market fast to avoid burning the market potential. A minimum viable product is enough to validate whether the device has real potential and to improve market understanding. This leads to a continuum to keep on developing the product,” Juha Nieminen says.