How to prioritise and sequence AI projects

Prioritisation without theatre

Prioritisation workshops often end in a matrix nobody remembers by the following Monday. Everyone nods at the two-by-two, someone photographs the whiteboard, and then the backlog gets built from whoever shouted loudest in the room. The fix isn't a better workshop. It's a scoring model you apply the same way every time, so the ranking survives contact with the next planning cycle.

Six factors worth scoring

Score each project 1-5 on:

1. Strategic fit. Does it move a stated business outcome, or just feel relevant?
2. Feasibility. Can a first version ship in one to two quarters with the team you actually have?
3. Data availability. Do you have the data today, or do you need to build the pipeline first?
4. Cost. Total cost of ownership across the first year, not the price of the pilot.
5. Risk. Regulatory, reputational, operational — score the worst plausible outcome, not the average one.
6. Time to value. When does someone outside the project team notice a difference?

The total gives you a ranking. That's useful, but it's the least useful part of the exercise. The sub-scores are where the decisions live.

Ranking tells you what. Sequencing tells you when.

Two projects can land on the same total score and still belong in completely different quarters. Take an example: a customer-service AI assistant and a supplier-risk monitoring tool, both scoring 19 out of 30.

The assistant scores high on strategic fit and time to value, but low on data availability — support transcripts are scattered across three systems and half of them aren't tagged. The supplier tool scores lower on strategic fit (it's operational hygiene, not growth), but high on feasibility and data availability — the procurement data is already clean and centralised.

Same total. Opposite sequencing logic. The supplier tool goes first, not because it matters more, but because it can bank a real win in six weeks while the assistant's data problem gets fixed in the background. Rank them by total score alone and you'd toss a coin. Sequence them by sub-score and the order is obvious.

This is the distinction worth holding onto: ranking answers "which is better," sequencing answers "what happens first, and why does that order work." A list sorted by total score is not a roadmap. It's an opinion poll.

Sequencing rules that hold up

• Foundations first. If three projects on your list all need the same clean customer dataset, build that once, and credit it to whichever project starts the clock. Building it three times, once per project team, is how programmes quietly triple their own cost.
• Confidence-building wins early. A visible result in quarter one is what pays for the harder, slower project in quarter three. Don't spend the first quarter on the hardest problem on the list just because it scored highest.
• Sequence to capacity, not appetite. A five-star project still shouldn't start if the team delivering it is already committed elsewhere. Appetite says "yes, and, and, and." Capacity says "one at a time, properly."

Two pitfalls that undo the whole exercise

Starting everything at once. Scoring produces a ranked list, and the temptation is to greenlight the top five simultaneously because the board approved the budget in one sitting. This is how you get five projects at 40% progress in month six and nothing shipped. Pick the next one or two. Finish them. Then pick the next.

Ignoring shared foundations. Scoring each project in isolation hides the dependencies between them. If your top three ranked projects all quietly assume the same data-quality fix that nobody scored separately, you'll discover it mid-delivery, which is the most expensive place to discover it. Look across the top of your ranked list before you sequence, not just down it.

What to do this week

1. Score every project on your current list against all six factors — not just the ones that make it look good.
2. Before you publish the ranking, group projects by shared dependency. Anything that needs the same data, system, or team goes in the same conversation, not three separate ones.
3. Sequence the top few using the rules above, then publish the ranking, the scores, and the reasoning behind the order. When someone asks "why isn't my idea being built yet," you have a specific answer instead of a shrug.

Where Florence helps

Florence scores every project against the same six criteria automatically, so the ranking doesn't depend on who was in the room that day. The scores sit next to your strategy, not in a separate spreadsheet that goes stale by the next quarterly review — so when priorities shift, you can see immediately which projects were affected and why.