Fachbeitrag
Agilität und Vergabe

 

Während klassisches Projektmanagement den Anspruch hat, den Projektverlauf detailliert vorab zu planen, basieren agile Methoden auf einem iterativen, inkrementellen Ansatz, um schnell auf Änderungen reagieren zu können.

Das Risiko, ein Endprodukt zu erhalten, das nach langer Entwicklungszeit nicht (mehr) den Anforderungen entspricht, wird bei einer auf agilen Ansätzen basierenden Entwicklung minimiert. Denn ausgehend von einer groben Beschreibung der Produktvision erfolgt zunächst die Entwicklung eines ersten Inkrements (z.B. ein Prototyp). Dieser Prototyp wird im weiteren Projektverlauf in sogenannten Sprints weiter spezifiziert und angepasst. Bei einem Sprint handelt es sich um kurze Entwicklungsphasen mit einer Dauer von 1-4 Wochen, in denen jeweils ein potentiell fertiges Produkt erstellt wird. Nach jedem Sprint kann dann das Feedback der Auftraggeber direkt eingeholt und berücksichtigt werden. So wird das Endprodukt schrittweise erstellt, bis das gewünschte Ergebnis erreicht worden ist.

Mit einem agilen Vorgehen können sich für öffentliche Auftraggeber neue Chancen ergeben. Nicht selten gleicht die Erstellung eines Produktes im Rahmen des klassischen Projektmanagements einer Blackbox für den Auftraggeber. Entwicklungsstände bzw. testbare Inkremente vom Auftragnehmer werden grundsätzlich nicht geliefert. Erst im Zeitpunkt der Bereitstellung zur Abnahme sieht der Auftraggeber das fertiggestellte Produkt. Fehlentwicklungen und Missverständnisse fallen somit erst zum Ende des Projekts auf. Ein Entgegenwirken ist dann nicht mehr möglich bzw. sehr aufwendig. Ebenso können Anpassungen der Leistungen, bspw. auf Grund von Gesetzesänderungen, nach der Konzeptionsphase nur noch schwer erfolgen oder erfordern schlimmstenfalls sogar eine komplette Neuplanung. Durch die Wahl eines agilen Ansatzes kann hingegen eine böse Überraschung zum Projektende hin vermieden werden. Der iterative und inkrementelle Ablauf sorgt für eine frühzeitige Einbeziehung des Auftraggebers, eine Einflussnahme in die laufende Planung und Entwicklung und die Berücksichtigung von Feedback in der Projektumsetzung. Gelieferte Zwischenstände können vom Auftraggeber bereits angesehen, besprochen und getestet werden.

Nachfolgend wird aufgezeigt, wie Agilität und öffentliche Verwaltung zusammenpassen und welche Möglichkeiten und Herausforderungen sich hieraus ergeben können.

Agilität und öffentliche Verwaltung

Die Vorteile einer agilen Entwicklung sind die bessere Nutzerakzeptanz durch häufige Feedbackschleifen, schnellere Ergebnisse durch kürzere Entwicklungszyklen und weniger prozessualem Overhead durch selbstorganisierende Teams. Um diese Vorteile zu erreichen, sind neben der Wahl des geeigneten Vorgehensmodells weitere wichtige Punkte zu beachten.

Agilität ist nicht immer besser

Ein einfaches Projekt mit bekannten Anforderungen und bekannter Technologie wird sich wahrscheinlich mit einer klassischen Projektmanagementmethode (z.B. V-Modell XT) gut umsetzen lassen. Bei komplexen Projekten mit unsicheren Anforderungen ist dagegen eine agile Methode besser geeignet. Je nach Projekttyp und Informationslage muss daher abgewogen werden, ob sich ein klassisches oder agiles Vorgehen besser eignet.

Eine agile Methode ist nicht automatisch Scrum

Eine Lehrbuchlösung nach Scrum Guide wird in der Realität kaum umsetzbar sein. Selbst in Organisationen, die seit langem Scrum einsetzen und die agilen Werte und Prinzipien leben, ist ein 100%-Ansatz wahrscheinlich nicht realistisch. In einer hierarchisch aufgebauten öffentlichen Verwaltung, die mit Agilität wenig Berührungspunkte hat, muss der Scrum-Ansatz umso eher angepasst werden. Und wenn Scrum verändert wird, ist es nicht mehr Scrum. Auftraggeber sollten daher die notwendigen Parameter des Vorgehensmodells anpassen und diejenigen Vorteile nutzen, die strukturell tatsächlich Nutzen bringen. Das Vorgehensmodell muss mit viel Pragmatismus und Realismus designt werden, damit ein erfolgreiches Produkt entwickelt werden kann. Auch wenn es State of the Art ist, agil zu werden, sollte sich der Auftraggeber bewusst sein, dass eine agile Umsetzung nur dann möglich ist, wenn die internen Strukturen und Prozesse dies zulassen.

Agilität erfordert Umdenken

Bevor ein Projekt zum Selbstzweck agil umgesetzt wird, sollte eine Organisation ehrlich mit sich sein und fragen, ob sie bereit für ein grundlegendes Umdenken ist. In der Praxis ist es notwendig, dass zumindest der Bereich, in dem das Projekt angesiedelt ist, grundsätzlich an einer agilen Transformation interessiert ist.

Fragen, die sich Auftraggeber stellen sollten

Sind Sie als Auftraggeber bereit, regelmäßig an Events teilzunehmen und so das notwendige Feedback zur Verfügung zu stellen? Sind Ressourcen auf Seiten des Auftraggebers für eine enge Zusammenarbeit vorhanden? Ist es strukturell und prozessual in der Organisation möglich, Kontrolle und Verantwortung abzugeben sowie Vertrauen in selbstorganisierte Teams aufzubauen?

Beschreibung der Leistung

Im klassischen Projektmanagement wird das Projekt zum Projektstart vollumfänglich geplant und bspw. Zeitpläne, Rollen und Verantwortlichkeiten oder Ergebnisse definiert bzw. festgelegt. Mithin ist das klassische Projektmanagement besser mit dem Vergaberecht vereinbar, welches vorschreibt, dass Leistung vorab eindeutig und erschöpfend beschrieben werden muss, um vergleichbare Angebote zu erhalten und somit die allgemeinen Grundsätze des Vergaberechts nach Transparenz, Gleichbehandlung und Wettbewerb zu erfüllen.

Was bedeutet dies aber nun für den Vergabeprozess in Kombination mit Agilität? Auch wenn keine abschließenden Lastenhefte erstellt werden müssen, so muss die Leistung sehr wohl so genau wie möglich beschrieben werden. Hierfür eignet sich in vielen Fällen im Gegensatz zu einer konstruktiven eine sogenannte funktionale Leistungsbeschreibung[1], in der das Resultat der Leistung, Zweck und Rahmenbedingungen ausgeführt werden. Zu den Rahmenbedingungen zählt ebenfalls die verbindliche Festlegung des agilen Vorgehensmodells. Auf diese Weise ist eine Ausschreibung agiler Vorhaben vergaberechtskonform möglich.

Gestaltung von Verträgen

Herausforderung bei einem agilen Projekt ist die vertragliche Gestaltung. Die EVB-IT-Musterverträge enthalten hierzu keine Regelungen und sind daher vom Auftraggeber entsprechend anzupassen.

Da bei unsicheren Anforderungen der Projekterfolg nicht vorab abschließend definiert werden kann, bietet sich grundsätzlich eine Leistungserbringung in Form einer Dienstleistung an. Das heißt, wenn EVB-IT-Verträge genutzt werden sollen, spiegelt der EVB-IT Dienstvertrag am ehesten die Theorie der agilen Methodik wider. Bei einer Vergütung nach Aufwand mit einer festen Obergrenze wird dann im Zweifel der Umfang der Funktionalität angepasst werden müssen. Ein Dienstvertrag und eine Abrechnung nach Aufwand sind die Varianten mit dem geringsten administrativen Aufwand auf beiden Seiten, benötigen aber das Vertrauen des Auftraggebers, dass der Auftragnehmer effizient arbeitet und dass nur tatsächlich anfallender Aufwand abgerechnet wird. Zu beachten ist, dass es bei einem Dienstvertrag keine Gewährleistungsrechte gibt und auch bei mangelhafter Leistung ein Vergütungsanspruch besteht. Eine enge Zusammenarbeit zwischen Auftraggeber und Auftragnehmer voraussetzend, kann das finanzielle Risiko trotzdem als gering eingestuft werden, da mangelhafte Leistung durch die kurzen Iterationen schnell auffallen würde.

Ein höheres Sicherheitsbedürfnis von Auftraggebern kann über werkvertragliche Vereinbarungen berücksichtigt werden. Eine mögliche Variante wäre es hier, einen Rahmenvertrag zum Abruf einzelner Werkverträge zu nutzen, wobei die Sprints als einzelne Werkverträge gestaltet werden und das Sprint Backlog als Beschreibung des Gewerks genutzt wird. Eine Abnahme muss dann aber separat und zusätzlich zu den agilen Events durchgeführt werden. Hierdurch wird dann der Erfolg (mangelfreies Gewerk) geschuldet und die Gewährleistung liegt beim Auftragnehmer. Der administrative Zusatzaufwand ist auf beiden Seiten als sehr hoch einzuschätzen, was sich letztlich dann auch im Preis widerspiegeln wird.

Preisgestaltung

In der Scrum-Welt wird nicht in absolutem Aufwand gerechnet, sondern relativ. Die Teams schätzen hierbei selbst ihren Aufwand relativ zu einer Referenz-User Story in einer Einheit, die Story Points genannt wird. Dadurch wird die relative Größe einer User Story immer mit demselben Punktwert beschrieben, egal, ob diese mit zunehmender Erfahrung des Teams schneller abgearbeitet werden kann oder nicht.

Für die Preisgestaltung und Abrechnungsmodalitäten existiert daher zusätzlich zur Abrechnung in Personentagen ebenfalls die Möglichkeit, Story Points zu nutzen. Ein Vorteil hiervon wäre zum Beispiel, dass effizientere Teams bessere Tagessätze erhalten. Dies stärkt natürlich auf der einen Seite die Motivation der Auftragnehmer darin, effizienter zu werden. Auf der anderen Seite kann dieser Aspekt dann andersherum wieder bei den Auftraggebern das Vertrauen in das agile Team stärken.

Es muss dabei aber berücksichtigt werden, dass die interne Abrechnung und das Controlling vieler Firmen auf Basis von Personentagen erfolgt und Story Points nach wie vor eher für die interne Teamorganisation genutzt werden als für abrechnungsrelevante Prozesse. Eine Abrechnung in Story Points würde daher einen zusätzlichen Overhead für die Umrechnung und ungewöhnliche Kalkulation und Rechnungsstellung erfordern. Und auch als Auftraggeber sollte man sich die Frage stellen, ob das hausinterne Controlling eine Abrechnung nach Story Points nachvollziehen könnte und freigeben würde.

Neben der Frage der Abrechnungseinheit stellt sich immer auch die Frage nach dem Abrechnungsmodell. Für Dienstverträge bietet sich eine Abrechnung nach Aufwand an, während Festpreise für Werkverträge gewählt werden sollten. Im Vertrag kann zusätzlich die Verteilung von Risiken vereinbart werden, die festlegen, in welchem Umfang entstandene Kosten bei einer Überschreitung des Maximalpreisrahmens an den Kunden verrechnet werden.

Zudem ist das Konzept des sogenannten agilen Festpreises zu erwähnen. Hierbei wird in einer Checkpoint-Phase geprüft, inwiefern die vorab getroffenen Annahmen bezüglich Aufwand und Preis korrekt waren und erst dann wird der zunächst indikative Festpreisrahmen vertraglich bindend festgelegt.

Fazit

Die Ausschreibung agiler Vorhaben ist für öffentliche Auftraggeber grundsätzlich vergaberechtskonform möglich und bietet neue Chancen durch eine frühzeitige Einbeziehung und Einflussnahme in die laufende Planung und Entwicklung sowie die Berücksichtigung von Feedback in der Projektumsetzung.

Zunächst sollte der öffentliche Auftraggeber aber klären, inwieweit er ein Projekt agil gestalten kann und möchte. Hiernach sind dann die Parameter eines agilen Vorgehensmodells anzupassen, um diejenigen Vorteile zu erhalten, die auch tatsächlich Nutzen bringen. Sind bspw. die Anforderungen bereits umfassend und abschließend in einem Lastenheft festgelegt, so kann dennoch ein agiler Ansatz für die Lieferung von Zwischenständen und Feedbackschleifen vereinbart werden. Existiert hingegen kein Lastenheft oder soll dieses dynamisch im Projektverlauf angepasst werden, so muss insgesamt ein agilerer Ansatz für das gesamte Projekt gewählt werden. Dies entbindet den öffentlichen Auftraggeber aber nicht von seiner vergaberechtlichen Plicht, die Leistung so genau wie möglich zu beschreiben. In vielen Fällen eignet sich dafür eine funktionale Leistungsbeschreibung, in der das Resultat der Leistung, Zweck und Rahmenbedingungen ausgeführt werden. Herausforderung bei einem agilen Projekt ist auch die vertragliche Gestaltung. Die EVB-IT-Musterverträge enthalten hierzu keine Regelungen und sind daher vom Auftraggeber entsprechend anzupassen. Auch über die Preisgestaltung und Risikoverteilung muss sich der Auftraggeber vorab Gedanken machen und ggf. mit den Bietern im Wege eines Verhandlungsverfahrens konkretisieren.

[1] Gegenüberstellung konstruktiver und funktionaler Leistungsbeschreibungen siehe UfAB 2018.

 

Ansprechpartner:

Martin Lehrmann, Geschäftsbereichsleiter

Martin.Lehrmann@aios.de