Das Scheitern von Multi-Millionen-Euro IT-Projekten - Warum scheitern IT-Projekte?

Das Internet hat vor einigen Jahren die Welt im Sturm erobert und ist mittlerweile ein fester und wichtiger Bestandteil unseres Alltags. Besonders Unternehmen müssen sich diesem Umstand bewusst werden und sich damit anfreunden.

Unternehmen, die sich gegen die fortwährende Digitalisierung wehren, fallen ihr immer wieder zum Opfer. Ohne einen konkreten Plan für die Digitalisierung werden diese eingestaubten Unternehmen noch viele Jahre Probleme haben. Der Übergang in die digitale Welt wird zu einer Notwendigkeit, um das Fortbestehen des Unternehmens zu sichern. Die Zahl von IT-Projekten nimmt täglich zu, da Unternehmen versuchen, sich mit der digitalen Welt zu arrangieren.
Allerdings sind nicht alle IT-Projekte gleich. Die Praxis zeigt, dass die große Mehrheit der IT-Projekte es nicht bis zur Ziellinie schafft. Ein Bericht, der 2017 vom Project Management Institute (PMI) veröffentlicht wurde, ermittelte den Prozentsatz der IT-Projekte, die scheitern oder nicht die Ziellinie in der vorgegebenen Zeit erreichen. Der Bericht zeigte, dass fast 14% aller IT-Projekte scheitern, was quasi einem totalen Versagen entspricht. Es gibt noch andere Statistiken, über die man sich Sorgen machen sollte. Von den 86% der Projekte, die nicht gänzlich gescheitert sind, haben 31% der Projekte ihre erwarteten Ziele nicht erreicht, 49% wurden nicht rechtzeitig fertig und 43% der Projekte haben das vorgesehene Budget überschritten.
In diesem Artikel werden wir uns zunächst mit mehreren Hauptgründen für das Scheitern von IT-Projekten beschäftigen und dann versuchen, diese Probleme mit entsprechenden Lösungsansätzen zu begegnen.

Ausfallrate von IT-Projekten geordnet nach Industriesegmenten

Ungenaue Anforderungen

Ein wesentlicher Teil eines jeden Projekts ist die Anfangsphase, in der die Kunden, das Management und das Entwicklungsteam die Anforderungen des Kunden diskutieren und versuchen, sie zu verstehen. Hier treten meistens jedoch auch schon die ersten Probleme auf. Jedes Missverständnis in dieser Phase kann ein IT-Projekt schon von Anfang an zum späteren Scheitern verurteilen. Der berühmte Cartoon das Baumschaukel-Projekt erklärt dieses Konzept sehr gut.
Dieses Bild veranschaulicht die Art von Missverständnissen, die während der Phase der Aufstellung von Anforderungen auftreten können. Es gibt viele Gründe für diese Unklarheiten, und eine Kommunikationslücke ist eine davon.
Eine fehlende Durchführbarkeitsanalyse ist ein weiterer Grund. Immer wenn Kunden erklären, was sie wollen, lassen sich diese Informationen nicht unbedingt gut in den endgültigen Umfang übertragen. Hier kommt die Durchführbarkeitsanalyse ins Spiel. Setze sie ein, um unnütze Informationen herauszufiltern und realistische Anforderungen zu sammeln. Wenn man dem Kunden ganz am Anfang schon eine Idee präsentiert, kann man sowohl dem Unternehmen als auch dem Kunden viel Zeit und Geld sparen.

Wenig bis gar keine Beteiligung der Stakeholder

Ein weiteres großes Problem, das eine Hauptursache für das Scheitern von IT-Projekten ist, ist die geringe bis gar keine Beteiligung von Stakeholdern des Projekts. Wer ist hiermit gemeint? Projektmanager, sowie der Kunde oder der User. Bei vielen Projekten wird in der Regel das Wasserfallmodell angewandt. Nach dieser Methode werden die Projektanforderungen während des Starts zusammengetragen. Anschließend wird ein linearer Managementansatz gewählt, bei dem ein sequenzieller Projektplan verwendet wird. Dieser Ansatz kann zum Scheitern eines Projekts führen, weil der Stakeholder keine Kenntnis von den laufenden Fortschritten hat. Es gibt Zeiten, in denen spezifische Fragen auftauchen und das Entwicklungsteam nicht weiter weiß. Nun stehen ihm die Kunden jedoch nicht mit Rat und Tat zur Seite. Ohne einen handhaltenden Ansatz für die Kommunikation mit dem Kunden kann es passieren, dass du etwas völlig anderes kreierst, als das, was der Kunde braucht oder möchte.
Eine Entscheidung, die in Abwesenheit des Kunden getroffen wird, kann das Schicksal des Projekts völlig verändern. Die agile Herangehensweise wird eher bei Softwareentwicklungsprojekten bevorzugt, da Kunden und alle anderen Beteiligten in jede Entwicklungsphase einbezogen werden. Und jede Entscheidung, die sich auf die ursprünglichen Änderungen bezieht, wird mit der Zustimmung des Kunden getroffen. Diese Eigenschaft macht Agile für das Entwicklungsteam extrem einfach zu entscheiden und gleichzeitig die Anforderungen des Kunden zu erfüllen.

Änderung der Ziele des Projekts

Die Änderung der Ziele des Projekts ist ein weiteres Problem, mit dem Entwicklungsteams konfrontiert werden können. Auch wenn veränderte Ziele vielleicht nicht zum vollständigen Scheitern des Projekts führen, so führen sie doch zu außerordentlichen Verzögerungen im Projektzeitplan, erhöhten Projektkosten und vielen anderen Problemen, die mit diesen beiden einhergehen.
Hier kann man ebenfalls wieder erwähnen, dass die beiden Ansätze, d.h. die Wasserfallmethode und die agile Methode, mit den sich ändernden Projektzielen auf sehr unterschiedliche Art und Weise umgehen. Da das Wasserfallmodell ein linearer Managementansatz ist, können Änderungen der Projektziele verheerende Auswirkungen haben. Zum Beispiel müsste das Team wieder bei Null anfangen, da es keinen Raum für Änderungen gab.
Bei der Agilen Methode hingegen geht es darum, in kleinen Iterationen zu arbeiten. Am Ende jeder Iteration gibt es eine Gelegenheit zur Veränderung. Auch wenn es immer noch nicht ideal ist, die Projektziele zu ändern, so gibt es doch Raum für diese Modifikationen. Allerdings kosten diese Projekte in der Regel mehr und dauern vielleicht etwas länger als ein Projekt mit festen Zielen.

Unvorhersehbare Risiken

Wie Donald Rumsfeld sagte:

Es gibt bekanntes Wissen; es gibt Dinge, von denen wir wissen, dass wir sie wissen. Wir wissen auch, dass es bekannte Unbekannte gibt; das heißt, wir wissen, dass es einige Dinge gibt, die wir nicht wissen. Aber es gibt auch unbekannte Unbekannten - diejenigen, von denen wir nicht wissen, dass wir sie nicht wissen.

- Donald RumsfeldFree, Miles. 2016. “Unknown Knowns: Rumsfeld Missed One-Will You?” Production Machining, 1. Mai 2016.

Laut Donald gibt es also drei Arten von Risiken:

  1. Bekannte Bekannte, d.h. diejenigen, die ein Team normalerweise erwartet und auf die es vorbereitet ist
  2. Bekannte Unbekannte, d.h., diese beziehen sich auf die Themen, die ein geringes Potential haben, zu einem Risiko zu werden und
  3. Unbekannte Unbekannte – das sind die gefährlichsten von allen, da sie auftauchen, wenn alles in Ordnung ist, und du am wenigsten darauf vorbereitet bist.

Aus dem Bericht des Project Management Institute geht hervor, dass unerwartete Risiken 27% der gesamten Misserfolge von IT-Projekten ausmachen. Dieses Problem gehört zu denen, gegen die man nichts anderes tun kann, als darauf vorbereitet zu sein. Ein aktuelles Beispiel für ein solches Risiko war ist die globale Corona-Pandemie, welche die ganze Welt auf den Kopf stellt und auch zum Scheitern vieler wichtiger IT-Projekte führt. Es gab nicht viel, was die Entwicklungsteams dagegen tun konnten, außer die, die agile Methoden anwenden. Agile erlaubt es den Teams, flexibel zu sein und Raum für alle Transformationen und Modifikationen zu lassen, die während des unerwarteten Risikos stattfinden könnten. Eine Gruppe von Softwareingenieuren, die agile Methoden praktiziert haben, ist besser gerüstet, um mit solchen Problemen fertig zu werden.

Ungenaue Schätzungen

Richtige Schätzungen vorzunehmen ist vielleicht einer der wichtigsten Teile eines Projekts.  Gleichzeitig ist es aber auch einer der Hauptgründe für verzögerte Projekte oder das Überschreiten von Budgets. Immer wenn ein Projekt kurz vor dem Start steht, verlangen die Kunden sowohl einen Kostenvoranschlag als auch einen Zeitrahmen für die Fertigstellung. Zu diesem Zeitpunkt müssen alle, vom Entwicklungsteam bis hin zu den Test- und Projektmanagern, zusammenkommen, um genaue Schätzungen über den Preis und den Zeitrahmen des Projekts zu machen.
Eine genaue Schätzung der Kosten beinhaltet, dass man alles in Betracht zieht, was getan werden muss, und einen Spielraum für unerwartete Ausgaben lässt, die während des Projekts entstehen können. Das Gleiche gilt für den Zeitplan des Projekts, d.h. das Team muss alles bewerten, was Zeit verbrauchen oder Verzögerungen im Zeitplan des Projekts verursachen könnte.

Verzögerungen aus Abhängigkeiten

Während viele IT-Projekte relativ einfach sind und von kleinen, individuellen Teams durchgeführt werden, gilt das für andere große und komplexe IT-Projekte nicht unbedingt. In solchen Fällen arbeiten mehrere Teams oder zahlreiche Unternehmen gleichzeitig an dem Projekt. Wenn die Aufgaben zwischen verschiedenen Softwareentwicklern, Designern, Testern usw. aufgeteilt werden, teilen sich alle Teammitglieder die für das Projekt notwendige Gesamtarbeit. Diese Abhängigkeit bedeutet, dass jedes Team seinen Teil des Projekts fertigstellen muss, bevor es überhaupt versucht, eine höhere Stufe zu erreichen.
Dieser Zustand verursacht bei vielen Projekten Verzögerungen und führt manchmal zum völligen Scheitern eines Projekts. Einige Studien zeigen, dass Verzögerungen aufgrund dieser Abhängigkeit dazu geführt haben, dass fast 23% der Projekte die Ziellinie nicht erreichen. Es gibt nicht viel, was getan werden könnte, vor allem bei großen IT-Projekten, bei denen ein einzelnes Team die Aufgabe nicht erfüllen kann, und es gibt keine andere Möglichkeit, als mehr Teams in das Projekt zu integrieren.
Ein besserer Ansatz für dieses Problem ist es, die Arbeit in Teams aufzuteilen, um ihre gegenseitige Abhängigkeit zu verringern. Da das nicht zu 100% möglich ist, müssen auch Notfallpläne aufgestellt werden - das Management muss für jeden Teil des Projekts einen Notfallplan haben. Wenn ein Team nicht pünktlich liefert, muss immer ein Backup-Team da sein, das ihnen hilft, das Ziel rechtzeitig zu erreichen.

Mangelnde Ressourcen

Wieder einmal lässt sich dieses Problem mit einem Problem in Verbindung bringen, das wir bereits angesprochen haben. Ein Mangel an Ressourcen, Geldmitteln und Personal, wird nur dann verursacht, wenn das Team ungenaue Schätzungen vornimmt. Es ist Gewohnheit der Entwicklungsteams, den Arbeitsumfang eines bestimmten Projekts zu untergraben oder die mit jedem Teil verbundenen Kosten zu niedrig anzusetzen.
Wenn das Projekt beginnt, wird das Entwicklungsteam mit Arbeit überfordert und verlangt mehr Personal, das in die Gruppe eingebracht werden muss, oder es geht das Geld aus und benötigt mehr Budget, um die Projektziele zu erreichen.

Poor Project Management

Last but not least wollen wir dir natürlich nicht den wichtigsten Punkt von allen vorenthalten, nämlich das Projektmanagement. Ein gut gemanagtes Projekt umgeht all die oben genannten Probleme eines und führt es erfolgreich zum Ziel. Auf der anderen Seite kann schlechtes Projektmanagement zu jedem der oben genannten Probleme führen. Wenn ein Manager seine Arbeit nicht gut macht, kann dies zu ungenauen Schätzungen der benötigten Personalressourcen führen, oder die Projektkosten verursachen ungewöhnliche Verzögerungen im Projekt. Ein guter Projektmanager legt realistische Zeitpläne fest, versteht die Probleme, mit denen ein Mitglied seines Entwicklungsteams konfrontiert werden könnte, und bildet eine Kommunikationsbrücke zwischen dem Entwicklungsteam und den Stakeholdern.

Abschließende Worte

Zusammenfassend kann man sagen, dass alle genannten Probleme eigentlich recht einfach vermieden werden können, und viele vergangene und bestehende Projekte erfolgreicher gestaltet werden könnten. Einer der Schritte, die von den Softwareentwicklungsteams gemacht werden muss, ist die Wahl von agileren und anpassungsfähigeren Entwicklungsmethoden, die nicht starr sind und Raum für Veränderungen lassen. Diese Methoden tragen dazu bei, die Projekte pünktlich abzuschließen und helfen den Teams, alle finanziellen oder personellen Probleme zu überwinden. Abgesehen davon müssen die Projektleiter solcher Projekte natürlich auch alles geben und sicherstellen, dass jedes Projekt die Aufmerksamkeit erhält, die es verdient.

Autor

Kris Terziev, Leiter Abt. F&E

Kris ist Leiter der Abteilung für Forschung und Entwicklung bei CodeCoda und sucht, wie er selbst sagt, ständig nach besseren Methoden für die Entwicklung und Implementierung von Softwarelösungen. In seiner vorherigen Laufbahn als Software-Ingenieur war er in allen entscheidenden Bereichen tätig, vom reinen Assemblycoding bis hin zur Optimierung von Geschäfts-und Funktionsanalysen, sowie in der Entwicklung von Fintech Anwendungen. In seiner Schulzeit gewann er im Rahmen internationaler Wettbewerbe mehrere Medaillen in Mathematik und Informatik. In Bezug auf sein berufliches Interesse spezialisiert er sich auf Algorithmen und Softwareentwicklungsmethoden.