Conducting Phase Gate Reviews in the Waterfall Model
This skill teaches you how to run formal gate reviews at the end of each Waterfall phase to validate deliverables, secure stakeholder sign-off, and make go/no-go decisions that authorize progression to the next phase.
To conduct phase gate reviews, assemble key stakeholders at the end of each waterfall phase, evaluate deliverables against predefined exit criteria, document any deficiencies, and formally decide whether to approve progression, reject with rework requirements, or conditionally approve with action items. Each gate should produce a signed decision record authorizing the next phase.
Outcome: You will be able to design and facilitate rigorous phase gate reviews that catch defects early, keep stakeholders aligned, and ensure each waterfall phase is truly complete before the project advances.
Prerequisites
- Understanding of the Waterfall methodology and its sequential phases
- Familiarity with project deliverables and acceptance criteria
- Basic stakeholder management experience
- Knowledge of creating Waterfall project plans
Overview
Phase gate reviews are the critical quality checkpoints that give the waterfall model its disciplined, sequential structure. At the boundary between each phase—requirements to design, design to development, development to testing—a formal gate review brings together stakeholders and subject matter experts to inspect deliverables, verify that exit criteria have been met, and make an explicit go/no-go decision. Without these gates, the waterfall model loses its primary advantage: the confidence that downstream work rests on a validated foundation.
In practice, many teams skip or rush gate reviews, treating them as rubber-stamp formalities. This undermines the entire methodology. A well-conducted gate review surfaces ambiguities in requirements documents, design inconsistencies, and resource gaps before they compound into expensive rework. It also creates a clear accountability record—every stakeholder who signs off shares ownership of the decision to proceed.
This skill covers the end-to-end process of preparing for, facilitating, and documenting gate reviews within a Waterfall project. You'll learn how to define exit criteria, structure the review meeting itself, handle disagreements, and produce decision records that protect the project and its team.
How It Works
The phase gate review mechanism works on a simple but powerful principle: no phase transition without explicit validation. Each phase in the waterfall model produces defined deliverables—a requirements specification, a system design document, tested code, and so on. The gate review is the formal ceremony where those deliverables are measured against pre-agreed exit criteria.
Conceptually, each gate has three possible outcomes: Go (all criteria met, proceed to next phase), No-Go (critical gaps exist, return to current phase for rework), or Conditional Go (minor items outstanding, proceed with documented action items and deadlines). This trinary decision model prevents the dangerous middle ground where teams proceed despite known issues but without a plan to resolve them.
The power of gate reviews comes from several reinforcing dynamics. First, the existence of a gate motivates teams to complete work thoroughly rather than leaving loose ends. Second, the multi-stakeholder review catches blind spots that a single team might miss. Third, the formal sign-off creates shared accountability—if requirements are approved at the gate, the business cannot later claim they were never agreed upon. This is why the waterfall model, when executed properly with rigorous gates, remains effective for projects with regulatory compliance needs, fixed contracts, or safety-critical systems.
Gate reviews also serve as natural synchronization points for project plans and Gantt charts, giving project managers concrete milestones to track progress against the baseline schedule.
Step-by-Step
Step 1: Define Exit Criteria Before the Phase Begins
Exit criteria should be established at the start of each phase, not invented at the end. Work with the project sponsor, technical leads, and quality assurance to define specific, measurable criteria that deliverables must satisfy. For a requirements phase, exit criteria might include: all functional requirements traced to business objectives, all non-functional requirements quantified, requirements document reviewed by at least two subject matter experts, and no open TBD items remaining.
Document these criteria in a gate review checklist that will be used during the actual review. Each criterion should be binary—met or not met—to prevent subjective interpretation during the gate meeting. Where quantitative thresholds are appropriate (e.g., test coverage percentages, defect density limits), specify the exact numbers.
Make sure all team members know the exit criteria from day one of the phase. This gives them a clear target and prevents surprises at the gate.
Tip: Store exit criteria in the same document repository as your project plan so they're always accessible. Consider creating a standardized template with common criteria for each waterfall phase that you customize per project.
Step 2: Prepare the Gate Review Package
One to two weeks before the scheduled gate review, the phase lead should assemble the gate review package. This package includes: all phase deliverables in their final or near-final state, a self-assessment against each exit criterion, a summary of any known issues or risks, and metrics collected during the phase (effort spent, defects found and resolved, scope changes processed).
Distribute this package to all gate reviewers with enough lead time for them to conduct a thorough review—typically 3-5 business days for complex deliverables. Specify exactly what you need reviewers to do: read the entire document, focus on specific sections, validate technical accuracy, or check regulatory compliance.
Include a pre-filled gate review form that reviewers can annotate with their findings. This structures their feedback and makes the actual gate meeting far more productive than an open-ended discussion.
Tip: Send a brief cover memo highlighting what's new or changed since any prior reviews. Busy stakeholders will engage more deeply if you respect their time and direct their attention.
Step 3: Schedule and Structure the Gate Meeting
Book the gate review meeting with all required attendees well in advance—these are often senior stakeholders whose calendars fill quickly. Define required vs. optional attendees clearly: required attendees must be present for the gate decision to be valid.
Structure the meeting with a clear agenda: (1) brief phase summary and context setting (5-10 minutes), (2) walkthrough of deliverables against exit criteria (bulk of the time), (3) discussion of open issues and risks (15-20 minutes), (4) formal go/no-go decision (10 minutes). For a typical phase gate, allocate 60-120 minutes depending on project complexity.
Assign a dedicated note-taker who is not the facilitator. The facilitator needs to manage the discussion, drive toward decisions, and handle conflicts—they cannot simultaneously capture accurate minutes.
Tip: Never combine a gate review with a status meeting or other agenda items. The gate deserves its own dedicated time block to signal its importance and ensure adequate focus.
Step 4: Facilitate the Review Against Exit Criteria
During the meeting, work through each exit criterion systematically. For each criterion, present the evidence that it has been met, allow reviewers to challenge or confirm, and record the verdict. Resist the temptation to skip criteria that seem obviously satisfied—the discipline of checking each one is what makes gates effective.
When reviewers raise concerns, distinguish between three categories: (a) showstoppers that must be resolved before proceeding, (b) important items that can be resolved in parallel with the next phase, and (c) observations for future phases. Categorizing issues in real-time prevents the discussion from spiraling into an unfocused debate.
If technical disagreements arise between reviewers, capture both positions and the evidence for each. If resolution isn't possible in the meeting, assign an owner and deadline for resolution before the gate decision is finalized.
Tip: Use a visible scorecard—projected on screen or shared document—and mark each criterion green, yellow, or red in real-time. This creates transparency and builds toward the final decision naturally.
Step 5: Make and Record the Formal Gate Decision
After reviewing all criteria, the gate decision authority (typically the project sponsor or steering committee) makes the formal decision: Go, No-Go, or Conditional Go. This should be an explicit, verbal declaration, not an implied conclusion.
For a Go decision, confirm the date the next phase will begin and any preparation needed. For a No-Go, specify exactly which criteria were not met, what rework is required, and when the gate will be re-reviewed. For a Conditional Go, document each condition with an owner, deadline, and escalation path if the condition isn't met.
Capture the decision in a gate review decision record that includes: date, attendees, criteria assessment results, decision, conditions (if any), and sign-off lines. Obtain signatures—physical or digital—from the decision authority and key stakeholders before the meeting concludes or within 24 hours.
Tip: A 'Conditional Go' should have no more than 3-5 minor conditions. If you're tempted to attach a dozen conditions, the honest decision is probably No-Go.
Step 6: Distribute the Decision Record and Track Conditions
Within 24 hours of the gate review, distribute the signed decision record to all stakeholders, the project team, and anyone affected by the phase transition. Store it in the project's controlled document repository alongside the reviewed deliverables.
If the decision was Conditional Go, add each condition to the project's issue or action item tracker with the assigned owner and deadline. Review progress on these conditions in the next phase's kickoff meeting and subsequent status meetings. If a condition misses its deadline, escalate to the gate decision authority immediately—do not let conditions quietly expire.
Update the project plan and Gantt chart to reflect the actual gate review date (which may differ from the baseline) and formally transition the project to the next phase.
Tip: Create a gate review log that tracks all gate decisions across the project lifecycle. This becomes invaluable for retrospectives and for demonstrating process compliance to auditors or clients.
Examples
Example: Requirements-to-Design Gate Review for an ERP Implementation
A mid-sized manufacturing company is implementing a new ERP system using the waterfall model. The requirements phase has just concluded, producing a 120-page Software Requirements Specification (SRS). The project manager needs to run the gate review before design begins.
The project manager established exit criteria at the start of the requirements phase: all functional requirements traced to business processes, all requirements reviewed by department leads, no open TBD items, and sign-off from the compliance officer on regulatory requirements.
Two weeks before the gate, the BA team completed the SRS and performed a self-assessment, finding 3 remaining TBD items related to inventory valuation methods. They escalated these to the finance director and resolved 2 of 3 before the gate package was distributed.
The gate review package was sent 5 business days before the meeting, including the SRS, traceability matrix, self-assessment checklist, and a note flagging the one remaining TBD item (a tax calculation edge case awaiting legal input).
During the 90-minute gate meeting, the team walked through each criterion. All passed except the TBD item. The compliance officer confirmed it was low-risk and wouldn't affect the initial design architecture. The steering committee issued a Conditional Go: proceed to design, with the TBD resolved within 10 business days and the SRS updated accordingly. The finance director was assigned as owner.
The decision record was signed, distributed, and the condition was tracked in the project's issue log. The item was resolved in 7 days, the SRS was updated, and the condition was formally closed.
Example: Design-to-Development Gate with a No-Go Decision
A government agency is building a citizen portal using the waterfall model. The design phase produced detailed system architecture and UI wireframes, but the security review revealed significant gaps in the authentication design.
Exit criteria for the design gate included: system architecture approved by the enterprise architecture board, UI designs validated against accessibility standards (WCAG 2.1 AA), security architecture reviewed and approved by the CISO's team, and all interface specifications documented for third-party integrations.
During the gate review, the enterprise architecture and accessibility criteria passed. However, the security team presented findings showing that the proposed authentication flow didn't meet the agency's zero-trust requirements—a fundamental architectural concern, not a minor detail.
The gate decision authority (the program director) issued a No-Go decision. The decision record specified: the security architecture must be redesigned to incorporate zero-trust principles, the CISO's team would provide reference architecture patterns within 5 business days, and the gate would be re-reviewed in 3 weeks.
Rather than viewing this as a failure, the project sponsor acknowledged that catching this gap before development saved an estimated 8-12 weeks of rework. The redesigned security architecture passed the re-review, and the project proceeded to development on a revised but realistic timeline. The project plan and Gantt chart were updated to reflect the 3-week delay at this gate.
Best Practices
Define exit criteria at the start of each phase, not retroactively before the gate review—this gives the team a clear definition of done throughout the phase.
Distribute review materials at least 3-5 business days before the gate meeting so reviewers can prepare substantive feedback rather than reacting in real-time.
Keep gate reviews focused on deliverable quality against criteria—do not allow them to become status update meetings or scope negotiation sessions.
Require the decision authority to verbally state the gate decision and sign the decision record—implicit approval erodes accountability over time.
Maintain a running gate review log across all phases so you can identify patterns (e.g., certain criteria types consistently failing) and improve your process.
Time-box issue discussions during the gate meeting and park items that need deeper investigation—assign owners and deadlines rather than solving everything in the room.
Common Mistakes
Treating gate reviews as rubber stamps where approval is assumed before the meeting even starts
Correction
Establish a culture where No-Go is a legitimate and respected outcome. The first time a gate legitimately rejects a phase, it signals that the process has teeth. Celebrate the defect caught, not the delay.
Allowing the gate review to proceed without all required stakeholders present
Correction
Define required attendees upfront and enforce the rule that the gate cannot issue a valid decision without them. If a required attendee can't make it, reschedule—don't dilute the gate's authority.
Using vague, subjective exit criteria like 'requirements are complete' or 'design is adequate'
Correction
Make every criterion specific and measurable: 'All 47 functional requirements have acceptance criteria defined' or 'Architecture document has been reviewed and approved by the security team.' Binary criteria eliminate interpretation disputes.
Issuing a Conditional Go with too many or too significant conditions, effectively proceeding despite a failed gate
Correction
Reserve Conditional Go for genuinely minor items. If conditions represent more than 10-15% of the phase's exit criteria or include any showstoppers, the honest decision is No-Go with a rework period and re-review date.
Not tracking conditional items after the gate, allowing them to silently become technical debt
Correction
Add every condition to your project tracker with an owner, deadline, and escalation path. Review condition status in the first status meeting of the next phase and escalate missed deadlines immediately.
Other Skills in This Method
Defining and Sequencing Waterfall Phases
How to structure and sequence the core Waterfall phases — requirements, design, implementation, verification, and maintenance — so each phase has clear entry and exit criteria.
Building Content Waterfall Strategies
How to apply the Waterfall approach to content production by cascading a single asset into multiple formats and channels in a planned, sequential workflow.
Running Structured Testing and Verification Phases
How to plan and execute systematic testing — unit, integration, system, and acceptance — as a dedicated phase that validates all requirements before deployment.
Managing Change Requests in Waterfall Projects
How to evaluate, document, and process scope change requests through a formal change control board without derailing the sequential project plan.
Creating Waterfall Project Plans and Gantt Charts
How to build detailed project schedules with milestones, dependencies, and resource allocations using Gantt charts and work breakdown structures for Waterfall projects.
Analyzing SEO Waterfall Charts for Page Performance
How to read and interpret browser waterfall charts to diagnose page load bottlenecks, optimize resource loading order, and improve Core Web Vitals for SEO.
Writing Comprehensive Requirements Documents
How to gather, document, and freeze detailed requirements specifications before design begins, ensuring completeness and traceability throughout the project.
Frequently Asked Questions
How many gate reviews should a waterfall model project have?
A typical waterfall model project has one gate review between each sequential phase—usually 4-6 gates total (e.g., after requirements, design, development, testing, and deployment). The exact number depends on how many phases you've defined in your project plan.
Who should attend a phase gate review in a waterfall project?
Required attendees typically include the project sponsor or steering committee (decision authority), the phase lead who produced the deliverables, quality assurance representatives, and key stakeholders who will consume the deliverables in the next phase. Subject matter experts attend as needed based on the phase content.
What happens if a gate review results in a No-Go decision?
The team returns to the current phase to address the specific deficiencies identified. The decision record specifies what needs to be fixed, and a re-review date is scheduled. The project plan is updated to reflect the delay, and stakeholders are notified of the revised timeline.
How long should a phase gate review meeting last?
Most gate reviews take 60-120 minutes depending on project complexity and the number of exit criteria. Simple phases with clear deliverables may need only 45 minutes, while complex phases with regulatory requirements might require a half-day session.
Can gate reviews be conducted remotely in a waterfall project?
Yes, gate reviews can be conducted remotely using video conferencing, provided all required attendees can participate, review materials are shared digitally in advance, and digital signatures are accepted for the decision record. The key is maintaining the same rigor and formality as an in-person review.
What is the difference between a gate review and a peer review in the waterfall model?
A peer review is a technical review of specific deliverables conducted by peers during a phase (e.g., code review or document review). A gate review is a formal management decision point between phases that evaluates whether all exit criteria are met and authorizes the project to proceed. Peer reviews feed into gate reviews but don't replace them.