Services – Design Sphere

Why do product developments go so easily over budget and take so long?

Anyone who has developed a product knows how easily time may be lost and/or budgets increase. A plethora of things can foil the best laid plan. Diligent planning helps enormously but doesn’t remove the problem. So, what is the problem with product development that makes it such a tough nut to crack?

The elements of NPD that are physical are usually well scoped and treated appropriately, but those that require judgement and aren’t the sole responsibility of the developer are often assumed prescriptive but far from it. Unfortunately, these elements are critical. A change to increase or modify performance is straightforward to scope and predict, but the absence of a prescriptive specification such that the needs of the root customer are unspecified, particularly when those needs are the unwritten perceptions of a range of people in the client’s team and are left to the developer to fathom, will normally lead to failed expectations. An example serves to illustrate this:

• Physical: the client wants a product to have wireless communication. Chip chosen, designed, built, tested, and firmware/software enabling a basic data bridge assumed. Perfectly possible to deliver as part of a scheduled delivery. Any oversights in the design or build can cause hiccups, but they are easily scoped and rectified as part of a Core Service Level (CSL) delivery.
• Judgemental Issues: there are multitude of reasons that could cause the apparently simple requirement (or similar) above to become problematic and lead to delay and extra cost (very far from exhaustive list):
  • The root client is using the device in a swimming pool environment – wireless range of chip doesn’t meet requirement. What is the requirement? No one may have thought about it. Teams meetings between all the parties result, and even if the decision is the existing chip is adequate, weeks are lost while the stakeholders come to a common understanding.
    A demanding, time consuming but thorough and prescriptive specification would have avoided this.
  • Supply logistics: the client has a programmed demand, but its needs weren’t shared and scoped as part of the specification of the product. The engineer chose a chip from Farnell, which attracted a long lead time shortly after the product went into production.
    An introduction at the onset of the project between a substantial and reputable electronic component distributor and the client, e.g., Anglia or Avnet, would have ensured supply guarantees and longevity with the added benefit of expert application engineers on tap.
  • The product has a real time clock supplied by a button cell battery. The delivery involves shipping batteries and electronics separately, and these two elements are to be assembled by the client. Failures occur because the batteries are found to be in a discharged state, sometimes even before shipment by the client to root clients. The assembly process involved using tweezers to place the battery – the client was using metal ones that shorted the battery at installation. I wonder how many people can honestly say they could have predicted this!
    A recognition of the need for a design for manufacture (DfM) process would have avoided this.
  • A client, after having received many production batches, complained of instances of the device going into an unpredictable control state – the microcontroller was getting lost. It transpired that the failing items were in the attic of a house in an extremely hot and humid part of the world – operating outside initial specification.
    A demanding, time consuming but thorough and prescriptive specification would have avoided this.
  • A client was experiencing about 85% successful installation of a product. The developer concluded the likely cause was damage from electrostatic discharge (ESD) during one of the handling processes. This was resisted by the client as a deflection from what was probably a design flaw. Investigation suggested ESD damage was probably occurring during installation, so the installation engineers were given ESD equipment and training that was again resisted on the grounds it was superfluous. It transpired that the problem was indeed ESD damage, and it was resolved by giving the electronics a coat of plastic (conformal coat) – the failures disappeared.
    A recognition of the need for a design for service (DfS) process would have avoided this.

The essential truth is recognition that there are responsibilities for both client and developer that require a constant iterative and monitoring approach over the entire duration of the project, e.g., specification, project management (planning/monitoring/execution), design for manufacture (DfM), etc.