AI programme management
AI roadmap prioritisation: choose what to build first
Prioritise an AI roadmap around evidence, dependencies and measurable value. Use a practical decision sheet to choose the next project with confidence.
Your AI roadmap has twelve promising ideas, three available people and one quarter to show progress. A scoring workshop can put the ideas in order. It cannot make missing data appear, give a business owner time to review outputs or turn a demo into an operational service. AI roadmap prioritisation starts by separating attractive projects from projects you can responsibly deliver.
The useful question is concrete: which next investment will resolve an important business problem, with evidence strong enough to justify its cost and dependencies understood well enough to make a credible commitment? This guide gives you a decision sheet, a worked hypothetical example and a review method for answering it. For the wider operating model, start with the AI programme management guide.
Start with a task someone already has to complete
Write each proposal as a change to an existing task. “Introduce an AI assistant” names a product category. “Help account managers locate the current contractual service definition before answering a customer” names work you can observe. The second formulation gives you a user, an input, an output and a point at which the output could cause harm.
Observe the current task before estimating value. Include waiting time, search time, correction time and the work performed by colleagues downstream. An assistant that writes a reply quickly may transfer the effort to the person checking it. If you measure only generation time, your roadmap rewards a local improvement while missing the total workload.
Google's People + AI guide on user needs asks whether AI adds value. Use that question before choosing a model. A better document structure, an ordinary search filter or a clearer approval rule may solve the task with less ongoing maintenance.
Set a baseline using work you are authorised to inspect. Keep task types separate: a straightforward status request and a disputed contractual interpretation should not become one average. Record what the baseline cannot tell you, particularly where rare but consequential errors are absent from your observation period.
For marketing applications, the AI marketing guide helps define the content or campaign task before it becomes a programme proposal.
Separate eligibility from ranking
A project should first pass a small set of eligibility checks. Does it have an accountable operational owner? Can the team access appropriate inputs? Is the intended use permitted by internal policies? Can someone assess the output? Is there a workable fallback? These checks decide whether the proposal is ready to compete for delivery capacity.
Passing a gate does not mean a project is safe in every setting. It means the unresolved questions have owners and a credible route to resolution. If access approval is missing, put the proposal in a discovery lane with that dependency visible. Do not quietly award it a low feasibility score and then treat it as a delivery commitment.
This distinction protects the conversation from false precision. A score of 7.4 can conceal a fundamental uncertainty about who will run the service. An explicit “owner not assigned” makes the decision harder to misunderstand. The NIST AI RMF core treats context, measurement and governance as continuing activities. The roadmap worksheet below is an editorial application, rather than a NIST certification or compliance checklist.
For projects that qualify, compare business relevance, strength of evidence, delivery effort, operating effort, reversibility and dependencies. Discuss ranges rather than making a spreadsheet manufacture certainty. If two projects change places whenever you adjust an assumption slightly, the responsible conclusion is that the ranking remains uncertain.
Use a decision sheet that exposes the unknowns
Keep the sheet short enough to use in a portfolio review and detailed enough to support a real decision. Link to evidence rather than copying a long presentation into every cell. A useful record looks like this:
Swipe or use the arrow keys to see every column.
| Field | What to write | What makes it reviewable |
|---|---|---|
| Task and reader | Who does what, in which workflow | A concrete beginning and end |
| Baseline | Time, quality or service level today | Source, period and limitations |
| Expected change | A measurable outcome with a range | Assumptions shown separately |
| Readiness | Data, owner, evaluation and fallback | Missing items have named owners |
| Dependencies | Access, integration, procurement, training | Earliest credible resolution date |
| Evidence investment | The next test that could change the decision | A cost ceiling and stopping rule |
| Operating burden | Review, maintenance, incident response | Capacity identified after release |
| Decision | Discover, deliver, defer or stop | Reason and next review trigger |
The evidence investment is particularly useful. A proposal may deserve a limited study even when it does not deserve production funding. For example, test whether approved source documents cover real customer questions before building a chat interface. Failure here changes the project, rather than merely making its demonstration less polished.
Avoid turning the decision categories into permanent labels. A deferred project can become attractive when a dependency clears. A project in delivery can return to discovery when evaluation reveals a problem. Document the reason so a status change reflects new evidence, not the influence of whoever last attended the meeting.
Worked example: three projects competing for one team
Consider a hypothetical business-services company. The projects and decisions in this example are illustrative, with no claimed client results. It is considering meeting summaries, a customer-answer assistant and automated proposal drafting. All three appear to save writing time.
Meeting summaries have an accessible input and a willing team owner. The team can assess missing decisions, inaccurate attributions and time spent correcting the output. However, confidential meetings need a separate policy decision. The first commitment therefore covers a narrowly defined meeting type, rather than every conversation in the company.
The answer assistant could address a more expensive problem, but its source documents disagree about current service terms. Ranking it first on expected value would hide the dependency. The next investment becomes source reconciliation and a coverage test. A usable result would be a governed document set, even if no assistant is released that quarter.
Proposal drafting has the most compelling demonstration. It also depends on sales judgement, current pricing permissions and approved customer references. The team cannot yet define which statements the tool may make. It is deferred until the approved-claims boundary and reviewer capacity are established.
The resulting roadmap includes a small delivery project, an enabling data project and an explicitly deferred proposal. This can look less exciting than announcing three assistants. It gives the sponsor a more useful promise: each allocation has a reason, a way to test that reason and a person responsible for the result.
Make dependencies visible across projects
Shared foundations deserve their own roadmap entries. Access controls, document ownership, evaluation sets and integration work consume capacity and can unlock several later projects. They cannot be treated as administrative overhead squeezed between use cases.
Create a simple dependency map. An arrow should mean “cannot responsibly proceed until”, rather than “might benefit from”. Too many soft arrows produce a diagram that cannot guide scheduling. For each hard dependency, record the deliverable, the owner and the evidence that would show completion. “Data ready” is too vague; “current approved service documents available through the agreed access boundary” is actionable.
Keep dependency value separate from immediate user value. A source catalogue might show little short-term adoption yet remove a major delivery risk. Judge it against the decision it enables. The AI project risk register helps connect those dependencies to concrete failure scenarios.
Also inspect resource dependencies. Two use cases may not share software but may rely on the same legal reviewer, data steward or operational team. A portfolio plan that ignores those people will overcommit even when engineering estimates look reasonable.
Measure progress by decisions and operational outcomes
Use different measures for discovery and delivery. In discovery, track whether the team answered the uncertainty that justified the work: source coverage, usable quality, reviewer effort or user demand. Do not reward discovery teams for producing more demos if none changes a funding decision.
For delivery, compare the complete task with its baseline. Record output quality, total handling effort, completion rate and relevant incidents. Segment by task type and operating conditions. Monitor adoption as a diagnostic measure: low usage may reflect poor fit, lack of access or an inconvenient workflow. Usage alone does not establish business value.
Predefine the comparison period and who will interpret it. If possible, compare comparable work through a controlled rollout. When randomisation is unsuitable, describe the limitations of the observational comparison and check for changes in case mix, staffing or seasonality. A before-and-after chart is useful evidence, but it cannot isolate an AI effect by itself.
Use the guide to evaluating AI output to define quality checks and the production KPI guide to connect them with operational monitoring. Keep benefits provisional until quality and workload are assessed together.
Review the roadmap when assumptions change
A recurring review should answer four questions: what changed, which assumption did it affect, what decision follows and who acts next? Keep the previous decision visible. Otherwise a revised roadmap can erase the evidence that an earlier commitment was based on a different situation.
Watch for familiar failure modes. Optimistic effort estimates omit maintenance. Popularity scores favour highly visible teams. A model upgrade changes output behaviour after an evaluation. Benefits double-count time saved across overlapping projects. A sponsor refuses to stop an initiative because its first presentation was persuasive.
None of these problems disappears through a more elaborate scoring formula. Address them through ownership, evidence and reversible commitments. Limit work in progress to the capacity available for delivery and review. Keep a place for important proposals whose evidence is still weak, but name the investigation they need before committing.
Your next practical step is to put three current proposals through the decision sheet. If you cannot complete a row, that missing information becomes the next task. To discuss how those decisions fit your programme, tell me about your AI roadmap.
Apply this to your project
Tell me the decision you are facing, the constraints and what you have already tried.
Keep exploring
AI programme management: from roadmap to delivery
Build an AI programme around business outcomes, clear ownership and production readiness. A practical guide to priorities, governance and delivery.
AI governance: assign responsibility before release
Make AI governance operational with clear decision rights, release gates and incident ownership. Use a charter that your team can apply to real work.
AI project risk register: turn concerns into controls
Build an AI project risk register around failure scenarios, owners and tested controls. Use a worked example to review residual risk before release.