Warum Softwareprojekte gerne eskalieren – Chaos as a Service
Software erblickt oft im Rahmen von Entwicklungsprojekten das Licht der Welt. In vielen Projekten läuft es häufig gut, manch andere leiden unter vielfältigen Problemen, und wieder andere fahren völlig gegen die Wand. Wenn Projekte also Probleme haben oder scheitern, dann liegt das aber häufig nicht (nur) an der Technik, sondern an bestimmten, immer wiederkehrenden Mustern.
Dabei könnte es doch so einfach sein: Ein Entwickler startet in ein Projekt, er weiß, was er zu tun hat, versteht die Anforderungen, beherrscht die Technik und bietet am Ende dem Kunden eine Anwendung mit echtem Mehrwert. Aber häufig ist es leider so, dass es kleinere oder größere Probleme unterschiedlichster Art gibt, welche dafür sorgen, dass man nicht so arbeiten kann, wie man es gerne will, oder dass sie auch den Grund dafür darstellen, dass die Projekte komplett ins Stocken geraten.
Dieser Artikel identifiziert einige dieser Problemstellungen, zeigt potenzielle Reaktionsmuster auf und bietet, soweit möglich, konkrete Handlungsoptionen. Daher betrachten wir im folgenden einige klassische Problemstellungen aus diesen Bereichen:
- Strukturelles
- Menschliches & Soziales
- grundsätzlich projektbezogene Problemfaktoren
- Technologie
Strukturelle Probleme
Ein solides Projektfundament besteht nicht nur aus Code, sondern vielmehr aus Klarheit: über Ziele, Zuständigkeiten, Prozesse. Wenn die Struktur bröckelt, dann hilft auch das kompetenteste Team nicht. Die folgenden Probleme treten besonders häufig auf – oft schleichend und unbemerkt.
Unklare Anforderungen
Weiß das Entwicklungsteam überhaupt, was genau umgesetzt, also implementiert werden soll? Und auch, warum? Gibt es überhaupt ein Ziel, und wenn ja, wie soll der Weg dorthin führen? Oft werden Anforderungen zu früh "eingefroren" und als gottgegeben betrachtet, oft zu ungenau formuliert, auch zu widersprüchlich. Oder sie unterliegen einer stetigen Änderung, ohne Rücksprache mit dem Entwicklungsteam.
Fehlende oder unklare Verantwortlichkeiten
Herauszögern von Entscheidungen, unerledigte Aufgaben, niemand fühlt sich zuständig – oder zu viele fühlen sich zuständig. Schwammige Projektleitung oder ungeklärte operative Verantwortlichkeiten sorgen für massive Reibungsverluste, die sich auf das Entwicklungsteam und damit auf die Qualität der Software auswirken.
Fehlende Standards
Wenn jeder Entwickler seine eigene Lösung schreibt – und seine eigene Ordnerstruktur, sein eigenes Logging, seine eigene Build Pipeline – ,wird das Projekt zum Flickenteppich. Spätestens bei der Wartung oder bei Teamwechseln wird das zum echten Problem.
Menschliche & soziale Probleme
Noch wurden wir nicht alle durch KI ersetzt, sind also Menschen mit all unseren Befindlichkeiten, Gefühlen, Vorlieben und Abneigungen. In Projekten kommen im Normalfall dann auch viele dieser Menschen zusammen und häufig kommt es dann auch zum Konfliktfall, oder es stellt sich heraus, dass die Menschen nicht sinnvoll miteinander kommunizieren.
Wer macht eigentlich was? Und warum tut es keiner?
Mangelhafte Kommunikation
Die meisten Missverständnisse entstehen nicht, weil ein Teammitglied böswillig handelt – sondern weil Informationen fehlen oder missinterpretiert werden. Meetings ohne klare Agenda, Entscheidungen im Flurfunk, kryptische Jira-Kommentare oder der Klassiker: "Das stand doch in der E-Mail." – das sind Faktoren, die immer wieder auftreten. Wenn Kommunikation zur Schatzsuche wird, verliert das ganze Team Zeit, Energie und Nerven.
Rollenunklarheit im Team
Wer macht eigentlich was? Und warum tut es keiner? Wenn Rollen und Verantwortlichkeiten nicht klar verteilt sind, entsteht ein Vakuum – oder noch schlimmer: Reibung durch Überschneidung. Manche machen alles, andere gar nichts, und niemand fühlt sich zuständig, wenn es dann wirklich mal brenzlig wird und die Produktion steht. Auch sehr schön: Plötzlich erhält man eine völlig neue Rolle ohne vorherige Absprache oder man wird immer noch für Themen als Ansprechpartner gehandelt, obwohl man sich um völlig andere Dinge kümmert.
Widerstände gegen Veränderung
"Das haben wir immer schon so gemacht." Mehr muss man hierzu vermutlich nicht sagen.
Schwelende Konflikte
Nicht jeder Konflikt wird laut ausgetragen – viele gären still vor sich hin. Unausgesprochene Spannungen, unterschwelliger Ärger oder Mikroaggressionen vergiften die Stimmung. Oft sind es kleine Dinge, die sich über Wochen oder Monate aufstauen – und plötzlich sprechen die Menschen nicht mehr miteinander oder nur noch schlecht übereinander.
Wir sehen also: Wenn Menschen miteinander arbeiten (müssen), läuft nicht immer alles glatt.
Projektbezogene Probleme
Fehlendes Risikomanagement
Manche Projekte wirken, als hätte man auf gutes Wetter gehofft, obgleich turmartige Haufenwolken näherkommen: Ohne Regenschirm, ohne Regenkleidung. Risiken werden ignoriert oder schöngeredet, weil sie unbequem sind. Wenn dann etwas schiefläuft (und das tut es fast immer), fehlt die Vorbereitung, die Panik beginnt, die Schuldigen werden gesucht und die Köpfe rollen! Denn schuld sind immer die anderen…
Unrealistische Zeitrahmen
Ein Klassiker: Ohne Rücksprache mit dem Entwicklungsteam werden dem Kunden Features oder Liefertermine versprochen. Das ist Planung auf Basis von Wunschdenken statt Aufwandsschätzung, oftmals aus politischem Druck heraus.
Fehlende Priorisierung
Alles ist gleich wichtig! Da weiß das Team gar nicht, was es als erstes tun soll, und dann fällt viel links und recht herunter. Unklare Priorisierung sorgt für Nebenkriegsschauplätze oder Tätigkeiten, die mit dem eigentlichen Projektziel nichts zu tun haben.
Scope Creep
Der Umfang der Anwendung wächst langsam, aber stetig, still und leise. Budget, Personal und Zeit erstaunlicherweise aber nicht, und irgendwann führt das zur Implosion des Projekts unter seinen eigenen Anforderungen.
Technische Probleme
Veraltete oder schlecht gewartete Codebasis
Jede Änderung wird zu einem unkalkulierbaren Risiko, wenn die Codebasis alt, unübersichtlich oder auch historisch gewachsen ist. Neue Teammitglieder verlieren sich in Abhängigkeiten, alte Hasen trauen sich nicht mehr ran, denn man weiß nie, welchen Effekt eine Codeänderung an der einen Stelle an einer ganz anderen Stelle in der Software provozieren kann. Technische Schulden werden zum Innovationskiller und oft hört man in diesen Team Aussagen wie: "Da fassen wir lieber nichts an, sonst geht wieder was kaputt…".
Technische Schulden
Zeitdruck ist nur einer der Gründe für technische Schulden. Falsche Entscheidungen sind ein anderer Grund. Wenn kurzfristige Lösungen den Vorrang erhalten, rächt sich das irgendwann – mit steigenden Wartungskosten, Fehleranfälligkeiten und Frust unter den Entwicklern.
Tooling…
Die Verwendung von Tools ist nicht standardisiert und niemand weiß, wo etwas dokumentiert wurde. Statt Effizienz gibt es ein Tool-Wirrwarr, und das alles führt zu hohen Einarbeitungszeiten, insbesondere bei neuen Teammitgliedern, die das historische Wachstum nicht mitgemacht haben.
Die hier vorgestellten Symptome chaotisch verlaufender Projekte sind nur eine Auswahl, es existieren durchaus viele mehr. Es müssen in einem Projekt auch nicht alle vorgestellten Probleme auftreten, aber in der Regel hat man es immer mal wieder mit dem Auftreten von zwei bis drei dieser Problematiken zu tun.
Agile auf den diesjährigen IT-Tagen
Spannende Vorträge und Workshops zum Thema Agile erwarten Euch auch auf den IT-Tagen, der Jahreskonferenz von Informatik Aktuell. Die IT-Konferenz findet jedes Jahr im Dezember in Frankfurt statt – dieses Jahr vom 08.-11.12.
Was kann ich tun?
Sobald man in ein solches Projekt hineingerät oder nach einer Zeit bemerkt, dass manches schiefläuft, sollte man sich als Erstes folgende Fragen stellen:
- "Will ich etwas verändern?"
- "Bin ich in der richtigen Rolle dafür?"
- "Kann ich es auch durchsetzen?"
Werden diese Fragen mit "Ja" beantwortet, dann kann man die folgenden fünf, recht breit anwendbaren Optionen betrachten, mit denen man den geschilderten Problemen entgegentreten kann.
- Überblick: Man sollte sich zuerst einen Überblick über die Misere verschaffen und nicht vorschnell mit wenig durchdachten Ideen aus der Hüfte schießen, denn das wirkt oftmals überheblich oder zumindest naiv. Daher gehören eine eingehende Analyse und Aufstellung der Probleme zu den ersten Tätigkeiten, wenn man etwas ändern möchte.
- Über den Elefanten im Raum sprechen: Es gilt im nächsten Schritt, die Probleme aufzuzeigen und zu kommunizieren. Hierbei sind Painpoint-Listen hilfreich, die nüchtern die bestehenden Problematiken beschreiben, ihre Auswirkungen darlegen und erste Vorschläge für Änderungen beinhalten. Dabei kann die Painpoint-Liste auf die prozessualen Probleme hinweisen, sie kann aber auch in Form von vierzig Powerpoint-Folien bereitgestellt werden, in welchen explizit alle technischen Schulden aufgelistet und Wege zur Beseitigung beschrieben werden. Wichtig ist hierbei, konkret auf die Probleme hinzuweisen und sie auch klar zu benennen.
- Verbündete suchen: Es ist wichtig, diejenigen zu finden, die auch in der Lage sind, die Probleme zu sehen, aber bislang nicht tätig werden konnten, um sich mit ihnen zu verbünden. Allerdings nicht im Sinne von "Revolution", sondern um gemeinsam Vorschläge zu unterbreiten, Ideen vorzustellen oder um zusammen voranzuschreiten.
- Vertrauen aufbauen: Durch Einführung stetiger kleiner Verbesserungen fördert man das Vertrauen der Stakeholder in die vorgebrachten Ideen und Veränderungsvorschläge. Ganz im agilen Sinne immer nach iterativem Besserwerden streben, statt den Big Bang zu versuchen.
- Auf Veränderung bestehen: Die vielleicht schwierigste der Optionen, denn Menschen tun sich teilweise sehr schwer mit Veränderung. Manchmal muss man vorsichtig oder auch subtil agieren und kommunizieren, manchmal aber auch disruptiv. Das ist völlig individuell, es kann im Fall ”disruptiv“ gegebenenfalls auch bedeuten, dass man aus dem Projekt entfernt und somit zum Märtyrer wird.
Die beschriebenen Optionen sind mehr oder weniger generisch und in vielen Projektsituationen anwendbar. Natürlich gibt es darüber hinaus noch viele kleinere Möglichkeiten, auf Probleme zu reagieren. Es gibt durchaus Projekte, in denen das Entwicklungsteam sich erstmal selbst um die Anforderungen kümmern musste, weil einfach keine sinnvollen Beschreibungen vorlagen und sich auch sonst niemand darum kümmerte. Am Ende gab es ein Einsehen seitens der Verantwortlichen, als sie sahen, wie fähig das Team ist.
Wenn ein Team mit Aufgaben überschüttet wird und dabei die lapidare Aussage fällt "Macht das – wie ihr es macht, ist euer Problem," dann kann das Team entweder die Arbeit einstellen oder selbst eine Triage durchführen und sich auf das Wesentliche konzentrieren – mit allen Konsequenzen, aber auch das kann dazu führen, dass an den verantwortlichen Stellen aufgehorcht wird. Es ist auch nicht selten, dass Softwareprojekte in Bugtickets versinken und es scheinbar keinen Ausweg gibt. In dem Fall lohnt es sich, ein Defect-Management einzuführen, und auch externe Stakeholder im Rahmen der Klassifizierung und Priorisierung in die Verantwortung zu nehmen – das schafft Awareness dafür, was ein Team überhaupt bewältigen kann.
Auf den IT-Tagen im Dezember hält Andreas Monschau einen Vortrag zum Thema
"Held oder Märtyrer – Eine Reise ins Projektchaos".
Die Konferenz findet vom 08. - 11.12.2025 in Frankfurt statt.
Fazit – Erfolg ist möglich
Man kann Problemprojekten durchaus begegnen, wenn man wohl überlegt handelt. Was für den einen hoffnungslos erscheinen mag, kann für den anderen eine Chance sein. Manchmal verlässt man das Projekt als Held – also als derjenige, der das Ruder herumreißen konnte – und manchmal als Märtyrer – als derjenige, der auf die Probleme hinwies und zu einer Besserung beitragen konnte, es ihn aber gleichzeitig den "Kopf" kostete. Projekte lassen sich sanieren, jedoch ist Erfolg nicht vorprogrammiert. Aber er ist möglich.
