An unrefreshed map drifts from a changed process

What it is

A map finished for last year’s campaign still sits in the folder titled Current Journey, while warehouse SLAs, the return entry, and the verification method have all changed. Completion is not a shelf life. Temporal drift means the map remains a snapshot of process on the drawing day while field rules keep moving; the longer the lag, the more the sheet is archaeology. This is not the same problem as “no department co-owns it.” Even with clear ownership at the time, if nobody writes back on a calendar or a change event, the map expires by itself.

Why it happens

Research projects have a closing ritual—export PDF, file in the wiki, present, stop. The ritual turns a working file into an archive. Product, ops, and risk keep shipping rules by version. People then read new complaints through the old map, mistaking a new break for “the pain we already knew,” and miss the step that actually appeared. Conversely, a failure already fixed stays on the map, so the team thinks the problem is live and opens a duplicate project. Drift is silent: no error is thrown, only the distance between date and field grows.

Studying it

Stamp every in-use map with drawing date and last check date. Pin current real cases onto it, count steps that no longer hold, and scatter that rate against time since drawing. Compare “seal at project end” with “rewrite triggered by a version release” on how fast distortion grows. Outcomes: share of expired steps, new complaints misread through the old map, and failures that remain on the map after disappearing in the field.

Where it stops holding

A map kept as a dated historical baseline should not be updated, or the comparison is lost; the drift problem is treating it as present tense. Very slow compliance-disclosure flows may be checked on a longer cycle, but still need a next-check date rather than a tacit forever. A one-shot study map (that one redesign only) may be sealed if every citation carries a timestamp and it never enters a “live experience” folder. Instrumentation can flag vanished or new steps; it cannot by itself prove the journey’s meaning has changed. Someone still has to walk one complete case.

Applying it

• Footer: drawing date plus “must be checked by” date or release; maps past that check leave the present-tense directory for the archive.
• Treat process-rule changes (cut-off, verification, return entry) as triggers: before the change ticket closes, edit the map or declare it unaffected.
• Once a quarter, walk the old map with a fresh end-to-end case; if it fails, edit. Do not add a comment that says “may have changed.”
• Before using a map to decide, check the date. Treating a past-due map as current fact is a method error; discard that warrant.

Related

• Same group: Q4.04.1 A journey map spans touchpoints and shows the whole course · Q4.04.2 Emotion and pain on the map need a source · Q4.04.3 An unverified map is a team hypothesis · Q4.04.4 As-is maps what happens; to-be maps what is wanted — keep them apart · Q4.04.5 Too fine a grain drowns turning points; too coarse hides breaks · Q4.04.6 Maps that cross departments need shared upkeep
• Adjacent: Q4.10 Generalizability of findings · Q4.05 Service blueprints
• Search terms: journey map temporal drift · stale journey map · living journey documentation