---
title: Contextualize before transforming
pageKind: heuristic
status: published
abstract: When adopting a standard, first map the existing operating model onto the standard's structure. Adoption follows mapping; transformation follows adoption.
sources:
  - articles/open-group-2017-managing-business-of-it
---

## The heuristic

> When introducing a new standard or framework, first **map** the existing operating model onto its structure. Don&#39;t try to transform until the map is shared.

## When it applies

Any standard adoption against an organisation that already runs — `[[entities/it4it]]`, TOGAF, ArchiMate, `[[entities/csdm]]`, BIAN, COBIT, ITIL refactor. Especially when the executive audience is fluent in their current operating model and skeptical of "yet another framework."

## Why it works

Mapping is a low-stakes activity. It doesn&#39;t commit anyone to change. It surfaces where the current model is strong (those parts stay) and where the standard adds value (those parts get adopted deliberately). The conversation moves from "are we wrong?" to "where is the standard most useful for us?" — which is a question executives engage with.

The phrase to use: *"How is our current operating model the same or different from this standard?"*

## Counterexamples

- Greenfield builds where there&#39;s no current operating model to contextualize against — go straight to the standard.
- Compliance-driven mandates where the standard is non-negotiable. You still contextualize internally for adoption planning, but the framing externally is "adopt this."
- Operating models that are visibly broken and the org agrees they&#39;re broken. Contextualization is too patient for a fire-drill; transformation is the right frame.

## See also

- Parent stance: `[[stances/contextualize-dont-transform]]`
- Related heuristic: `[[heuristics/find-at-least-one-champion]]`
- Related heuristic: `[[heuristics/pitch-simple-adjust-per-audience]]`
