Electronics Machine
Search
Close this search box.

One Page Guide: Big Risk Mitigation with Electronics Product Development

Big risk with development

 

What’s the issue?

An alarming issue is that most electronic product developments fail ROI requirements (even fail to materialise at all) at the first attempt. Why? – poor management of commercial and technical risk.

We are all human, and it is an understandable part of our ego preservation that we avoid analysis of the uncomfortable, but in business it is exactly those topics that are likely to encourage success if addressed and ensure failure if ignored. For example, it is very easy to avoid cash budgeting until looking into the abyss. It is equally easy to drift from one day to the next without taking the actions necessary to ensure orders appear in the future. Solution of this lies in establishing systematic processes and methods that make taking action to mitigate risk part of daily life.

What are the types of risk?

Essentially, all risk relates to money. Nevertheless, the electronics product development process lends itself to sub dividing risk into commercial and technical:

  • Technical Risk: It is terribly easy to overlook a technical risk and pay handsomely for it. There are two key areas (feasibility and specification):
    •  Feasibility involves not getting dragged into something that appears defined and certainly isn’t. Imagine that a client has a new product that measures pressure and has requested that the data from the pressure transducer is transmitted wirelessly. That’s all that’s been said. If this is taken as is, it is relatively easy to implement a wireless technology (say BLE) to do it. Will the wireless be able to transmit data fast enough? You know nothing of the necessary rate of sampling needed for the customer’s product to achieve its purpose – perhaps the customer doesn’t either! The key to assessing whether or not feasibility work is required is firstly to demand proper specification of the product (see: OPG: Specifications), and secondly to insist that every single requirement has a defined test with stated acceptance criteria. If it isn’t possible to state how the requirement may be confirmed as compliant by test then it will be necessary to do some feasibility work before starting to specify the product thoroughly. 
    • As implied in the previous bullet, thorough specification of requirement, how it is to be done,  and what the test and acceptance criteria are, must be explicit. (see OPG: Specifications)
  • Commercial Risk: No one needs to have what commercial risk is explained, but what’s not so straightforward is how to maintain, monitor and react to measures that will confirm success or warn that something might be going awry:
    • If a viable maximum manufacturing cost has been set, no matter what the stage of the project, it must be monitored. If the project is pre-design, it doesn’t mean manufacturing cost estimates can’t be made (take a look at the EM’s post on cost estimation). If the project has reached design or manufacture, actual estimates can be used. Make sure that the project progress meeting regularly (every meeting) reviews the current manufacturing cost estimate and the target, which should be in a mutually approved specification. Make it an agenda item.
    • The manufacturing cost should be tied to an ROI (discounted cash flow prediction over a fixed term). If it isn’t, it is probably of limited meaning. DCF (discounted cash flow is a management accounting technique geared for this purpose). There is little purpose in having a manufacturing cost monitored and followed if it isn’t part of the ROI calculation. It is the EM’s recommendation that the DCF is in a piece of software, e.g., a spreadsheet that allows variance to be quickly and easily monitored. ROI should also be an agenda item at project development meetings. If assistance is required with discounted cash flow, please feel free to contact the EM – CONTACT US
 

How do I do risk assessment?

The previous section gives guidance on monitoring and controlling macro-risks, but real projects involve dealing with problems that are a bit more down and dirty. An example might be the product under development could unreasonably be perceived as unsafe by prospective clients. What is to be done about it? There are formal risk assessment processes (BS EN IEC 31010:2019 Risk Management), but a basic risk assessment is often all that’s needed. A document having a list of all the risks imagined and populating the following for each risk:
  • A thorough description of the risk.
  • An assessment of the severity of the risk. The EM recommends that this and all other risk measures are binary – can become fanciful if scores are given. So, the question is: If the risk in question manifests itself, are its consequences serious? Either they are serious or they aren’t – don’t get into debates about ‘how serious’. 
  • An assessment of likelihood of occurrence. Is the risk likely to happen – yes/no. 
  • Finally, is it likely that the risk will be corrected before its severity has a chance to take effect. Will the issue be noticed and corrected before it has a chance to have serious consequences.
  • If the answer to all 3 of the previous bullets is yes, mitigating actions must be established. State what these will be.
  • Re-asses risk using the method above after actions are done, which should reduce risk to acceptable levels
Make sure that risk assessments are programmed in to the project development process – should be part of the project plan. 
 

 

The EM would be delighted to give you further guidance if you need it – please click CONTACT US and we’ll take it from there.