Building The Model

1. Capability Assessment

What it is: a structured evaluation of how mature each capability is and how much it matters to the strategy — the evidence base everything else in this domain is built on. It is scoring against two axes, maturity and importance, not an opinion survey.

What you need to do:

1. Confirm or build the capability map first. An assessment scored against an undefined or contested map produces numbers nobody trusts.
2. Agree a maturity scale before scoring anything — for example ad hoc, repeatable, defined, managed, optimised — so every capability owner is judged against the same yardstick.
3. Agree an importance scale tied explicitly to the strategy and value proposition, not to how persuasively a function argues its own case.
4. Gather evidence from more than one source: capability owner interviews, performance and incident data, audit findings, and value-stream feedback. A score built on a single workshop is a guess with a number attached.
5. Score every capability on both axes and plot the results on a maturity-versus-importance grid to see where priority actually sits.
6. Validate the scores with capability owners and governance before treating them as final. An assessment nobody recognises will not survive contact with target operating model design.

Plotting scored capabilities on this grid is what turns an assessment into a priority list: invest where importance is high and maturity is low.

Inputs: the capability map, performance and incident data, prior audit or assurance findings, and access to capability owners and their teams.

Outputs: a scored capability map, a prioritised view of where investment matters most, and the evidence base for the current operating model baseline.

Watch for: scoring capabilities on aspiration rather than evidence, and skipping owner validation — an unvalidated score gets challenged the first time it is used to justify investment.

2. Current Operating Model

What it is: the as-is state, described honestly across every design dimension — not the org chart, and not what the last transformation programme said should be true by now.

What you need to do:

1. Describe the current state across all six design dimensions — process, organisation, people and skills, information and data, technology, and locations and sourcing — for each capability in scope, in enough detail to support real comparison later.
2. Use the capability assessment as your evidence base. Maturity scores and the notes behind them become the substance of the baseline, not a separate exercise run from scratch.
3. Document the model as it actually operates, including the informal workarounds and shadow processes that never made it into a process manual — this is usually where the real pain and the real risk concentrate.
4. Capture root causes behind the pain points capability owners report, not just the symptoms they mention first.
5. Get explicit sign-off from capability owners that the baseline is a fair description of today. An unchallenged baseline is not the same thing as a validated one.

Inputs: the scored capability map, workshops and interviews with capability owners, existing process documentation and where it diverges from practice, technology and data inventories.

Outputs: a documented current operating model across all six dimensions, validated and owned by the people who actually run it — the from-position for every gap that follows.

Watch for: baselining the model your last transformation programme intended to deliver, rather than the one that is actually operating today.

3. Target Operating Model

What it is: the designed future state, shaped by the design principles and specified to the same level of detail as the current state, so the two can genuinely be compared.

What you need to do:

1. Design forward from strategy and the ranked design principles, not backward from the current state. Patch-and-extend thinking produces a slightly tidier version of today, not a target operating model.
2. Specify the target across all six design dimensions, including capabilities the strategy requires that do not exist yet. A target expressed only as a new org chart is a reorg, not an operating model design.
3. Test every design choice against the ranked design principles from the Strategy & Direction domain. Where a choice sits uneasily against a principle, either change the choice or make the exception and its cost explicit.
4. Attach a horizon or date to the target. An undated target operating model is a mood board, not a plan anyone can be held to.
5. Validate the target with governance and with the leadership who will own it before it becomes the reference point for gap analysis. A target nobody has agreed to is a design document, not a target.

Inputs: strategy, the ranked design principles, the capability assessment, and leadership's appetite for pace and risk.

Outputs: a dated target operating model, specified across all six design dimensions, tested against the design principles and agreed by the leadership who will own it.

Watch for: a target that is detailed on structure and silent on process, data, technology, and sourcing — the dimensions that usually decide whether the target is actually deliverable.

4. Gap Analysis

What it is: the honest, structured distance between the current and target operating models — sized and characterised per dimension and per capability, not judged as a single global verdict.

What you need to do:

1. Compare current to target dimension by dimension and capability by capability. A single "how far are we" conversation hides exactly the detail the roadmap will need.
2. For every gap identified, record what is missing or different, a rough size of the effort involved, the risk it carries, and what it depends on.
3. Look specifically for gaps that cut across dimensions. A process change that also needs a skills change and a technology change is one coordinated piece of work, not three separate backlog items.
4. Prioritise using the same maturity-and-importance lens from the capability assessment: close the gaps that matter most to the strategy first, not the ones that are simply easiest to start.
5. Write down the gaps you are explicitly choosing not to close in this cycle, and why. An unstated gap has a way of resurfacing later as an audit finding or an incident.

Inputs: the validated current operating model, the agreed target operating model, and the prioritisation logic from the capability assessment.

Outputs: a sized, dependency-aware list of gaps per dimension and capability, including the gaps knowingly deferred and the reasoning behind that choice.

Watch for: sizing gaps in isolation from their dependencies — a gap that looks small on its own can be the blocking dependency for several others.

5. Transition Roadmap

What it is: the time-phased sequence that turns a list of gaps into a route the organisation can actually walk — defined transition states, each one stable enough to pause on.

What you need to do:

1. Sequence gaps by dependency first and value second — never by enthusiasm, and never simply in the order they happened to be raised. A simple prioritisation technique such as MoSCoW or an impact/effort matrix can structure this conversation, provided it stays subordinate to the dependency mapping.
2. Define named, stable intermediate transition states rather than a single leap from current to target. Each state should be one the organisation could genuinely operate in for a period if delivery paused.
3. Identify foundational changes that need to go first even when they are less visible than the changes people are actually asking for — an identity or data platform often has to land before the process automation that depends on it can.
4. Align the roadmap's horizon and stages to the organisation's actual funding cycles and governance cadence, so each stage can be resourced when it needs to be, not only in principle.
5. Stress-test the sequence against business-as-usual capacity. A roadmap that assumes capability owners have spare capacity to also run the change is a roadmap that will slip at the first busy quarter.

Inputs: the sized and dependency-mapped gap analysis, funding and governance cycles, and a realistic view of business-as-usual capacity.

Outputs: a time-phased roadmap of named transition states, sequenced by dependency and value, ready to be resourced through the change portfolio.

Watch for: a roadmap built to look achievable on a slide rather than to survive the capacity constraints of the teams who actually have to deliver it.

6. Change Portfolio

What it is: the governed, funded collection of initiatives that actually deliver the roadmap — traceable, in both directions, to the gaps it exists to close.

What you need to do:

1. Map every initiative in the portfolio to the specific gap or gaps it closes, and check the reverse too. Any gap in the roadmap without a funded initiative behind it is a gap that will not close on its own.
2. Set up portfolio governance: prioritisation against the same criteria used throughout, funding gates, and benefits tracking against the performance measures defined in the Governance & Performance domain.
3. Keep architecture involved through delivery, not only at design. Initiatives drift, and someone needs to keep checking delivered change back against the target operating model and its design principles.
4. Feed delivered outcomes back into performance measurement, and let that evidence open the next capability assessment. This is the point where the journey becomes a loop rather than a one-off programme.

Inputs: the transition roadmap, funding and governance mechanisms, and the performance measures the model is judged against.

Outputs: a funded, governed set of initiatives traceable to the gaps they close, and a continuous flow of delivered outcomes back into performance measurement and the next capability assessment.

Watch for: a portfolio that has drifted from the roadmap it was meant to deliver, with initiatives that no longer trace back to any specific gap.