Solution options and option appraisal

Generating genuine options

The first step in appraisal: a diverse, genuinely viable set of options that protects you from confirmation bias.

The hardest part of option appraisal isn't the scoring or the cost modelling. It's generating options that are actually different from one another and genuinely worth considering. Everyone has preferences, and those preferences shape which options you bring before you've consciously decided anything.

The classic failure is the strawman: a modern cloud-native build, sat next to "keep the fifteen-year-old system exactly as it is" and "rewrite everything in assembly", so the answer you wanted all along looks inevitable. A seasoned board member or a GDS assessor spots that pattern in seconds, and once they do, they stop trusting the rest of your analysis.

The discipline that protects you is starting from the problem rather than the solution, and forcing yourself to develop at least one option you don't instinctively like. Research it properly, find its real strengths, and you'll occasionally discover it was the better answer all along.

A strawman doesn't just waste a slot in your appraisal. It tells the board you'd rather win the argument than find the right answer.

Defining evaluation criteria

Fair, relevant criteria chosen before comparison begins, so the appraisal stays balanced and transparent.

Criteria are the dimensions you compare options against, and the single most important thing about them is timing. Agree them, and their weightings, before anyone scores anything. Criteria chosen after the fact, tuned to favour the option you prefer, are one of the easiest forms of dishonesty to commit and one of the easiest to detect.

Standard government criteria cover strategic alignment with the Technology Code of Practice, user needs, total cost of ownership, delivery risk, operational sustainability, security and compliance, flexibility, and vendor or technology risk. Not all of them matter equally. A service with a fixed ministerial deadline weights delivery risk heavily; one handling sensitive data lets security dominate; a service with a three-person operations team can't afford to ignore operational sustainability.

When stakeholders disagree about the weights, resist the urge to smooth it over. That disagreement is telling you something real about competing priorities, and it's far better surfaced now than discovered at assessment.

If you can't agree the weighting before you score, you don't yet agree on what the decision is for.

Scoring and comparing options

Scoring as a decision aid, not a substitute for judgment, with the common biases made visible.

Scoring is where appraisal feels objective and quietly stops being so. A weighted numerical model that produces a total of 3.7 against 3.5 looks decisive, but that gap is almost always noise dressed up as signal. For most government decisions, traffic light scoring is more honest: red, amber, green tells a board exactly where an option fails rather than burying the failure inside an average.

Reserve numbers for the things that genuinely quantify, like cost and performance targets, and use narrative to explain the rest. Whatever method you choose, the biases are predictable. You'll anchor on the first option you assessed, inflate the scores of the one you secretly prefer, let a single strong result spread across unrelated criteria, and favour whatever builds on money already spent.

The cheapest defence against all of this is a second pair of eyes: have someone score independently, then compare where you diverge and talk through why.

Score every option honestly enough that your recommended one still shows its weaknesses. If it doesn't, you haven't finished.

Buy, build, or configure in government

Choosing a delivery approach by weighing fit, control, cost, and long service life through a government lens.

Whether to buy a commercial product, build something custom, or configure an existing platform is one of the most consequential calls you'll make, and in government it carries dimensions the private sector never has to think about. The Technology Code of Practice says share and reuse before you buy, and buy before you build, so a decision to build custom when a suitable product already exists is hard to defend at spend control.

The useful first question is whether the capability is commodity or differentiating. Authentication, notifications, and payments are commodities; you should be reaching for GOV.UK One Login or an existing pattern, not writing your own. A capability that implements unique policy is a different matter, and that's often where custom build earns its place.

Watch low-code especially carefully. It deploys fast and demos well, but the long-term questions about data portability, maintainability, and lock-in are the ones that decide whether you've made a good choice or just a quick one.

The right answer here isn't ideological. It depends on the capability, the fit of what's available, your team, and how you'd get out if it went wrong.

The 'do nothing' option

The baseline treated as a real option, because the cost of inaction is rarely zero.

Every appraisal needs a 'do nothing' or 'do minimum' option, and it isn't there as a courtesy. It's the baseline that every other option is measured against, and sometimes it's the honest answer. Including it forces you to articulate the case for change, and if you can't explain clearly why standing still is inadequate, you don't yet have a strong enough case to spend public money. "The current system works but could be better" will not carry a £5m programme.

The cost of doing nothing is almost never zero either: there's ongoing maintenance, support, licensing, and the hidden cost of every workaround people have built to cope. It's worth separating 'do nothing', which means genuinely no change, from 'do minimum', which means the smallest set of changes that addresses the most pressing risks. Do minimum is frequently the most proportionate option on the table, and a board will respect you more for putting it there honestly than for pretending the only choice is a large new build.

If 'do nothing' looks acceptable in your appraisal, that's not a problem with the option. It's a signal your case for change needs more work.

Presenting options honestly

A presentation that helps a board decide well, rather than steering it toward a preferred answer.

How you present options matters as much as how you evaluated them, because a board can only make a good decision from what you actually show them. Set the context first, give them the whole landscape before the detail, then work through each option with its strengths, its weaknesses, and a cost expressed as a range rather than a falsely precise single figure.

When you reach your recommendation, state it plainly and explain the trade-off you're accepting: "we recommend Option B because it balances cost and delivery risk best, knowing it scores lower on flexibility than Option C". Then do the thing most architects are tempted to skip, and set out the risks of the option you're recommending alongside the mitigations you propose. Boards that discover those risks later, on their own, stop trusting your judgment.

Your job is to inform the decision, not to make it, and if the board chooses differently you support that choice professionally while documenting any risk you flagged.

A good presentation makes the decision clearer, not narrower. Show the downsides of what you recommend, not just the upsides.

Cost, benefit and risk analysis

Cost, benefit, and risk brought together so decision-makers can judge value, not just price.

Cost-benefit-risk analysis is the standard frame for appraisal in government, and it sits directly alongside HM Treasury's Green Book, so programme boards and spend control teams will expect to see it. Cost means total cost of ownership across the service's life, typically five to ten years, taking in implementation, migration, ongoing operation, the cost of likely changes, and decommissioning at the end. Present it as a range, and be explicit about what's in and what's out; an early estimate carrying 50% uncertainty is more honest stated that way than disguised as a precise number.

Benefits won't all reduce to cash, and you shouldn't force them to. Cash savings get the most scrutiny, efficiency gains can usually be expressed as time saved, but risk reduction and strategic value often have to be made qualitatively, with as much specificity as you can manage. Then pair every risk with a credible mitigation, because a risk on its own is a problem, while a risk with a plan attached is a managed concern a board can accept.

Tell a story about value, not a spreadsheet. What it costs, what it delivers, and what it puts at risk.

Common pitfalls in option appraisal

The biases and omissions that quietly undermine appraisals, and the habits that keep them honest.

Most appraisals don't fail because the arithmetic was wrong. They fail because of bias, omission, and weak challenge. The most damaging trap is the predetermined conclusion, where you've already decided what to recommend and reverse-engineer the criteria, the scoring, and the alternatives to support it. Close behind is the missing option, the genuinely good approach that never made the page because it was unfamiliar, politically awkward, or needed cooperation from another department.

Then there's the asymmetry that creeps in around your favourite: you estimate its cost more generously, identify fewer of its risks, and let sunk investment flatter it because "we've already spent the money", when that money is gone whatever you decide. You can't reliably see these biases in your own work, which is exactly why peer review is the strongest safeguard you have. Hand the appraisal to another architect before it reaches the board and ask them to find the bias you can't.

Assume bias is present, invite the challenge early, and treat peer review as part of the work rather than a check at the end.