---
name: emergence-conditions-audit
description: "Invoke when a program's projects all report green (on schedule, on budget) but program-level benefits aren't materializing, or when designing governance for a new multi-project program that needs an owner for the interaction layer where outcomes emerge."
---
# Emergence Conditions Audit for Program Governance

## R — Reading

> "Project managers own their projects. The PMO owns the reporting. Nobody owns the interaction layer where the program-level outcome actually lives. The unowned space is not an oversight. It is a structural feature of how program governance is usually designed, and it produces structural failure with remarkable consistency."

*Source: `20260418_emergence-not-a-metaphor`, citing Hoel (2026) on causal emergence*

## I — Interpretation

Williams draws on formal emergence science — specifically Hoel (2026)'s finding that macroscale outcomes contain genuine causal information not reducible to component properties — to make a precise claim: program-level outcomes are causally located at the interaction layer between projects, not within the projects themselves. This is not a management metaphor. It is the structural reason why governing a program at the component level produces strong project performance and weak benefit realization. The outcomes live somewhere the governance isn't.

The four emergence conditions (drawn from complex adaptive systems theory) specify what the interaction layer actually needs in order for program-level outcomes to form. Disequilibrium is the first: the system must be disturbed from comfortable equilibrium before a new pattern can form. The instability that characterizes early program execution — the conflicts, the unresolved dependencies, the competing team priorities — is not a failure state to eliminate. It is the precondition for the outcome to form. Governance that moves too quickly to eliminate this instability may prevent the very emergence the program was created to produce. The governance function is to hold the boundary conditions, not to neutralize the instability inside them.

The other three conditions — amplifying mechanisms, recombination and self-organization, and stabilizing feedback — each require specific governance instruments that conventional oversight-based governance does not provide. Amplifying mechanisms require active propagation of cross-project learning, not just reporting. Recombination requires organizational slack and explicit permission for teams to deviate from original design based on what they are learning. Stabilizing feedback (which is what governance at the program level actually is) requires boundary conditions that prevent the system from flying apart — not surveillance of components.

The governance reframe is ecological rather than hierarchical: governance as the design of conditions under which the right emergence becomes possible, rather than governance as oversight of components. This reframe changes which governance questions are worth asking. The question is not "are the projects on track?" but "are the four emergence conditions present?"

## A1 — Past Application

Williams analyzes the Healthcare.gov launch failure (c04) through the emergence conditions lens. The program had 55 contractors, each governed at the component level. Every contractor was accountable for their own deliverables. There was no governance instrument — no role, no process, no authority — that owned the interaction layer between contractors. The failure when the system went live was not a component failure. Multiple components worked as specified. The failure was at the interaction layer: the interfaces between components produced a system that didn't function at scale. The repair intervention (installing a systems integrator with explicit cross-contractor authority) was the creation of a governance function for the interaction layer — retroactively installing what should have been present from the start.

Williams also cites the EVM pattern (c15): programs that run earned value management consistently show strong project reporting — schedule variance, cost performance index, earned value metrics are all tracked at the component level — alongside weak benefits realization at the program level. She argues this is the structural signature of the unowned interaction layer. EVM governs components. The outcome space between components goes ungoverned. The correlation between rigorous EVM adoption and weak benefits realization is not coincidental; it reflects a governance design that measures what it owns and ignores what it doesn't.

## A2 — Future Trigger ★

- A program has completed phase one delivery: all projects within budget and schedule, all milestone criteria met, and the sponsor is asking why the expected business impact hasn't materialized — the structural signature of ungoverned interaction layer
- A new program is being set up with a PMO responsible for consolidated reporting; the charter is clear on project accountability but silent on who owns cross-project dependencies, integration risks, and emergent outcomes — the unowned space is being built in from the start
- A program has been running for 12+ months and governance discussions focus almost entirely on individual project status, with no standing forum that examines what is emerging from project interactions — the interaction layer has no governance owner
- A program director is being asked to add more oversight, more reporting, more controls to a troubled program, but the program already has extensive reporting; the question is whether the problem is insufficient oversight of components or total absence of governance at the interaction layer
- A program is entering a design phase and the instability and conflict between teams is being treated as a problem to resolve quickly; the question is whether eliminating that instability early might foreclose the emergence the program needs

## E — Execution

1. **Establish what level the program outcome lives at.** Ask: is the program benefit something any single project could produce, or does it require the interaction between projects? If it requires interaction, the outcome is at the interaction layer and requires governance there.

2. **Audit the ownership map.** For each project, name who owns it. For the PMO function, name what it owns (typically: consolidated reporting, resource coordination, escalation management). Then explicitly ask: who owns the interaction layer — the dependencies, interfaces, emergent behaviors, and cross-project learning loops between projects? If the answer is nobody, the structural failure mode is already built in.

3. **Check each of the four emergence conditions:**

   - *Disequilibrium:* Is there productive instability present — unresolved tensions, competing approaches, live dependencies? Or has governance moved too quickly to create false stability by imposing solutions before emergence can occur?
   - *Amplifying mechanisms:* Are there active mechanisms that propagate learning from one project to others? Not just reporting — actual feedback that changes what other teams do?
   - *Recombination and self-organization:* Do teams have organizational slack and permission to reorganize, recombine their approaches, or deviate from original design based on emerging learning? Or are they locked to original design?
   - *Stabilizing feedback:* Is there a governance function — a role, a forum, a process — that holds boundary conditions (integration constraints, strategic alignment, non-negotiable interfaces) without micro-managing component decisions?

4. **Identify the specific governance gap.** Map each missing condition to a concrete governance instrument that is absent. An absent amplifying mechanism means no cross-project learning loop. Absent recombination permission means teams cannot adapt even when they know the original design is wrong. Absent stabilizing feedback means the interaction layer has no boundary conditions and the system can fly apart.

5. **Assign ownership of the interaction layer.** Recommend the creation of a role or forum with explicit authority over the interaction layer. Name what decisions this owner can make, what information they are responsible for synthesizing, and how their authority relates to individual project PMs and the PMO.

6. **Reframe the disequilibrium question with the sponsor.** If early-stage instability is being treated as a failure signal, make the ecological design argument: stabilizing feedback should hold the boundary conditions, not eliminate the instability inside them. The program needs to create conditions for emergence, not conditions that prevent it.

7. **Redesign the governance reporting structure.** Add a standing forum (weekly or biweekly) that examines interaction-layer signals: cross-project dependency health, emerging integration issues, cross-project learning, benefits realization leading indicators. This forum is separate from project status review.

8. **Reassess quarterly.** Emergence conditions change as programs mature. The disequilibrium that was productive in month three may be destructive in month twelve. Recalibrate which conditions need strengthening or constraining as the program evolves.

## B — Boundary

This framework applies to programs — multi-project portfolios producing outcomes through the interaction of components. It does not apply to single projects. The emergence conditions concept requires a scale of interdependence that a single-team effort simply doesn't have. Applying an interaction-layer audit to a standalone project produces noise, not insight.

The four conditions audit identifies governance gaps but does not prescribe how to own the interaction layer. The specific governance design — what role has what authority, what forums exist, what instruments produce amplifying feedback — requires domain-specific knowledge that the framework does not supply. The audit tells you what is missing; designing the replacement requires contextual judgment.

The disequilibrium reframe is susceptible to misuse. The argument that governance should not eliminate productive instability does not mean instability is always productive. A program in genuine crisis needs stabilization. The argument applies to the early stages of emergence, not to programs that are simply failing to execute. Misapplied, this reframe becomes a rationalization for tolerating problems that require direct intervention.

Williams' framework relies heavily on Hoel (2026) for the causal emergence foundation. This is cited as a single source, and the application of formal emergence science to program governance is relatively new. Practitioners with strong traditional PM backgrounds may find the scientific framing unconvincing even if the operational findings are valid. The audit is useful regardless of whether the reader accepts the causal emergence framing.

## Related Skills

- composes-with: `program-governance-ecological-design` — audit identifies which conditions are absent; ecological design framework provides the design response; run emergence audit first
- contrasts-with: `sv-trend-diagnostic` — both diagnose feedback dysfunction; SV is the quantitative signal; emergence audit is the structural cause
- composes-with: `governance-model-adequacy-test` — interaction layer ownership requires someone who holds the model; Conant-Ashby and emergence audit diagnose the same gap from different angles

______________________________________________________________________

## Provenance

- **Source:** Project Management Research and the Critical Path, Nicole Williams, 2026