The project that shows up in every status meeting and never leaves
You know the one.
It was supposed to wrap last spring. The big launch happened, everyone clapped, someone brought a cake. And yet here it is, eight months later, still on the agenda. Still green, technically. Still eating an hour of someone's Thursday.
Nobody can quite say what is left to do, but nobody can say it is done either. It has become the project equivalent of a houseplant: quietly alive, gently ignored, watered just enough to keep it from dying.
These projects rarely fail loudly. They just refuse to end. And the cost of that refusal is almost invisible, which is exactly what makes it dangerous.
Let me be precise about one word before we go further. When I say "cost" here, I do not mainly mean budget. I mean capacity: the specific people, hours, and attention that stay tied up in something that should have been released back to the portfolio months ago.
Why these projects tend to survive
The never quite finished project is usually not a disaster. Disasters get killed. This thing survives precisely because it is doing fine.
A few forces keep it alive.
- The last 10 percent has no owner. The exciting work is done. What remains is documentation, a training session nobody scheduled, and two low priority defects. Real work, but unglamorous, so it drifts.
- Closing feels like admitting something. Marking a project complete invites the question "did we get the benefits we promised?" It is more comfortable to leave it open and vaguely in progress than to answer that.
- Support work wears the project's clothes. Once a thing ships, it needs care. But that care often gets logged against the original project instead of a support bucket, so the project appears to still be running.
- It is somebody's identity. People become attached. A project that closes is a story that ends. Some folks would rather keep the story going.
None of these are villains. They are ordinary human reasons. That is why the problem is so common and so quiet.
The cost you cannot see on the invoice
Here is the part that hurts. An always on project usually does not cost much money on paper. The heavy spend already happened. What it costs is far harder to spot.
It holds a claim on your scarce people.
When a senior integration specialist is officially 15 percent allocated to a project that is basically done, that 15 percent does not show up as free. So the next thing that genuinely needs her waits, or gets a less experienced substitute, or gets crammed in on top of everything else. The portfolio quietly loses flexibility, and no line item explains why.
It also crowds the attention layer. Every zombie project on the status deck is a row your PMO has to read, discuss, and reassure someone about. Ten of them turn a governance meeting into a roll call of the almost dead.
And it corrodes trust in your own data. If half your "active" projects are not really active, then your capacity numbers, your dashboards, and your forecasts are all describing a portfolio that does not exist.
The money is fine. The truth is the casualty.
A worked example: the Atlas migration that would not die
Let me make this concrete.
A mid-size operations team runs a project called Atlas, a migration of their customer records to a better platform. The cutover happens in March. It goes well. Champagne, mostly.
But Atlas stays open. Why?
- There are 42 records that failed to migrate cleanly and need manual review.
- The training video was never recorded.
- Two "nice to have" reports from the old system were promised to finance and never built.
Each item is small. So the project stays green, and one data analyst, Priya, stays allocated at 20 percent "for Atlas cleanup."
Now it is October. A higher value project, a fraud detection improvement, needs exactly Priya's skills. The PMO looks at capacity. Priya is 20 percent committed to Atlas, so the fraud project is planned around a four-fifths Priya. It slips two weeks.
Here is the tradeoff nobody made on purpose: the team chose 42 stale records and two optional reports over two weeks of fraud detection. Said out loud, that is an easy call. But it was never said out loud. It was just the quiet default of a project left open.
The fix is not heroic. Someone finally asks: what would it take to close Atlas this month? The answer:
- Write off the 42 records as a known data gap (finance signs off, five minutes).
- Move the two reports into next quarter's demand intake as their own small request.
- Convert the training video into a one-page guide.
Atlas closes. Priya is freed. The reports, if they matter, will earn their place against everything else competing for attention. If they do not matter, they quietly disappear, which tells you they never should have held a person hostage.
That is the whole trick. You force the almost done work to compete honestly, instead of coasting on inertia.
Where a portfolio view helps (and where it does not)
Most of this is a discipline problem, not a software problem. The habit of asking "is this actually done?" is what matters, and you can run it on a shared spreadsheet if you are honest with yourself.
What a portfolio tool adds is that it makes the drain visible. When you can see that Priya is 20 percent committed to a project with no open tasks, the zombie stops hiding.
Perspective does this by tying capacity and resource planning to the actual roadmap, so an open allocation with no live work stands out instead of blending in. But the principle holds with any tool, or with a whiteboard and a bit of courage: you cannot recover capacity you refuse to look at.
The honest limit: closing projects faster does not create people. It just stops pretending you have fewer of them than you do. That is progress, not magic.
How to start this week
You do not need a program for this. You need one afternoon and a willingness to be slightly annoying.
- Pull every active project and find the ones with no tasks completed in 30 days. That short list is your suspect pile.
- For each one, ask a single question: what would it take to close this? Not "how is it going." Closure specifically.
- Separate the leftover work into three buckets: genuinely required to close, real ongoing support (move it to a support bucket), and optional (send it back through intake to compete on merit).
- Set a closure date and name an owner for the required-to-close items. A project without a closing date tends to never close.
- Close the ones you can, and tell people. Celebrate the ending. Endings are a feature, not a failure.
Do this once a quarter and the zombie population stays low.
A project that cannot end is a project that never quite began to matter.