Viele Faktoren entscheiden darüber, ob ein Software-Projekt erfolgreich ist oder nicht. Es ist die entscheidende Frage für den Auftraggeber: wie kann ich mich davor schützen, dass ein Projekt nachträglich für mich teuer wird? Langjährige Zusammenarbeit und gegensätzliches Vertrauen ist ein ganz wesentlicher Aspekt.

Es gibt Partnerschaften zwischen Unternehmen, die sind einfach erfolgreich. Trotz gelegentlicher Reibungspunkte und Diskussionen weiß man voneinander sehr genau, welche Leistung in welcher Qualität man für einen Betrag X bekommt. Die pdv-software GmbH hat die Erfahrung gemacht, dass auch zufriedenen Kunden manchmal herausfinden möchten, was wohl passiert, wenn man einer Kuh Schlittschuhe verpasst und sie aufs Eis lässt. Wenn das Budget plötzlich knapp wird, der Funktionsumfang aber noch nicht wie gewünscht gegeben ist, kann man durchaus in Versuchung kommen, zur Kostenreduzierung mit der Entscheidungen für einen neuen Softwareentwickler auf das besagte Glatteis zu begeben, sich also auf eine neue, ungewohnte Partnerschaften einzulassen.

Erfolgs-Faktoren

Der Vergleich mit dem Glatteis funktioniert deswegen, weil jeder Software-Entwicklungsprozess eine beliebige Vielzahl von kombinierbaren Faktoren besitzt, die zu einem Scheitern führen können. Es gibt Statistiken, nach denen etwa 80 Prozent der begonnenen Softwareprojekte niemals zu einem effektiven Einsatz in der Praxis kommen. Die Faktoren, die über den Erfolg oder Misserfolg einer Entwicklung mitentscheiden, sind in der Summe recht beeindruckend:

• Zusammensetzung des Teams allgemein,
• Regeln für die Teamkommunikation und definierte, abgegrenzte Verantwortlichkeiten,
• Zuweisung der richtigen Kompetenzen den richtigen Aufgaben/Verantwortungen,
• Widerspruchsfreie Spezifikationen durch vollständige Pflichtenhefte und Anforderungsprofile, frei von Variabilität und Interpretierbarkeit,
• Präzise Aufwandsabschätzung mit dem Projekt entsprechender Detaillierung,
• Kenntnisse über die Ursache und den Urheber von Anforderungen und Änderungen an den Anforderungen, vor allem im laufenden Projekt,
• Definierter, dem Team bekannter Softwareprozess,
• Nutzung der Kenntnisse zeitgemäßer Softwarearchitektur,
• Festlegung von Meilensteinen,
• Einsatz bekannter Technologien (gleichzeitig Vermeidung von Technologien, an die sich nur noch ausgeschiedene Mitarbeiter erinnern können – der „Wir-haben-wir-schon-immer-so-gemacht-aber-keiner-weiß-warum-Effekt“),
• Für das Projekt und die Aufgabenstellung angemessene Modellierungs- und Designwerkzeuge,
• fachlich fundierte Entscheidungen für Werkzeuge und Komponenten anhand von Funktionalität vor der sicherlich nötigen Kosten- (gepflegte Werkzeuge) und Risikobetrachtung (freie Software),
• Vermeidung von Technologieänderungen im laufenden Projekt,
• Eindeutig definierte, gemeinsam genutzte Terminologie bei anwendungs- und entwicklungsspezifischen Fachbegriffe,
• Projektbegleitende, überwachte Entwicklerdokumentation,
• Begleitende Schulung,
• Durchgehendes Qualitätssicherungskonzept.

Hinzu kommt, dass sich die Anzahl der Zeilen (Lines of Code), die nötig sind, um ein Problem zu lösen, im Schnitt alle 10 Jahre verzehnfacht. Dies liegt vor allem an den in Bezug auf die eigentliche Funktionalität „nebensächlichen“ Anforderungen, am Aufwand für die grafische Darstellung oder für die Anwenderfreundlichkeit. Außerdem werden häufig Technologien berücksichtigt, die vielleicht gebraucht werden könnten und daher von Anfang an im Code mitgeschleppt werden, weil es einfacher ist als sie nachträglich zu integrieren. Speicherplatz ist billig geworden, und der letztendlich ausgeführte Code ist bis ins Detail laufzeitoptimiert – was macht es also noch aus, wenn der Code insgesamt länger wird? Um diese Anzahl an Zeilen zu bewältigen, sind heute völlig andere Kompetenzen und Techniken zu beherrschen als vor 5 bis 10 Jahren, als noch andere Anforderungen an Softwareentwickler gestellt wurden.

Zeitdruck

Hat man einen optimalen Softwarehersteller gefunden, der alle oben genannten Aspekte mit allen Abhängigkeiten optimal im Griff hat, kann es immer noch zahlreiche Gründe fürs Scheitern geben, die beim Auftraggeber selbst liegen.

Nicht selten vergehen von der Entscheidungen über eine zu schaffende Lösung bis zur Auftragsvergabe Wochen, Monate oder sogar Jahre. Das führt anschließend zwangsläufig zu einem extrem hohen Zeitdruck, wenn dann endlich die Mittel bereitstehen. Dann wird das Entwicklerteam häufig bereits zu diesem Zeitpunkt erst gar nicht mehr um eine zeitliche Abschätzung gebeten, sondern seitens des Auftraggebers direkt ein Datum festgelegt, an dem die ganze Lösung installiert sein und uneingeschränkt laufen muss. Meist steht dieser Termin sogar schon vor der Frage nach den anfallenden Kosten oder den dringend nötigen Gesprächen über den Umfang im Raum.

Der Softwarelieferant steckt dann in der Bredouille. Sagt er die Wahrheit, dass das geplante Projekt innerhalb des gewünschten Zeitrahmens kaum zu schaffen ist, dann braucht er auf weitere Gespräche gar nicht mehr zu hoffen. Pokert er und verschweigt den Zeitdruck, der möglicherweise durch andere parallele zu erledigende Projekte besteht, bleibt er im Rennen, indem er dem Termin zustimmt. Wenn auch vielleicht mit einem schlechten Gewissen, weil er sich bereits jetzt Begründungen zurechtlegen muss, die rechtfertigen, warum es am Ende zeitlich doch nicht ganz hingehauen hat.

Herausforderung Spezifikation

Die zweite Hürde ist die Spezifikation der zu entwickelnden Lösung. Ein Projekt kann nur dann optimal verlaufen, wenn der Kunde zunächst ein gut fundiertes Lastenheft vorlegt und anschließend in enger Kooperation mit dem Softwarelieferanten ein gemeinsames Pflichtenheft erstellt wird. Diese enge Zusammenarbeit hat allerdings meist für den Kunden einen Nachteil: das Pflichtenheft ist so eng mit den Möglichkeiten und Fähigkeiten der Entwicklungsfirma verknüpft, dass eine Auftragsvergabe an diese Firma fast schon zwingend nötig ist, möchte man nicht ein weiteres Mal die Kosten für ein neues Pflichtenheft investieren.

Dieser Nachteil lässt sich für den Kunden nur insofern umgehen, indem er das Pflichtenheft mit der Auflage beauftragt, es neutral zu spezifizieren. In diesem Fall kann er das Projekt anschließend ausschreiben. Für die Softwarefirma hat diese Methode den signifikanten Vorteil, aufgrund genauster Detailkenntnisse eine präzise und realistische Aufwands- und somit Kostenabschätzung abgeben zu können. Diese Vorgehensweise widerspricht leider den üblichen Vorgaben der Öffentlichen Hand und auch zahlreicher größerer Konzerne;, schließlich wird dadurch der Wettbewerb indirekt eingeschränkt. Für einen optimalen Entwicklungsprozess ist ein derart konzipiertes Pflichtenheft aber optimal.

Software-Preisdumping

Der dritte Aspekt, der Projekte scheitern lässt, ist die Tendenz, das sich die Vergabe immer häufiger allein am Preis orientiert. Es ist keine Seltenheit, dass nach einer Ausschreibung die Angebote hinsichtlich der Kosten deutlich voneinander abweichen. Dies kann natürlich darauf zurückzuführen sein, dass einer der Anbieter beispielsweise bereits über vorbereitete Module oder ähnliche Lösungen verfügt (z.B. Adaption vorhandener Quellen), die in der Tat eine reelle Kosteneinsparung ermöglichen. Häufig haben die Preisunterschiede aber einfach damit zu tun, dass der entsprechende Anbieter die Spezifikation nicht detailliert gelesen hat, mit einer sehr vage geschätzten Summe ins Rennen geht und letztendlich die Leistung für den angebotenen Preis gar nicht erbringen kann.

Worst Case und die Folgen

Diese Fälle enden häufig in einem Desaster – und führen nicht selten zu Konventionalstrafen oder gar gerichtlichen Auseinandersetzungen. Das eigentliche Ziel, eine funktionelle Softwarelösung zu bekommen, ist dann nur noch Nebenschauplatz. Man muss sich fragen, was es dem Kunden nutzt, wenn die Softwarefirma aufgrund entsprechender Vertragsstrafen in die Knie gezwungen, die Lösung aber trotzdem nicht fertig wird. Und ob eine Strafe, egal in welcher Höhe, dem tatsächlich entstandenen Schaden überhaupt gerecht wird.

Was passiert dann mit der Software? Zu diesem Zeitpunkt sind die Entwickler meist soweit mit ihrer Arbeiter vorangekommen ist, dass sich niemand findet, der die halbfertige Lösung weiterführen würde. Die Materie zur kilometerbasierten Erfassung einer deutschlandweiten Maut-Gebühr ist allein schon komplex genug, ohne sich auch noch im fremden Quelltext orientieren zu müssen. Ganz davon abgesehen ist ein Wechsel des Softwareanbieters im laufenden Entwicklungsprozess allein schon aufgrund der meist völlig unterschiedlichen eingesetzten Entwicklungsumgebung unmöglich.

Es zeigt sich, welch bedeutende Rolle erfolgreiche Partnerschaften spielen. Kompetenz zeichnet sich nicht allein dadurch aus, aus drei ähnlichen Angeboten einfach das günstigste herauszusuchen. Freilich, wenn drei Anbieter auf eine Ausschreibung hin ähnliche Angebote abgeben und ein vierter, ggf. sogar renommierter Anbieter die gleiche Leistung für die halbe Summe offeriert, dann sind dagegen schwer Argumente zu finden. Gerade bei Entscheidungsträgern im Unternehmen ist dann manchmal ein entsprechendes Rückrat gegenüber der Konzernspitze gefragt, was heute leider Seltenheitswert besitzt.

Fazit

Software-Entwicklung hat direkt mit Menschen und deren Fähigkeiten zu tun. Neben einer hohen fachlichen Kompetenz entscheidet auch die Organisation und die Kooperation während des Entwicklungsprozesses über den Erfolg oder Misserfolg eines Projektes. Die größte Herausforderung ist und bleibt die sachlich-vernünftige Abschätzung, ob der von einer Softwarefirma angebotene Preis und Zeitrahmen hinsichtlich einer sauberen Implementierung zu vertreten ist und ob das Vertrauen in derartige Angaben gegeben ist. Wenn ein Kunde mit einer Softwarefirma gemeinsam auf erfolgreiche Projekte zurückblicken kann, ist das häufig entscheidender als die Nachkommerstellen im Preis unter einem Vertrag. Denn auch hier gilt eine der Basisregeln im Geschäftsleben: „Never change a winning Team“.