After a stage-gate review, the step before releasing the next budget is to list the test results required before that money can be committed. A Go decision can increase a project's exposure before it increases confidence in delivery. Check whether the approval funds a test or commits the organisation to relying on its result.
A stage-gate review evaluates project evidence against agreed criteria to decide whether work can enter its next phase and receive resources.
FBI approvals outpaced evidence that the software could work
The FBI needed a better way to manage investigative files. Its Trilogy program included upgrades to computers and communications, alongside new user applications. The Virtual Case File, or VCF, was intended to replace an old case management system. The need was real; a useful system still had to be delivered.
In his February 2005 congressional testimony, FBI Director Robert Mueller acknowledged that the June 2001 contract lacked complete requirements. He also described missing internal expertise and underestimated integration complexity. In November 2003, a demonstration impressed him. The software delivered the following month was unusable.
That sequence matters to anyone reading a gate decision. An approved contract authorised development. A demonstration showed selected functionality. Neither, by itself, established that the complete system could support operational work. Each piece of evidence must be read against the specific commitment it is meant to justify.
The Justice Department inspector general's findings explain that the FBI rejected the December 2003 delivery. Correcting an initial set of concerns still left substantial work, including security and records management. Completing some corrections did not establish that the remaining system was ready.
For a project sponsor, that leaves a practical question at the next approval: what exactly can the evidence support? Work completed against one part of the specification cannot settle a separate question about deployment. The approval paper should make the difference visible before anyone agrees to further spending.
This is the same distinction that matters after a technical feasibility study. Evidence that a component can work may justify a bounded development test. It does not automatically justify depending on the finished service. The next phase determines which conclusion the sponsor needs.
In June 2004, the FBI adopted a two-track approach. One track produced a limited workflow prototype for testing in early 2005. The other continued work on the wider solution. The audit findings state that the prototype did not deliver the intended full case management capability.
The audit's executive summary reported that the wider VCF still lacked a clear completion timetable. It identified weaknesses in requirements and oversight, among other problems. This was not simply a project with a late milestone; the intended operational capability remained undelivered.
A limited pilot can earn confidence in its own purpose without earning permission for wider deployment. Its results need a clear boundary. A sponsor can approve learning from an incomplete system while withholding approval for operations that depend on the complete system working.
For someone who has just finished a review, the immediate task is therefore to separate the next learning activity from the next operational commitment. Read the approval and identify which one it permits. If both appear in the same budget, identify the point where spending moves from investigation into dependence.

The cited records do not document use of the proprietary Stage-Gate process during VCF development. The testimony describes strengthened internal gate reviews by 2005. This case provides a technology project decision-review lesson, rather than evidence of a failed application of the named commercial framework.
Nor does it prove that one better review would have prevented the failure. The documented weaknesses were wider. Its narrower lesson is usable: before increasing a commitment, require evidence of the capability that commitment depends on. Approval and an attractive demonstration leave that question open unless the relevant test has been completed.
The Walk helps you state what must be demonstrated before a Go decision releases the next budget. Start the Walk →
What does a Go decision actually authorise?
A properly run gate gives the project team a decision about what happens next. Stage-Gate International's overview describes gates as decisions about further investment. A Go outcome includes an agreed next-stage plan and resources, with deliverables due at the next gate.
After the review, record the approved outcome and circulate it to the people responsible for carrying it out. Confirm which work the budget covers. Make unresolved conditions explicit. A project manager needs to know whether approval permits further testing, development or actual deployment before assigning work.
This makes the framework useful. A gate lets an organisation release resources in stages instead of committing everything at once. It gives the relevant decision-makers a place to examine readiness. Within the wider choice of decision-making frameworks, that control over resource release is a practical strength.
A condition needs a person authorised to confirm it is met. Leaving that responsibility unnamed lets the project team and sponsor each expect the other to check.
Define readiness for the next phase, rather than treating the completed review as proof of readiness. The framework already allows readiness criteria. The task is to make those criteria specific enough that evidence can satisfy or fail them. A signed checklist alone does not answer a missing technical question. For production, the follow-up to a manufacturing readiness review identifies the supported rate and the conditions that would require that decision to be reopened.
A gate does not require certainty about the entire future project. Early work may be approved precisely because important questions remain. The distinction is whether the next spend obtains an answer or relies on an answer already being correct. This is also central to challenging a business case before approval.
The next-stage plan should state what uncertainty the authorised work is meant to resolve. If a gate releases money for validation, preserve that purpose when assigning tasks. Expanding the work into production before the validation finishes changes the decision. Return that change to the person who controls the budget.
The required confidence should increase when the next decision becomes harder to reverse. Funding a small test can be sensible with limited evidence. Committing to a supplier contract or withdrawing an existing service needs evidence matched to those consequences. Specify the boundary in the decision record.
Write the evidence conditions before releasing the next budget
Take the review's decision record and the proposed next-stage budget. Name the next action that would be costly to undo. It might be a contractual commitment or an operational handover. State what must be true for that action to meet the project's purpose.
For each decisive condition, write the demonstration required before that action starts. In a software project, this might be a completed test of an essential interface using representative data. This is an illustrative check, not a claim about an undocumented VCF test. Define the expected result and who will assess it.
The US health department's stage-gate practices guide connects conditional approval with corrective action plans and milestones. Use that distinction: an unresolved condition must change what the team is allowed to commit. Otherwise the condition is merely a note attached to an unrestricted approval.
Keep the condition beside the budget line it controls. Record a due date for the check and name the person who can release the remaining funds. The project manager can then plan the work without guessing whether an open issue has been accepted or merely deferred.
If the result is missing, fund only the work needed to obtain it, where that work is justified. If the result fails, change the plan or return it for review. Record the actual permission given. The decision record should show which release remains conditional.
Keep the completed test result with the decision record. Identify the version or operating conditions it covers. If later work changes either, ask whether the demonstration still supports the intended use. This prevents a valid earlier result from being used to justify a different commitment.
The Universal Decision-Making Method asks what certainty is sufficient for the decision at hand. Applied here, it means enough evidence for this budget release and its consequences. It does not mean demanding complete knowledge before allowing the project to learn.
Check the conditions again immediately before the named commitment. Changed requirements can make earlier evidence insufficient. Use the same release criteria when reviewing whether there is enough information to decide. The gate record then tells the budget owner what evidence supports acting now.
How confident are you that the evidence at your gate supports the next commitment it permits?
Work through your decisionNo sign-up. Just pick your decision and start.
Grant Purdy is the co-author, with Roger Estall, of Deciding (2020), and the architect of the Universal Decision-Making Method.