10 Questions Boards Should Be Asking Before Approving the Next Transformation
Most transformation programmes that underdeliver were approved without the architectural answers the programme would later need. The questions below surface those answers at the approval gate.
- Most mid-market transformation programmes that underdeliver did so because the board approved cases that did not contain the architectural answers the programme would later need.
- The ten questions below surface those architectural answers at the approval gate — when they are still cheap to address. Each question maps to a specific post-approval failure mode.
- The board-defensible position is not “we approved a credible case.” It is “we required architectural specification proportional to the investment, before approving the case.” Most mid-market boards have not yet adopted this discipline.
The transformation paper goes to the board. The executive sponsor presents. The case is well-documented. The risks are listed. The benefits are quantified. The board reviews, discusses, and approves. The programme begins.
Twelve months later, the programme is six months behind plan. Eighteen months later, the benefits realisation is partial. Twenty-four months later, the board is reviewing a remediation paper that re-architects what should have been architected at approval.
This pattern is now well-documented across UK mid-market transformation programmes. The board approved a case that did not contain the architectural answers the programme would later need. The approval was based on commercial intent, executive conviction, and benefits modelling — not on architectural specification. The architectural questions surfaced later, in delivery, when fixing them was materially more expensive.
The questions below are designed to be asked at the approval stage, not the remediation stage. Each one is unbluffable. Each one surfaces a specific architectural decision that, if deferred, will produce a specific failure mode. The discipline is to ask them before approval — even when the case looks ready, even when refusing creates short-term tension. The cost of asking late is materially higher than the cost of asking early.
What is the future operating model — described in equivalent specificity to the technology architecture?
Open the board paper. Find the section describing the technology stack. Note the level of detail: platforms named, integration patterns documented, data flows specified, vendor selections justified. The technology architecture is articulated.
Now find the section describing the future operating model. Compare the level of detail. In most mid-market transformation papers, the operating-model section is at vision level — strategic intent, target state principles, capability descriptions. It is not specified at the same standard as the technology architecture.
This asymmetry is the most consistent predictor of post-approval drift. The technology will be built to specification because the specification exists. The operating model will be built to whatever level of specification surfaces in delivery — which is materially less than the technology side. The architectural test is symmetry. If the technology architecture is paragraph-by-paragraph specific and the operating-model architecture is bullet-point principles, the programme is technology-led regardless of language.
Who is the named executive author of the future operating model — not the technology delivery?
The transformation programme has an executive sponsor. The technology delivery has a programme owner. The architecture has an architectural lead. Each of these roles is named in the paper.
What is rarely named is the executive owner of the future operating model itself. The CRO who has authored the future commercial model. The COO who has authored the future operational model. The CCO who has authored the future customer experience model. The CFO who has authored the future financial model. Each functional executive’s signature on the part of the operating model their team will operate.
When the answer is “the CIO” or “the transformation programme team”, the operating model has been designed by a delivery function for a target customer — the functional executives — who have not authored it. The architectural test is authorship, not consultation. Functional executives who will operate the model have to have authored it. Most mid-market transformation papers do not name this.
What specific commercial KPI does each benefit line move?
The benefits case is in the paper. The numbers are credible. The sponsor can defend the assumptions. The cumulative benefit value justifies the investment.
The question to ask is — for each benefit line, what commercial KPI does it move, and what is the operational mechanism that produces the movement? If the answer is “improved efficiency” without a named KPI, the benefit is capability-aspirational rather than operationally specified. If the answer names a KPI but cannot describe the operational mechanism that moves it, the benefit is asserted rather than architected.
The architectural test is mechanism. Every benefit line names — the commercial KPI it moves, the operational mechanism that produces the movement, the owner of that mechanism, and the measurement protocol. Most mid-market transformation business cases do not pass this test cleanly.
The questions a board asks before approval are the cheapest version of the questions an enquiry asks after failure.
Who owns each benefit line at executive level, and what is their accountability mechanism?
The benefits case attributes value. The question is who is attributable for delivery.
In most papers, the executive sponsor is named as overall benefits owner. This is governance, not accountability. The named individual cannot personally cause each benefit to materialise — they depend on functional teams whose work happens outside the transformation programme’s authority.
The architectural test is named accountability with mechanism. Each benefit line has a named functional executive (not the transformation sponsor), a documented commitment from that executive, and a measurement protocol that tracks the executive’s accountability — not just the programme’s delivery. If the benefits case has no individual functional executive accountable for each specific benefit, the case will deliver capability but not benefit.
What evidence supports the change-management investment estimate?
Find the change-management line in the budget. Note its size relative to technology and consulting investment. In most mid-market transformation cases, change-management investment is 5–15% of total programme cost.
In delivered programmes that materially achieved their benefits, change-management investment is typically 25–40% of total programme cost. The under-pricing of change-management investment is one of the most consistent failure patterns in mid-market transformation.
The architectural test is scaling logic. The change-management investment has been priced at the scale of the affected population — not at pilot or workstream scale. The investment includes operating-model change activation, KPI realignment, capability development, executive coaching, and resistance management — not just training and communications. Most mid-market transformation papers underprice this line by half or more.
Recognising the pre-approval gaps is the first step. Naming which of the ten questions your current case would struggle with is the next.
The free Commercial Readiness Assessment positions your organisation across six dimensions of commercial architecture, including transformation governance. About ten minutes. No payment. No sales call.
Take the Free Assessment →What is the contingency plan if the programme is six months delayed or 25% over budget?
Most transformation papers include a risk register and mitigation plans. The question is sharper — what specifically happens if the programme reaches month eighteen with material schedule or budget variance?
The answer should not be “we will manage it.” The answer should be specific — which workstreams continue, which pause, which are cancelled, what triggers a return-to-board paper, what governance discipline applies during the variance period. If the paper does not contain this contingency specification, the board is approving without a defined response architecture for the most common failure modes.
The architectural test is contingency design. The variance scenarios are pre-defined. The decision rights for each scenario are pre-assigned. The board’s role at each scenario is documented. Approval is conditional on this architecture being present.
Redesign during executive review and resubmission. Cost is largely design effort and rework of the paper.
Redesign during scoping and vendor engagement. Cost includes contract renegotiation and team reassembly.
Redesign during delivery, with vendor renegotiation, team disruption, executive credibility loss, and benefits slippage.
Programme written off. Value recovered partially or not at all. Reputational, operational and financial cost compounds.
Same compounding-cost principle observed across architectural programmes. The cost of asking the right question before approval is materially lower than the cost of discovering the answer was missing later.
Which functional executives have signed off — in writing — on operating-model changes their teams will operate?
The transformation paper claims operating-model change. The functional executives have been consulted. Workshops have been run. Steering committees have met. The paper reflects their input.
The unbluffable test is documented sign-off. Each functional executive has signed, in writing, a specific commitment to — the operating-model changes their teams will adopt, the timeline, the KPI changes, the headcount or capability changes, the accountability for delivery. Not “approved the strategy” — committed to operate the future model.
If this documentation does not exist, the consultation was opinion-gathering rather than commitment-securing. The transformation will proceed and the functional teams will discover, in delivery, that they are being asked to operate a model they did not formally commit to. Resistance follows. Programme delays follow. The architectural test is signature. If the executive signatures don’t exist, the case isn’t ready for board approval.
Three things to do before the next transformation paper goes to the board
- For each of the ten questions above, identify which would be uncomfortable to answer in detail today. Those are the questions to answer architecturally before the board paper is drafted — not the questions to defer.
- Identify which functional executives have signed off in writing on operating-model changes their teams will operate. If any have not, the case is not yet ready for approval. Postpone.
- Identify the explicit sequencing of architectural decisions versus vendor commitments. If vendor commitments have already constrained operating-model design choices, the case has architectural debt the board needs to see — not hidden in a technical appendix.
What architectural decisions have already been made by vendor or SI selection that constrain operating-model design downstream?
The paper often comes after vendor selection. The platform is chosen. The systems integrator is engaged. The implementation methodology is set. The technology architecture is largely defined.
The question to ask is — which operating-model decisions have already been constrained by these technology selections, and which decisions remain genuinely open? In well-architected programmes, the technology decisions follow operating-model design, not the reverse. If technology decisions were made first, the operating-model design space has been narrowed — sometimes invisibly.
The architectural test is sequencing transparency. The paper documents which architectural decisions were made when, in what sequence, and which downstream choices are now constrained. If the paper presents the technology as the platform that will support the operating model — when in fact the operating-model design is being shaped by the technology — the sequencing has been violated. This is the technology-led transformation pattern hiding behind architecture-led language.
What is the post-programme governance architecture for the new operating model?
The transformation programme is funded for a defined duration. It will end. The question is — who owns the operating model after the programme ends?
In most mid-market transformation papers, this is the least developed section. The programme will deliver the operating-model change. The line organisation will then operate it. But the architecture of ongoing operating-model custodianship — the role that monitors operating-model performance, identifies architectural drift, commissions remediation, governs evolution — is rarely specified.
The cost of this gap is that the operating model degrades after programme completion. Functional teams drift from the designed model. Decision rights erode. The new architecture is treated as the programme’s output, not as an ongoing organisational capability. Six months after programme completion, the operating model in operation differs materially from the model designed. The architectural test is custodianship — who owns the operating model in its operational life, and what is the architecture of that ownership.
What is the cost of not proceeding — and the cost of proceeding with this design specifically versus a redesigned version?
Most transformation papers present a binary decision — approve as proposed, or do not proceed. The board’s decision is framed as go/no-go.
The architectural decision is materially richer. Approve as proposed. Approve with conditions. Defer for architectural redesign. Decline. Each path has different economics, different risks, different probability of success. The paper should present each option with its economic case — not just the recommended option.
The unbluffable test is decision rigor. If the paper presents only one go option and frames the alternative as “do nothing”, the board is being asked to approve at the wrong decision frame. The right decision frame is “what is the best architectural version of this transformation?” — which usually surfaces a redesigned version that is materially better than the proposed one.
What this means for the board approval gate
These ten questions describe what board scrutiny looks like when it is designed to surface architectural gaps at approval — not at remediation. None of the questions are exotic. All of them are present in well-governed programmes. What is rare in mid-market is the discipline to ask them consistently, with the willingness to defer approval when the answers are not yet ready.
The pattern across mid-market transformation failures is consistent. The board approved a case that did not contain the architectural answers the programme later needed. The answers were discovered in delivery. The cost of discovering them in delivery was materially higher than the cost of requiring them at approval. The board, in retrospect, would have benefited from harder questions earlier — but the dynamic at approval often favours forward motion over architectural rigor.
The economic argument for stronger pre-approval questioning is straightforward. Each architectural gap closed before approval is closed at design cost. Each gap closed during delivery is closed at delivery cost — typically five to twenty-five times higher. Each gap discovered at programme failure is paid at programme cost — often a hundred times the design cost.
This is where commercial-first architecture pays back at the boardroom specifically. The board’s discipline is the cheapest version of the architectural quality the programme will eventually require. The starting point is asking the questions before approval — not after delivery.
Are the right questions being asked before transformation approval — or only after it stalls?
The free Commercial Readiness Assessment positions your organisation across six dimensions of commercial architecture, including transformation governance discipline. You receive a personalised report naming where your governance architecture is most defined, where it is most exposed, and which of the ten questions above are most likely to expose gaps in your current transformation case.
Take the Free Assessment →About 10 minutes · No payment · No contract · No sales call