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

Verbindlicher Fixtermin und FestpreisFestpreisEin Festpreis ist der vom Auftraggeber an den Auftragnehmer zu zahlende Preis für die zu erbringende Projektleistungen, wobei Höhe und Zahlungsweise im vorhinein vertraglich festgelegt sind. Die Kalkulation des Festpreises ist dabei Aufgabe des Auftragnehmers, der dem Auftraggeber ein entsprechendes Angebot unterbreitet. – aber keine ausreichende Spezifikation: Das ist für jeden AuftragnehmerAuftragnehmerDer Auftragnehmer ist Verkäufer eines Produkts oder einer Dienstleistung. Er ist Vertragspartner des Auftraggebers, der die im Lastenheft spezifizierte Leistung kauft. 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 AbnahmekriterienAbnahmekriterienAbnahmekriterien sind vertraglich festgelegte Kriterien, die erfüllt sein müssen, damit der Auftraggeber zur Abnahme einer Projektleistung verpflichtet ist. fest. Auf dieser Basis steuern sie den LeistungsumfangLeistungsumfangLeistungsumfang ist die Menge aller Leistungen, die für die Abnahme eines Projekts verpflichtend zu erbringen sind. und maximieren – innerhalb des gesetzten Rahmens – den KundennutzenKundennutzenDer Kundennutzen ist die Gegenleistung für den vom Kunden bezahlten Preis. Jedes Produkt und jede Dienstleistung muss deshalb danach beurteilt werden, welchen Nutzen es bei seinen potentiellen Kunden realisiert. Beispielsweise erbringt ein PKW für sich genommen noch keinen Kundennutzen. Ohne die entsprechende Infrastruktur (Straßen, Tankstellen usw.) ist er wertlos.. 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 FestpreisFestpreisEin Festpreis ist der vom Auftraggeber an den Auftragnehmer zu zahlende Preis für die zu erbringende Projektleistungen, wobei Höhe und Zahlungsweise im vorhinein vertraglich festgelegt sind. Die Kalkulation des Festpreises ist dabei Aufgabe des Auftragnehmers, der dem Auftraggeber ein entsprechendes Angebot unterbreitet. – aber keine ausreichende Spezifikation: Das ist für jeden AuftragnehmerAuftragnehmerDer Auftragnehmer ist Verkäufer eines Produkts oder einer Dienstleistung. Er ist Vertragspartner des Auftraggebers, der die im Lastenheft spezifizierte Leistung kauft. 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 AbnahmekriterienAbnahmekriterienAbnahmekriterien sind vertraglich festgelegte Kriterien, die erfüllt sein müssen, damit der Auftraggeber zur Abnahme einer Projektleistung verpflichtet ist. fest. Auf dieser Basis steuern sie den LeistungsumfangLeistungsumfangLeistungsumfang ist die Menge aller Leistungen, die für die Abnahme eines Projekts verpflichtend zu erbringen sind. und maximieren – innerhalb des gesetzten Rahmens – den KundennutzenKundennutzenDer Kundennutzen ist die Gegenleistung für den vom Kunden bezahlten Preis. Jedes Produkt und jede Dienstleistung muss deshalb danach beurteilt werden, welchen Nutzen es bei seinen potentiellen Kunden realisiert. Beispielsweise erbringt ein PKW für sich genommen noch keinen Kundennutzen. Ohne die entsprechende Infrastruktur (Straßen, Tankstellen usw.) ist er wertlos.. Wie dies funktioniert, schildern sie an einem Beispiel aus ihrer Praxiserfahrung.

Wir empfehlen zum Thema Controlling
Methoden des modernen Portfoliomanagements

Die richtigen Dinge tun – für mehr Fokus, Agilität und Produktivität im Unternehmen! In unserem E-Learning-Seminar lernen Sie in nur 4 Workshops, wie Sie Ihr Portfolio mit modernen Methoden organisieren und ausbauen.  Mehr Infos

Ein häufig anzutreffendes Dilemma bei Software-Entwicklungsprojekten besteht darin, dass der AuftraggeberAuftraggeberDer Auftraggeber eines Projekts ist der wichtigste Projektbeteiligte (Stakeholder). Er erteilt den Auftrag und ist der Vertragspartner, der über den Erfolg des Projekts endgültig entscheidet. einerseits keine exakte SpezifikationSpezifikationSpezifikation ist die exakte, vollständige und für eine Überprüfung geeignete Beschreibung eines Gegenstands oder eines Prozesses. Innerhalb des Projektmanagements definiert die Spezifikation das Projektziel und die Werke (Liefergegenstände) des Projekts. Das Lastenheft ist die vollständige Dokumentation aller erforderlichen Spezifikationen in einem Projekt. Im Rahmen des Konfigurationsmanagements ist die Spezifikation eine Referenzkonfiguration. vorlegen kann, andererseits aber das Projekt zum Festpreis durchführen will. Verschärfend kann ein verbindlicher Liefertermin hinzukommen, der aufgrund externer RandbedingungenRandbedingungenDie Randbedingungen eines Projektes sind die vom Projektumfeld vorgegebenen Bedingungen, die bei der Projektplanung nicht beeinflussbar sind und daher als gegebene Größen verwendet werden müssen. 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 PRINCE2PRINCE2PRINCE2 ® ist ein vollständiges Projektmanagement-System, bestehend aus Prozessdefinitionen, Rollenbeschreibungen, Vorlagen für Management-Produkte und Methoden. Das Akronym "PRINCE" steht für "PRojects IN Controlled Environment". (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 ErfolgsfaktorenErfolgsfaktorenErfolgsfaktoren im Projektmanagement sind empirisch bestimmte Bedingungen, die dazu beitragen, dass die Stakeholder ein Projekt als erfolgreich bewerten. In der Fachliteratur und in – meist qualitativen – Untersuchungen werden regelmäßig folgende Bedingungen für eine erfolgreiche Projektdurchführung genannt: 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ätzungAufwandsschätzungAufwandsschätzung wird in drei Bedeutungen verwendet: Das Erstellen einer Prognose über den Aufwand, der erforderlich ist, um eine Aufgabe durchzuführen oder ein Produkt herzustellen Methode, um Aufwände zu prognostizieren Schätzwert für einen Aufwand 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 PflichtenheftPflichtenheftDas Pflichtenheft ist der vom Auftragnehmer erstellte Projektplan, mit dem er das Lastenheft des Auftraggebers erfüllen möchte. 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.

Gleich kostenlos weiterlesen!

  • Zum Newsletter anmelden und diesen Artikel freischalten
  • Jede Woche neue Inhalte, Tipps und Tools per E-Mail
Gratis Newsletter bestellen & sofort weiterlesen

 

Hiermit melde ich mich zum Newsletter an. Ich habe die Datenschutzrichtlinien gelesen und akzeptiere diese. Ihre Daten nutzen wir ausschließlich zum Newsletter-Versand. Sie können sich jederzeit abmelden, indem Sie auf den Link in der Fußzeile unserer E-Mails klicken. Informationen zu unserem Datenschutz finden Sie hier.
DownloadDownload

Jetzt Feedback geben und mitdiskutieren!

Wir würden uns über Ihre Bewertung und/oder einen Kommentar freuen ‒ nur so können wir Ihnen in Zukunft noch bessere Inhalte liefern.

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

Alle Kommentare (10)

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.

 

Tassilo
Kubitz

Ich bin erst jetzt über das Spotlight auf den Artikel gestoßen. Ein analoges Verfahren benutze ich schon seit langer ZeitZeitZeit ist eine der zentralen Steuerungsgrößen des Projektmanagements und bildet neben Kosten und Leistungsumfang im sog. Magischen Dreieck einen der drei Eckpunkte. Mittlerweile sind Qualität, Risiko und Nutzen als weitere Steuerungsgrößen etabliert. Je nach Projektart ist der Faktor Zeit besonders kritisch, z.B. im Veranstaltungsmanagement oder bei Wartungs- und Instandhaltungsprojekten. und habe dabei eher den Begriff aus der Baubranche "design2cost" benutzt. Das haben meine Kunden bisher immer gut verstanden.

Das ureigentliche ProblemProblem1) Aufgabenstellung, für deren Erfüllung noch keine Arbeitsanweisung besteht und für die es eine neue Lösung zu entwickeln gilt (z.B. Produktinnovation). 2) Unerwünschte Abweichung der Ist-Situation von der Soll-Situation (z.B. Kostenüberschreitung). 3) Risikofolge, die Schaden verursachen kann (z.B. Patentklage eines Wettbewerbers). 4) Einschränkende Randbedingung zur Erfüllung von Aufgaben. (z.B. Verfügbarkeit einer Engpassressource). beim "Aufs-Budget-Passendmachen" ist doch der Mensch, der bei Verzicht oder Weglassen sofort Verlustängste hat.

Hier empfehle ich eine sehr transparente Methode, die quasi einem Puzzle entspricht, wo man auf eine gegebene Grundfläche (Budget/Termin) die Features "Bauklötze" mit einer eigenen Grundfläche "Kosten" und einer Höhe "Nutzen" verteilt. Das ZielZielZiel ist ein prognostizierter Zustand, der ein bestimmtes Handeln legitimiert. Um ein Ziel zu erreichen ist ein Plan erforderlich. Sowohl Ziel als auch Plan sind charakterischte Bestandteile eines Projekts . Siehe Projektziel . des "Spiels" ist es das maximale Volumen "Outcome" zu erzeugen.

Details gibts hier im projektmagazin: https://www.projektmagazin.de/artikel/agile-festpreisprojekte-der-praxi… (Teil 1) und https://www.projektmagazin.de/artikel/agile-festpreisprojekte-der-praxi… (Teil 2)

Bei meinen Projekten klappt das erstaunlich gut bei unterschiedlichsten Brachen und Auftraggebern. Auch den "klassisch denkenden".

Würde mich freuen, von den Autoren hierzu mal Feedback zu bekommen.

Viele Grüße
Tassilo Kubitz

Hallo Herr Kubitz,

vielen Dank für Ihren Kommentar, es freut uns natürlich, dass das Thema auch nach einigen Jahren noch so aktuell ist.

In 2012, als wir diesen Artikel geschrieben haben, war der "agile Festpreis" noch nicht viel mehr als ein Schlagwort, deshalb spielt er auch in unserem Artikel keine RolleRolleRolle bezeichnet eine temporäre Funktion einer Person oder Organisationseinheit innerhalb der Projektorganisation. Eine Rolle wird beschrieben durch Aufgaben, Befugnisse und Verantwortungen. Zur vollständigen Definition einer Rolle gehört die Angabe, ob sie teilbar (d.h. ob sie von mehreren Personen wahrgenommen werden kann) und kombinierbar (d.h. ob sie mit anderen Rollen gemeinsam von einer einzigen Person wahrgenommen werden kann)..

Unter "design-to-cost", bzw. "design-to-budget" haben wir damals verstanden, dass ein Kunde aus einer Anzahl von Features nur die auswählen kann, die er sich leisten kann. Die anderen entfallen ersatzlos. Dagegen verspricht unser Vorgehen die Umsetzung aller Features, aber in verhandelbarer Ausprägung/Qualität.

Den interessierten Lesern empfehle ich auf jeden Fall die Lektüre ihres Artikels!