Fixtermin, Festpreis aber kein Lastenheft "Work-to-Budget" – den Leistungsumfang nach dem Kundennutzen steuern

Verbindlicher Fixtermin und Festpreis – aber keine ausreichende Spezifikation: Das ist für jeden Auftragnehmer ein Schreckensszenario. Matthias Eberspächer und Ralf Neubauer haben für diese immer wieder anzutreffende Situation in Software-Entwicklungsprojekten eine pragmatische Herangehensweise entwickelt, die sie "Work-to-Budget" nennen: Zusammen mit dem Auftraggeber identifizieren sie die zentralen Business-Ziele des Projekts und legen die Toleranzen für die Abnahmekriterien fest. Auf dieser Basis steuern sie den Leistungsumfang und maximieren – innerhalb des gesetzten Rahmens – den Kundennutzen. Wie dies funktioniert, schildern sie an einem Beispiel aus ihrer Praxiserfahrung.

 

Fixtermin, Festpreis aber kein Lastenheft "Work-to-Budget" – den Leistungsumfang nach dem Kundennutzen steuern

Verbindlicher Fixtermin und Festpreis – aber keine ausreichende Spezifikation: Das ist für jeden Auftragnehmer ein Schreckensszenario. Matthias Eberspächer und Ralf Neubauer haben für diese immer wieder anzutreffende Situation in Software-Entwicklungsprojekten eine pragmatische Herangehensweise entwickelt, die sie "Work-to-Budget" nennen: Zusammen mit dem Auftraggeber identifizieren sie die zentralen Business-Ziele des Projekts und legen die Toleranzen für die Abnahmekriterien fest. Auf dieser Basis steuern sie den Leistungsumfang und maximieren – innerhalb des gesetzten Rahmens – den Kundennutzen. Wie dies funktioniert, schildern sie an einem Beispiel aus ihrer Praxiserfahrung.

 

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.

Tabelle 1: Die priorisierten Kern-Businessziele und -Anforderungen.
Ziel-Nr.Ziel

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
8 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 10
Kommentare 8

Alle Kommentare (8)

Guest

Für solch einen Projektrahmen bietet sich Scrum als Vorgehen an. Da der Begriff Product Backlog gefallen ist, wurde agil entwickelt?

 

Hans-Heinz
Maier

Hallo, das Prinzip ist gut. Ich habe das oft so gemacht: Mit dem Kunden und einem/meinem Programmierer mit Überblick habe ich mich an einen Tisch gesetzt und bin wie folgt vorgegangen: - Der Kunde sagte, was er realisiert haben möchte, also die Liste der Funktionen in seinen Worten - Den Programmierer fragte ich, welche Funktion besonders teuer und aufwändig ist zu realisieren und warum - Dann überlegten wir, ob man das weglassen kann oder einfacher machen kann,oder anders, damit es nicht so teuer ist - So haben wir jede Funktion durchleuchtet, der Kunde konnte immer gleich sagen, ob ihm das wichtig ist oder nicht - Oft haben wir dem Kunden gesagt: Wenn Sie das so haben wollen,kostet das so und soviel, ist Ihnen das die Sache wirklich wert, wollen Sie dafür wirklich soviel Geld ausgeben? Dann hat er manchmal doch gezuckt und steckte zurück, er wusste ja nicht, was er für Kosten verursacht. Es war erstaunlich, in welch kurzer Zeit technische Probleme und Kundenwünsche so behandelt werden konnten, oft ergab sich eine bessere Lösng als der Kunde forderte, denn er wusste ja oft nicht, was in manchen Fällen mit wenig Aufwand möglich war. So gehts also auch.

 

Walter
Plagge
Dipl.-Phys.

Ein schönes Beispiel dafür, was möglich ist, wenn Kunde und Lieferant vertrauensvoll zusammenarbeiten. Erfolgsgarant ist nicht nur die Konzentration auf die Businessziele, sondern die Tatsache, dass Experten für Businessziele und Experten für Machbarkeit VOR Vertragsabschluss zusammensitzen, was - gerade bei Festpreisprojekten - leider oft nicht der Fall ist ...

 

Guest

Hallo *, vielen Dank für das positive Feedback. Es freut uns sehr, dass unser Appell für mehr Gemeinsamkeit im Projekt und Konzentration auf die eigentlichen Ziele auf so viel Zustimmung trifft. @rainwebs: Unser Vorgehen war "agil" im Wortsinne; Scrum im engeren Sinne des mittlerweile etablierten Vorgehensmodells haben wir nicht angewendet. Unseren Themenspeicher kann man als projektübergreifendes "Product-Backlog" verstehen (daher auch die Anführungsstriche). Unsere dreiwöchige rapid-Prototyping-Phase für die Entwicklung der ersten Maske kann man sich so vorstellen wie von Frau/Herrn "Maier HH" beschrieben (PL und Senior-Entwickler im Dialog mit dem Kunden). In der darauf folgenden Realisierung (im Entwickler-Team) haben wir aus Zeitgründen jede neue Maske so schnell wie möglich mit dem Kunden abgestimmt - selbst Scrum mit seiner festen Sprint-Dauer und geregeltem Sprint-Ablauf wäre für uns hier zu beschränkend gewesen. Trotzdem gebe ich Ihnen recht, dass Scrum eine sinnvolle Ergänzung des beschriebenen Vorgehens ist, wenn die Realisierungsphase länger ist. @Walter Plagge: Leider gibt es häufig Beschränkungen (wie z.B. Ausschreibung mit mehreren Anbietern), die dieses an sich gute Vorgehen verhindern. Ideal wäre eine zweistufige Áuftragsvergabe: Eine Anbieterauswahl z.B. auf Basis von Stundensätzen und Know-How-Nachweis, danach ein Festpreis-Vertrag mit dem ausgewählten Anbieter nach Work-to-Budget.

 

Volker
Kraska

Das erinnert auch mich sehr an seit langem bekannte Thema "agile Software-Entwicklung und agiles Projekt-Management". Das Vorgehen bzgl. der SW-Entwicklungen heißt dann in der Tat SCRUM - und ist seit Jahren ein bewährtes Vorgehen. Trotz neuen Namens (Work-to-budget) sehe ich da Unterschiede.

 

Volker
Kraska

Hallo, ich bin nicht sicher, ob Herr Thaler in seinem Kommentar ein Wort vergessen hat - aber man könnte den Artikel in der Tat auch "agile Softwareentwicklung mit SCRUM" nennen. Ich sehe da trotz des Names "Work to budget" eben keinen nennenswerten Unterschied. Und wenn die wesentliche Herausforderung die Steuerung war (btw: das ist es in jedem Projekt!), dann erscheint mir der Projektplan doch sehr "generisch".

 

Guest

Hallo Herr Thaler, hallo Herr Martin, vielen Dank für Ihre Anmerkungen. Nein, wir haben weder "Agilität", noch Scrum noch das Projektmanagement oder die Softwareentwicklung neu erfunden. Wie wir in der Einleitung schreiben: "(...) 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. (...)" Das Ziel der agilen Softwareentwicklung ist es dagegen den eigentlichen Softwareentwicklungsprozess so flexibel und schlank wie möglich zu machen. Unser Vorgehen stellt den Kundennutzen in den Mittelpunkt und richtet den Entwicklungsprozess danach aus. Nur danach entscheiden wir über die zu verwendenden Methoden und Werkzeuge. Deshalb haben wir in diesem Projekt auch nicht mit festen Scrum-Sprints gearbeitet, in anderen Projekten könnte Scrum den Work-to-Budget-Gedanken am besten unterstützen. Wir haben übrigens auch in reinen Konzeptions-Projekten mit Work-to-Budget-Methoden gearbeitet. Insofern sehen wir eher eine Verwandtschaft zur Wertanalyse oder dem Value-Driven Project Management.

 

Manfred
Damsch

Ich halte diese agile Vorgehensweise für absolut richtig, sie setzt allerdings ein wirklich partnerschaftliches Verhältnis zum Auftraggeber voraus und verlangt nach nachhaltiger Gültigkeit der getroffenen Vereinbarungen. Wie oft kommt es vor, dass erst während der Realisierung klar wird, was eigentlich benötigt wird. Ganz besonders bei IT-Systemen, deren Funktionen und Verhalten mit Geschäftsprozessen synchronisiert laufen müssen. Hier sind die betroffenen Geschäftseinheiten häufig nicht in der Lage, den gesamten Prozess zu überschauen und leicht gehen so wichtige Anforderungen verloren, die später als längst vereinbart eingefordert werden. Wenn das Verhältnis zwischen AG und AN aber funktioniert, ist das die angenehmste Art der Zusammenarbeit - mit Vorteilen für beide Seiten.