Last quarter an OEM customer asked for traceability on a deviation. We had the deviation on file, we had the linked CAPA, we had the supplier NCR — but nobody could tell which of three OEM programs the part had been built against in the month the deviation occurred. We spent three weeks pulling batch records, blending logs, and shipment data to reconstruct what should have been one field. That trace-back is what sold me, finally, on project-scoped work.
This is the honest CMO take on tying every record — CAPA, change, NCR, deviation, complaint — to a project. The principle is right. The execution is harder than the article made it sound.
The shape of the problem at a CMO
We run three OEM programs concurrently. Each has its own DMR, its own BOM, its own supplier list, and its own regulatory framework — one is UKCA / EU MDR Class IIa, one is 510(k) Class II, one is CE Class I sterile-packaged. When a supplier sends an NCR or we open an internal deviation, the first question is always: which OEM project does this belong to?
If the answer is "I don't know" or "probably the main one," you have already lost the thread. The rest of your QMS — risk file, design history, CAPA effectiveness — reads as noise.
What the standards actually require
- ISO 13485:2016, clause 7.5.8 — identification of each product with the relevant drawings, specifications, and regulatory requirements
- ISO 13485:2016, clause 8.3.4 — design and development controls, including traceability between inputs and outputs
- ISO 13485:2016, clause 4.1.4 — change control with evaluation of impact and resulting actions
- EU MDR, Article 10(9) and Annex VIII — traceability obligations that scale with device class
The text does not say "use a project ID." It asks for the chain of evidence from device → process → record → decision. Project-scoped work is the practical mechanism for making that chain defensible, particularly when you have multiple OEM customers sharing a plant.
What I tried, and what broke
First pass: a mandatory project dropdown on every NCR, CAPA, and change record.
It failed in three quiet ways:
- Operators defaulted to whichever project they were working on that day
- Engineers created a fourth "miscellaneous" bucket to escape the constraint
- The audit trail looked clean on paper, untrue in spirit
Second pass: project ID auto-derived from the part number or work order reference, with manual override only for genuinely cross-project records.
This worked because the part already knows its project. Humans cannot lie about a part number. Three additional disciplines had to follow:
- The project field becomes read-only after a record opens; reassignment is a separate event
- The cross-project CAPA requires an explicit justification and the project owners of every affected program must sign
- Project metadata pulls in the OEM customer, regulatory classification, and notified-body framework automatically
The boring bits are what made the system hold up at our last OEM audit. The interesting bits — the AI, the dashboards, the predictive models — are useless if the project field is wrong.
The change-control half of the lesson
ISO 13485 clause 4.1.4 does not just ask for change control, it asks for evaluation of impact and resulting actions. Project context is what lets an engineer write "this change affects the Class IIa sterile barrier packaging for OEM Customer B, lot release scheduled for week 14" instead of "this is a process change."
Without project scope:
- Risk assessment is generic
- Reviewer assignment is whoever is around
- Verification and validation scope is unbounded
- Customer notification timing slips
With project scope, the right people get notified, validation is bounded, and the customer's own change-control window can be planned against. Tying change to a project is what turns impact assessment from a paragraph of words into a checklist of names.
What I would do differently if I started fresh
- Mandate project scoping at intake, not at closure — we left it late and paid for it in backfilled audit evidence
- Build the project registry from the OEM purchase order upward, not from internal departments downward
- Treat cross-project impact assessment as its own documented step, with its own approval, not as an afterthought
- For CMOs specifically: the OEM customer's device master record should anchor your project metadata, not the other way around. They are the regulatory entity. You are the producing entity.
The honest caveats
Project-scoped work slows things down. Engineers complain about the extra dropdown. Cross-project CAPAs need more signatures, more review, more time. The benefits show up at audit, in OEM customer meetings, and in your own incident review — not in monthly throughput numbers. If your CMO has fewer than five projects and three suppliers, you can probably get away with lighter discipline for now. At our scale, it is the only defensible way to work.
One thing I have not yet figured out, which is what I would like to hear from other contract manufacturers:
When the same part ships to two OEM customers under two different specifications and two different regulatory frameworks, do you split the part number on your side to force two project records, or do you keep one part number and split only the project record with two trace chains underneath?
Top comments (0)