Why the list always goes wrong
Every enterprise ends up with a list of AI opportunities, and the list is almost always assembled in one of two bad ways. It is either a demonstration-driven list — whatever the team saw last month — or a wish-list collected from department heads, who are each certain their own area is the priority. Both lists share the same defect: they are sorted by enthusiasm and visibility rather than by value, and neither has been tested against whether the organisation could actually deliver.
The first ten projects matter more than the next fifty, because they establish whether the organisation believes this kind of work produces results. A first portfolio that includes one hard failure and two unmeasurable successes sets a precedent that is expensive to overturn. The method below is designed to make the first portfolio survivable.
Step one: collect candidates from the work, not from the agenda
A candidate list built from a strategy workshop will contain strategies. A candidate list built from evidence of work contains problems. The distinction is worth enforcing at the start, because it is very easy to spend the first fortnight discussing ambition and never reach a process.
- Ask each functional leader for the three things their team does most often that they would not do twice if they could, and the three that generate the most rework. Requested as tasks rather than as problems, this produces a list of activities, which is what you want.
- Ask where information is copied, re-entered or re-typed. This is the signature of fragmented operations and it is easy for people to identify, because everyone has recently been annoyed by it.
- Ask where decisions are made on incomplete information. This surfaces reporting and visibility gaps, and it is where continuous operational intelligence programmes genuinely pay.
- Add anything already being attempted informally. Somebody has already built a spreadsheet to solve a problem, and that spreadsheet is the most detailed requirements document available for the problem.
Expect fifteen to thirty candidates. The output of this step is not a shortlist. It is a pool, and its purpose is to make sure that the shortlist is not merely the most visible ten.
Step two: score five dimensions
Each candidate is scored on five dimensions. The value of the exercise is not the arithmetic; it is the argument it forces about why a project is worth doing.
| Dimension | The question it answers | What a high score means |
|---|---|---|
| Economic value | Is there a measurable cost or delay that this process carries? | A number exists, or one can be counted in a fortnight. |
| Feasibility | Can this be built with available data and normal integrations? | The data exists in a system of record, not in somebody's inbox. |
| Data readiness | Does the required context have an owner, a definition and a location? | Someone is accountable for it and can be asked. |
| Risk | What happens if this is wrong, and who is affected? | The consequence is bounded and reversible, and an approver is identifiable. |
| Organisational sponsorship | Is there an executive who owns the outcome, not the tool? | A named owner will defend the outcome when it is inconvenient. |
Two rules make the scoring worth doing. First, the economic value dimension must be scored from evidence, not from the advocate's enthusiasm — a candidate with no measurable cost cannot score highly however compelling its technology. Second, the sponsorship dimension is a hard gate rather than a weight: a project without a named business owner will consume the team's attention indefinitely while never reaching production.
Step three: test the top three cheaply
The next mistake is to treat selection as a decision. It is a hypothesis, and hypotheses should be tested before they are funded. Three tests are enough, and they can be run in a fortnight for a fraction of the cost of building anything.
- A data test. Can a person, given the source systems, produce the input the project needs, reliably, in a day? This is where most candidates fail, and failing here is cheap.
- A value test. Using historical records, does the proposed intervention predict or produce the outcome it claims? A simple model, run by a person, is sufficient for this purpose.
- An ownership test. Would the executive who owns the outcome use the result weekly, and would they act on it? Ask them directly, with a description of the output rather than of the technology.
The third test is the one most often skipped and the one most predictive of whether a pilot becomes a deployment. An output nobody acts on does not produce value, however good it is, and the people best placed to know whether they would act on it are the ones who own the process.
Step four: shape the portfolio, not the ranking
The final step is the one that distinguishes a portfolio from a shortlist, and it involves deliberately not taking the top three by score.
- Include at least one project with a short, unambiguous transaction time and a visible volume. It will deliver first, it will be unremarkable, and it will establish the credibility that the harder projects need.
- Include at least one project that crosses a departmental boundary, early rather than late, and with the boundary problems acknowledged in advance. This is where the organisational learning happens, and it is far cheaper to learn it on a small project.
- Include one project that deliberately does not use AI. It is often present in a strong first portfolio, it demonstrates discipline rather than enthusiasm, and it removes the impression that a tool is being deployed for its own sake. The reasoning is set out in when to use AI, rules or conventional automation.
- Exclude any candidate that duplicates an existing capability you have already built. Rebuilding is the most common way a first portfolio fails to compound, and the warning signs are described in building reusable enterprise AI capabilities.
What the first ninety days should produce
A first portfolio should end with a short document: ten candidates, their scores, the reasoning behind the scores, the three tests and their results, the recommended three projects, the excluded candidates with reasons, and the baseline figures for each recommended project. It is a document that will be read again in a year, when the portfolio is being reviewed, and it will either confirm or contradict the judgements recorded in it.
That document also does something more useful than selecting projects. It gives the executive team a shared, evidence-based view of where value sits in the business, which is a considerably harder thing to obtain and the thing most worth having. The full discovery method behind it is described in the first thirty days of a forward-deployed engagement, and the interviews that produce candidates of this quality are in the executive interview questions that reveal hidden AI opportunities.