Dependency Mapping Board¶
Visual mapping tool — instantiates Backcasting Pathway Design
Lays prerequisites out as a manipulable visual lattice so precedence links, parallel paths, and bottlenecks become legible and rearrangeable.
A Dependency Mapping Board is a visual surface — a wall of cards, a whiteboard, or a digital equivalent — on which the pathway's prerequisites sit as nodes and the "must-precede" relationships are drawn as edges, so the structure of the backcast becomes something you can see and rearrange with your hands. Its defining idea is spatial legibility of structure. Unlike a workshop, which derives the chain, or a roadmap, which renders it as a communication timeline, the board's job is to make precedence, parallelism, and bottlenecks physically obvious and cheap to restructure when a link turns out to be wrong. It holds the prerequisites and the dependency relations as its primary object and says nothing about who owns them or whether they are affordable.
Example¶
A county health department is backcasting toward equitable cancer-screening access. On the board, each prerequisite is a card: community trust established, mobile-clinic capacity, data-sharing agreements with providers, a reimbursement pathway, multilingual outreach. Arrows record precedence: trust must precede outreach uptake; data-sharing must precede targeting under-screened populations; a reimbursement pathway must precede sustained clinic capacity. Laid out spatially, two facts jump off the wall. First, several streams — outreach and clinic build-out — can run in parallel rather than in sequence. Second, one node, the data-sharing agreement, sits upstream of three others, which marks it as the bottleneck governing the whole pathway. When the team realizes that community trust must also precede data-sharing (residents must consent to how their data is used), they physically move a card and the lattice re-forms in front of them — a correction a flat list would have buried.
How it works¶
- Place each prerequisite as a node on the surface.
- Draw a must-precede edge for every genuine dependency between nodes.
- Read off parallel paths (unconnected branches) and bottlenecks (high-fan-out nodes).
- Rearrange physically the moment a dependency is found to be wrong.
- Keep it live — the board is meant to be re-manipulated as evidence arrives, not frozen.
A bottleneck on the board is the pathway's governing constraint in the Theory-of-Constraints sense: the node that gates the most downstream work.[n1]
Tuning parameters¶
- Node granularity — coarse conditions versus fine sub-conditions; finer shows more structure but crowds the surface.
- Edge strictness — only hard "impossible-without" links versus softer "helps" links. Too many soft edges bury the real structure.
- Layout convention — time-columned layers versus free-form network; layers ease reading, networks ease rearranging.
- Bottleneck marking — whether high-dependency nodes are visually flagged so the governing constraint is obvious.
- Physical versus digital — a physical board invites tactile rearrangement; a digital one eases sharing and version history.
When it helps, and when it misleads¶
Its strength is turning an implicit tangle of dependencies into a visible, manipulable object where bottlenecks and parallelizable work jump out, and it invites correction because moving a card is cheap. Its failure mode is false edges — drawing dependencies that are not real (from habit, the org chart, or "we always do X first") clutters the lattice and manufactures phantom bottlenecks, while a missing real edge hides a true one. The classic misuse is freezing the board as documentation, treating the first layout as truth instead of re-testing links as evidence arrives. The guarding discipline is to challenge every edge with "is the later node genuinely impossible without the earlier one?" and to keep the board editable so found-wrong links get moved rather than preserved.
How it implements the components¶
dependency_map— is the visual dependency map itself: nodes and must-precede edges made legible and rearrangeable.prerequisite_condition— holds each prerequisite as a placeable node on the surface, so the conditions become manipulable objects.
It shows structure but resources nothing: it assigns no pathway_owner and models no feasibility_constraint — that is the Future-State Implementation Plan, which consumes this board — and it displays links rather than deriving them, so placing the reverse_milestones themselves belongs to the Reverse Milestone Planning Workshop.
Related¶
- Instantiates: Backcasting Pathway Design — the visual surface that makes the pathway's dependency structure legible.
- Consumes: Reverse Milestone Planning Workshop supplies the prerequisites this board arranges.
- Sibling mechanisms: Sustainability Backcasting Session · Reverse Milestone Planning Workshop · Transformation Roadmap · Future-State Implementation Plan · Pathway Assumption Review · Present Commitment Register
Editorial Notes¶
Form Classification¶
Form family: Interface, Display & Cue
Rationale: Dependency Mapping Board operates as a user-facing prompt, display, template, or perceptual cue that shapes attention and action at the point of use because it lays prerequisites out as a manipulable visual lattice so precedence links, parallel paths, and bottlenecks become legible and rearrangeable.
Independent corroboration: The frozen evidence defines Dependency Mapping Board as 'Lays prerequisites out as a manipulable visual lattice so precedence links, parallel paths, and bottlenecks become legible and rearrangeable', so its operative form is Interface, Display & Cue.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Operations Research
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: Project-network planning cohered visual precedence maps that expose parallel paths, critical bottlenecks, and rearrangeable task dependencies.
Related originating lineages:
- Organizational & Management Science — Collaborative planning practice supplied cards and boards as manipulable shared surfaces.
Review resolution: Project-network planning cohered visual precedence maps that expose parallel paths, critical bottlenecks, and rearrangeable task dependencies. Project-network scheduling is primary, while collaborative board facilitation materially shapes the encyclopedia artifact and warrants the retained ambiguity.
Attribution caveat: The board is a facilitation artifact built on established dependency-network scheduling.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
[n1] Theory of Constraints (Eliyahu Goldratt) — the principle that a system's throughput is governed by its single tightest bottleneck; on a dependency board the highest-fan-out prerequisite is that governing constraint. ↩