The Board’s Questions Before Approving a New Digital System

A vendor walks into a board meeting with a polished proposal: a dashboard, a demo, a promise that the new system will modernise the organisation. The board is not technical. The budget is real. The pressure to look decisive is real too.

This is exactly the moment a governance routine matters more than technical expertise. A board does not need to understand the database schema. It needs a short, repeatable set of questions that separates a system ready for approval from one that is not — and it needs the discipline to ask those questions even when a confident presentation, or a confident AI-generated business case, makes them feel unnecessary.

The questions below are grouped the way a board actually works through a decision: what changes, who owns the risk, what must exist before a signature, and what rule decides the outcome.

1. Ask what actually changes — for everyone, not just the obvious users

Before any figures are discussed, the board should be able to answer one question in a single sentence: what specific decision or service does this system improve? "Modernisation" is not an answer. Neither is "efficiency." A useful answer names a concrete outcome — the system triages credit applications, flags fraud patterns, reduces the queue at a particular branch, or gives frontline staff information they currently have to ask for by phone.

Next, ask which users will actually change how they work day to day. A system can look impressive in a demo and still leave the people who depend on it doing the same manual workaround they used before, simply routed through a new screen.

Then ask the question boards most often skip: how does this affect the people who will not use the system every day? Occasional users — a branch manager who checks a report monthly, a field officer who submits data once a week, a board member who reviews a quarterly extract — rarely appear in a vendor demo. If the system is inconvenient for them, they will build a workaround. Workarounds by people who touch a system rarely are one of the quietest ways an approved investment fails, because nobody reports the problem; they simply route around it.

2. Ask who owns the data, what happens when it fails, and how you leave

Three questions belong together because vendors rarely volunteer honest answers to any of them.

Who holds legal ownership of the data? Establish, in writing, that the organisation — not the vendor — owns the inputs, the outputs, and the right to audit them. "The vendor stores it securely" is not the same statement as "the organisation owns it and can extract it on demand."

What happens during a connection or system outage? Every proposal should include a business-continuity answer for the offline moment: the branch with no internet, the day the vendor's cloud service is unreachable, the week the mobile network is down. If the answer is silence, assume the service stops with the connection.

What is the exit strategy? Before signing, the board should know exactly how the organisation leaves this supplier if it needs to — without losing data access and without an operational lock-in that makes the "no" option unaffordable later. A system with no described exit path is a system the board is approving permanently, whether or not that word appears in the contract.

3. Require these before a single signature

Treat the following as a governance gate, not a wish list. If any one is missing, the proposal is not ready for approval — it is ready for more work.

None of these five items are technical. A board that cannot evaluate an architecture diagram can absolutely confirm whether a named owner exists, whether a budget line exists, and whether a review date is on the calendar. That is the level at which board oversight is supposed to work.

4. Approve the controlled first step, not the grand promise

This is the rule that resolves most board disagreements: never approve a full system rollout based on limited evidence. Authorise a controlled, time-bound pilot tied to a verifiable result instead — a defined group of users, a defined period, and a defined measure that will tell the board whether the promise held.

Then commit, in the same meeting, to what happens next on either outcome:

• If the pilot succeeds with real evidence, expand the rollout in the next phase.
• If the pilot fails, or produces no usable evidence, stop and fix the underlying data or process problem before spending further.

This single rule protects the board from the two most expensive failure patterns: approving a "grand promise" that was never tested, and continuing to fund a system past the point where the evidence already said stop.

A word on AI-generated business cases

Generative AI tools can draft a business case, model scenarios, and summarise a vendor's proposal faster than any team could by hand. That is useful preparation work. It is not evidence, and a board should never treat it as independent proof that a system will deliver what it promises.

An AI-assisted document still needs the same checks a human-written one needs: verified figures, a named owner willing to be accountable for the numbers, and a pilot that produced real, checkable results. If nobody on the paper trail can explain where a projection came from, the projection is not evidence — no matter how fluent the document sounds. The human recommends context; the human decides. The tool does not decide, and it does not stand in the room to answer for the outcome.

The one-page test before the meeting ends

Before closing the agenda item, the chair should be able to answer six questions out loud, without checking the slide deck:

1. What specific decision or service does this system improve, and how will we know if it worked?
2. Who are all the affected users, including the ones who touch the system rarely?
3. Who legally owns the data, and what happens to service during an outage?
4. What is our exit path if this supplier relationship needs to end?
5. Do we have a named owner, a real budget, protected training time, a support route, a risk register and a review date?
6. Are we approving a controlled first step with a measurable result, or a promise with no evidence behind it?

If the answers are clear, approve the pilot and put the review date in the diary before anyone leaves the room. If they are not, the honest board decision is not "no" — it is "not yet, until these gaps are closed."