Most projects do not go wrong because the idea was bad. They go wrong because nobody was checking at the right moments. Budget drifts. Decisions get made informally. A key person leaves. By the time someone notices, the project is months off track and the fix costs more than catching it early would have.
A phase gate review process is the simplest way to prevent this. It breaks your project into phases, puts a formal checkpoint between each one, and makes sure the project is genuinely ready before it moves forward. No rubber stamps. No "we'll sort that in the next phase." Ready means ready.
What Is a Phase Gate Review?
A phase gate review is a structured checkpoint between project phases. The team stops, reviews a short list of key deliverables, and makes a decision: go forward, hold until something is fixed, or cancel.
That is it. The power is not in the framework. The power is in the discipline of actually stopping, actually checking, and actually making a decision before spending more time and money.
A gate that passes automatically is not a gate. If your review always ends in a green light regardless of what the team presents, the review has become a formality. Gates need teeth to be useful.
The Four Phases of a Project
Four phases cover everything from the first idea to the final handover. Each phase has a clear question it needs to answer before the project moves on.
Concept
Do we have a good idea, a clear plan, and the commitment to deliver it?
Design and Build
Are we building the right thing, in the right way, with the right resources?
Test and Verify
Does it work? Is there objective evidence that it meets what was required?
Launch and Close
Are we ready to go live, and have we properly handed over and closed out the project?
What to Review at Each Gate
Each gate has a short list of things that must be complete before the project advances. Not in progress. Complete. The list does not need to be long. It needs to be honest.
Gate 1: Concept Approval
The question: do we have a genuine case to proceed?
| What to Check | Why It Matters |
|---|---|
| Project Charter signed by the Sponsor | Without a signed charter, there is no formal commitment from anyone. Scope disputes and budget debates later have no reference point. |
| Business case confirmed | Is there a real market or clinical need? If this question has not been answered properly, everything that follows is building on sand. |
| Rough budget estimate agreed | Not a precise number, but a realistic envelope. If the budget available and the budget required are not in the same ballpark, now is the time to find out. |
| Key risks identified | A short list of the things most likely to derail the project. Not a 40-row register. The five things that would actually stop it. |
| Team and resources confirmed | Named people, confirmed availability. "We assume engineering will have capacity" is not a resource plan. |
Gate 2: Design Freeze
The question: is the design complete and do we have the plan locked to deliver the rest?
| What to Check | Why It Matters |
|---|---|
| Design outputs complete and verified against agreed requirements | You cannot test whether something works if the design is still changing. A frozen design is the reference point for all testing in Phase 3. |
| Schedule baseline set and being tracked | A schedule that has never been baselined cannot show variance. If the project is late, late compared to what? |
| Budget baseline set and being tracked | Same principle. Overspend against what? A baseline makes cost variance visible before it becomes a crisis. |
| Risks and issues log active and reviewed | This should be a live document, reviewed regularly. If it was created and never opened since Gate 1, that is a red flag. |
| Key dependencies confirmed | Third-party suppliers, lab bookings, regulatory submissions. Anything the project is waiting on that is outside the team's direct control. |
Gate 3: Launch Readiness
The question: is there objective evidence that this is ready to launch?
| What to Check | Why It Matters |
|---|---|
| Testing complete with signed-off results | Complete means signed off, not nearly done. A test that is 90% complete is an incomplete test. |
| All open issues resolved or formally accepted | Every issue should have a status: closed, or accepted with a documented reason. Issues carried forward informally become problems after launch. |
| Schedule and budget variance reviewed by the Sponsor | If the project is significantly over budget or behind schedule, the Sponsor must make an explicit decision to proceed, not assume it will sort itself out in Phase 4. |
| Operations and handover plan agreed | Who is taking ownership after launch? What do they need to run it? If this has not been agreed before Gate 3, Phase 4 will be chaotic. |
| Regulatory submission status confirmed (where applicable) | For regulated products, the status of any required submission must be documented. A verbal "we expect to have it" is not a confirmed status. |
Gate 4: Project Closure
The question: has everything been properly handed over and documented?
| What to Check | Why It Matters |
|---|---|
| Handover to operations complete and signed off | The project team should not be the people keeping the product running. A formal handover transfers that responsibility clearly. |
| All project documentation archived | If knowledge only lives in people's heads, it leaves when they do. |
| Final budget versus plan recorded | The cost data from this project is the most accurate input you have for estimating the next one. |
| Lessons learned captured | This needs to happen now, while people remember. A session scheduled for "after things settle down" rarely happens. |
| Team formally released from the project | People cannot be properly committed to the next project if they are still nominally assigned to this one. |
What If a Project Is Cancelled?
Cancellation is not a failure. Stopping a project at Gate 1 because the business case does not hold is the gate process doing exactly what it should. The question is not whether to cancel. The question is whether to cancel properly.
An informal stop is not a project closure. It leaves people unsure of their commitments, costs unrecorded, and risks unresolved. In regulated industries, incomplete project records can create audit findings long after the work has stopped.
When a project is cancelled at any gate, the following should be completed before everyone moves on: a short closure report documenting the decision and the reason behind it, final costs recorded against the original budget, the risk log formally closed, all completed work archived, and the team formally released so their availability is clear for other projects.
Who Should Approve at Each Gate?
Gate approvals work because each approver is formally confirming that their part of the project is ready. When a gate passes and something later turns out not to have been ready, there is a record of who confirmed it and when. That creates accountability, which is what makes gate reviews meaningful rather than ceremonial.
| Role | Gate 1: Concept Approval | Gate 2: Design Freeze | Gate 3: Launch Readiness | Gate 4: Project Closure |
|---|---|---|---|---|
| Project Sponsor Owns the budget and business case |
Required | Required | Required | Required |
| Project Manager Owns the schedule and risk log |
Required | Required | Required | Required |
| Engineering Lead Owns the technical work |
Required | Required | Required | Recommended |
| Quality Owns testing standards and compliance |
Optional | Required | Required | Required |
| Regulatory Affairs Owns regulatory submission readiness |
Optional | Recommended | Required | Required |
| Operations Owns the handover and go-live |
Optional | Optional | Required | Required |
How Arcturus Pro Supports This
Arcturus Pro is built around this exact structure. Each of your four phases is fully configurable: you name them to match your team's existing language, set the approvers for each gate, and track the status of every deliverable in one place. When a gate review is due, everyone can see what is ready and what is not, without a single spreadsheet.
The gate review becomes a 30-minute decision backed by live programme data, not a two-day preparation exercise before every meeting.
Frequently Asked Questions
What is a phase gate review?
A phase gate review is a checkpoint between project phases where a team stops and asks: are we ready to continue? Key deliverables are reviewed, a decision is made to go forward, hold, or cancel, and the project only advances when it is genuinely ready. It prevents teams from spending money on work built on shaky foundations.
How many phases should an NPI project have?
Four phases works well for most NPI projects: Concept, Design and Build, Test and Verify, and Launch and Close. Four phases give you enough checkpoints to catch problems early without adding overhead that slows the project down unnecessarily.
Who should approve a phase gate review?
The Project Sponsor approves every gate, because they own the budget and the business case. The Project Manager confirms the project is on track. The Engineering Lead confirms the technical work is ready. Quality and Regulatory Affairs should be included from Gate 2 onwards in regulated manufacturing environments.
What happens if a project is cancelled at a gate?
A cancelled project still needs to be formally closed: document the reason for cancellation, record final costs against the budget, close the risk log, release the team, and archive completed work. An informal stop leaves open commitments and, in regulated industries, incomplete records that can surface as audit findings later.
Book a Discovery Call
See how Arcturus Pro structures phase gate reviews, RAIDS logs, and project governance for regulated manufacturing NPI teams in Ireland and Europe. A 30-minute call, no obligation.
Book a 30-Minute Discovery Call