A value realization review compares what an initiative actually delivered in production against the measurable objective it was approved on, at a point far enough after release for the effect to show. It is the step of the Learn practice that closes the loop back to funding, and it is a step organizations often skip, which is a large part of why the same kinds of initiative keep getting approved. Its output is not a report. It is a decision: scale, sustain, or retire.
How does a value realization review work?
The review works by reading three numbers side by side: the baseline before the work, the target the initiative was approved against, and the measured value now. Everything else in the meeting is context for those three.
That structure only holds if the objective was written as a measurable objective at approval time, with a number, a date, and an owner. When it was not, the review turns into a negotiation about what the initiative was really trying to do, and the initiative always wins that negotiation, because a goal stated loosely enough can absorb almost any result.
The review is run by the investment decision authority, with the sponsor, the long-term operational owner, and whoever holds the portfolio. It is short. Ten to fifteen minutes per initiative is usually enough, because the numbers were collected before the meeting from the operational dashboard rather than assembled for it. If preparing for the review takes a week of analysis, the measurement was not set up during delivery.
When should a value realization review be scheduled?
Schedule it against the objective's measurement window, not against the release date. The measurement window is the time the effect needs to become visible in the number, and it varies more than people expect:
- A change to a transactional process, such as intake or approvals, usually shows within 30 to 60 days once volume has passed through it.
- An efficiency change that depends on people changing how they work needs long enough for adoption to settle, commonly 90 days.
- A retention, renewal, or cost-per-unit effect may need two or three business cycles before the number means anything.
Set that date at approval, on the same artifact that records the objective, and put it on the portfolio calendar then. Reviews scheduled after go-live get scheduled by whoever is least busy, which is rarely the person who can decide anything.
Two failure modes sit on either side of the window. Review too early and you measure the deployment rather than the outcome, then conclude that a change which needed a quarter to land did not work. Review too late and the decision no longer matters, because the capacity has already been reabsorbed and the system has become part of the furniture.
Where is the result recorded?
Record it on the artifact the original approval produced, not in a new document. That is what makes the comparison possible at all: the hypothesis, the target, and the result end up in the same place, in the same words, and nobody has to reconstruct what was promised.
For most portfolios that artifact is the outcome scorecard. The outcome scorecard template entry explains what a scorecard should capture, including the decision this review writes into it. Use the scorecard itself rather than building a review pack around it. A separate review deck is how the promise and the result drift apart: the deck reflects what the team chose to present, while the scorecard reflects what was approved.
Whatever holds your portfolio, the rule is the same. One artifact per initiative, written at approval, updated at review, readable in a minute.
What does a good value realization review look like?
The numbers arrive before the meeting, with their dates and sources, and the review opens with baseline, target, and actual rather than a list of work completed. Anything in the world that moved the number for reasons unrelated to the initiative is named briefly, not used as a blanket excuse.
A good review keeps two questions apart: did the thing get built and adopted, and did the adopted thing move the number? A miss on the first is a delivery or change management problem. A miss on the second means the hypothesis was wrong, which is more useful information for the portfolio. The review ends in a scale, sustain, or retire decision with a named owner, and what it teaches about estimating and scoring goes back into the next Align cycle.
What does a value realization review look like in practice?
Say a finance shared services group automates invoice matching. The objective approved in Align is to cut average days to pay a supplier invoice from 18 to 9, measured 90 days after go-live, owned by the accounts payable manager.
At the review, the numbers are: baseline 18 days, target 9 days, actual 13.6 days. Adoption is 82 percent of invoice volume, with two supplier formats still handled manually.
The useful part of the discussion is the split. The system works on the volume it handles, where average days to pay comes in below the target. The miss is concentrated in the 18 percent still routed by hand, which holds a disproportionate share of the exceptions. That is not a failed hypothesis. It is an incomplete rollout with a named, sized remainder, and it argues for scale rather than sustain. Had the automated volume also come in at 13 days, the conclusion would be the opposite, and the right response would be to stop adding scope to it.
What goes wrong with value realization reviews?
No baseline. Nobody measured the old process, so the comparison is against memory. Capture the baseline before the work starts, during Focus.
Moving the target. The number is missed, so the objective is restated in terms the result satisfies. This is a common failure and a damaging one, because it destroys the portfolio's ability to learn anything about its own estimates.
Reviewing outputs. A list of delivered features is a status report, and a review that accepts one is not a value review.
Attribution taken too seriously, or not seriously enough. Few portfolio outcomes are cleanly attributable. Record the confounders in a sentence and move on, rather than either ignoring them or letting them excuse every miss.
No decision. A review that ends with "let it run" without saying which of the three options that is, and who owns it, leaves the initiative consuming capacity by default.
Value realization vs benefits realization vs a project post-mortem
All three look backward. They differ in what they measure and what they change.
| Value realization review | Benefits realization | Project post-mortem | |
|---|---|---|---|
| Compares | Actual production result against the approved objective | Actual benefits against the business case, often financial | What the team did against how they wanted to work |
| Timing | At the objective's measurement window, then as needed | Usually annually, or at benefit maturity | Shortly after delivery closes |
| Owned by | The investment decision authority | Finance or the PMO | The delivery team |
| Produces | Scale, sustain, or retire | A benefits report, tracked over years | Lessons and process improvements |
| Feeds | The next Align decision | The financial case for the next cycle | The improvement backlog |
Benefits realization is not wrong, and in a public sector or capital environment you will often have to do it regardless. The practical difference is cadence and consequence: benefits tracking reports on a business case, while a value realization review is expected to change what happens to the capacity next week. A post-mortem asks a different question again, about how the work was done rather than whether it was worth doing, and its output belongs in the improvement backlog.
Run both if you must, but do not let the annual benefits cycle stand in for the review that actually reallocates people. The wider vocabulary is in agile portfolio management terms, and if you are not sure your current portfolio could pass this kind of review, a 60-minute Portfolio Clarity Session is a place to start.