Key takeaways
- Kill criteria are cheapest to write on the day a project is approved, while everyone is optimistic and nobody is defending a decision they already made.
- Meeting a kill criterion triggers a review, not a cancellation. Conflating the two is why most organizations refuse to write criteria at all.
- The cancellation meeting has exactly three permitted outcomes: continue, restructure, or cancel. "Come back with more information" is the outcome that keeps dead projects alive.
- Sunk cost is beaten by a question, not a lecture. Ask the board to approve the remaining cost for the remaining benefit as though it were a new request today.
- Track portfolio stop rate: the share of active projects cancelled in a year. A portfolio that stops nothing is not disciplined, it is not deciding.
Project cancellation is the decision to stop a project that is still running, before it delivers, because the value it can still produce no longer justifies the cost of finishing it. It is a portfolio decision rather than a project management one, and it is made by whoever holds the funding, usually a steering committee or a portfolio board, against criteria that should have been agreed long before the project got into trouble.
That is the only definition on this page. The rest is the mechanics: what the criteria should measure, who calls the meeting, what the three permitted outcomes are, how to harvest value out of work that is about to stop, what to write down, and how to tell whether your organization is capable of stopping anything at all.
Why cancelled projects are so rare, and so late
Ask a PMO how many projects it cancelled last year and the answer is usually zero. Ask how many projects finished late, over budget, and delivered something nobody uses, and the answer is not zero. Both things are true at once, and the gap between them is the whole subject of this page.
Cancellation is rare because the cost of proposing it is personal and the cost of avoiding it is institutional. The person best placed to see that a project is finished is the project manager, who is also the person with the most to lose from saying so. Above them sits a sponsor who put their name on the business case and defended it in a room full of peers. Neither of them is going to open a meeting by suggesting the thing they are responsible for should stop. So the project continues, quietly consuming people who could be somewhere else, until it becomes so obviously dead that stopping it costs nobody anything because everybody already knows.
The delay is expensive in a way that does not show up in any variance report. A project that should have stopped in March and stops in November spends eight months of a team that a different project needed, and it spends them at full rate. The money is only part of it. The scarcer resource is the attention of the people who would have been the difference on something with a future, which is the same argument that cost of delay makes about sequencing, applied to the decision to stop rather than the decision to start.
The fix is structural, not cultural. You cannot exhort people into raising cancellation when raising it is professionally expensive. What you can do is arrange for the question to be asked by a process rather than by a person, on a date nobody chose, against thresholds agreed when the project was popular. That is what kill criteria are for.
Kill criteria: write them the day you approve the project
Kill criteria are pre-agreed, measurable conditions that trigger a formal review of whether a project should continue. They belong in the business case, written at approval, alongside the benefits the project is promising. Writing them at approval is the entire trick. On approval day the sponsor is confident, the estimates are fresh, and nobody is defending anything, so a sentence like "if the forecast completion date moves past Q3 we will reassess" costs nothing to agree. Eighteen months later that same sentence is an accusation.
Good criteria measure three different things, because projects die in three different ways. They run out of schedule, they run out of money, or the reason they existed stops being true. The third one is the one nobody writes down and the one that ends the most projects.
| Trigger class | What it measures | Example threshold | Why it belongs |
|---|---|---|---|
| Schedule | Current forecast completion against the date approved in the business case | Forecast slips beyond the approved date by more than one quarter, or the delivery date has moved twice | Catches the project that is progressing but will arrive after the window it was justified by |
| Cost | Estimate at completion against the approved budget | Estimate at completion exceeds approved budget by more than 25 percent | Uses a forecast, not spend to date, so it fires before the money is gone |
| Strategic assumption | Whether the specific assumptions in the business case still hold | A named assumption fails: the regulation is withdrawn, the partner exits, the product it supports is retired | The only class that catches a project delivering perfectly toward something nobody needs |
| Benefit | Whether the benefit case survives the current forecast | Forecast benefits fall below the cost still to spend | Ties the stop decision to value rather than to variance |
| Capability | Whether the project can still be staffed or supplied | A critical role or vendor unavailable for more than two months with no replacement | Names the practical failure that otherwise gets reported as amber forever |
Swipe to see more →
Two rules make the difference between criteria that fire and criteria that decorate a document. First, each threshold must be a number or a named event, not an adjective. "Significant slippage" is not a criterion because two reasonable people will disagree about whether it has happened, which returns the decision to the politics it was supposed to escape. Second, the strategic assumption criterion must name specific assumptions from that project's own business case, not generic ones. "The market may change" is unfalsifiable. "This depends on the vendor keeping the current API available until 2028" is a criterion that a person can check.
Attach the criteria to the approval record itself. In practice this means one extra section in the business case template, carried forward into the project charter so the project manager has them from day one. Criteria that live only in a governance policy document apply to nothing.
A kill criterion is not a kill decision
This is the distinction that makes the whole mechanism acceptable to the people who have to agree to it. A kill criterion firing does not cancel a project. It obliges a specific forum to look at the project and choose, on the record, between continuing, restructuring, and cancelling. Nothing stops automatically, and nobody is condemned by a threshold.
Organizations resist writing kill criteria because they hear them as automatic execution, and they are right to resist that version. Automatic cancellation on a numeric trigger would kill good projects that are late for defensible reasons and would teach everybody to manage the number instead of the work. Forecasts would improve overnight and mean nothing, in the same way that a RAG status scale with consequences attached to red produces a portfolio with no red in it.
Separating the trigger from the decision solves both problems at once. The trigger is mechanical, so raising it is not an act of disloyalty by any individual. The decision is human, so context still counts. The project manager who reports that a criterion has been met is following a procedure, not making an accusation, and that is precisely why they will actually report it.
The project cancellation checklist
Once a review is triggered, the work runs in a fixed order. Skipping straight to the meeting produces a decision nobody can defend a week later, and skipping the salvage steps means the value already paid for leaves with the team.
| # | Step | Owner | Output |
|---|---|---|---|
| 1 | Confirm the criterion actually fired, with evidence rather than opinion | Project manager | One page stating which criterion, the measured value, the source |
| 2 | Rebuild the forecast: cost to complete, date to complete, benefits still achievable | Project manager with finance | Current estimate at completion and revised benefit forecast |
| 3 | Price the restructure option honestly, including a reduced scope that still delivers something | Project manager with sponsor | A named smaller version with its own cost, date and benefit |
| 4 | Price cancellation itself: exit costs, contract commitments, write offs, redeployment | Finance with procurement | Total cost of stopping, which is never zero |
| 5 | Assemble the decision pack and circulate it before the meeting, not in it | PMO | Pack issued at least two working days ahead |
| 6 | Hold the decision meeting with one item on the agenda | Steering committee or portfolio board | Continue, restructure, or cancel, recorded with reasons |
| 7 | Run the salvage inventory before the team disperses | Project manager | Harvested assets, documented decisions, transferable licenses |
| 8 | Stop committed spend: purchase orders, contractor extensions, subscriptions | Procurement with finance | Closed commitments and a final cost position |
| 9 | Tell the team, then the stakeholders, in that order and on the same day | Sponsor with project manager | Communication done before the news travels informally |
| 10 | Release people to named destinations, not to a pool | Resource manager | Every person has their next assignment before the project closes |
| 11 | Write the decision record and file it where the next team will find it | PMO | Cancellation record in the portfolio archive |
| 12 | Close the project formally so it stops appearing in reporting | PMO | Portfolio and financial systems updated |
Swipe to see more →
Step 4 is the one most often skipped, and skipping it produces bad decisions in both directions. Cancellation always has a price: contract termination clauses, hardware already bought, a partner integration that has to be unwound, redundancy or redeployment costs, and occasionally a regulatory commitment that does not care whether you cancelled. A board that has not seen that number is comparing an honest cost of continuing against an imagined cost of zero for stopping, and it will stop things it should have restructured.
Step 10 matters more than its position suggests. If people leave a cancelled project into an unallocated pool, cancellation becomes visibly career damaging and the next team will fight much harder to keep a doomed project alive. Named destinations, arranged before the announcement, are what make it safe to stop things. The mechanics of that sit in resource allocation and in whatever resource contention queue the organization already runs.
The cancellation meeting: continue, restructure, or cancel
One agenda item, three permitted outcomes, and a rule that the meeting does not end without one of them. The three-outcome structure is what stops the meeting from doing the thing that comes naturally, which is to ask for more analysis and reconvene, and to keep doing that until the question answers itself by the project running out of runway.
| Outcome | What it means | What the board must also do |
|---|---|---|
| Continue | The project proceeds broadly as planned | Re-approve the revised cost and date explicitly, and reset the kill criteria against the new baseline. Continuing on the old criteria means they can never fire again. |
| Restructure | A smaller or differently shaped project proceeds | Approve the reduced scope as a new commitment with its own benefits, budget and criteria. Restructuring without re-approving is how a project quietly loses its purpose and keeps its funding. |
| Cancel | The project stops and is closed | Authorize the exit costs, name the release destinations for the team, and state the criterion that fired so the record is about a threshold rather than a person. |
Swipe to see more →
Notice that all three outcomes create an obligation for the board, not just for the project. That is deliberate. A governance forum that can send a project away with an instruction and no commitment of its own is not governing, it is commentating, which is the failure mode described in more detail on the steering committee page.
The prohibition on a fourth outcome deserves stating in the terms of reference. "Defer pending further information" is legitimate exactly once, with a named date inside four weeks and a named person owning the missing information. A second deferral on the same project is a decision to continue, and should be recorded as one, so that the cost of the choice lands somewhere visible rather than disappearing into a calendar.
Who decides, and who should not
The decision belongs to whoever can reallocate the money, which is the portfolio board or the steering committee, not the project. The more useful question is who should be kept out of the decision, because the seniority that makes someone a good sponsor makes them a poor judge of whether their own project should live.
| Role | In the decision? | Why |
|---|---|---|
| Portfolio board or steering committee | Decides | Holds the funding and can reallocate it, so it is the only body for which cancellation is a real choice rather than a loss |
| Project sponsor | Presents, does not decide alone | Authored the business case. Asking them to rule on their own project is asking them to grade their own judgment in public |
| Project manager | Provides the forecast and evidence | Owns the numbers the decision rests on. Should not be asked to recommend cancellation of their own assignment |
| PMO | Assembles the pack, holds the process | The only neutral party, and the one that can insist the criterion is measured the same way for every project |
| Finance | Prices both options | Supplies estimate at completion and the cost of stopping, and neither number should come from the project alone |
| Delivery team | Not present | People do not give an honest read on feasibility in the room that decides their next six months |
Swipe to see more →
The sponsor exclusion is the contentious one and it is worth being precise about it. The sponsor absolutely should present the case and argue for their preferred outcome. What they should not do is chair the meeting or hold the deciding vote, because the sunk cost pressure lands hardest on the person whose reputation is attached to the original approval. Governance forums that let the sponsor decide their own project's fate produce portfolios where nothing is ever cancelled, and the decision rights that prevent this belong in the governance framework rather than being settled in the moment.
The test that defeats sunk cost thinking
Sunk cost is usually explained as a psychological bias and then left there, which helps nobody in a meeting. The operational version is a single question the chair asks out loud: if this project did not exist today, and someone brought us the remaining work at the remaining cost for the remaining benefit, would we fund it?
The question works because it changes what is being compared. Left to itself, a board compares the money already spent against the benefit still promised, and the money already spent argues for continuing. The reframe compares the money still to spend against the benefit still available, which is the only comparison that can change anything, because the earlier money is gone under every option on the table.
Two supports make the question answerable rather than rhetorical. The first is a genuine estimate at completion, produced independently of the project, which is why earned value management exists in organizations that do it properly. The second is a comparison against what else the money could fund. A project that is marginal on its own merits is easy to continue and hard to defend the moment it sits next to three approved-but-unfunded items from the pipeline. Bringing that list into the room is the single most effective thing a PMO can do to make cancellation thinkable.
Expect the argument that stopping now wastes everything spent so far. It does not. The money was spent buying information, and the information is that this will not work at an acceptable cost. That is a real return, and the organizations that learn to say it out loud are the ones that can afford to start ambitious things at all.
The salvage inventory: harvest before the team disperses
A cancelled project has usually produced something worth keeping, and there is a window of about two weeks in which the people who know what it is are still available. After that the knowledge leaves with them and the next team pays for it again, typically two years later, without ever knowing this attempt happened.
| Asset | What to do with it |
|---|---|
| Requirements and process analysis | Usually the most reusable output. File it against the business capability, not the project name, or nobody will ever find it |
| Vendor evaluations and pricing | Keep with the date attached. Still useful for eighteen months and expensive to redo |
| Working code, models, or configuration | Identify the parts with standalone value and give them an owner, or archive them explicitly. Unowned code is not an asset |
| Licenses, hardware, environments | Reassign or cancel deliberately. Subscriptions renew silently long after the project stops |
| Contracts and open commitments | Terminate or novate. Check notice periods before the announcement, not after |
| The reason it failed | The most valuable output and the one most often lost, because nobody wants to write it down |
| The team | Named next assignments, arranged before the announcement |
Swipe to see more →
The filing point in the first row is not a small detail. Material archived under a cancelled project's name is effectively deleted, because the next team searches for the capability, not for a project they have never heard of. Whatever repository the organization uses, the test is whether someone can find the vendor evaluation two years later by searching for what it was about rather than by knowing which project produced it. That same principle governs how the rest of a portfolio's paperwork becomes usable, which is the subject of turning project documents into portfolio data.
Open commitments deserve their own pass. Cancellation stops the work but not the spending: contractor extensions already signed, purchase orders raised against next quarter, cloud environments provisioned and forgotten. Somebody has to walk the committed cost line item by line item, and the discipline for that is the same one described in project budgets and purchase orders.
Telling the team before they hear it somewhere else
Tell the delivery team first, in person, on the same day the decision is made, and before any wider announcement. This is not courtesy. A team that learns its project is cancelled from a portfolio report or a corridor conversation concludes that the organization did not think their six months were worth a meeting, and that conclusion follows them into their next project.
Say three things and resist the urge to soften them. What was decided, which criterion drove it, and where each person goes next. The second is the one that changes how cancellation is understood: a project stopped because the forecast completion date moved past the window the business case depended on is a different story from a project stopped because the team underperformed, and only the first one is usually true. Naming the criterion is what stops people writing the second story for themselves.
For everyone outside the team, keep it short and factual, and make sure it goes out through the channels the communication plan already uses rather than as an exception. Stakeholders who invested time in requirements workshops deserve to hear it directly, and the ones with the strongest reactions are usually visible in advance on the stakeholder map. Announcing cancellation as though it were a scandal teaches the organization that stopping is shameful, which is the opposite of what a portfolio needs.
The cancellation decision record
Write one page and file it in the portfolio archive. Its purpose is not compliance. It is to make the next cancellation easier, by proving that the last one was made against stated criteria by a named forum and that the organization survived it.
| Field | Content |
|---|---|
| Decision and date | Cancelled, restructured, or continued, and when |
| Criterion that fired | The specific threshold, its measured value, and the source of that measurement |
| Options considered | All three, with the cost and benefit of each, including the priced restructure |
| Decision forum | Which body decided and who attended |
| Financial position | Spent to date, committed, cost of exit, budget released |
| Assets retained | What was salvaged and where it is filed |
| Benefits withdrawn | Which promised benefits come out of the portfolio forecast, so the plan stays honest |
| What we would do differently | Two or three sentences, written about the decision process rather than about individuals |
Swipe to see more →
The benefits row is the one PMOs forget, and forgetting it corrupts the portfolio's numbers for years. Benefits promised by a cancelled project sit in the forecast until somebody removes them, and a forecast that includes returns from work nobody is doing will overstate portfolio performance until the gap becomes unexplainable. Removing them is a normal part of benefits realization management, and it should happen in the same week as the decision.
Write the record about the threshold, not the person. A cancellation record that reads as a verdict on a project manager guarantees that the next person in the same position will not report the criterion when it fires, and the mechanism dies quietly the first time it is used that way.
Portfolio stop rate: the number that says whether you decide at all
Portfolio stop rate is the share of active projects cancelled or materially restructured during a year, counted at the portfolio level rather than per project. It is a governance health measure, not a performance target, and it answers a question no other portfolio metric asks: is this organization capable of changing its mind about something it has already funded?
| Annual stop rate | What it usually indicates |
|---|---|
| 0 percent | Not discipline. Either projects are never reviewed against criteria, or cancellation is politically impossible. The most common reading by a wide margin |
| 1 to 5 percent | Stopping happens but only in obvious cases, usually late and usually after the money is gone |
| 5 to 15 percent | A portfolio that reviews and acts. Normal for organizations doing genuinely uncertain work |
| Above 20 percent | Look upstream instead. The problem is probably approval, not delivery: too much entering the portfolio on weak cases |
Swipe to see more →
Treat these as bands to calibrate your own history against rather than as external benchmarks, because the right number depends entirely on how uncertain the work is. A portfolio of regulatory and infrastructure projects should stop almost nothing, since those projects have to happen. A portfolio of product bets that stops nothing is not making bets, it is making commitments, and it will find out which ones were wrong at the most expensive possible moment.
The diagnostic value is in the pairing. Read stop rate next to the share of projects that finish late or deliver reduced scope. An organization with a zero stop rate and a large late-and-descoped population is cancelling projects, just without admitting it, by starving them slowly instead. That combination is worth more attention than either number alone, and it belongs alongside the other portfolio metrics a PMO reports.
Five ways project cancellation goes wrong
The zombie project. Never cancelled, just defunded to a trickle. Two people remain, the reporting line stays open, and the project appears in the portfolio for another three years consuming governance attention out of all proportion to what it produces. Zombies exist because defunding requires no decision and no announcement. The cure is a rule that any project below a minimum viable staffing level goes to the board for an explicit continue or cancel.
Rename and relaunch. The project is cancelled on Friday and reappears in the next intake round with a new name, a new sponsor, and substantially the same scope. Sometimes this is legitimate reframing. More often it is the same commitment escaping its own history. A cancellation record that the intake process actually checks is the only real defense.
Death by descoping. Each time the project is in trouble a piece of scope comes out, until what remains delivers none of the benefit the case was built on but still costs most of the original budget. Nobody ever decided to build the shrunken thing. The check is simple and rarely applied: whenever scope is cut through change control, restate the benefits, and if the remaining benefits no longer justify the remaining cost, the project has just met a kill criterion.
Cancellation by attrition. People are reassigned one at a time until the project cannot proceed and stops by itself. This is the most expensive version because it takes the longest and produces no decision, no record, and no salvage. It is also invisible in reporting, since the project stays green until the week it stops existing.
Cancelling the evidence instead of the project. The review finds serious problems, and the response is to change the reporting: a new format, a different status scale, a fresh baseline that resets the variance to zero. Re-baselining has legitimate uses, but a re-baseline that immediately follows a bad review and resets the kill criteria is the mechanism defeating itself. Any reset of criteria should be an explicit board decision recorded as one.
Where this fits alongside gates, health checks, and closure
Cancellation sits in a crowded neighborhood, and most confusion about it is really confusion about which of these five things somebody means. This page owns one of them: the decision to stop a project that is still running.
| Mechanism | What it owns | When it happens |
|---|---|---|
| Project cancellation (this page) | The decision to stop an in-flight project before it delivers | Whenever a criterion fires, which is deliberately unscheduled |
| Stage gate process | The scheduled go or no go decision between phases | At fixed points in the lifecycle, agreed in advance |
| Project health check | Independent diagnosis of how a project is really doing | Before the decision. It produces evidence, not a verdict |
| Post implementation review | Looking back at a project that finished and delivered | After go live, once benefits can be observed |
| Portfolio review meeting | The recurring review of the whole funded portfolio | Monthly or quarterly, across all projects at once |
Swipe to see more →
The health check relationship is the one to get right. A health check produces findings; it does not stop anything. Running a health check and treating its report as a cancellation decision skips the forecast rebuild, the priced restructure option, and the cost of exit, which are exactly the three things that make the decision defensible. In practice the sequence is: a criterion fires, a health check supplies independent evidence if the situation is contested, and the board then makes the call.
The gate relationship is complementary rather than competing. Gates are scheduled, which is their strength and their weakness: a project that becomes untenable in month two of a nine month phase will sail on until the next gate unless something else can trigger a review. Kill criteria are that something else. Organizations running a stage gate review discipline should still write criteria, precisely so the calendar is not the only thing that can stop a project.
Finally, cancellation is where portfolio management stops being a planning exercise. Choosing what to start is comparatively easy, because starting things is popular and the money is theoretical. Choosing what to stop is where the funding actually gets reallocated, and a portfolio governance arrangement that has never done it has not yet been tested.
Frequently asked questions
What is project cancellation in project management?
Project cancellation is the decision to stop a project before it delivers, taken by the body that funds it because the remaining benefit no longer justifies the remaining cost. It is distinct from project closure, which is the administrative process of shutting a project down and applies whether the project succeeded, failed, or was cancelled.
When should a project be cancelled?
When the value it can still deliver is worth less than the cost of finishing it, or when the assumption it was approved on has stopped being true. In practice the trigger should be a pre-agreed kill criterion: a schedule, cost, benefit, or strategic assumption threshold written into the business case at approval, which obliges the board to review rather than cancelling anything automatically.
Who has the authority to cancel a project?
Whoever controls the funding, normally the portfolio board or the steering committee. The sponsor presents the case and argues their position but should not hold the deciding vote on their own project, because the pressure of having authored the original business case makes an impartial judgment unlikely. The PMO runs the process and the project manager supplies the forecast.
What are kill criteria in project management?
Kill criteria are measurable conditions, agreed when a project is approved, that trigger a formal review of whether it should continue. Typical criteria cover forecast slippage beyond an agreed date, estimate at completion exceeding budget by a set percentage, and the failure of a named business case assumption. Meeting one starts a review; it does not cancel anything by itself.
What is the difference between project cancellation and project closure?
Cancellation is a decision, closure is a process. Cancellation means the funding body has chosen to stop an in-flight project. Closure is the set of administrative steps that follow any ending, including handing over assets, closing contracts and budgets, releasing the team, and archiving records. Every cancelled project goes through closure, but most closures follow successful delivery.
How do you tell a team their project has been cancelled?
In person, on the day of the decision, before any wider announcement. Cover three things: what was decided, which criterion drove it, and where each person goes next. Naming the criterion matters because it makes the decision about a threshold rather than about the team's performance, and having named destinations ready is what stops cancellation from looking career damaging.
What happens to the budget when a project is cancelled?
The uncommitted balance returns to the portfolio and becomes available for reallocation, but not all of it. Exit costs come out first: contract termination, commitments already raised, environments and licenses still running, and any redeployment cost. Committed spend has to be closed deliberately, because purchase orders and subscriptions continue long after the work stops.
Is it a failure if a project is cancelled?
Not usually. A project cancelled early on evidence is a governance success, because the money still unspent goes somewhere better. The failure is the project that should have stopped and did not, or the one that ran eight months past the point where everyone knew. What deserves examination is how long the decision took, not that it was taken.
How do you document a project cancellation?
Write a one page decision record covering the decision and date, the criterion that fired with its measured value, all three options considered with their costs, the forum that decided, the financial position including exit costs, the assets retained and where they are filed, and the benefits withdrawn from the portfolio forecast. Write it about the threshold rather than about individuals.
What percentage of projects are cancelled?
There is no reliable universal figure, and the widely circulated numbers come from surveys with inconsistent definitions of both cancellation and failure. The more useful measure is your own portfolio stop rate over several years. Most organizations that measure it for the first time find it is zero, which is a finding about their governance rather than about their projects.
Should kill criteria be reset when a project is re-baselined?
Only as an explicit board decision, recorded as one. Re-baselining with an automatic criteria reset is the most common way the mechanism is quietly defeated, because it means a project can absorb any amount of slippage as long as it re-baselines each time. When the board re-approves a revised cost and date, it should set the new thresholds in the same decision.
Last updated August 2026.