The change record wasn't wrong. It was filed against the wrong project — and it paused our release.

At 22:40 on a Thursday, eleven days out from a release train, I opened a change record that had been approved three weeks earlier — by two competent people who had both done exactly their job.

Nothing about the record looked wrong. The change was a supplier substitution: a new adhesive lot in the enclosure assembly for one of our Class II device families. The supplier sent the notification, engineering wrote a sensible justification, QA checked the chemical characterization package, and the change went through review and approval without a hitch.

What was missing was a sentence nobody could find: what does this change touch?

The scope that wasn't there

The request had been created against a site-level quality bucket rather than the device program it actually affected. With three programs in flight, whoever filed it didn't want to guess wrong, so they parked it somewhere generic.

Generic is where dependencies go to disappear. Once it was approved, no downstream process picked it up:

• The ISO 14971 risk management file for that device family never received the new lot data.
• The DHF index didn't pull in the updated supplier qualification record.
• The incoming inspection instruction kept the old lot acceptance criteria.
• The training assignment for the receiving inspector went to a site group nobody read.

We caught it during release readiness review because I was walking the open change queue against the release checklist. The checklist itself was fine. It was manual, and it was only ever populated for changes scoped to a product. Site-level changes were assumed to be product-agnostic. That assumption cost us eleven days and a re-review of the supplier's process capability data.

What the standard actually asks for

Here's what I had to sit with afterwards: ISO 13485:2016 never asks for a project.

Clause 7.1 talks about product realization planning. Clause 7.3.9 asks that changes to the product or the QMS be reviewed, verified and validated as appropriate, and documented. Clause 7.5.6 asks that changes to documented information be identified, reviewed, revised and approved. ISO 14971 asks that you evaluate the change against the risk management plan. And for a supplier substitution on a cleared device, there's a separate question about whether the change needs a new 510(k).

None of that language requires a project tree. What it requires is that you can demonstrate, years later, that every affected output was considered and that the right people signed it. A project scope is simply the cheapest mechanism I've found for making that demonstration possible — it turns "did we check everything?" from a memory test into a query.

That distinction matters when someone asks me to justify the rule. The rule isn't in the standard. The auditability is in the standard. The rule is just my implementation of it.

What I changed

• No scope, no approval. A change record must carry a device or program scope before it can enter an approver's queue. If it genuinely spans programs, it gets a parent scope with linked child records instead of a generic bucket.
• The release impact assessment became a query, not a checklist someone remembers to open.
• A weekly "orphan sweep." Any open change with a blank scope, or a scope that matches no active program, gets reviewed by hand. Not elegant, but it's the only thing that catches the leftovers.
• Approver training now says the quiet part out loud: approving the justification is not the same as confirming the downstream outputs were updated. Two of my reviewers told me afterward they'd genuinely never been told that.
• "Unscoped" stopped being a valid state, including for site-level work. If it isn't attached to a product, it's attached to an owner, a date, and a defined scope like a process improvement — but it still has to live somewhere with a name.

The 22:40 review was the symptom

The late-night part sounds more dramatic than it was. Mostly it was fatigue.

The review was scheduled late because the release gate sat outside the contract manufacturer's working hours in their timezone, and because the documentation checks had been slotted after engineering sign-off rather than planned alongside it. That's the same problem wearing a different hat: when work is scoped, it has an owner, a duration, and dependencies, and it appears in a plan. When it isn't scoped, it appears as a surprise at 22:40.

I also want to be honest about what we didn't solve. Our project tree is not the DHF index, and if we let the two drift into parallel truth sets, we'd have the original problem with better metadata. We still have open changes sitting in the site bucket that I review by hand each month. It's administrative debt, and I've stopped pretending otherwise.

What I'd still change

If I ran this again, I'd put documentation impact on the release plan at the same level as verification activities, rather than as a gate that happens afterwards. I'd also run a monthly query for changes approved in the last 90 days with no downstream linked records — not because it proves a problem, but because it's the question that would have caught this one, and it takes about ten minutes.

For those of you running mixed portfolios: how do you scope a change that genuinely affects more than one product without the structure turning into a second index that drifts from the DHF?