Delivery roadmap: how to build one that survives the quarter

What a delivery roadmap is, and how it differs from the commitment record underneath it, has its own page. This essay is about building one: where the rows come from, what goes on each of them, how often to touch it, and how it goes bad. I will assume a quarter as the horizon, because that is the period most engineering organisations promise in.

Build it downward from commitments

The usual way to build a roadmap is to open a blank timeline and place things on it. The order of operations is the problem. A bar on a timeline gets its date first and its evidence later, if ever, and by the time anyone asks whether the team agreed to it, the slide has been shown to sales.

Reverse the order. A row earns its place on a delivery roadmap by already being a commitment: somebody owns it, the delivering team gave the capacity figure, and the date was agreed by the people who have to hit it. The roadmap is then a summary of promises that exist elsewhere, and drawing it is an afternoon's work, because every hard conversation has already happened. If drawing it is hard, that is the finding: you are discovering which rows were never agreed.

Everything else people want to see on it, the things leadership hopes for and the things still under discussion, goes in a separate section labelled intended, not committed, with a period instead of a date. Keeping those two sections apart is most of the craft.

What goes on each row

Five columns beyond the name of the work. Each one is there because its absence produces a specific failure.

• Owner. One person, by name. A team name is a blank that looks answered, and the owner is who a reader goes to when the row looks wrong.
• Capacity, per team. FTE-months, team by team, in the figure each delivering team gave. Per team because the constraint is never the organisation's total; it is the one team three rows happen to need, and only a per-team figure shows that against that team's capacity line.
• Dependency. Who else has to do something, what, and whether they have agreed. "Asked, not confirmed" is a legitimate entry and the most useful one on the page, because logged is not asked and asked is not confirmed. "None known" is also an entry. Blank is not.
• Target date. The date the delivering team agreed to, not the date someone needed.
• Date confidence. High, medium or low, with the reason in a few words whenever it is not high. This is the column that stops a range hardening into a date on its way upstairs: a reader who sees "low: legal scope not signed off" cannot later claim to have been promised the twelfth of December.

What does not go on it: tickets, tasks, percentage complete, progress bars. Those belong to the team's board. A roadmap that tries to carry them is out of date by Tuesday, and the first stale row teaches every reader to distrust the other rows.

A worked example

The example below is invented: a logistics software company, four teams, the October to December quarter. It is the whole roadmap, not an excerpt.

Three things to read off it. The third committed row is where a reader's attention should land, and the table sends it there: low confidence, the reason attached, a dependency nobody has confirmed. Payments appears on two rows, five FTE-months in total, which is the figure to hold against that team's line before anyone adds a fourth row. And the second table has no dates at all, deliberately, so that nothing in it can be repeated to a customer as one.

It is a table, not a picture. Draw bars from it if your audience wants bars, but the table is the roadmap and the picture is an illustration of it. When the two disagree, the picture is wrong.

How it differs from a product roadmap in practice

The definitions are on the glossary page. In daily use the difference comes down to four habits. Who can add a row: a product lead adds to a product roadmap on their own judgement; nobody adds a committed row to a delivery roadmap without the delivering team's agreement to the capacity. What a date means: on a product roadmap, a direction of travel; here, something another person is planning against. What a change is: a product roadmap changing its mind is the artifact doing its job, while a delivery roadmap changing a date is an edit to a promise, and someone has to be told. Who reads it: sales, support and adjacent teams, who will act on what it says without asking you first.

If one document has to serve both purposes, mark every row with which kind it is. The expensive failure is the unmarked row that product meant as intent and sales read as a date. I have set out where roadmap tools and commitment records sit relative to each other in a separate comparison.

How often to update it

Three rhythms, none of them weekly redrawing.

On the event. When a commitment is made, changed or closed, its row changes the same day. The roadmap is derived, so it moves when its source moves and not otherwise. When a date moves, the reason goes on the row, stated against what was agreed: the scope changed, the capacity changed, a dependency did not land, or the outcome itself was revised. A new urgent row does not simply appear either. It displaces a named row, and both edits are made together.

Every two weeks. Each owner restates their confidence and its reason. Ten minutes, no slides. Most rows will not change, and that is a result worth having on the record.

At the quarter boundary. Rebuild it from the commitments instead of rolling the old one forward. Rolling forward is how a row nobody would commit to today survives for a year.

The three ways it rots

Dates move without a reason. Someone drags the bar. The new date is visible and the old one is gone, along with any way of asking what changed. After three of these the roadmap is a record of current hopes, and readers work that out faster than its authors do.

Intentions leak into the committed section. It starts with one row a senior person wanted to see there. It has a date, because the section has a date column, and no owner or capacity, because nobody agreed to it. From the outside it is indistinguishable from its neighbours.

It stops being derived. People begin editing the roadmap directly because it is the thing everyone looks at. Now the roadmap and the commitments underneath it disagree, and the roadmap wins by visibility while being the less careful of the two.

One test catches all three. Pick any committed row and ask its owner two questions: what capacity did each team agree to, and what would move the date? If the answers come from a record, the roadmap is alive. If they come from memory, it has started to rot.

Where DeliverySheet sits

DeliverySheet has no roadmap, Gantt or timeline view, and I will not pretend its reports are one. What it holds is the layer a delivery roadmap should be built from: a commitment recorded per demand, with an owner (the picker accepts a team; name a person), capacity estimated per team in FTE-months, and the dependencies and risks from its Plan. Committing a demand before it is ready requires a recorded exception, and re-baselining a commitment requires a reason that is kept on the commitment ledger. The roadmap itself you still draw by hand, wherever you draw it; there are no integrations to do that for you.