Technical Feasibility Assessment: The Evidence Needed Before You Fund a Build

Before funding the build

A technical feasibility assessment exists to answer one question: can this be built and paid for under the conditions you actually have? Theoretical possibility is cheap. Almost anything is possible with unlimited time and budget, which is why "yes, that's technically achievable" is the least useful sentence in a business case.

The record backs the caution. The Standish Group's 2020 CHAOS data puts 31% of projects in the successful column, with half challenged on cost or time. Bent Flyvbjerg and Alexander Budzier found something sharper in 1,471 IT projects: average overrun of 27%, but one in six was a black swan at roughly 200% over budget.

Untested assumptions are what turn a sensible plan into one of those outliers.

What the assessment decides

Feasibility is an investment test. It asks whether the proposed solution works against real constraints. It then asks whether the organisation can run it once built, and whether the cost of getting there still leaves the commercial case standing. A technical feasibility assessment that only answers the first of those three has answered a third of the question.

This is different from technical discovery. Discovery plans delivery: architecture and backlog. It belongs after the idea has earned further commitment. Feasibility work comes first and is deliberately narrower, because its job is to find the things that would make detailed planning a waste of money.

Flyvbjerg, who holds the BT chair in major programme management at Oxford, put the failure mode plainly to the BBC: "IT managers tend not to see these black swans", because they assume the rare event will happen to somebody else. Evidence is how you stop assuming.

Technical feasibility assessment scope

A technical feasibility assessment covers the areas where problems either stop delivery or raise the investment you need. You are hunting for the constraints that change the number on the approval paper.

The National Audit Office traced this back to sequencing. Gareth Davies, head of the NAO, wrote that underperformance in digital change "often resulting from decisions on technology" taken too early, before the business problem is properly understood. The scope below is designed to surface those decisions while they are still reversible, and it feeds directly into the technical risk assessment described later.

Systems data and integrations

Legacy estates are where feasibility work earns its keep. The UK government's own definition of a legacy system covers anything "based on an end-of-life product" or unsupported by the supplier. If your proposed solution depends on one, the integration path is a finding you need.

Data is the other half. Gartner's research puts the cost of poor data quality at $12.9 million a year on average for the organisations it surveyed, and the same gaps that drain operations will break a new platform that assumes clean records. Check what the source systems actually hold and whether the application programming interfaces (APIs) you need exist or have to be built.

Performance and infrastructure

Demonstrations run on ideal conditions. Production does not. Test scalability and latency against the load you expect at peak, on the devices and connections your users have.

A technical feasibility assessment that skips load evidence discovers its ceiling after go-live, when the fix is a rewrite rather than a design choice. Where reliability targets are contractual, the assessment should say what architecture is needed to hit them and what that costs. Infrastructure capacity has lead times, and those belong in the schedule.

Security and compliance

Regulation reshapes architecture and budget, so it has to be priced before approval rather than discovered during build. The Information Commissioner's Office can impose penalties up to £17.5 million or 4% of worldwide turnover for the more serious infringements. In October 2025 it settled with Capita at £14 million over a 2023 incident affecting more than 6.6 million people.

For organisations operating in the European Union, the NIS2 Directive raised the baseline across 18 sectors with a member state transposition deadline of 17 October 2024. Assurance requirements and penetration testing cycles consume time. A technical feasibility assessment prices those controls into the estimate instead of treating them as a later phase.

Skills and operations

Build capacity is only part of it. Somebody has to run the thing at 3am in year three. Assess whether you have the specialist skills and the operational headroom to sustain what you are proposing.

The UK market makes this concrete. The Department for Education's Employer Skills Survey 2024 recorded 250,500 skill-shortage vacancies, 27% of all vacancies, with advanced or specialist IT skills missing in a quarter of them. Among IT specialist manager roles, the Learning and Work Institute found 64% were hard to fill. Any technical feasibility assessment that assumes you will simply hire the capability needs to say how, and by when.

Evidence that reduces uncertainty

The point of this work is conversion: take the assumptions carrying the most weight and turn them into findings. You are buying certainty on the handful of questions where being wrong is expensive.

Pick those questions by asking which assumption, if false, would change the decision. Most concepts rest on two or three of them. Everything else can wait for discovery, and saying so explicitly is what keeps a feasibility exercise from swelling into a paid architecture project.

Prototypes and technical spikes

Workshops produce opinions. Diagrams produce agreement about opinions. Neither tells you whether the legacy API sustains the throughput you need, and that is what a spike is for. The Agile Alliance describes a spike as work "whose purpose is to provide the answer" to a technical question rather than shippable product.

Scaled Agile frames technical spikes as a way to "reduce the risk of a technical approach" and increase the reliability of estimates. In practice, a two-week integration test against the real system beats a month of architectural debate, because it produces a number. Benchmarks and working prototypes do the same job.

Estimates and dependencies

Single-figure estimates hide everything a decision needs. HM Treasury's Green Book guidance addresses this with explicit optimism bias uplifts, which include an upper bound of 200% for outsourcing projects where contributory factors go unmanaged. Range-based estimating is honesty about what has been tested.

What the estimate pack should carry:

• Cost and timeline ranges with the assumption behind each end of the range, and a stated confidence level

• Sequencing constraints, including infrastructure lead times and anything that cannot start until a dependency lands

• External dependencies you do not control, such as third-party APIs, vendor roadmaps, regulatory approvals or data access from another business unit

• The two or three factors most likely to move each figure, named, so movement is expected rather than treated as failure

The Emergency Services Network shows the cost of skipping that discipline. By March 2023 the Home Office had spent close to £2 billion without a functioning replacement network. Dame Meg Hillier, then chair of the Public Accounts Committee, called it "a classic case of optimism bias" with no realistic plan behind it.

Technical risk assessment

A risk register earns its place when it separates manageable uncertainty from the blockers that threaten the investment. Record each risk with likelihood and impact, and attach the evidence supporting that judgement so a named owner holds the mitigation and the residual exposure after mitigation. Without the evidence column, a technical risk assessment is just a list of worries ranked by who spoke loudest.

Residual exposure is the figure that matters at approval. If a risk stays high after every mitigation you can afford, that is a finding about the concept rather than a task for the delivery team. The British Airways penalty of £20 million is the kind of consequence that belongs in a register with a cost attached.

Keep the technical risk assessment tied to tested evidence. A risk downgraded because a spike proved the integration works is a real reduction. One downgraded because the team feels better about it is not.

Alternative approaches

Some concepts are possible and still not worth funding. That is the most common outcome worth catching, because it is the one people avoid naming. When the evidence says the original shape is too expensive, compare reduced scope against phased delivery.

Vendor comparison is where a software feasibility study pays for itself. Buying 80% of the capability and integrating it changes the cost profile and the time to first value. Present the options with the same estimate ranges and the same risk treatment, so the comparison is genuine rather than decorative.

Technical feasibility assessment scorecard

Scoring makes the decision reviewable. Weight each area by how much it influences the investment and score it on the evidence you hold rather than the confidence you feel. Agree the weights before the findings arrive so nobody tunes the model to the answer.

A workable weighting for a complex build:

1. Evidence strength, 15%. Has the critical assumption been tested, or only discussed?

2. Architecture and integrations, 15%. Includes API availability and the state of any legacy dependency.

3. Data availability and quality, 10%. Scored against the actual source records.

4. Performance and infrastructure, 10%. Measured under realistic load.

5. Security and compliance, 10%. Controls identified and costed.

6. Skills and operations, 10%. Covers both build capacity and the long-term support model.

7. Cost and schedule confidence, 15%. Ranges with assumptions, not point estimates.

8. Dependencies and technical risk assessment outcome, 15%. Residual exposure after mitigation.

Set the pass threshold at 70% overall with no individual area below 50%, because a strong average hides a single fatal constraint. Treat these as critical failures regardless of total score: no viable integration path to a system you must connect to, or a residual risk whose cost exceeds the expected return.

Sample approval evidence pack

The pack is what turns weeks of investigation into a decision that takes an hour. Keep it short enough to be read in full before the meeting, and put the recommendation where nobody has to hunt for it.

What an approval discussion needs in front of it:

• A decision summary of one page, with the recommendation stated first

• The assumptions tested, the method used for each, and the result

• Prototype, benchmark and integration test findings, including anything that failed

• The option comparison, with estimate ranges and confidence levels for each option

• A dependency map showing sequencing constraints and external owners

• The risk register with residual exposure, and the scorecard against the agreed thresholds

• Unresolved questions, with the cost and timescale of resolving each one

That last item is the one teams drop, and it is the one that protects you. Naming what remains unknown, and what it costs to find out, is how a technical feasibility assessment supports a conditional approval instead of forcing a binary bet. Every claim in the pack should trace to a test or a measurement.

Make the funding decision

Agree the decision criteria before the evidence lands, then apply them. Five outcomes cover the ground. Go and conditional go are two of them, and pivot and pause are two more. No-go is the fifth. Which one applies follows from the scorecard and the residual exposure in the technical risk assessment.

Conditions have to be tied to something specific. A conditional go releases funding for the first phase while a named integration risk is retired, with a defined checkpoint and a stated cost for the mitigation. A pivot follows when the evidence supports a different architecture or a vendor route. A pause is the right answer when a dependency you do not control has to move first.

No-go deserves more respect than it gets. The NAO identified this pattern across 11 government digital strategies over 25 years, with the same themes recurring because programmes proceeded past the point where the evidence said stop. A technical feasibility assessment that produces a well-argued no has saved you the overrun you would otherwise have funded.

Get targeted evidence

Most investment decisions hinge on two or three uncertainties. Evolved Ideas has spent 19 years building bespoke software for clients including the NHS and Bridgestone, and that work starts by understanding the problem before recommending anything. If you are weighing a significant build and want the riskiest assumptions tested first, talk to our team about a focused technical feasibility assessment.