Ergebnisverantwortung in agilen Projekten – wer trägt diese?

Folgender Satz stand im Angebot eines renommierten IT-Unternehmens: „Dem agilen Vorgehen folgend tragen wir keine Ergebnisverantwortung“. Heißt das also: Agile Projekte übernehmen keine Verantwortung für das Ergebnis und damit für den Erfolg eines Projektes? Ich dachte, Scott Adams hätte es ironisch gemeint, als er agil mit „no more planning, no more documentation. Just start writing code and complaining“ beschrieb? Wurde wieder einmal die Satire von der Realität übertroffen?

Nun wäre es unseriös, einen einzigen Satz aus dem Zusammenhang zu lösen und darauf eine Polemik aufzubauen. Also blicken wir etwas tiefer, wie das gemeint sein kann und was davon einer ernsthaften Prüfung standhält.

Ursprung ist wohl die richtige Aussage, dass bei agilen Projekten der Leistungsumfang nicht im gleichen Detaillierungsgrad festgelegt wird wie bei klassischen Projektverträgen, die im Kern einen Werkvertrag beinhalten. Mein Kollege Philip Weihs und ich haben das in einem Vortrag für Juristen in einer Grafik so dargestellt.

Allerdings war das nicht als Abschied von jedweder Ergebnisverantwortung Erfolg gemeint, wir wollten nur klarstellen, dass es unterschiedliche Prioritäten bei der Fixierung von Parametern gibt, je nach Vorgehensmodell. Als Kriterium des Projekterfolges sehen wir alle drei Parameter des „magischen Dreiecks“, insofern beinhaltet Erfolgsverantwortung mehrere Dimensionen.

Richtig ist, dass agile Projekte von Beginn an eingestehen, dass nicht alles im Voraus bekannt und fixiert ist. Dazu habe ich in einem anderen Beitrag schon ausführlich Stellung genommen.

Was ist an der zitierten Aussage also richtig? Was ist in einem IT-Projekt zu entscheiden und zu gestalten, um erfolgreich zu sein? Hier die wichtigsten Faktoren, die Gegenstand einer Planung sind, an denen auch der Erfolg des Projektes gemessen wird.

Warum – „Business Case“

• Return on Investment

Was – „Scope“

• Welche Geschäftsprozesse sollen in welchem Ausmaß unterstützt werden?
• Welche Teile des Anwendungsportfolios sollen abgelöst werden?

Wann – „Roadmap“

• In wie vielen Etappen wird das Gesamtvorhaben umgesetzt?
• Gibt es Teilproduktivsetzungen oder eine Big-Bang-Umstellung?

Wie – „Funktionalität“

• User Interface Design
• Benutzerführung (Style Guide, Behavior Guide)
• Automatisierungsgrad von Teilprozessen (Workflow, Geschäftsregeln, Algorithmen …)

Womit – „Technologie“

• Standard-Software und/oder Individualentwicklung
• Java, .NET …
• Mobility, Apps …

Wenn ein IT-Unternehmen einem Kunden ein Angebot macht, so nimmt der Einfluss und damit die Ergebnisverantwortung vonseiten des Kunden von oben nach unten ab, der Einfluss des IT-Unternehmens umgekehrt zu. Erfolg ist daran zu messen, dass in allen Bereichen ein zufriedenstellendes Ergebnis erzielt wird. Dafür müssen die Planungsvorgaben und die Arbeitsergebnisse so sein, dass das Projektergebnis insgesamt den Zweck erfüllt, für den das Projekt gestartet wurde.

Die Standish Group misst den Erfolg von IT-Projekten an den Kriterien „OnTime“, „OnBudget“ und „Satifactory“. Und nun genau zu unserer Ausgangsfrage: „This means the project was resolved within a reasonable estimated time, stayed within budget, and delivered customer and user satisfaction regardless of the original scope“ (Chaos Report 2015,  Hervorhebung von mir).

Wir sehen also, dass die Variabilität des Scope in agilen Projekten genau dazu dient, den Erfolg sicherzustellen. Denn je größer und wichtiger das Projekt für ein Unternehmen ist, umso größer die Wahrscheinlichkeit, dass sich wesentliche Rahmenbedingungen während des Projektverlaufes ändern und daher eine Änderung des ursprünglichen Scope notwendig ist, um das eigentliche Projektziel zu erreichen. Natürlich ist damit nicht gemeint, dass eine Scopeänderung „passiert“, also die Folge einer Fehlentwicklung der Projektarbeit ist. Es geht hier um bewusste Reaktionen auf geänderte Voraussetzungen oder um neue Erkenntnisse, wie die Projektziele besser zu erreichen wären als durch das strikte Festhalten am ursprünglichen Scope. Daran zeigt sich auch, dass Werkverträge für große IT-Projekte nicht nur für den Auftragnehmer ungünstig sind, sondern auch für den Auftraggeber. In Wirklichkeit sogar besonders ungünstig für den Auftraggeber, denn die Fesseln, die man einem Projekt angelegt hat, binden auch den Kunden. Er bekommt zuverlässig etwas geliefert, was er so nicht gebrauchen kann, nur weil man gegen jegliche Änderung hohe Hürden (aufwändige und träge Change-Request-Verfahren) errichtet hat.

Der Satz, den ich anfangs zitiert habe, müsste also so lauten: „Um unseren Teil der Ergebnisverantwortung wahrzunehmen, haben wir ein agiles Vorgehen gewählt. Wir sind aufgrund unserer Erfahrungen mit vergleichbaren Projekten davon überzeugt, dass wir auf diese Weise durch professionelle und vertrauensvolle Zusammenarbeit aller am Projekt Beteiligten den von Ihnen gewünschten Erfolg erzielen werden.“

Aber das klingt vielleicht zu kompliziert für die Ohren der Rechtsabteilungen auf beiden Seiten? Kann sein. Dazu mehr in einem anderen Beitrag.

Diese und andere Fragen, die zwischen Erfolg und Misserfolg eines IT-Projektes entscheiden, behandle ich in meinem Buch „12 Halbwahrheiten über IT-Projekte„.