Schlechte Zeiten für Angsthasen

Das Geschäft mit unternehmensindividueller Software-Entwicklung hat sich in den letzten Jahrzehnten nicht wesentlich verändert. Zumindest dann nicht, wenn man die kritischen Phasen, also die frühen und späten, von Software-Aufträgen betrachtet. Während in der eigentlichen Programmierung dank weiterentwickelter Sprachen, Technologie-Frameworks und Entwicklungsumgebungen die Effizienz deutlich gesteigert werden konnte, hat sich der kritischste Erfolgsfaktor kaum verändert: die Übersetzung von Fachlichkeit in Softwarefunktion. Die effizienteste Software-Entwicklung ist jedoch vergebliche Mühe, wenn am Ende eben doch nicht genau das kreiert wurde, was gebraucht wird. Und wenn der Lieferant dann noch beweisen kann, dass ihn keine Schuld trifft, weil ja der Kunde nichts anderes spezifiziert hat als das, was er nun nicht brauchen kann, dann zeigt sich die volle Absurdität heutiger Individualsoftwareprojekte.

Damit befindet sich die Softwarewirtschaft in einem Dilemma: Einerseits bedeuten Individualprojekte zum Festpreis ein unkalkulierbares Risiko für den Lieferanten sofern nicht eine vermeintlich risikomindernde, ausführliche Spezifikation erfolgt. Andererseits zeigt aber die Erfahrung, dass dieses Vorgehen nicht nur teuer ist, sondern auch viel weniger erfolgreich als angenommen. Denn am Ende arbeitet ein Sachbearbeiter eben nicht mit bunten Bildern, wie sie die Tools der Spezifikationsphase produzieren, sondern mit echter Software. Diese sollte er möglichst schnell, also bevor viele Kosten entstanden sind, anfassen können.

Damit spricht alles für agile Verfahren, in denen die Spezifikation auf ein Minimum reduziert wird und stattdessen schnell einsetzbare Software entsteht. Ohne Spezifikation fehlt aber die vertragliche Grundlage, weswegen sich heute kaum ein Lieferant auf einen Festpreis für derartige Projekte einlässt. Leider ist das Risiko in einem derartigen Projekt für den Kunden aber ebenso schwer zu fassen wie für den Lieferanten, so dass es viel zu selten zu echten agilen Projekten in der Individualsoftware-Entwicklung kommt. Agile Projekte gibt es fast nur bei Eigenleistern, aber das ist ein anderes Spiel mit anderen Regeln, wenngleich es die Möglichkeiten dieses Ansatzes aufzeigt.

Am Ende hilft alles nichts: Die Lieferanten von Individualsoftware müssen mehr Risiko übernehmen. Eine Vollkaskoversicherung für gescheiterte Projekte werden Auftraggeber ihnen immer seltener zugestehen. Agile Verfahren bieten die Chance auf besonders effiziente Projekte, was gut für beide Seiten ist. Aber natürlich muss das damit einhergehende Risiko von beiden Seiten getragen werden. Ein Beharren auf vertraglich risikoabsichernde, ausgedehnte Spezifikationsphasen wird es nicht mehr häufig geben – schlechte Zeiten für Angsthasen und Heulsusen in der Softwarewirtschaft.

Und wie können Softwarelieferanten das gesteigerte Risiko solcher Projekte in den Griff bekommen? Zum einen indem sie in die Qualität der Mitarbeiter investieren. Wer fachlich mitreden kann und versteht, wovon der Anwender spricht, baut auch mit höherer Wahrscheinlichkeit die richtige Software. Zum anderen braucht es intelligente Geschäftsmodelle, die die komplexe Interessenlage zwischen Fach- und IT-Abteilungen der Kunden und dem Lieferanten ausbalanciert. Nicht trivial, aber machbar.