The Phase-Gate Process is a structured project-management method that divides medical device development into defined phases separated by decision points called gates. At each gate, a cross-functional team reviews deliverables against predetermined criteria and makes a go, no-go, hold or conditional-go decision before the project consumes additional resources.
What is the Phase Gate Process?
The Phase Gate Process, also called the stage-gate process, breaks a development program into sequential phases. For a device, this typically runs from concept and feasibility through design, verification and validation, design transfer, and launch. Each phase ends at a gate, where predefined deliverables must be complete and approved before work moves on.
In regulated MedTech, gates map closely onto the design and development stages required by design controls. A gate is not a status meeting. It is a formal decision checkpoint with documented entry and exit criteria, a defined approval authority, and a recorded outcome.
Why the Phase Gate Process matters in medical device development
Rushing gates is one of the most expensive mistakes a device program can make. A design flaw caught at the concept gate costs a fraction of the same flaw caught during design validation or, worse, after launch through a field complaint or recall.
Gates also create the audit trail regulators expect. Under the FDA Quality Management System Regulation, design controls are enforced through ISO 13485:2016 Clause 7.3. A properly managed phase-gate process produces the plans, design records, review minutes and approvals needed to demonstrate medical device regulatory compliance during FDA inspections and notified-body audits under EU MDR 2017/745.
How the Phase Gate Process works
A typical medical device phase gate structure includes:
- Concept and feasibility gate: Confirms user needs, the device’s intended use, preliminary ISO 14971 risk assessment, technical feasibility and business case before formal design begins.
- Design input gate: locks the design and development inputs and requirements the device will be built against.
- Design output, verification and validation gates: Confirm through documented verification and validation (V&V) evidence that design outputs meet approved inputs and that production-equivalent devices meet user needs and intended use. Evidence may include IEC 60601-1 electrical-safety testing and IEC 62304 software testing where applicable.
- Design validation gate: confirms the device meets user needs and intended use, usually with production-equivalent units.
- Design transfer and launch gate: Confirms that approved design outputs have been translated into controlled specifications for repeatable medical device manufacturing, with production readiness and required IQ, OQ and PQ process-validation evidence completed.
Each gate requires three elements: defined entry criteria, review by the appropriate cross-functional owners, and a documented decision. A maintained Requirements Traceability Matrix (RTM) helps reviewers confirm that user needs, design inputs, outputs, risk controls and V&V evidence remain connected as the program moves between gates. ISO 13485 Clause 7.3.5 also requires design and development reviews to identify problems and propose necessary actions.
The go/no-go decision is the point of the whole exercise. Typical options are go (proceed), no-go (kill the project), hold (pause pending fixes), or conditional go (proceed while closing named actions).
Common challenges and best practices
The most common failure is the rubber-stamp gate: a review held for form’s sake where no one is empowered to say no. If every gate is a go, the gates are not doing their job.
Teams also overload early gates with deliverables that cannot realistically be completed yet, then waive them, which erodes discipline. Better to define lean, meaningful exit criteria per gate and hold to them.
A few practices separate strong programs from weak ones:
- Tie gate criteria to the design and development plan and the risk management file, not to a generic template.
- Give quality and regulatory real veto authority, not observer status.
- Keep gate records lightweight but complete: decision, rationale, open actions, owners, dates.
- Treat conditional approvals as tracked commitments, not loopholes.
Change control matters between gates too. When inputs shift after a gate closes, the affected deliverables need re-review rather than a silent update.
How SJML helps with the Phase Gate Process
SJML applies phase-gate program management across end-to-end device development, taking programs from concept and feasibility through architecture, detailed design, verification and design transfer. Change control is applied at each stage, while ISO 14971 risk management and IEC 62366-1 usability engineering are built into the gate structure. In-house laboratories support IEC 60601 electrical-safety, EMC, reliability and environmental testing, keeping gate decisions grounded in objective evidence.
Frequently asked questions
A phase is a block of development work, such as design input or verification, with its own deliverables and objectives. A gate is the decision point at the end of a phase where a cross-functional team reviews those deliverables against exit criteria and decides whether to proceed. Phases are where work happens; gates are where go or no-go decisions are made.
The FDA does not mandate a specific phase gate process by name. It requires design controls, now enforced through ISO 13485:2016 Clause 7.3 under the QMSR effective February 2026. A phase gate process is a common, practical way to meet those requirements, particularly the design and development planning and review obligations, but the method itself is a choice, not a rule.
There is no fixed number. Most device programs use four to six gates, aligned to the main design and development stages: feasibility, design input, verification, validation, and transfer. The right count depends on device risk class and complexity. A Class III implant may need more granular gates than a low-risk Class I accessory. Match gate granularity to risk, not to a template.
Gate approval is a cross-functional decision, not a single manager’s call. Typical approvers include engineering or R&D, quality assurance, regulatory affairs, and manufacturing, with clinical input where relevant. Quality and regulatory should hold genuine authority to stop or hold a program. The design and development review under ISO 13485 Clause 7.3.5 expects representatives of the functions concerned to take part.
