Build a transformation thesis and portfolio

An investment committee receives three proposals labelled “digital transformation”: an enterprise platform, clearer status messages and a shared staff worklist. Professional judgment is not choosing the most modern-sounding proposal or summing arbitrary scores. A **transformation thesis** explains how an intervention changes organizational capability and work behavior to improve a defined outcome, and names the assumption that could overturn the decision. A **portfolio** sequences interdependent interventions under money, time and risk constraints, with room to stop or revise between stages. Deferring a large project can therefore be a sound transformation decision.

Start with the observed problem rather than vendor presentations. In a fictional service, customers make a follow-up call for 25% of 10,000 annual requests because they cannot see request status or because a case moves between teams without a clear owner. Each follow-up consumes an average of ten service minutes. The baseline is 2,500 follow-ups and 25,000 minutes, about 417 hours a year, provided the definitions of call and request are consistent. Not every call is avoidable: some represent legitimate exceptions or advice. Review a sample of reasons before turning these minutes into a promised benefit.

Suppose a review of 100 calls classifies 40 as unclear status messages, 35 as handoffs without a visible owner, 15 as missing documents and ten as other causes. These sample shares are clues for tests, not certain annual proportions. The message hypothesis is that clearer status, next step and expected timing will reduce calls driven by uncertainty, if the underlying status is accurate and current. The worklist hypothesis is that one visible owner at each handoff will reduce lost cases, if both teams keep ownership updated. An enterprise platform might combine both mechanisms, but it may consume the transformation budget before the causes are established.

| Option | First-year cost | Hypothesized effect on follow-up rate | Dependency or risk | | --- | ---: | --- | --- | | Current process plus limited training | 15,000 | Perhaps 1 percentage point | Missing status remains | | A: clear, synchronized status messages | 60,000 | Up to 6 points in similar cases | Requires a trustworthy status source | | B: shared worklist and handoff owner | 120,000 | Up to 8 points | Changes authority and data exchange | | C: enterprise platform | 400,000 | Vendor claims up to 10 points | Exceeds cap; migration not tested |

Do not add “6 + 8” and declare a 14-point reduction. Causes can overlap, and A's effect depends on accurate case status, which B may help maintain. Nor should we multiply speculative scores by invented weights and call the rank precise. First compare hard conditions: C cannot be funded from this allocation; A is feasible if the status source can be tested; B requires both teams to agree on decision rights and data exchange. Then compare learning and reversibility. A bounded trial of A is cheaper and easier to stop, and can show whether uncertainty is a material cause. It can also do harm if it sends incorrect status, so verify the data source before sending messages.

The conditional decision is a six-week A trial capped at 60,000, with shared status fields designed so B could reuse them. Do not automatically spend the remaining 120,000 on B. Before launch, define a stable request category, its follow-up baseline and, where feasible without harming users, a comparable category that does not receive the new messages. Record status accuracy, follow-up calls per 100 requests, call reason and cases lost at handoff. If uncertainty calls fall while information remains accurate, trial B on one sufficiently large handoff. If they do not, examine the reason classification and message design before the next investment. If material notification errors appear, stop automated messages and repair the status source.

What if the overall 25% does not move? The trial may have falsified an assumption before the organization bought a larger platform. That is useful learning, provided failure is not renamed success. More opened messages alone do not prove a better service. The outcome is fewer justified status calls without more complaints or slower decisions. People who rely on phone support may be affected differently, so compare channels and request types instead of reading only the aggregate. Record why C was deferred and what evidence could bring it back: perhaps smaller options fail while a need they cannot meet is demonstrated, with a migration and capacity plan under a new budget.

The practical sequence is to define outcome and denominator, describe each option's mechanism, separate hard constraints from testable assumptions, compare possible benefit with cost, risk, dependency and reversibility, and connect later funding to observed results. HM Treasury's Green Book structures option appraisal around costs, benefits and risks for its public-spending scope; we adapt that clarity of comparison, not its legal applicability, to the fictional enterprise. The GOV.UK Service Manual emphasizes a baseline and testing different solutions before treating benefits as established. The invented effect estimates in the table come from the case, not from either guide.