What every board should know before approving a digital transformation budget

A board can approve a platform, website or AI budget and still leave the investment unable to succeed.

The proposal may describe a solution, supplier, timetable and impressive return. It may say little about the problem, authority, evidence or decisions required after approval. The delivery team then reports progress against outputs while nobody can show whether the organisation is moving towards a useful outcome.

The source article opened with a $2.3 trillion waste estimate and transformation-failure percentages attributed to several consultancies without durable links or comparable definitions. Those numbers are unnecessary. A board can test the governance in the proposal in front of it.

Approval begins the governance work

Board members do not need to manage technical delivery. They do need to establish what the organisation is authorising and how material uncertainty will return for decision.

An investment can underperform with competent suppliers and working technology. Common governance causes include:

• A capability described in place of a problem
• Benefits with no baseline or calculation method
• Accountability assigned to a group with no decision authority
• Internal capacity assumed rather than committed
• Risks and dependencies separated from the plan
• All useful evidence arriving near the end
• No pre-agreed condition to redirect or stop

These are visible before approval if the board asks for them.

The source includes an account of a 300-person firm approving a 300% return that had allegedly been reverse-engineered from the desired budget. It is a serious claim about a client or observed board and needs project verification and permission. The transferable lesson is to require the benefit calculation, owner, baseline and sensitivity, rather than accepting a headline ratio.

Five questions before the vote

1. Which problem changes, for whom?

“Implement a client portal” is an output. A useful problem statement identifies the affected person, current failure, consequence and evidence.

For example: brokers submit avoidable errors because the current journey cannot validate certain information, creating rework and lost placements. The example still needs a measured baseline. Its strength is that several responses can compete: portal change, process, guidance, data integration or another intervention.

Ask which evidence would disprove the diagnosis. If the chosen technology appears in the problem statement, the team may have agreed the answer too early.

2. What result will count, and what should remain protected?

Define a small set of outcomes with baselines, target ranges and dates. Include client, operational, financial and risk effects in proportion to the programme.

A login target alone can encourage forced adoption while clients struggle. A faster process can increase error or exclusion. State guardrails such as accessibility, service quality, security, staff workload and complaint outcomes.

Be careful with attribution. If technology, training and process change arrive together, the benefit belongs to the combined intervention unless evidence separates them.

3. Who owns the outcome and has authority?

Name one accountable executive for the outcome and the leaders responsible for work beneath it. State which decisions they can make, which need committee or board approval and how conflicts will be resolved.

A steering committee can provide oversight, expertise and challenge. It cannot replace personal accountability. Conversely, a named owner without budget, people or authority is accountability in name only.

Ask which internal specialists have committed time. Delivery slows when the plan assumes immediate access to partners, editors, security, legal, data and operations while none has capacity assigned.

4. What happens if the organisation waits?

Compare action with a credible defer or do-minimum case. Include continuing support, manual work, incidents, lost opportunity and the option value of waiting.

The answer may show that delay is tolerable. That is useful. Avoid inventing a dramatic “cost of doing nothing” from unobserved conversions or broad industry percentages.

Also ask what happens if the proposed investment proceeds and fails to change the outcome. The downside includes sunk cost, distraction, migration exposure and lost confidence, rather than budget alone.

5. How is commitment phased?

Break the programme at points where new evidence can alter the decision. A first phase might validate user need, content complexity, technical feasibility, data or a service pattern. Later funding should depend on what that phase learns.

Every stage needs:

• A decision owner and date
• Evidence required
• Threshold or judgement criteria
• Updated cost, benefit and risk range
• Proceed, change, pause and stop options
• Consequence of each decision

Phasing should avoid creating disposable work solely to make an initial number look smaller. Each stage must either create usable value or remove consequential uncertainty.

Distinction's WHNN® framework structures What and How for Now and Next. The five questions can stand on their own; a framework is useful only when it changes the quality and cadence of decisions.

Read the assumptions behind return

An ROI figure should have a model a finance director can inspect.

Require:

• Benefit categories and calculation
• Current baseline and source
• Adoption and timing assumptions
• Internal and continuing costs
• Dependencies on other programmes
• Low, central and high cases
• Owner of benefit realisation
• Plan for measurement after launch

Avoid counting the same benefit twice. Time saved is not cash unless capacity is removed, redeployed or used to create measured value. Increased enquiries are not revenue until suitable demand progresses. Risk reduction requires a defined exposure and intervention mechanism.

The board does not need certainty. It needs to see which assumptions drive the answer and which phase will test them.

Treat red flags as prompts for evidence

Several proposal patterns deserve challenge:

Outputs presented as outcomes. A launched portal proves delivery of software, rather than client or commercial value.

Return with no method. Decorative precision can conceal the weakest part of the case.

A supplier selected before the need is defined. This can narrow discovery and bias requirements around a product.

Value deferred to the final launch. The organisation receives little evidence while most budget becomes committed.

A risk register detached from decisions. Risks need owners, mitigations and triggers that affect scope or release.

Governance with meetings and no authority map. Cadence alone does not resolve disagreement.

These signals do not automatically make a proposal bad. They tell the board what to ask next.

Stage gates need the power to say no

A stage gate becomes theatre if everyone expects approval. Agree the evidence and criteria before the phase begins. Give decision-makers time to examine it. Preserve a real route to redirect or stop, including contractual and technical exit.

Evidence can include task research, prototype performance, data readiness, assurance, content sample, delivery forecast and user adoption. The source quoted a portal-adoption percentage from Kitces without explaining its application. A programme should set its own adoption and outcome expectations based on affected users and voluntary or mandatory use.

Low adoption is a question, rather than an automatic failure. It may reveal poor value, weak communication, inaccessible design, incorrect audience or a sound user preference for another channel.

Good governance supports delivery

Clear outcomes and escalation help teams make decisions. Guardrails reduce late surprises. Stage gates protect the organisation from continuing for the sake of sunk cost and protect suppliers from being held to benefits nobody defined.

The source ends with a dramatic case in which a £400,000 programme allegedly became an £80,000 fix and improved conversion by 22%. The same case appears elsewhere in the collection with variations. Hold it until the engagement record, analytics, attribution, quotation and client permission are verified.

Before the next vote, ask for the problem, outcome, owner, alternative and next evidence gate. Approving the budget is one decision in a sequence. The board's most valuable contribution is making the rest of that sequence governable.

If you want the five questions and the stage-gate framework as a one-page checklist you can bring to your next board or investment committee meeting, download it here. It's designed to be shared with your finance director, NEDs, or anyone else who'll be in the room when the next digital investment lands on the agenda.