.png)
Ask most platform owners when their ServiceNow investment was last formally evaluated against its original business case, and the honest answer is usually "at go-live" — followed by a long silence. Go-live sign-off gets treated as the value conversation, when it's actually the least informative point at which to have it. At go-live, nothing has had time to prove out. Adoption hasn't settled. Cost savings haven't materialised. Risk reduction hasn't been tested against a real incident. Declaring value at that point isn't measurement — it's a forecast dressed up as a result.
A genuine value realisation review is a different exercise, run on a different cadence, producing a different kind of output. This article is a practical framework for running one: how to structure it, what to measure, who needs to be in the room, and — the part most guidance skips — what to actually do with the results once you have them.
Step One: Define What You're Actually Measuring Before the Review, Not During It
The most common reason value realisation reviews fail is that the review itself becomes the moment someone tries to define what success looks like. That's too late. If outcomes weren't defined in business terms before the platform was built, the review has nothing legitimate to measure against — it becomes a retrospective negotiation over what counts as good, rather than an assessment against an agreed standard.
The indicators worth tracking span several categories, and a useful review pulls from more than one: cost of service delivery, time to resolution, employee experience score, platform adoption rate, technical debt index, release quality score, business outcome versus target, and architecture compliance rate. Not every platform needs all eight tracked with equal weight, but a review that only looks at delivery activity — tickets closed, releases shipped — is measuring outputs, not outcomes, and will systematically miss whether the platform actually changed anything.
If your organisation hasn't defined baselines for these indicators yet, that's the first finding of your review, not a reason to skip it. Define them now, measure from today forward, and treat this cycle as the new starting point.
Step Two: Get the Right People in the Room, Not the Most People
A value realisation review that includes everyone tangentially connected to the platform produces a status meeting, not a review. The people who actually need to be present each hold a distinct piece of the answer.
The business sponsor brings accountability for the original outcome commitment and the budget context to judge it against. The platform architect brings technical direction and an honest view of what's driving cost, quality, and technical debt trends. The product owner brings ground truth on backlog reality and user adoption that dashboards alone won't fully capture. If there's a cross-cutting accountable role — an Iconica architect, or the equivalent in-house function — that person should be tracking outcome integrity across the whole review, not just their own workstream.
Missing any of these roles produces a predictable failure mode: without the business sponsor, the review becomes technically thorough but disconnected from the business case. Without the architect, it becomes a business conversation with no visibility into what's actually driving the numbers. Without the product owner, adoption and backlog signals get missed entirely.
Step Three: Separate What Happened from What It Means
This is the step most reviews skip, and it's the one that turns a review from a reporting exercise into a genuine steering mechanism. Once the indicators are pulled together, the review needs to work through three questions for each one, not just present the number.
What is the indicator actually showing — the number itself, presented honestly even when it's not the number anyone wanted to see. Why is it showing that — a root-cause conversation, not a defensive one, distinguishing between a genuine platform issue and a measurement artefact. And what does it mean for the roadmap — because a value realisation review that doesn't connect its findings back to the next quarter's priorities is a report, not a review.
A platform adoption rate that's flat isn't just a data point to note and move past. It's a signal that needs an answer: is enablement under-resourced, did a workflow change without retraining, or has a workaround emerged that's quietly displacing the intended process? The review's job is to force that question into the room while it's still cheap to answer, rather than let it surface eighteen months later as an unexplained renewal-time gap.
Step Four: Report It in Business Language, Not Delivery Language
The output of a value realisation review needs two versions, and conflating them is a common mistake. There's the technical detail — the full indicator set, trend lines, root-cause notes — which the platform team and architect need for planning. And there's the executive summary, which needs to answer one question in terms a CFO or COO actually uses: is this platform delivering the business outcome it was funded to deliver, in cost avoided, hours reclaimed, risk reduced, or whatever the original business case specified.
A review that only produces the technical version fails to close the loop with the people who hold the budget decision. A review that only produces the executive summary loses the detail needed to actually act. Both need to exist, and the executive version needs to be generated as a natural byproduct of the technical review, not written separately after the fact by someone translating it into business terms after the numbers are already stale.
Step Five: Steer, Don't Just Record
This is the step that separates a value realisation review from a status report, and it's the one this whole framework has been building toward. When an indicator is drifting from target, the review needs to produce an actual decision about what changes in response — not next quarter's planning cycle, now, while the finding is still fresh and the cost of correction is still low.
That might mean reprioritising the roadmap to address a technical debt trend before it compounds further. It might mean reallocating enablement resources toward a business unit where adoption has stalled. It might mean revisiting an architectural decision that's driving cost higher than the original business case assumed. Whatever the specific action, the discipline is the same: the review isn't complete until it has produced a concrete adjustment to what happens next, owned by a named person, with a date attached.
Without this step, even a well-run review just becomes a more sophisticated way of recording that something is wrong without doing anything about it — which is functionally the same failure as never measuring at all, just with better documentation of the drift.
