The first project is a decision about the programme
An executive group choosing its first enterprise AI project is making more than a choice of use case. It is stating what the organisation believes it can do, which leader is measured on the result, and whether the transformation office can be trusted with something real. A first project that fails does not fail alone: it becomes the reference against which every later proposal is judged.
That is why the criteria in most organisations are implicit. They live in the head of whoever has done the most reading, or in the readiness of the loudest advocate. The result is a portfolio that is technically reasonable and operationally unaccountable, and the unaccountability surfaces only later.
Measurable value is a precondition rather than a score
A candidate with no measurable cost in it cannot be a first project, however promising the technology is. This is not a ranking dimension to be traded against others. It is an entry condition, because without a baseline nobody can later distinguish a successful project from a successful-looking one.
The baseline is unglamorous and quick to gather: the number of transactions the process handles in a period, the proportion touched after first record, the interval from trigger to completion, and the hours spent correcting and re-entering. Those four quantities are usually already in a system of record. The method is described in calculating the value of enterprise AI.
Operational readiness decides whether the first project survives
A pilot can be technically excellent and still fail at handover, because the organisation was not ready to receive it. Readiness here is a business condition: the process has a named owner, the required context has a definition and a location, and the people who do the work have been told what will change.
Four questions settle readiness quickly. Does one executive own the outcome? Is the process documented rather than remembered? Does the data exist in usable form? Has the team delivered anything to this user group before? A candidate that fails two is not a first project, however attractive the value looks.
Implementation effort is the variable almost nobody counts
Value and readiness are both visible in a room. Effort is not, and it is the variable that most often turns an approved project into a stalled one. Three components sit inside it, and each has a different owner.
| Component | What it covers | Who can reduce it |
|---|---|---|
| Context preparation | Definitions, authoritative sources, reconciliation of the records the process depends on | The business owner, with the data team |
| Integration | Reading and writing across systems of record, and reconnecting whenever one of them changes | Platform and architecture |
| Adoption | Training, the productivity dip while people learn a new way of working, and retiring the old way | The function that owns the process |
A project that names only the build will underestimate itself, and the first overrun will be spent on context preparation. Asking the engineering team for an honest range on the three components separately is reasonable, and the answer is usually narrower than the organisation fears.
Risk and sponsorship have to sit in the same decision
Risk is usually discussed as a technical property: how accurate the output is, how often the model fails, what happens when the data is missing. That is the wrong level for a first project. The question that matters is what happens to a person, a customer or a regulator if the system is wrong, and whether it can be reversed.
Bounded and reversible outcomes belong in a first project: a proposal assembled from information the business already holds, a queue that prioritises work for a person, a draft a human approves before it reaches anyone external. Irreversible outcomes do not, whatever their value. Sponsorship runs alongside this and is not a soft factor: a project without an executive who will defend the outcome when the first quarter is disappointing will consume attention indefinitely without ever reaching production. Keeping a first project small enough to finish is an engineering discipline, set out in business application engineering.
A sequence for the selection review
The review itself is where a bad portfolio is usually created, because it treats selection as a decision. It is a hypothesis, and hypotheses are cheaper to test than to argue about.
- Collect candidates from the work rather than from the strategy agenda: what does your team do most often that it would not do twice, where is information re-entered by hand, and where are decisions made on incomplete information.
- Score each candidate on the five dimensions in this framework, treating value and sponsorship as gates rather than weights, so that a strong score elsewhere cannot rescue a candidate with no measurable cost.
- Run three cheap tests on the leading candidates: a data test that proves the inputs can be produced reliably, a value test that replays the proposed intervention against historical records, and a readiness test with the process owner present.
- Shape the portfolio rather than the ranking. Include one project with a short, unambiguous cycle and visible volume, so that a delivery arrives early.
- Record the excluded candidates and the reason for each, and set the review date at which the baseline, the first delivery and the adoption data are on one page.
The document that results should be short enough to read in ten minutes. If it runs longer, the candidates have not been reduced to a decision, and the review will produce a ranking nobody can act on.
The first project does not prove that the technology works. It proves that this organisation can be trusted to finish something.
A defensible first project is unremarkable in a specific way: the value is counted, the owner is named, the effort is estimated in three parts, the consequence of failure is bounded, and the baseline is written down before a line of code exists. How that first success becomes an organisational capability is the subject of building reusable enterprise AI capabilities.