Skip to content
CAPIntelligence
←All insights

A gate is a decision, not a meeting

CAP IntelligenceCapital projects practiceSeptember 26, 20265 min read

Ask a project team what happened at their last gate and you will usually hear about a meeting. Slides were shown, questions were asked, someone from finance wanted to know about the contingency, and at the end the sponsor said something like “okay, keep going.” The project proceeded. Nobody wrote down what was decided, because nothing was, exactly. The meeting happened, and proceeding was what happened next.

That is the failure mode of most owner-side gate processes, and it has nothing to do with the quality of the slides. A gate that has only one real outcome is not a gate. It is a milestone with a calendar invite attached.

Four outcomes, and the second one is the point

A gate in a working capital process is a management decision with four possible outcomes, and the process is only as strong as its willingness to use all four:

  • Proceed. The deliverables meet what this gate requires; the next phase’s resources are committed.
  • Recycle. Specific, named deliverables go back, with a dated re-review. The project does not stop. It does not proceed either. This is the outcome that separates a gate from a milestone, because it is the one that costs a team something without killing the project, and therefore the one a gatekeeper actually has to be willing to choose.
  • Hold. The project pauses. Usually a portfolio reason: the window moved, the funding year changed, a bigger project displaced it.
  • Cancel. The alternative that was honestly killed at feasibility is allowed to stay dead.

If a site’s gate history shows a hundred gates and a hundred proceeds, the gates are not working. Not because a hundred projects were unready, but because a hundred decisions carried no information. A recycle rate of zero means the gate is a formality; a recycle rate that is real means the definition work before the gate is being done because someone will check.

One gatekeeper, named in advance

The second thing a gate needs is a person. Not a committee, not “leadership,” a named gatekeeper who chairs that gate and whose decision it is. On the front-end gates, feasibility, definition, and sanction, that is the sponsor, the person who owns the business case and the funding request. From construction readiness onward it is the steering chair, or on a small project the chair of the portfolio governance body. The project manager prepares every funding request and is never the decider, for the obvious reason that a project manager asked to grade their own readiness will grade it ready.

Naming the gatekeeper in the standard, before any project exists, is what makes the gate decision reconstructable. Six months later, the record says who decided, what the outcome was, what conditions were attached, and when the recycled deliverables were due back. A meeting cannot say that. A decision can.

The review is an input, never the decision

The third piece is where independent assurance fits, and it is easy to get wrong in both directions. An assurance review ahead of a gate is an independent read on whether the project is where this gate says it should be: is the scope defined to the depth the gate requires, is the estimate class honest, does the schedule have real logic, is the team reading the project the same way. It arrives before the gate, in time for the team to act on it.

It is not the decision. A consultant who “passes” a project has taken a decision that belongs to the sponsor, and a sponsor who treats a review as a pass has outsourced a judgment they are accountable for. The review informs; the gatekeeper decides; and the third assurance layer, the accountable sign-off on each key deliverable against its acceptance test, is what the review and the gatekeeper are both standing on.

Three layers, then: the deliverable sign-offs, the independent review, the gate decision. Each one is a different person answering a different question. When a site collapses them into one meeting, it gets one outcome, and the outcome is always proceed.

What to look at on your own process

Three questions. Does your gate record carry four outcomes, and has the second one ever been used? Is the gatekeeper for each gate named in the standard, not chosen on the day? And when a review is done before a gate, does the record show the decision as the sponsor’s, informed by the review, or as the review’s?

The Capital Project Assurance Review is built around that third answer, and the platform records the gate decision as one object, bound to the gate row, with the outcome, the conditions, and the re-review date on it. But the discipline itself needs no software. It needs a gate that can say recycle, and a person whose name is on it.

Want a defensible read on your next gate?

Start a conversation