Digital programmes are planned over years and delivered in steps. The plan has to work at both scales.
In brief
- Large programmes succeed when split into releases that each deliver visible value on their own.
- Sequence by dependency, value and adoption capacity, not by the order of a vendor’s product list.
- Write down dependencies, assumptions and decision points so the plan survives a change of sponsor.
- Adoption takes time. Plan training and support alongside the software.
A five-year roadmap looks reassuring on paper. Then the first release slips, priorities change, and the sequence that made sense no longer holds.
The real issue is a plan that cannot bend.
Technology work has dependencies: data before analytics, integration before automation. People have limits: only so much change can be absorbed at once. A plan that ignores either will be delivered in the wrong order.
Three views to keep side by side
| View | Question | Example content |
|---|---|---|
| Business sequence | What should happen first for value reasons? | The problem that hurts most, and the foundations it needs |
| Dependencies | What must exist before the next step? | Shared data, agreed definitions, connected systems |
| Adoption capacity | How much change can people absorb at once? | Training, peak seasons, staff availability |
The roadmap is where these three meet.
Building the plan
1. Split into releases
Each release should be useful on its own and have an owner. If a release only makes sense when the next one arrives, it is too small to stand alone.
2. State dependencies and assumptions
Say what must be true for the next release to proceed: a data source agreed, a system retired, a team trained. Review them at each decision point.
3. Define decision points
Between releases, decide whether to continue, change or stop, based on what was learned. Planned decisions are easier to defend than surprises.
4. Plan for people, not only for systems
Training, support, process change and data cleanup are part of the investment. Plans that leave them out deliver the software and starve its use.
5. Write it down for the next sponsor
Leaders change. A short document that explains the goals, the reasons for the sequence and the current status helps a new sponsor continue instead of restart.
Five mistakes we see repeatedly
- A plan that cannot be changed.
- Releases that deliver nothing until the last one.
- Forgetting running costs once the build is finished.
- No record of the reasons, so new leaders re-open settled decisions.
- Treating adoption as an afterthought.
How we think about it
We build the pieces that multi-year programmes depend on: data foundations, integration and systems that are delivered in stages and have to keep working while the business changes. That experience shapes how we read a roadmap: we look at dependencies and at who must change their routine first.
We can explore a staged plan for your programme with you. What is the first release that would make your people notice a difference?
A plan that can be delivered in steps
A multi-year plan is useful if each release stands on its own and the reasons are visible. Make each step valuable by itself, and the whole plan becomes easier to defend.
Talk to Balerion about shaping a digital roadmap that can be delivered in stages. Email us at talk@balerion.co.th.
