The Intellectual Friction
The weight of the projector remote in my hand felt exactly the same as it did last quarter, and the quarter before that. It’s heavy, rubberized plastic, yes, but what really gets you is the intellectual friction of presenting slides that should have been retired eighteen months ago. We call it ‘Project Seraphim,’ but the team internally calls it ‘The Undead.’ And yes, the slide that flashes up, currently, right now, says “Completion Status: 90%.”
90% is the worst number in software.
The contradiction isn’t technical; it’s existential. We know 90% means the last 10% is 90% of the actual work. But for Seraphim, 90% has become the goal itself.
It is the plateau where ambition dies and administration begins. We don’t strive for 100%; we strive to successfully explain why we didn’t hit 100% *this time*. I forgot why I walked into this meeting room this morning. Was it for the coffee? Or to argue about why the integration layer with the legacy system 7 (L7) still registers phantom transactions? This specific type of forgetting, this cognitive stutter, is exactly what these projects do to your brain: they steal the closure centers, replacing them with circular reporting mechanisms. They introduce chaos while demanding precision.
The Clarity of the Tank Cleaner
‘Done’ is when the algae is scraped clean. Terminal task, definite outcome.
Sustained by political inertia, thriving on endless maintenance.
But our corporate zombies thrive on that last 10%. They are sustained not by progress, but by political inertia. These projects justify the budget for Department T-7. They maintain the relevance of managers who staked their careers on the initial launch-a launch that never came. Killing them means admitting a massive, quantifiable failure. It means confronting the sunk cost fallacy head-on, something very few executive teams are willing to do.
$777 Million
Calculated Internal Labor Wasted on Seraphim
The budget line item for Seraphim isn’t an expense; it’s a security blanket for middle management.
The decision to keep feeding the zombie isn’t economic; it’s cowardice dressed up as commitment. The real tragedy is that this avoidance of tough cuts is ultimately what drains innovation everywhere else. We keep investing in the dead thing, hoping the investment itself will resurrect it, rather than taking the clear, necessary loss. This inability to make the hard, evidence-based call is precisely where organizations fracture. We need tools and methodologies that force clarity, metrics that don’t allow 90% to be a sustainable state.
If you’re serious about moving beyond institutional paralysis and truly making data-driven choices-choices that require you to look at the evidence, no matter how painful the conclusion-you need to understand the analytical rigor that cuts through this kind of organizational nonsense.
It’s about being able to call a project dead when the vital signs are gone, instead of spending another 237 hours writing justifications for its continued life support.
Corporate Archaeology
I remember arguing two quarters ago that we needed to make one final, focused push. My mistake wasn’t optimism; it was believing the rules of physics applied here. I thought, if we just assigned the 7 best developers, gave them four weeks, and isolated the scope creep, we could force Seraphim to the finish line. I criticized the team for lacking discipline-a classic move of someone who doesn’t understand the system they’re in. I said, “Stop doing 90% of the work perfectly and focus entirely on the final 10%.”
I was wrong. Utterly and embarrassingly wrong.
The moment we dedicated the 7 developers, the project expanded sideways. Not forward, but sideways. The legacy system integration that held us up was, we discovered, dependent on a proprietary API controlled by a subsidiary we barely talk to, requiring a license renewal fee of $7,777 every 47 days. This was never budgeted. It wasn’t the code; it was the corporate archaeology. The zombie had roots deep into the organizational structure, feeding off contracts nobody remembered signing in ’97.
I had tried to solve a political/structural problem with a technical solution. That’s like trying to stop a tidal wave with a single piece of clean code. It simply highlights your naïveté.
Project Observer
The sneaky nature of the zombie project is that it’s designed to absorb complexity and weaponize dependence. If Seraphim dies, seven other systems that feed its status reports also suddenly have no purpose, creating a political ripple effect that upper management finds far more frightening than the persistent operational expense. The rhythm of these projects is maddening. It’s all tension followed by false calm. We have a crisis (a data breach near Subsystem 7), everyone sprints, we patch it, and then we return to the medium-paced, low-stakes quarterly dance. The goal shifts from ‘launching successfully’ to ‘avoiding failure violently.’
Metabolizing Opposition
I used to critique processes mercilessly, advocating for rapid iteration and definitive endpoints. Now I understand the limitation: sometimes the limitation is the organization itself. I found myself advocating in the meeting just now-I swear I didn’t mean to-for a *less* specific timeline, arguing that pinning a date on the final 10% creates undue pressure and potential quality issues. Wait, what? I criticized this exact sentiment last year! This is the contamination. This is the moment you realize you stopped being a critic and became part of the immune system protecting the disease. The project changed me. It metabolized my opposition into organizational defense.
The project doesn’t consume time; it consumes intent.
The zombie project is, ultimately, a massive statement of organizational inertia: we are better at maintaining the failed status quo than we are at confronting difficult truths. It represents three core failures: 1) the inability to calculate total operational costs honestly, 2) the fear of admitting personal error and organizational miscalculation, and 3) the preference for continuous, moderate effort over one dramatic, defining action that might result in job cuts or loss of power. We often talk about technical debt-the shortcuts we took in code. But zombie projects create existential debt. We borrow from the future credibility of the organization to maintain the illusion of progress today.
Accountability and Vulnerability
Security Blanket
Maintains budget relevance.
No Bar Setting
Completion sets the bar for the next thing.
Infinite Loop
Easier to maintain than risk vulnerability.
I look at the 90% slide again. It isn’t a status report. It’s a monument to the fear of the final 10%. Because finishing means accountability. Finishing means the thing you built has to survive in the real world, subject to real performance reviews, not just quarterly PowerPoint presentations. If Seraphim finished, what would Department T-7 do? They would have to find a new mission. A new purpose. And that is truly terrifying to large, established structures.
“I realized the project wasn’t the product; the quarterly report *was* the product. And I didn’t want to spend the rest of my life producing reports.”
Escapee, Dept. T-7
The challenge isn’t how to fix the remaining 10%. The true challenge is figuring out how to institutionalize the bravery necessary to recognize that some things are already dead, and that the only logical move is divestment, even if the body count of sunk costs looks like $7,777,777.
The Defining Question
We need to ask ourselves a single, critical, defining question every 7 days, or every 47 days, whenever we review scope, budget, or timeline:
Are you building a deliverable, or are you just building a better tomb?
(Focusing resources on eternal justification rather than termination.)