Skip to content

Requirements Churn

A project pathology in which the specification changes faster than the execution organization can absorb it — a control-theoretic case where the reference signal outruns the controller's bandwidth, so no spec lives long enough for work to consolidate against it.

Core Idea

Requirements churn is the project-management pathology in which the specification of what is being built changes repeatedly or substantially faster than the execution organization can stably incorporate the changes into in-flight work. Each new wave lands while the prior one is still propagating through design, build, test, and integration; no version of the spec lives long enough for work to consolidate against it, and throughput collapses not because the team is slow but because velocity is consumed re-touching obsoleted work. Structurally, the cadence of specification change exceeds the bandwidth of the execution loop.

Scope of Application

Requirements churn lives across the sectors of organizational delivery where a complex artifact is built under stakeholder-defined requirements — sectors of one substrate, not structurally distinct ones.

  • Software delivery — sprint plans turning over weekly as stakeholders reprioritise.
  • Construction megaprojects — owner change-orders outrunning the contractor's integration capacity.
  • Policy implementation — a rule amended faster than affected entities can reach a stable compliance posture.
  • Research programs — funder priorities shifting faster than the team can resettle its design.
  • Defense acquisition, drug development, curriculum reform, M&A integration — further delivery sectors.

Clarity

Naming requirements churn pries apart three states a lead otherwise lumps as "the spec keeps changing": iteration (small scoped change, the designed input to a controlled loop), late binding (deliberate deferral), and churn proper (change faster than the loop can absorb). The three call for opposite responses, so the vocabulary routes the fix to the inflow, not execution. It relocates blame: the team is not the bottleneck even though every symptom points at it — defensible because of the measurement it crystallizes, amendment rate versus completion rate.

Manages Complexity

A deteriorating project presents a pile of symptoms — missed milestones, rework, stale test suites, falling velocity, burnout — all seeming to indict the team. Requirements churn collapses that scatter to a single regularity: a relation between two cadences, amendment inflow versus work-completion throughput. The analyst tracks one comparison and reads the true state off which cadence is faster. That relation installs a clean branch — change-inflow problem versus execution problem — that routes the fix to opposite places, and a set of distinctions that keep the analyst from misrouting.

Abstract Reasoning

Churn licenses a diagnostic move (inferring an inflow constraint from symptoms that all point at the team, confirmed by consolidation failure), an interventionist move (acting on the inflow via change-control, scope freezes, and change-order economics, with the strong negative prediction that adding capacity buys only more rework), a boundary-drawing move (prying churn apart from iteration, late binding, scope creep, underspecification, and bottleneck), and a predictive move (the failure trajectory of ballooning rework and collapsing throughput).

Knowledge Transfer

Within project and delivery practice churn transfers as mechanism, because the cadence comparison and the control-theoretic diagnosis are stated independently of the artifact — carrying intact across software, construction, policy, and research delivery, all delivery flavours of one substrate. Beyond delivery it is a clean shared abstract mechanism: stripped of PM vocabulary, the mechanic is the reference signal varying faster than the controller's tracking bandwidth, recurring as mechanism in cognition, thermoregulation, markets, and ML drift. That control-bandwidth-shortfall pattern carries the cross-substrate weight; churn's change-control boards and change-order architecture stay home. Note it is neither scope_creep (monotonic expansion) nor feedback_loop_with_delay (a delayed signal, not an outrunning reference).

Relationships to Other Abstractions

Local relationship map for Requirements ChurnParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Requirements ChurnDOMAINPrime abstraction: Reference Cadence Exceeds Tracking Bandwidth — is a kind ofReference Caden…PRIME

Current abstraction Requirements Churn Domain-specific

Parents (1) — more general patterns this builds on

Hierarchy path (1) — routes to 1 parentless root

Neighborhood in Abstraction Space

Requirements Churn sits in a sparse region of the domain-specific corpus (60th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Managing Exceptions & Change (5 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-07-12