THE BRIEFING ROOM

Five questions every board member should ask before approving a digital budget

I've watched this play out more times than I can count. A managing partner or digital director walks into a board meeting with a proposal for a new platform, a website rebuild, or some kind of digital transformation initiative. The proposal is well-intentioned. It might even be the right thing to do. But within twenty minutes, the conversation has drifted into a fog of vague questions, vaguer answers, and a general sense that nobody in the room is entirely sure what they're actually being asked to approve.

The board defers. "Come back with more detail." The proposer leaves frustrated. The board feels responsible. And the project sits in limbo for another quarter - or longer.

I've been on both sides of this conversation. I've been the one presenting, and I've been the one advising people who are about to present. And what I've noticed is that the problem isn't usually the quality of the proposal. It's the quality of the questions being asked about it.

Most board members I've worked with are smart, experienced people who've been approving investments for decades. But digital is different enough from, say, office fit-outs or lateral hires that the usual instincts don't always map cleanly. Board members either don't ask the hard questions - because they don't want to look like they don't understand technology - or they ask something broad like "what's the ROI?" which is almost impossible to answer well in the moment.

The board doesn't need a script. They've been approving investments for years.

I understand that instinct. And yes, your board has plenty of commercial judgement. But the evidence suggests otherwise when it comes to digital specifically. McKinsey's research has consistently shown that large-scale technology projects run 45% over budget and deliver 56% less value than predicted. That's not a failure of ambition. It's a failure of scrutiny at the approval stage.

What follows are five questions. They're not complicated. They're not technical. Any board member can ask them, and any proposer should be able to answer them. If a proposal can answer all five clearly, it's probably worth approving. If it can't, it's not ready yet - which is useful information for everyone.

What I like about these questions is that they work from both directions. If you're the one presenting to the board, prepare your proposal against them and you'll have answered the objections before they're raised. If you're the one reviewing the proposal, apply them and you'll cut through the waffle in minutes.

Question 1: What specific problem does this solve?

Not "what will it build?" What problem does it solve?

This is the most common failure mode I see in digital proposals. They describe a capability. "We will build a new client portal." "We will migrate to a modern CMS." "We will implement an AI-powered document management system." All perfectly reasonable things to build. But none of them are reasons to spend money.

The reason to spend money is the problem. "Clients are waiting an average of four days to receive documents that should be available on demand." "Our marketing team files 30 IT tickets a month for content changes that should take five minutes." "We're losing two out of every five broker applications to errors caused by a portal that hasn't been updated since 2018."

A board that approves a capability without understanding the specific problem it solves has no reference point for whether the investment succeeded. You've given them nothing to measure against. And the proposer who can't answer this question in one sentence - genuinely, one sentence - hasn't yet earned a board conversation. That's not me being harsh. That's me saving you from a deferral.

I sat with a COO last year who'd been quoted over £400,000 for a full website and CRM rebuild. When I asked what problem it was solving, there was a long pause. The honest answer turned out to be that about 60% of the original brief was unnecessary. The real problem was a broken enquiry-to-onboarding handoff that could be fixed for a fraction of the cost. The question isn't difficult. But it is ruthlessly clarifying.

Question 2: How will we know it's working?

Specific metrics. Not "improved digital presence."

The approval of a digital investment that has no agreed success criteria is not a decision. It's a deferral dressed up as progress. Everyone leaves the room feeling like something happened, but nobody has committed to a measurable outcome. And when the project completes twelve months later, the conversation about whether it worked becomes entirely subjective. "It feels better." "The team likes it." "We've had some positive feedback."

That's not accountability. That's vibes.

The board member who asks for three specific, measurable outcomes before approving isn't adding governance overhead. They're creating the structure that turns a projection into a commitment. "A 25% increase in enquiry conversion rate within 12 months of launch." "Reduction in content publishing time from two weeks to same-day." "Portal login failures reduced by 40% within six weeks." These are things you can actually track. Things you can report back on at the next board meeting without anyone having to squint.

And here's the thing - defining these metrics isn't just good governance. It actually makes the project better. When the delivery team knows what success looks like in specific terms, they make different decisions about scope, priorities, and trade-offs. I've seen this play out dozens of times. The projects with clear success criteria at the outset are the ones that deliver. The ones without them are the ones that drift.

I'll be honest - I've been guilty of this myself. Early in Distinction's history, we delivered a project we were genuinely proud of, technically. The client was happy enough. But because we'd never agreed what "working" looked like, there was no moment where anyone could say it had succeeded. The relationship fizzled. We'd done good work with no way to prove it. That stings more than a bad project.

Question 3: What happens if we don't do this?

The standard board question is "what does this cost?" The better question is "what are we actually choosing between?"

Every digital investment proposal I've ever seen includes a cost. Very few include the cost of not doing it. And that asymmetry distorts the decision. The board sees a number - say, £250,000 - and their instinct is to protect cash. Sensible instinct. But they're comparing that £250,000 against an implicit zero, as if the alternative to investing is free.

It never is.

The alternative to investing is continuing to pay the maintenance costs on an ageing platform. Continuing to lose the enquiries that bounce off a website that hasn't been touched in five years. Continuing to carry the security risk of an unsupported CMS - the average cost of a data breach now sits at $4.45 million, according to IBM, and that figure doesn't get smaller when you explain to your insurer that you knew the platform was past end-of-life. Continuing to fall behind competitors who've already moved. The cost of inaction compounds daily. We've written about this at length in our guide on the fragility of digital foundations - 60-80% of IT budgets are spent just maintaining legacy platforms. That's not investment. That's treading water.

A proposal that includes an honest estimate of the cost of deferral - in maintenance, lost revenue, competitive position, and risk exposure - gives the board the comparison they need to make a rational decision rather than a cost-avoidance one. If you're preparing a proposal, do this work. If you're reviewing one and this section is missing, send it back.

Question 4: Who owns the outcome?

A name. Not a committee.

A digital investment without a named accountable owner is a digital investment with no accountability. Full stop.

The board member who asks "who is personally responsible for whether this delivers against the criteria we just agreed?" and receives the answer "the digital steering committee" has identified a governance failure before a single pound has been spent. Committees don't own outcomes. Individuals do. The right answer is a single name - someone with explicit authority to make the decisions required for delivery, and explicit accountability for whether it works.

This isn't about blame. It's about clarity. When something inevitably goes sideways mid-project - and something always does - you need someone who can make a call without convening a meeting. Someone who can say "we're descoping that feature to protect the launch date" or "we're bringing in additional resource for the integration work" without waiting for consensus from eight people with competing priorities.

I had a conversation with a partner at a consulting firm a few months back who told me their last digital project had a steering committee of eleven people. Eleven. I asked who was accountable for the outcome. He laughed. Not in a good way. That project ran fourteen months over schedule.

Question 5: What's Phase 1 and what does it cost?

Not the full programme cost. Phase 1.

A board that's asked to approve a two-year, £500,000 digital transformation programme based on a projection is being asked to trust a plan in deeply uncertain territory. Markets shift. Requirements change. The thing you thought mattered in month one turns out to be less important than something you discover in month four. A two-year projection is a guess wearing a suit.

A board that's asked to approve a 90-day Phase 1 with specific deliverables, specific success criteria, and a gate review before any further commitment is being asked to trust a much smaller, much more visible plan. That's a fundamentally different risk profile.

The proposer who cannot describe Phase 1 specifically - what it delivers, what it costs, how you'll know it worked, and what triggers the decision to proceed to Phase 2 - has not yet done the planning that earns board approval. We use this approach with almost every engagement at Distinction. Our WHNN framework runs on a quarterly rhythm precisely because it breaks large initiatives into reviewable phases. Not because we're being cautious. Because certainty decreases the further out you plan, and your approval process should reflect that honestly.

These aren't the only questions

Context matters. Your industry's regulatory environment, your firm's risk appetite, the specific technology involved - all of these might generate additional questions that are entirely appropriate. A financial services firm will have compliance considerations that a consulting firm won't. A firm that's been burned by a failed project will - rightly - want more detail on delivery methodology.

But these five are the ones I've seen make the biggest difference, consistently, across sectors and firm sizes. They're the questions that, when asked, turn a vague proposal into a clear decision. And when answered well, they give the board genuine confidence rather than the polite fiction of consensus.

If you're walking into the boardroom next month with a digital investment proposal, stress-test it against all five before you go. If you can answer each one crisply, you're ready. If you can't, you've got work to do - and better to discover that now than in front of the people holding the chequebook.

And if you're on the other side of the table - reviewing the proposal, deciding whether to approve - these five questions will tell you within ten minutes whether what you're looking at deserves a yes, or needs another pass.

We've put together a formatted checklist version of these questions - designed for board members reviewing proposals and for proposers preparing them - which you can download here. It includes a simple scoring guide so you can assess whether a proposal fully answers each question, partially answers it, or doesn't yet address it. Between that and the companion piece on how to present a digital investment to a sceptical board, you'll be well-armed for whatever's coming up at your next board meeting.