Im Backlog liegt ein Feature, das seit achtzehn Monaten „in Arbeit“ ist. Niemand arbeitet wirklich daran, aber es wird auch nicht gestrichen.
Bei jedem Planning kommt die Frage: „Was machen wir damit?“ Die Antwort ist immer dieselbe: „Behalten wir erstmal, vielleicht brauchen wir es später.“
In der Roadmap steht ein Projekt, für das vor zwei Jahren ein Team zusammengestellt wurde. Der ursprüngliche Sponsor ist längst in einer anderen Abteilung, die Anforderungen haben sich dreimal geändert und der Prototyp liegt irgendwo zwischen „fast fertig“ und „komplett überholt“. Trotzdem läuft das Projekt formal weiter. Faktisch ist es längst tot.
Willkommen im Feature-Friedhof. Hier stapeln sich die unvollendeten Ideen, die halb fertigen Prototypen, die Features, die niemand nutzt, und die Projekte, die zwar Ressourcen binden, aber keinen Wert mehr liefern. Sie sind die Zombies der Softwareentwicklung: nicht tot und nicht lebendig. Sie fressen Budget, binden Aufmerksamkeit und blockieren Raum für Neues.
Der Jahreswechsel ist der ideale Zeitpunkt für einen ehrlichen Blick auf diese Altlasten. Nicht aus Nostalgie oder Sentimentalität, sondern aus wirtschaftlicher Vernunft. Denn jedes tote Projekt, das weitergeführt wird, kostet Geld. Jedes ungenutzte Feature verursacht Wartungsaufwand. Und jede Ressource, die in Zombies fließt, fehlt für lebendige, wertschöpfende Arbeit.
Zombie-Projekte sind Vorhaben, die formal noch existieren, faktisch aber keine Lebenszeichen mehr zeigen. Sie stehen in Backlogs, Roadmaps und Statusreports. Sie haben Teams, Budgets und manchmal sogar regelmäßige Meetings. Aber sie bewegen sich nicht mehr vorwärts. Und wenn doch, dann nur im Zeitlupentempo. Sie produzieren keine echten Ergebnisse, erzeugen keinen Nutzen und erfüllen keine strategischen Ziele mehr.
Das Tückische ist, dass Zombie-Projekte aussehen wie normale Projekte. Sie haben alle äußeren Merkmale von Aktivität. Es gibt Tickets, Commits, Deployments. Aber bei genauerem Hinsehen fehlt das Entscheidende: die Wirkung. Der Code wird nicht genutzt, das Feature bringt keinen Mehrwert, das Produkt findet keine Kunden.
Wie erkennt man Zombie-Projekte? Es gibt einige typische Warnsignale:
Der ursprüngliche Sponsor ist weg. Die Person, die das Projekt ursprünglich angestoßen und verantwortet hat, ist nicht mehr im Unternehmen, hat die Rolle gewechselt oder interessiert sich nicht mehr dafür. Niemand fühlt sich wirklich zuständig, aber das Projekt läuft weiter, weil niemand den Mut hat, es zu stoppen.
Die Anforderungen haben sich fundamental geändert. Was vor zwei Jahren Sinn ergab, passt heute nicht mehr zur Strategie. Der Markt hat sich verändert, die Technologie hat sich weiterentwickelt, oder das Unternehmen hat eine neue Richtung eingeschlagen. Aber das Projekt wurde nie offiziell angepasst oder beendet.
Es gibt keinen klaren Nutzen mehr. Die ursprüngliche Business-Case-Rechnung ist veraltet oder war von Anfang an optimistisch. Niemand kann heute noch erklären, welcher konkrete Wert aus dem Projekt entstehen soll. Wenn man fragt: „Wofür genau machen wir das?“, kommen ausweichende Antworten.
Das Team arbeitet nur noch widerwillig daran. Die Motivation ist am Boden. Entwickler wissen, dass die Arbeit sinnlos ist, machen aber weiter, weil es der Auftrag ist. In Retrospektiven wird das Projekt nicht mehr besprochen. Es ist ein unangenehmes Thema, das alle vermeiden.
Der Fortschritt ist minimal. Bei jedem Review zeigt sich, dass sich kaum etwas getan hat. Das liegt nicht an fehlender Kompetenz, sondern an fehlender Priorität. Das Projekt wird immer wieder verschoben, unterbrochen, auf Eis gelegt. Es ist nie dringend, aber auch nie ganz weg.
Keiner nutzt das Feature. Das Feature ist bereits live, aber die Nutzungszahlen sind vernichtend. 0,5 % der Nutzer haben es in den vergangenen drei Monaten angeklickt. Niemand beschwert sich, wenn es ausfällt. Es ist einfach … da.
Diese Warnsignale sind nicht subtil. Aber sie werden oft ignoriert, weil das Eingeständnis schmerzhaft ist: Wir haben Zeit, Geld und Energie in etwas investiert, das keinen Wert liefert.
Zombie-Projekte sind nicht harmlos. Sie kosten. Und zwar mehr, als auf den ersten Blick sichtbar ist.
Direkte Kosten sind der offensichtlichste Faktor. Jedes Projekt, das läuft, bindet Budget. Entwicklerzeit, Infrastruktur, Lizenzen, eventuell externe Dienstleister. Ein Team von drei Entwicklern mit durchschnittlichen Gehältern von 80.000 Euro kostet das Unternehmen grob 240.000 Euro pro Jahr. Plus Overhead. Wenn dieses Team auch nur 20 % seiner Zeit mit einem toten Projekt verbringt, sind das knapp 50.000 Euro, die jährlich verpuffen.
Aber das ist nur die Spitze des Eisbergs. Opportunitätskosten sind oft deutlich höher. Jede Stunde, die in ein totes Projekt fließt, fehlt für ein lebendiges. Jede Entwicklerin, die an einem Zombie arbeitet, kann nicht an einem Feature arbeiten, das echten Nutzen bringt. Die Frage ist nicht nur „Was kostet uns das Zombie-Projekt?“, sondern auch „Was entgeht uns, weil wir daran festhalten?“
Wenn ein Team 20 % seiner Kapazität verschwendet, bedeutet das nicht nur 20 % weniger Output. Es kann bedeuten, dass ein entscheidendes Feature nicht gebaut wird, das Marktanteile sichern oder neue Kunden gewinnen könnte. Cost of Delay macht diesen Zusammenhang greifbar: Der Wert, der nicht geschaffen wird, weil Ressourcen falsch allokiert sind.
Wartungskosten treffen besonders Features, die bereits live sind, aber niemand nutzt. Jedes Feature im System muss gewartet werden. Bei jedem Update muss geprüft werden, ob es noch funktioniert. Bei jedem Refactoring muss es berücksichtigt werden. Bei jedem Sicherheitspatch muss es getestet werden. Code, der nicht genutzt wird, ist nicht kostenlos, er ist Verschwendung.
Eine Studie von Pendo aus dem Jahr 2019 zeigt: In durchschnittlichen Software-Produkten werden 80 % der Features kaum oder gar nicht genutzt. Diese Features existieren weiter, verursachen Komplexität, binden Wartungsaufwand und verwirren Nutzer. Jedes ungenutzte Feature ist ein Zombie, der die Produktivität des gesamten Systems senkt.
Kognitive Belastung ist ein unterschätzter Kostenfaktor. Jedes Projekt im Backlog, jedes Feature in der Roadmap verbraucht mentale Energie. Teams müssen sich erinnern, dass es da ist, müssen bei jeder Priorisierung darüber nachdenken, müssen bei jedem Planning entscheiden, ob jetzt endlich der richtige Zeitpunkt gekommen ist. Diese ständige Reibung summiert sich. Ein aufgeräumtes Backlog ist übersichtlicher, es reduziert kognitive Last und erlaubt Fokus.
Kulturelle Kosten sind vielleicht die gefährlichsten. Wenn Teams wissen, dass sie an sinnlosen Projekten arbeiten, sinkt die Motivation. Wenn Zombies nie offiziell beendet werden, entsteht Zynismus: „Es ist eh egal, was wir machen – am Ende wird nichts davon genutzt.“ Die Folge sind sinkende Zufriedenheit, steigende Fluktuation, Schwierigkeiten beim Recruiting. Das SPACE Framework zeigt einen Weg, um den Zusammenhang zwischen Zufriedenheit und Produktivität zu messen. Zombie-Projekte untergraben beides.
Warum halten Organisationen an toten Projekten fest? Die Antwort liegt oft in einem der hartnäckigsten kognitiven Verzerrungen: der Sunk Cost Fallacy, dem Trugschluss der versenkten Kosten.
Die Logik ist einfach und gefährlich: „Wir haben schon so viel investiert. Wir können jetzt nicht einfach aufhören.“ Zwei Jahre Entwicklungszeit, 500.000 Euro Budget, unzählige Meetings. All das wäre „verloren“, wenn das Projekt jetzt gestoppt würde. Also wird weitergemacht. Noch ein Sprint. Noch ein Quartal. Vielleicht wird es doch noch etwas.
Das Problem: Die Kosten sind bereits versenkt. Das Geld ist ausgegeben, die Zeit ist vorbei. Diese Investitionen kommen nicht zurück. Egal, ob das Projekt weiterläuft oder gestoppt wird. Die einzige relevante Frage ist: Rechtfertigt der zukünftige Nutzen die zukünftigen Kosten?
Daniel Kahneman und Amos Tversky haben in ihrer Forschung zu Prospect Theory gezeigt, wie tief verwurzelt diese Verzerrung ist. Menschen bewerten Verluste emotional stärker als Gewinne gleicher Größe. Ein Projekt zu beenden, fühlt sich wie ein Verlust an, auch wenn es wirtschaftlich die richtige Entscheidung ist.
In Organisationen wird dieser Effekt noch verstärkt durch persönliche Verantwortung. Wer ein Projekt initiiert hat, möchte nicht als die Person in die Geschichte eingehen, die „das große Projekt in den Sand gesetzt hat“. Wer monatelang daran gearbeitet hat, möchte nicht zugeben, dass die Arbeit umsonst war. Das ist menschlich verständlich und wirtschaftlich fatal.
Die Lösung liegt in der Trennung von Vergangenheit und Zukunft. Was bereits investiert wurde, ist irrelevant. Die einzige Frage ist: Wenn wir heute von null anfangen würden, würden wir dieses Projekt starten? Würden wir diese Ressourcen dafür aufwenden? Wenn die Antwort nein ist, sollte das Projekt beendet werden. Unabhängig davon, wie viel bereits investiert wurde.
Organisationen, die psychologische Sicherheit schaffen, machen es einfacher, Fehler einzugestehen. Wenn das Beenden eines Projekts nicht als Versagen, sondern als Lernen gerahmt wird, sinkt die Hemmschwelle. „Wir haben gelernt, dass dieser Ansatz nicht funktioniert. Jetzt investieren wir in etwas Vielversprechenderes.“
Wie entscheidet man, was bleibt und was geht? Es braucht klare Kriterien und keine politischen Verhandlungen, sondern ehrliche Bewertungen. Und diese leiten sich direkt ab aus den Erkennungskriterien eines Zombie-Projekts.
Kriterium 1: Gibt es einen messbaren Nutzen? Die Frage klingt banal, wird aber erschreckend selten gestellt. Was genau soll das Projekt erreichen? Umsatzsteigerung? Kostensenkung? Nutzerzufriedenheit? Und ist dieser Nutzen messbar? Wenn die Antwort vage bleibt („strategische Bedeutung“, „langfristige Positionierung“, „Innovation“), ist das ein Warnsignal. Nicht jeder Nutzen muss in Euro messbar sein, doch er muss konkret sein.
Kriterium 2: Passt es zur aktuellen Strategie? Strategien ändern sich. Was vor zwei Jahren Priorität hatte, kann heute irrelevant sein. Die Frage ist nicht, ob das Projekt damals Sinn ergab, sondern ob es heute noch zur Ausrichtung des Unternehmens passt. Wenn die Strategie „Mobile First“ lautet und das Projekt eine Desktop-Only-Lösung ist, gibt es ein Problem.
Kriterium 3: Gibt es einen engagierten Sponsor? Jedes erfolgreiche Projekt braucht jemanden, der dafür brennt, der Verantwortung übernimmt, der Entscheidungen trifft. Wenn niemand diese Rolle ausfüllt – wenn die Frage „Wer ist eigentlich verantwortlich?“ zu peinlichem Schweigen führt – ist das Projekt faktisch verwaist.
Kriterium 4: Rechtfertigt der Nutzen die laufenden Kosten? Selbst wenn ein Feature technisch funktioniert und manche Nutzer hat, rechtfertigt der Nutzen auch die Kosten? Ein Feature, das 0,5 % der Nutzer verwenden, aber 5 % der Wartungskosten verursacht, ist ein schlechter Deal. Die Rechnung muss ehrlich gemacht werden.
Kriterium 5: Ist der Fortschritt realistisch? Manche Projekte sind nicht tot, sondern nur langsam. Aber es gibt einen Unterschied zwischen „langsam“ und „stecken geblieben“. Wenn ein Projekt seit sechs Monaten keinen echten Fortschritt gemacht hat, wenn jeder Meilenstein verschoben wurde, wenn die Timeline längst unrealistisch ist, dann hilft kein Optimismus mehr.
Kriterium 6: Würde jemand es vermissen? Der ultimative Test: Was passiert, wenn das Feature morgen verschwindet? Würden Nutzer sich beschweren? Würde ein Business-Prozess zusammenbrechen? Oder würde einfach nichts passieren? Wenn niemand es vermissen würde, ist es überflüssig.
Eine pragmatische Methode ist die 90-Tage-Regel: Jedes Projekt, das in den vergangenen 90 Tagen keinen messbaren Fortschritt gemacht hat, kommt auf die Abschussliste. Es gibt drei Monate Zeit, entweder echten Fortschritt zu zeigen oder einen klaren Grund zu liefern, warum es weiterlaufen sollte. Ohne beides wird es beendet.
Ein hilfreiches Werkzeug ist die Kill-Liste: eine Liste aller Kandidaten für die Einstellung. Die Liste wird öffentlich gemacht (zumindest innerhalb der relevanten Teams) und mit Begründungen versehen. „Feature X wird eingestellt, weil es in sechs Monaten nur 47 Klicks hatte und jährlich 12.000 Euro Infrastrukturkosten verursacht.“ Transparenz verhindert, dass Entscheidungen im Hinterzimmer getroffen werden, und schafft Akzeptanz.
Ein Projekt zu beenden, ist nicht nur eine technische oder wirtschaftliche Entscheidung, sondern auch eine emotionale. Menschen haben Zeit und Energie investiert. Manche haben sich mit dem Projekt identifiziert. Das Einstellen muss daher sorgfältig kommuniziert werden.
Ehrlichkeit ist nicht optional. Die schlechteste Variante ist das stille Sterben. Das Projekt wird einfach nicht mehr erwähnt, die Ressourcen werden umgelenkt, und niemand spricht darüber. Das erzeugt Unsicherheit und Misstrauen. Besser ist die klare Ansage wie „Wir haben entschieden, Projekt X einzustellen. Hier sind die Gründe.“
Die Begründung muss nachvollziehbar sein. Nicht: „Das Management hat entschieden.“ Sondern: „Die ursprünglichen Annahmen haben sich nicht bestätigt. Wir haben gelernt, dass der Markt anders funktioniert als gedacht. Die Ressourcen bringen woanders mehr Nutzen.“ Je transparenter die Kriterien, desto höher die Akzeptanz.
Die Investition muss anerkannt werden. „Die geleistete Arbeit war nicht umsonst. Wir haben wichtige Erkenntnisse gewonnen, die in andere Projekte einfließen.“ Das ist kein leeres PR-Geplänkel, und oft stimmt es tatsächlich. Ein gescheitertes Experiment liefert wertvolle Daten. Wichtig ist, diese Lerneffekte zu benennen.
Die Verantwortung liegt nicht beim Team. Wenn ein Projekt eingestellt wird, darf das nicht als Versagen des Teams gerahmt werden. Die Entscheidung, das Projekt zu starten, wurde auf einer anderen Ebene getroffen. Die Entscheidung, es zu beenden, liegt dort ebenfalls. Entwickler haben ihre Arbeit gemacht und die strategische Ausrichtung hat sich geändert.
Es gibt einen Plan für die Zukunft. „Was passiert jetzt mit uns?“ ist die bange Frage vieler Beteiligter. Die Kommunikation sollte diese Frage beantworten: Wohin fließen die Ressourcen? An welchen Projekten wird stattdessen gearbeitet? Wie geht es weiter? Unsicherheit ist lähmend. Klarheit befreit.
Das Einstellen ist kein Tabu. In vielen Organisationen wird das Beenden von Projekten als Misserfolg betrachtet. Das ist fatal. Eine gesunde Innovationskultur akzeptiert, dass nicht alles funktioniert. Wenn 100 % aller gestarteten Projekte erfolgreich sind, wurde nicht genug experimentiert. Das Einstellen von Projekten sollte als notwendiger Teil eines lernenden Systems normalisiert werden.
Ein gutes Format ist die „FLAP“-Retrospektive. Statt nur zu fragen „Was lief schief?“, wird gefragt „Was haben wir gelernt?“ und „Wie nutzen wir dieses Wissen für zukünftige Entscheidungen?“. Das deutet das Einstellen als Lernchance, nicht als Niederlage.
Was passiert, wenn Zombies tatsächlich beerdigt werden? Die Effekte sind oft verblüffend schnell sichtbar.
Mehr Fokus. Weniger Projekte bedeuten mehr Aufmerksamkeit für die richtigen Dinge. Teams können sich konzentrieren, anstatt zwischen zehn parallelen Baustellen hin- und herzuspringen. Das reduziert die Kosten von Multitasking und Kontextwechseln dramatisch. Ein Team, das an drei Projekten gleichzeitig arbeitet, liefert nicht dreimal so viel wie ein Team, das sich auf eines konzentriert, sondern oft weniger.
Schnellere Lieferung. Mit weniger Projekten im System steigt die Durchlaufgeschwindigkeit. Features werden schneller fertig, weil sie nicht ständig warten müssen. Das verbessert direkt die Time-to-Market und damit die Wettbewerbsfähigkeit. Die Liefergeschwindigkeit steigt nicht durch mehr Story Points, sondern durch weniger Work-in-Progress.
Höhere Qualität. Wenn Teams sich nicht zwischen fünf Projekten zerreißen müssen, bleibt Zeit für Sorgfalt. Code wird sauberer, Tests werden geschrieben, Dokumentation entsteht. Das reduziert Technical Debt und macht zukünftige Entwicklungen schneller und günstiger.
Bessere Moral. Nichts ist frustrierender, als an Projekten zu arbeiten, die nirgendwohin führen. Wenn Zombies beerdigt werden und die Energie in lebendige, sinnvolle Arbeit fließt, steigt die Zufriedenheit. Teams spüren, dass ihre Arbeit zählt. Das steigert Motivation, senkt Fluktuation und macht das Unternehmen attraktiver für Talente.
Klarere Kommunikation. Ein Backlog mit 30 halblebendigen Features ist verwirrend. Ein Backlog mit 10 klaren, priorisierten Features ist verständlich. Stakeholder wissen, woran gearbeitet wird. Kunden wissen, was sie erwarten können. Die Kommunikation wird ehrlicher und effektiver.
Mehr Raum für Neues. Das ist vielleicht der wichtigste Punkt: Solange Zombies Ressourcen binden, ist kein Platz für neue Ideen. Innovation braucht Kapazität. Nicht nur budgetär, sondern auch kognitiv. Erst wenn Altes losgelassen wird, entsteht Raum für Neues. Continuous Improvement bedeutet auch, regelmäßig aufzuräumen.
Ein praktischer Ansatz ist die jährliche Portfolio-Review. Einmal im Jahr – idealerweise zum Jahreswechsel – wird das gesamte Projekt- und Feature-Portfolio durchgegangen. Jedes Projekt muss sich neu rechtfertigen. Die Frage ist nicht „Warum sollten wir es beenden?“, sondern „Warum sollten wir es weiterlaufen lassen?“. Die Beweislast wird umgekehrt.
Das bedeutet nicht, dass langfristige Projekte unmöglich werden. Aber sie müssen aktiv verteidigt werden. „Dieses Projekt läuft noch zwei Jahre, weil wir konkrete Meilensteine haben, messbare Fortschritte machen und es strategisch zentral ist.“ Das ist legitim. „Dieses Projekt läuft, weil wir es immer schon gemacht haben“, ist es nicht.
Der Feature-Friedhof existiert in fast jeder Organisation. Zombie-Projekte, die formal leben, faktisch aber tot sind. Features, die niemand nutzt, aber Wartungskosten verursachen. Initiativen, die vor Jahren Sinn ergaben, heute aber überholt sind. Sie binden Ressourcen, belasten Teams und blockieren Innovation.
Der Jahreswechsel ist der ideale Moment für eine ehrliche Bestandsaufnahme. Nicht aus Nostalgie, sondern aus wirtschaftlicher Vernunft. Denn die Kosten des Am-Leben-Haltens sind real: direkte Kosten durch verschwendetes Budget, Opportunitätskosten durch verpasste Chancen, Wartungskosten durch unnötige Komplexität, kognitive Kosten durch Ablenkung und kulturelle Kosten durch sinkende Motivation.
Die größte Hürde ist oft psychologischer Natur. Die versenkten Kosten erscheinen so groß, dass Weitermachen wie die einzige Option wirkt. Aber bereits investierte Ressourcen kommen nicht zurück, egal, wie die Entscheidung ausfällt. Die einzige relevante Frage ist: Rechtfertigt der zukünftige Nutzen die zukünftigen Kosten? Wenn die Antwort nein lautet, ist Beenden die wirtschaftlich richtige Wahl.
Der Feature-Friedhof ist kein Scheitern. Er ist die Realität komplexer, sich verändernder Systeme. Die Frage ist nicht, ob er existiert, sondern wie damit umgegangen wird. Organisationen, die regelmäßig aufräumen, die Zombies begraben und Ressourcen auf lebendige Projekte konzentrieren, sind effektiver und langfristig erfolgreicher.
Das neue Jahr ist die Gelegenheit für einen Neuanfang. Nicht durch noch mehr Projekte, noch mehr Features, noch mehr Initiativen. Sondern durch Fokus. Durch das Loslassen dessen, was nicht mehr funktioniert. Durch den Mut, ehrlich zu sein: Das war eine gute Idee, aber sie ist vorbei. Jetzt investieren wir in das, was wirklich zählt.
Buchen Sie jetzt Ihre kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Sie am wirkungsvollsten unterstützen kann.