Five Tasks Ordered Into a Build Sequence

Five scored tasks arrive from discovery. What leaves this phase is the same five in a sequence, each with a position, a reason for that position, an effort estimate and a running cost.

The first build is picked for how fast it can be judged: a task that finishes proves the route while a task with a larger saving can still be halfway done in March. The remaining four are ordered by what they depend on, so two tasks sharing a connector are built together and the connector is set up once.

What that produces is a plan somebody can stop. Each task ships on its own and into use before the next one starts, so an assumption that does not survive contact with the work is corrected at the second position.

Build Cost and Monthly Running Cost on Every Line

Each task on the plan carries two figures: what it costs to build once, and what it costs to run at the measured volume.

Effort is split. The known work and the part that has not been done in this system before are estimated separately, and the unknown part gets a time box with a decision at the end of it and a defined budget ceiling. That is what keeps one unfamiliar system from absorbing the sequence.

Payback is written in the same unit as the baseline, in hours per month, so the comparison is a subtraction. A task that cannot pay back its build effort inside a year is recorded as such on the plan, which is a cheaper place to discover it than the second month of a build.

Acceptance Defined and Result Measured

The acceptance criteria are written before the build by the person who accepts the result today. They say what a correct output looks like and what happens when it is wrong, which is what decides when the build stops.

After the build is running, the baseline gets read again by the same method that produced it: hours per month on the same task, by the person who owns it. The actual saving is the difference between the two readings, and what that number says about the estimate goes into the next position.

The sequence is re-read after each build with what the last one taught, so the next position starts from the actual state of the work.

5 tasks
scored candidates carried in from discovery
One first
build in progress, the other four dated in advance
Hours/month
the one unit effort, payback and review all share

The Scored List Becomes a Costed Build Plan

From a Scored List to a Build Order 3 steps
01

Planning Opens With the Scored Sheet

The planning session opens with the artifact the previous phase produced: five selected tasks, each carrying hours per month, a suitability total out of thirty, one leading route and a named owner. Nothing enters the plan that does not already sit on that sheet with a number beside it.
02

First Build Chosen for Speed to a Verdict

The first build is chosen for how quickly it can be finished and judged: a task whose owner can tell a correct result from a wrong one, whose systems can be reached today, and whose failure costs an afternoon at most. The saving matters second: a task that ships proves the route as well as a larger one.
03

Remaining Tasks Sequenced by Dependencies

Two tasks that both need the same connector get built as one and a half, and two that share nothing can run in either order. The sequence is therefore derived from dependencies: which tasks share a connector, which need an administrator to approve a permission first, which wait on a decision somebody outside the room has to take. What comes out is an order with a reason attached to every position.
What Each One Costs, Before and After It Runs 3 steps
04

Effort Split Into Known and Unknown Work

Each task is split into the part that is known work and the part that has not been done in this system before: a Graph permission and a mailbox read are known, a wrapper around a system built only for this company sits in the unknown half. Both get days against them, and the unknown part is bounded by a time box with a decision point at the end of it and a defined budget ceiling.
05

Payback in the Same Unit as the Baseline

Both sides are written in hours per month: the measured baseline, the target after the build, and the difference. A task that pays back its build effort inside a year is worth a place in the sequence, and one that does not is written down as such on the plan.
06

Build Cost and Running Cost per Task

Each task therefore carries two figures: what it costs to build once, and what it costs to run per month at the measured volume. Model usage is estimated per run and multiplied by runs per month, hosting is a fixed line, and both go on the plan before anything is approved.
How It Actually Ships 2 steps
07

Each Task Ships Before the Next One Starts

Every task in the sequence is scoped to ship by itself, into use, with the next one starting only after the previous one is running. What that buys is the right to be wrong cheaply: an assumption that does not survive the first build is corrected in the second.
08

Acceptance Criteria Agreed Up Front

The acceptance criteria are written before the build, by whoever accepts the result today, and they say what a correct output looks like and what happens when it is wrong. That sentence is the whole handover test: it decides when the build stops, and it is what the remeasurement is read against.
What Each Build Returns 2 steps
09

Baseline Re-Read After the Build Ships

After the build is running, the baseline gets read again by the same method that produced it: hours per month on the same recurring task, recorded by the person who owns it. The difference is the actual saving. What it says about the estimate goes into the next position in the sequence.
10

Sequence Re-Read After Each Build

After each build ships, the sequence is re-read with what the last one taught: which systems behaved as expected, which step took longer than the estimate, what the acceptance criteria revealed about the task. The next build starts from a position that reflects the actual state of the work.

Frequently Asked Questions

How is this different from the discovery phase that comes before it?
Discovery produces facts, this phase produces a decision. Systems analysis and a single session with the office count the recurring tasks, measure hours per month, score each one against six criteria and assign a leading route. This phase takes that scored sheet and settles what comes next: which task is built in September and which one waits until November, and what each will cost to run.
How long does the planning itself take?
It is measured in days. The work is the estimating: splitting each task into known work and unfamiliar work, checking that the systems named in its route can actually be reached, and getting the acceptance criteria written by the people who accept the results today. The output is a plan document.
What if the plan turns out to be wrong once the first build starts?
That is the reason each task ships on its own. An assumption that does not survive the first build is corrected in the second position, and the sequence is re-read after every build. The baseline and the acceptance criteria stay fixed, because both were recorded before anything was built and are what the remeasurement is read against.
Is this the same planning you do for a software project?
No, and it deliberately stays off that ground. An engineering plan fixes a file tree, an owning track per path and every shared interface verbatim so several build tracks can run at once against one codebase. This one sequences office tasks against the systems a company already runs, in hours per month and running cost per month. If the work is a build on your own codebase, the fact gathering and planning page on the engineering branch is the one that applies.