The Phase Gate Process is a structured project management method that splits medical device development into defined phases separated by decision points called gates. At each gate, a cross-functional team reviews deliverables against preset criteria and makes a go, no-go, or hold decision before the project consumes further 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 creates the audit trail regulators expect. Under the FDA Quality Management System Regulation (QMSR), effective February 2, 2026, design controls are enforced through ISO 13485:2016 Clause 7.3, and the former 21 CFR 820.30 text is now reserved. A well-run phase gate process produces the design and development records, review minutes, and approvals that demonstrate compliance during an FDA inspection or a notified body audit under EU MDR 2017/745. Without gate records, a team is left reconstructing decisions after the fact.
How the Phase Gate Process works
A typical medical device phase gate structure includes:
- Concept and feasibility gate: confirms user needs, intended use, a preliminary risk assessment (ISO 14971), and the business case before formal design starts.
- Design input gate: locks the design and development inputs and requirements the device will be built against.
- Design output and verification gate: confirms design outputs meet inputs, backed by verification testing evidence such as electrical safety per IEC 60601-1 and software per IEC 62304 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 the design is correctly translated into manufacturing specifications and the process is validated through IQ/OQ/PQ.
Each gate has three ingredients: entry criteria (the deliverables due), review by the right cross-functional owners (R&D, quality, regulatory, manufacturing, and often clinical), and a documented decision. The design and development review requirements of ISO 13485 Clause 7.3.5 map directly onto these gate reviews, including the need to identify problems and propose 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 runs phase-gate program management as part of its end-to-end device design and engineering service. Its teams take programs from concept and feasibility through architecture, design, verification, and design transfer, with change control applied at each stage. Risk management to ISO 14971 and usability engineering to IEC 62366-1 are built into the gate structure rather than bolted on afterward. In-house labs support verification activities such as IEC 60601 electrical safety, EMC, and reliability testing, which keep gate decisions grounded in real evidence and help shorten time to market.
Talk to SJML’s engineering team →
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.
Related terms
- Design Controls
- Design Review
- Design Verification
- Design Transfer
- Risk Management (ISO 14971)
