Agile Controlling zwischen Auftraggeber:innen und Auftragnehmer:innen Controlling zwischen agilen und nicht-agilen Organisationen aufbauen

Zwei Menschen reichen sich die Hand vor Kletterwand

Als agile Organisation mit nicht-agilen Organisationen zusammenarbeiten – nicht immer einfach, gerade wenn es ums Controlling geht. Dr. Stefan Barth gibt nach sechs Jahren ein Update, wie jetzt in seiner Firma Agile Controlling umgesetzt wird.

Management Summary

Agile Controlling zwischen Auftraggeber:innen und Auftragnehmer:innen Controlling zwischen agilen und nicht-agilen Organisationen aufbauen

Zwei Menschen reichen sich die Hand vor Kletterwand

Als agile Organisation mit nicht-agilen Organisationen zusammenarbeiten – nicht immer einfach, gerade wenn es ums Controlling geht. Dr. Stefan Barth gibt nach sechs Jahren ein Update, wie jetzt in seiner Firma Agile Controlling umgesetzt wird.

Management Summary

Vor sechs Jahren schrieb ich für das projektmagazin einen Artikel mit dem Titel "Agile Controlling - aussagekräftiges Berichtswesen für agile Organisationen" (Ausgabe 05/2015) aus der Sicht der tarent solutions GmbH, einem Dienstleister für Design und Entwicklung sicherer und skalierbarer Cloud-Plattformen für Medien, Logistik, Retail und Telekommunikation mit rund 300 Mitarbeitern. Der Anlass war damals der Folgende: Ausgehend von den drei Bewertungsparametern für erfolgreiche Software-Entwicklungsprojekte

  • Budgeteinhaltung,
  • Realisierung innerhalb der geforderten Zeitspanne
  • und tatsächlicher Umsetzung der gewünschten Anforderungen

kam die amerikanische Forschungs- und Beratungsfirma Standish Group in ihrem Chaos Report 2015 zu dem Ergebnis, dass Software-Entwicklungsprojekte mehrheitlich an einem dieser drei Parameter scheitern.

Software-Entwicklungsorganisationen reagierten auf diesen Missstand zunehmend mit dem Einsatz agiler Entwicklungsmethoden – was heute als Standard betrachtet werden kann – während die Auftraggeberseite verstärkte Controlling-Bedürfnisse entwickelte, die klassischen Prinzipien folgten. Diesen kulturellen und methodischen Bruch versuchte ich damals mit einem "schützenden Kokon" um die agile Entwicklungsorganisation zu entschärfen: Es wurde eine Übersetzungsschicht zwischen agilem Vorgehen und klassischer Projektsicht geschaffen (Bild 1).

Bild 1: Die 2015 vorgeschlagene Organisationsstruktur. Der Demand-Bereich (Auftraggeber) adressiert die Anforderungen gegenüber Supply (Dienstleister), dieser weist in Operations selbst einen agil arbeitenden Kern auf, der sich nach außen mit klassischen Reporting-Mechanismen abschottet. 
Bild 1: Die 2015 vorgeschlagene Organisationsstruktur. Der Demand-Bereich (Auftraggeber) adressiert die Anforderungen gegenüber Supply (Dienstleister), dieser weist in Operations selbst einen agil arbeitenden Kern auf, der sich nach außen mit klassischen Reporting-Mechanismen abschottet. 

Das Grundproblem besteht nach wie vor

Der Chaos Report 2020 der Standish Group zeigt, dass sich die Situation hinsichtlich des Erfolgs von Software-Entwicklungsprojekten in den letzten sechs Jahren wenig verändert hat. Dementsprechend bleiben uns auch bis heute die Unsicherheiten der Auftraggeber-Seite erhalten, die zu einem erhöhten Controlling-Bedürfnis führen.

Was die Statistik jedoch verbirgt: Aus unserer Sicht als Dienstleister treffen wir auf neue Herausforderungen in den Projektumsetzungen. Während in der Vergangenheit der kulturelle Bruch zwischen einer klassischen Projektsicht und dem agilen Entwicklungsvorgehen an der Schnittstelle zwischen Dienstleister:in und Anforderer:in verlief, hat sich der kulturelle Bruch mittlerweile tief in die Organisation des Auftraggebenden verschoben. Ursächlich hierfür ist ein stetig zunehmendes Verständnis agiler Arbeitsweisen, das über die Kernorganisation der IT (des Auftraggebenden) hinaus abstrahlt. Dies macht es tatsächlich sogar noch schwieriger als in der Vergangenheit, eine konsistente Strategie für den Umgang mit dem kulturellen Bruch zu finden, da der Verlauf der "Frontlinie" unklar ist.

Bild 2: Der kulturelle Bruch zwischen einer agil und einer klassisch arbeitenden Organisation. Insbesondere im Themenkomplex "Planung & Verbindlichkeit" finden sich die Herausforderungen, die in einem kulturell inhomogenen Umfeld zu lösen sind. 
Bild 2: Der kulturelle Bruch zwischen einer agil und einer klassisch arbeitenden Organisation. Insbesondere im Themenkomplex "Planung & Verbindlichkeit" finden sich die Herausforderungen, die in einem kulturell inhomogenen Umfeld zu lösen sind. 

Uns ist darüber hinaus deutlich geworden, dass ein "Kokon", der die agile Entwicklungsorganisation vor einem klassischen Umfeld schützt, maßgeblich kommunikativ zum Projekterfolg beiträgt, jedoch kaum inhaltlich. Der Denkfehler im System ist der gebrochene Anforderungsprozess: Wenn der:die Product Owner:in auf der Dienstleister-Seite agil arbeitet und die gleichnamige Rolle auf der Auftraggeber-Seite konsequent klassischen Prinzipien folgt, geht das verloren, was man gemeinhin als den maßgeblichen Vorteil agilen Anforderungsmanagements betrachtet: iterativ und visionsorientiert zu arbeiten, statt zu versuchen, bereits am Anfang des IT-Projekts das exakte Ergebnis zu kennen.

Handelt die "Demand-Seite" jedoch agil (was ja wünschenswert ist), wird der kulturelle Bruch von der Schnittstelle zwischen Demand und Supply in die Demand-Organisation verlagert – mit der Folge, dass die Sphärentrennung zwischen Demand und Supply unsinnig wird. Das Modell von 2015 zur Bewältigung der Herausforderungen im Controlling verliert damit seine Grundlage.

Kundenszenarien und unser Umgang damit

Die Antwort darauf, wie sich unter diesen Voraussetzungen agiles Projektcontrolling umsetzen lässt, ist so nicht mehr durch eine einfache, modellartige Blaupause zu beantworten: Das Umfeld, in dem Controlling etabliert werden muss, ist komplex. Erfolgreich sind nur individuelle Lösungsansätze.

Der:die (weitestgehend) agile Auftraggeber:in

Dieses Szenario ist für uns im Hinblick auf die Ausgangsherausforderung am einfachsten: der Auftraggebende ist vertraut mit agiler Softwareentwicklung.

Das Szenario zeichnet sich durch folgende Eigenschaften aus:

  • Gegenseitiges Vertrauen, dass die Erreichung des gemeinsamen Projektziels wichtiger ist als die wirtschaftliche Selbstoptimierung der eigenen Partei (siehe Infokasten: Gefahr Selbstoptimierung)
  • Vollständige Transparenz über den Budgetverbrauch (über Zeitbuchung) und den fachlichen Fortschritt (durch das Backlog/die Sprintplanungen)
  • Gemeinsames Verständnis vom Budgetrahmen, innerhalb welchem gewisse Feature-Entwicklungen vonstattengehen sollten mit einem ebenso geteilten Verständnis, dass man Scope Creeping (ausufernde Anforderungen) verhindern möchte, um den Rahmen einzuhalten

Unsere Teams betten sich in das bestehende Controlling-System ein und leisten den geforderten Beitrag. Dieser kann darin bestehen, Burn Down Charts beizubringen oder aktiv an der Programminkrement-Planung mitzuwirken in skalierenden, agilen Organisationen. Hier bewegen sich unsere Mitarbeitenden inklusive der projektorganisierenden Rollen (Scrum Master und Product Owner) in einem Ökosystem, was unserem internen nicht unähnlich ist (siehe Abschnitt "Organisation"). Die Abrechnung erfolgt über Zeit und Aufwand.

Gefahr Selbstoptimierung – Misstrauen in einer Dienstleisterbeziehung

Die Grundlage agilen Arbeitens ist die Bereitschaft, sich gegenseitig zu vertrauen – insbeson-dere im Auftraggeber-Dienstleisterverhältnis. Nicht umsonst lautet das dritte Prinzip des agi-len Manifests "Customer collaboration over contract negotiation". Ist das Vertrauen gestört, beginnen beide Seiten sich vor möglicher Unredlichkeit zu schützen, indem sie ihre eigene, wirtschaftliche Position im Projekt optimieren. Der:die Auftraggeber:in hinterfragt permanent Kostenprognosen für die Weiterentwicklung mit dem Gefühl, dass ihm Informationen vorent-halten werden. Der:die Dienstleister:in versucht, unbezahlte Aufwände durch Kleinlichkeit bei Change Requests zu begegnen. Dies ist ein Teufelskreis.

Wir begegnen einem solchen Umfeld in der Regel als mitwirkende oder gestaltende Dienstleister in großen Plattformentwicklungen. Die Grenzen des Projektcontrollings sind dort erreicht, wo die Führungskraft ein Gantt-Chart mit zeitlichen Meilensteinen bis zum Projektende sehen möchte und womöglich regelmäßig Fortschritts- und Risikoberichte erwartet.

In der beschriebenen Konstellation ist die Führungskraft oft weit von den Details der fachlichen Umsetzung entfernt. Ich begegne ihrer Anforderung nach konkreter Projektplanung dann mit einer Darstellung der größeren Feature-Bausteine für einen Zeithorizont von bis zu einem Jahr. Dies ist auch mit agilen Controlling-Methoden ohne weiteres möglich.

Die Herausforderung, die bleibt, ist der "5-Jahresplan", den sich das Top Management wünscht. Intern stellen wir bei Tarent Solutions uns nicht die Frage nach einem 5-Jahresplan. Gegenüber unseren Auftraggeber:innen begründen wir, warum wir hierzu keine seriöse Prognose geben können: Markt- und Kundenbedürfnisse sind bei diesem Zeithorizont zu wenig vorhersehbar, sodass das zu erstellende Endprodukt kaum klar zu umreißen wäre. Damit suggeriert eine langfristige Fertigstellungplanung eine Sicherheit, die nicht existiert. Da die Argumente tatsächlich augenscheinlich sind (und typischerweise dieselben, warum der:die Auftraggeber:in sich seinerseits agil aufgestellt hat), ist der Überzeugungsversuch häufig erfolgreich.

Kund:innen, die agil wollen, aber damit nicht vertraut sind

Download PDFDownload PDF

Jetzt Feedback geben und mitdiskutieren!

Wir würden uns über Ihre Bewertung und/oder einen Kommentar freuen ‒ nur so können wir Ihnen in Zukunft noch bessere Inhalte liefern.

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung.
0 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 2
Kommentare 0

Das könnte Sie auch interessieren

Vorschaubild

Mit agilen Metriken haben Sie verlässliche Wegweiser in Ihrem Projekt. In 7 Schritten erarbeiten Sie ein passgenaues Set von Kennzahlen und verbessern so kontinuierlich die Leistungsfähigkeit Ihres Teams.

Vorschaubild

Agiles Vorgehen und klassisches Projektcontrolling lassen sich nicht so ohne weiteres unter einen Hut bringen. So besteht z.B.