When I run a QMS rollout now, I run it the same way every time. Five phases. Same kickoff memo. Same deliverables checklist. Same exit criteria. The first three rollouts I did, I improvised — and every improvisation taught me something the next client had to pay for. This is the partner-side flow I now bring into every engagement, end to end.
A bit of context. I've been on both sides of this — a QA tech lead at a contract manufacturer for over a decade, and now taking on a handful of consulting engagements on the side. The plants I work with are Class I and Class IIa device shops, mostly 20 to 80 heads, often running paper-based QMS or a half-deployed eQMS that nobody finished rolling out. The pattern is depressingly consistent: somebody bought a tool two years ago, configured 40% of it, and the rest is held together by shared drives and tribal knowledge. My job is to take that mess and land it on the other side of an ISO 13485 audit with the system actually used, not just configured.
Here's how I structure the work.
Phase 1 — Discovery and gap framing (week 1)
No templates yet. No tool config. Just three things in the first five days:
- A process map of the as-is QMS: how a CAPA actually moves today, where change requests sit, who owns what.
- A gap list against ISO 13485 clause by clause, with the gaps scored by audit risk, not by document count.
- A short list of "showstoppers" — things that would fail a notified body audit today, full stop.
I write this up in a single memo, two to three pages, no slides. The first rollout I did, I produced a 60-page discovery report. The client read none of it. Now I write the memo the way I write a CAPA executive summary — the auditor will read the first page and skim the rest.
Phase 2 — Configuration and document architecture (weeks 2-4)
This is where most consultants burn trust. They disappear into the tool for three weeks and come back with a configured system nobody asked for. The fix is simple: the document architecture is decided before configuration, in a half-day workshop with the QA manager and the process owners.
The non-negotiable outputs from the workshop:
- One controlled document hierarchy (policy, SOP, work instruction, form, record).
- A record-retention matrix that matches the client's markets — EU MDR, FDA 21 CFR Part 820, MDSAP, UKCA — not a generic 7-year rule.
- A naming convention that survives the next two reorgs.
Configuration then follows the architecture. Not the other way around.
Phase 3 — Pilot on one process, end to end (month 2)
Pick one process and run it through the configured system, end to end, with real records. Not a sandbox. Not a demo dataset. A real CAPA, a real change, a real complaint, opened by the people who will own these records after go-live.
The pilot catches things no UAT script will. It catches the form field that's mandatory in the tool but meaningless to the business. It catches the workflow that nobody explained to the people who'll actually use it. It catches the integration that "works in staging" and breaks on day one.
I run the pilot for three weeks minimum. Less than that, and you're testing the tool, not the rollout.
Phase 4 — Training that isn't a recording (months 2-3)
Every QMS rollout I've watched die has died in training. Not because the training was bad — because it was the same generic recording played for everyone from the QA manager to the line operator.
What I do instead:
- Role-based sessions: QA/RA, process owners, end users, system admins. Different curricula, different durations.
- Each session ends with the user opening the system and doing their job in front of me. Not a demo — their actual workflow.
- A one-page "where do I do X" cheat sheet for each role. Print it. Laminate it. Tape it to the monitor.
Recording-based training is a regulatory convenience and a learning disaster.
Phase 5 — Hypercare and audit-readiness check (month 3 onward)
The last 30 days before go-live is hypercare — I'm on call, the client is using it for real, and we meet twice a week to triage issues. But hypercare isn't just "fix the bugs." It's an audit-readiness walk-through:
- Pull a random CAPA and trace it through the system, record by record.
- Pull a random change and confirm the impact assessment links to the right documents.
- Pull a random complaint and confirm the investigation timeline is reconstructable.
If any of those traces breaks, the rollout isn't done. The tool is configured; the system isn't.
What I'd do differently now
Three things, looking back:
Set the exit criteria in writing on day one. "Done" means different things to the consultant, the QA lead, and the CEO. Pick one definition. Mine is: the client passes a Stage 1 audit using only the new system.
Charge for change management, not configuration. Configuration is the cheap part. The hard part is getting 30 people to use the system instead of their old shared drive. If your SOW has 70% configuration and 15% change management, the rollout is going to fail and it's not going to be the tool's fault.
Don't promise a go-live date in week one. Promise a go-live window. The honest answer at kickoff is "between week 12 and week 18, depending on pilot results." Anyone who gives you a date in week one is selling.
What the standard actually asks for
ISO 13485 clause 4.1.6 is the line I keep coming back to: "the organisation shall document procedures for the validation of the application of computer software used in the quality system." Validation isn't configuration. It's the documented evidence that the system does what you say it does, in the client's environment, with the client's users. Every rollout I've seen skip validation has come back to bite at audit.
Question for the consultants here: what's the one phase you always run the same way, regardless of client size or industry? I'm curious whether there's a phase I'm under-weighting.
Top comments (0)