Deutsch
Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.
Agiles Vorgehen in Ausschreibungs- oder Festpreisprojekten
Blog offline
Immer wieder erreichen mich Fragen zu der Möglichkeit agilen Vorgehens im Rahmen von Ausschreibungs- oder Festpreisprojekten.
Wir haben seit mehreren Jahren durchaus positive Erfahrungen damit, zum einen selbst als Auftragnehmer von Festpreisaufträgen als auch begleitend für die Auftraggeber. Eines unserer ersten Beispiele war die öffentliche Ausschreibung zur Entwicklung eines Hafenlogistiksystems für den Seehafen Kiel. oose hat dort (zum Festpreis, aber agil vorgehend) das Pflichtenheft für die Ausschreibung erstellt. Anschließend haben wir den Auftraggeber bei der Auswahl des Systementwicklers (T-Systems hatte die Ausschreibung dann gewonnen) bis hin zur Abnahme begleitet. Auch der Systementwickler T-Systems ist dann wieder agil vorgegangen. (Auf der OOP-Konferenz 2005 hatten wir in einem Vortrag gemeinsam mit dem Auftraggeber und T-Systems das Projektvorgehen seinerzeit vorgestellt).
Folgendes ist dabei zu beachten gewesen:
Wir haben seit mehreren Jahren durchaus positive Erfahrungen damit, zum einen selbst als Auftragnehmer von Festpreisaufträgen als auch begleitend für die Auftraggeber. Eines unserer ersten Beispiele war die öffentliche Ausschreibung zur Entwicklung eines Hafenlogistiksystems für den Seehafen Kiel. oose hat dort (zum Festpreis, aber agil vorgehend) das Pflichtenheft für die Ausschreibung erstellt. Anschließend haben wir den Auftraggeber bei der Auswahl des Systementwicklers (T-Systems hatte die Ausschreibung dann gewonnen) bis hin zur Abnahme begleitet. Auch der Systementwickler T-Systems ist dann wieder agil vorgegangen. (Auf der OOP-Konferenz 2005 hatten wir in einem Vortrag gemeinsam mit dem Auftraggeber und T-Systems das Projektvorgehen seinerzeit vorgestellt).
Folgendes ist dabei zu beachten gewesen:
- Das Pflichtenheft darf nicht zu detailliert sein, sonst landet man wieder beim Wasserfall. Es darf nur so konkret sein, um vergleichbare Angebote einzuholen und die vertragliche Sicherheit für beide Parteien zu erreichen. Das ist sicherlich eine Gratwanderung, aber auch keine Hexerei.
- Es muss ein agiler Festpreis vertraglich vereinbart werden. So nennen wir es, wenn sich der Vertrag auf den initialen Anforderungsumfang des Pflichtenheftes bezieht, beide Parteien aber dann vereinbaren, dass *noch nicht realisierte* Anforderungen jederzeit gegen andere getauscht werden, wobei der Wert der rein- und rausgehenden Anforderungen jeweils aufgerechnet wird. Quasi ein Konto, dessen Saldo zum Projektende ausgeglichen sein sollte.
Die Details haben wir in unserem Buch APM - Agiles Projektmanagement beschrieben.
Außerdem gibt es einen älteren Artikel von mir dazu: " Der agile Festpreis und andere Preis- und Vertragsmodelle", Objekt-Spektrum, 01/2006
Außerdem gibt es einen älteren Artikel von mir dazu: " Der agile Festpreis und andere Preis- und Vertragsmodelle", Objekt-Spektrum, 01/2006
Beim Seehafen Kiel war es übrigens so, dass der Auftragnehmer pünktlich liefern konnte und der Auftraggeber auf seinem Konto sogar noch ein paar Anforderungen gut hatte.
Generell denke ich sind agile Vorgehensweisen wie APM sehr viel besser für Festpreissituationen geeignet als ein Wasserfallvorgehen - weil letzterer den unvermeidbaren Erkenntnisgewinn und die daraus resultierenden Änderungswünsche ignoriert und als Störung begreift und somit kontraproduktiv beim Festpreis ist: entweder bekommt der Auftraggeber nicht die Funktionalität die er braucht, sondern nur die beauftragte, oder der Auftragnehmer realisiert die gewünschte Funktionalität, bekommt die aber nicht bezahlt. Der Kunde möchte ja in der Regel eines festen Preis, aus Haushalts- und Budgetgründen. Eine fixe Funktionalität ist in der Regel nicht sein unmittelbares Interesse, sondern nur mittelbar aufgrund des Unvermögens, sonst bestimmte vertragliche Sicherheiten zu gewährleisten. Wenn dies anderweitig hergestellt werden kann, wie beim agilen Festpreis, ist das Thema fixe/variable Funktionalität weitgehend gelöst.
Generell denke ich sind agile Vorgehensweisen wie APM sehr viel besser für Festpreissituationen geeignet als ein Wasserfallvorgehen - weil letzterer den unvermeidbaren Erkenntnisgewinn und die daraus resultierenden Änderungswünsche ignoriert und als Störung begreift und somit kontraproduktiv beim Festpreis ist: entweder bekommt der Auftraggeber nicht die Funktionalität die er braucht, sondern nur die beauftragte, oder der Auftragnehmer realisiert die gewünschte Funktionalität, bekommt die aber nicht bezahlt. Der Kunde möchte ja in der Regel eines festen Preis, aus Haushalts- und Budgetgründen. Eine fixe Funktionalität ist in der Regel nicht sein unmittelbares Interesse, sondern nur mittelbar aufgrund des Unvermögens, sonst bestimmte vertragliche Sicherheiten zu gewährleisten. Wenn dies anderweitig hergestellt werden kann, wie beim agilen Festpreis, ist das Thema fixe/variable Funktionalität weitgehend gelöst.
Bernd Oestereich
Weitere Links: APM, Vortrag XP-Days 2005
Weitere Links: APM, Vortrag XP-Days 2005