Running the Roadmap in Practice

The first lesson set out the baseline, sequencing, gaps and phasing. This lesson covers how a roadmap is kept honest in practice: how you decide when to stop, who can commit money, how to choose between building, buying and configuring, how to say no, and how to tell people what you know and do not know.

Write the stop criteria before you start

Every phase needs conditions under which it pauses or ends, written in advance and agreed by the sponsor. Examples include an error that would harm a person, a complaint pattern, a data problem, a cost above the agreed ceiling, or review capacity that falls behind the volume. Once money is spent and enthusiasm is public, stopping on a judgment call is much harder. A pause criterion is what makes it safe to try. Name who may trigger a pause, and make clear that using it carries no blame.

Dependencies, funding and authority

Initiatives rarely stand alone. A customer-service assistant may depend on a cleaned knowledge base, which depends on a content owner being appointed, which depends on a team that is already committed elsewhere. Draw these links and sequence accordingly, or one late item stalls others and nobody can say why. Also be clear about money and authority. Someone can recommend an initiative, and someone different holds the authority to commit the funds. A roadmap that implies approval it does not have creates false expectations, so mark each item as proposed, funded for a test, or funded for rollout, and name the person who can change that status. If a team starts spending on an initiative before the commit decision, record that and route it to the authorised owner rather than letting it stand by default.

Build, buy or configure is a leadership decision

The technical staff can advise, but the decision turns on questions that are not technical: how distinctive is this work to us, what happens to our data, how long will we depend on the supplier, who will maintain it, and who is accountable if it fails. Configuring something you own is often the fastest and least risky step. Buying brings speed and dependence on a supplier. Building brings control and a long maintenance burden. Whichever route is chosen, responsibility for the outcome stays with your organisation.

Keep the roadmap alive, and be willing to say no

A roadmap is a living document. It should carry review triggers, such as a stage gate result, a major vendor change, a regulatory date, an incident, a change of strategy or a budget cycle, as well as a regular review date. Saying no is part of the discipline. When a use case is declined, record what was proposed, who proposed it, the reasons and what would need to change for it to be reconsidered. An unrecorded no resurfaces as a fresh request or as unsanctioned use.

Dates that shape the order

Some sequencing is set by external dates, and the plan should use them accurately. Under the EU AI Act, the transparency duties in Article 50 have applied from 2 August 2026, and they were not deferred. A marking grace period for systems already on the market before that date ends on 2 December 2026. Regulation (EU) 2026/1744, the Digital Omnibus, defers the standalone high-risk categories listed in Annex III to 2 December 2027. That gives time but not permission to drift: a use case that could fall into Annex III needs earlier groundwork on data, oversight and documentation. The duty on AI literacy in Article 4 is an obligation of means rather than result, and it applies to AI systems generally, so a plan that adds tools without developing staff understanding has a gap whatever the risk class. Whether a specific use case falls within these provisions is a question for qualified advice.

As of 24 September 2026.

Communicate honestly, and settle conflicts openly

Tell staff and sponsors what is decided, what is being tested and what is uncertain, including what the evidence so far does not show. Resource conflicts between teams are normal: two teams want the same data engineer or reviewer. Surface the conflict, set out the options and costs, and ask the sponsor or the authorised owner for a specific decision, recording the outcome.

A worked example and the common failures

Marlow Building Society, an invented organisation, ran a test of an assistant that drafts replies to member queries. The stop criteria were set in advance: a pause if a drafted reply stated a wrong fee or rate and the error reached a member, or if the checking team fell behind. In week five a wrong fee appeared in a draft that a tired checker nearly passed. The team lead paused the test under the criteria, without blame, and the sponsor was asked whether to extend the checking team before resuming. The decision was recorded and the roadmap updated.

Common failures: plans follow the tool rather than the strategy. The baseline omits vendor updates and personal accounts. Phases are skipped because a pilot looked good. Stop criteria are written after trouble starts. Dependencies are invisible, so one slip becomes four. Authority is assumed, not checked. Nos are not recorded. And the roadmap is presented as certain, so that the first change looks like failure rather than governance.