Seven questions every board should ask before approving a core systems replacement

Programmes of this kind rarely fail at the point of approval. They fail around month eighteen, when the original sponsor has moved on, the scope has drifted, and nobody can say with confidence how much has been spent against what was promised.

These seven questions will not make a board technical. They will surface most of the risk that matters, and they can be asked by any director.

Every replacement paper explains why the new system is better. Fewer explain what actually breaks if the board declines. Is the current platform unsupported, or merely unfashionable? Is there a regulatory deadline, or a vendor sales quarter? A paper that cannot describe the cost of waiting is usually a paper driven by supply rather than need.

Name the individual, not the committee. Then ask what the programme looks like if that person resigns in month nine, because on a three year programme that is a realistic event rather than a hypothetical one. If the answer is that the programme would stall, the board has just found its largest single risk, and it is a people risk rather than a technology one.

Not the strategic narrative. The numbers. Cost saved, revenue enabled, risk reduced, expressed in figures that can be measured after go live. Then the commitment that matters: that those same figures will come back to the board annually for three years after implementation. Business cases that are never revisited are not business cases, they are permission slips.

Programme status normally reaches the board through the programme itself. That is not independence, and it is not a criticism of anyone's integrity. It is a structural problem. People reporting on their own delivery, under pressure, with careers attached, do not report bad news early. Boards that commission an independent view, reporting to the board rather than to the programme, find out about trouble while it is still cheap.

Every replacement has a boundary. Which processes stay manual. Which systems remain. Which integrations are out of scope. The most expensive surprises in a core replacement are almost never in the new system. They are in the things nobody listed as excluded, discovered at integration, and funded from a contingency that was never sized for them.

Ask for the exit. What does the contract permit. What is the cost of stopping at each phase. What happens to the data. Which decisions become irreversible, and at what point. Most boards discover the answer at the worst possible moment. A board that asks at approval, when it still has leverage with the vendor, tends to get better terms as well as better information.

If the honest answer is never, the board should sit with that. It is possible that every programme in the institution's history was worth completing. It is more likely that the board has not built the habit, or the information, that allows it to stop one. A board that cannot stop a programme is not overseeing it. It is funding it.

Notice that none of the seven require technical knowledge. They require a management team that has thought past the approval, and a board that is willing to be unpopular for twenty minutes.

The tell is not whether the answers are good. It is whether they exist. An executive who has genuinely thought about the exit, the boundary and the independent view will answer in specifics. One who has not will answer in reassurance, and reassurance at approval stage is the most expensive sound in a board room.

If your board is approving something significant this year, run these seven questions before the paper is tabled rather than during the meeting. Management will thank you for the warning, and the paper that comes back will be better than the one that would have arrived.

These seven sit inside a longer set we use in board evaluations. The Board Technology Oversight Checklist covers twenty five questions across accountability, board information, cyber, programme oversight, data and resilience, with a scoring guide. It is free and takes about fifteen minutes.