-
NPI: A How To Guide for Engineers & Their Leaders
-
Leading from the Front
-
Marcel Tremblay: The Olympic Mindset & Engineering Leadership
-
Anurag Gupta: Framework to Accelerate NPI
-
Kyle Wiens on Why Design Repairability is Good for Business
-
Nathan Ackerman on NPI: Do The Hard Thing First
-
JDM Operational Excellence in NPI
-
Building the Team
-
Quality is Set in Development & Maintained in Production
-
3 Lessons from Tesla’s Former NPI Leader
-
Maik Duwensee: The Future of Hardware Integrity & Reliabilitypopular
-
Reject Fake NPI Schedules to Ship on Time
-
Leadership Guidance for Failure to Meet Exit Criteria
-
-
Screws & Glue: Getting Stuff Done
-
Choosing the best CAD software for product design
-
Screws vs Glues in Design, Assembly, & Repair
-
Design for Instrumental - Simple Design Ideas for Engineers to Get the Most from AI in NPI
-
Best Practices for Glue in Electronics
-
A Practical Guide to Magnets
-
Inspection 101: Measurements
-
A Primer on Color Matching
-
OK2Fly Checklists
-
Developing Your Reliability Test Suite
-
Guide to DOEs (Design of Experiments)
-
Ten Chinese phrases for your next build
-
-
NPI Processes & Workflows
-
-
Production: A Primer for Operations, Quality, & Their Leaders
-
Leading for Scale
-
Greg Reichow’s Manufacturing Process Performance Quadrants
-
8D Problem Solving: Sam Bowen Describes the Power of Stopping
-
Cut Costs by Getting Your Engineers in the Field
-
Garrett Bastable on Building Your Own Factory
-
Oracle Supply Chain Leader Mitigates Risk with Better Relationships
-
Brendan Green on Working with Manufacturers
-
Surviving Disaster: A Lesson in Quality from Marcy Alstott
-
-
Ship It!
-
Production Processes & Workflows
-
Failure Analysis Methods for Product Design Engineers: Tools and Techniques
-
-
Thinking Ahead: How to Evaluate New Technologies
-
How to Buy Software (for Hardware Leaders who Usually Don’t)
-
Adopting AI in the Aerospace and Defense Electronics Space
-
Build vs Buy: A Guide to Implementing Smart Manufacturing Technology
-
Leonel Leal on How Engineers Should Frame a Business Case for Innovation
-
Saw through the Buzzwords
-
Managed Cloud vs Self-Hosted Cloud vs On-Premises for Manufacturing Data
-
AOI, Smart AOI, & Beyond: Keyence vs Cognex vs Instrumentalpopular
-
Visual Inspection AI: AWS Lookout, Landing AI, & Instrumental
-
Manual Inspection vs. AI Inspection with Instrumentalpopular
-
Electronics Assembly Automation Tipping Points
-
CTO of ASUS: Systems Integrators for Manufacturing Automation Don't Scale
-
-
ROI-Driven Business Cases & Realized Value
-
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.
The number one root cause for launch delay 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:
- 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.
- 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 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:
- 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
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:
- enclosures that change color in extended heat soak
- displays that degrade
- bubbles growing in fully laminated stacks
- 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:
- Plan for at least one major unexpected obstacle (I've never seen a program without at least one)
- 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 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.