Three change controls, two supplier CAPAs, and one design transfer were sitting in my queue last Tuesday. I knew the dates from the project plan. I knew the approval status from the eQMS. I did not know, at a glance, which project epic owned the change control that owned the supplier CAPA. That gap — between "what the project says we are doing" and "what the QMS says we have approved" — is the gap the Managing Through Quality (MTQ) model tries to close.
The split that costs you audit points
Most CMOs I have worked with or talked to run two parallel systems. The project plan lives in Jira, Azure DevOps, MS Project, or even a spreadsheet that everyone is afraid to delete. The QMS lives in a separate eQMS — sometimes a heavyweight validated platform, sometimes a document-only system with a QMS label stapled on. CAPAs, change controls, document approvals, training assignments, supplier qualification — all of these are quality workflow processes, but they are tracked separately from the project work that triggers them.
The cost shows up in three places that matter at audit:
- Findings where a notified body auditor asks, "show me the link between this design transfer project and the change controls it spawned," and the answer requires three manual joins across two systems and a screenshot from someone's desktop.
- Stale document states where the project moves on but the document control workflow lags behind by a sprint.
- CAPA investigations that start late because nobody mapped the project task to the quality event in time.
None of this is a tooling problem on its own. It is a workflow design problem wearing a tooling costume.
What MTQ actually means
A walkthrough I revisited recently put the MTQ model very simply: QMS workflow processes are driven by project management. Not the other way around. The project is the spine; the QMS activities — change control, CAPA, document approval, risk review, training, supplier qualification — are the ribs hanging off it. Every quality event has a parent project task. When the project task closes, the QMS records show that. When a quality event opens, it was triggered by something in the project plan, and you can see why.
This sounds obvious written down. In practice it almost never happens, because most eQMS platforms were designed the other way: QMS first, project as an afterthought or a separate module bolted on. And most project management tools were not designed with audit-grade evidence in mind. The two communities talk past each other, and the CMO sits in the middle holding the join key.
How it looks in practice at a CMO
At our plant, the workflow now runs roughly like this:
- A new product introduction from an OEM customer opens as a project — milestones, owners, Gantt, the usual.
- Every milestone that touches a controlled document, a process change, a supplier, or a risk gets a child task that links to a QMS record type.
- The change control does not exist as a free-floating record; it is opened from the project task. The project task cannot be marked complete until the change control reaches an approved state.
- CAPAs triggered by a non-conformance attach to the project task where the non-conformance was logged. Investigation, root cause, effectiveness check — all of it visible from the project view, not buried in a separate queue.
- Document approvals and training assignments are routed off the same backbone, with status pulled back into the project dashboard so the PM sees what is actually approved and what is only drafted.
For a CMO with three OEM customers and forty-plus component suppliers of our own, this is the difference between "we trust the spreadsheet" and "we can show the auditor the chain in two clicks." Under ISO 13485 clause 4.1.5 and EU MDR Article 10, the responsibility for traceability and documented evidence does not get weaker when you outsource manufacturing — it gets stronger.
Where document-only systems fall short
A lot of tools marketed as QMS are actually document management systems with quality fields attached. You can route a document for approval, you can stamp a training record, you can file a CAPA form. But the workflow processes — change control, CAPA, risk management, supplier qualification — are not first-class objects that drive other objects. They are forms. Forms do not run a quality system. Workflow processes, with state, ownership, linkages, and triggers, do.
This is the practical gap MTQ names. Project management drives the workflow. The workflow produces the evidence. The evidence satisfies the standard. Break any link in that chain and the audit becomes archaeology — and your CAPA queue gets longer than it already is.
What I would still do differently
Two things, honestly.
First, I would push harder on the "project task cannot close until the QMS record is approved" rule earlier. We let it be a soft convention for too long, and the gaps only showed up at internal audit. Making it a hard gate cost us a few arguments with project managers who wanted to close milestones fast. Worth every tense meeting.
Second, I would not have assumed the project tool and the QMS would talk to each other cleanly. They never do without explicit integration work. Budget for it, and if you are evaluating both at the same time, ask how change controls, CAPAs, and document approvals are linked to project tasks — and ask to see it live, not on a slide.
The MTQ framing is not a product pitch. It is a way of organising work so that the project plan and the quality system stop contradicting each other. Once you have run a notified body audit with both views aligned, you do not go back.
For those of you running a CMO or a smaller OEM — how are you keeping your project plan and your QMS records joined today? Spreadsheet, custom integration, native linking, or two uncomfortable truths?
Top comments (0)