What a technology roadmap owes the board

Most technology roadmaps presented to boards are lists. Twelve initiatives, colour-coded by quarter, each with a confident label and a budget line. Directors nod, ask one question about cyber security, and approve. Eighteen months later, four initiatives are finished, three are "in progress", and nobody can say whether the business is better off.

A roadmap is not a list of things technology would like to do. It is an argument for how the business will change, and a board is entitled to test that argument. In our experience, a roadmap earns its place on the agenda only if it answers three questions clearly.

1. What stops?

Every organisation has a finite amount of change it can absorb. New systems need training, migration, testing and attention from the same small group of people who run the current ones. A roadmap that only adds work is a roadmap that will quietly fail.

So the first page should list what the business will stop doing, stop paying for or stop maintaining as a result. Systems to be retired, with dates. Manual processes to be removed. Contracts that will not be renewed. If nothing stops, the plan is either underestimated or unaffordable.

2. What starts, and how will we know?

For each initiative, the board should see the outcome it is meant to change, the measure of that outcome today, and the level it is expected to reach. "Implement a new CRM" is not an outcome. "Reduce the time from enquiry to quote from nine days to three" is.

This does two things. It lets the board prioritise between initiatives on value rather than enthusiasm. And it makes it possible, a year later, to tell which initiatives worked. A roadmap without measures cannot be reviewed; it can only be re-presented.

3. What does it cost to be wrong?

Every plan rests on assumptions: that a vendor will deliver, that staff will adopt the new process, that the data is cleaner than it looks. The board's job is not to eliminate that risk but to understand where it sits and how expensive it would be.

For each major initiative, the roadmap should say what the first checkpoint is, what will be known by then, and how much will have been spent. Good plans are structured so that the expensive commitments come after the uncertain questions have been answered. A three-year programme with its first real test in year two is a gamble presented as a plan.

What the board should ask for

• A single page showing what starts, what stops and what it is all for.
• A measure for every initiative, with today's value.
• A checkpoint in the first ninety days for anything over a set budget.
• The decision rights: who can stop an initiative that is not working, and on what evidence.

None of this requires technical expertise from directors. It requires the same discipline they would apply to any other capital decision. Technology is not special; it is just often presented as if it were.