Project management in an ISO 13485 environment has a strange shape. The quality side of new product development is heavily systematised: design controls, document control, CAPA, and management review all live in the QMS, with auditors checking them on a defined cycle. The delivery side, the schedule, the budget, the resource plan, and the decision to proceed, usually lives nowhere in particular. A planning file one person can open, a budget spreadsheet, and a risk log nobody has updated since the last design review.
The result is a team that can prove its product is compliant but cannot say with confidence when the project will finish, what it will cost, or who decided to proceed at the last milestone. This post is about closing that gap without making the mistake most teams make: trying to bend the QMS into a project management tool.
What ISO 13485 Actually Asks of Your Project Planning
Clause 7.3 of ISO 13485:2016 requires design and development to be planned: stages defined, reviews held at suitable points, verification and validation activities identified, responsibilities assigned, and records kept. Notice what it does not say. It does not say how to schedule the work, manage the budget, balance engineers across three concurrent introductions, or escalate a slipping milestone. The standard defines the quality evidence a development project must produce. It is silent on how the project is actually run.
That silence is where most NPI pain lives. An auditor will find your design review records. Your managing director cares whether the launch date is real. Those are two different systems of truth, and pretending one tool can serve both is how teams end up in trouble.
The core principle: ISO 13485 is a quality standard, not a project management standard. It defines what evidence you must produce. A separate project system defines how you will produce it, on time and within budget.
The Two Failure Modes in Regulated NPI Teams
Failure mode one: the QMS becomes the project tool. Every schedule update becomes a controlled document revision. Planning slows to the pace of document control, so the team stops updating the plan, and the official schedule is permanently three weeks stale. The QMS was built to control documents, not to manage moving work.
Failure mode two: delivery runs on scattered files. The schedule, budget and risks live in separate spreadsheets owned by separate people. Before each design review, someone spends days retrofitting evidence, assembling the story of decisions that were actually made in corridors and email threads. The audit trail exists, but it is reconstructed, not recorded.
Both failure modes are common in 50 to 500 person manufacturers. Both are fixable without replacing your QMS or hiring a programme management consultant. They require one thing: treating the delivery side of NPI as a system in its own right.
The Working Model: Two Systems, One Set of Gates
The teams that handle this well keep two systems with a clear boundary and connect them at the gates:
The QMS holds quality records
- Design inputs and outputs
- Verification and validation evidence
- Design history file (DHF)
- Risk management file (ISO 14971)
- Change control records
The project system holds delivery
- Project charter and scope
- Work breakdown structure and Gantt
- Live budget and cost tracking
- Project risk register
- Resource plan and capacity view
Phase gates join the two. Each gate has a checklist that references the QMS records required at that point without duplicating them. The gate decision (proceed, hold, recycle, stop) is recorded in the project system with a named approver and a date. Align your gates with your design control milestones and one meeting can serve both: the design review the standard requires and the business decision the project needs.
If you are new to structuring gates, start with our guide to what a phase gate review should cover. The gate checklist is where the two systems talk to each other.
Project Risk Is Not Product Risk
One distinction worth being strict about: ISO 14971 risk management is about harm to patients and users. It belongs in the QMS, owned by quality and regulatory people, and it follows the product for its whole commercial life. Project risk is about harm to the project: a supplier slipping, a key engineer leaving, a test rig arriving three weeks late. It belongs in the project risk register, owned by the project manager, and it is closed when the project closes.
Teams that merge these into one list serve neither purpose. The product risk file gets cluttered with schedule worries an auditor has no interest in, and project risks inherit a documentation burden that guarantees nobody will update them. Keep them separate, and reference across only where one genuinely creates the other, for example where a supplier delay affects a validation timeline, creating a product risk exposure.
Common mistake: Recording a schedule slip as an ISO 14971 risk. A late delivery is a project risk. It only becomes a product risk if the delay forces a design change or validation shortcut. Track each in its proper place.
The Five Project Elements Every ISO 13485 NPI Needs
A workable setup for a 50 to 500 person manufacturer looks something like this:
| Element | What it covers | Why it matters in a regulated environment |
|---|---|---|
| Project charter | Scope, sponsor, budget authority, success criteria | Names the person who can stop the project at a gate; prevents scope creep mid-development |
| WBS and schedule | All work packages, dependencies, milestones, critical path | Shows whether validation, design transfer and launch can still be met when a phase slips |
| Gates aligned to design reviews | Go/no-go decisions with QMS checklist references | One meeting serves the auditor and the MD; decision is recorded, not assumed |
| Project risk register | Delivery risks only; separate from ISO 14971 file | Keeps the QMS clean; ensures project risks actually get reviewed and owned |
| Budget and resource visibility | Actual vs planned spend and hours by phase | A slip shows its cost the day it happens, not at month end when the damage is done |
Where to Start if Your Projects Currently Run on Spreadsheets
Do not try to fix everything at once. Pick the next NPI programme and give it three things: an approved project charter, gates aligned to its design reviews, and a risk register that is actually reviewed at each gate. Run it that way once and the case for doing it everywhere makes itself.
The common objection is that this adds overhead. In practice, it reduces overhead. The time teams spend reconstructing a decision trail before an audit, or figuring out why the schedule slipped by two months without anyone noticing, is far greater than the time spent keeping a live project system updated. The overhead is already there. You are just not getting the benefit of it.
If you want to know how mature your current setup is before you change anything, our free PM maturity assessment takes ten minutes and benchmarks you across twelve knowledge areas, including governance and risk. The broader governance framework behind this approach is also described in our complete ISO 21502 guide. ISO 21502 is, in effect, the delivery-side companion to the quality standards your organisation already follows.
Frequently Asked Questions
What does ISO 13485 require from a project management perspective?
ISO 13485 Clause 7.3 requires design and development to be planned, with stages defined, reviews held at suitable points, verification and validation activities identified, and responsibilities assigned. It defines the quality evidence a development project must produce. It does not specify how to schedule work, manage budgets, or escalate slipping milestones. That gap is where project management fills in.
Should a project risk register be part of the QMS in a medical device company?
No. ISO 14971 risk management covers harm to patients and users; it belongs in the QMS and follows the product for its whole life. Project risk covers harm to the delivery of the project, such as a supplier slipping or a test rig arriving late. Keep them in separate registers with different owners. Merging them creates audit clutter in the QMS and ensures project risks never get properly updated.
How do phase gates relate to design reviews in an ISO 13485 environment?
Design reviews are a quality requirement under ISO 13485 Clause 7.3.5; phase gates are a project governance decision point. In practice, they can be run as a single meeting if the checklist covers both. Each gate should reference the QMS records required at that point without duplicating them, and should record a named business decision: proceed, hold, recycle, or stop. Aligning the two saves time and creates a single source of truth for auditors and management.
What is the difference between a QMS and a project management system in med-tech?
A QMS is a controlled document environment that holds compliance evidence: design records, validation reports, CAPA logs. It is audited by regulatory bodies and must meet ISO 13485. A project management system holds delivery information: the schedule, budget, resource plan, and project risk register. It is used daily by the project team. Both are necessary. Using the QMS as a project tool slows planning down to the pace of document control.
See How Structured Project Governance Works Alongside Your QMS
A 20-minute call is enough to show you the exact setup: charter, gates, risk register and schedule in one place, without touching your QMS.
Book a Discovery Call