Ein häufig anzutreffendes Dilemma bei Software-Entwicklungsprojekten besteht darin, dass der Auftraggeber einerseits keine exakte Spezifikation vorlegen kann, andererseits aber das Projekt zum Festpreis durchführen will. Verschärfend kann ein verbindlicher Liefertermin hinzukommen, der aufgrund externer Randbedingungen unumstößlich feststeht.

In den letzten Jahren haben wir als Projektleiter von Software-Entwicklungsprojekten unterschiedlicher Größe im Automotive-Umfeld immer wieder nach neuen Ansätzen und Wegen gesucht, die Termin- und Budgettreue in unseren Projekten zu steigern und gleichzeitig den Kundennutzen zu erhöhen. Die Methoden und Werkzeuge, die wir in den von uns durchgeführten Projekten als Best Practices identifizierten, haben wir unter dem Schlagwort "Work-to-Budget" gesammelt und aufbereitet.

Alle unsere Work-to-Budget-Methoden und -Werkzeugen konzentrieren sich darauf, den Kundennutzen möglichst effizient zu realisieren. Hierzu müssen zum einen die zentralen Business-Ziele möglichst frühzeitig identifiziert werden. Zum anderen sind alle Tätigkeiten im Projekt konsequent auf diese Business-Ziele und somit auf die Wertschöpfung auszurichten. Insofern steht unser Ansatz in enger Verbindung zum "Value-Driven Project Management" von Kerzner (vgl. Angermeier, 2010), der Wertanalyse (Value Management, vgl. Mathoi, 2007) und der Business-Case-Orientierung der Projektmanagementmethode PRINCE2 (vgl. Rother, 2007).

In diesem Artikel stellen wir anhand eines Projektbeispiels vor, wie wir "Work-to-Budget" in der Praxis anwenden, und bewerten die wichtigsten Erfolgsfaktoren bei diesem Projekt, das besonders große Herausforderungen hinsichtlich Termintreue und Budgeteinhaltung stellte.

Ein IT-Projektbeispiel

In unserem Projektbeispiel ging es um die Neu-Entwicklung eines zum Ausschreibungszeitpunkt nur sehr ungenau spezifizierten Datenbank-Frontends. Über dieses Frontend sollte eine bestehende Datenbank für das Supply-Chain-Management eines Automobilherstellers gepflegt und ausgewertet werden.

Für die Realisierung einer funktionsfähigen ersten Leistungsstufe blieben aufgrund eines wichtigen und nicht verschiebbaren Business-Termins (Start of Production einer neuen Produktlinie, die mit der neuen Anwendung begleitet werden sollte) nur drei Monate Zeit. Einerseits wünschte sich der Kunde einen Werkvertrag, um uns als Lieferanten bei der Einhaltung des Zieltermins und des Budgets verbindlich in die Pflicht nehmen zu können, andererseits waren die Anforderungen an das System lediglich durch eine handgezeichnete Architekturskizze festgelegt, bestehend aus den Datenbankservern, dem Webserver der neuen Anwendung sowie den wichtigsten Schnittstellen des Systems. Eine seriöse Bottom-Up-Schätzung des Aufwands war damit nicht möglich.

Das konventionelle Vorgehen

Um eine Aufwandsschätzung nach traditionellem Vorgehen für die Umsetzung liefern zu können, muss zunächst mit dem Kunden ein Lastenheft erstellt werden. Dieses Lastenheft beschreibt unter anderem die Business-Ziele, also das "was" und "wofür". Auf dieser Basis wird im nächsten Schritt ein Pflichtenheft erstellt, welches das "wie" und "womit" definiert. Diese Konzepte schränken den möglichen Lösungsraum für die konkrete Lösung ein, mit welcher die Business-Ziele erreicht werden sollen. Der potenzielle Auftragnehmer könnte diese Lösung dann im Rahmen eines Werkvertrags dem Auftraggeber zum Festpreis anbieten.

In unserem Beispielprojekt wäre der vom Kunden benötigte Zieltermin längst verstrichen gewesen, bis wir mit dieser Vorgehensweise die für einen Vertrag erforderlichen Dokumente produziert hätten. Für uns stellte sich also die Frage, wie wir ohne diese für ein konventionelles Vorgehen notwendigen Vorarbeiten schnell und unkompliziert zu einem Werkvertrag kämen, um mit der eigentlichen Wertschöpfung starten zu können.

Unser Weg zum Work-to-Budget-Vertrag

Um diesen Konflikt zu lösen, machten wir uns zunächst bewusst, worin die eigentliche Kern-Leistung des Projekts bestehen sollte. Unserem Kunden ging es ja nicht um das IT-System an und für sich, sondern darum, mit dem Einsatz dieses IT-Systems bestimmte Business-Ziele zu erreichen. Die eigentliche Leistung, die wir zusagen mussten, war somit die adäquate Unterstützung dieser Business-Ziele durch ein noch nicht näher definiertes IT-System.

Um ein klares Bild auf diese Ziele zu erhalten, führten wir mit unserem Kunden einen halbtägigen Workshop durch. In diesem sammelten wir gemeinsam alle Business-Ziele, die er mit dem IT-System (als gedachte "Black Box") verfolgt. Durch Brainstorming erhielten wir so eine flache, ungeordnete und nicht priorisierte Liste von Zielen, die wir in Excel dokumentierten. Anschließend reduzierten wir diese Ziele schrittweise auf die zentralen Business-Ziele. Bei der Identifikation dieser Kernziele hinterfragten wir jedes Ziel aus der Excel-Liste: Erreicht das Projekt noch den vom Auftraggeber gewünschten Effekt, wenn dieses Ziel nicht vom Projekt verfolgt wird? Die so gestrichenen Ziele (wie z.B. Rollenkonzept und nicht funktionale Anforderungen) wurden für die spätere Projektdurchführung dokumentiert. Die verbliebenen Kern-Businessziele priorisierten wir gemäß ihrem Beitrag zur Wertschöpfung, indem wir die einzelnen Ziele solange paarweise gegeneinander bewerteten, bis die endgültige Prioritätsreihenfolge feststand.
Tabelle 1 zeigt die auf diese Weise priorisierten Kern-Businessziele und -Anforderungen.