[MELDEN] Von der Vision zum Code: Ein Leitfaden zur Ausrichtung der Geschäftsstrategie auf die Ziele der Softwareentwicklung ist veröffentlicht!
HOL ES DIR HIER

IT-Projekte in Schwierigkeiten: Wann muss man sie retten und wann muss man sie aufgeben

readtime
Last updated on
February 12, 2025

A QUICK SUMMARY – FOR THE BUSY ONES

TABLE OF CONTENTS

IT-Projekte in Schwierigkeiten: Wann muss man sie retten und wann muss man sie aufgeben

Einführung

Auf dem hart umkämpften Markt von heute ist jedes Unternehmen bestrebt, die neuesten digitalen Technologien und Tools zu nutzen, um sich einen Wettbewerbsvorteil zu verschaffen. Um die Bereitstellung zu beschleunigen und die Kosten zu senken, ergreifen IT-Unternehmen und Softwareingenieure alle Arten von Initiativen.

Doch statt der erwarteten Transformation in Richtung Effizienz geraten viele Initiativen häufig unter Budget-/Infrastruktur-/Zeitbeschränkungen und werden zu problematischen IT-Projekten.

Laut dem Projektmanagement-Umfrage 2017 Laut KMPG liefern 31 Prozent der Unternehmen Projekte termingerecht, 29 Prozent sind bereit, Projekte im Rahmen des Budgets abzuwickeln, und nur 34 Prozent führen Projekte durch, die die Zustimmung der Interessengruppen erhalten. Der CIO drückt es unverblümter aus und sagt 50% der IT-Projekte scheitern am Ende.

Insgesamt haben verschiedene Umfragen ergeben, dass schlechte Schätzungen, schlechte Ziele, mangelnde Beteiligung der Geschäftsleitung und mangelnde Kommunikation die wichtigsten Vorboten für gescheiterte Projekte sind.

Man sagt, wenn Sie noch nie jemandem geraten haben, ein Projekt abzubrechen, waren Sie kein guter Projektmanager. Die Verwaltung problematischer Projekte ist aufgrund der IT-Komplexität, der menschlichen Natur und einer Vielzahl anderer Faktoren eindeutig eine Herausforderung.

Daher könnten sowohl Rettungsmaßnahmen zur Neugruppierung und Neubeginn als auch ein Projektabbruch relevant sein. Lassen Sie uns gemeinsam überlegen, wann es sich lohnt, ein Projekt zu speichern und wann es storniert werden sollte.

Definition eines problematischen Projekts

Ein Projekt in der Softwareentwicklung scheitert, wenn es mit Qualität, Kosten und Zeitplan zu kämpfen hat. Bei IT-Projekten mit Schwierigkeiten wird die Unähnlichkeit zwischen dem, was geplant wurde und dem, was erreicht wurde, so groß, dass ein Projekt auseinanderfällt und letztendlich scheitert. Im Falle eines Scheiterns führt dies zu Geldverlust und Reputationsschäden.

Die Ursachen für notleidende Projekte liegen hauptsächlich im Projektmanagement, das für die Organisation der Arbeitsabläufe verantwortlich ist. Es versteht sich von selbst, dass die typischen Ursachen schlechte Planung/Kommunikation/Führung, ungenaue Kostenschätzungen, fehlende klare Anforderungen, mangelnde Nachverfolgung/Rechenschaftspflicht usw. sind.

Grundsätzlich können wir sie alle in drei Gruppen einteilen: menschliche, kommunikative und prozessbezogene Faktoren.

Identify the signs of troubled IT projects.

Identifizierung von Anzeichen für problematische IT-Projekte

Es ist wichtig, Parallelen zwischen einer Erkrankung und einem Projekt in Schwierigkeiten zu ziehen, Symptome (Ursachen) zu identifizieren und frühzeitig zu handeln. Wenn Sie Probleme erkennen und die Intervention verzögern, wird die Situation nur noch schlimmer. Die meisten Softwareprojekte erkennen Probleme jedoch erst spät an, was teilweise auf Fehler im IT-Management zurückzuführen ist.

Achten Sie auf die folgenden Anzeichen, die möglicherweise einer weiteren Untersuchung bedürfen:

  • Regelmäßiges Verpassen wichtiger Termine/Meilensteine, Dinge laufen aus dem Ruder in Bezug auf Zeitplan, Verfahren, Technologie und Budget;
  • Schlechte Planung, Uneinigkeit über Projektanforderungen/Zieldefinitionen;
  • Häufige Änderungen, Improvisation seitens der Entwickler, Mangel an klarem Input durch das Top-Management;
  • Mangel an Ressourcen und/oder erforderlichen Fähigkeiten;
  • Durchführung von Aktivitäten/Aufgaben, die nicht in der Dokumentation/dem Projektplan angegeben sind;
  • Verzögerungen, negative Statusberichte, Kostenüberschreitungen;
  • Negative Stimmung über das Projekt, niedrige Teammoral, hohe Mitarbeiterfluktuation.

Beachten Sie, dass „Probleme“ nicht nur das Vorhandensein solcher Bedingungen sind, sondern auch Fortbestehen von Problemen und allgemein wachsendes Unbehagen. Probleme zu sehen, bedeutet nicht automatisch, dass ein Projekt scheitert. Es ist eine Grundlage, auf der analysiert werden kann, warum das Projekt scheitert und was dagegen getan werden könnte.

Bewertung

In der Sprache des Projektmanagements wird eine solche Analyse als problematische Projektbewertung bezeichnet, die darauf abzielt, eine der folgenden Maßnahmen festzulegen:

  • um das Projekt weiterzuverfolgen und zu retten,
  • um das Projekt zu speichern, indem Sie es komplett neu starten,
  • oder das Projekt herunterfahren (beenden).

Eine Bewertung der beiden Perspektiven — Projektfortführung versus Projektabbruch — und der jeweiligen Konsequenzen könnte erfolgen, indem man sich auf zentrale Fragen konzentriert.

Können wir das Projekt retten, indem wir den Projektplan aktualisieren, Mitarbeiter wechseln, Meilensteine überarbeiten, die Finanzierung erhöhen usw.? Hat die Absage eines Projekts Vorteile... können dadurch Ressourcen und Budgets für die Arbeit an anderen Projekten freigesetzt werden?

Die Hauptziele der Bewertung sind die detaillierte Prüfung aller Projektaspekte, die Analyse der Daten, die Zusammenstellung der Ergebnisse und die Berichterstattung an das Top-Management oder die Interessengruppen. Es handelt sich also um eine Untersuchung der Projekte Leistung, Ergebnisse, Probleme und allgemeiner Zustand.

Als Ergebnis der Bewertung können wir feststellen, was geändert werden muss (in Bezug auf Personen, Prozess oder Produkt) und die nächste Stufe empfehlen: Rettung oder Kündigung.

Neben der Untersuchung des aktuellen Projektstatus sollten auch die folgenden Projektvariablen gründlich analysiert werden:

  • Ein Projektstrukturplan (WBS);
  • Projektressourcen — personell und technologisch;
  • Risikobewertung (protokolliert und noch nicht identifiziert);
  • Terminplanung;
  • Projektspezifische Arbeitsorganisation und -prozesse;
  • Lieferbare Mängel oder Inkonsistenzen.
See how to decide whether to rescue or abandon troubled IT projects.

Das Bewertungsteam oder der Manager führt auch Teambesprechungen und Interviews durch, um Bedrohungen und Chancen zu bewerten und die Ergebnisse zu bestätigen. Dies könnte auch eine gute Grundlage für die weitere Beteiligung des Teams an Rettungsmaßnahmen sein (siehe unseren vorherigen Beitrag zu Tipps für Teambesprechungen).

Speichern oder nicht speichern: Rescue vs Termination

Die Abfolge der Maßnahmen bei problematischen IT-Projekten besteht im Wesentlichen aus vier Phasen: Bewertung, Empfehlung (Entscheidung), Planung und Ausführung. Nach einer gründlichen Bewertung steht das Management also vor einer wichtigen Entscheidung — ob ein Projekt wiederhergestellt oder beendet wird.

Natürlich würden Sie alle Vor- und Nachteile beider Szenarien abwägen. Hier sind zunächst einige Anweisungen zur Analyse:

Learn how to deal with troubled IT projects.

Wenn sich die Marktbedingungen und die technischen Aspekte und Anforderungen nicht drastisch geändert haben und dennoch innerhalb einer angemessenen Zeit geschäftliche Vorteile erzielt werden können, lohnt es sich möglicherweise, ein Projekt zu retten.

Auswirkungen auf die Wiederherstellung von Projekten

Die Wiederherstellung eines gescheiterten Projekts kann eine Überarbeitung des Projektumfangs und der Ziele sowie eine Erweiterung des Budgets und/oder des Zeitplans zur Folge haben. Der allgemeine Zweck der Wiederherstellung eines Projekts besteht darin, die wirtschaftliche Machbarkeit wiederherzustellen. Vor diesem Hintergrund sind die Hauptziele die Neudefinition des Projektplans, die Festlegung neuer (realistischer) Termine, die Wiederbelebung des Kundenvertrauens und die Behebung von Problemen.

In Bezug auf ein Projektteam kann es erforderlich sein, es neu zu besetzen oder möglicherweise sogar das ursprüngliche Team neu zusammenzustellen. Es wird in erster Linie in der Verantwortung eines Projektmanagers liegen, die Teamevaluierung durchzuführen, die Beteiligten davon zu überzeugen, dass es wieder soweit ist, die Mitarbeiter zu motivieren, einen Sanierungsplan zu erstellen und ihn jederzeit zu überwachen, um entschlossen zu sein und die Dynamik für ein erfolgreiches Ergebnis zu entwickeln.

Hinweis: weil das Projektteam bei den Wiederherstellungsbemühungen eine entscheidende Rolle spielt („..Du bist nur so gut wie dein Team..“), es wird dringend empfohlen, jedes Teammitglied in die Erstellung der Rettungs-Roadmap einzubeziehen.

Die Ansätze für eine Projektwiederherstellung sind immer unternehmensspezifisch und bestehen in der Regel aus einer oder einer Kombination der folgenden:

  • Behebung von Kommunikations- und Managementproblemen;
  • Neudefinition des Projekts (Umfang, Ziele, Gewinne);
  • Lösung technischer Probleme;
  • Zuweisung von mehr Ressourcen/Kosten;
  • Einen Projektmanager ersetzen.

Es versteht sich von selbst, dass das Hauptziel darin besteht, die Grundursache (n) von Problemen zu beseitigen und zu verhindern, dass sie jemals wieder auftreten. Es ist wichtig, sich an Maßnahmen auf drei Ebenen zu erinnern: Menschen, Prozess und Produkt. Maßnahmen zur Erreichung dieses Ziels können Folgendes umfassen:

  • Behebung von Produktfehlern;
  • Festlegung neuer Regeln für Arbeitsprozesse;
  • Fertigstellung oder Überarbeitung der Projektdokumentation;
  • Entwicklung eines strukturierten Sanierungsplans;
  • Implementierung neuer Qualitätskontrollen und Fortschrittsberichte

Auswirkungen des Projektabbruchs

Wann ist es sinnvoll, ein Projekt komplett abzubrechen? Ein Beispiel dafür ist, wenn Projektergebnisse nicht innerhalb einer angemessenen Zeit oder zu angemessenen Kosten erbracht werden können. Andere Szenarien, die zur Kündigung drängen, könnten eine Änderung der Geschäftsziele und/oder der Marktbedingungen, technologische Veränderungen, die das Projekt unmöglich machen, der Ausstieg von Investoren, mangelnde Teammotivation und rechtliche Probleme sein.

Auch hier ist es wichtig zu betonen, dass ein Projekt Kündigung ist nicht unbedingt ein Misserfolg. Es könnte angemessen sein, wenn alle — von den Stakeholdern bis hin zu den Entwicklern — zu dem gleichen Ergebnis kämen.

Das beliebte Technologiemagazin CIO hat solche Empfehlungen zur Beendigung problematischer IT-Projekte:

  • Überprüfen Sie die Möglichkeit einer Projektwiederherstellung
  • Machen Sie alle spezifischen Gründe für die Stornierung für alle klar
  • Seien Sie bei den Daten sehr spezifisch — Kosten, Schäden, Zeitplan, Personen usw.
  • Erkundigen Sie sich mit einem Projektvertrag nach den Verpflichtungen (möglicherweise fallen sogar Stornogebühren an)
  • Machen Sie es zu einer Lernerfahrung für Management und Mitarbeiter

Der letzte Punkt ist hier besonders bemerkenswert, da die nächsten Projekte klüger angegangen werden sollten, was die Festlegung von Erwartungen, Teamaufgaben, Zuweisung von Ressourcen und ein Budget angeht. Mit anderen Worten, abgesagte Projekte sollten beim nächsten Mal zu besseren Ergebnissen führen.

Konkrete Schritte zur Durchführung des Projektabbruchs umfassen Konsultationen mit anderen Abteilungen, die Einholung der Zustimmung des Top-Managements, die Erstellung einer schriftlichen Erklärung zur Information der Teammitglieder und Kunden, die Ankündigung der Kündigung, die Zuweisung von Entwicklern für andere Projekte/Aufgaben und den Abschluss einer Projektüberprüfung.

Grundlegende Tipps

Aufgrund mangelnder Steuerung und menschlicher Fehler ist es oft schwierig, Probleme zu erkennen. Um Probleme rechtzeitig zu erkennen, achten Sie auf die erwähnten Anzeichen (Symptome) und behandeln Sie die Wiederherstellung als separates Projekt.

Führen Sie eine Rettungsaktion durch, wenn Sie Kompromisse aus den Projektbeschränkungen ziehen und trotzdem das Ergebnis erzielen können. Wenn das unmöglich erscheint oder eine Korrekturmaßnahme nicht ausreicht, scheuen Sie sich nicht, ein Projekt abzubrechen. Reduzieren Sie die negativen Auswirkungen und lernen Sie aus Fehlern.

Frequently Asked Questions

No items found.

Our promise

Every year, Brainhub helps 750,000+ founders, leaders and software engineers make smart tech decisions. We earn that trust by openly sharing our insights based on practical software engineering experience.

Authors

Matt Warcholinski
github
Chief Growth Officer

Ein Serienunternehmer, leidenschaftlicher Forschungs- und Entwicklungsingenieur mit 15 Jahren Erfahrung in der Technologiebranche. Teilt sein Expertenwissen über Technologie, Startups, Geschäftsentwicklung und Marktanalysen.

Matt Warcholinski
github
Chief Growth Officer

Ein Serienunternehmer, leidenschaftlicher Forschungs- und Entwicklungsingenieur mit 15 Jahren Erfahrung in der Technologiebranche. Teilt sein Expertenwissen über Technologie, Startups, Geschäftsentwicklung und Marktanalysen.

Read next

No items found...

previous article in this collection

It's the first one.

next article in this collection

It's the last one.