Above the line

The single most important idea in Tollgate is a line. Above it sit the people answerable for the money — sponsors, transformation leads, programme directors, and the steering committees they answer to. Below it sit the people delivering the work. Tollgate lives entirely above the line. Almost everything else about the product falls out of that one commitment. This page explains what the line is, why it matters, and what it means in practice.

Two altitudes, two questions

Delivery teams answer “are we building it well?” — and Jira, boards, burndowns and velocity are good tools for that. Sponsors answer a different question: “are we on track for the payoff we funded this for?”

These look adjacent, but they don’t translate into one another. Story points aren’t a yes/no. Velocity isn’t a payoff. A green sprint can sit inside an investment that’s quietly drifting away from its business case, and a red sprint can sit inside one that’s dead on track. The executive’s question has been asked for a decade and keeps coming back answered in the delivery team’s language — outputs where an outcome was wanted.

Tollgate refuses to make that translation error. It doesn’t launder delivery signals into governance language. It takes delivery state from Jira as input and speaks above it, in the sponsor’s own vocabulary.

Why the abstractions are shaped the way they are

Every core object in Tollgate exists to keep the surface above the line:

The business case is there because “on track for what?” needs a defined what. Without it, status is just colour.
The work-package abstraction is there because executives don’t think in tickets. A work package is a coherent slice of scope with an owner, a budget and a schedule — big enough to mean something to a sponsor, small enough to have resolution. It deliberately isn’t a Jira story (that’s noise) and isn’t the whole project (that’s no resolution).
The derived Cost / Schedule / Scope / Risk RAGs exist because a sponsor needs status pulled apart, not collapsed into one colour that hides the disagreement.
The decision log and change register exist because the sponsor’s next question is always “what did we approve, and what has it cost us?”

None of these is a delivery-management feature. Each is a governance one.

The grievance underneath

There’s a quiet frustration Tollgate speaks to. Executives have spent years being told agile is the answer, and their reasonable question — are we on track for the payoff? — keeps coming back as story points, velocity and “outcomes over outputs”. Most PPM tools that sit on Jira have absorbed the agile worldview and reflect it back in the same language, which means they fail at the exact job the executive hired the tool for.

This isn’t an anti-agile position. Agile is fine for delivery. Tollgate is the governance layer that agile delivery needs but doesn’t supply on its own. (Worth knowing: the sponsor-grievance framing is for sponsor-facing conversations, not for the Jira admin whose sign-off you need to install — the tool sits happily alongside the delivery team’s world without disrupting it.)

The line is enforced twice — editorially and by permission

What makes the line hold isn’t just good intentions. It’s enforced in two ways at once:

Editorially, in the product. Tollgate ships a strong opinion about what earns space on the investment-governance surface. Below-the-line signals aren’t offered as configuration options you could switch on — they’re simply not there. The six-tab discipline is this restraint expressed as information architecture.
By permission. Visibility is gated by a customer-managed governance group. Tollgate can be made invisible to delivery teams entirely — the editorial discipline about what earns space is reinforced by access control over who sees it. See Restrict access with governance groups.

Recommendations, not stipulations

Being above the line also shapes how Tollgate behaves. It guides; it doesn’t enforce. It surfaces drift, stale data and missing decisions — but it doesn’t block you from saving a half-finished record, and it doesn’t email or Slack you a nag. Aging signals appear on the surfaces the sponsor already opens, not in their inbox. The right vector is surfaces, not push. (The one deliberate exception is the Adoption & Change quartet required at business-case submission — because leaving adoption out of the funding decision is the mistake most likely to sink the investment.)

This restraint is a governance stance, not a missing feature. Nagging is what the tools below the line do to chase delivery. Above the line, the sponsor decides when to look.

The line in one sentence

Tollgate is not a PMO operations tool and not a delivery management tool. It is the above-the-line investment view: the sponsor’s surface, the presentation surface for governance, and the structured conversation about whether the investment will land. When you’re deciding whether something belongs in Tollgate, ask whether it serves that conversation — and if it has an authoritative home below the line, point at that home instead.

The SAM methodology — the full method this idea anchors.
Does Tollgate calculate ROI? — the above-the-line stance applied to the payoff question.
Scaffold, don’t dictate — why the surface is opinionated, not configurable.