The roadmap

What you will learn The four phases one project passes through from idea to production, what each produces, and the test for whether you may move to the next one.

Why a procedure at all

Once you have picked the work, why not just build it? Because without a procedure it typically goes like this:

text

"Let's automate invoice entry" → straight into development→ 3 weeks later: "wait, every supplier uses a different format?"→ 2 more weeks: "40% of these are exception cases"→ a month later: "honestly a person doing this would be better"

Those are things learned while building. Learned before building, you would have changed direction or narrowed the scope.

The purpose of the roadmap is to create an order in which cheap checks come before expensive builds.

The four phases

graph TD
  P1["Phase 1<br/>Define the problem"] --> P2["Phase 2<br/>Data and system assessment"]
  P2 --> P3["Phase 3<br/>Design and run a POC"]
  P3 --> P4["Phase 4<br/>Production rollout"]
  P3 -.->|"effect unproven"| P1
  P4 --> P1

The two dotted lines matter.

Phase 3 → Phase 1 (going back): if the POC does not confirm the effect, going back is the correct move. Scaling something unverified is the most expensive mistake there is.
Phase 4 → Phase 1 (going round again): rollout is not the end; it is the starting point of the next project.

What each phase answers

Phase	Core question	Output
1. Define the problem	what hurts, and how much	list of suitable work & ROI projection
2. Assessment	can it be built	system architecture & data flow diagram
3. POC	does it actually work	POC report & scale-up recommendation
4. Rollout	does it keep running	operations manual & KPI dashboard

Gates — may you move on?

At the end of each phase there is a test for whether you may proceed. Without it, phases become ceremony — you produce a document and move on anyway.

Gate	Pass condition	If it fails
1 → 2	every candidate has numbers for current time and cost	collect the numbers first
2 → 3	you confirmed you can actually access the data you need	solve access first
3 → 4	Phase 1's numbers actually moved, and users keep using it	go back and redesign
4 → next	it runs without hand-holding and metrics land on a dashboard	strengthen operations

If you skip a gate

Skipping each gate has a determined place where it blows up.

Gate skipped	When it blows up
1 → 2 (no numbers)	at the very end. No proof, so no expansion budget
2 → 3 (no access check)	mid-POC. "You can't have that data"
3 → 4 (effect unverified)	after company-wide rollout. Failure discovered after big spend
4 (no operations)	3–6 months later. Quietly stops being used

It gets more expensive as you go down. The purpose of a gate is to fail cheaply.

How long each phase takes

It varies with project size, but roughly:

Phase	Duration	Note
1. Define	1–2 weeks	if it runs long, you usually have too many candidates
2. Assess	1–3 weeks	data access permissions stretch this
3. POC	3–6 weeks	the core. Shorter is better
4. Rollout	2–4 weeks	includes training and monitoring setup

For a first project that comes to two to three months. That is the arithmetic behind "a first project must produce results within three months" from sequencing.

This roadmap versus hyper-agile

Easy to confuse, so let us separate them up front.

	What it covers	When
The AX roadmap	the organisation's adoption procedure	starting one project and embedding it
Hyper-agile	how you work day to day afterwards	in Phases 3–4, when you actually build

	Who reads it
The AX roadmap	whoever decides on and drives adoption
Hyper-agile	whoever leads the team that builds

You do not need both. If you are driving adoption, this roadmap is enough; hyper-agile is for the engineering side to read when they start building.

The roadmap is the frame; the hyper-agile methodology enters inside it at Phases 3–4, when you start actually building something.

Common misconceptions

"Four phases is heavy for a small project."

Keep the phases and make each one short. For a small project, Phase 1 might be half a day and Phase 2 a day. What matters is the order and the gates, not the page count.

There is no phase you can skip. Phase 1's "record the current value" takes half a day, and skipping it makes the whole thing unprovable later.

"The POC succeeded — why can't we scale immediately?"

You can. Phase 4 is that scaling. But Phase 4 contains training, monitoring, and an improvement loop, and skipping those to "just open it to everyone" leads to it quietly falling out of use in three to six months. Scaling is not "widening access" — it is embedding.

Check yourself

1. If Phase 3 does not confirm the effect, what is the correct behaviour?

Answer

Go back to Phase 1. Scaling something unverified is the most expensive mistake there is. The purpose of a POC is not to succeed — it is to decide whether to scale.

2. State the purpose of gates in one phrase.

Answer

To fail cheaply. The more gates you skip, the later and more expensively the problem surfaces. Skip the access check and you stall mid-POC; skip effect verification and you discover failure after a company-wide rollout.

3. Must a small project go through all four phases?

Answer

Yes, but make each one short. Phase 1 might be half a day. What matters is the order and the gates, not the page count. In particular, Phase 1's record of the current value takes half a day and skipping it makes everything unprovable.

Now the phases one at a time → Phase 1 — define the problem