The Roadmap That Outran the Release Train
A payments team has a six-month roadmap showing three releases. Release 1 (fraud scoring) shipped on schedule. Release 2 (merchant self-service portal) is now four weeks late because a regulatory review of data residency was added mid-flight, and two of the four developers were pulled onto a security incident for eleven working days. The roadmap still shows Release 3 (open banking integration) starting in two weeks with the same four developers, who are already at capacity. The sponsor wants the dates held because a marketing campaign is booked against Release 3. The change lead has been asked to 're-baseline the roadmap' by Friday.
1. What is the change lead's most defensible first action, and why?
Read the worked answer
The change lead should not silently re-baseline dates to protect the campaign. The first action is to make the constraint visible: Release 3 cannot start in two weeks with the same four developers who are still finishing Release 2, so the roadmap's dependencies are broken, not merely its dates.
Reasoning:
- A roadmap is a forecast of value delivery under assumptions. When an assumption (team capacity, regulatory scope) fails, the roadmap must be revised against evidence, not against a booked campaign.
- The change lead's job is to surface the trade-off so the sponsor can decide with full information: hold Release 3 and accept campaign risk, cut Release 3 scope, or add capacity.
- Re-baselining without flagging the capacity conflict hides the problem and guarantees a second miss.
So: document the actual capacity and the regulatory scope change, present two or three options with consequences, and let the sponsor choose. The change lead owns the honesty of the roadmap, not the marketing calendar.
2. How should the change lead treat the regulatory review that appeared mid-flight?
Read the worked answer
Treat it as a legitimate scope change with a real cost, not as an anomaly to absorb. The review of data residency affects Release 2's design and therefore its timeline, and it may constrain Release 3's open banking integration too.
Practical handling:
- Record it as an explicit assumption change on the roadmap, with the eleven lost developer-days and the review effort shown as impact.
- Ask whether the review is a hard gate (cannot ship without it) or a parallel track. If it is a gate, Release 2's date moves and Release 3's start is contingent on it.
- Check whether the same review applies to Release 3 now, so the roadmap does not repeat the surprise.
The judgement point: changes that arrive mid-flight are normal, but absorbing them invisibly is what breaks roadmaps. The change lead makes the cost explicit so future planning reflects it.
3. The sponsor insists the Release 3 date is fixed. What should the change lead propose?
Read the worked answer
Accept the fixed date as a constraint and work backwards to what is actually deliverable by then, rather than pretending the full scope fits.
Options to put to the sponsor:
- Reduce Release 3 scope to a minimum viable integration (fewer banks, fewer transaction types) that the current team can deliver by the date.
- Sequence: deliver a thin Release 3 slice on the date and defer the rest, with the deferred items shown on the roadmap as a follow-on.
- Add capacity (contractors or a loaned developer) and state the onboarding cost and the quality risk of a team that has not worked on the codebase.
Each option names what is sacrificed. The change lead's value is in framing the choice honestly: a fixed date plus fixed scope plus fixed team is three constraints that cannot all hold. The sponsor picks which one bends; the change lead records the decision and its consequences on the roadmap.