Project Kill Criteria¶
Protocol — instantiates Marginal Stop Rule
Defines conditions under which a project should stop because the value of alternatives now exceeds the value of continuing.
Project Kill Criteria are the stop conditions a team writes down before the work begins — while judgment is coldest and no one is yet attached — and then checks at scheduled milestones. The defining move is pre-commitment: the decision to stop is made in advance and handed to a future self who will be tempted to keep going, so a written criterion, not the mood in the review room, decides whether the next phase gets funded. Each criterion pairs an evidence condition ("retention below X at the alpha gate") with a consequence ("do not greenlight beta"), and the whole set lives in the project charter where a later reviewer can see exactly what was promised. Its narrow job is to convert "we should probably stop something like this eventually" into named, dated trip-wires that fire on their own.
Example¶
A game studio greenlights a mid-budget action title. At the kickoff, before anyone has fallen in love with the concept, the producer and an independent portfolio lead write three kill criteria into the charter: at the vertical slice gate, a blind playtest must show median session length above a floor; at alpha, day-two retention in a soft launch must clear a set line; at beta, projected cost-to-ship must stay under the approved envelope. Each is tied to a specific gate date and a specific consequence — advance, or stop and reassign the team.
At the alpha gate a year later, the soft-launch retention lands well under the committed line. The team has a hundred reasons to push on — the combat "just needs polish," a marketing beat is booked. But the criterion was set when none of that pull existed, and it names the consequence plainly: the project does not proceed to beta. The studio stops it, redirects the engineers to a title that cleared its own gate, and the charter records why — so six months later no one relitigates whether the call was fair.
How it works¶
- Write the criteria at the coldest moment. Author them at project start, when no sunk cost or momentum is pulling the decision, and bind them to the charter.
- Tie each to a scheduled gate. A criterion only bites at a named checkpoint — vertical slice, alpha, beta — so the review is a calendar event, not a judgment call someone has to choose to raise.
- Pair condition with consequence. Every criterion states both the evidence line and what happens when it is crossed: stop, or route to a documented exception review. No orphan metrics.
- Give the trigger an owner outside the team. An independent gatekeeper checks the criteria, because the people doing the work are the worst-placed to call their own project.
- Record the decision. The charter captures the evidence seen, the criterion applied, and the outcome, so the call is auditable and cannot be quietly reinterpreted later.
Tuning parameters¶
- Strictness of the line — where the threshold sits. A high bar kills more aggressively and risks cutting a slow-burner; a low bar rarely fires and can become decorative.
- Gate frequency — how often criteria are checked. Frequent gates catch waste early but add ceremony and churn; sparse gates let a doomed project run months longer than it should.
- Trigger ownership — team-owned versus independent. Independent triggers resist optimism but cost political capital; team-owned ones are cheaper and easier to rationalize away.
- Hardness — whether a tripped criterion auto-kills or merely forces a review. Auto-kill maximizes courage-to-stop; review-triggering trades some of that courage for context sensitivity.
- Evidence bar — how much data a gate demands before it may fire, guarding against a kill on one noisy data point.
When it helps, and when it misleads¶
Its strength is that it disarms the single most reliable reason bad projects continue: the decision to stop, made before commitment forms, is far cooler than the same decision made once a team, a roadmap, and a reputation are riding on it. Pre-committed criteria are the standard antidote to escalation of commitment — the tendency to pour more resources into a failing course[1] precisely because so much has already been spent.
The classic misuse is the ceremonial criterion: a line that exists on paper but gets waived under deadline pressure "just this once," until the exception is the rule. A related failure is the criterion gamed by choosing a flattering metric window, or a premature kill that fires on noise before a lagged payoff could appear. The guarding discipline is to seat the trigger with someone outside the delivery team and to require any override to be written down with its justification — a waived criterion should cost something to waive, not nothing.
How it implements the components¶
stop_threshold— each kill criterion is a stop threshold: a named evidence condition welded to a consequence (do not advance, or escalate to review).decision_rationale— the charter records the criteria, the evidence seen at the gate, and the outcome, leaving an auditable trail of why the next phase was funded or stopped.review_cadence— the criteria are bound to scheduled stage gates, so continuation is re-earned at each checkpoint rather than assumed.
It does not read a rolling risk-versus-benefit signal or plan a reversible pull-back (risk_or_side_effect_estimate, reversibility_plan) — that is Training Volume Limit — nor does it guard a protected floor that stopping must never breach (protected_obligation_check) — that is Treatment Escalation Limit. Its trip-wires can kill outright; those siblings cannot.
Related¶
- Instantiates: Marginal Stop Rule — supplies the pre-committed, gate-bound stop condition the archetype needs when momentum would otherwise carry a project forward by default.
- Sibling mechanisms: Budget Stop Rule · Ad Spend Cap · Training Volume Limit · Treatment Escalation Limit · Research Continuation Gate · Repair-vs-Replace Decision · Sunset Review with Reauthorization
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: Project Kill Criteria operates as a standing rule, threshold, contractual commitment, or policy constraint governing future conduct because it defines conditions under which a project should stop because the value of alternatives now exceeds the value of continuing.
Independent corroboration: The frozen evidence defines Project Kill Criteria as 'Defines conditions under which a project should stop because the value of alternatives now exceeds the value of continuing', so its operative form is Rule, Policy & Commitment.
Nearest alternative: Decision, Gate & Allocation — Project Kill Criteria includes features of a case-specific gate, selection, routing, prioritization, or resource disposition, but its defining operation is a standing rule, threshold, contractual commitment, or policy constraint governing future conduct.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Explicit termination criteria are canonical portfolio and project-governance mechanisms against escalation of commitment.
Related originating lineages:
- Economics & Finance — Project Kill Criteria is most plausibly rooted in the economics_finance tradition because its characteristic form depends on prices, incentives, contracts, scarcity, and resource exchange. The assignment tracks that formative lineage, not the many settings in which the mechanism can now be applied.
- Innovation & Entrepreneurship — Stage-gate and venture practice materially institutionalized stop criteria under uncertainty.
- Operations Research — The operations_research tradition materially shaped Project Kill Criteria 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. OECD: Innovation Portfolios—Knowing When to Stop Development; U.S. GAO: Agile Portfolio Management and Iterative Business Cases 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 economics finance is substantive: those traditions materially developed, translated, or operationalized part of the mechanism. The cited provenance places its defining lineage in organizational management.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- OECD: Innovation Portfolios—Knowing When to Stop Development
- U.S. GAO: Agile Portfolio Management and Iterative Business Cases
Notes¶
The power of the mechanism lives almost entirely in when the criteria are written, not how clever they are. A mediocre criterion set fixed at the cold start beats a brilliant one negotiated at the hot gate, because the second is authored by the very optimism it is supposed to check.
References¶
[1] Staw, B. M. "Knee-Deep in the Big Muddy: A Study of Escalating Commitment to a Chosen Course of Action". Organizational Behavior and Human Performance 16(1): 27–44 (1976). Shows that negative results can prompt greater resource commitment to an already chosen course, especially under personal responsibility. registry ↩