Value case
Put the argument for scaling a solution you have tested on one board that a decision maker can read in five minutes.
- Time
- 45 min
- People
- 3–6
- Kind of work
- Scale · Choose
In short
A value case is a one-board argument for scaling a tested solution. It sets out who it serves, what changes for them, how it reaches them, what it takes, the evidence so far, what the organisation gains and the risks. To build one, gather your test results, fill each box in plain language, then challenge every claim against evidence.
What it is
When a pilot works, the team that ran it usually knows why, but the people who must fund and approve a wider rollout do not. A value case closes that gap. It is a single board, in plain language, that answers the questions a decision maker will ask before saying yes: who is this for, what difference does it make to them, how will it reach everyone it should, what will it cost in money, people and systems, what evidence do we have, what does the organisation get back, and what could go wrong.
It is not a full business case. There is no detailed financial model and no option appraisal. It is the short argument that comes first, and that a formal business case can later build on if your organisation requires one. Moving from a successful test to a wider service is a recognised step in public-sector innovation practice, and the value case is Tiremesù's worksheet for it. It works best when every box can point to something you measured or observed in the test. In this worksheet you record seven boxes: who it serves, what changes for them, how it reaches them, what it takes, evidence so far, what the organisation gains, and risks and open questions.
When to use it
Use it when
- A pilot or prototype has worked in one place and you need approval to extend it.
- Leaders keep asking for the full business case before the team knows enough to write one.
- Several tested ideas compete for the same budget and you want them compared on the same terms.
- You are about to bring a solution to a challenge panel or a steering committee and need a clear starting document.
- A solution is being handed from an innovation team to an operational owner, who needs to understand what they are taking on.
Skip it when
- You have not tested the solution yet. Without evidence the board becomes a list of hopes; run a hypothesis test or a small pilot first.
- Your organisation needs a formal business case with costed options for a major investment. Use the value case to prepare, but do not present it as the final document.
- The change is small enough that the operational owner can simply decide and do it. A board and a meeting would only slow it down.
You need
- Time
- About 45 minutes to fill the board with a team that ran the test, plus time beforehand to pull the results together.
- People
- 3 to 6 people: the people who ran the test, someone from finance or planning, and the person who would own the service at scale.
- Materials
- Test results and measures, cost and staffing figures, a one-page board with seven boxes on a wall or shared screen, and sticky notes.
How to run it
Step 1: Gather the evidence first
Before the session, collect what the test produced: measures before and after, numbers of people served, quotes from users and staff, costs and time spent. Put it on one sheet. The value case rests on this; without it the session becomes a pitch.
Step 2: Name who it serves
Describe the people the solution is for, and how many of them there are at full scale. Be specific: "about 18,000 patients a year discharged from medical wards" is better than "patients". Note any groups the test did not reach, since a decision maker will ask.
Step 3: Say what changes for them
Write, in the users' terms, what is different for them because of the solution. Use measured change where you have it, such as fewer return visits or shorter waits, and say how it was measured. Keep each claim to one line.
Step 4: Explain how it reaches them and what it takes
Describe how the solution will be delivered to everyone it should serve: channels, places, partners and the order in which it grows. Then list what it takes: money, staff time, training, systems and any rule changes. Separate one-off costs from running costs.
Step 5: State what the organisation gains
Write the benefit to the organisation in terms its leaders already use: cost avoided, capacity released, complaints reduced, targets met. Connect each gain to evidence from the test, and mark clearly which gains are estimates.
Step 6: List the risks and open questions
Write the main things that could stop it working at scale, and what you still do not know. Include risks the test could not show, such as a busier site, a different population or a partner who may not stay. Honest risks make the case more credible, not less.
Step 7: Challenge every box
Read the board aloud as if to the decision maker. For each claim, ask "how do we know?". Strike out or soften anything the evidence does not support, and turn gaps into actions. The result is a board you can stand behind in the room.
Worked example
A tertiary hospital had tested a nurse-led follow-up phone call within 48 hours of discharge on two medical wards for three months. Of 640 patients discharged in the test, 590 received the call. Emergency readmissions within 30 days fell from 14% to 10% on those wards, against no change on comparable wards. The team needed approval to extend the call to all 11 medical wards.
Five people filled the board in 45 minutes: the ward nurse manager who led the test, two of the calling nurses, a finance analyst and the deputy director of nursing who would own the service.
Who it serves: about 18,000 patients a year discharged from medical wards, with a note that the test had included few patients who did not speak Arabic, since interpreter calls had not been set up.
What changes for them: a named nurse calls within two days, checks medicines and warning signs, and books an earlier clinic slot if needed. Two in three patients in a short survey said the call answered a question they would otherwise have taken to the emergency department.
What it takes: six nurses' time spread across shifts, about 12 minutes per call on average, a call script, a simple log in the existing patient system and one morning of training. The analyst estimated the running cost at about 1.1 million riyals a year.
What the organisation gains: if the four-point fall held across all medical wards, about 720 fewer readmissions a year, which the analyst valued at well above the running cost. The board marked this as an estimate based on two wards.
Risks and open questions: other wards might see a smaller effect, nurse vacancies could squeeze call time, and interpreter calls were untested. The deputy director proposed rolling out to five more wards first and reviewing readmissions after six months, and the case went to the nursing executive in that form.
IllustrativeTips and mistakes
Tips
- Write it for someone who has not been near the project. If a box only makes sense to the team, rewrite it.
- Use the test's own numbers wherever you can, and say where they came from in a few words.
- Mark estimates as estimates. One overclaimed number can sink a sound case.
- Bring the future owner of the service into the session. Their name on the board makes the case more believable.
Common mistakes
- Filling the board with ambitions rather than evidence, so the first question from a decision maker brings it down.
- Leaving out running costs because the test was funded from a project budget.
- Assuming the result in one place will be the same everywhere, without saying how the wider setting differs.
- Hiding the risks to make the case look stronger, which only moves the surprises to after approval.
What you walk away with
You leave with a one-board value case in plain language that a decision maker can read in five minutes, every claim tied to evidence or marked as an estimate, and a short list of open questions. The next step is usually to test the case with a challenge panel before it goes for approval, then to sequence the growth in a roadmap.
Questions people ask
What is the difference between a value case and a business case?
A value case is a short, plain-language argument on one board, built from the evidence of a test. A business case is a longer formal document with costed options and financial analysis, often required for major investment. The value case usually comes first and feeds the business case.
How much evidence do we need before writing a value case?
Enough to support the main claim with something measured or observed in a real setting, usually a pilot or a structured test. If you only have opinions and plans, test first.
Who should present the value case?
Ideally the person who will own the service at scale, supported by the team that ran the test. Decision makers are more likely to approve a case when the future owner is the one asking.
Tool card
The worksheet your team fills in, one box per field.
- Who it serves
- What changes for them
- How it reaches them
- What it takes
- Evidence so far
- What the organisation gains
- Risks and open questions