A target operating model without a credible roadmap is just a nice drawing. The roadmap is where you turn the blueprint into a timed sequence of moves that the organization can absorb and actually deliver. This chapter is about how to do that in a way that is ambitious, but not reckless; structured, but not rigid.
We will cover:
- How to sequence work using risk, dependency, and value as your main lenses
- How to design waves, pilots, and MVPs that prove and scale the new model
- How to manage dependencies across technology, organization, process, and people
- How to assemble a clear TOM roadmap with milestones and deliverables that executives can govern
14.1 Principles for Sequencing: Risk, Dependency, and Value
You cannot do everything at once. The question is not whether you will phase; the question is whether you will phase by design or by accident.
Three primary principles should drive your sequencing:
- Risk – avoid catastrophic failure and control your J-curve
- Dependency – respect what must come before what
- Value – bring forward impact where you can, not as an afterthought
You balance these three, rather than maximizing any one of them.
Risk: protect the core and control exposure
Start by identifying:
- “Do not break” areas: critical services, regulatory processes, system-of-record cores
- “Prove it first” areas: completely new patterns (e.g., new journey ownership model, new shared service model)
- “Experiment” areas: lower-risk segments or processes where the business can tolerate learning
You typically want to:
- Avoid starting in the single most complex, high-risk part of the business (e.g., your most regulated or most visible franchise), unless you are forced by regulation or crisis.
- Limit concurrent major shocks in the same area: do not change org, platform, and location simultaneously for the same team unless you must.
- Intentionally design overlap periods and fallbacks: dual running or controlled rollbacks for critical cutovers.
The mindset: you are deliberately buying insurance against catastrophic failure by pacing and scoping your moves.
Dependency: respect the order of construction
Your TOM blueprint contains implicit dependencies:
- Technology and data capabilities that must exist before certain journeys can be redesigned
- Shared services that must be in place before you move volume
- Governance and performance routines that must exist before you decentralize decisions
Foreground them. For example:
- A workflow and integration layer may need to be live before you can roll out new digital journeys at scale.
- A risk framework and data ownership model may need to be clarified before you automate approvals.
- New journey owner and product owner roles may need to be staffed before you push funding and prioritization to them.
You do not need to finish every foundational element before doing anything else, but you must be honest about critical-path items. A good rule:
- If a dependency failure would block multiple waves, move it earlier.
- If a dependency failure would only affect one local initiative, you can allow some parallelism.
Value: show impact early, without mortgaging the future
A roadmap that shows all the benefits in “Year 3+” will die in Year 1. You must deliberately bring forward value:
- Choose a first wave that can deliver visible improvements in cost, speed, or experience within 6–12 months.
- Use those improvements to build belief, free up capacity, and fund later waves.
At the same time, don’t cannibalize the future:
- Avoid “quick fixes” that harden today’s fragmentation or technical debt.
- When you take a tactical step, be clear how it fits into (or will be replaced by) the structural TOM moves.
A simple litmus test for your sequence:
- Is there a credible path to early wins that matter to the P&L and to employees?
- Are the foundational moves sequenced early enough that later waves are not fantasy?
- Is the risk exposure at any given time something your organization can absorb?
If yes, you are in the right zone.
14.2 Designing Waves, Pilots, and MVPs
The roadmap should not be hundreds of projects; it should be a handful of waves, each containing pilots and MVPs that test and scale the new operating model.
Think of the structure as:
- Waves – time-bounded sets of changes with a clear theme
- Pilots – limited-scope trials of key TOM patterns
- MVPs – “minimum viable” versions of new journeys, services, or capabilities
Designing waves
Waves are typically 6–12 months long. Each wave should answer:
- What are we proving or scaling in this period?
- Where will the organization feel the change?
- What must be true by the end of the wave for us to proceed?
Common wave patterns:
- Wave 0 – Mobilize and prove concept
- Establish governance, core team, design standards.
- Run 1–2 focused pilots to prove key TOM elements (e.g., new journey model, a shared service, or a workflow platform).
- Wave 1 – First-scale deployment
- Scale pilots to one or two business units, regions, or journeys.
- Stand up initial hubs or shared services with real volume.
- Begin org changes (macro-structure, critical roles).
- Wave 2 – Broader rollout and consolidation
- Extend to more regions, segments, or products.
- Drive consolidation (locations, vendors, legacy systems).
- Embed new performance routines and culture shifts.
- Wave 3+ – Optimization and extension
- Rationalize residual legacy pockets.
- Tackle more complex or peripheral areas.
- Optimize and fine-tune, including next-generation improvements.
You do not need exactly three waves, but you do need clearly labeled phases with distinct objectives and end-states.
Pilots: where and how to test
Pilots are not random experiments; they are controlled tests of TOM hypotheses:
- “This is how journey ownership will work.”
- “This is how the shared service will interface with BUs.”
- “This is how the workflow platform will orchestrate the process.”
Choose pilot areas based on:
- Representativeness: similar enough to wider business that lessons travel.
- Manageability: not the most complex or political environment.
- Leadership: local leaders open to change and capable of partnering well.
- Risk: important enough that results matter, but not existential if you stumble.
Define pilots tightly:
- Clear objectives and success metrics (operational and experience).
- Fixed time window (e.g., 3–6 months) with explicit exit criteria: either scale, adjust, or stop.
- Documented learnings: what worked, what broke, what must change in the TOM design.
Avoid the trap of “perpetual pilots” that never scale and never die. A pilot without an explicit decision point is just a small, permanent variant.
MVPs: minimum viable TOM implementations
An MVP is not sloppy work; it is the smallest coherent version of the new model that can operate and be learned from.
Examples:
- For a journey redesign:
- MVP = new E2E process + basic workflow support + clear owner + simple KPI set, for one segment or region.
- Not MVP = just a new form or script with no change in ownership, tools, or KPIs.
- For a shared service:
- MVP = one or two processes moved, standard work defined, basic SLA and governance in place, small team and location live.
- Not MVP = “planning to centralize” with no volume moved.
- For analytics-enabled decisioning:
- MVP = one use case (e.g., lead prioritization) embedded in one front-line tool with clear outcome metrics.
- Not MVP = isolated dashboard that no one uses.
In your roadmap, tie MVPs to waves:
- Wave X: MVP of journey Y in country Z
- Wave X+1: extend MVP to additional segments; deprecate old variants
- Wave X+2: fully standardize and integrate across regions
This approach keeps the TOM real and grounded rather than conceptual.
14.3 Managing Dependencies: Tech, Org, Process, and People
Sequencing is mostly about managing dependencies on purpose. Left unmanaged, dependencies show up as surprises: “we can’t go live because IT isn’t ready,” “we reorganized but processes didn’t change,” and so on.
Useful categories:
- Technology and data
- Processes and policies
- Organization and governance
- People and change
- Vendors and regulators
Technology and data dependencies
Common dependency failures:
- Front-end journeys redesigned before integration or workflow capabilities exist.
- Multiple initiatives competing for the same system teams or release windows.
- Data models are not aligned, so analytics and reporting cannot be trusted.
To manage:
- Keep a simple tech dependency map: which TOM initiatives depend on which platforms, integrations, and data changes.
- Align TOM waves with major tech milestones (e.g., platform releases, decommission dates).
- Protect capacity in architecture, integration, and data teams for TOM-critical work.
Your roadmap should make it obvious:
- Which tech capabilities are critical paths for each wave.
- Where temporary solutions will be used (and later removed), and where you must wait for industrial-strength platforms.
Process and policy dependencies
Process and policy changes often lag structure and tech, causing friction:
- New roles but old approval matrices.
- New locations but old escalation paths.
- New systems with old paper-based policies.
In the roadmap, for each major TOM move, ensure you have:
- A list of policies and procedures that must be updated in that wave.
- Owners and timelines for changes and communications.
- Alignment with risk, legal, and compliance to avoid last-minute blocks.
Treat process/policy changes as real deliverables, not “admin to catch up later.”
Organization and governance dependencies
You cannot ask people to act in new roles that do not exist yet, or hold them accountable for KPIs that are not in their scorecards.
For each wave:
- Confirm which org changes must be in place before cutovers (e.g., creation of journey owners, heads of shared services, platform leads).
- Align governance forums and decision rights ahead of time (e.g., investment boards, product councils, risk committees).
- Time changes so that leaders are in roles before they need to make TOM-related decisions.
You want to avoid:
- Launching a new shared service without a clear service owner and governance forum.
- Pushing responsibilities into regions or BUs that do not yet have the leadership bench.
People and change dependencies
Capability and change readiness are often the hidden blockers.
For each wave, ask:
- What skills must be in place to operate the new model (e.g., journey leadership, agile teams, automation developers, new risk skills)?
- What training and coaching must happen before go-live?
- Where will change fatigue be highest, and how will you pace changes there?
Integrate capability-building milestones into the roadmap, not as a side plan.
Vendors and regulators
Vendor and regulatory timelines can impose hard constraints:
- Contract notice periods and transition durations.
- Regulatory approval cycles and blackout periods (e.g., year-end reporting).
Your roadmap should:
- Show when key contracts will change and where dual-running with vendors is required.
- Reflect regulatory calendars: when exams, reporting peaks, or known rule changes will hit.
You are aiming for an integrated view where, for each major TOM milestone, you can see:
- Tech readiness
- Policy and process readiness
- Org and people readiness
- Vendor / regulatory readiness
If any of these are red, you either adjust timing or change the scope.
14.4 The TOM Roadmap: Structure, Milestones, and Deliverables
Finally, you need to turn all this into something that can be governed and communicated. A good TOM roadmap is:
- Visual and simple enough for an executive to grasp in minutes
- Detailed enough underneath to run as a real program
- Structured around waves, not just workstreams
A practical structure for the roadmap:
1. One-page roadmap view
This is the slide the CEO and board will actually remember. It typically shows:
- Time across the top (quarters or half-years over 2–4 years)
- Waves or phases as horizontal bands (Wave 0, Wave 1, Wave 2, etc.)
- Under each wave:
- Major journey or business changes (e.g., “SME Lead-to-Cash redesign in Top 5 markets”)
- Major platform or tech milestones (e.g., “CRM rollout to Retail,” “Shared workflow layer live in Region A”)
- Major structural moves (e.g., “Operations hub 1 and 2 live,” “New shared service for Finance in place”)
This view should show logic and pacing at a glance: where disruption is concentrated, where benefits land, and how foundations are built.
2. Wave charters
For each wave, create a 1–2 page wave charter that answers:
- Objectives: what this wave is meant to achieve (in TOM and value terms).
- Scope: which journeys, BUs, regions, functions, and systems are in.
- Key initiatives: a short list of major changes inside the wave (not every task).
- Milestones: 4–8 key dates (design sign-offs, build completion, go-lives).
- Benefits: what you expect to see by the end of the wave (leading indicators and, where possible, P&L impact).
- Risks: top risks specific to this wave and how you will mitigate them.
This gives wave leads and sponsors clear accountability.
3. Initiative-level plans (selective)
Not every activity needs a separate Gantt, but the following usually do:
- Major platform builds or replacements
- Shared service / hub stand-ups and large migrations
- Significant org restructurings
- High-stakes journey redesigns (especially in regulated areas)
For these, maintain:
- 1-page initiative plan with timeline, dependencies, and resourcing
- Clear handoff points to other initiatives (e.g., when tech hands over to operations)
These plans live one level down from the central TOM roadmap but must align with it.
4. Milestones and stage gates
Your roadmap should incorporate stage gates—decision points where you confirm conditions are met before moving on.
Examples:
- Before scaling a pilot to more regions:
- MVP stability and performance within defined thresholds
- User adoption above a threshold
- Key defects resolved or workarounds clearly documented
- Before migrating major volume to a new shared service:
- SLAs met at pilot volume
- Knowledge transfer completed
- Control and compliance checks passed
Make these gates explicit in the roadmap, not implicit assumptions.
5. Deliverables calendar
Behind the visual view, maintain a simple deliverables calendar:
- Design deliverables (e.g., finalized E2E blueprints, org designs, control libraries)
- Build and configuration deliverables (e.g., system configuration, integrations, test completions)
- Change deliverables (e.g., training completed for certain groups, comms milestones)
- Post-go-live deliverables (e.g., benefit tracking reports, lessons learned reviews)
This is what program managers will actually use to run the transformation. From an executive’s point of view, the key is that:
- Each quarter, there is a small number of meaningful deliverables that can be discussed and judged.
- Those deliverables are clearly linked to TOM progress and value, not just project activity.
When you put it all together, the TOM roadmap becomes the operational contract between design and reality: what you will do first, where you will prove and then scale, how you will manage risk and dependencies, and when the organization can expect to see results.
