Strategy, Roadmaps, and Target Operating Models
By the end of this module you will be able to:
- Apply the MIT CISR operational backbone versus digital platform positioning model to assess an organisation's digital strategy
- Construct a Now/Next/Later roadmap and distinguish it from a project plan
- Identify the Target Operating Model dimensions (people, process, technology, data, governance) and explain the role of each in a digital transformation business case
Real-world transformation · GDS · GOV.UK platform (2011-2016)
A strategy that cannot be drawn on one page is probably not a strategy.
In 2010, Martha Lane Fox's "Directgov 2.0" report found that the UK government operated 750 separate websites. Citizens had to navigate dozens of unconnected domains to access government services. The Government Digital Service (GDS) was created in 2011 with a specific, bounded strategy: one domain, one design system, one API standard.
GDS published a public Now/Next/Later roadmap. Citizens and journalists could see which services were planned for migration, which were in progress, and which had been completed. By 2016, 1,800 government services had moved to GOV.UK. The strategy worked because it was specific, visible, and measurable.
The strategy succeeded for two reasons that are frequently absent from large transformation programmes. First, it set a clear scope boundary: one domain, not all of government IT. Second, the roadmap showed progress publicly, creating accountability that internal plans never create. This module covers the frameworks that make digital strategy legible: MIT CISR positioning, Now/Next/Later roadmapping, Target Operating Models, and change management.
A strategy that cannot be drawn on one page is probably not a strategy - it is a wish list.
With the learning outcomes established, this module begins by examining digital strategy frameworks: mit cisr positioning in depth.
12.1 Digital Strategy Frameworks: MIT CISR Positioning
MIT Center for Information Systems Research (CISR) has conducted over 30 years of research on how organisations create value from digital technology. Their positioning model identifies two foundational investments that underpin digital strategy, and which an organisation should prioritise depends on its current state.
An operational backbone is the integrated, stable core of an organisation's technology estate: the ERP systems, master data management, core HR and finance systems, and the integrations between them. An organisation without a reliable operational backbone cannot build digital services on top of it: the data is inconsistent, the processes are manual, and every new system requires bespoke integration. MIT CISR research found that 65% of companies they studied had not fully established their operational backbone before launching digital platform investments.
A digital platform is the set of capabilities that enables an organisation to build and scale digital customer experiences rapidly. APIs, shared data services, customer identity management, and cloud infrastructure are components of a digital platform. A digital platform can only deliver value if built on a reliable operational backbone.
The strategic question is sequencing: organisations that have not established their operational backbone should invest in it before scaling digital customer experiences. Organisations that have a reliable backbone should invest in the digital platform layer. Building a compelling customer app on top of inconsistent back-office data creates a different kind of problem: a digital front end that surfaces operational failures to customers in real time.
GDS was able to build GOV.UK because the UK government's core operational systems (benefits payment, tax collection, licensing) already worked reliably. GOV.UK digitised the access layer; it did not fix the back-office systems. This is why the GDS strategy was achievable in five years.
Understanding where you are in the operational backbone / digital platform sequence tells you what to prioritise. Section 12.2 covers the roadmap format that communicates those priorities without overpromising - the Now/Next/Later model.
12.2 Now/Next/Later Roadmap Construction
A product roadmap is a communication tool that shows the strategic direction of a digital product or programme. It is not a project plan. A project plan shows tasks, resources, and timelines. A roadmap shows priorities and the intended order of progression at a strategic level.
The Now/Next/Later format (developed by product strategy consultancy Intercom and popularised by Janna Bastow of ProdPad) organises initiatives into three columns based on strategic priority rather than calendar date. Now contains what the team is actively working on. Next contains what is planned after current work is complete. Later contains future possibilities that are not yet committed.
The advantage of Now/Next/Later over Gantt chart roadmaps is that it is honest about uncertainty. Committing a specific date to a Later initiative is a lie: the organisation does not yet know what "Now" will uncover, how long it will take, or what new information will change priorities. A Now/Next/Later roadmap shows direction without false precision.
GDS published a public quarterly roadmap showing which GOV.UK services were in each column. This transparency had an accountability effect: teams could not indefinitely defer migrations because the public could see what was planned and what was completed.
“A roadmap is a plan that matches short-term and long-term business goals with specific technology solutions to help meet those goals.”
Gartner IT Glossary - Technology Roadmap Definition
The critical word in this definition is 'goals', not 'tasks'. A roadmap aligns technology direction with business objectives. When a roadmap becomes a list of features and release dates without connecting to business outcomes, it has become a delivery plan rather than a strategy document. GDS's roadmap showed service migrations per quarter; the business outcome (one domain, accessible services) was always visible alongside the activities.
Common misconception
“A roadmap is a project plan.”
A roadmap shows strategic direction and priorities, not sprint tasks or resource assignments. A project plan specifies who will do what by when. A roadmap communicates where the organisation is going and in what order. Roadmaps tolerate uncertainty; project plans eliminate it. When teams turn roadmaps into multi-year Gantt charts with specific release dates for each feature, they produce false certainty that erodes trust when plans inevitably change.
A roadmap shows the sequence of change. A Target Operating Model (TOM) describes the destination state across people, process, technology, data, and governance. Section 12.3 covers how to design one.
12.3 Target Operating Model Design
A Target Operating Model (TOM) describes how an organisation will operate once a digital transformation is complete. It is not a system architecture diagram. It addresses five dimensions that must be designed together, because a technology change without corresponding people and process changes produces a failed transformation.
- People: which roles exist, which skills are required, how teams are structured, and which capabilities are insourced versus outsourced. A cloud migration that requires 15 new cloud engineers but doesn't include a hiring and training plan is not a complete TOM.
- Process: the target-state business processes that the technology will enable. A new payments system can support multiple process designs; the TOM specifies which process the organisation is choosing.
- Technology: the technology estate (systems, platforms, integrations) in the target state. Reference Architecture Building Blocks rather than specific vendor products to avoid premature procurement commitments.
- Data: information flows, data ownership assignments, data governance policies, and master data management arrangements. Many transformation failures are data failures: the new system cannot be populated because the legacy data is too poor quality to migrate.
- Governance: how decisions are made, how policies are enforced, how performance is measured, and who is accountable for each capability. Governance without accountability is compliance theatre.
The TOM defines the target state. Securing the investment to reach it requires a business case that quantifies both cost and value. Section 12.4 covers how to build one using the HM Treasury Green Book methodology.
12.4 Business Case Construction
A digital transformation business case must quantify benefits, not just costs. The UK government's HM Treasury Green Book provides the standard methodology for public sector investment cases: Net Present Value (NPV), payback period, and benefits realisation planning.
NPV accounts for the time value of money: a benefit of GBP 1 million received in year 3 is worth less than GBP 1 million today, because the organisation could have invested the GBP 1 million for two years. The HM Treasury Green Book specifies a 7% central discount rate for public sector investments. A positive NPV means the investment is financially justified.
Benefits realisation management recognises that benefits do not occur when a system goes live; they occur when the people and processes enabled by the system change their behaviour. A new digital case management system does not reduce processing time the day it launches; it reduces processing time after staff are trained, processes are redesigned, and the old system is retired. Benefits realisation plans identify which benefits depend on which behaviour changes, and assign ownership to specific individuals.
The McKinsey Global Institute found in 2016 that large IT projects (budget over GBP 15 million) run 45% over budget and 7% over time on average, while delivering 56% less value than predicted. Benefits realisation planning is the discipline that addresses the 56% value shortfall, not the budget or schedule overrun.
A business case secures funding. Investment without managed change delivers technology that nobody uses. Section 12.5 covers ADKAR and Kotter - the two models most commonly applied to digital transformation change management.
12.5 Change Management: ADKAR and Kotter
Prosci's research on change management, conducted since 1998 with over 9,000 projects, consistently finds that ineffective change management is the primary cause of failed digital transformations, ahead of technology failure and budget overrun. Change management is not training and communications; it is the structured process of moving people from current-state behaviour to target-state behaviour.
The ADKAR model is a sequential model of individual change. People must pass through each stage in order; jumping to training without building awareness and desire produces training that is not applied:
- Awareness - understanding that change is needed and why
- Desire - choosing to support and participate in the change
- Knowledge - knowing how to change and what the new state looks like
- Ability - demonstrating new behaviours and skills in practice
- Reinforcement - sustaining the new behaviours so they become permanent
John Kotter's 8-step change model (published in Leading Change, 1996) addresses organisational-level change. Kotter's model is frequently applied to the leadership and communication dimensions of a digital transformation programme:
- Create urgency - make the case for change compelling and real
- Form a guiding coalition - build a team with the authority and credibility to lead
- Develop vision and strategy - define what the changed organisation looks like
- Communicate the vision - embed it in every interaction and decision
- Empower broad-based action - remove barriers that block people from changing
- Generate short-term wins - create visible early successes to build momentum
- Consolidate gains - use early wins to drive further change
- Anchor changes in culture - embed new behaviours in organisational norms
GDS's transformation succeeded in part because it had a clear guiding coalition (Cabinet Office, Minister for the Cabinet Office, GDS leadership) and generated visible short-term wins (the first GOV.UK service launches in 2012) before attempting the full 1,800-service migration.
Common misconception
“Digital strategy is separate from business strategy.”
A digital strategy that is separate from the business strategy is a technology project, not a strategy. GDS's strategy was not 'improve government websites'; it was 'make it simpler, clearer, and faster to access government services'. The digital platform was the mechanism, not the strategy. MIT CISR research found that organisations in which the chief digital officer is responsible for digital strategy rather than the CEO consistently underperform organisations in which digital is the CEO's agenda.
“The number one success factor in digital transformation is an engaged executive sponsor who actively champions the change.”
Prosci, Best Practices in Change Management, 11th Edition - Chapter 2: Contributor to Success
Prosci's 11th edition synthesised data from over 9,000 change management projects. The finding that executive sponsorship is the primary success factor (appearing in the top three across all 11 editions of the study) directly contradicts the common belief that digital transformation is primarily a technology problem. The technology is usually the smallest risk; the organisational change is usually the largest.
A large retailer has multiple ERP systems with inconsistent customer data, no master data management, and manual reconciliation processes across 12 regional offices. Their CDO proposes investing in a new customer-facing mobile app. A senior architect argues they should invest in the operational backbone first. Who has the stronger position according to MIT CISR research?
A government department produces a digital transformation roadmap showing 47 initiatives with specific delivery dates for each over the next three years. A CDIO review flags concerns. What is the most likely concern?
Prosci's ADKAR model describes Awareness, Desire, Knowledge, Ability, and Reinforcement. A digital transformation team has invested heavily in training (Knowledge stage) for a new case management system, but adoption is low six months after launch. According to ADKAR, what is the most likely diagnostic?
Key takeaways
- MIT CISR research shows that digital platform investments only deliver value when built on a reliable operational backbone; organisations that skip this sequence produce digital experiences that surface back-office failures to customers.
- The Now/Next/Later roadmap format communicates strategic direction without false precision; it is honest about uncertainty in a way that multi-year Gantt charts are not.
- A Target Operating Model must address people, process, technology, data, and governance simultaneously; technology changes without corresponding people and process changes produce failed transformations.
- Business cases for digital transformation must include benefits realisation plans that assign ownership of specific benefits to specific people and identify which behaviour changes each benefit depends on.
- Prosci's ADKAR model is sequential: Awareness and Desire must be established before training (Knowledge) is delivered; skipping these stages is the most common cause of poor technology adoption.
- A digital strategy that is separate from the business strategy is a technology project; digital strategy must be owned at CEO level to have the organisational authority needed to drive genuine transformation.
Standards and sources cited in this module
Ross, J., Weill, P. and Robertson, D., Enterprise Architecture as Strategy
Harvard Business Review Press, 2006
MIT CISR source for operational backbone versus digital platform positioning model. Referenced throughout Section 12.1.
Kotter, J., Leading Change
Harvard Business Review Press, 1996 (updated 2012)
Source for Kotter's 8-step change model referenced in Section 12.5 and the DragSortChallenge.
Prosci, Best Practices in Change Management, 11th Edition
Prosci Inc., 2023
Primary source for ADKAR model and executive sponsorship findings cited in Section 12.5.
HM Treasury, 2022 revision
UK government standard methodology for investment appraisal including NPV calculation and 7% discount rate referenced in Section 12.4.
GDS, Government Transformation Strategy 2017-2020
gov.uk/government/publications
Source for GOV.UK transformation case study including roadmap approach, 1,800 services figure, and Martha Lane Fox report context.
McKinsey Global Institute, Delivering Large-Scale IT Projects
October 2016
Source for 45% budget overrun and 56% value shortfall statistics cited in Section 12.4.
Strategy provides direction. The next module examines one of the hardest problems in digital strategy: sharing data across organisational boundaries while maintaining trust, privacy, and regulatory compliance.
Module 12 of 15 in Practice and Strategy