Nine months in. Two engineers, a designer, and the better part of a quarter’s cash. The team says it is close. They said that in month five as well, and they were sincere both times.
Everyone in the room is arguing about the nine months. The nine months are not a variable, and the only number that is live is what the next six buy.
Why these three models
The decision is whether to continue a project you have already funded, and how to make that call without a fight. The features that fire are a completion estimate built from the project’s own details, a set of opinions that cost nothing to state, and a genuine lag between effort and evidence that is indistinguishable from failure while you are inside it.
Three lenses. The inside view produces an equilibrium answer about why the estimate is wrong in a predictable direction. Pricing produces a random answer about how to extract what people actually believe. Delay produces a complex answer about the one case where continuing is right and looks identical to the case where it is not. Nobody needs to be told to ignore sunk costs; what they need is a way to forecast the remainder, and that is where these decisions actually fail.
1. Your estimate is built from the wrong material
Start with the part everyone already knows and then keep going, because the well-known part is not the useful part.
The money spent is gone whether you continue or stop, so it should not enter the decision. Everyone agrees with that in the abstract and it settles nothing, because the argument in the room is never really about the sunk cost. It is about whether the thing will work, and both sides are forecasting.
So look at how the forecast is made. It is built from the project’s own particulars: what is left on the list, how the last sprint went, what the team believes about the remaining hard part. That is the inside view, and it produces estimates that are systematically optimistic about duration and completion, not because the people are optimists but because the method cannot see the failure modes that have not happened yet.1
The alternative is to ask what happened to projects like this one. Not similar in subject, which is where the comparison usually goes wrong, but similar in structure: same size of team, same dependence on an unproven technical step, same number of months already elapsed past the original estimate.
The most useful version of that question is uncomfortable and quick. Of the last five internal projects that were nine months in and described as close, how many shipped within three months. Most companies can answer that from memory and have never asked it, and the answer usually reframes the meeting faster than any argument about discipline.
Two failure modes sit inside that question. The first is a class chosen too wide. Software projects run late is true and useless, because it contains everything and predicts nothing. The class has to be narrow enough that you can name its members out loud. If you cannot list them, you have picked a category rather than a reference class.
The second is having no class at all, which is the ordinary case in a company that has run four projects in its life. The substitute is not to guess. Ask the team the question the outside view answers indirectly: what would have to be true for this to ship in eight weeks, listed as events rather than as effort. Then mark which of those events sit inside your control. A list where six of nine items wait on a bank integration, a supplier’s firmware, or a regulator’s response is not a plan with eight weeks left in it. It is a plan with an unknown number of weeks left, and the unknown is sitting in somebody else’s building on somebody else’s priorities.
A concrete version. A Kampala payments team nine months into a merchant settlement product counted four prior builds, of which one had shipped inside a quarter of its stated date. That is a base rate of one in four, assembled in a few minutes from memory. It moved the conversation off whether the engineers were competent and onto what a one in four chance was worth buying for another two months of payroll. The number was small and unscientific. It was still the first thing in the room that neither side could talk out of existence.
2. Make them price it, not argue it
Opinions in a project review cost nothing to state, which is exactly why they carry so little information. The person who says we are close is not lying and is also not exposed to being wrong.
The fix is to convert the opinion into something with a price attached. Ask each person to state a probability that the project ships a stated, checkable outcome by a stated date. Write the numbers down with names against them. That is not a bureaucratic exercise; it is the minimum structure that makes a belief comparable across people and checkable afterwards.2
An estimate nobody has to stand behind is a mood, and you cannot run a business on the aggregate of moods.
Two things reliably happen when you do this. The verbal consensus fragments, because close means eighty percent to one person and thirty percent to another and the word concealed the gap. And the numbers come in lower than the room’s tone, because stating a probability is a small commitment and the tone was not.
Aggregation only helps under conditions worth naming: the judgements have to be roughly independent and their errors have to point in different directions. Collect them privately before anyone speaks, or you will get one person’s number repeated with variations, which has the confidence of a group and the information of an individual.
Somebody will decline to give a number on the grounds that it is unknowable. Treat the refusal as information rather than as an obstacle, then ask the same question with the arithmetic removed: given the choice today, would you spend the remaining budget here again. Almost nobody refuses that one twice, and the answer sorts the room as cleanly as a probability does.
The failure mode is worth naming before you run this. A written probability with a name against it can turn into a performance target, and once people believe the number is being scored against their judgement rather than used to make a decision, they converge on whatever is safe. You can see it happening: the spread narrows quarter on quarter while the projects get no more predictable. The fix is procedural. Review calibration in aggregate, never inside an assessment of an individual, and say so out loud the first time you collect numbers. A forecast used as evidence about a person has stopped being a forecast.
Then keep the record. The value compounds, because after three or four projects you have your own calibration data and you no longer need anyone else’s base rate.
3. The one case where continuing is right
The first two lenses will kill projects. The third exists to stop you killing the ones that were working.
Some efforts genuinely accumulate before they show anything. Content, distribution, trust, and most infrastructure behave this way: the spend goes in continuously and the result arrives as a step some months later. During the accumulation phase, a project that is working looks exactly like a project that is failing, because both produce the same observable, which is nothing.3
This is the case that makes kill discipline dangerous when applied mechanically. A company that reviews everything on a quarterly cadence will systematically kill work whose payoff lag exceeds a quarter, and will do it while feeling rigorous.
Worse, the people inside a lagged system reliably explain its behaviour by pointing outside it, and they do so with confidence and in good faith.4 So the month-nine account of why the results have not appeared will be fluent, internally consistent and produced by exactly the people least able to audit it. Fluency at month nine is not evidence, it is what month nine sounds like.
The distinguishing test is not patience, it is whether you specified the lag in advance. If at the start you wrote down that this would show nothing for eight months and then move, you have a hypothesis and month nine is data. If the eight months is an explanation being offered now, in the meeting, to account for the absence of results, it is a story rather than a forecast and it should carry no weight.
Written in advance, that line does a second job which is easy to miss. It tells you what to watch while you are waiting. An accumulation that is working moves an input long before it moves the outcome: repeat visits before revenue, second orders from the same distributor before any change in monthly volume, replies from the same dozen buyers before a signed contract. Name the leading indicator at the start and you are no longer choosing between blind patience and a mechanical kill. You are checking a stock that should be filling.
And if the leading indicator is flat too, the lag argument has run out and you can stop without waiting for the outcome window to close. That is the entire point of specifying it. A real lag makes a testable promise about the intermediate evidence. A lag being used as cover makes no promise at all, which is why it always sounds more reasonable.
The practical instruction is to write the expected shape of the evidence at the beginning of every project, in one line: what we expect to see, and when. That line costs nothing at the start and is the only thing that separates a lag from a failure nine months later.
What the three say together
- Stop debating the spend. Ask only what the next period buys.
- Find the reference class: of the last five projects in this position, how many shipped within a quarter.
- Collect private probabilities against a stated outcome and date, with names, before anyone speaks.
- Check whether the lag was predicted or is being offered as an explanation. Only the first is evidence.
Where they disagree
The reference-class argument and the lag argument give opposite readings of the same evidence.
The reference class says that a project nine months in and still described as close is in a well-populated category with a poor completion rate, so the prior should be harsh. The lag argument says that if this project’s payoff structure is genuinely delayed, the reference class you are using is the wrong one, because it is populated by projects with fast feedback and yours is not.
Both cannot govern, and the resolution is the written prediction. If the expected shape of the evidence was recorded at the start, the lag argument wins and you should hold. If it was not, the reference class wins, because the alternative is accepting an explanation constructed after the fact by the people with the most invested in continuing. That is not a comment on their honesty. It is that nobody can distinguish their own reasoning from their own motivation at month nine, which is exactly why the line has to be written at month zero.
What none of them contain
None of the three prices what killing the project does to the people on it. A team that has spent nine months on something reads its cancellation as a judgement on them, and the good ones update their view of whether this company finishes things. That cost is real, it is not in any of these models, and it is reduced almost entirely by how the decision is explained rather than by whether it is correct.
None of them handles the project that has become load-bearing for something else. Kill analysis treats the project as separable, and by month nine other work has often been built on the assumption that it lands.
And one property the ensemble will not produce: the option to pause. All three lenses present this as continue or stop, and a third choice frequently exists, which is to reduce the project to one person and a monthly checkpoint. That preserves the accumulated knowledge at a fraction of the cost, and it is rarely on the table because the meeting was framed as a binary before it started.
The one action that survives the ignorance: before your next project review, ask everyone to write down privately the probability that it ships a specific outcome by a specific date. Collect the numbers before the discussion. If the spread is wide, the room does not have a shared view and the meeting you thought you were having is not available.
Who has to move
The founder, and the intervention belongs at the start of projects rather than at the review. The instinct in a stalled review is to ask for a plan to get it back on track, which produces a document rather than a forecast and moves the decision another quarter out. The cheapest first test costs five minutes at the top of the next review: private probabilities, written, before anyone speaks. It usually reveals that the disagreement everyone was avoiding was larger than the one they were having.
Sources and notes
- Sanjit S. Dhami, The Foundations of Behavioral Economic Analysis, Oxford University Press. The distinction between inside and outside views, and the planning fallacy in which forecasts built from case-specific detail underestimate duration and overestimate completion, sit in the part on bounded rationality. The original framing is due to Kahneman and Lovallo. Used in section 1 for the direction of the error only; no magnitude is claimed, since the size of the optimism varies with the domain and the forecaster’s experience.
- Jeffrey Carpenter and Andrea Robbett, Game Theory and Behavior, MIT Press. Prediction markets and belief elicitation, and the conditions under which aggregated judgements outperform individual ones, are treated alongside information aggregation. Used in section 2, including the requirement that judgements be roughly independent and that their errors be uncorrelated, which is why they should be collected privately. Cheap talk, the reason an unpriced opinion carries little information, is developed in the same volume.
- John D. Sterman, Business Dynamics: Systems Thinking and Modeling for a Complex World, McGraw-Hill, and Donella H. Meadows, Thinking in Systems: A Primer, Chelsea Green Publishing. The behaviour of systems in which effort accumulates in a stock and the effect appears only after a delay, and the resulting inability to distinguish a working intervention from a failing one during the accumulation phase, are developed in both. Used in section 3. The prescription that follows, to specify the expected shape of the evidence in advance, is the standard remedy for a lagged loop.
- John D. Sterman, The Beer Distribution Game, MIT, https://web.mit.edu/jsterman/www/SDG/beergame.html. Participants reliably attribute outcomes produced by their own decisions and the system’s delays to external causes that did not occur, and the effect holds for graduate students and business executives alike. Cited for the general point in section 3 that people inside a lagged system misread its state, which is why the prediction must be written before the lag is being lived through.
A note on a number this article does not give. There is no month at which a project should be killed. The threshold depends on your own completion base rate, which is why the article keeps sending you to your last five projects rather than to a benchmark. Collect two or three rounds of written probabilities and you will have a calibration nobody else can supply.
Joshua Agonya Pi’Rwot, Founder.