There is a real tension here, and it is worth naming. Boards want confidence that a programme can be delivered before they commit, but they do not want six months of study that burns the urgency, the budget and the goodwill before any value appears. A feasibility assessment that becomes its own mini-programme has failed at its own job.
The way out is to be ruthless about what feasibility actually has to answer. It is not "have we designed the solution." It is a much smaller set of questions. Is the goal achievable with the time, money and capability available, what are the two or three things most likely to make it fail, and what would have to be true for those to be manageable. Everything else can wait.
I run these as short, intense pieces of work, not long ones. A focused team, a handful of weeks, direct access to the people who actually know the constraints. The aim is depth on the few questions that decide the outcome, not breadth across everything that could eventually matter. Most of the delay in feasibility work comes from studying things that were never going to change the decision.
Speed also comes from being willing to reach a negative answer. A lot of assessments drag because no one wants to be the one who says it cannot be done in the form proposed. If you treat "not feasible as scoped, but feasible if we change these two things" as a perfectly good outcome, the work moves much faster, because it is no longer a search for a way to say yes.
The output should make the next decision easier, not heavier. A board should be able to read it and choose with confidence. Proceed, proceed with these changes, or stop. If the assessment ends in more questions than it started with, it was scoped wrong.
Done this way, feasibility is not a brake. It is the thing that lets you commit hard later, because you already know where the programme is most likely to break and you have decided what to do about it. That is faster than discovering it in delivery, by a wide margin.