Agiler Festpreis flexibel bei Planungssicherheit

Der Begriff „agiler Festpreis“ (englisch: „Agile Fixed Price“) hat sich inzwischen so etabliert, dass er sogar einen eigenen Wikipedia-Eintrag vorweisen kann. Jeder, der mit der agilen Methodik in der Software-Entwicklung oder in einem anderen Zusammenhang vertraut ist, wird sich wahrscheinlich über die Verbindung von „agil“ und „Festpreis“ wundern, da es sich hierbei für viele um einen unüberwindbaren Gegensatz handelt.

Bei agilen Projekten werden die Anforderungen nicht von Anfang an in Stein gemeißelt –  Parameter und Details lassen sich im Laufe der Zeit verändern, wenn es die Situation erfordert.

Bei Festpreis-Projekten hingegen ist alles von Anfang an vorgegeben. Der Kunde verlangt Klarheit darüber, welche Leistung wann und zu welchen Kosten geliefert wird.

Befürworter von agilen Projekten argumentieren, dass in der Praxis die meisten Projekte pünktlich, im Budget und zur Zufriedenheit des Auftraggebers geliefert werden. Und auch wenn es viele Belege hierzu gibt, so muss der Auftraggeber bei traditionellen agilen Verträgen dennoch einen Vertrauensvorschuss leisten.

„Sie bestehen also darauf, dass wir eine bessere Leistung pünktlich und innerhalb der vereinbarten Kosten erhalten, wenn wir im Vorfeld den Umfang, das Budget und die Frist des Projekts nicht definieren oder vertraglich festlegen? Und falls dies nicht der Fall sein sollte, ist dies auch gut, denn das bedeutet im Umkehrschluss, dass die ursprüngliche Frist und das Budget falsch definiert waren?“

Das Problem wird deutlich – der agile Ansatz lässt sich nur schwer verkaufen. Dennoch hat er sich als der dominierende Ansatz in der Software-Entwicklung etabliert, insbesondere im Zusammenhang mit großen, komplexen Projekten, die hierzu Scaled Agile Frameworks verwenden. In der Praxis hat sich diese Form von Verträgen bewährt. Vor allem trägt ein agiler Ansatz wesentlich dazu bei, das Risiko von Investitionsruinen zu verhindern, wie wir später noch genauer sehen werden.

Das bedeutet im Umkehrschluss jedoch nicht, dass Projektsponsoren durch den agilen Ansatz nicht mehr auf Zeitpläne und Kostenparameter achten sollten. Denn ein Software-Entwicklungsprojekt liefert nur dann das gewünschte ROI, wenn es in der Lage ist, zu einem gewissen Zeitpunkt und bis zu einem bestimmten Preis das zu tun, wofür es ursprünglich geplant wurde.

Dem Sponsor ist ebenfalls bekannt, dass wenn die technischen Spezifikationen, die Frist und das Budget bereits vor Projektbeginn genau festgelegt werden und Abweichungen nicht erlaubt sind, das Risiko für Fehler im Endprodukt massiv erhöht wird.

In diesem Zusammenhang wird deutlich, warum das Konzept eines agilen Festpreises so attraktiv ist. Es verspricht den besten Kompromiss beider Welten: Genug Flexibilität, um sicherzustellen, dass das Endprodukt den beabsichtigten organisatorischen Nutzen bietet, jedoch ohne das Risiko einer verspäteten Lieferung oder zu einem Preis, der die Organisationsziele des Sponsors durchkreuzen würde.

Aber ist es tatsächlich möglich, dass ein Entwicklungsteam ein agiles Projekt ausführen und sich dennoch absolut an Fristen oder an das vorgegebene Budget halten kann? Oder ist der agile Festpreis nach all diesen Überlegungen nicht mehr als das perfekte Beispiel einer kognitiven Dissonanz?

In diesem Beitrag werden wir die schwer vereinbaren Prioritäten von agilen und Festpreis-Software-Entwicklungsprojekten genauer skizzieren und versuchen, diese durch den agilen Festpreis miteinander zu verbinden. Wir werden zudem auf unseren bevorzugten Ansatz, das „Controlled Agile“, genauer eingehen.

Sind agile mit Festpreis-Verträgen vereinbar?

Die agile Methodik wird eher als eine Art Ansatz oder Denkweise und nicht als ein schrittweiser Prozess beschrieben. Das Kernkonzept eines agilen Ansatzes für die Software-Entwicklung besteht darin, dass es sich um einen iterativen Prozess handelt. Ein größeres Projekt wird hierdurch in kleinere Teile zerlegt, die auch als „Sprints“ bezeichnet werden. Jeder Sprint besteht aus Entwicklungsaufgaben, die so zusammengefasst sind, dass das Resultat eines jeden abgeschlossenen Sprints ein greifbares Arbeitsergebnis darstellt, dass der Software hinzugefügt werden kann.

Allgemeine Anforderungen wie Funktionalität und Benutzererfahrung werden am Ende jedes Sprints überprüft und bevorstehende Sprints werden dementsprechend angepasst. Nicht umsonst gehören regelmäßige Feinabstimmungen und Anpassungen zur Maxime eines jeden agilen Projekts, während die Begrüßung von Veränderungen eines der 12 Prinzipien des Agilen Manifests darstellt.

4 Leitsätze des Agilen Manifests

1. Individuen und Interaktionen mehr als Prozesse und Werkzeuge
2. Funktionierende Software mehr als umfassende Dokumentation
3. Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
4. Reagieren auf Veränderung mehr als das Befolgen eines Plans

Nummer 4 der Leitsätze, reagieren auf Veränderung mehr als das Befolgen eines Plans, ist gleichzeitig Ausdruck der enormen Flexibilität, die jedem agilen Software-Entwicklungsprojekt innewohnt.

Agil klingt wie ein Freifahrtschein, um Entwicklungsbudget und Fristen zu überschreiten

Die adaptive, iterative und agile Denkweise könnte auf Skeptiker wie ein Freifahrtschein wirken, der es Entwicklern ermöglicht, das eingeplante Budget und die Fristen zu überschreiten. Wie kann eine Organisation den Wert eines Projekts kalkulieren, wenn von Anfang an wenig bis gar nichts in puncto Projektumfang, Zeitpläne und das Budget in Stein gemeißelt ist?

Befürworter von agilen Projekten würden antworten, dass sich die agile Methodik in der Praxis bewährt hat und dass es nachweislich Belege gibt, die diesen Fakt bestätigen – besonders dann, wenn es sich um große und komplexe Projekte handelt.

Wie passt das zusammen? In einem großen, komplexen Software-Entwicklungsprojekt ist es fast unmöglich, jedes Detail im Voraus genau einzuplanen. Es gibt mehrere Beispiele für enorm teure Projekte, die zu Investitionsruinen wurden, obwohl sie im Vorfeld minutiös geplant wurden. Nach der Fertigstellung der Projekte wurde jedoch Folgendes deutlich:

• Die technischen Eigenschaften der Software funktionieren nicht wie gewünscht
• Die Software liefert eine funktionierende Lösung, die jedoch niemand nutzen möchte
• Die Software liefert eine funktionierende Lösung, die keinen Mehrwert bietet

Große Organisationen wie Banken und Regierungsabteilungen sind berühmt für Investitionsruinen, die mit exorbitanten Kosten verbunden sind. Zwei der bekanntesten Beispiele aus Großbritannien werden von den Unternehmensberatern Citi detailliert beschrieben:

DAS 500-MILLIONEN-PFUND-E-BORDERS-PROGRAMM

Einer der Hauptgründe für das Scheitern dieses Projekts war, dass die Anforderungen nicht genau genug kommuniziert wurden und das Projekt auf der Grundlage von Annahmen geplant wurde, die sich letztendlich als unbegründet herausgestellt haben. Zum Beispiel:

• Als das System im Jahre 2007 bestellt wurde, hat niemand in der Regierung bemerkt, dass die Ziele laut EU-Recht illegal waren
• Das Pilot-Projekt wurde nur an Flughäfen ausprobiert und es wurde angenommen, dass das System auch in Häfen und im Eurotunnel funktionieren würde. Dem war leider nicht so

DAS 10-MILLIARDEN-PFUND-NHS-TECH-PROGRAMM

Seit der Planung im Jahre 2003 war allseits bekannt, dass es sich bei diesem Programm des National Health Service (NHS), dem britischen Gesundheitssystem, um ein Mammutprojekt handeln würde – nicht umsonst wurde es als „das weltweit größte Programm für zivile Informationstechnologie“ bezeichnet.

In einem so großen und komplexen IT-Programm, das über mehrere Jahre verläuft, ist es unmöglich, individuelle Fehlerquellen einzeln zu betrachten. Bereits im August 2005 wurden Vorbehalte geäußert; das Programm wurde aber erst im Juli 2011 eingestellt. Zwei Punkte lassen sich hierbei nicht abstreiten:

• Der Umfang des Programms war schlicht und ergreifend zu riesig, um selbst von dem erfahrensten Team bewältigt zu werden.
• Es gab keine Unterstützung der Endnutzer und die allgemeine Begeisterung aller Beteiligten hielt sich in Grenzen: 2008 sagten zwei Drittel der Ärzte, sie würden sich weigern, ihre eigenen medizinischen Unterlagen im System zu speichern.

Natürlich stellen diese beiden Beispiele spektakuläre Einzelfälle dar, die enorme Summen an Geld, Zeit, Aufwand und Opportunitätskosten zur Folge hatten. Dennoch kennt jeder, der für einen bestimmten Zeitraum in der Software-Entwicklung gearbeitet hat, ebenfalls Projekte, dessen Technologielösungen nicht wie beabsichtigt funktioniert haben, nicht verwendet wurden oder keinen Mehrwert erbracht lieferten.

Diese Probleme können auch bei kleineren Projekten auftreten.

Die agile Methodik wurde entwickelt, um Investitionsruinen bestmöglich zu vermeiden. Anstatt eine vollständige und umfassende Softwarelösung von Anfang bis Ende ins kleinste Detail zu planen, nur um anschließend feststellen zu müssen, dass sie entweder nicht wie beabsichtigt funktioniert oder keinen Mehrwert liefert, wird das Projekt in kleinere Arbeitskomponenten unterteilt – die sogenannten Sprints.

Jeder Sprint sollte zu einer funktionierenden und testbaren Softwarelösung führen, quasi einem „Mini-Produkt“, das auf Wirksamkeit, Nützlichkeit und Beitrag zu den Endzielen des gesamten Projekts bewertet werden kann. Falls ein Sprint eine Investitionsruine hervorbringen sollte, ist der Schaden nicht besonders groß und frühere sowie zukünftige Sprints werden hierdurch ebenfalls nicht beeinträchtigt.

Bei einem traditionellen „Wasserfall“-Ansatz hingegen muss möglicherweise ein großer Teil des ganzen Projekts von Grund auf neu strukturiert werden, wenn etwas in der Mitte mit der Software nicht in Ordnung ist. In vielen Fällen  wird das Projekt auch einfach fallengelassen, da die Reparatur zu viel Kosten oder zu viel Zeit in Anspruch nehmen würde.

Agil klingt super, ich bin dabei! Aber ich bräuchte noch A, B & C bis Juni und mein Budget ist….

Ein agiler, iterativer Ansatz für die Software-Entwicklung scheint auf den ersten Blick sinnvoll. Richtig ausgeführt gilt die Methodik als narrensicher, um Investitionsruinen oder ähnliche Fehler bestmöglich zu vermeiden. Deshalb haben sich agile Projekte auch als dominierende Software-Entwicklungsmethode durchgesetzt.

Dieser Ansatz kann aber auch zu Reibungen in der Finanzplanung, der Geschäftsstrategie und den firmeneigenen Entwicklungsprozessen führen. Die meisten Unternehmen richten sich nach einem Zeit- und Kostenbudget, wenn sie ein neues Projekt in Angriff nehmen, egal ob es um interne Effizienz oder Produkte für Dritte geht.

Werden diese Parameter nicht eingehalten, kommt es zur Wertminderung, da das Zeitfenster verloren geht oder sich der finanzielle ROI des Projekts nicht mehr lohnt.

Das bedeutet konkret, dass eine agile Methodik immer noch Zeitpläne und Budgets berücksichtigen muss. In den meisten Fällen können Budget- und Zeitbeschränkungen nicht einfach verworfen werden, auch wenn dies im Ansatz gegen die Prinzipien einer agilen Vorgehensweise spricht. Time-to-Market und Budget sind immer noch wichtige Variablen, die im Auge behalten werden müssen.

Der agile Festpreis – Kann das Risiko minimiert und der Nutzen maximiert werden?

Der agile Festpreis wird von uns deshalb vorgestellt, weil er alle Vorteile eines flexiblen, agilen Ansatzes bietet, ohne sich hierbei negativ auf Budget und Fristen auszuwirken. Ein agiler Festpreis sorgt für Planbarkeit und Sicherheit.

Aber hieraus folgt ein Logikfehler. Wenn alle drei Seiten des Entwicklungsdreiecks – Umfang, Zeit und Budget – festgelegt sind, wie agil kann der Ansatz überhaupt sein? Anders sähe die Sache aus, würde man das Dreieck mit dem vierten Parameter „Qualität“ zu einem Quadrat verwandeln. Aber welche Organisation würde Qualität als einzige Variable zulassen?

Dies bringt uns zu unserem letzten Ansatz: Lässt sich die agile Methodik in Festpreis-Projekte integrieren? Sind agile Festpreise nur Wunschvorstellungen oder eine Bereicherung der traditionellen, agilen Methodik? Eine Verschmelzung beider Ansätze würde nämlich eine funktionsfähige Software bereitstellen und gleichzeitig die Anforderungen an Budget und Lieferfristen erfüllen.

Agile Festpreise erfordern ein gewisses Geben und Nehmen. Wir sind der Auffassung, dass hier die englische Wortschöpfung „Controlled Agile“ präziser ist. Die Methodik ist praxisnah und erfolgversprechend,  sofern sie sowohl vom Sponsor eines Projekts als auch vom Team, was für die Durchführung verantwortlich ist, vollständig verstanden und richtig umgesetzt wird. Im Folgenden zeigen wir, wie es geht:

Der agile Festpreis und das Controlled Agile sind keine Wunschvorstellung

Das Kernproblem, das eine agile Festpreis-Methode lösen muss, besteht darin, dass ein festgelegter Preis normalerweise keine Änderungen in Bezug auf Frist, Budget und Mehrwert zulässt. Auf der anderen Seite muss das agile Team auf Änderungen reagieren, die die Sprints vorschreiben.

Wie kann eine einzelne Methodik Veränderungen verhindern und sie gleichzeitig begrüßen?

Hierauf lässt sich eine Anschlussfrage stellen. Was genau muss eigentlich geändert werden?

Das Project Management Institute (PMI) hat hierzu eine der klarsten Beschreibungen erstellt, wie sich diese Frage auf das Verhältnis zwischen Festpreis und Agile auswirkt. Um hier zu einer Antwort zu gelangen, müssen wir zuerst drei weitere Begriffe klären:

1. Verkaufsangebot: Alle Projekte konkurrieren um Ressourcen. Ein Angebot formuliert klar und deutlich den Wert eines bestimmten Projekts. Hierbei werden übergeordnete Ziele, geschätzte Kosten und ein Zeitplan formuliert.
2. Vertrag: Sobald ein bestimmter Verkäufer auf der Grundlage des Angebots ausgewählt wurde, wird eine „für beide Seiten verbindliche Vereinbarung“ getroffen, um die geschäftlichen Bedingungen des vorgeschlagenen Projekts umzusetzen.
3. Projekt: Zum Schluss wird auf Grundlage des bestehenden Vertrages ein Projektteam beauftragt, um die definierten Ziele in die Tat umzusetzen.

Wir haben drei verschiedene und aufeinanderfolgende Aktivitäten: Angebot > Vertrag > Projekt. Der Vertrag macht lediglich die im Angebot festgelegten Einschränkungen (Umfang, Budget, Frist) geltend. Diesen Schritt können wir außen vor lassen und uns stattdessen darauf konzentrieren, wie Angebote und Projekte für ein agiles Festpreis-Projekt korrekt erstellt und umgesetzt werden.

Angebote für agile Festpreis-Projekte – Best Practices zur Risikominimierung

Wie erstellen wir ein agiles Festpreis-Angebot, das die geschätzten Fixkosten und die festgelegte Frist definiert und gleichzeitig die Wahrscheinlichkeit erhöht, dass die erforderlichen und definierten Projektergebnisse auch geliefert werden?

Der wichtigste Faktor ist die sorgfältige Definition der geschäftlichen Erfolgskriterien eines jeden Projekts. Festpreis-Projekte priorisieren eine fristgerechte Fertigstellung innerhalb des vorgegebenen Budgets. Eine der Stärken der agilen Methodik ist dagegen die Verwendung von „Zeitboxen“. Die korrekte Verwendung von Zeitboxen sollte die Einhaltung von Zeitplan und Budget gewährleisten. Dies setzt jedoch voraus, dass der Umfang gegebenenfalls angepasst werden muss.

Der Umfang eines agilen Festpreis-Projekts sollte als Geschäftsziel festgelegt werden

„Wenn der Umfang veränderbar ist, gibt es keinen festen Preis“ ist wohl einer der ersten Einwände. Damit agile Festpreise funktionieren, müssen nicht die Features, sondern der Umfang als Geschäftsziel definiert werden. Features dagegen müssen als Mittel zum Zweck und als variabel verstanden werden, wenn wir die Begriffe „agil“ und „Festpreis“ in einen sinnvollen Zusammenhang bringen möchten.

Das PMI beschreibt dies hervorragend:

„Anstatt sich zur Fertigstellung spezifischer Arbeitspakete zu verpflichten, werden in einem progressiven Angebot konkrete und messbare Geschäftsziele erörtert. Wenn das Projekt den Umsatz steigern oder Betriebskosten einsparen soll, sollten die Projektergebnisse messbare Auswirkungen auf diese Ziele haben.“

„Es geht nicht um die Features – diese sind nur Mittel zum Zweck. Stattdessen sollten die Geschäftsziele klar definiert werden. Anschließend sollten die Kosten und der Zeitplan für die Erfüllung dieser Ziele bestimmt werden. Wenn wir während des Projekts auf unvorhergesehene Schwierigkeiten und Risiken stoßen, können wir die Features außer Kraft setzen, die nicht direkt zu den Geschäftszielen beitragen.“

„Der Projekterfolg ist viel wahrscheinlicher, wenn wir berechtigt sind, den Projektumfang zu variieren, um unsere Geschäftsziele innerhalb eines festen Preises und eines festen Zeitplans zu erreichen.“

Definition von „Abschluss“

Die häufigste Fehlerquelle bei Festpreis-Projekten ist das Auftreten von neuen Anforderungen, die in der Angebotsphase nicht bedacht wurden – das passiert nicht nur manchmal, sondern eigentlich immer. Hier kommt es darauf an, wie wichtig diese unerwarteten Anforderungen für das Projekt sind. Unerwartete Anforderungen entstehen zum großen Teil nicht durch neue Ansprüche an die Funktionalität, sondern hängen oft mit anderen Faktoren wie der Einhaltung gesetzlicher Vorschriften, Qualitätsanforderungen und Dokumentation zusammen.

Ein agiles Festpreis-Angebot muss diese Erwartungen und eine Definition von „Abschluss“ klar festlegen und dokumentieren. Diese Definition muss festlegen, wann jedes einzelne Funktionselement die Anforderungen erfüllt.

Fehlt die Definition, besteht ein erhebliches Risiko, dass sich die Schätzungen eines Angebots auf die offensichtlichen Arbeitspakete konzentrieren und weniger sichtbare Anforderungen vernachlässigen, die sich möglicherweise im erheblichen Maße negativ auf die Gesamtkosten auswirken könnten.

Durchführung von agilen Festpreis-Projekten – Best Practices zur Risikominimierung

Sobald ein agiles Festpreis-Angebot und ein Vertrag abgeschlossen wurden, übernimmt der Projektmanager / Delivery Manager (oder Product Owner, etc.)  die Verantwortung und kümmert sich um die Ausführung des Projekts. Im besten Fall wurde die für die Ausführung verantwortliche Person in die Angebotsphase miteinbezogen. Aber selbst wenn dies nicht der Fall ist, liegt es in der Verantwortung der Person, die Arbeitspakete innerhalb des festgelegten Budgets und Zeitplans umzusetzen.

Re-Adjustierung der Grundrichtung

Die erste Aufgabe des Managers sollte darin bestehen, die Kosten und den Zeitplan für das nun besetzte Projekt neu festzulegen. Wenn das Angebot gut gemacht wurde und der Projektmanager involviert war, sollte dieser Prozess unkompliziert sein und nur geringfügige Anpassungen beinhalten.

Wenn jedoch Entscheidungen getroffen werden müssen, weil die neue Grundrichtung Abweichungen vom Angebot vorsieht, ist dies der richtige Zeitpunkt, um Kompromisse auszuhandeln. Eine Flexibilitätsmatrix kann hierzu ein sehr nützliches Werkzeug sein. Es konzentriert sich auf die gewünschten Ziele anhand von Kompromissen, die bei den vordefinierten Kriterien eingegangen werden müssen.

Quelle: PMI

Die „Dynamic Scope Option“

Die Dynamic Scope Option konzentriert sich auf Spezifikationen, um geschäftliche / organisatorische Ergebnisse anstelle von spezifischen und unantastbaren Features zu erzielen. Hierbei lässt sich die agile Methodik erfolgreich mit festen Preisen und Zeitplänen verbinden. Der Auftraggeber ist somit gegen Kosten- und Zeitplanschwankungen geschützt, ohne das zu liefernde Produkt in puncto Innovation und Mehrwert einschränken zu müssen.

Die Dynamic Scope Option ermöglicht es einem Software-Entwicklungsprojekt, sowohl agile als auch Festpreis-Anforderungen einzuhalten. Somit können den Sprints neue Features beigefügt werden (auf eigene Initiative des Sponsors oder auf Empfehlung des Projektteams), indem andere Features gleichen oder größeren Umfangs entfernt werden. Dies bietet dem Sponsor des Projekts die gewünschte Flexibilität, ohne das Budget und die Zeit zu beeinträchtigen.

Controlled Agile für die Software-Entwicklung

Einige der größten Projekte, an denen wir bei K & C arbeiten, weisen kleine Abweichungen vom agilen Festpreis-Modell auf – dieser Ansatz nennt sich Controlled Agile. Nach unseren Erfahrungen beseitigen Controlled-Agile-Angebote und -Projekte einen Teil der Probleme, die agilen Festpreisen innewohnen.

Was ist der Unterschied zwischen Controlled Agile und agilem Festpreis? Theoretisch ist der Unterschied sehr subtil. Die praktischen Auswirkungen reichen jedoch von kaum wahrnehmbar bis zu überaus beträchtlich. In einem Controlled-Agile-Projekt wird die Dynamic Scope Option dahingehend erweitert, dass der Sponsor, wenn er am Ende eines Sprints eine Funktion hinzufügen möchte, dies tun kann, selbst ohne eine verbindliche Verpflichtung, ein anderes Feature mit ähnlichem Umfang zu entfernen.

Anstatt ein anderes Feature zu entfernen, kann der Projektsponsor auch das Budget, die Frist oder beides anpassen, um das gewünschte Feature als Ergänzung zum vorher besprochenen Umfang mit aufzunehmen. Das bedeutet, dass das Projektteam mit einem agilen Festpreis arbeitet, es sei denn, der Projektsponsor beschließt, das Budget oder die Frist zu ändern, um den Umfang zu erweitern.

Dieser Ansatz ermöglicht den Projektsponsoren, den gewünschten Schutz in Bezug auf Kosten und Zeitplan zu haben und gleichzeitig die Möglichkeit, den agilen Festpreis ein wenig „agiler“ in puncto Preis und Zeitplan zu gestalten – Controlled Agile sei Dank.

Stellen Sie sicher, dass Ihr agiler Festpreis nicht zum Oxymoron wird

Der Konflikt zwischen festen Budget und Zeitplan sowie einem agilen Ansatz bei der Software-Entwicklung stellt Unternehmen vor große Herausforderungen. Änderungen im Umfang, Zeitplan und Kosten sollten vermieden werden, aber Änderungen des Risikos, Komplexität, Anforderungen und Ressourcen können oftmals nicht umgangen werden.

Diese Kombination von konkurrierenden Prioritäten kann mit einem Best-Practise-Ansatz zur optimalen Definition von Angeboten sowie zur Ausführung von Projekten bewältigt werden. Achten Sie auf folgende Punkte, um sicherzustellen, dass es sich bei Ihrem agilen Festpreis um kein Oxymoron handelt:

• Stellen Sie sicher, dass sowohl der Sponsor als auch der Projektleiter die Unterscheidung zwischen einem Angebot und einem Projekt verstehen und ergreifen Sie die erforderlichen Maßnahmen, um die verbundenen Risiken bestmöglich zu verringern.
• Die Angebote sollten für jedes Arbeitspaket eine eindeutige „Definition von Abschluss“ enthalten.
• Eine enge Zusammenarbeit zwischen Projektsponsor und Ausführer (intern oder extern) zur Entwicklung von geschäftlichen Erfolgskriterien und Arbeitspaketen für die Features.
• Erwägen Sie Vertragsänderungen, um Anpassungen des Umfangs mit den ursprünglichen Budget- und Zeitbeschränkungen zu ermöglichen.
• Überlegen Sie, ob Controlled Agile möglicherweise besser funktioniert als eine pure agile Festpreis-Vereinbarung.