Skip to content

Capability–Case Crosswalk

Artifact — instantiates Target-Complete Mapping Design

Reconciles a catalog of what the organization can do against the list of cases it must serve, exposing prioritized cases that no capable, adequately-resourced provider actually covers.

Capability–Case Crosswalk sets an organization's catalog of capabilities (the valid sources — what it can actually do) beside the list of cases it must serve (the targets), and reconciles the two so every required case is matched to at least one capability that can genuinely deliver it. Its defining move is reconciling two independently-maintained catalogs: capability inventories and case lists are usually owned by different teams and drift apart, so the crosswalk's value is catching prioritized cases that fall in the seam — a case everyone assumed "someone" covers but no capability with real capacity actually does. It weights cases by priority, so the gaps it exposes arrive already triaged by what matters rather than as a flat list.

Example

A bank maintains 40 business capabilities — KYC onboarding, dispute resolution, wire recall, and so on — and the next roadmap names 65 customer use-cases it must serve. Crosswalking the two, 61 use-cases map cleanly to a capability. Four do not, including "recall an erroneous international wire within 24 hours," which Product had assumed Operations owned and Operations had assumed Payments owned — a case lost in the ownership seam between two catalogs. Two further use-cases map only to a capability already flagged over-subscribed: mapped on paper, but with no spare capacity to actually take the load. Weighting by priority pushes the wire-recall gap to the top of the remediation list. (Illustrative; the bank and figures are not drawn from any real institution.)

How it works

What distinguishes it is two-catalog reconciliation with a capacity qualifier and a priority lens. Rows are the required cases, columns the capabilities; a match counts only when the capability both fits the case and has capacity for it. Two gap shapes then fall out: high-priority rows with no qualifying match (the actionable holes) and matched-but-over-capacity cells (latent holes that will fail under real volume). Priority weighting orders both so attention goes where it counts.

Tuning parameters

  • Match criterion — nominal fit ("this capability is relevant") versus qualified fit (relevant and has spare capacity). Qualified matching is what surfaces the latent, over-subscribed gaps.
  • Catalog granularity — coarse capabilities versus fine sub-capabilities. Finer columns catch partial coverage a coarse column would paper over.
  • Priority scheme — how cases are weighted — by revenue, regulatory exposure, or risk. This dial decides which exposed gaps get worked first.
  • Reconciliation cadence — how often the two catalogs are re-crosswalked as either drifts, since a stale catalog is where the seam gaps hide.

When it helps, and when it misleads

Its strength is catching cases lost in the ownership seams between teams, and separating "mapped" from "mapped to something that can actually deliver." Its weakness is that a crosswalk is only as current as its two source catalogs: a stale capability list hides recently-lost capacity, and a stale case list misses newly-required targets. The classic misuse is mapping a case to a loosely-relevant capability to claim coverage without checking the capability can bear it — coverage on paper, a gap in practice the first time real volume arrives. The discipline that guards against it is to require a capacity check on every match — handing the deep throughput question to Source Capacity Load Test — and to re-reconcile the catalogs on a set cadence rather than once at planning time.[1]

How it implements the components

Capability–Case Crosswalk realizes the source-inventory-and-fit side of the archetype — the components that decide whether a capable provider exists for each prioritized case:

  • valid_source_space — the capability catalog: the inventory of sources eligible to serve cases.
  • feasibility_and_capacity_check — a lightweight fit-and-capacity test so a match means the capability can actually bear the case, not merely relate to it.
  • target_priority_weighting — the weighting that ranks cases so exposed gaps are ordered by importance, not treated as a flat list.

It does not stress-test a capability's true throughput under production load — that is Source Capacity Load Test — nor enumerate the case list in the first place, which is Scenario Enumeration Workshop; the crosswalk reconciles catalogs that already exist.

  • Instantiates: Target-Complete Mapping Design — the crosswalk is the reconciliation that guarantees each prioritized case has a capable provider.
  • Consumes: Scenario Enumeration Workshop supplies the case list; Source Capacity Load Test supplies the deep capacity data behind each match.
  • Sibling mechanisms: Source Capacity Load Test · Scenario Enumeration Workshop · Bipartite Coverage Matrix · Set-Cover Analysis · Uncovered-Target Triage

References

[1] Capability-based planning — the practice of managing an organization around an explicit catalog of capabilities and mapping demands (cases, missions, requirements) onto it. The crosswalk is the coverage check inside that discipline: it is where a capability catalog and a demand list are held against each other to find demands no capability answers. ↩