The delivery decision your portfolio keeps avoiding

A portfolio review reaches an aging initiative. The evidence has weakened, scarce specialists remain tied up, and the next credible learning point keeps moving. The conversation turns to replanning, re-sequencing, and whether the deadline should move. Nobody asks whether the initiative should continue.

That omission can be built into the review. Sponsors arrive prepared to justify continued existence, and an initiative that has already survived one funding round will often have a story for another.

Weak initiatives survive because stopping is the harder argument

Sunk-cost bias explains only part of why software initiatives keep going after the case weakens.

Keil et al. (2000) surveyed IS professionals about software projects that continued despite negative evidence, testing four competing explanations. The completion effect best separated escalated from non-escalated projects: the closer an initiative appears to finishing, the easier another increment of funding may be to defend. That makes "almost there" a relevant claim to examine rather than proof that more funding is warranted.

Self-justification may add a second layer. Keil and colleagues reported that constructs derived from self-justification theory were significant in their regression models. Their abstract does not establish the more specific pattern that the same person both approved and later defended an initiative, so that should remain a review hypothesis rather than a finding from this study.

Berente et al. (2022) looked at how this plays out over time in large information-system projects, synthesizing fifteen published cases. The reasons for continuing changed as initiatives aged. At approval, the argument was opportunity and return. Later, it shifted to accumulated cost or technical necessity. Each justification could sound credible while replacing the original case. A review that sees only the latest rationale may miss that substitution.

Heng et al. (2003) tested whether social cover helps. In a controlled software-project decision scenario, they examined whether support from superiors or peers — blame-sharing, explicit reassurance — made it easier to de-escalate. The tactics showed some promise when commitment was still low. Under high sunk commitment, none of the four strategies moved the decision. This was a laboratory scenario with individual decision-makers, not a study of executive portfolio governance, so read it as a caution rather than a finding about your review board. The caution is worth taking seriously: waiting until the political cost is high and then offering someone a graceful exit may be too late to matter.

The counter-argument that deserves room

There is a version of this argument that overcorrects, and delivery leaders should resist it. Continuing a struggling initiative is not automatically irrational.

Tiwana et al. (2006) ran an experiment with managers drawn from over a hundred firms, examining how real options shaped continuation decisions in escalation situations. Managers recognized and valued options — the ability to stage the investment, scale it later, switch direction, defer a commitment, or abandon cleanly at a defined point. Perceived option value largely explained their continuation choices. Growth options drew more weight than operational ones.

Killing every initiative that shows red can destroy useful flexibility. A stalled initiative may still hold open a valuable future choice.

But the study measured how managers respond to project information, not whether their option valuations were accurate. Perceived option value can be optimistic, and it can be politically convenient. This article therefore proposes a sharper operational test than "there might be upside later": ask for a specific future choice, the information that will resolve it, the date the choice expires, and what it costs to keep it open. If the sponsor cannot state those four elements, treat the option claim as unsubstantiated in this review. That does not prove that no real option exists.

Lee et al. (2018) found something adjacent in two experiments on launch-date commitment for software with known defects: decision-makers asked to take the perspective of affected users reduced their commitment more than those asked to take a shareholder perspective. This narrow laboratory setting still raises a useful review question: whose consequences is the room asked to consider?

What the evidence does not settle

None of this validates a stop threshold. No paper here establishes that an initiative past a certain cost overrun, schedule slip, or completion percentage should be terminated. Anyone selling you that number is selling you something the research does not support.

The evidence combines a retrospective professional survey, laboratory experiments, a manager experiment, and a qualitative case synthesis. None tests a modern portfolio continuation review against delivery outcomes. The review below is a mechanism-based decision aid, not a validated route to better cycle time or portfolio throughput.

What the evidence does support is the shape of the problem: different arguments can legitimize continuation at different stages, and a review that asks only for justification may not expose that shift.

A one-page continuation case you can use on Monday

Pick one aging initiative. Before the next review, ask the sponsor to write a single page — not slides — containing these eight items.

The outcome. What problem or measure is this initiative expected to move? Not the output it will produce. The change it will cause.

The current evidence. What have we learned since the last decision, and does it strengthen or weaken the case? Define what counts as strengthening before the review, so the evidence is not selected after the fact.

The next decision boundary. When is the next real go/no-go moment, and what must be known by then?

Scarce capacity consumed until that boundary. Which specialists, review forums, and decision attention does this initiative need between now and then? Name people and groups, not headcount.

The next-best use of that capacity. What would those same people work on if this stopped today? If nobody can answer, the portfolio has no opportunity cost model and every initiative will look affordable.

Any claimed option, tested concretely. Apply this article's proposed four-part check: specific future choice, the information that resolves it, the expiry, and the carrying cost. If those elements are missing, label the claim as unsubstantiated future upside rather than concluding that no option exists.

A named pause or stop trigger. What observation would make continuation wrong? Write it down before you need it.

An independent reviewer. Someone who did not own the original approval. Berente and colleagues found that external scrutiny and leadership change were among the contextual conditions that disrupted the justifications keeping projects alive. You cannot always arrange a leadership change. You can arrange a reviewer with no stake in the original decision.

Then run the review as a comparison across six outcomes rather than a yes-or-no on one: continue, pause, resize, redirect, stage, or stop.

A sound stop decision compares the initiative's current case with its next-best use of scarce capacity, using evidence defined before the review rather than defending money already spent.

That framing is designed to make both failure modes more visible: a weak initiative surviving because ending it is socially expensive, and a valuable option being terminated because a dashboard rendered uncertainty as a red cell. It may reduce the risk of either error, but the retained studies did not validate this review design or test its effect on portfolio outcomes.

References

Berente, N., Salge, C. A. D. L., Mallampalli, V. K. P., & Park, K. (2022, July 3). Rethinking project escalation: An institutional perspective on the persistence of failing large-scale information system projects. Journal of Management Information Systems, 39(3), 640–672. https://doi.org/10.1080/07421222.2022.2096545

Heng, C.-S., Tan, B. C. Y., & Wei, K.-K. (2003). De-escalation of commitment in software projects: Who matters? What matters? Information & Management, 41(1), 99–110. https://doi.org/10.1016/S0378-7206(03)00030-2

Keil, M., Mann, J., & Rai, A. (2000, December 1). Why software projects escalate: An empirical analysis and test of four theoretical models. MIS Quarterly, 24(4), 631–647. https://doi.org/10.2307/3250950

Lee, H. K., Lee, J. S., & Keil, M. (2018, October 2). Using perspective-taking to de-escalate launch date commitment for products with known software defects. Journal of Management Information Systems, 35(4), 1251–1276. https://doi.org/10.1080/07421222.2018.1523604

Tiwana, A., Keil, M., & Fichman, R. G. (2006). Information systems project continuation in escalation situations: A real options model. Decision Sciences, 37(3), 357–391. https://doi.org/10.1111/j.1540-5414.2006.00131.x

AI disclosure: AI was used to help create this article. Responsibility for the published content remains with Nico Thümler.