Immer wieder hört man als Argument gegen den Einsatz von agilen Methoden in einem regulierten Umfeld (insbesondere wenn die Vergaberichtlinien für öffentliche Institutionen gelten), dass es mit diesen Regularien unvereinbar wäre, es müsse ein Fixpreis vereinbart werden. Die Praxis zeigt zwar, dass jeder Fixpreis alles andere als fix ist (das Zauberwort heißt „Change Requests“), aber es ist schon richtig, dass es schwierig ist, im voraus eine rechtskonforme Vereinbarung zu treffen.
Aus einen praktischen Anlass habe ich versucht, das Modell des „Guaranteed Maximum Price“ (GMP) und agile Vorgangsweisen so zu vereinen, dass man dies auch im Falle eines öffentlichen Auftraggebers praktizieren könnte. Der finale Praxistest steht noch aus, aber ich freue mich vorweg über Feedback dazu.
Hier das Modell, es werden die Abkürzungen AG für Auftraggeber und AN für Auftragnehmer verwendet:
- Anforderungen und Preise
In der zweiten und eventuell dritten Angebotsrunde erfolgt eine Deckelung des Volumens von Seiten des AN auf Grundlage der Aufklärungen und einem entsprechend angepassten Anforderungsprofil (Beseitigen der erkannten und verzichtbaren Preistreiber von Seiten des AG) auf Grundlage einer Vereinbarung zur Zusammenarbeit im Projekt.
Vereinbarung der Eckpunkte der Anforderungen in fachlicher Terminologie (Prozesse, fachliche Use-Cases, Maskeninhalte und Funktionen, Geschäftsregeln, Transaktionsfolgen) als Basisdokument für die Projektabwicklung.
- Projektabwicklung
Nominierung von fachlichen Ansprechpartnern auf Seiten des AG. Diese Personen können für bestimmte Phasen des Projektes in unterschiedlichem Ausmaß eingeplant werden. Rollierende Bedarfsplanung von Seiten des AN, so dass unnötige terminliche Bindungen vermieden werden können.
Besetzung der agilen Rollen (Produkt-Owner (AG), Scrum-Master (AN), Team-Mitglieder AN und Team-Mitglieder AG). Zuordnung von Primärzuständigkeiten zu Teammitgliedern (fachliche, technische und betriebswirtschaftliche Expertise). Nominierung eines Team-Koordinators sowohl von Seiten AG als auch AN , diese sind für die laufende Planung und Abwicklung des gemeinsamen Projektes verantwortlich.
Teilnahme des fachlichen Projektleiters auf Seiten des AG an einer Schulung zum Produkt-Owner.
Vorlage einer Sprintplanung (Termine, Grobbeschreibung der geplanten Ergebnisse, Kapazitätsanfor-derungen auf Seiten AG und AN) als Initialplanung von Seiten des AN.
Einigung auf ein Verfahren zur rollierenden Aufwandsplanung . Plausibilisierung der Aufwandschätzungen durch Quervergleich mit bereits realisierten oder bereits geplanten Features (z.B. Quality Points) nach Wahl des AN.
Tägliches „Standup-Meeting“ (Rückschau, Vorschau) moderiert vom Scrum-Master des AN.
Kurzfristige Verfügbarkeit von Auskunftspersonen auf Seiten des AG für Rückfragen und Entscheidungen wird von AG in allen Phasen innerhalb der Normalarbeitszeit zugesichert. Kontaktaufnahme per Telefon, Mail oder Meeting. Der Einsatz von Kommunikationsmedien wie Web-Meetings wird von beiden Seiten unterstützt.
Transparenz des Personaleinsatzes auf Seiten des AN während der Laufzeit (Arbeit vor Ort oder Leistungen im Büro des AN werden wöchentlich offen gelegt und bestätigt).
Transparenz des Fortschrittes durch Burn-Down-Charts, die nach Abschluss jedes Sprints zwischen AG und AN einvernehmlich aktualisiert werden.
Recht des AG, bei ungenügend qualifizierten Mitarbeiters auf Seiten des AN deren Austausch oder Kürzung der auf das Budget anzurechnenden Stunden zu verlangen.
Recht des AN, bei Nicht-Erbringung vereinbarter und notwendiger Mitwirkungsleistungen auf Seiten des AG eine angemessene Erhöhung seines Budgets zu verlangen.
Es gilt gegenseitig eine weit gefasste Hinweispflicht im Sinne eines Frühwarnsystems.
Hinweispflicht des AN bei Entscheidungen des AG, die ein Sprengen des Aufwands- und Zeitrahmens zur Folge haben können.
- Abnahmen und Change Requests
Tests erfolgen im Rahmen der Sprints. Grundsätzlich nehmen alle Teammitglieder an der Testvorbereitung, -durchführung und –auswertung aktiv teil (also sowohl Mitarbeiter des Fachbereiches als auch Entwickler). Es werden in höchstmöglichem Ausmaß Werkzeuge zur Testautomatisierung eingesetzt, vor allem, um den Aufwand für Regressionstests gering zu halten.
Teilabnahmen von Seiten des AG bei jedem Sprint. Vorbehalt Integrationstest und Performance, sichtbare Features werden verbindlich abgenommen (Dokumentation durch „Hinterlegung“ des Standes der Software auf einem Read-Only Speichermedium, ergänzend bei Bedarf Screenshots etc.). Nach einer solchen Abnahme gilt für Änderungen das Verfahren für Change Requests.
Change Requests sind von Seiten AG und AN jederzeit möglich. Sie sind hinsichtlich des Nutzens für die Erreichung des Projekterfolges (Qualität der Lösung, Aufwand, Termin) vom Antragsteller zu begründen, vom anderen Partner zu prüfen, allenfalls Vorschläge zur Modifikation einzubringen. Wenn diese Anforderungen hinreichend geklärt sind, erfolgt eine Kalkulation der daraus resultierenden Auswirkungen für Aufwand und Termin von Seiten des AN. Entscheidung des AG über Freigabe des Change Requests. Es wird vereinbart, Change Requests wohlwollend zu prüfen, allfällige Einwände und Hinweise des anderen Partners ernst zu nehmen und stets ein Einvernehmen zu suchen.
Höchste Eskalationsstufe bei Nicht-Einigung (Aufwände, CRs, Abnahmen, …) sind jeweils ein Geschäftsführer auf Seiten AG und AN. Solche Meetings werden von einem neutralen, externen Sachverständigen moderiert. Es gelten die Grundsätze einer Mediation.
Nachträglicher Hinweis: Etwas allgemeiner setze ich mich mit diesem Thema in einem Beitrag zur Vertragsphilosophie agiler Projekte auseinander.
Drei Bücher zu diesem Thema seien hier genannt:
Wenn Sie regelmäßig über neue Blogposts informiert werden wollen, tragen Sie sich bitte hier ein. Bitte öffnen Sie dann Ihr Postfach und klicken Sie auf den Bestätigungslink, andernfalls wird die Anmeldung nicht wirksam („Double-Opt-In“).
Ihre Adresse wird nicht weitergegeben. Sie können sich jederzeit mit einem Klick wieder abmelden.
Webmentions
… [Trackback]
[…] Info to that Topic: it-governance.blog/agile-softwareentwicklung-mit-preisdeckelung-fur-ein-software-entwicklungsprojekt/ […]
… [Trackback]
[…] Read More on that Topic: it-governance.blog/agile-softwareentwicklung-mit-preisdeckelung-fur-ein-software-entwicklungsprojekt/ […]
… [Trackback]
[…] Read More on on that Topic: it-governance.blog/agile-softwareentwicklung-mit-preisdeckelung-fur-ein-software-entwicklungsprojekt/ […]
… [Trackback]
[…] There you will find 46076 more Information to that Topic: it-governance.blog/agile-softwareentwicklung-mit-preisdeckelung-fur-ein-software-entwicklungsprojekt/ […]