Value-linked delivery: get paid when it works

If you only have 60 seconds:

Every SAP customer carries a quiet backlog: change requests the business wants, that IT has no capacity to build. The value they would create decays while they queue.

Classic consulting answers that backlog by selling effort. Day rates price the input, procurement fights the only number it can see, and nobody is accountable for whether value actually lands.

Value-linked delivery turns the logic around: a fixed fee derived from the business value all three parties confirm, paid on acceptance. Nothing up front. Half at MVP acceptance, half at go-live.

It also repairs an incentive AI is quietly breaking: priced by effort, every productivity gain shrinks the provider’s invoice; priced by value, it becomes their margin.

It is not a pricing trick. It is a different allocation of risk -- and that is what makes it better.

The backlog is not a capacity problem

Walk into any established SAP installation and ask for the change request list. It exists, it is long, and most of it is older than anyone likes to admit.

The standard diagnosis is capacity: IT cannot build fast enough, so the queue grows. The standard remedy is more capacity: external consultants, billed by the day.

I think the diagnosis is wrong, and I have spent enough years on every side of this table, as a customer, inside the vendor, and as a partner, to say it with some confidence. The backlog is a pricing problem. Nobody has established what the changes are worth, so nobody can decide rationally which ones deserve to be built, and nobody will underwrite the outcome. A queue without value numbers is not a plan. It is a grievance, renewed quarterly.

There is a second absence, quieter than the first: almost nobody quantifies the cost of not doing a change. Every quarter a change request waits, the value it would create decays: the process stays manual, the workaround stays in place, the margin leaks on. That cost never appears in anyone’s business case, so the queue is carried at zero while it quietly burns money. A decision made without either number -- the value of doing it, the cost of leaving it -- is not a decision. It is noise with a steering committee.

And the billing model makes it worse. When effort is the product, the incentive is to sell more effort. When the fee is unrelated to the outcome, the outcome is, politely put, somebody else’s KPI.

The inversion

Value-linked delivery starts from the opposite end. Not “what does the work cost?” but “what is the change worth, and who is prepared to put their name under that number?”

The model runs in five steps.

1. Establish the value first. Before anything is priced, the business states what the change is worth and puts a named owner behind the number. The claim is structured and pressure-tested into a one-page value case; IT co-signs that the change is feasible. The baseline always belongs to the business, never to the consultant. What cannot be confirmed stays marked as unknown: a value case with honest gaps beats a confident fiction.

2. Size the effort honestly. The delivery cost is estimated from a defined scope. It serves as the floor under the fee, not as its justification.

3. Derive the fee from the value, conservatively. The fee is a modest share of the value all three parties have confirmed. If the calculation is in doubt, the low end of the range counts. If even that number does not hold, there is a veto: the change request goes to classic delivery instead. A change that cannot carry its value is disqualified, never priced up.

4. Build at risk, get paid on acceptance. Nothing is paid up front. Half of the fee is due when the MVP is accepted against a written definition, the other half at go-live against agreed criteria. The customer never pays for a promise. The provider finances the delivery and carries the risk -- and that risk is precisely what the margin buys. Anyone who finds the margin generous is invited to finance the build themselves.

5. Run it across the backlog. Applied to the whole queue, the same method produces what most IT organisations have never had: a ranked portfolio of change requests by confirmed value against effort. The high-value cases get built first. The queue becomes a plan.

The one page that does the work

The instrument behind step one deserves a closer look, because it is where most of the discipline lives. Each change request gets exactly one value case, and it fits on one page. In the version I work with, that page holds seven things:

1. The change and its people. The problem in one sentence, the named business owner who signs the value, the named IT owner who signs feasibility, and, honestly stated, why IT cannot build it now: capacity, skills or priority.
2. The value drivers, as ranges. One row per driver. The baseline always comes from the business, with a named owner; the provider never supplies it. Improvement is always stated as a range, never a point estimate. What cannot be confirmed stays marked as unknown. It does not get invented. Soft value may be shown, but it never carries the fee on its own. And the time horizon is explicit: typically the first twelve months after go-live.
3. What gets built. The MVP definition as a list of measurable, testable acceptance criteria, and the go-live definition as a cutover plus a verification window with no open critical defect.
4. What does not get built. An explicit out-of-scope list. In my experience this list prevents more disputes than any contract clause.
5. What the customer must provide. Access, test data, transport windows, key users: named dependencies with owners.
6. The effort and its floor. The provider’s own sizing, including contingency and the risk reserve, as the floor under the fee.
7. The three signatures.

The page earns its keep twice. First as the decision instrument. Then as the scope document of the order itself: whatever is not on the page is not in scope, and a change of scope means a new value case and a new order, never an amendment by e-mail.

What keeps it honest

Three signatures, three vetoes. The business owns the value baseline and can refuse a number it does not believe. IT owns feasibility and the go-live gate and can refuse a change that endangers the platform. The provider owns the effort estimate and the fee and can refuse a case that does not carry itself. That is the entire governance. It fits on one page, and in my experience the discipline of those three signatures does more for delivery quality than any steering committee I have sat in.

One detail matters more than it looks: what counts as a case that does not qualify is agreed before any value is scanned, not argued afterwards. A value that does not match the volumes behind it, a baseline without a named owner, a value below the cost of building the thing: these are disqualifiers everyone has accepted in advance. That keeps the veto a rule, not a negotiating move, in either direction.

Note what is deliberately absent: no payment “when the value materialises”. Realised value depends on adoption, management attention and a dozen factors the provider does not control. Tying the fee to realised value sounds braver and is actually vaguer: it turns a clean acceptance gate into a years-long argument about attribution. Paid on acceptance keeps the promise testable: the thing works, as jointly defined, or it does not.

The contract is deliberately boring

All the innovation sits in how the number is derived. None of it sits in the legal mechanics -- and that is by design, because procurement departments do not buy novelty.

The stack is conventional: one framework agreement per client for the general terms, then one short order per change request, whose scope document is the signed value case itself. The contract headline is a milestone-based fixed fee, full stop. No success-fee construct, no clause about whether value was later realised, nothing a procurement regime has to invent a category for.

The acceptance mechanics carry the fairness, in both directions:

• Rejection must name the unmet criterion. Only a named gap against the written definition can reject an MVP or a go-live. “That is not what we meant” is not a rejection.
• Silence cannot stall it. If no written rejection with reasons arrives within a defined number of working days, acceptance is deemed. The provider carries the delivery risk; it does not also carry the risk of an inbox.
• Client delay moves the date, not the fee. If access, key users or test data arrive late, the milestone shifts; the commercial terms do not.
• Either side can stop at the MVP gate. If the MVP is rejected twice, both parties may end the order. The provider carries its own cost; the customer owes nothing. A model built on confidence needs an exit that does not require a lawsuit.

That last rule is the one I find executives underestimate. It is also the strongest proof of seriousness: a provider who offers a double-rejection stop right is betting the engagement on first-pass quality.

Why each party says yes

The business gets the change built and pays only on a proven result. IT keeps control: it co-validates feasibility, owns the go-live gate, and closes its capacity gap without ceding the mandate. The provider earns a margin that reflects risk carried, not hours logged, and builds something capacity selling never produces: a method that compounds.

And there is a fourth yes, the one AI forces. Under day rates, every productivity gain a provider achieves (better tooling, better templates, AI-assisted build and test) lowers its own revenue. The better it gets, the less it earns, which is why genuine efficiency so rarely reaches the customer as speed rather than as a discount fight. Price the work on confirmed value instead, and faster delivery raises the provider’s margin while the customer’s fee stays exactly where three signatures put it. Efficiency becomes margin, not discount -- the one incentive structure in which the provider’s AI adoption and the customer’s interest point the same way.

Where it breaks, and what caps it

A model that cannot name its own failure modes is a pitch. These are the five I plan for.

Value inflation. The business overstates the value to push a pet project. Cap: the baseline needs a measurable proxy, IT co-signs it, and the fee is derived conservatively: on a doubtful calculation, the low end counts.

The acceptance dispute. The classic “that is not what we meant”, at the worst possible moment. Cap: acceptance criteria written before the build starts, and staged demos along the way: no big-bang reveal, so the acceptance session confirms what everyone has already seen working.

The failed go-live. The provider eats the cost. Cap: small MVPs, kill criteria agreed up front, and a portfolio of change requests rather than a single bet. When it happens anyway, that loss is the model working as designed: the customer was protected.

IT resistance. The model can look like a threat to IT’s mandate. Cap: it is positioned, and contractually built, as capacity relief under IT’s control. IT co-signs feasibility, owns the go-live gate and holds a veto. Nothing enters the portfolio around IT.

Adverse selection. The provider gets handed only the changes IT already judged unfeasible. Cap: the feasibility screen runs before any commitment, and the provider chooses which cases to take. Selection is part of the model, not a courtesy.

How to start: one loop, not a programme

Nobody should buy this model from a slide, including from this page. The honest way in is one loop.

Pick one mid-size change request with a clear value and a willing business owner and IT sponsor. Establish the value case: a short, fixed-scope scan, one to two weeks, credited against the delivery if it proceeds. Agree the MVP definition, the acceptance criteria and the fee. Build. Pass the gate or miss it.

Then, and only then, scale: scan the whole backlog, rank it, and let the portfolio decide what gets built next. Re-scan it periodically, because new requests arrive and old values decay. But the sequencing discipline is absolute, and it binds the provider more than the customer: no productising, no programme, no glossy launch before one at-risk loop has actually closed and paid. One closed loop is worth more than a polished deck.

The honest limits

This is Mission: BETTER!, not Mission: PERFECT. So, the limits, stated plainly.

Not every change request qualifies. Some values cannot be confirmed, some baselines have no willing owner, and some changes are simply maintenance in disguise. Those belong in classic delivery, which remains a perfectly legitimate business: the wider ecosystem delivers enormous value on exactly that model every day. Value-linked work will coexist with capacity work for years; the point is the direction of the mix, not a purge.

And it demands something of the provider that no slide can fake: the willingness to finance a build and walk away unpaid if the acceptance gate is missed. That willingness has unglamorous prerequisites: a finance function ready to carry work in progress, recognise revenue at milestones rather than monthly, and write off a failed build without drama. A firm that is not prepared to carry that is not doing value-linked delivery. It is doing time-and-material with extra steps.

One more honest line, about measurement. Whether the promised value actually materialised deserves checking at three, six and twelve months after go-live. But it is checked for learning, never for invoicing: the fee was settled at acceptance, and it stays settled. A provider that measures its own value estimates against reality, case after case, is building the only asset this model really runs on: calibration.

The question for the next board agenda

Take one change request from the backlog. Ask the business what it is worth, and who will sign the number. Ask IT whether it is feasible, and who owns the go-live gate. Then ask your delivery partner what they would charge if the fee had to be earned on acceptance.

And if the partner answers quickly and confidently, ask the only question that separates a model from a gimmick: are they willing to put their own capital and delivery capacity at risk against a value number they helped set? That is a yes/no question, and everything else in this episode follows from it.

The answers will tell you more about all three parties than any RFP ever has.

That is the better deal this episode opens -- and the thread the next ones will pull on.

---

Andreas BORN is the publisher of sapperment and writes Executive Clarity. The delivery model described is one the author operates commercially, outside sapperment; sapperment does not sell it.

Independent. Not affiliated with or endorsed by SAP SE. SAP is a registered trademark of SAP SE.

Next: explore Executive Clarity or browse the sapperment library.