The SAM methodology

Tollgate isn’t a general-purpose project tool with governance features bolted on. It’s the software embodiment of a methodology — the Softwired Above-the-Line Methodology (SAM) — for investment governance above the line. Understanding SAM is the fastest way to understand why Tollgate is shaped the way it is, why it does fewer things than the tools it sits beside, and why it refuses some things outright. This page is the why; it doesn’t tell you which button to press.

The question SAM exists to answer

A sponsor signs off a multi-million-pound technology investment and becomes accountable for one question: is this still going to deliver what we funded it for, and if not, what do we do about it?

The data to answer it exists — but it’s scattered across a finance system, a Jira instance, a few spreadsheets, some SharePoint folders and a year-old kickoff deck. The PM becomes the integration layer, reassembling the picture every reporting cycle, and the picture goes stale on the way to the room. Worse, when a committee member asks a follow-up — “what did we decide about that change in Q2? what’s the cumulative budget impact?” — the honest answer is “I’ll have to come back to you on that”, and the meeting stalls.

The PPM tools that try to solve this on Jira tend to solve it the same way: more configurability, more dashboards, more fields. The end state does forty things adequately, and the sponsor’s actual question adequately at best. SAM takes the opposite bet — do fewer things, properly, in the sponsor’s own vocabulary, in the tool where the work already lives.

Above the line

SAM operates above the line — at the altitude of the people answerable for the money, not the people delivering the work. Scrum, SAFe and the rest operate below it, and they’re fine there; SAM doesn’t compete with them. It refuses to launder delivery noise — story points, velocity, burndown — into governance language, because none of those is a yes/no answer to “on track for the payoff?” This is the first and most important idea in SAM, and it has its own page: Above the line.

The seven principles

SAM is, at its core, seven principles. Everything else — the lifecycle, the surfaces, the refusals — follows from them.

1. Above the line. The investment-governance layer, not the delivery-management layer.
2. Recommendations not stipulations. Tollgate guides; it doesn’t enforce or nag. It surfaces drift, stale data and missing decisions — it doesn’t block you or email you. The single deliberate hard gate is the Adoption & Change quartet on business-case submission, because adoption is the best predictor of whether an investment lands.
3. Kill with dignity. Every state has a low-shame path to “explored, not pursued — here’s why”. Archived and not-realised records are elevated in the corporate memory, not buried, because failures teach more than successes.
4. The dashboard is the deck. Tollgate is the presentation surface, not a deck producer. (See The dashboard is the deck.)
5. No realised-ROI score. SAM computes the forward target (NPV, IRR, payback) in the financial case, but at realisation it holds the sponsor’s prose verdict — not a computed variance against that target. (See Does Tollgate calculate ROI?.)
6. The methodology is the product. Strong defaults backed by practitioner judgement, not configurable everything. (See Scaffold, don’t dictate.)
7. Six tabs deliberate. Business Case, Work Packages, Risks, Decisions, Changes, Investment Health — the whole universe of what a sponsor needs to interrogate an investment. A seventh tab would fight the methodology.

The lifecycle: Commit, Run, Evaluate

The life of an investment under SAM has three acts. Each is the sponsor asking a different version of the same question, and each maps onto two of the six stages Tollgate surfaces.

Act	Stages	The sponsor’s question
Commit	Discovery + Approval	Is this worth funding?
Run	Initiation + Delivery	Is it still worth it?
Evaluate	Close-out + Benefits Realisation	What did we get, and what next time?

Commit — is this worth funding?

In Discovery, a hypothesis is pressure-tested: is the problem real, the outcome plausible, the return defensible, the adoption cost bearable? The business case sits in an Exploring state with relaxed gates; candidates that don’t survive are archived with a one-line rationale and stay findable.

In Approval, the PM submits a polished business case with the Adoption & Change quartet set and a sponsor named. It flips to Submitted, and the sponsor reads, then Approves, Returns with notes, or — rarely, with full dignity — Archives. Submissions age visibly on the surfaces the sponsor already opens; nothing gets emailed.

The beat: we decide whether this is worth funding, in writing, with the memory of every alternative explored preserved against the day someone asks.

Run — is it still worth it?

In Initiation, the morning after approval, the PM lays foundations: coarse work-package structure with owners and baselines, the steering committee inducted, the Adoption & Change work seeded, the risk register started, cadence confirmed. A visible-but-non-blocking checklist composes itself from the registers and recedes once the first steering meeting is held.

In Delivery — the long stretch where most weeks live — the PM keeps the picture current through the week (a guided review takes minutes). Confidence on the Outcome and Adoption axes is reported alongside RAG. Materialised risks become decisions of record; pending changes surface for a call. At each steering meeting, the projector shows Investment Health and the meeting runs straight off it.

The beat: we govern while it runs, the case file is always current, and the sponsor never hears “I’ll have to come back to you on that”.

Evaluate — what did we get?

In Close-out, the symmetric peer of Approval, the PM prepares an as-built record — what was actually delivered, deltas against the approved case, residual risks resolved, lessons captured, BAU handover confirmed. The approved business case stays immutable; what’s amended is the record of what actually happened. The project enters the Closed lane — hidden by default, findable.

In Benefits Realisation — the lightest-touch stage — the sponsor confirms at 90 days whether adoption took, posts a short check at six months, and at the twelve-month verdict declares Realised, NotRealised or “not ready yet”. The declaration is the governance act; the prose pair (what we said beside what we got) is the artefact. Not-realised records carry an elevated lessons field, because the next sponsor funding a similar case needs to find them.

The beat: we learn what we got, we write the verdict in the words of the person who signed the cheque, and we preserve the failures as carefully as the successes.

What SAM refuses

The refusals are part of the methodology, not gaps in it. SAM will not build ticket-level rollups, capacity or resource planning, sprint metrics, a live realised-ROI or variance tracker, configurable approval workflows, email or Slack nags, or a slide-authoring workflow. Each has a home elsewhere, or would drag Tollgate below the line. Saying no — visibly — is what makes the depth possible.

Why an app, not a process

A disciplined PMO could operate SAM with a SharePoint site and a calendar invite — many approximate it, at varying levels of heroism. SAM lives in a Forge app inside Jira because the methodology needs a single surface where the case file is kept rather than reassembled, inside the tool where the work already lives. The moment governance lives somewhere different from delivery, governance drifts. Forge is the right runtime because it satisfies the “Runs on Atlassian” trust constraint — no external data exfiltration, no external AI — and because Ask Tollgate runs natively on the same data.

Where to go next

• Above the line — the founding distinction.
• The SAM lifecycle — the six stages and their states, as dry reference.
• Your first investment — see the front half of the lifecycle in action.