“It is only a minor change” is one of the most expensive sentences in product development. Sometimes it is true. But the size of a change in a drawing does not tell us the size of its effect on testing, production, suppliers, instructions, or users.
As an engineer, I learned to trace a design choice into analysis and test evidence. As a program manager, I learned to trace it into schedules, owners, and handoffs. Both views matter when someone proposes a quick revision.
Follow the change beyond the part
Imagine a hypothetical change to a reusable instrument's polymer handle. The new material seems equivalent and is easier to source. It may still affect grip, cleaning compatibility, dimensions after processing, assembly fit, durability, labeling, supplier qualification, or the validity of earlier verification work. Each possibility is a question to investigate, not a claim that the change is unsafe.
The FDA's current design-and-development training includes control of design changes in the ISO 13485-based quality-system framework. For regulated devices, the specific review and documentation requirements depend on the change and applicable rules. For any product team, the general habit is to examine impact before committing to a release date.
Five questions for a useful impact review
- What is changing, and why? State the original problem and the proposed solution. A supplier substitution and a performance improvement may call for different evidence.
- Which requirements and risks does it touch? Trace the change to user needs, design inputs, risk controls, and any claims in labeling or marketing.
- Which evidence remains valid? Existing tests, analyses, and usability work may still apply—or may rely on assumptions the change removes.
- What must operations repeat or update? Drawings, work instructions, inspection methods, tooling, training, inventory, and supplier controls often live outside the design team's immediate view.
- Who approves the decision and when? Put the right functions in the room early enough to avoid a late surprise.
This is not an argument for retesting everything after every edit. It is an argument for documenting why particular evidence is sufficient. A focused review can make a small change stay small.
| Impact area | Question for the review | Likely partner |
|---|---|---|
| Requirements and users | Does the change alter a product claim or experience? | Product and design |
| Risk and evidence | Do prior controls or tests rely on the old design? | Quality and test |
| Production and supply | Must instructions, inspection, tooling, or suppliers change? | Operations and sourcing |
| Release plan | Which dependencies set the real completion date? | Program leadership |
The schedule cost is often a handoff cost
The visible engineering task may take a day. Waiting for a revised component, updating a fixture, repeating a test, reviewing a risk file, and aligning production can take much longer. The sequence matters: if a test needs production-equivalent parts, starting it before the process is settled may create an elegant but unusable report.
I have found that a simple dependency map is more helpful than a long status meeting. Put the change in the center. Draw arrows to requirements, risk, verification, validation, supplier, manufacturing, and release documentation. The arrows that lack an owner show where the schedule is fragile.
Make learning part of change control
After release, ask whether the change solved the original problem and whether it introduced new signals in complaints, production yield, or user feedback. ISO 14971:2019 treats production and post-production information as part of risk management. The same feedback loop improves nonmedical products.
Change control works when it makes consequences visible early and helps a team make a timely decision. It fails when it becomes a form people complete after the decision has already been made.
A change assessment should revisit the hazards and controls described in A Risk Register Is Not a Product Risk-Management System. It should also revisit the requirement and test links explained in Design Input vs. Design Output.
If you are facing a change that looks simple in the design file but complicated across teams, let's talk. Mapping the dependencies is often the first useful step.
Leave a Reply