# Sequencing

> **What you will learn**
> How to order several candidates that all passed the three questions. And why
> starting with the biggest impact is a mistake.

## Impact order versus starting order

Impact grows as you go down the three principles.

```
Quality  <  Cost  <  Revenue and margin
```

But **the starting order is generally the reverse.**

```
Cost  →  Quality / Revenue
```

The table makes the reason clear.

| Criterion | Quality | Cost | Revenue |
|---|---|---|---|
| Size of effect | medium | medium–large | **large** |
| Speed of proof | slow | **fast** | medium |
| Data prerequisite | medium | **low** | high |
| Resistance from the floor | low | medium | low |
| **Fit as a first project** | △ | **◎** | △ |

## Why not start with the big one

Here is the most common failure path, in order.

```mermaid
graph TD
  A["Month 1: start with revenue<br/>because impact is biggest"] --> B["Month 2: data is scattered"]
  B --> C["Month 4: still cleaning data"]
  C --> D["Month 5: 'how's it going?' starts"]
  D --> E["Month 6: nothing to show"]
  E --> F["Budget and attention leave"]
```

**The judgement was not wrong.** Revenue work really does have the largest
impact. What was left out of the calculation is **the organisation's patience as
a resource.**

Organisations do not wait indefinitely. A first project in particular is under
**the "is this actually going to work?" gaze**, and that gaze usually reaches a
verdict in three to six months.

## What a first project needs

A first project should not be the one with the biggest result. It should be the
one **that can be proven.**

| Condition | Why |
|---|---|
| Results within 3 months | inside the organisation's patience |
| Measurable in numbers | expansion is decided on that number |
| You already know the current value | you have something to compare against |
| Failure does no real damage | so failure does not stop the whole transformation |
| The owner cooperates | without them you cannot build it |

> **Do not treat the fifth lightly.** A technically perfect project fails if the
> person doing that job is uncooperative, because only they know how the work
> really runs.

## The table for ordering

With several candidates, lay them out like this. A real example:

| Candidate | Principle | Time to result | Current value? | Owner | Order |
|---|---|---|---|---|---|
| Invoice entry automation | cost | 2 months | ○ (400/mo, 40 hrs) | cooperative | **1** |
| Automated ticket replies | cost, quality | 4 months | ○ (1,200/mo) | cooperative | **2** |
| Review analysis | quality | 6 months | △ (rating only) | — | 3 |
| Price optimisation | revenue | 8 months+ | ✗ | needs HQ approval | 4 |

**The "current value?" column effectively decides the order.** If the value
exists you can start immediately; if not, you have to build it first, so it goes
to the back.

## After the first project — the second is different

A successful first project gives the organisation **three things.**

1. **Trust** — the experience of "this works"
2. **A baseline** — you learned how to measure and how to judge
3. **People** — someone has now done it

With those in hand you **can start longer projects.** A six-month revenue
project will be waited for, because the first one proved itself.

```mermaid
graph TD
  A["1st: cost reduction<br/>2–3 months · solid proof"] --> B["Trust · baseline · experience"]
  B --> C["2nd: quality or mid-sized<br/>4–6 months"]
  C --> D["3rd: revenue<br/>6 months+"]
```

## Can you not run several at once?

**Do exactly one first project.** Two reasons.

**One, you lose causality.** Run three at once and when a metric moves you do
not know which one did it. Then you cannot decide what to expand.

**Two, the first project is also a learning process.** You learn how to measure,
who to work with, and where things stall. Run three at once and you make the
same mistake three times.

From the second round on, parallel is fine.

## Common misconceptions

### "Start small but also high impact — isn't that contradictory?"

Two different axes.

- **The three questions** ask "is it worth anything" → they filter candidates
- **Sequencing** asks "which one first" → it picks among the survivors

Among worthwhile candidates you do **the small, fast one** first. You do not
pick the small one among the worthless ones. That is why
[the three questions](/guide/ax-choosing-tasks) come first.

### "Leadership wants the big one."

The point is not to **skip** the big project but to **stage it.** Explained this
way, it usually lands:

> "Price optimisation needs competitor price data, which we don't have. Phase 1
> is automating that research, and that alone saves X hours a month. Once the
> data accumulates, phase 2 is the price optimisation."

**Break a big project into stages** and the first stage very often turns out to
be a cost project.

---

## Check yourself

**1. Why is starting with the highest-impact project prone to failure?**

<details>
<summary>Answer</summary>

Because **the organisation's patience** was left out of the calculation. Big
projects have many prerequisites and can spend months on data cleanup alone,
while a first project sits under the "is this going to work?" gaze, which
usually reaches a verdict in three to six months.
</details>

**2. Which column effectively decides the order of candidates?**

<details>
<summary>Answer</summary>

**"Do you already know the current value?"** If it exists you can start and
compare immediately; if not, you have to build it first, so it goes to the back.
</details>

**3. Two reasons to run only one first project?**

<details>
<summary>Answer</summary>

One, with several at once, a metric moving does not tell you **which one caused
it**, so you cannot decide what to expand. Two, the first project is **a
learning process** for measurement, collaboration, and bottlenecks — run several
and you make the same mistake several times.
</details>

---

That is how to choose. Now score your own candidates →
[Actually score your candidates](/guide/ax-try-scoring)