What’s the Biggest Mistake Engineering Teams Make With Late-Stage Design Changes?

The biggest mistake engineering teams make with late-stage design changes is recording “what” changed about the design without capturing the “why.” 

An engineering change order (ECO) records what design change took place and who approved it. However, that information won't necessarily help the next engineer understand why the change was made. Without that context in place, future designs could pass important stage-gates with the same recurring issues slipping through the cracks. In fact, engineering leaders believe 60% of late-stage errors could have been prevented with better design reviews.

A late-stage design change isn’t automatically a failure for the team or program. Reacting to a supplier's decisions or to a test result that nobody could have predicted are just part of working in new product development (NPD).

At its core, engineering is all about problem-solving. Teams find issues, they find solutions, action them, and move on. That part usually goes fine.

What can cause trouble is when the thinking behind that problem-solving disappears between design reviews, or between one program and the next. The next engineer who opens a CAD model may be able to see what changes were made, but without the right context, they will have to reconstruct the “why” of the design's evolution. In the worst case, a recurring design issue that isn't tracked gets repeated by someone who didn't have the right information. When these types of issues stack up, your program starts to face real headwinds including expensive scrap, late-stage rework, and maybe even recalls from the field.

What counts as a late-stage design change?

A late-stage design change is one made after the design clears the critical design review (CDR), with drawings released, tooling committed and long-lead parts on order. After that point it gets much harder to get feedback you can act on quickly and at an acceptable cost.

A late-stage design change might look like one of the following:

• A supplier quote that comes back over target cost, or a sole-source part that lands on allocation
• A material that clears design and then fails qualification, gets superseded by a compliance requirement or goes end-of-life
• A tolerance stack-up where every part measures in spec and the assembly still doesn't fit
• A design validation (DV) or production validation (PV) failure that results in a necessary CAD or drawing modification
• A manufacturability problem the supplier sees immediately and never had a chance to raise

Why are late-stage design changes risky?

Late-stage design changes introduce substantial risk because the cost of fixing a design issue scales with how late it’s found in the product development cycle. At the preliminary design review (PDR), most issues can be solved by revising the CAD model or drawing. After the design is released, the same issue can mean recutting tooling, requalifying a part, scrapping inventory, or delaying a launch date.

90% of engineering leaders admit to delaying product launches because of late-stage design changes. Component shortages and supply chain delays are events that are outside your control. But a missing draft angle on a molded part? With the right tools and design review process, that’s just the sort of issue that shouldn’t rear its head as a late-stage surprise.

Imagine that your team released a design for Program A two months ago. In the meantime, you’ve started working on concepts and preliminary designs for Program B. But suddenly, you’re tasked with executing a late-stage change order, and it needs to be done yesterday. Suddenly it’s not just the timeline of Program A that’s affected, but also Program B. 

Why do the same design issues keep reaching CDR?

Some design issues recur because engineering teams lack a way of applying their organization’s collective knowledge to the design while it can still change. Running more meetings won’t necessarily solve that problem, because not all your engineers and SMEs can be in every design review. What’s more, since not everyone has a license to expensive CAD or PLM tools, they might lack the right information to flag an issue or make a suggestion.

Every team has a few experienced people who have seen typical failures before. But how much of that experience exists in an engineer’s head compared with a lessons learned document that is easy to find when a more junior engineer needs it? It’s no wonder that 87% of engineering leaders estimate it takes several hours to multiple days to track down the justification for a single design decision. To make matters worse, 43% of design review feedback never gets documented or acted on at all.

So what’s a new engineer to do? If they don’t know what they don’t know, their latest design might include a number of issues that contributed to expensive scrap, retooling, and delayed launches on previous programs.

How do you prevent late-stage design changes?

You can prevent late-stage design changes by running a design review process that gets more stakeholders inspecting the design at the appropriate stage-gate while recording their feedback for future reference. 

Most engineering teams already know they need more eyes on the design sooner. What usually stops them from doing so is the admin work involved. Every extra reviewer means more notes, more markups to transcribe, more people to chase down for input. Capturing comments is not sufficient on its own either. Feedback has to stay tied to the geometry it concerns and to the decision it produced, or the lesson learned will not be interpretable by the next engineer who needs it on a subsequent program.

You can optimize design review by rethinking three key approaches:

Enable reviewers to check the CAD asynchronously in their own web browser.

The quality of a design review is often impacted by who can make the meeting and who holds a CAD or PLM license. Coordinating the right cross-functional reviewers into one call is why reviews tend to get scheduled weeks out, and the cost of software licenses is why manufacturing and supplier quality engineers are frequently not involved at all. In a browser-based platform that allows for asynchronous review, each reviewer can open the model, see other reviewers' feedback in context, and add their own markups on their own time.

This way, when it does come time to host a formal review meeting, every stakeholder has had the opportunity to inspect the CAD and flag issues. A first-pass inspection before that meeting catches the basic errors and non-conformances, so the time you spend together goes to evaluating the tradeoffs that need a group of engineers working in a live setting.

Keep reviewer feedback pinned to the geometry.

A single review can produce dozens or hundreds of issues, and many of them are never addressed. That's often because such feedback is trapped in a PowerPoint deck, an email, or elsewhere, which creates more room for misinterpretation and delay.

The better way is to ensure that feedback is pinned directly to the latest design. This way, anyone can click on the relevant part or assembly and see the issue in context. Anchoring comments to relevant features makes every reference unambiguous. It also gives the design itself a reason to be the review surface rather than a bunch of screenshots that can be lost in your Downloads folder.

Assign an owner, a status, and a discipline tag to every comment.

Once a design review meeting ends, the issues raised in it need somewhere to live. If they only exist in someone's notes, ownership of next steps is too often assumed rather than confirmed. Weeks may go by with the assumption that the design is ready for the next stage-gate, but several issues might be left unaddressed.

To solve this, every comment should include an owner and a status, plus a tag for the discipline that raised it. The status carries into the next revision, so the review owner can confirm whether a change was made and closed or whether it is still open, instead of comparing old files to find out. The discipline tag is what makes the record searchable months later, when someone needs to know what supplier quality flagged on a similar part.

If you and your team incorporate these new approaches when you run design reviews, your designs will carry their own history. Your PLM already maintains the record of what changed at each revision, but the reasoning behind those changes can be just as important for future reference. 

How do lessons learned reach the next design?

Recording the reasoning for a design change only pays off if it reaches the next engineer at the moment they need it. In practice, nobody stops mid-design to spend hours searching through two years of review history to justify a single design decision. We need a faster, more reliable way to surface that information.

Within the CoLab platform are two AI agents that work in tandem to capture and surface more engineering knowledge. When someone uploads a model or drawing, AutoReview runs a first-pass check of basic design issues. As the analysis runs, it surfaces feedback from past reviews of similar parts, with the context (including your standards and guidelines) attached. You can see exactly who made a decision, what the relevant issue was, where it came up on the previous assembly, and how it was resolved. That's the comprehensive context an ECO in PLM can’t hold.

In addition to AutoReview, Operator gives engineers a plain-language way to search their engineering data and past reviews, so you can quickly get answers to questions like "Have we solved this before?" and "What did we decide on similar parts?"

Late-stage design changes don’t have to be the cost of doing business in hardware engineering. Using a platform like CoLab, every piece of feedback, every assigned owner and status, and every tagged issue becomes something that makes the next design review more informative and more efficient. Your most experienced engineers no longer have to be in the room for their judgment to reach the design.

If you want to test CoLab’s capabilities against your own designs, get in touch with me or one of my fellow Solutions Engineers. We'll set up a time to meet and discuss how CoLab can help you catch design issues earlier and faster, freeing up your time to focus on the next program instead of constantly reconstructing the last one.

‍