Softwareentwicklung ist ein komplexer Vorgang.
Bei jeder neuen Entwicklung auf einer grünen Wiese werden neue Ideen umgesetzt. Dabei ist jedes neue Softwareprodukt am Anfang ein Prototyp, der einen andauernden Verbesserungsprozess durchlaufen muss.
Von dem Blickwinkel aus betrachtet, ist die Quote von erfolgreichen Softwareprojekten sehr hoch.
Aber genau hier hören und sehen wir leider immer wieder (manchmal sogar aus der Presse), dass Softwareprojekte gescheitert sind.
Aus unserer Sicht sind das fast immer systematische Fehler, die hier zum Scheitern führten. Wer diese Problem Felder schon am Anfang kennt, kann von Beginn an dagegen steuern und Fehlentwicklungen viel früher erkennen und entsprechend Handeln.
Aus unserer Sicht gibt es drei wesentliche Gründe, die zum Scheitern eines Softwareprojektes führen können.
1. Das Softwaresystem wird schon zu Beginn mit umfangreichen Funktionen geplant
Es gibt Projekte, die viele Monate ja vielleicht sogar Jahre im Labor entwickelt wurden, um möglichst viele Funktionen schon von Beginn an zu implementieren.
Dann wird das Projekt, das erste Mal produktiv geschaltet und es wird ganz hektisch angefangen an vielen Stellen gleichzeitig zu verbessern.
Unsere Empfehlung ist deshalb. Entwickeln Sie ein „Minimum Viable Product“ (kurz MVP genannt).
Ein MVP ist die simpelste Konfiguration, die ein Benutzer testen und bewerten kann. Im Idealfall ist dieses MVP schon produktiv nutzbar. Dieses MVP kann für einen kleinen Prozentsatz der kompletten Entwicklung in kürzester Zeit entwickelt werden und zeigt deutlich, ob man auf dem richtigen Weg ist.
An dieser Stelle ist es dann einfach, Korrekturen vorzunehmen und das hektische Verbessern an vielen Stellschrauben entfällt.
Überlegen Sie sich also, welche Funktionen muss ein neues Softwareprodukt haben, damit es bereits einen Nutzen (wenn auch vielleicht nur geringer Nutzen) für Sie hat.
Darauf aufbauend, ist die weitere Entwicklung viel, viel einfacher.
2. Bei der Entwicklung des Softwaresystems werde keine (oder erst sehr spät) zukünftige Nutzer mit eingebunden
Softwareprojekte entstehen meist zwischen verschiedenen Softwareentwicklern und Business Analysten oder Projektmanagern, die ihre eigene Sicht auf die Prozesse in einem Unternehmen haben.
Es wird deshalb sehr häufig beim Beginn des Projekts aus Kostengründen darauf verzichtet, einen oder mehrere Endnutzer in dem Projekt mit einzubeziehen.
Das fertige Produkt gefällt dann vielleicht dem Projektmanager oder einem Softwarespezialisten. Das muss dann nicht zwangsläufig den Anforderungen von einem Endbenutzer entsprechen.
Ich habe schon zu oft erlebt, dass am Ende der Benutzer sagte, damit kann ich gar nichts anfangen.
Meistens sagt der Endnutzer gar nichts, da er glaubt von solchen IT-Dingen keine Ahnung zu haben. Es wird dann versucht, das System irgendwie produktiv zu nutzen.
Dann fangen die Benutzer erst langsam dann aber immer heftiger an sich zu beschweren, bis dann jemand die Reißleine zieht, und die Nutzung des neuen Softwaressystems stoppt.
An der Stelle ist dann das Katzengejammer sehr groß.
Wer also von Beginn an die Benutzer mit einbezieht, bekommt rechtzeitig Feedback und kann während der Entwicklung dieses Feedback mit einbeziehen.
Das wirkt sich am Ende deutlich auf die Qualität des Produktes aus.
3. Das Projekt hat einen zu großen zeitlichen und finanziellen Rahmen
Der dritte Punkt klingt erstmal widersprüchlich. Ist er aber nicht.
Der Mensch braucht immer eine gewisse Dringlichkeit, um etwas fertig zu stellen oder etwas zu liefern.
Dieser Punkt bringt Motivation für jeden, an einem Projekt konzentriert und vor allem effizient zu arbeiten.
Hat ein Projekt einen großen Zeitraum bis zur Ablieferung mit entsprechend großem Budget, wird das Projekt am Anfang sehr gemütlich sein. Das Projekt kommt zwangsläufig unter Druck. Termine und Budget werden nicht eingehalten bis etwas deutlich aus dem Ruder läuft.
Setzen Sie dem Projektteam immer kurzfristige Termine mit einem überschaubaren finanziellen Aufwand und Sie werden Ihre Ziele schneller erreichen.
Verlassen Sie sich nicht auf Powerpoint Slides oder Screenshots.
Überprüfen Sie die abgelieferte Software immer selbst auf einem Staging- oder Testsystem. Unser Motto lautet hier immer „Look Touch and Feel“. Nur dann können Sie beurteilen, ob Sie mit dem Projekt auf dem richtigen Weg sind oder Korrekturen vornehmen müssen.
Glauben Sie mir, als Software Architekt, der neue IT-Systeme entwickelt und ständig verbessert, tut es richtig weh, wenn man erfährt, dass ein Softwareprojekt gescheitert ist. Damit meine ich nicht nur die eigenen Projekte sondern vor allem Softwareprojekte, in der viele Monate von Arbeit hineingeflossen sind und nun unklar ist, wie diese Plattform weiter genutzt werden soll.
Wer diese drei oben erwähnten Punkte berücksichtigt, der sollte schon früh Fehlentwicklungen erkennen und dagegen steuern können.
Wenn Sie genau bei diesem Thema Unterstützung benötigen, melden Sie sich bei uns.
Wir haben mehr als 20 Jahre Erfahrung in der Softwareentwicklung und können in einem ersten Gespräch einige Ideen mitgeben, wie Sie in einem schwierigen Umfeld, die richtigen Entscheidungen treffen können.
Mit den besten Grüßen aus Rostock,
Gunnar Bock