Warum Softwareentwicklung auf Projektbasis nicht funktioniert
Seit einigen Jahren beschäftige ich mich nun mit der Softwareentwicklung. Sei es Mobile App-, Desktop- oder Webentwicklung. In allen diesen Bereichen haben wir Software entwickelt und Kunden zur Verfügung gestellt.
Einige Dinge sind uns jedoch bei allen Projekten, welche wir ausgeführt haben, aufgefallen. Diese sind in diesem Beitrag beschrieben. Grundsätzlich geht es darum aufzuzeigen, warum Softwareentwicklung auf Projektbasis meistens nicht klappt.
Einführung
Laut unterschiedlichen Quellen liegt die Rate des Scheiterns von Softwareprojekten zwischen 60 und 75 Prozent. Eine unglaublich hohe Zahl, wenn man bedenkt, wieviel Geld und Zeit dadurch jedes Jahr verloren gehen.
Dennoch macht man in der Softwareentwicklung immer wieder die gleichen Fehler.
Start
Meistens fängt eine IT Unternehmung damit an, dass irgendwo die Idee entsteht, dass man mit einer bestimmten Software einen Unternehmensprozess oder eine Interaktion automatisieren, vereinfachen oder verschnellern kann.
Falls eine oder mehrere Personen mit Budget/ Geld und die Entscheidungsbefugnis die Freigabe geben, wird eine Anfrage an ein Softwareumsetzungsunternehmen (in den meisten Fällen eine Agentur, IT Unternehmen oder eine interne IT Abteilung) versendet. Gehen wir in unserem Fall davon aus, dass es ein IT Unternehmen ist.
Dieses IT Unternehmen wird nun ein erstes Treffen oder Telefonat mit den Ansprechpartnern auf der Auftraggeberseite vereinbaren und die Eckdaten für das Projekt aufnehmen.
Das Dilemma beginnt
Das IT Unternehmen wird sagen, dass die Anforderungen nicht genau bestimmt sind und es eine initiale Phase geben sollte, in welcher die Anforderungen genauestens bestimmt werden.
Solch eine Anforderungsaufnahme, in welcher zum Beispiel alle Funktionalitäten, etc. in einem Dokument eingetragen werden, auf welches alle Beteiligten Zugriff haben, kann mehrere Wochen bis Monate dauern.
Die meisten Auftraggeber (sei es interne oder externe Auftraggeber) werden jedoch auf so eine lange Phase verzichten wollen. “Keine Zeit”, “Nicht notwendig”, “Dafür seit Ihr doch da?”, “Habt Ihr die Expertise nicht, oder warum fragt Ihr uns?” und noch viele weitere Argumente werden, von Seiten des Auftraggebers fallen, um diese lästige Anforderungsphase zu umgehen.
Ratespiel beim IT Unternehmen
Da der Auftraggeber nicht bereit ist, die Anforderung genauestens zu bestimmen, fängt nun das Ratespiel beim Auftragnehmer an.
Meistens versucht man die Anforderungen so zu bestimmen, so dass nur sehr wenige Kontaktpunkte mit dem Auftraggeber entstehen. Eine Möglichkeit ist die Erstellung von “User-Stories”. Dass heisst, das Entwicklungsteam setzt sich zusammen und schreibt unterschiedliche Nutzer-Szenarien auf.
Diese Nutzer-Szenarien werden dann in kurzen Meetings mit dem Kunden abgestimmt. Dabei ist auf Kundenseite meistens nur ein Projektleiter präsent, welcher das mit dem Entwicklungsteam abstimmt. Wichtige Nutzergruppen oder Entscheider sind oftmals in diesen Meetings nicht vorhanden.
Hier entsteht bereits eine Diskrepanz. Die Funktionalitäten sind überwiegend vom IT Unternehmen, ohne eine grosse Involvierung des Kunden niedergeschrieben worden. Die Wahrscheinlichkeit, dass das Unternehmen genau das herausfindet, was der Kunde möchte, ist bereits in dieser Phase mehr als sehr gering.
Lang oder kurz?
Jetzt gibt es bei den meisten Entwicklungsunternehmen den Ansatz eng mit dem Kunden zusammenzuarbeiten und sich mit diesem in sehr kurzen Intervallen abzustimmen (zum Beispiel in der Scrum Entwicklungsmethode jeden Monat einmal) oder nur in sehr geringen Intervallen (zum Beispiel in der Wasserfall Entwicklungsmethode nach Fertigstellung eines Grossteils des Projektes).
Beides bringt jedoch seine Vor- und Nachteile mit sich.
Wählt das Softwareunternehmen kurze Abstimmungsintervalle, dann werden dem Kunden sehr viele neue Funktionalitäten “einfallen” welche doch nützlich wären, und in das Projekt eingebaut werden sollen. Gleichzeitig wird er eventuell wollen, das bereits programmierte Funktionalitäten geändert oder herausgenommen werden sollen. Eine weniger als ideale Situation für ein Softwareunternehmen, das damit beauftragt wurde, das Projekt in einer bestimmten Zeit und mit einem bestimmten Budget fertigzustellen.
Wenn die Intervalle der Abstimmung lang sind, und der Kunde das Endprodukt zum Beispiel erst zu Gesicht bekommt, wenn alle Funktionalitäten fertig programmiert sind, dann besteht die grosse Gefahr, dass man komplett in die falsche Richtung programmiert hat und der Kunde komplett unzufrieden ist. Eine erfolgreiches IT Unternehmen lebt jedoch von langen Kundenbeziehungen. Wenn der Kunde nicht zufrieden ist, dann wird der Anbieter ausgetauscht oder langfristig das Budget gekürzt.
Unzufriedenheit mit den Funktionalitäten und mit der Performance
Meistens ist der Kunde unzufrieden mit der Funktionalität und mit der Performance des Systems. In vielen Fällen besteht kein Verständnis beim Abnehmer für solche Dinge. Auch wenn der Fehler bei der Technik/ Technologie liegt. Beispielsweise kann man mit einer HTML5 Mobile App nur eine bestimmte Menge der derzeitigen Möglichkeiten ausschöpfen und wird nicht so performant sein, oder die gleichen Funktionalitäten bieten wie eine Native App auf Basis von Android oder iOS.
Aus Sicht des Kunden muss die Lösung, schlank, elegant, schnell und sehr nützlich sein. Alles Geringere als das, wird als misslungenes Projekt betrachtet.
Schwere Einschätzbarkeit des Preises für die Fertigstellung
Die grosse Preis-Frage. Das ist ein Bereich an dem schon die Besten der Besten Softwareentwickler/ IT Unternehmen gescheitert sind. Die Technologie, die Anforderungen des Kunden, die Technik/ Endgeräte, die Gehälter, die Steuern, das Entwickler-Team, alles ist im konstanten Wandel. Besonders die Anforderungen an die Funktionalitäten. Wie soll ein IT Unternehmen hier einen Preis nennen können.
In manchen Fällen, ist es nicht einmal klar, mit welchem Technologie-Ansatz und wie genau eine Softwarelösung/ Programmierung aussehen kann. Hier einen Preis zu nennen, ist glatter Unfug. Jedoch wird das heutzutage von IT Unternehmen verlangt.
Die grosse Problematik die hierbei besteht, ist eher auf ein psychologisches Phänomen zurückzuführen. Wenn der Preis einmal genannt ist, dann sind die meisten Menschen nicht mehr bereit eine Änderung daran vorzunehmen. Besonders wenn es um eine Preiserhöhung geht. “Aber das war doch Teil der Vereinbarung”, “Das hatten wir bereits besprochen”, “Das ist normalerweise bei so einem Projekt inklusive”, und noch viele mehr Argumente werden von Seiten des Auftraggebers fallen. Ein IT Unternehmen kann hier hart sein, und mehr Geld verlangen, wird dafür aber sehr tief in der Gunst des Kunden fallen. Oder man benötigt einen sehr guten Vertriebler, welcher diese Budget-Änderungen in einer verständlichen Weise erklären kann.
Fertigstellungsdatum schwer bestimmbar
Auch das Fertigstellungdatum ist so ein Thema. Besonders in Deutschland, in dem Pünktlichkeit eine sehr wichtige Eigenschaft ist, wird es gar nicht gerne gesehen, wenn einmal vereinbarte Termine nicht eingehalten werden.
Hier stellt sich jedoch die gleiche Frage wie beim Budget: Wie kann ein Zeitrahmen bestimmt werden, wenn sich alle Parameter (Team, Funktionalitäten, Technologie, etc.) ständig ändern?
Umfang der Funktionalitäten
Viele Anforderungen werden nur in kurzen Sätzen formuliert. Zum Beispiel “Eine Suche der Daten sollte möglich sein”. Dies kann vieles bedeuten. Ist es eine simple Datenbank-Suche oder muss die Suche ähnliches erreichen wie Google?
Auch dies wird schlussendlich zu Unstimmigkeiten führen. Den Umfang zu bestimmen ist nahezu ein Ding der Unmöglichkeit.
Änderungen während des Projektes
Während des Projektes werden, besonders auf Kundenseite, sehr viele Änderungswünsche entstehen. Dies liegt auch daran, dass der Auftraggeber merkt, dass während der kurzen Eruierungsphase der Anforderungen wichtige Aspekte des Projektes übersehen wurden.
Manchmal sind diese zusätzlichen Funktionalitäten entscheidend für den Erfolg der Implementierung. Somit kann das IT Unternehmen auch nicht “Nein” zu der Forderung sagen.
Machbarkeit
Wir leben in einer Zeit in der vieles machbar ist. Jedoch ist nicht alles machbar. Zum Beispiel können wir mit einem Flugzeug in der Luft fliegen, jedoch können wir uns nicht von einem zum anderen Ort “beamen”. So sind auch in der IT Entwicklung sehr viele Grenzen gesetzt, welche um einiges trivialer sind, als das eben genannte Beispiel.
Vor dem Zeitalter der Smartphones, wäre es zum Beispiel nicht möglich gewesen, mit einem Mobil-Telephone die Geschwindigkeit zu messen. Heutzutage ist das wiederum kein Problem.
Laut dem Kunden müsste jedoch alles umsetzbar sein. Und wenn man erklärt, dass es dann doch nicht möglich ist, wird schnell von Inkompetenz gesprochen. “Ein anderer Anbieter hätte das sicherlich hinbekommen”
Fazit
Im Grossen und Ganzen ist es nicht verwunderlich das soviele IT Projekte scheitern. Es ist eigentlich logisch, dass dies Projekte scheitern müssen, wenn alle Seiten (Kunde und Auftragnehmer) schon von Anfang an, mit unmöglichen Anforderungen an Zeit, Geld, Ressourcen, Technologie, etc. konfrontiert werden.
Der falsche Weg wäre es hier noch weiter zu eruieren, wie man den die Anforderungen des Kunden genauer und mit noch weniger Aufwand bestimmen kann. Dies ist ein Ding der Unmöglichkeit, denn der Kunde weiss meistens selbst nicht was er denn genau möchte, der Auftragnehmer weiss zudem auch nicht wie lange es mit einer unbestimmten Anzahl an Technologien (z.B. verschiedene Softwaresprachen, Datenbanken, bestehender Software auf Kundenseite, etc.), einem unterschiedlichen Fachkräftepersonal, bei dem jeder schneller, langsamer, besser oder schlechter ist, benötigt, um die Programmierung fertigzustellen.
Es ist ein Ratespiel welches seinesgleichen sucht.
Wollen wir es bei diesem Beitrag also nicht bei einem Fazit lassen, sondern stellen auch eine mögliche Lösung vor.
Die Lösung
Es müssen im Vorfeld einige Dinge auf allen Seiten klar sein.
Zu diesen gehört auch, dass es unmöglich ist, zum Anfang den Preis, den Umfang, die genaue zu verwendende Technologie, die Teammitglieder oder das genaue Endprodukt zu bestimmen oder zu beschreiben.
So, dass wäre dann der erste Stein, welchen sich alle vom Buckel laden können.
Zweitens muss eine hohe Transparenz, Ehrlichkeit und Vertrauen auf allen Seiten (sei es Kunde oder Entwicklungsunternehmen) bestehen. Bereits hier scheitert es in vielen Fällen, denn es treffen unterschiedliche Interessen aufeinander. Der Kunde möchte so wenig Geld wie möglich ausgeben und das Produkt so schnell wie möglich haben und der Auftragnehmer möchte einen idealen Betrag für deren Leistungen bekommen und genug Zeit, um eine ideale Lösung zu bauen. Hier muss ein Verständnis auf beiden Seiten entstehen. Beide müssen im gegenseitigen Interesse handeln. Der Kunde muss verstehen, dass nicht alles möglich ist, und sollte sich bei Änderungswünschen so gut wie möglich zurückhalten und der Auftragnehmer muss verstehen, dass der Erfolg des Kunden im Vordergrund steht, er eine hohe Transparenz und Einsicht in den Entwicklungsprozess geben und den bestmöglichen Preis für die Leistung zur Verfügung stellen sollte.
Aus unserer Sicht als Auftragnehmer sollte zudem folgender Punkt beachtet werden: Es sollte weniger aus einer Projektsicht gedacht werden. Es macht in vielen Fällen (jedoch natürlich nicht in allen) Sinn auf feste langfristige Partnerschaften zu schauen, in denen man Softwareentwickler langfristig an sich bindet. Denn Projekte sind meistens nicht nach einer bestimmten Zeit fertig, sondern werden bei Erfolg langfristig weitergeführt und auch hierfür müssen die Entwickler bereitstehen, um weitere Funktionalitäten zu bauen, die bestehende Lösung zu warten und Funktionalitäten zu verbessern. Diese langfristige Bindung von Ressourcen (Entwicklern) ist nach meiner Meinung die bessere Lösung, als auf Projektbasis zu arbeiten.
Fälle in welchen es Sinn macht auf langfristige Entwicklerbeziehungen zu setzen:
- Softwareprodukte, welche an Geschäftskunden verkauft werden und bei denen ständig weitere Funktionalitäten benötigt werden und bei denen die Wartung sichergestellt sein muss.
- Agenturen und IT Unternehmen, welche ständig neue Apps, Software und Web-Lösungen für Kunden entwickeln.
- IT Abteilungen welche ihren Fachabteilungen immer wieder mal neue Software programmieren.
Fazit 2
Hier sind wir bereits beim zweiten Fazit. Es braucht ein starkes Umdenken in der Softwareentwicklung auf allen Seiten. Soviele IT Projekte wie möglich, sollten in langfristige Beziehungen umgewandelt werden, in welcher die gleichen Ressourcen (Entwickler, Projektmanager, Technologie, etc.) dem gleichen Kunden helfen, um IT Lösungen zu bauen, zu verbessern und zu warten.
Kurzfristig sollte man nur zusammenarbeiten wenn:
- Der Kunde relativ klein ist und keine Möglichkeit besteht das Produkt weiter auszubauen, sei es, weil es nicht benötigt wird, oder weil kein Budget besteht. (In diesem Fall macht es sowieso mehr Sinn auf Cloud Software oder Standardlösungen zu setzen. Eigenentwicklungen machen hier wenig Sinn.)
- Produkte welche nur kurzfristig genutzt werden. Zum Beispiel gibt es Marketingkampagnen, in welcher eine App oder eine Webapplikation nur kurzfristig benötigt wird. Nach einer bestimmten Zeit wird die Applikation nicht mehr benötigt.
Es gibt sicher noch andere Fälle, in welchen man kurzfristig Zusammenarbeiten kann. In jedem dieser Fälle, sollte jedoch die Weiterentwicklung und die weitere Wartung keine grosse Rolle spielen.
Ich würde mich sehr freuen mit Euch darüber zu diskutieren. Welche Ansätze verfolgt Ihr? Warum scheitern Projekte und wie kann man das Ganze erfolgreicher gestalten?
Interessante Links:
75 Prozent aller Projekte scheitern
Zu komplex und schlecht geplant
Bilder: Flickr.com/ Cardus/ ING/ U.S Army/ Rogers/ Depolo/ Campell/ Grimnes
Der Autor: Sascha Thattil arbeitet bei YUHIRO und hilft Unternehmern und Unternehmen beim einfachen Aufbau von Programmier-Teams in Indien. YUHIRO ist ein deutsch-indisches Unternehmen welches IT Firmen, Agenturen und IT Abteilungen Softwareentwickler bereitstellt.
Richtig gut, finde nur nicht dass ein Umdenken der Softwareentwicklung sondern auch bei den Anwendern nötig ist
Danke für den Input.