# 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: ``` "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 ```mermaid graph TD P1["Phase 1
Define the problem"] --> P2["Phase 2
Data and system assessment"] P2 --> P3["Phase 3
Design and run a POC"] P3 --> P4["Phase 4
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](/guide/ax-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](/guide/ha-agile-limits) 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](/guide/ax-phase1-problem)