Individuelle ProjektpreiseÜber 25 Jahre ErfahrungPersönlicher KontaktTrusted Advisor
BitInfo logo

Rufen Sie uns kostenlos an

0800 - 248 46 36
JETZT BERATEN LASSEN

Christian Wegener

09.06.2020

Lesezeit: oftware-Projekte

Gründe warum Software-Projekte scheitern

Gründe warum Software-Projekte scheitern


Es kommt öfters vor, dass Software-Projekte scheitern. Das kann an überzogenen Erwartungen liegen oder daran, dass wichtige Features im Verlauf des Projektes geändert werden. Viele Management-Entscheidungen und technische Faktoren können dafür verantwortlich sein, dass Projekte entgleisen oder nicht erfolgreich beendet werden können.

Jedes Softwareprojekt beginnt mit großen Erwartungen und Visionen. Die Hoffnung lautet, dass es irgendwo in einem Paralleluniversum ein Projekt gibt, welches jeden Traum erfüllt. Aber allzu oft können die Projekte diesen Anspruch nicht erfüllen. In der Realität taumeln die Projekte oft zur Ziellinie und überqueren sie nur manchmal.

Es ist schwer zu bestimmten, wie viele Projekte tatsächlich vom Scheitern betroffen sind. Denn Erfolg und Misserfolg lassen sich nicht immer einfach auseinanderhalten. Am Ende eines Projektes kann ein Code stehen, den niemand verwenden will. Oder es gibt einen Code, der sich nicht kompilieren lässt. Manchmal lässt sich noch etwas aus dem brennenden Projekt-Wrack retten. Manchmal ist davonlaufen die beste Lösung.

Nach einem Scheitern beginnt die Obduktion und die Mitarbeiter beginnen nach Erklärungen zu suchen und herauszufinden, was falsch gelaufen ist. Hier ist eine Liste der häufigen Gründe, warum Software-Projekte scheitern.

Unpassende Anzahl an Teammitgliedern

Die Auswirkungen von Projekten mit zu wenigen Teammitgliedern sind einfach nachzuvollziehen. Ein Jahr hat nur 52 Wochen und die Mitarbeiter können nur eine bestimmte Anzahl an Code-Zeilen produzieren, bevor sie ausgelaugt sind. Natürlich ist es schwierig herauszufinden, wie viele Programmierer ausreichen. Manchmal ist der Plan zwar vollständig und funktioniert akkurat. Aber manchmal stehen Hindernisse und Probleme im Weg. Es ist vielleicht nicht der Fehler des Managers, dass die Aufgaben der Mitarbeiter mehr werden. Aber das Projekt ist dann wahrscheinlich dem Schicksal überlassen.

Zu wenig Programmierer zu haben, kann ebenfalls problematisch sein und führt wahrscheinlich zu größeren Problemen. Mehr Mitarbeiter bedeuten mehr Koordination und das bedeutet mehr Meetings und weniger Zeit den Code zu schreiben. Man kann versuchen, die Anzahl an Meetings zu verringern. Aber wenn zu wenige gehalten werden, wird die gute Zusammenarbeit der Teams riskiert. Zu viele Programmierer nehmen sich gegenseitig die Arbeitszeit, weswegen das Projekt Gefahr läuft im Sumpf stecken zu bleiben. Es wäre zwar schön, Projekteerfolge nur mit einem höheren Budget und großen Teams erzielen zu können. Aber so einfach ist es nicht.

Wechsel der grundlegenden Features

In der Theorie sehen die Entwickler ihre Arbeitsweise als agil an. Deshalb finden sie das Wort so gut. Aber manchmal kann mit hoher Agilität die Balance aufs Spiel gesetzt werden. Es kommt darauf an, ob für einen Wandel grundlegende Änderungen am zugrundeliegenden Framework benötigt werden. Es ist einfach agil zu sein, wenn ein Button bewegt werden soll oder Farben geändert werden. Aber wenn Datenbankschemas, Replikationen oder Bestände überarbeitet werden sollen, gibt es keinen einfachen Weg die Änderungen spielerisch umzusetzen.

Nicht die richtige Technologie ausgewählt

Selbst wenn man behutsam einen Plan entwickelt und die korrekten Features für das Projekt auswählt, kann es vorkommen, dass die falsche Technologie ausgewählt wird, um das Feature-Set aufzubauen. Datenbanken zum Beispiel wurden designt, umso generell und flexibel wie möglich zu sein. Allerdings verfügen sie über eine limitierte Architektur. Wenn man versucht auf den Datenbanken unmögliche Aufgaben durchzuführen, kann man dabei zusehen, wie sie langsamer werden oder zum Stoppen kommen, wenn sie skaliert werden. Die Auswahl der richtigen Technologien ist wichtig.

Entsprechen Ihre Server-Configs
den gültigen Best Practices?

Wir analysieren IT-Infrastruktur, Clouds, Systeme und Server.

Unzureichende Priorisierung

Gute Planung umfasst das Erstellen einer Feature-Liste und deren Priorisierung. Aber manchmal stimmt die Reihenfolge der Priorisierung nicht mit der Implementierung in der Wirklichkeit überein. In komplexeren Fällen sind die wichtigsten Features am schwierigsten herzustellen. Wenn sich die Entwickler auf die wichtigsten Features konzentrieren, machen sie nicht genug Fortschritt und können am Ende vielleicht sogar nichts liefern. Und wenn sie sich um die unwichtigen Features können, bleibt am Ende vielleicht nur nutzloses übrig. Gute Planung benötigt also mehr als eine Checkliste. Die Vision der neuen Architektur muss die Needs und die Herstellungskosten mit einbeziehen.

Das Marktfenster schließt

Es kann vorkommen, dass ein Produkt nach Einführung keine Abnehmer findet, weil sich das Marktfenster geschlossen hat. Ein Scheitern des Software-Projektes ist nicht der Fehler des Programmier- oder Management-Teams, sondern das Marktsegment hat sich inzwischen bewegt oder existiert nicht mehr.

Schlechte Architektur-Entscheidungen

Manchmal lassen selbst einfachste Funktionen in den bestehenden Architekturen nur mühsam implementieren. Beispielsweise ist ein IT-System, welches auf einer Microservice-Architektur aufbaut ist, nicht dafür ausgelegt mit einzelnen Programmcodes geändert zu werden. Dann muss ein neuer Microservice hinzugefügt werden, der mit anderen Microservices interagiert und die einfache Funktion in das System implementiert. Dieses Unterfangen kann aufwändiger sein als gedacht und viel Programmierarbeit benötigen.

Entscheidungen über die Architektur können ein Leben lang Bestand haben, vor allem, wenn sie unveränderbar sind. Projektmanager müssen dies im Auge behalten, um festzustellen wann die grundlegende Architektur nicht mehr funktioniert und wichtige Entscheidungen anstehen.

Politische Konflikte

Wenn die Projekte größer werden ist es keine Überraschung, dass Fraktionen und Gruppen auftreten, die um Kontrolle, Ressourcen und Macht ringen. Verschiedene Gruppen bearbeiten unterschiedliche Small Services und nutzen dabei unterschiedliche Technologien. Es bietet sich an den Überblick zu behalten und gegebenenfalls Vereinheitlichung anzustreben.

Auf die falsche Technologie setzen

Die ausgewählte Technologie kann aus zwei Gründen nicht die richtige sein. Entweder ist sie nicht bereit die Aufgaben durchzuführen oder es gibt modernere Alternativen. Manchmal kann es vorkommen, dass die nächste Software-Generation noch nicht einsatzbereit ist. Die neuen Features sind zwar verlockend und die neue Software löst einige Probleme, aber manchmal fehlen elementare Bestandteile. Wer allerdings zu lange auf bestehenden Software-Umgebungen sitzenbleibt, läuft Gefahr mit veralteten Technologien zu arbeiten. Nach einiger Zeit fehlen wichtige Features und zukünftige Entwicklungen werden verpasst.

Unrealistische Deadlines

Bei der Benennung einer Deadline raten Experten abzuschätzen, wie lange es dauert und diesen Zeitraum zu verdoppeln. Deadlines sind knifflig und werden trotzdem am Anfang eines Projektes als erstes festgelegt. Wenn das Projekt außer Kontrolle gerät und die Deadline vorbeizieht, wird das Projekt als Fehlschlag eingestuft, selbst wenn der Code kurz davor ist bestens zu funktionieren. Deadlines helfen zwar sich zu fokussieren und zusammenzuraufen, sie kreieren aber auch eine unrealistische Erwartungshaltung.

Unvorhergesehene Konkurrenz

Ein guter Produktmanager hat einen Überblick über die Konkurrenz. Aber niemand kann vorhersagen, welche Wettbewerber unvorhergesehen auftauchen. Dann kann es vorkommen, dass neue Features entstehen, die beim eigenen Produkt eingegliedert werden müssen, genau wie beim Wechsel der Features und der Priorisierung.

Inkorrekter Glaube an Macht der Software

Manche Träumer haben einen unrealistischeren Glauben daran, dass Software die Welt verändert. Viele Software-Projekte sind mit derartigen Erwartungen verbunden. Die Nutzer der Software werden wütend, gelangweilt oder verwirrt, wenn keine Transformation der Welt stattfindet. Dann wird angenommen, die Software habe versagt. Viele Software-Projekte können kompilieren, Qualität sichern, etwas verschicken und gute Kritiken erhalten. Aber ein Change of World ist damit nicht möglich.

Kommentar hinzufügen