You know the project. The one that was supposed to die in 2019. It had a clear mission, a launch date, a hero demo. It shipped. You closed it. And then someone opened a defect in it three weeks later. So you reopened it. Now it’s 2026, and that \”temporary\” project has more history than a small country. Nobody can close it. Nobody dares.
\n\n
That’s not a management failure. That’s not a training problem. That’s a structural flaw in every enterprise software product that still treats a project as a permanent home for work that refuses to die. And until you see it, you’ll keep building zombie projects—and blaming yourself.
\n\n
Here’s the twist: Most \”projects\” in your platform are not projects at all. They are homes. They’re where products, teams, and business capabilities live for years. You just labeled them \”project\” because your software gave you no other choice. Then you forced them into a lifecycle they were never built to survive.
\n\n
The Three Faces of \”Project\”
\n\n
Listen to yourself the next time you say the word. \”The payment project.\” Is that the one-time initiative to migrate to a new gateway? Or the permanent team and product infrastructure that’s been running for five years? Or the department? You’re using one word for three completely different things.
\n\n
Real projects are temporary. They have an end date. Project management 101 says so. But your product’s roadmap isn’t temporary. The team isn’t temporary. The service’s lifecycle isn’t temporary. When you force these permanent facts into a container that’s supposed to end, you create an ontological explosion—and you clean it up with duplicated work, endless migrations, and projects you’re afraid to touch.
\n\n
Jira noticed. They renamed their Project to Space. But as they’ll admit, it was mostly a term change. Your underlying model is still the problem.
\n\n
The Square Peg, The Round Hole, and the Zombie Graveyard
\n\n
Here’s what happens when you conflate long-term ownership with temporary delivery:
\n\n
- \n
- You can’t close the project because history lives there.
- You create \”Project 2.0\” every year and lose all context.
- You copy the same fields, workflows, and members—and watch them drift.
- You set two statuses called \”Done\” that mean completely different things.
\n
\n
\n
\n
\n\n
Never attach a permanent fact to a temporary container. It will either outlive the container or die with it. That’s the principle that should guide your information architecture.
\n\n
The solution isn’t to rename everything \”Space.\” It’s to separate ownership from delivery. A work item belongs to one stable Space—its permanent home, with a stable identifier and a long-lived history. It can then enter any number of Projects, iterations, versions, or goals—each of those is just a delivery context. Temporary. Interchangeable.
\n\n
Think of it this way: Your key employee belongs to the company. She temporarily joins a task force. The task force ends. She’s still employed. You don’t clone her to keep the task force alive. You don’t delete her when the task force disbands. So why do we do that to work items?
\n\n
Your Project Is a Lie. Here’s the Truth.
\n\n
Take a hard look at your most painful project. The one with the end date field that’s been empty for three years. That’s not a project. That’s a Space wearing a project costume. If it can’t die, it’s not a project. It’s a home.
\n\n
When you finally accept that, the architecture simplifies:
\n\n
- \n
- The Space holds the product, the service, the long-term facts.
- The Project is a bounded initiative with a goal, a budget, and an end.
- Projects reference Spaces. They don’t replace them.
\n
\n
\n
\n\n
Now, when the project closes, the work doesn’t die. It stays home. The defect that comes in six months later finds the same work item, the same history, without resurrecting a zombie project.
\n\n
How to Stop the Zombie Apocalypse
\n\n
Stop starting every quarterly initiative as a new project. Look at what you already have. Is that five-year-old \”Payment Processing Upgrade\” project still taking new requests? Is there a \”Q1 Product Launch\” project that’s been running for six quarters? Those are Spaces. Give them a permanent home. Let the next delivery be a project that briefly wraps them.
\n\n
You don’t need to redesign your entire platform overnight. Start by identifying your undead projects. Then ask one question: Which part of this project is permanent, and which is temporary? Permanent goes to the Space. Temporary stays in the Project. Yes, it’s that simple. And no, it’s not easy.
\n\n
You’ll fight old habits. You’ll fight vendor features. You’ll fight colleagues who think \”project\” and \”team\” are synonyms. But every time you refuse to create a new project for an old fact, you save a future admin from a data-migration nightmare.
\n\n
The project can end. The fact cannot. Build a structure where that’s true, and you’ll stop fighting your software—for the first time in years.
FAQ
Q: What is the key takeaway?
A: See the article.