Product delay is the most common challenge faced by modern hardware teams. These delays are happening more often, across a breadth of hardware industries including consumer electronics, automobiles, medical devices, and more. These delays have significant consequences too: they result in lost sales revenue for the entire supply chain for the product, as well as have negative ripple effects on logistics providers, retail companies, and consumers. Why are there so many delays?
In the hardware world, there is an endless cycle of competition between companies to aggressively develop and ship new products in time for key market windows such as Christmas. But if companies plan too aggressively, they risk shipping units with quality issues, having a costly recall, or – you guessed it – missing the window and having a product delay.
Over the course of more than a hundred interviews we conducted with hardware engineers from companies large and small, a common root case for these product delays is a mis-managed schedule.
The typical hardware development schedule
At the core of any schedule are the fundamental hardware build phases: EVT, DVT, and PVT.
Hardware teams build their products by traversing through these phases and into mass production using the Build>Test>Iterate hardware iteration cycle.
Pictured below is a product development schedule representative of what a typical consumer electronics company might come up with and adopt. It is not an idealized schedule based on infinite time and resources, but rather an “optimistic” schedule influenced by the aggressive goals that are common for products being developed for competitive markets of all sizes and maturities. This type of schedule is the status quo.
Some notes on this example schedule:
- During EVT, while the physical assembly may only take a week or two, reliability testing and other validation activities can take up to three weeks. Building and testing can (and often does) overlap – often there will be opportunity during the build to find and fix small issues, and create an issues list of what needs to be iterated. However, that list won’t be fully complete until reliability testing concludes weeks after the build.
- Additional DOEs may be required after reliability testing – but it’s rare for them to be explicitly scheduled beforehand.
- Instead of waiting for DVT validation to finish, most teams will kick off mass production hard tools in parallel with soft tool revisions at the end of EVT, in order to stack the DVT build with the typical 12 week tool fabrication time. This is the “middle ground” in terms of how aggressive you can get with the timing:
- Ideal schedule: MP tool kickoff happens after DVT validation is complete.
- Normal schedule (more aggressive): MP tool kickoff happens in parallel with or just before DVT
- Extra aggressive schedule (danger!): MP tool kickoff happens in parallel with or just before EVT
How typical hardware development schedules result in delays
Now that we’ve seen the expectation of how things typically go, it’s time to look at the reality of how things actually go. The differences between expectation and reality are the things that lead to product delays. These are canonical examples of the kinds of things that nearly always “go wrong.”
Right away, you will see that the EVT>DVT>PVT progression was broken, with a “continuous build” situation taking its place, which ultimately resulted in a product delay of up to 15 weeks. If your product release target was the holiday shopping season, that could mean missing November/December and shipping in February instead. Let’s take a closer look at what went wrong and how it affected the schedule:
Issue 1 : IQC / OQC sync-up issue. Effect: 4 days to 1 week delay
Your upstream vendor’s outgoing quality inspection (OQC) report showed no issues, but your final assembly site’s incoming quality inspection (IQC) report is red all over. This is an incredibly common occurrence for supply chains with proper inspection. This typically causes a four day delay. Unless the parts are really bad, you will end up accepting them anyway and will likely build EVT with multiple out-of-spec parts, just four to seven days behind schedule.
Issue 2: A major design issue discovered during reliability testing. Effect: 6 to 9 week additional build + 2 to 4 week additional tool revision
During EVT, partially through reliability testing, you find a critical problem. Common examples of “critical problems” might include:
- enclosures that change color in extended heat soak
- displays that degrade
- bubbles growing in fully laminated stacks
- product falling apart in strife testing
Generally speaking, it is prudent to expect to face at least one or two critical problems in any program (I’ve worked on programs with dozens). In order to recover, your team quickly designs some DOEs, identifies a candidate solution, and kicks off soft tool adjustments. The new fix is not validated yet, however, so while the next build is “DVT,” everyone knows that the product isn’t actually at DVT maturity – we could say its at “XVT”.
This is the moment where you can fall into the trap of continuous building: in an attempt to avoid delay, your team stays on the original DVT schedule, and kicks off unvalidated MP tools on schedule. Unfortunately, more often than not you will find your XVT wasn’t sufficient to roll right into MP, and you’ll need to eventually add an additional build – as well as spend significant time and money to go back and modify your hard tools.
Instead, your team should just take the hit in advance and add the build as an EVT2. Since it’s EVT2, you would hold off on MP tool kickoff until you reach a true DVT state. All in, if your team takes the EVT2 route, the delay will be six to nine weeks. If they take the continuous build route, the delay will be at least an additional two weeks longer because of the time it takes for additional tool modifications.
The true cause of product delays
Delays are caused by unrealistic, overly aggressive schedules which were designed to meet aggressive goals. Teams on these flawed schedules inevitably fall behind when they encounter an issue that should have been planned for but wasn’t, and in response, may adopt flawed recovery modes – such as continuous building – that ironically exacerbate the problems further and lead to even more delay.
Adopting “fake schedules” simply doesn’t work, and will only lead to problems. The correct approach to speed up product development is not to compromise the EVT, DVT, PVT process, but to instead target the speed of the Build>Test>Iterate cycle: to shorten the time between when a defect is created on the line, and when that defect is discovered and understood.
The secret to speed lies in the hardware iteration cycle
Again, there are two parts of the hardware development process: the fundamental build phases (EVT, DVT, PVT), and the iteration cycle teams use to traverse these phases (Build>Test>Iterate).
The product delays we see today are the consequence of companies trying to speed up the schedule, when instead the answer lies in speeding up the iteration cycle.
Hardware schedules should always:
- Plan for at least one major unexpected obstacle
- Aim for hard iterations, keeping parallel iteration to a minimum and only with structured DOEs
- Wait until after EVT reliability test results confirm a good design before kicking off MP tooling
Speed originates from the ability to collect and analyze data faster. On today’s assembly line, there is a ton of information about units that is left uncollected (quickly forgotten in operator memory), unshared (siloed on the hard drive of a piece of equipment on the line), or even unobserved. No one person has a complete view of the line, process, and development status. Getting access to this “missing information” would enable teams to gain insights into units immediately, rather than having to wait for results from functional tests. Finding issues faster gives teams a head start on fixing them, and ultimately enables them traverse through EVT, DVT, and PVT on, or ahead of, schedule.
The Instrumental System provides hardware teams with unprecedented data capture and analysis capabilities designed to shorten the time between when a defective unit is made, and when teams learn about and fix it. Instrumental is trusted by Fortune 500s to empower their teams to ship on time and avoid delays – request a demo today to learn more.
Related Topics
