10 Questions Boards Should Ask Before Approving the Next Transformation
Most programmes that disappoint were approved without answers to questions nobody asked. Each of these ten is reverse-engineered from a way programmes later go wrong.
- Programmes that underdeliver usually got approved on a case that did not contain the answers the programme would later need. The answers surfaced in delivery, when they cost far more to work out.
- The ten questions below bring those answers forward to the approval meeting, while they are still cheap. Each one is drawn from a specific way programmes go wrong afterwards.
- The position worth holding is not “we approved a credible case”. It is “we asked for the detail in proportion to the money, before we approved it”.
The paper goes to the board. The sponsor presents. The case is well documented, the risks are listed, the benefits are quantified. The board discusses and approves. The programme starts.
Twelve months later it is six months behind. Eighteen months later the benefits are partial. Two years later the board is reading a remediation paper that redesigns what should have been designed before approval.
This is the common pattern, and the cause is usually the same. The board approved a case built on commercial intent, executive conviction and a benefits model — but not on any real description of how the business would work afterwards. Those questions surfaced later, in delivery, when answering them was expensive.
The ten below are meant to be asked at approval rather than at remediation. Each one is hard to bluff. Each one surfaces a decision that, deferred, produces a predictable problem. The discipline is to ask them even when the case looks ready, and especially when asking creates awkwardness in the room. Asking late costs far more than asking early.
How will the business actually work afterwards — in as much detail as the technology?
Open the paper. Find the technology section. Note the detail: platforms named, integrations documented, data flows described, vendors justified. It is specific.
Now find the section describing how the business will run afterwards. In most mid-market papers it is at vision level — target state principles, capability statements, strategic intent. Nothing like the same standard.
That gap is the most reliable predictor of drift. The technology will get built to specification because a specification exists. How the work is done will get built to whatever emerges during delivery, which is far less. The test is symmetry: if the technology runs to paragraphs and the operating model runs to bullet points, it is a technology programme whatever the paper calls it.
Which executive wrote the description of how the business will work — not who is delivering it?
The programme has a sponsor. Delivery has an owner. Architecture has a lead. All three are named in the paper.
What is rarely named is who actually wrote the description of how each part of the business will run. The sales director who wrote the commercial half. The operations director who wrote the operational half. The finance director who wrote the financial one. Each of them signing off on the part their own team will have to live with.
When the answer is “IT” or “the programme team”, the future has been designed by a delivery function for people who did not write it. The test is authorship rather than consultation. Being shown something in a workshop is not the same as having written it, and the difference shows up eighteen months later as resistance nobody predicted.
For each benefit, which number moves and what makes it move?
The benefits case is there. The numbers are credible. The sponsor can defend the assumptions. The total justifies the spend.
The question to ask on each line is which number on the management accounts moves, and what specifically causes it to. If the answer is “improved efficiency” with no named number, the benefit is a hope. If it names a number but nobody can describe the mechanism, the benefit is an assertion.
The test is mechanism. Every line should name the number, the thing that moves it, the person who owns that thing, and how it will be measured. Most mid-market cases do not survive this cleanly, and the ones that do are noticeably better programmes.
The questions a board asks before approval are the cheap version of the questions it will ask after failure.
Who is accountable for each benefit, and how would you know if they were not delivering it?
The case attributes value. The question is who is attributable.
In most papers the sponsor is named as owner of the benefits overall. That is governance rather than accountability. No one person can cause each benefit to appear; they depend on teams outside the programme’s authority.
The test is a named person per line, with a mechanism. Each benefit has a functional director — not the sponsor — who has committed to it, and a way of tracking whether they are delivering, separate from whether the programme is shipping. Without that, the programme will deliver capability and the benefits will not appear.
What is the change budget based on?
Find the change line. Note its size against technology and consulting. In mid-market cases it is often a small single-digit or low double-digit percentage of the total.
In programmes that actually landed their benefits, it tends to be a much larger share. Under-pricing this line is one of the most reliable patterns in mid-market transformation, and it is under-priced because it is the easiest line to cut when the total looks high.
The test is whether it was costed against the number of people whose jobs change, rather than against the pilot. It should cover getting the new way of working started, changing what people are measured on, building capability, coaching the leadership, and dealing with people who do not want it — not just training and a communications plan.
Knowing which of these ten your current case would struggle with is the useful part.
A free Executive AI Opportunity Assessment. Forty-five minutes, online, with your leadership team. We arrive with a model of how firms in your sector make money and where AI has moved those numbers — and you tell us where it is wrong.
Book a free assessmentWhat happens if it is six months late or a quarter over budget?
Most papers carry a risk register and mitigation plans. The sharper question is what specifically happens if month eighteen arrives with real slippage.
“We will manage it” is not an answer. The answer names which workstreams continue, which pause, which stop, what brings it back to the board, and who decides during the difficult period. Without that, the board is approving with no agreed response to the most likely thing that will happen.
The test is that the scenarios are written down before they occur, with decision rights already assigned. It costs an afternoon to do and it is the difference between a controlled decision and a panicked one.
Rework of the paper and some design effort. The cheapest moment there will ever be.
Scoping and vendor engagement have begun. Contracts get renegotiated and teams reassembled.
Vendors renegotiated, teams disrupted, credibility spent, benefits slipping.
Written off. Value recovered partly or not at all, with the cost falling well outside the programme.
These figures come from Barry Boehm’s work on software engineering economics, first published in 1981, which measured what it costs to fix a defect at successive stages of development. It did not measure transformation programmes, so the application here is by analogy rather than by evidence. The analogy holds because the mechanism is the same: a decision gets embedded in contracts, code, org design and expectations, and each of those has to be unpicked. The exact multiples are not the point. The direction is, and it is steep.
Which directors have signed, in writing, for the changes their own teams will live with?
The paper claims the business will work differently. The directors have been consulted. Workshops happened. Steering meetings met. Their input is reflected.
The test that cannot be bluffed is a signature. Each director has signed a specific commitment to the changes their team will adopt, the timing, what they will be measured on afterwards, and any change to headcount or skills. Not “supported the strategy” — committed to run it.
If those signatures do not exist, the consultation gathered opinions rather than commitments. The programme proceeds, and eighteen months later the functional teams discover they are being asked to work in a way they never agreed to. The resistance that follows is usually read as a change management problem. It is an approval problem.
Three things to do before the next paper reaches the board
- Work through the ten and mark the ones you would rather not answer in detail today. Those are the ones to settle before the paper is written, not after it is approved.
- Check which directors have signed in writing for the changes their teams will live with. If any have not, the case is not ready. Postpone it.
- Ask which decisions the vendor choice has already closed off. If technology commitments have narrowed the options for how the business can work, the board needs to see that in the paper rather than find it in a technical appendix.
What has the technology choice already decided for us?
The paper often arrives after the platform has been chosen and the integrator engaged. The technical shape is largely set.
The question is which decisions about how the business will work have already been closed off by those choices, and which are genuinely still open. Where this is done well, the technology follows the design of the work. Where it is done badly, the design of the work quietly narrows to fit the technology, and nobody says so out loud.
The test is that the paper shows the order things were decided in, and which options are now closed. If it presents the technology as the platform that will support the new way of working, when in fact the new way of working is being shaped around the technology, the order has been reversed. That is the most common programme failure there is, and it usually hides behind confident language about architecture.
Who owns the new way of working once the programme ends?
The programme is funded for a period. It will finish. Then what?
In most papers this is the thinnest section. The programme delivers the change; the line organisation then runs it. But nobody is made responsible for watching whether it is still being run as designed, spotting the drift, or deciding what to do about it.
The cost is quiet. Teams slide back towards what they did before. Decision rights blur. Six months after the programme closes, the way the business works differs materially from the way it was designed to work, and no single decision caused it. The test is custodianship: who owns this in its working life, with what authority, and how would they know it was slipping.
What are the options, other than approve or decline?
Most papers offer a binary. Approve as proposed, or do not proceed. The board is framed into go or no-go.
The real choice is richer. Approve as proposed. Approve with conditions. Send it back to be redesigned. Decline. Each has different economics and a different chance of working, and the paper should cost each rather than presenting one option against doing nothing.
The test is whether the board is being asked the right question. “Should we do this?” is a weaker question than “what is the best version of this?” — and the second one usually surfaces a redesign that is better than what was proposed. Boards that only ever get asked the first question approve a lot of second-best programmes.
What this means
None of these ten questions are exotic. They are present in every well-governed programme. What is rare in the mid-market is asking them consistently, and being willing to defer approval when the answers are not ready — which is harder than it sounds when the sponsor is in the room and the momentum is towards yes.
The pattern behind the failures is always the same. The board approved a case that did not contain the answers the programme would need. The answers got worked out during delivery, at many times the cost. In hindsight the board would have wanted harder questions earlier, but the dynamic in the room favoured forward motion over rigour.
The economics are not close. A gap closed before approval costs design effort. The same gap closed during delivery costs delivery money, disruption and credibility. Closed at failure, it costs the programme.
Which is the same argument as everywhere else. Change the work before you change the technology — and settle what the work will become before anyone signs for the technology that will speed it up.
Are the hard questions being asked before approval, or after it stalls?
Forty-five minutes with your leadership team, online, at no cost. We bring a working model of how firms in your sector make money and where AI has moved those numbers. You tell us where it is wrong. Then we tell you what we think — including “don’t invest”, if that is the honest answer.
Book a free assessment45 minutes · online · no cost · nothing to prepare
Continue reading
7 Signals That Suggest the Way You Run Is Breaking
The warning signs most leaders miss before a programme goes wrong.
For the whole board9 Reasons Transformation Programmes Fail After Approval
Why programmes underdeliver against the outcomes the board signed off.
For chief executives11 Transformation Mistakes Boards No Longer Tolerate
What boards used to accept on trust and now challenge directly.