A programme that finishes on time and within budget has answered one question well and left another one entirely open. Project success has traditionally been judged against what is often called the iron triangle — cost, time and quality — but Atkinson (1999) makes the case that this is a weaker test than it looks: cost and time are, at best, two guesses made when least is known about the project, and quality is "a phenomenon", an emergent property that different stakeholders judge differently, rather than a fixed line to hit. A programme can satisfy all three and still fail the test that actually matters to the people who funded it — did the organisation get what it paid for?

That second test is benefits realisation. The Project Management Institute (2019) defines benefits realisation management as the discipline of identifying, planning, tracking and confirming that the benefits promised in a business case are actually delivered — a distinct activity from delivering the project's outputs, and one that typically runs for longer. Most digital benefits do not appear the day a system goes live; cost savings, revenue growth and customer-experience gains accumulate as adoption spreads and old habits fall away, often over months or years after the project itself has formally closed and its delivery team has moved on. That time lag creates an accountability gap unless someone is explicitly made responsible for it: a project manager can reasonably be judged on delivery, but benefits realisation needs an owner — usually the business sponsor — who is still answerable for the numbers long after the delivery team's job is done.

Conflating the two measures is not a harmless simplification; it lets a programme declare victory the moment it goes live, before the only evidence that actually matters — did the benefit show up — has had time to exist. Separating them is what makes a later, honest "did it work" conversation possible at all.

A baseline is only useful if someone goes back and measures against it. Module 1 scored Thornfield's digital maturity at 2.1 out of 5 across strategy and leadership, technology and data, customer experience, and innovation culture — a four-dimension model consistent with the strategy-led view of maturity in Kane, Palmer, Phillips, Kiron and Buckley's (2015) research. Re-measuring maturity means returning to that identical model, dimension by dimension, rather than quietly redesigning the scorecard to flatter whatever has actually changed; a maturity assessment that measures different things at baseline and re-measurement cannot honestly report a before-and-after figure at all, because the two numbers are not describing the same thing.

Interpreting the result is where the discipline gets harder than the arithmetic. A score that has risen but still sits below its target can mean several quite different things, and the re-assessment's job is to say which: the organisation may simply be behind where it should be; it may be on a longer, perfectly sound path than the roadmap first assumed, with the shortfall a matter of timing rather than direction; or the original target may itself have been set with more optimism than evidence. Each explanation calls for a different response — accelerating effort, extending the timeline, or revising the target — and a re-assessment that doesn't distinguish between them leaves leadership no better placed to decide than before it was commissioned.

There is also a quieter risk worth naming: whoever runs the re-assessment usually has some stake in the result looking like progress, which creates a subtle pressure to score generously. Guarding against this means being explicit, before the scores are seen, about what evidence justifies moving a dimension up or down — the same discipline that made the original baseline credible in the first place.

Module 2 built Thornfield's digital business case around the structure Ward and Peppard (2002) set out: costs, and benefits split into those that are quantified in money, those that are measurable but not easily monetised, and those that are observable only qualitatively. Revisiting the financial case means returning to that same structure with actuals in place of forecasts — recalculating return on investment, payback period and net benefit on what has actually happened, not on what the original business case projected would happen.

A gap between the original projection and the actual result is not, by itself, evidence that the original case was wrong. Flyvbjerg (2006), drawing on his team's studies of large transport infrastructure projects, argues that cost and benefit forecasts are systematically distorted by optimism bias — the ordinary human tendency to underestimate cost and overestimate benefit — and, in some cases, by strategic misrepresentation, where a sponsor shades the numbers to get a proposal approved. A digital business case carries the same two risks on a smaller scale. So a shortfall against target has at least two live explanations that call for different responses: the original estimate may have been too optimistic, in which case the lesson is about how the next business case should be built; or the benefit may simply be arriving more slowly than planned, in which case the lesson is about adoption, not about the estimate. Distinguishing between the two requires looking at the mechanism behind the shortfall, not just the size of the gap.

A board scorecard tends to collect metrics of genuinely different kinds — financial, maturity, customer, team — and the temptation is to let the best-looking number carry the room. Customer Net Promoter Score is a useful case study in why that temptation should be resisted. Reichheld (2003) proposed NPS as a single figure calculated from the percentage of customers who are promoters (likely to recommend) minus the percentage who are detractors, answering one recommendation question on a 0–10 scale, and argued it was a cleaner proxy for customer loyalty than longer satisfaction surveys. The simplicity is also the limitation: compressing an entire distribution of customer sentiment into one number discards the texture a longer survey would have kept, and NPS benchmarks vary enough by sector that a score which looks poor in one industry would be considered strong in another — a single number read without its sector context, or without the qualitative feedback behind it, is easy to misread in either direction.

The same caution applies to combining NPS with the other metrics on a transformation scorecard: maturity, cost-to-serve and team engagement are measured in different units, on different scales, for different reasons, and no single one of them should be allowed to stand in for the whole picture — a strong engagement figure does not offset a weak financial return, and a strong financial return does not excuse a maturity score that still lags its target. The discipline that makes a scorecard trustworthy is reporting every metric against the target set for it at the outset, not against a revised, more comfortable goal chosen after the fact because the original one looks unflattering. A board that sees the original targets alongside the actuals can do its own weighing of what matters most; a board shown only the metrics that look good, or targets quietly softened to match the result, cannot.