Tollgate reviews that executives actually value

Most tollgates go wrong in the same way. The team presents 34 slides of activity. The sponsor asks three questions about things that are not on the critical path. Somebody says 'looks good, keep going.' No decision is recorded, no conditions are set, and the gate has provided exactly zero governance value while consuming two hours of senior time.

A tollgate exists to answer one question: is there enough evidence to invest the next phase's effort in this problem? That is a yes, a conditional yes, or a no. If your gate cannot end in a 'no', it is not a gate.

The single highest-leverage change is publishing phase-specific entry criteria and refusing to schedule the review until they are met. For a Measure gate, that typically means: an approved operational definition for the primary metric, a completed MSA within acceptable limits, a stability assessment, a baseline with a stated sample size and confidence, and a data collection plan that was actually followed.

When criteria are explicit, the review stops being an argument about completeness and becomes a conversation about the finding. Teams self-police, because nobody wants to be the project that got bounced at the door. Reviewers relax, because they know what they are being asked to certify.

The traditional workflow is that a project leader spends a day copying charts into slides the night before the review. That day is pure waste, and it introduces transcription errors and stale numbers. The alternative is to generate the deck from the tools you actually worked: the Pareto you saved, the capability study you ran, the process map you validated.

Ci Flow takes exactly that approach. Only tools that have been worked and saved are eligible as evidence slides, each slide carries a stakeholder-facing explanation of what the chart means, and the deck exports to editable PowerPoint for a phase or for the whole project. The effect on behaviour is more interesting than the time saved: when the deck can only contain real evidence, teams stop performing and start working.

A gate decision needs four recorded elements: the outcome, the conditions attached to it, the owner and due date of each condition, and the evidence set the decision was based on. Without the fourth element you cannot defend the decision later, and 'we approved that on the information available' becomes an argument instead of a record.

Conditional approvals are the workhorse of a healthy programme, but they decay if nobody tracks them. Treat every condition as an action with an owner, and review open conditions at the start of the next gate. Programmes that do this find their conditional-approval rate falls over time, because teams learn which gaps trigger conditions.

Rework is not failure; it is the gate working. But rework has to be handled cleanly, or the project quietly carries forward approvals it no longer deserves. If a project returns to an earlier phase, the approvals for the later phases must be voided, because the evidence they rested on has changed.

Ci Flow enforces this automatically: moving a project back to an earlier phase clears the gate approvals for the phases that follow it. It feels harsh the first time. It is also the only way a portfolio-level view of gate status can be trusted, and trust in that view is the whole point of governance.