What's included
Each wave delivers something usable and each is followed by a benefit review that can change what the next wave contains. That feedback loop is the point:
- Strategy, baseline & governance — Current-state assessment, digital maturity baseline, target operating model, the value case, and standing up the governance rhythm and portfolio office that will outlive individual leaders. Milestone: roadmap and governance approved.
- Wave 1 — foundations — The unglamorous wave that everything else depends on: identity and access, the integration layer, the data platform and governance, cloud landing zone and security baseline. Nothing customer-visible ships here. Milestone: foundations live.
- Wave 2 — core process digitisation — Finance, procurement and HR process automation, workflow and document management, and the retirement of the manual and spreadsheet processes they replace. Milestone: core processes migrated.
- Wave 3 — customer-facing capability — Customer portal, self-service, the mobile experience, unified customer data and journey redesign — deliverable only because wave 1 built the identity and integration underneath. Milestone: customer capability launched.
- Wave 4 — analytics & intelligent automation — Self-service analytics, predictive models and automation of the high-volume decisions, plus the model governance to run them responsibly. Milestone: analytics capability adopted.
- Benefit realisation & sustainment — Post-wave benefit reviews after each wave, adoption and change measurement, capability transfer into the line, legacy decommissioning and the annual roadmap refresh. Milestone: programme transitioned to run.
How to customize it
- Rename the waves to your own capability language, but keep foundations first — that ordering is the substance of the plan.
- Set wave length to whatever your organisation can absorb; six to nine months per wave is common, and shorter waves fail on change capacity rather than delivery.
- Add a benefit review row after every wave, each with a named owner who was there when the benefit was claimed.
- Add legacy decommissioning rows explicitly — transformations that never switch anything off end up funding two estates.
- Insert a governance reset row at each expected leadership change, budget cycle or reorganisation.
- Break each wave into per-workstream rows once its scope is agreed; the single bar is only useful at roadmap level.
Scheduling tips
- Sequence by dependency, not by enthusiasm. The right question for any wave-1 candidate is what breaks in wave 3 if this is not there.
- Measure adoption, not deployment. A platform live with fifteen percent usage has not delivered anything, and only an adoption metric will tell you that in time to act.
- Assume the sponsor changes. Write the value case, the decisions and the benefit baselines down in a form a successor can pick up without you.
- Keep one integration pattern. Waves that each invent their own integration approach create the exact fragmentation the programme was meant to remove.
- Decommission on a date. Legacy retirement that is not scheduled with an owner does not happen, and the savings in the value case depend on it.
Related templates
- Cloud Migration Project Plan Template
- ERP Implementation Schedule Template
- Change Management Plan Template
- SAP S/4HANA Migration Plan Template
- OKR Quarterly Planning Template
- Browse all Gantt chart templates
Frequently asked questions
How long is a digital transformation roadmap?
Typically two to four years across three or four waves. The template runs about three years. Roadmaps shorter than that are usually single programmes; roadmaps longer than that stop being plans and become intentions, so refresh annually rather than extending.
Why do foundations have to come first?
Because customer portals, analytics and automation all depend on knowing who a user is, moving data between systems, and trusting that data. Building them on top of fragmented identity and integration works as a demo and fails as a capability, and the rebuild lands in the next wave.
What is benefit realisation and why after each wave?
It is measuring whether the claimed value actually arrived — cost, cycle time, adoption, revenue. Doing it after every wave rather than at the end means the measurement happens while the people who made the claim are still in post, and the result can change what the next wave contains. Deferred benefit reviews reliably become unfalsifiable.
How do we keep governance going through leadership change?
By making the rhythm and the artefacts institutional rather than personal: a standing portfolio board with a defined cadence, documented decisions, and benefit baselines recorded where a successor can find them. The template includes a governance reset row for exactly this reason.
How does this relate to a single system programme like ERP?
A roadmap sequences several programmes; an implementation plan runs one. If a wave contains an ERP replacement, plan it separately with the ERP implementation schedule or, for an SAP conversion, the SAP S/4HANA migration plan, and keep the roadmap row as a summary bar.
Is the digital transformation template free?
Yes. Free Excel, PowerPoint and CSV downloads, and free online editing with no account and no watermark.