Most engineering teams accept some rework during an NPD cycle. It’s even built into most product development processes. Depending on the company, there may be multiple rework cycles built into NPD.

“Rework is failure. And when we’re allowed to do 2 or 3 rework cycles, it means we’re allowed to fail. Twice.”
‍
Director of Engineering
Top Medical Device Manufacturer

For an engineer, this is maddening. And for engineering teams, this is waste.

But as the pressure to launch products faster, cheaper and with less resources gets more pronounced (especially in the age of AI), rework becomes the waste you accept to hit those metrics.

However, the problem with rework is two-fold:

• Its downstream effects haven’t been properly quantified
• Teams believe rework as a whole outweighs those downstream costs
  ‍

In this article, we’ll explore how rework is a quantifiable source of major downstream failures like high COPQ, cost overruns and eroding margins. And then why the cost of rework is much greater than the rework itself.

The quantifiable downstream effects of rework

Product launch delays

In a recent survey, 90% of engineering leaders admit to delaying some portion of their product launches due to late-stage design changes. And late-stage design changes inevitably lead to rework.

This tells us one significant downstream effect of rework: Product launch delays.

Most engineering teams know product launch delays are bad, but they’re also quantifiable. In a McKinsey study, researchers found that a 6 month product launch delay resulted in a 33% drop in profitability over the life of the product. 

Meaning any delay in a product launch leads to some measure of lifetime profit erosion.
‍

Cost overruns

It’s also generally accepted that the earlier you catch an error, the cheaper it is to fix. Despite this, teams still catch too many errors too late. Why? Because it’s hard to quantify the gap between catching an error early and catching it late. 

Hard, but not impossible.

Let’s look at the agile model for the cost of change curve. In this graph we see how changes caught later in the product development process increase exponentially over time. While this is modeled from software development, the changes in hardware are even more pronounced because you’re often dealing with the same business challenges and customer needs, but you have the added complexity of physical hardware.

Now, your costs are even more striking. 

Let’s use the 2015 General Motors recall of a faulty ignition switch as an example. The total cost of the recall was $4.1B. If we backtrack that down the cost of a design change curve, we see the cost to fix that single design error early would have been a conservative $41,000 (100,000x the price of the post-production cost). 

When we dig deeper into this case study, we see that single ignition switch part was $0.57. An easily overlooked part in a massively complex assembly. So, to fix the problem before any rework occurred would have cost at most $41,000 and at minimum $0.57. Instead, it cost GM billions and significant loss of customer trust and market share.

COPQ

A study by the American Society for Quality (ASQ) found that the average cost of rework in the manufacturing industry was 12.5% of product sales. The same study also found that reducing rework by 50% could increase product profits by 13%.

If we look at complex hardware products, the yearly product sales for an enterprise manufacturing product is in the multi-billions. Take the Toyota Camry. In 2023, Toyota sold 290,649 of their most popular sedan. At an average price of $28,080, the Camry represents just over $8.1B in revenue. Then, if we take the average 7.5% profit margin for the automotive industry, the Camry brings in just over $600M in profits.

If we now apply the findings from the ASQ: 

• Toyota is spending just over $1B in rework (12.5% of product sales).
• Toyota could increase Camry profits by nearly $80M just by reducing rework 50%.

Obviously rework comes in many forms, so pre-production rework is only a portion of this. But one thing is clear: Manufacturing companies are drastically underestimating how much rework costs in early-stage product development.

Early-stage rework does not outweigh its downstream costs

Most manufacturing companies focus on reducing downstream rework, like scrap, parts failures, material rejects and warranty claims. It makes sense. These are measurable, visible and preventable problems.

On the contrary, early-stage rework is difficult to measure and difficult to see, so it doesn’t get the attention it deserves. Unless it’s an extreme case, like the GM faulty ignition switch recall, most companies can’t quantify the cost of design rework.

But, what if we could?

Using the above statistics and survey data from 250 engineering leaders, we can make some critical inferences.

1. Late-stage design changes (aka rework) cause 90% of companies to delay some portion of their product launches.
2. Product launch delays as minimal as 6 months result in 33% lost profitability over the life of the product.
3. Design changes cost 100,000x more to fix post-production than they do in detailed design.
4. For complex products, any reduction in rework means millions saved in both product sales and profits.

When we examine these stats together, it’s not a mental leap to conclude that early-stage rework does not outweigh its potential costs.

Meaning, engineering teams should be doing everything in their power to minimize pre-production rework.

Rework is not a necessary evil – it’s just an evil

This may sound extreme. But we talk with engineering leaders every day and the way they talk about rework is as if it’s a nuisance.

“Yeah, we want to improve design reviews because there’s a lot of late-stage changes. But, we need to weigh this with other initiatives.”

“Rework is top-of-mind but so are a lot of other things.”

Rework has become such an accepted part of the product development process that engineering teams are immune to its effects. 

This isn’t surprising considering over the past 5-10 years, product development has only gotten more complex: more specialists, more complex products and more globally dispersed teams and supply chains. 

Yet, the early product development process itself hasn’t changed. 
‍

Teams still do design reviews in spreadsheets and PowerPoints, taking screenshots of static CAD. They still discuss things in meetings as if the team is still a handful of people instead of 50-100+. It’s no wonder issues and decisions get lost in emails, chats and documents spread out over multiple locations.

And it’s no wonder rework happens. 

But with this added complexity, it means the cost of rework has also increased dramatically. Since the process hasn’t changed, however, rework still feels like just another part of the process.

It’s time to stop the madness. Rework is no longer a necessary evil. It’s not just costing you on-time launches, profits and customer trust – it’s costing you team morale. The engineers of today are digital natives. They’re not accepting “the way we’ve always done it” as an excuse for poor processes and improper tools. So, what happens? They leave for software jobs, startups or completely new careers.

If you need to save not just your product development process, but your talent pipeline: it’s time to start investing in the right tools and processes to empower the future of your engineering organization.

If you’re ready to see what that tech-enabled process could look like, learn more here.
‍