When the business asks for a roadmap but needs a decision

"Can we have a roadmap?" can mean several different things. A team may need to plan training. An executive may want confidence that a problem will be addressed. A sponsor may be asking whether their project has lost priority.

Responding with a row of dates can satisfy the request while leaving the disagreement untouched. The roadmap looks complete, but the organisation has not chosen between competing uses of its money or people.

I would first ask what decision the requester expects the roadmap to support. The answer determines whether they need a delivery schedule, a view of possible investments or a conversation about priorities.

Separate an option from a commitment

A funded project with a known team is different from an idea that needs investigation. Both can appear on a roadmap, provided the difference is obvious.

Use plain labels. Committed work has an agreed scope and resources, subject to stated conditions. Proposed work has a business case or hypothesis but lacks some approval. Discovery work is intended to answer a question, not quietly promise full implementation.

Avoid using the same coloured bar for all of them. Readers will reasonably assume that a dated item is something the organisation intends to deliver. A small footnote about indicative timing is unlikely to undo that impression.

For items further away, describe the conditions that would allow them to start. This can be more useful than a speculative month. "After the account-data decision and availability of the integration team" tells a sponsor what needs attention.

Make the competing choices visible

Take a fictional mid-market business considering two investments. One would simplify customer onboarding. The other would replace an ageing reporting process. Both need the same business analyst and the same integration specialist.

A dates-only roadmap can make both appear feasible by placing their bars beside each other. That presentation has not created capacity. It has hidden a decision about which problem should be addressed first.

Bring the options back to the people who can choose. Starting onboarding first delays the reporting change and requires the current reporting checks to continue. Starting reporting first means the onboarding team keeps its existing process longer. A narrower first release might reduce the conflict, but only if it still delivers something useful.

Ask each sponsor to describe the consequence of waiting, including any workaround. Compare the consequences rather than the enthusiasm of the presentations. Where the evidence is weak, commission a small investigation rather than inventing a precise score that makes the choice look objective.

Use dates according to what is known

Some dates are genuine constraints: a contract ends, a premises move is booked or a business commitment has been made. Others are estimates. Keep those categories separate.

A genuine deadline does not prove the proposed scope can fit before it. Work backwards with the delivery team and identify what must be true. If the necessary decisions, testing or staffing cannot fit, the roadmap should expose the conflict instead of concealing it behind a compressed schedule.

For uncertain work, use a delivery window with named assumptions. Explain what would narrow the window. A technical assessment might remove one uncertainty; confirmed participation from business users might remove another.

Do not turn ranges into a promise of the earliest date. When communicating the roadmap, say how people should use the information. A planning window may be enough to reserve attention without being reliable enough for a public launch announcement.

Give unresolved decisions their own dates

A roadmap can contain decision points as well as delivery points. This is useful when work is waiting for a scope choice, funding approval or a decision about a business process.

Record who decides, what evidence they need and the last responsible decision date. If the decision slips, show which delivery assumptions change. That makes waiting visible as part of the schedule rather than treating it as an unexplained failure by the delivery team.

For the fictional onboarding project, a decision point might be agreement on which customer types belong in the first release. Until that is settled, the team cannot sensibly finalise testing or training. A roadmap that shows only development dates misses the dependency that matters.

Business ownership in a technology project should include these decisions, with enough authority and available time to make them.

Publish the trade-offs alongside the sequence

Once the choices are made, publish a roadmap that reflects them. Include a short note on what was deferred and why. People should not have to discover that their request disappeared by comparing versions of a slide.

Keep an accessible change history. Record a changed assumption or decision, not merely that the roadmap was refreshed. If priorities change every review, examine the decision process rather than polishing the graphics more often.

There should also be a route to challenge the sequence. New information can justify a different order. The challenge needs to identify what has changed and what existing commitment would move, using the same reasoning as the original choice.

A strategy that survives a budget meeting provides that reasoning. The roadmap then communicates it in a form teams can plan around.

The next time someone asks for dates, clarify the choice those dates are expected to settle. You may still need the roadmap. You will be less likely to publish one that promises agreement the organisation has not reached.