Why roadmaps fail on missing steps, not bad estimates
The promise was made in January. A Series C software company with 60 engineers would launch its product in the European Union by 30 June. Three enterprise contracts worth $4.2 million a year depended on that date. The head of engineering built a roadmap of nine workstreams, sized each one, added a 20% buffer, and presented a plan that finished on 12 June with eighteen days to spare.
Every estimate in that plan turned out to be right. The regional data pipeline took the eleven weeks it was given. The infrastructure work landed early. Two workstreams ran a week over and the buffer absorbed both. By the standards the company used to judge its own planning, January's roadmap was a success.
The product reached Frankfurt on 4 February the following year, seven months late. One of the three customers had signed with a competitor by then.
In the last week of April, an engineer found that the company's identity provider ran on a single-region contract. Going regional needed an enterprise agreement, and the vendor would not sign one inside 90 days. Nothing engineering did could shorten that. The 30 June date had been dead since January. It took four months to notice.
The retrospective blamed the estimates. The estimates were fine. The plan was missing a step.
Engineering Measures the Wrong Thing
Engineering teams pour effort into estimation. Planning poker, story points, velocity charts, three-point estimates, burn-down history: all of it answers one question, which is how long a known task will take. Almost nothing in the process asks whether the list of known tasks is complete.
Those two errors behave nothing alike.
Estimation error is bounded and it cuts both ways. A task guessed at four weeks might take six, or three. Across forty tasks the misses cancel each other out, and a buffer soaks up what is left. That is why buffers work at all.
A missing step only runs one way. It can only add time, and its size has nothing to do with the size of the plan it lands in. A 90-day vendor cycle dropped into a 24-week programme is a 54% overrun. No estimation method on earth would have caught it, because estimation only works on tasks somebody already wrote down.
The data says the same thing. Bent Flyvbjerg's database of more than 16,000 projects, across two decades and twenty industries, found that 47.9% came in on budget. 8.5% came in on budget and on time. Half of one percent came in on budget, on time, and delivered what was promised. A McKinsey and Oxford study of 5,400 large IT projects found cost overruns of 45%, schedule overruns of 7%, and value 56% below forecast.
Look at the gap between those last two numbers. Schedules slipped a little. Value collapsed. That is what it looks like when teams execute their plans faithfully and the plans were missing the right contents.
Flyvbjerg's main finding is that the projects that work spend far more time planning before delivery starts. Planning is cheap because nothing has been built yet, so a plan can be torn up and redrawn for the price of a meeting. Delivery is expensive, and every extra week the delivery window stays open is another week for something to go wrong. The money is in moving the discovery earlier, to the point where discovery is nearly free.
Tasks Are Not Conditions
Forward planning starts from today and asks what the team can do next. It produces tasks, because tasks are what a team can do. That is its blind spot.
A task is an action you own. A condition is something that has to be true, and you often do not own it.
The identity provider contract was never a task. Nobody on that team could have put it in a sprint. It was a condition: the vendor agreement has to allow regional deployment. Conditions like this never appear on forward-planned roadmaps, because forward planning asks what to build, and this was not something to build. It was something that had to be true.
Working backwards asks a different question, and the different question is the whole trick. Start at the outcome. Ask what else has to be true for that outcome to hold. The answers come back as a mix of tasks and conditions, and the conditions show up straight away, because the question never asked who owns them.
The method is old and precisely defined. Richard Fikes and Nils Nilsson wrote it up as goal regression in the STRIPS planner at SRI in 1971: start at the goal, run the steps backwards, and stop when everything left over is already true. Engineers write backward chaining into software all the time. They almost never run it on their own delivery plans.
There is a clean rule for when to stop. Break each condition down until every leaf is one of two things: already true today, or a job one named person can start on Monday with what they already have. Anything else is not broken down yet. A leaf reading "get legal approval" fails, because nobody can start that on Monday without knowing which lawyer, which document, and which decision. A leaf reading "send the DPA draft to outside counsel, owner Priya, budget approved" passes.
What Working Backwards Gives You
Done properly, it produces three things a roadmap does not.
An order, not a list. A roadmap is a sequence somebody chose. Working backwards produces a graph where the sequence comes out of the dependencies instead of out of opinion. Once the graph exists, the critical path and the slack fall out of it for free. This is 1957 technology. Morgan Walker and James Kelley built the critical path method at DuPont, and its backward pass works out the latest date each task can start without moving the end date. Most software teams have never run one. So they treat every piece of work as equally urgent, because they have no way to tell which work cannot slip. In a normal delivery graph, most tasks carry real slack. Chasing all of them equally hard spends attention where it changes nothing.
Conditions with clocks on them. Working backwards digs up the steps whose length is set by somebody else: vendor procurement, regulator sign-off, penetration test booking, a customer's change freeze, an audit window, a notice period. Two things make these the ones worth finding early. Adding engineers does nothing to them, and they will almost always run alongside the build. A 90-day procurement cycle started in week one is free. The same cycle started in month four costs a quarter.
A resource picture, not a headcount. The graph says which skills are needed and when, which shows you the clashes a headcount number hides. Sixty engineers does not mean sixty engineers for this. If four tasks on the critical path all need the two people who understand the authorisation service, the critical path is longer than the graph says it is. Two people wanted by four critical tasks is the most common reason a correct critical path still understates the delivery date.
The Cost of Finding Out Late
Barry Boehm showed in Software Engineering Economics that the cost of fixing a defect goes up roughly tenfold for every phase it survives. Catch a requirements error at requirements and it is cheap. Catch the same error in production and it costs a hundred times more. The curve has held up for forty years.
A missing condition is a requirements defect in the plan, and it rides the same curve. Here is the same goal, planned both ways.
| Item | Planned forwards | Planned backwards |
|---|---|---|
| Planning before delivery starts | 1 week | 3 weeks |
| Planning cost (8 people, loaded) | $55,000 | $165,000 |
| Vendor contract found | Month 4 | Week 1 |
| Procurement cycle | On the critical path | Alongside the build |
| Rework on a dead assumption | $482,000 | $0 |
| Revenue pushed back two quarters | $2,100,000 | $0 |
| Contract lost to a competitor | $1,600,000 | $0 |
| Total exposure | $4,237,000 | $165,000 |
The rework figure is fourteen engineers spending five weeks building region-aware services on top of an identity layer that could not go regional, at $172 an hour fully loaded. The revenue figures are the contracts. The extra $110,000 of planning is the entire cost of avoiding all of it.
The work itself never changed. The same vendor agreement was needed either way, at the same price. The only thing that moved was when it became visible. Found in week one it costs an email. Found in month four it costs a quarter of the year's new enterprise revenue.
Amazon built the front half of this into how it operates. The internal press release and FAQ get written before any code does. That works not because press releases are useful documents but because they force the outcome to be specific enough to work backwards from.
Why Teams Keep Planning Forwards
None of this is hard. It is missing for reasons of incentive, not knowledge.
Working backwards needs a specific outcome, and being specific is politically expensive. "Improve our enterprise readiness" cannot fail. "On 30 June a customer in Frankfurt signs up and no personal data leaves the EU" can fail in public on a known date. Richard Rumelt's Good Strategy / Bad Strategy names that swap as the main sign of bad strategy: a list of wishes presented as a plan, with no diagnosis of the obstacle and no set of actions that deal with it. Most engineering roadmaps fit the description exactly. They are lists of work somebody wants, and a list of wants cannot be checked for completeness, because nobody ever claimed it was complete.
Working backwards also digs up obligations belonging to other departments. It produces sentences like "legal has to approve the standard contractual clauses by 15 March" and "finance has to release the vendor budget in Q1". Raising those in January means asking peers for dated commitments before anyone is invested. Raising them in April means the same conversation under pressure, which is worse for the company and easier for the person raising it, because by then nobody needs persuading.
The backward pass also makes the critical path visible, and a visible critical path hands somebody the blame in advance. When the graph shows one team's work setting the delivery date, that team's lead is carrying a public constraint. Vague sequencing spreads the blame thin enough that nobody has to carry it, which is most of why it survives.
What This Is Not
Working backwards is not waterfall, and that confusion is the main reason teams throw it out. Waterfall fixes the solution and the schedule up front. Working backwards fixes only the outcome, and treats the path as a guess about dependencies that gets revised as facts arrive. The graph is a model of what has to be true. It is not a Gantt chart of who does what in which week. When the outcome changes, run it again. Nothing has been built yet, so rebuilding costs a day.
It also has limits. Working backwards needs a goal you can describe. In research and in real product discovery you cannot describe it, and the right move there is to search rather than to plan. Force a dependency graph onto a search problem and you get a confident plan that is wrong. The skill is knowing which of the two you are in. Most work labelled discovery is not discovery. A company that has already sold three contracts against a date is not searching. It knows exactly what it owes and has agreed a price for it.
The last objection is that planning this early is guesswork. It is, and the answer is to ask the outside question. Daniel Kahneman and Amos Tversky's split between the inside and the outside view applies directly. Instead of guessing a condition from its own details, ask how long that kind of condition usually takes. Vendor enterprise agreements take a quarter. Penetration tests get booked six weeks out. Regulators take as long as they take. Those numbers are usually available for exactly the conditions that are most dangerous to guess at.
The Test
The test costs almost nothing. Take this quarter's biggest commitment and write one sentence describing the world on the day it is met, specific enough that an outsider could check it. Then ask what has to be true for that sentence to hold, and repeat on every answer until each leaf is either true today or startable on Monday by a named person.
Two things turn up nearly every time. There is at least one condition running on somebody else's clock that nobody had noticed, and it is already late. And the critical path runs through work the team had filed as low priority, while a good share of what everyone is busy with this week carries weeks of slack.
The company that missed 30 June did not execute badly. It executed a plan that was consistent, well estimated, properly buffered, and wrong in one place. For four months the team worked hard along a path that did not reach the goal.
Most teams find that out in month four. The graph tells you in week one.