After a technical feasibility study, most teams carry the go recommendation straight into detailed design and a funded delivery plan. The step they skip is testing the assumptions that the go recommendation quietly depends on.
A technical feasibility study tests whether a proposed system can be built and operated with available technology and resources, and ends in a go or no-go recommendation.
The standard next step after a technical feasibility study
The textbook sequence is well established. The study goes to a stage gate, a sponsor or investment committee reads the recommendation, and a go decision releases funding for the next phase. That phase is usually detailed design, followed by procurement, a baseline schedule and a delivery team.
The study itself hands over a predictable set of outputs: a preferred technical option, a list of technical risks with mitigations, a cost and schedule estimate, and a statement of how mature the core technology is. Engineering organisations often express that last point on the NASA technology readiness scale, which runs from TRL 1, where basic research is only beginning, to TRL 9, where the technology has been proven in operation.
Stage-gate review is one of several decision-making models that organisations use at this point, and most decision-making frameworks treat the feasibility gate as the moment where uncertainty about the technology is formally retired. After the gate, the questions change. Teams stop asking whether the thing can be built and start asking how fast and at what cost.
From there, the feasibility report becomes a reference document. Its technical risk list migrates into the project risk register. Its estimate becomes the budget. The recommendation stops being a conclusion under review and becomes the premise that every later plan is built on.
What that step adds
The gate does real work. It kills projects that cannot succeed before they consume serious money. A technology that has only been demonstrated in a laboratory should not anchor a production schedule, and a disciplined feasibility gate says so in writing.
The cost of skipping it is documented. The US Government Accountability Office built its Technology Readiness Assessment Guide on the finding that technologies which are not adequately mature have led to programme delays and cost increases. A formal assessment of maturity, completed before commitment, is the corrective.
The gate also creates an accountable decision point. Someone signs the go. The evidence behind it is recorded. If the project later struggles, a review can return to the study and ask what was known at the time. That places a genuine checkpoint inside the decision-making process rather than leaving commitment to momentum.
Finally, the study concentrates effort. By narrowing several candidate solutions to one preferred option, it lets the design team work on a single architecture with a known set of technical risks. That focus is worth a great deal on large programmes where rework is expensive.
None of this is wasted effort. The weakness lies in what the gate is asked to certify.
Write down the condition your go decision depends on most beyond the technology itself and ask who has tested whether it will hold on go-live day. Start the Walk →
Where the standard playbook breaks down
A technical feasibility study answers a conditional question: can this work, given the conditions the study assumed? The go decision answers a different one: will this work here, on this date, operated by these people, alongside these other systems? The second question rests on assumptions the study was never scoped to test.
Those assumptions concern the conditions around the technology: that testing time will survive construction delays, that staff will be trained before go-live, and that the organisations sharing an interface will coordinate. Because none of them appear in the feasibility report, none of them get challenged at the gate. They inherit the confidence that the technology earned.
Heathrow Terminal 5 is the clearest public example. The £4.3 billion terminal opened on 27 March 2008 for a single airline, British Airways, with a new automated baggage system at its core. The committee's findings point less at the technology than at the conditions around it. According to the House of Commons Transport Committee inquiry, construction delays squeezed the time available for testing and training. Proving trials were reduced in scope or cancelled because parts of the site could not be accessed. BA deferred its on-site familiarisation programme for passenger service and ramp staff by six weeks.
The opening date held. On the first day, staff struggled to reach their posts, the baggage operation fell behind and BA suspended checked baggage. Hundreds of flights were cancelled in the days that followed, and BA told the committee that 23,205 bags required manual sorting before they could be returned to their owners. The committee blamed poor communication between BA and airport operator BAA, alongside inadequate staff training and system testing. Its chair, Louise Ellman, said: "What should have been an occasion of national pride was in fact an occasion of national embarrassment."
The failure sat between two organisations, a pattern familiar from stakeholder analysis that maps who is involved without testing whether they will act in step. Brady and Davies (2010) later reconsidered the project's reputation as a model of delivery in light of the opening.
The pattern is not unique to T5. Flyvbjerg (2014) found overruns to be the norm on major projects and traced much of the problem to optimism bias and strategic misrepresentation, neither of which a technical study is designed to catch.
A feasibility study can prove the technology works and still leave the conditions of success unexamined.
The step to take first
Before the go recommendation releases funding, list the assumptions the go decision depends on beyond the technology itself.
The exercise is short and needs no second study. It asks what must be true about schedule, people, interfaces and the operating environment for the project to deliver what the feasibility report promised. The Universal Decision-Making Method gives it a structure: frame the decision, set out its tentative elements, surface the assumptions, decide what level of certainty is sufficient, then implement and monitor.
The third stage carries the weight. Each assumption gets written as a plain statement and classified. Has it been verified, or is it still believed? Belief left unexamined is where overconfidence does its damage. If believed, can it be tested before commitment, or does it need a monitor with a trigger attached? The go decision then becomes conditional on the assumptions that matter as well as on the maturity of the technology.
At Terminal 5, the assumption that proving trials and familiarisation would be complete before opening was testable in the months beforehand. A go-live date conditioned on those trials, with a named trigger for delay, would have turned a public failure into a schedule decision taken in private.
The same logic applies to any technical feasibility study. The technology case still gets made. The gate still gets passed. What changes is that the conditions of success are written down and sorted into verified and assumed, then monitored through delivery. Proof that the technology works becomes one input to the go decision, alongside evidence that the conditions of success will hold.
You could close this tab and carry that decision into another week.
Work through your decisionNo sign-up. Just pick your decision and start.
Grant Purdy is the co-author, with Roger Estall, of Deciding (2020), and the architect of the Universal Decision-Making Method.