Reject Fake NPI Schedules to Ship on Time

Fake schedules and playing "Schedule Chicken" are at the heart of many delayed products. Leaders who build a strong culture around realistic schedule management will ship more of their products on time and if they encounter significant issues, will have shorter delays overall.

Launch delay is the most common challenge faced by modern hardware teams, regardless of whether they are building consumer electronics, automobiles, medical devices, industrial equipment, airplanes, etc. These delays have significant consequences: they result in lost sales revenue for the entire supply chain, 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 missing their window altogether. I've seen over a hundred NPIs and spoken to hundreds of engineering and operations leaders about these delays, and the number one root cause is a mismanaged schedule.

The typical hardware development schedule

At the core of any schedule are the fundamental hardware build phases: EVT, DVT, and PVT. Below is a product development schedule representative of what a typical consumer electronics company might adopt. It is not an idealized schedule based on infinite time and resources but rather an “optimistic” schedule influenced by the aggressive goals 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:

1. 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 an 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 complete until reliability testing concludes weeks after the build.
2. Additional DOEs may be required after reliability testing – but it’s rare for them to be explicitly scheduled beforehand.
3. Instead of waiting for DVT validation to finish, most teams will kick off mass production hard tooling in parallel with soft tool revisions at the end of EVT 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:
   1. Ideal schedule: MP tool kickoff happens after DVT validation is complete.
   2. Normal schedule (more aggressive): MP tool kickoff happens in parallel with or just before DVT
   3. Extra aggressive schedule (danger!): MP tool kickoff happens in parallel with or just before EVT

How typical hardware development schedules result in delays

Okay, let's look at reality now. These are canonical examples 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 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 all red. 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 was discovered during reliability testing. Effect: 6 to 9 weeks additional build + 2 to 4 weeks additional tool revision During EVT, partially through reliability testing, you find a critical problem. Common examples of “critical problems” might include:

1. enclosures that change color in extended heat soak
2. displays that degrade
3. bubbles growing in fully laminated stacks
4. product falling apart in strife testing

Two pathways from one critical problem

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).

Path 1: To recover, your team quickly designs some DOEs, identifies a candidate solution, and kicks off soft tool adjustments. However, the new fix is not validated yet, so while the next build is “DVT,” everyone knows that the product isn’t actually at DVT maturity – we could say it's at “XVT”. This is where you can fall into the trap of continuous building: 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 a build you weren't planning for and spend significant time and money to go back and modify your hard tools. The delay will be eight to eleven weeks: six to nine weeks for the additional build plus at least two weeks longer because of the time it takes for additional tool modifications.

Path 2: Instead, your team should 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.

Playing Schedule Chicken: the true cause of product delays

Delays are caused by unrealistic, overly aggressive schedules designed to meet aggressive goals. Jeff Lutz, who has led engineering and operations teams at Motorola, Lenovo, and others, describes this as "playing Schedule Chicken." 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 and a cascade of other expensive decisions – that leads to even more delay. Adopting overly optimistic “fake schedules” 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 phase gates but instead to 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.

Speed up development by focusing on the speed of learning and iteration

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 result from teams trying to speed up the schedule when they should be looking to speed up the iteration cycle. Hardware schedules should always:

1. Plan for at least one major unexpected obstacle (I've never seen a program without at least one)
2. Aim for hard iterations, keeping parallel iteration to a minimum and only with structured DOEs
3. Wait until after EVT reliability test results confirm a good design before kicking off hard tooling

In practical terms, iteration speed originates from faster discovery of issues, faster root cause analysis, and a tight feedback loop to make changes on the line. Manufacturing traceability and a solid main issues list (MIL) process are a great way to start -- and once that is in place, improved access to data and analysis technology through manufacturing analytics is the next step. Finding issues faster gives teams a head start on fixing them and ultimately enables them to traverse through EVT, DVT, and PVT on or ahead of schedule and ultimately paves the way for manufacturing optimization.