Vorgehensmodell – Abwägung zwischen klassischem und agilem Vorgehen

Im Kontext der Dienstleister-Steuerung ist das Vorgehensmodell der Projektsteuerung auf Seiten des Bedarfsträgers, d.h. dem abrufenden Projekt oder der jeweiligen Organisation, eine relevante Einflussgröße. Hierbei sind folgende Ausprägungen zu betrachten:

Klassisch: Projekte mit klassischem Vorgehensmodell (z.B. Wasserfall, V-Modell XT, PRINCE2) mit dem Ziel hoher Planungssicherheit bei fest definierten Projektergebnissen bzw. Organisationen mit starker Hierarchie und Prozessorientierung.

Agil: Projekte mit agilem Vorgehensmodell (z.B. Scrum, Kanban, PRINCE2 Agile) mit dem Ziel hoher Veränderungsgeschwindigkeit, Flexibilität und schnellen Ergebnissen bzw. agile Organisationen.

Hybrid: Mischansätze von klassisch und agil in einem Projekt bzw. in einer Organisation.

Alle genannten drei Ausprägungen bringen unterschiedliche Auswirkungen und Herausforderungen für die Dienstleister-Steuerung auf Seiten des Bedarfsträgers mit sich. Wenn die Vorgehensmodelle auf Seiten des Bedarfsträgers und auf Seiten des Dienstleisters stark konträr ausgeprägt sind, sich also agil vs. klassisch gegenüberstehen, und somit eine Verzahnung unterschiedlicher Philosophien erforderlich wird, können sich bestehende Herausforderungen noch weiter verstärken. Wie lässt sich also damit umgehen und ein Gestaltungsrahmen mit Planungssicherheit für Auftraggeber und Auftragnehmer schaffen, der die zielgerichtete Steuerung bei gleichzeitiger Flexibilität zulässt?

Die Erbringung von Leistungen durch Dienstleister und oftmals schon die Definition von Steuerungsinstrumenten (Controlling, Eskalationsebenen etc.) erfolgt auf Basis eines zu schaffenden Vertragsverhältnisses. Prinzipiell gilt, dass es nicht den jeweils einen richtigen Vertrag für ein agiles oder für ein klassisches Umfeld gibt. Der Vertragstyp ist vielmehr abhängig von den Zielen der Vertragspartner, den Rahmenbedingungen und der gewünschten Risikoverteilung. Fristen für Vergabeverfahren und hoher Zeitdruck für die Umsetzung führen häufig dazu, Ausschreibungen zu einem Zeitpunkt durchzuführen, an dem Entscheidungsträger und Verwaltung selbst noch keine detaillierte Vorstellung vom angestrebten Leistungsumfang haben.

Im klassischen Vorgehen wird mit einem Lastenheft und einer entsprechenden zeitlichen und monetären Planung eine Vertragsgrundlage geschaffen. Die Herausforderungen selbst ergeben sich jedoch in einem agilen Umfeld: Wie können der Vertragsgegenstand und die umzusetzenden Anforderungen gegenüber einem Dienstleister eindeutig und rechtssicher definiert werden, wenn man sich der Agilität verschrieben hat und die erwarteten Ergebnisse nicht abschließend definiert sind? Die Erstellung eines detaillierten und vollständigen Lastenheftes, wie im klassischen Vorgehen, ist natürlich das Gegenteil eines agilen Modells und reduziert von Beginn an jegliche Flexibilität. Insofern ist ein Werkvertrag auch im agilen Umfeld zwar nicht ausgeschlossen, hat aber einen hohen Regelungsaufwand. Eine Beauftragung von Dienstleistern ohne klare Definition erwarteter Ergebnisse, d.h. als reine Dienstleistung nach Aufwand erhöht zwar die Flexibilität, aber im Gegenzug auch das Risiko des Verfehlens jeglicher Erwartungen des Bedarfsträgers.

Ein Lösungsweg für ein agiles Umfeld sollte die Vereinbarung als Dienstleistungsvertrag mit einer zwar in der Breite vollständigen, in der Tiefe jedoch nicht detaillierten Beschreibung der Anforderungen an die zu erbringende Leistung sowie mit definierten Abrufkontingenten an Aufwand sein. Ganz dem Sprint-Gedanken folgend können zum Ende der Vereinbarung jeweils Nutzenbewertungen erfolgen und über den Abruf des nächsten Kontingentes entschieden werden. Zusätzlich ließe sich ein minimal erwartetes Ergebnis klassisch definieren, ohne damit den Grundsatz der Agilität zu behindern. Nachteil der genannten Tranchen ist jedoch eine fehlende Planungssicherheit für den Dienstleister, da nach jeder Tranche „Schluss“ sein kann.

In Anbetracht der Restriktionen der öffentlichen Verwaltung im Hinblick auf Entscheidungswege, Umgang mit Risiken und Haushaltsrecht sind ausschließlich agil durchgeführte Projekte durchaus selten. Ebenso sind einzubindende Dienstleister sehr unterschiedlich aufgestellt und selten alle durchgehend agil oder klassisch organisiert. Nichtsdestotrotz hat die Agilität Vorteile gegenüber klassischen Arbeitsmethoden: Die Prozesse werden kürzer, Risikofaktoren sind schneller sichtbar, und die Abstimmung zwischen Kunde und Dienstleister erhält eine größere Transparenz. Insbesondere Lieferanten von IT-Systemen setzen für ihre internen Entwicklungsprozesse zunehmend auf agile Methoden und binden bei Bedarf auch die Auftraggeber mit ein.

Der realistische Mittelweg in der Öffentlichen Verwaltung lautet „hybrides Projektmanagement“, also die Kombination zweier oder mehrerer Projektmanagement-Methodiken. Hybrides Projektmanagement kombiniert die klassische Rahmenplanung (Termine, Ressourcen, Meilensteine) mit agilen Vorgehensweisen, wie z.B. Scrum in der eigentlichen Projektarbeit. Dadurch kann auf der höheren Ebene passend zu den Verwaltungsstrukturen grob klassisch agiert werden – im operativen Geschäft ergänzen agile Arbeitsweisen das iterative Element.

Dies wirkt sich auch auf die Schnittstellen zwischen Dienstleister und Auftraggeber aus. Treffen klassische Steuerungsanforderungen (der Verwaltung) auf agile Vorgehensweisen beim Dienstleister, können mittels des zuvor genannten klassischen Überbaus gerade in der Schnittstelle zwischen Auftraggeber und Dienstleister z.B. Meilensteine oder Statusmeetings eingeplant und trotzdem in geeignetem Umfang Vorteile agiler Arbeitsmethoden genutzt werden. Wichtig im hybriden Ansatz sind hierbei klare Rollendefinitionen im Kontext klassischer Projektleitung vs. Rollen wie Product Owner und Scrum Master sowie gemeinsame Regeln der Zusammenarbeit und Kommunikation.

Die Planung für die Umsetzung der Anforderungen oder im agilen Fall die Planung einzelner Iterationen sollte gemeinschaftlich zwischen Auftraggeber und Dienstleister erfolgen. Im agilen Vorgehen wird es keinen vollständigen Projektstrukturplan bzw. -ablaufplan geben, in dem alle Arbeitspakete zeitlich definiert sind. Benötigt der Auftraggeber eine phasenorientierte Sicht (z.B. Analyse, Umsetzung, Test/ Abnahme), kann im hybriden Ansatz jede Phase für sich agil und mit Iterationen ungesetzt werden und dabei der Übergang zwischen den Phasen mit klaren Entscheidungspunkten bestehen bleiben.

Zur Ermittlung des Fortschritts in der Umsetzung bestehender Anforderungen im Sinne eines Controllings ist anhand aussagefähiger Kennzahlen (z.B. zu Aufwand, Kosten, Qualität, Fertigstellungsgrad) zu überwachen, dass die Leistung des Auftragnehmers in der vereinbarten Qualität und zum vereinbarten Preis/Termin erfolgt. Bei agilem Vorgehen kann das Controlling durch den Auftraggeber jedoch nicht anhand von Arbeitspaketen erfolgen wie bei einem klassischen Vorgehen, sondern muss aus der Erreichung der Ziele der Iterationen abgleitet werden. Nach Abschluss einer Iteration werden jeweils die Qualität und die Menge der umgesetzten Funktionalität bewertet. Der Projektfortschritt ergibt sich demnach anhand der umgesetzten Eigenschaften aus dem Product Backlog und kann entsprechend über dieses gesteuert werden.

Wann sind Liefergegenstände fertig? Im klassischen Vorgehen ist die Frage recht einfach zu beantworten. Hier lassen sich auf Basis der initial definierten Anforderungen (Lastenheft) klare Akzeptanzkriterien in Bezug auf Art, Umfang und Qualität der zu liefernden Ergebnisse definieren, die wiederum in entsprechende Test- und Abnahmemaßnahmen münden. Im agilen Vorgehen ist die Frage de facto für jedes Inkrement und unter Betrachtungen eventueller vorhergehender Inkremente zu stellen, Test und Abnahme werden daher stufenweise fortgeschrieben. Wesentlich scheint, dass nicht jedes im agilen Vorgehen bereitgestellte Inkrement auch zwingend mit einer Veröffentlichung einhergeht. Stattdessen müssen ein geeignetes Release-Vorgehen und eine damit verbundene zeitliche Planung in der Abwägung von Stabilität vs. Flexibilität sehr individuell definiert werden, was das „Überspringen“ einzelner Zulieferungen explizit zulässt.