Sequencing: First, Second, Never

The first project has a different job

Your first project's return is almost irrelevant. Its job is to prove the organisation can take an AI system from idea to production and have it change something.

That argues for a first project that is boring, quick, well-instrumented and internal:

Boring, because you want the difficulty concentrated in the organisational plumbing you are actually testing, not in the modelling.
Quick — results inside six months. Sponsors move, priorities shift, and a project that outlives its sponsor rarely survives.
Well-instrumented, so success is a measurement rather than an opinion. A project whose outcome is arguable will be argued about instead of learned from.
Internal, so early errors are absorbed by colleagues rather than customers.

The delivery-note extraction case from the previous lesson is the archetype. Nobody will present it at a conference. It will work.

Each project should make the next one cheaper

This is the difference between a programme and a series of pilots. Ask of every candidate: what does doing this leave behind?

📅 Timeline

Reusable plumbingA path from a source system to a model and back, an authentication pattern, a way to deploy and monitor. The second project should not rebuild it.

A labelled datasetEspecially where human corrections are captured, the asset compounds.

A working relationshipThe business team and the technical team having shipped once together is worth more than any document.

An answer about your own organisationHow long extraction from that system really takes, who blocks, who helps.

A project that leaves none of these behind is a pilot, not a step. Two or three of those in a row and you have spent a year with nothing accumulated.

Deliberately second

Some strong candidates should wait, and saying so explicitly protects them from being started badly.

High value, low readiness. Real benefit, missing preconditions. Do the precondition as a capability project and revisit.
High value, high risk. Worth doing eventually, not while your governance is immature and you have no track record.
Anything depending on a system migration in flight. Building against a system being replaced is the MD Anderson error, which the next module examines in detail.
Anything whose sponsor is leaving. Unsentimental and correct.

Deliberately never

Some candidates should be refused rather than deferred, and it is worth being able to say why in one sentence.

Where the error cost is unbounded and undetectable. A wrong answer reaching a customer, patient or regulator with nothing catching it.
Where the value depends on a decision nobody will take. A cost case in an organisation that will not reduce headcount or absorb growth. The technology is irrelevant; the case cannot land.
Where automation would remove the judgement you sell. If clients pay for your people's expertise, automating the visible expression of it can damage the product while improving the metric.
Where it scores or ranks people without a defensible process. Module 7 covers the obligations. If you cannot meet them, do not start.

Set the stop condition now

Before a project begins, write down what would make you end it. Not "if it fails" — something checkable:

"If we have not reached 80% straightforward-case accuracy by week 12."
"If integration into the ticket tool is still unavailable at week 16."
"If triagers override more than 40% of suggestions after a month of live use."

Two reasons this matters more than it seems. Written at the start, it is an objective test; written later, it is a negotiation with people who now have reputations attached. And an unstoppable project consumes the budget and credibility of the next three.

AI projects are unusually prone to running long past the point of sense, for reasons worth naming.

Progress is genuinely hard to read from outside — accuracy improves in irregular jumps, so "we are nearly there" is always plausible. The team is usually working hard and well, so stopping feels like a judgement on them. Money is spent early on data work, so the sunk cost is large before there is any result to judge. And by month nine, several people's credibility is attached.

The technique that works is a pre-mortem, run before starting. Gather the people involved and ask them to imagine it is twelve months from now and the project has clearly failed. Then ask each person to write down why.

It produces a different quality of answer than "what are the risks?", because it removes the social cost of pessimism — you are not predicting failure, you are explaining a hypothetical one. People say the thing they would otherwise not say in front of the sponsor.

Typical output, and every item is actionable:

"The data extract took four months because the vendor of the source system charges for API access and procurement took a quarter."
"It worked, but triagers kept overriding it because they were never told how it decides."
"The person who understood the exception rules retired in March."
"We built it against the old system and the migration landed in September."

Turn each into either a mitigation or a stop condition. The last one is the MD Anderson failure, and a team that has said it out loud in month zero will not walk into it in month fourteen.

❓ Knowledge Check

What primarily determines the choice of a first AI project?

📚 Flashcards1 / 6

Term

The first project's job

Click to flip

Definition

To prove the organisation can take an AI system from idea to production and change something. Boring, quick, well-instrumented and internal — its return is close to irrelevant.

Click to flip back

💡Key Takeaway

Choose the first project to prove the organisation can ship, not to maximise return — boring, quick, measurable and internal. Judge every candidate by what it leaves behind, because a project that leaves no reusable plumbing, data or relationship is a pilot rather than a step. Be explicit about what is deliberately second and what is deliberately never, and write a checkable stop condition before starting, while it is still cheap to be objective.