Benefit data should inform tollgate decisions by adding a second dimension to the standard review: not just whether the project is on schedule and budget, but whether it is delivering the value that justified its funding. Without this, a project can score green on every execution metric and still be destroying capital. Go, hold, or stop — only benefit data tells you which.
In this guide
- Why Are Tollgate Decisions Made Without Benefit Data?
- How Do You Build a Benefit-Integrated Tollgate Decision Matrix?
- When Should You Issue a Hold Decision at a Tollgate Review?
- When Does Benefit Data Justify Stopping a Project?
- How Do You Build a Tollgate Decision Framework Around Benefit Delivery?
- Frequently asked questions
Why Are Tollgate Decisions Made Without Benefit Data?
The tollgate review asks a binary question dressed in three options: should this project continue to receive capital? Go means yes, proceed as planned. Hold means pause, something needs investigation before we commit further. Stop means no, redirect the remaining capital elsewhere. These are the highest-stakes decisions in the project governance lifecycle, and they are routinely made without the single most relevant piece of information: whether the project is delivering the benefits that justified its funding.
The standard tollgate review evaluates execution metrics. Is the scope being delivered as defined? Is the project on schedule? Is expenditure within the approved budget? Are risks being managed? These are important questions. But they address whether the project is being run well, not whether the project is producing value. A project can score perfectly on every execution metric and still fail to deliver a single committed benefit.
Integrating benefit data into the tollgate decision does not complicate the process. It completes it. The governance committee gains a second dimension of performance assessment that, combined with execution metrics, provides the full picture needed to make an informed go, hold, or stop decision.
How Do You Build a Benefit-Integrated Tollgate Decision Matrix?
The most useful way to integrate benefit data into the tollgate is through a two-dimensional assessment that considers both execution performance and benefit delivery. This creates four scenarios, each with a distinct governance response.
The first scenario is strong execution and strong benefit delivery. The project is on scope, on schedule, on budget, and its committed benefits are on track or exceeding. This is the clearest go signal. The project is running well and producing value. The governance response is to continue with standard monitoring.
The second scenario is strong execution but weak benefit delivery. The project is on scope, on schedule, and on budget, but one or more committed benefits are at risk. This is the scenario that execution-only tollgates miss entirely. The project looks green on every traditional metric, but the value it was funded to deliver is not materialising. The governance response should be a hold pending investigation. What is causing the benefit shortfall? Is the project building the right deliverables but missing the conditions needed for benefit realisation? Are there dependencies outside the project scope that are not being managed? Is the benefit target still achievable or does it need to be revised?
The third scenario is weak execution but strong benefit delivery. The project is behind schedule or over budget, but its benefits are on track or exceeding. This scenario is less common but not rare, particularly in agile environments where early value delivery can outpace planned timelines. The governance response should weigh the benefit delivery against the execution shortfall. If the project is delivering value despite execution challenges, a stop decision would sacrifice confirmed returns to enforce process discipline. A more nuanced response might be to continue with enhanced execution oversight while protecting the benefit delivery trajectory.
The fourth scenario is weak execution and weak benefit delivery. The project is behind on execution metrics and its benefits are at risk. This is the strongest stop signal. The project is consuming capital without delivering it on time or translating it into value. Unless there is a credible recovery plan that addresses both dimensions, the governance response should be to stop the project and redirect the remaining capital.
| Scenario | Execution Performance | Benefit Delivery | Governance Response |
|---|---|---|---|
| 1 | Strong (on scope, schedule, budget) | Strong (on track or exceeding) | Go — Continue with standard monitoring |
| 2 | Strong (on scope, schedule, budget) | Weak (one or more benefits at risk) | Hold — Investigate benefit shortfall before committing further capital |
| 3 | Weak (behind schedule or over budget) | Strong (on track or exceeding) | Evaluate — Weigh benefit delivery against execution shortfall |
| 4 | Weak (behind on metrics) | Weak (benefits at risk) | Stop — Redirect remaining capital unless credible recovery plan exists |
See how Profit.co tracks benefit delivery at every tollgate
When Should You Issue a Hold Decision at a Tollgate Review?
The hold decision is the most underused option in the tollgate framework, and it is the decision most improved by benefit data. A hold is not a failure. It is a governance mechanism that preserves capital while the organisation gathers information needed to make a better go or stop decision.
Without benefit data, the hold decision is difficult to justify because the triggers are ambiguous. A project that is slightly behind schedule might warrant a hold or might simply need more time. A project with an elevated risk might warrant a hold or might be managing the risk effectively. The signals from execution metrics alone are often too soft to trigger a formal pause.
Benefit data provides harder signals. A benefit that has been classified as at risk for two consecutive check-in periods with a widening gap between planned and actual delivery is an unambiguous signal that something is wrong. A benefit that was expected to begin delivering in the current quarter but has recorded zero actual value is a clear trigger for investigation. These signals are specific, measurable, and difficult to dismiss as temporary fluctuations.
The hold decision triggered by benefit data creates a structured investigation window. The governance committee defines the questions that must be answered: What is causing the benefit shortfall? Can it be corrected within the existing scope and budget? Does the revised benefit forecast still justify the remaining investment? What would it cost to stop now versus continuing? The project team and benefit owner have a defined period to answer these questions before the committee reconvenes and makes a final go or stop decision.
This structured hold is vastly more productive than the alternative, which is a go decision accompanied by a vague instruction to monitor the situation. The go-with-monitoring response sounds reasonable but produces nothing. Nobody defines what monitoring means. Nobody defines what would trigger a different decision. The project continues to consume capital, the benefit shortfall persists, and the governance committee revisits the same situation at the next tollgate with the same inconclusive discussion.
When Does Benefit Data Justify Stopping a Project?
Stopping a project is the most difficult decision in investment governance. It requires acknowledging sunk costs, accepting a write-off, and overcoming the organisational momentum that keeps funded projects in motion. Most enterprises stop projects far too late, after the capital is substantially consumed and the recovery opportunity is minimal.
Benefit data makes the stop decision both earlier and more defensible. When the planned-versus-actual comparison shows a persistent, material gap across multiple check-in periods, the case for stopping is grounded in measurement rather than judgement. The governance committee is not debating whether the project might recover. It is looking at a documented trajectory that shows the project is not delivering the value that justified its funding.
The financial argument is straightforward. If a project has consumed forty percent of its budget and has delivered fifteen percent of its committed benefit value, the implied benefit delivery rate is well below the level needed to justify the remaining sixty percent of capital. Redirecting that capital to a project with a stronger delivery trajectory produces a better return for the organisation, even after absorbing the sunk cost of the underperforming project.
Benefit data also helps manage the political dynamics of the stop decision. When a senior sponsor’s project is stopped based on documented benefit delivery data, the decision is harder to contest than a stop based on subjective assessments. The data is impartial. It was collected through the standard check-in process. It was reviewed by the VRO. It was escalated through the governance chain. The stop decision is the logical conclusion of a measurement process, not a political act.
Project portfolio management systems that integrate benefit tracking make this data trail automatic. Every benefit owner submits actuals on a defined cadence. The VRO reviews and escalates. By the time the project reaches a tollgate, the committee is not asking for benefit data — it is already on the agenda.
The organisation that integrates benefit data into its stop criteria does not just make better decisions. It makes them faster. And in capital management, the speed of the stop decision is directly proportional to the capital recovered.
How Do You Build a Tollgate Decision Framework Around Benefit Delivery?
Integrating benefit data into tollgate decisions requires formalising the relationship between benefit status and governance action. This formalisation should take the form of a documented decision framework that defines the specific benefit conditions that trigger each outcome.
Most project management platforms track execution well. Gantt charts, task completion, budget burn. What they do not track is benefit delivery against committed targets. The result is that governance committees using these tools are making tollgate decisions with half the data. Benefit tracking systems close this gap directly: benefit owners log actuals against targets at defined intervals, the system flags at-risk benefits automatically, and that data surfaces as a governance input at every tollgate review.
The framework does not need to be rigid. Thresholds can be adjusted based on the organisation’s risk tolerance and the strategic importance of specific investments. But the framework must be explicit. Every tollgate participant should know in advance what benefit conditions will trigger a hold discussion, what conditions will trigger a stop recommendation, and what evidence is needed to override a triggered action. For example: any benefit classified as at-risk for two consecutive check-in periods automatically triggers a hold discussion. Any benefit that has recorded zero actual delivery against a target that was due to begin realising in the current quarter triggers an escalation to the governance committee.
The presence of the framework changes behaviour long before it is invoked. When project managers know that at-risk benefit status can trigger a hold or stop decision at the tollgate, the incentive to submit accurate check-ins, to flag benefit risks early, and to pursue corrective action proactively increases dramatically. The framework does not just improve tollgate decisions. It improves the quality of benefit management throughout the project lifecycle because every participant knows that benefit delivery has consequences.
Go, hold, or stop. Three options. One decision. And the data that makes it informed rather than intuitive comes from the same system that tracks whether investments deliver what they promise. Connect the benefits tracker to the tollgate, and the governance process finally has the information it needs to manage capital, not just spend it.
Your next tollgate review shouldn’t be missing half the data
Frequently Asked Questions
A tollgate decision is a formal checkpoint where a governance committee decides whether a project should continue (go), pause for investigation (hold), or be terminated (stop) based on its performance against defined criteria.
Committees should review planned versus actual benefit delivery for each committed benefit, current benefit status (on track, at risk, or missed), and trend direction across the last two or more check-in periods.
Issue a hold when execution metrics are green but one or more committed benefits are at risk. The hold triggers a structured investigation into the benefit shortfall before the committee commits further capital.
Benefit data grounds the stop decision in documented measurement rather than subjective judgement. A persistent, widening gap between planned and actual delivery is objective evidence that the project is not delivering the value that justified its funding.
Execution metrics measure whether a project is being run correctly — on scope, schedule, and budget. Benefit delivery measures whether it is producing the value it was funded to create. A project can pass execution and still deliver zero committed benefit.
