Prerequisite Matrix¶
Artifact — instantiates Dependency Ordering
A table mapping each unit of work to its prerequisites, evidence, owner, and allowed next step.
A Prerequisite Matrix is the tabular dependency artifact: one row per unit of work, with columns that pin down, for each unit, what predecessor conditions it requires, what evidence proves those conditions are satisfied, and who is accountable for producing them. Its distinguishing feature among the siblings is that it is built for dependencies that cross team, discipline, or organizational boundaries — where no single person holds the whole picture and a graph drawn by engineers would silently omit the legal, procurement, or regulatory edges. By putting owner and evidence in the same row as the dependency, the matrix turns "who is blocking whom, and how would we know it's cleared" into a shared, inspectable ledger rather than something reconstructed in a status meeting.
Example¶
A cross-functional program is preparing an aircraft for its first flight-test milestone, an effort spanning structures, avionics, flight-test operations, and the certification authority. A dependency graph alone would show arrows but not who clears them or what counts as cleared, so the program keeps a prerequisite matrix. Each row is a milestone activity — "instrumented flutter test," "avionics integration sign-off," "structural load-case analysis release." Its columns state the required predecessors ("load-case analysis released and reviewed"), the evidence that closes each one ("stress report rev C, signed by chief engineer"), the accountable owner (a named person, not a team), and the next activity the row unlocks.
Because a row is not "done" until its evidence column carries the actual artifact — the signed report, the test log, the authority's concurrence letter — the matrix resists the failure where a team claims readiness it has not demonstrated. When flight test asks "can we fly the flutter card?" the answer is a lookup, not a negotiation: the matrix shows that two predecessor rows still lack their evidence and names the two owners responsible. A dependency that would otherwise surface as a launch-day surprise is visible weeks ahead, with a name attached.
How it works¶
What distinguishes the matrix from a graph or a checklist is that each dependency carries its accountability and its proof in the same row:
- One row per unit, prerequisites as a column. The matrix records, for every activity, the predecessor conditions it depends on — a tabular dependency map that is easy to filter, sort, and hand across teams that would never share one diagram.
- Evidence closes a prerequisite. A predecessor is not satisfied by assertion; the row's evidence column must hold the artifact that proves it (a signed report, a passing test, a delivered material certificate), so readiness is documented rather than claimed.
- An owner is named per dependency. Each row (or each predecessor within it) carries an accountable person, so a blocked dependency has someone to escalate to rather than a diffuse "the team."
The matrix is a governance ledger, not an execution engine: it makes the cross-boundary structure legible and accountable, then leaves the computed run order and the moment-of-action gating to other mechanisms.
Tuning parameters¶
- Row granularity — milestones, activities, or fine-grained deliverables. Finer rows expose more real blockers but grow the matrix and its upkeep.
- Evidence strictness — what artifact counts as closing a prerequisite (a linked document, a signature, a passing test). Stricter evidence resists checkbox readiness but costs effort to produce and attach.
- Owner resolution — whether ownership is a role, a team, or a named individual. Named individuals sharpen accountability but need constant maintenance as people move.
- Update cadence — how often rows are reconciled against reality. A stale matrix confidently blocks valid work or clears invalid work, so cadence trades upkeep against trust.
- Scope breadth — how many disciplines the matrix spans. Wider scope captures the cross-boundary edges that cause the worst surprises but is harder to keep current.
When it helps, and when it misleads¶
Its strength is precisely at boundaries: when a dependency runs from engineering to legal to a regulator, the matrix is the one place that holds the relation, the proof, and the owner together, so cross-team blockers surface early and escalate to a name. It is the artifact that makes accountability for readiness explicit rather than assumed.
Its failure mode is the stale matrix — the system changes, a new dependency appears or an old one dissolves, but the rows are not updated, so the ledger gives false confidence in both directions. A related failure is evidence theater, where the evidence column is filled with a link to a document nobody checked, satisfying the form of proof without the substance. A classic misuse is treating the matrix as a computed schedule: it records prerequisites and readiness, but it does not itself derive the run order or tell you which chain is time-critical. The guarding discipline is a maintenance cadence that reconciles rows against the real system, evidence that is genuinely inspected rather than merely linked, and a clear handoff of the ordering computation to the mechanisms built for it.
How it implements the components¶
dependency_map— the matrix is a tabular map: each row's prerequisite column records the predecessor conditions a unit depends on, legible and filterable across team boundaries.completion_evidence— an explicit evidence column holds the artifact that proves each prerequisite is satisfied, so a dependency is closed by documented proof rather than assertion.dependency_owner— an owner column assigns an accountable person to each dependency, giving every cross-boundary blocker a name to escalate to.
It does not compute a valid global order (sequencing_rule, Topological Sort) — its "allowed next step" is a per-row read of the map, not a derived sort — nor mark the chain that controls total duration (critical_path_marker, Critical Path Method) or define an emergency bypass (exception_override_rule, Deployment Runbook).
Related¶
- Instantiates: Dependency Ordering — the Prerequisite Matrix is its cross-boundary governance artifact, holding dependency, evidence, and owner together.
- Sibling mechanisms: Topological Sort · Critical Path Method · Deployment Runbook · Manufacturing Process Plan · Curriculum Prerequisite Map · Treatment Sequencing Protocol · Dependency Graph
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Prerequisite Matrix operates as a static representation, map, specification, schema, or prospective plan that externalizes information because it a table mapping each unit of work to its prerequisites, evidence, owner, and allowed next step.
Independent corroboration: The frozen evidence defines Prerequisite Matrix as 'A table mapping each unit of work to its prerequisites, evidence, owner, and allowed next step', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Mapping work items to prerequisites, owners, evidence, and next steps is established project and program-management practice.
Related originating lineages:
- Education & Pedagogy — Prerequisite Matrix is most plausibly rooted in the education_pedagogy tradition because its characteristic form depends on instruction, learning progression, assessment, and scaffolded practice. The assignment tracks that formative lineage, not the many settings in which the mechanism can now be applied.
- Engineering & Design — Systems engineering materially shaped requirements traceability and gated progression.
- Operations Research — The operations_research tradition materially shaped Prerequisite Matrix through its own practice of queueing, optimization, scheduling, prioritization, and constrained allocation.
Review resolution: Light authoritative-source research resolves the primary-origin disagreement in favor of organizational management. U.S. Department of Energy: Critical Decision Approval Prerequisite Activities documents the defining practice, history, or theory described in the selected origin rationale. Other domains are retained only where the blind reviews identify material co-development or translation; broad later application is recorded separately as domain_reach=multi_domain, while origin_mode=cross_disciplinary_synthesis describes the relationship among formative lineages.
Attribution caveat: The blind-review boundary with education pedagogy is substantive: those traditions materially developed, translated, or operationalized part of the mechanism. The cited provenance places its defining lineage in organizational management.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
The matrix and a dependency graph are duals: the graph makes topology (chains, fan-in) visible at a glance, while the matrix makes accountability (who, what evidence) explicit per row.[1] Programs that cross many teams usually need the matrix precisely because the graph hides the human column.
References¶
[1] A Design Structure Matrix (DSM), introduced by Donald Steward in 1981, is a square matrix representation of dependencies among elements; reading dependencies in matrix form (rather than as a graph) is what makes clustering, ownership, and cross-team blockers tractable at scale. withdrawn registry ↩