Skip to content
Strategic
Concierge
Book a discovery callBook a call
← Back to Insights

Capability Mapping for Strategists: Build Around One Decision

Capability map focused on one decision

Capability mapping is a decision-scoped blueprint that shows what an organisation must be able to do to deliver its strategy, and it lets leaders prioritise investment and assign ownership quickly. It draws on established modelling conventions from frameworks such as TOGAF and TM Forum, and it works best when scoped tightly to a named decision rather than built as an exhaustive inventory. Strategists, architects and operating leaders use it to see where capability gaps threaten delivery.

TL;DR:

  • Start with a named decision and limit the scope to its needs; top level maps usually contain eight to fifteen capabilities.
  • Use top down mapping when strategic objectives are clear, bottom up when frontline teams know operations best, and a hybrid approach when both perspectives matter.
  • Name capabilities with a business object plus an action, not a team or system name, and give each one a single agreed definition.
  • Map capabilities to value streams and owners; prioritize high importance, low maturity capabilities used across several streams before areas used only once.
  • Assign each capability a named steward, review heat map scores quarterly, and defer deeper breakdowns until a decision requires them; log definition changes.
Strategic-concierge
Build Capability Around Your Strategy
Strategic Concierge helps build, improve and embed the capabilities businesses need to grow, from a launch-ready foundation toward ongoing managed capability.

Table of Contents

What capability mapping is and why it matters

A capability describes what an organisation does, independent of how it does it or who does it. A value stream describes how value actually moves from a trigger to an outcome. The two are related but distinct: capabilities answer “what”, value streams answer “how”, and mapping between them is what turns a static diagram into something you can act on, as the Open Group’s capability and value stream guidance sets out.

A capability map differs from a capability framework or maturity model. The map is a specific, scoped artefact built for your organisation; a framework such as the TM Forum capability map is a reference structure you adapt, and a maturity model is a separate scoring lens you apply once the map exists.

Capability maps typically support three decisions:

  • Portfolio prioritisation: which capabilities deserve investment this cycle.
  • Operating-model change: where ownership, duplication or gaps block a restructure.
  • Capability rationalisation: which overlapping functions can be consolidated or retired.

When to use capability mapping: the decisions and triggers

Capability mapping earns its place when a specific decision is waiting on clarity, not as a background documentation exercise. A strategy refresh is the classic trigger: new objectives need a view of which capabilities must improve, and which are already fit for purpose. Repeated duplication across teams, where two departments quietly build the same thing, is another strong signal. So is running multiple change programmes at once without a shared view of what each one actually touches.

Capability mapping complements, rather than replaces, value-stream and dependency mapping. Guidance on flow engineering and capability mapping recommends sequencing capability work after value-stream and dependency maps, so capability gaps are assessed against real flow constraints rather than in isolation. Our service value stream mapping piece covers the sequencing question in more detail.

Watch for these signals before committing time to a map:

  • Stakeholders disagree on who owns a given function.
  • Change programmes keep rediscovering the same gaps.
  • Investment requests cite capability without naming it precisely.

Pro Tip: If you cannot name the decision the map will inform, delay the workshop until you can.

How to build a capability map: a practical step-by-step method

Start with the decision, not the diagram. A map built to support “which three capabilities should get budget next quarter” needs far less depth than one built to redesign an entire operating model. Limiting initial scope to what that decision needs is what keeps the exercise finishable.

  1. Define the decision and boundary. Write down the decision in one sentence before anyone opens a drawing tool.
  2. Choose your build approach. Top-down works when you have clear strategic objectives and want speed; bottom-up suits organisations where frontline teams understand operations better than leadership does; most mature efforts use a hybrid, starting top-down and validating bottom-up.
  3. Name each capability consistently. Use a business-object plus action pattern (for example “customer onboarding” or “invoice reconciliation”), never a team name or a system name. The UK government’s digital capability model guidance treats ambiguous naming as a leading cause of map failure and duplication.
  4. Write one authoritative definition per capability. A capability with two competing definitions is a governance problem waiting to surface later.
  5. Level the map. Most organisations work in three tiers: L1 (eight to fifteen top-level capabilities), L2 (the detail beneath each, often three to seven per parent), and L3 only where a specific decision demands that granularity.
  6. Harvest evidence. Pull from existing process documentation, interview leads, and cross-check against known pain points rather than starting from a blank page.
  7. Validate quickly. A short review cycle with two or three senior stakeholders catches naming disputes before they become political.
  8. Heat-map maturity. Score each capability on dimensions such as maturity, importance and performance, following the attribute set recommended in capability-based development guidance.

Typical attributes to capture per capability include:

  • A unique identifier and name.
  • A single agreed definition.
  • An assigned steward.
  • A maturity and importance score.

Linking capability maps to value streams, organisation and architecture

A capability map on its own tells you what exists. Cross-mapping is what tells you what matters. Mapping capabilities against value-stream stages shows which capabilities are used once and which are load-bearing across several streams, a technique the TM Forum’s capability map treats as standard practice for portfolio planning.

Capability blocks mapped across value stream stages

Capability-to-organisation mapping does a different job: it overlays who owns each capability against the map itself, which is usually where duplication and ownership gaps become visible. Two teams claiming the same capability, or a capability with no clear owner at all, both point to a decision worth making.

Heat maps feed directly into roadmap construction once both cross-mappings are done:

  • High importance, low maturity capabilities become near-term investment candidates.
  • Capabilities used across many value streams get priority over single-use ones.
  • Duplicated ownership triggers a rationalisation conversation before further investment.

Our RevOps strategy piece covers how these findings typically translate into operating-model decisions.

Participatory systems mapping (PSM) and workshop design

Participatory systems mapping is a collaborative method for building causal system models as directed graphs, run with the people who actually do the work rather than imposed from above. It is particularly useful for capability harvesting because it surfaces constraints and relationships that documentation alone misses, as described in the Springer Nature chapter on PSM.

A workable workshop sequence runs through six stages:

  1. Define the aim, stated as the decision the map will inform.
  2. Set the boundary, deciding what is in scope and what is deliberately excluded.
  3. Choose stakeholders who represent different parts of the organisation, not just leadership.
  4. Run the mapping session itself, capturing factors and relationships as they emerge.
  5. Analyse the output, looking for bottlenecks and ownership gaps.
  6. Agree follow-up actions and a named owner for each.

The CECAN guide to designing a PSM process stresses that these stages are deliberately flexible and should be tailored to context to increase buy-in. To keep sessions productive, limit the starting factors participants suggest, then build submaps for focused analysis rather than one sprawling diagram.

Templates, tools and visual conventions

A minimal capability canvas needs six fields to be useful: a unique identifier, a name following the business-object-plus-action pattern, a single agreed definition, an assigned steward, a link to supporting evidence, and a maturity score.

Visual conventions matter more than they first appear. Tiers (management, core, support) should be visually distinct, heat-map colours should follow one consistent scale across the whole map, and every capability should link back to the evidence and value streams that justify its placement.

  • Use simple diagramming tools for a first decision-scoped map built in days.
  • Move to repository-style modelling tools once the map needs version control, multiple contributors, or links to architecture artefacts.
  • Keep a single source of truth regardless of tool, so stewards are not reconciling competing versions.

Governance, stewardship and turning the map into a roadmap

A capability map that nobody owns decays within a quarter. Assigning a named steward to each capability, along with an effective date for the current definition, keeps the map trustworthy enough to base decisions on.

Keep a deferred decomposition backlog rather than decomposing every branch to the same depth. The capability mapping cookbook makes the point plainly: stop when the map supports the decision, not when every branch looks symmetrical.

  • Review heat-map scores on a fixed cadence, quarterly for most organisations.
  • Feed high-importance, low-maturity findings directly into the next investment round.
  • Keep a change log of definition updates so stewards can trace why a capability moved.

Our guide to sequencing commercial work covers how these findings typically become a prioritised roadmap.

How Strategic Concierge applies a staged approach to capability mapping

Capability work runs through a staged approach: Build, Iterate, Optimise, Embed and Grow. A decision-scoped map is built first, validated against real evidence, then embedded with stewards and a review cadence before it feeds ongoing managed capability. Clients may move from an initial scoped map toward managed support once governance is in place.

Practical perspective from the author: what success looks like

The biggest pitfall we see is scope creep: a map started to support one decision slowly grows until nobody can finish it. The strongest maps stay narrow, get used, and get revised. Treat capability mapping as a discipline you repeat, not a document you file away.

— Chris

How Strategic Concierge can help and how to start

If you are ready to turn a capability map into something your organisation actually uses, a staged approach is built for exactly that. The process typically starts with Foundation to establish a launch-ready baseline, then moves through Flagship or Concierge engagements depending on scope, and into Managed Capability once governance and roadmap work need ongoing support.

Strategic-concierge

FAQ

What is a strategic capability?

A strategic capability is a capability that materially affects an organisation’s ability to deliver its stated strategy, typically one scoring high on importance in a heat-mapped capability map. It is identified through cross-mapping against value streams and organisational priorities rather than by instinct alone.

What is participatory mapping?

Participatory mapping, including participatory systems mapping (PSM), is a collaborative process where stakeholders build a shared model together rather than having one handed to them. The Springer Nature chapter on PSM describes it as building causal system models as directed graphs, which helps surface constraints a single author would miss.

What are the different types of process mapping?

Process mapping commonly includes value-stream mapping, which shows how work flows from trigger to outcome, and capability mapping, which shows what an organisation must be able to do regardless of how the work is currently run. Dependency mapping and organisation mapping are often used alongside both to reveal ownership and flow constraints.

What are examples of business capabilities?

Common examples follow a business-object-plus-action naming pattern, such as “customer onboarding”, “invoice reconciliation” or “product fulfilment”. The UK government’s digital capability model guidance recommends this consistent naming style to keep capabilities comparable across initiatives.

Sources

← Back to Insights