“Wir werden agil und organisieren uns in Teams. Ihr dürft zukünftig so agil arbeiten, wie Ihr wollt. Solange Ihr alles so liefert, wie wir es in der letzten Jahresplanung beschlossen haben!”
Das ist eine Ansage mit wenig Aussicht auf Erfolg. Projekte mit fixen Planungsvorgaben lassen sich mit agilen Arbeitsmethoden nicht retten. Und es lohnt sich auch nicht.
Was ist das “Iron Triangle”?
Unternehmen führen seit Jahrzehnten Veränderungsvorhaben in klassischen Großprojekten durch, die in Projektportfolios organisiert sind. Jedes dieser Projektvorhaben definiert sich durch einen präzisen Leistungsumfang, einen klaren Kostenrahmen und harte Terminvorgaben.
Für solche fixen Projektvorgaben hat sich der Begriff „Project Management Triangle“ oder kurz „Iron Triangle“ etabliert, weil das Management im Sinne der Planungssicherheit darauf besteht, dass die Umsetzung mit dem geplanten Leistungsumfang, mit dem vereinbarten Budget und mit den vorgegebenen Meilensteinen erfolgt.
Das „Iron Triangle“ ist in einer VUCA-Welt überholt
Leider erfüllt sich diese Erwartung heute nur selten. Wir leben in einer komplexen, dynamischen und volatilen Geschäftswelt (“VUCA-Welt”: Volatility, Uncertainty, Complexity and Ambiguity”), in der Veränderungen immer schneller eintreten. Da ist es schlichtweg unmöglich, für ein Veränderungsvorhaben vorab alles zu wissen und präzise zu planen. Das Management begegnet dieser Projekt-Realität zumeist mit Nachbesserungen („Change Requests“), was häufig zu höheren Kosten, zu einer Verschiebung von Terminzusagen und zu Kompromissen in der Qualität führt.
Die falsche Lösung: fixe Projektplanung und agile Teams
Als Hoffnungsschimmer sieht man heute gerne agile Arbeitsweisen. Sie sollen dafür sorgen, dass klassische Projekte die fixen Planungsvorgaben besser einhalten: „Wir werden agil und organisieren uns in Teams. Ihr dürft zukünftig so agil arbeiten, wie Ihr wollt. Solange Ihr alles so liefert, wie wir es in der letzten Jahresplanung beschlossen haben!”
Warum ist das der falsche Ansatz?
Management-Erfolg definiert sich besonders über die Fähigkeit, Projektvorhaben mit fixen Vorgaben konsequent und straff durchzuziehen. Spätestens bei der Nachverhandlung für Zusatzbudget und bei der Verschiebung von vereinbarten Terminen steigt der Erfolgsdruck enorm. Dieser Druck setzt sich in der Führungshierarchie der Linienorganisation weiter fort und ist im mittleren Management und bei den Mitarbeiter:innen in den „Teams“ besonders deutlich spürbar.
Die Einhaltung der fixen Projektvorgaben wird zu einer tagtäglich spürbaren Bedrohung. Verschärft wird diese Situation noch dadurch, dass viele Menschen parallel in mehreren Projekten arbeiten, jedes mit eigenen – manchmal sogar konkurrierenden – Vorgaben zum „Iron Triangle“.
In dieser Situation haben Menschen schlichtweg keinen Nerv dafür, sich mit Veränderungen ihrer Arbeitsweisen zu befassen. Sie werden alles daran setzen, in dem bekannten Umfeld zu bleiben, um keine zusätzlichen Risiken einzugehen, die die Einhaltung der Projektvorgaben noch stärker gefährden könnten, als dies die tägliche Projektrealität ohnehin schon tut.
Die gut gemeinte Aufforderung „Ihr dürft zukünftig so agil arbeiten, wie Ihr wollt. Solange Ihr alles so liefert, wie wir es in der letzten Jahresplanung beschlossen haben!” führt nicht zu mehr Motivation, sondern im Gegenteil zu noch mehr Frust im Arbeitsalltag. Ganz besonders, wenn Menschen gezwungen sind, bestehenden Konzern-Prozessen zu folgen, um Projektziele nicht zu gefährden, und gleichzeitig agile Arbeitsweisen nachzuahmen.
Projekterfolg neu definieren
Neue, agile Arbeitsweisen zu etablieren und gleichzeitig auf der Einhaltung fixer Projekt-Planungsvorgaben zu beharren, ist nicht vereinbar.
Die Führung muss „Projekterfolg“ und „Performance“ neu definieren: ein Vorhaben ist NICHT erfolgreich, wenn ein vorab festgelegter Plan über Monate und Jahre möglichst exakt ausgeführt und erfüllt wird. Ein Vorhaben ist dann erfolgreich, wenn es gelingt, in einer zunehmend dynamischen, volatilen und komplexen Geschäftswelt, die sich immer schneller verändert, möglichst rasch und möglichst kontinuierlich Mehrwert für Kunden zu generieren.
Bjarte Bogsnes schreibt über das Management von “Performance” in seinem Buch “Implementing Beyond Budgeting: Unlocking the Performance Potential”:
In fact, I do not believe that performance really can be “managed” at all, at least not in the traditional way that so many management theories want us to believe. People are not robots, organizations are not machines, and the future is more unpredictable than ever. Managers can’t just sit in the control room, pull strings, push buttons, and “manage” performance. You can’t make a flower grow by pulling on it.
What we can do, however, is to create the conditions needed for growth and performance. We can create an environment of trust and transparency, of positive challenge and stretch, of care and support, where people perform because they want to, not because they are told to.
Wie schaffen wir eine Umgebung von Vertrauen, Transparenz und positiven Herausforderungen?
Fixes Budget und fixe Zeitvorgaben. Aber flexibler Scope!
Die Führung gibt keinen fixen, detaillierten Leistungsumfang (Scope) mehr vor über ein Projekt-Pflichtenheft oder eine Detailspezifikation. Stattdessen formuliert sie eine konkrete Zielsetzung für eine gewünschte Wirkung, die aus Business-Sicht erzielt werden soll (Business-Hypothese).
Die Führung verbindet diese Zielsetzung mit einem konkreten Zeitfenster und einem fixen Budget, die beide für die Erreichung dieser Zielsetzung realistisch erscheinen. Damit ist sichergestellt, dass das Vorhaben kein Fass ohne Boden wird, und eine laufende Kosten/Nutzen-Einschätzung erfolgen kann.
Wie hoch ist der Einsatz?
Im Grunde legt die Führung damit fest, wie viel sie bereit ist zu riskieren, um die gewünschte Wirkung zu erreichen. Denn es gibt in einer komplexen, dynamischen und volatilen Geschäftswelt leider keine Garantie, ob das formulierte Ziel tatsächlich erreichbar ist.
Je nachdem, wie viel die Führung bereit ist zu riskieren, können die Budget- und Zeitvorgaben sehr überschaubar sein oder auch längerfristig. Aber selbst bei längeren Zeiträumen (z.B. ein Jahr) empfiehlt es sich, zumindest einmal pro Quartal zu verifizieren, ob die Zielsetzung noch relevant ist und ob zunehmend mehr Sicherheit entsteht, dass sie erreichbar ist. Die Komplexität kann in verschiedenen Dimensionen liegen. Zumeist ist es eine Mischung aus
- welcher Nutzen entsteht beim Kunden (desirable)?
- was lässt sich in der vorgegebenen Zeit bzw. im Budget umsetzen (feasible)?
- welcher Wert lässt sich für das Unternehmen daraus generieren (valuable)?
Welchen Scope brauchen wir?
Das Team erarbeitet dann selbst iterativ und inkrementell den notwendigen Leistungsumfang (Scope, Output), um diese gewünschte Business-Wirkung (Outcome) möglichst gut zu erreichen.
Flexibler Scope heisst somit nicht überbordende Kosten und unkontrollierbare Ergebnisse, sondern genau das Gegenteil: man kann Risiken früher erkennen und darauf reagieren. Man entwickelt nur das, was wirklich benötigt wird. Gemäss dem Prinzip „Simplicity – the art of maximizing the amount of work not done – is essential “ aus dem Agilen Manifesto.
Im Gegensatz dazu gibt es nur wenige Projekte mit fixen Planungsvorgaben, die mit dem ursprünglich definierten Leistungsumfang auskommen. Nach einer langen „geplanten“ Phase ist zumeist eine Reihe von Change Requests erforderlich, um tatsächlich eine gute Lösung zu finden. Agile Methoden beginnen damit von Anfang an, weil es viel mehr der heutigen Realität entspricht. Leider haben die meisten Menschen ein mentales Problem mit Unsicherheit und Volatilität. Sie halten lieber am „Iron Triangle“ fest, das ihnen aber nur eine trügerische Sicherheit geben kann.
Es ist somit ganz klar erklärbar, wie das Iron Triangle durch agile Methoden aufgebrochen wird: mit der Herangehensweise zur Lösung von komplexen Problemen. Die Aussage „Ihr dürft zukünftig so agil arbeiten, wie Ihr wollt. Solange Ihr alles so liefert, wie wir es in der letzten Jahresplanung beschlossen haben“ widerspricht fundamental dieser Herangehensweise. Agile Arbeitsweise bedeutet ja genau, dass man NICHT im Vorhinein sagen kann, wie das Projekt geliefert werden soll.
Im Umkehrschluss ist in jenen Situationen, wo tatsächlich alles präzise planbar ist (in ALLEN Komplexitätsdimensionen, siehe oben) Agilität auch nicht die effizienteste Vorgehensweise. In unserer Zeit ist dies aber immer seltener der Fall. Und so gut wie nie in der Softwareentwicklung.
Was wäre ein erster, sinnvoller Schritt?
Es ist klar, dass ein Konzern sein klassisches Projektportfolio nicht von heute auf morgen durch kontinuierliche Liefer- und Wertströme ersetzen kann.
Einen kontinuierlichen Wertestrom aufzubauen bedeutet, Produkte und Services kleinteiliger zu liefern, damit Nutzen beim Kunden früher und laufend entsteht und die Feedback-Frequenz steigt. In der Konsequenz kann auch die Festlegung von Leistungsumfang, Budget und Zeitvorgaben für Veränderungsvorhaben nur kleinteiliger erfolgen als bisher.
Für einen ersten Schritt weg vom „Iron Triangle“ wäre es schon großartig, wenn es der Führung gelingt, nur ein einziges, überschaubares Pilotvorhaben im Unternehmen/Konzern zu finden, für das Erfolg neu definiert wird und in dem Mitarbeiter:innen wirklich anders agieren dürfen.
- dieses Vorhaben bekommt die Zusicherung der Führung, losgelöst von bestehenden Konzernprozessen und klassischen Portfolios agieren zu dürfen (Safe-to-Fail).
- die Führung formuliert für das Vorhaben eine Business-Hypothese mit konkreten Wirkungszielen.
- das Management setzt für das Vorhaben einen überschaubaren Zeitrahmen, z.B. drei (oder sechs) Monate.
- in diesem Vorhaben dürfen sich Menschen aus unterschiedlichen Unternehmensbereichen freiwillig für die Mitwirkung in kleinen, cross-funktionalen Teams melden (maximal drei Teams zu je 5-7 Menschen). Das Unternehmen kann beispielsweise dafür eine Einladung zur Mitwirkung aussprechen.
- das Vorhaben bekommt ein Budget, dass die laufenden Kosten für die Teams über drei (oder sechs) Monate abdeckt (Run-Rate).
- alle Teammitglieder dürfen sich für den vereinbarten Zeitraum zu einhundert Prozent nur diesem Vorhaben widmen. Sie dürfen selbst entscheiden, welche Rolle sie einnehmen wollen.
- die erhalten Ausbildung und Coaching-Begleitung für ihre neuen Rollen, bevor sie starten.
- die Teams sind mit allen Fähigkeiten (Skills) ausgestattet, die sie brauchen, um möglichst autonom Kundenwert zu liefern.
- die Teams legen selbst fest, in welcher Reihenfolge (bis wann) sie welche Lieferungen (Scope) umsetzen werden, um die formulierte Business-Hypothese zu realisieren.
- die Führung nimmt regelmäßig (z.B. alle 2 Wochen) an einem Review-Termin teil, bei dem die Teams live präsentieren, wie sie konkreten Kundennutzen generieren. Dabei gibt sie direktes und offenes Feedback. Daraus entsteht wechselseitig Transparenz und Vertrauen, dass die Teams an den Themen arbeiten, die der Führung wichtig sind, und damit auch nachvollziehbar Fortschritt erzielen – im Sinne einer laufenden Kosten/Nutzen-Kontrolle.
Nach drei (oder sechs) Monaten haben alle Beteiligten inklusive Führung hautnah erlebt und erfahren, wie es mit neuen, agilen Arbeitsweisen gelingt, in einer zunehmend dynamischen, volatilen und komplexen Geschäftswelt laufend Kundenwert zu generieren.
Fazit & Take-Away
Projekte mit fixen Vorgaben für Leistungsumfang, Budget und Meilensteine mit agilen Arbeitsweisen effizienter machen zu wollen und damit das “Iron Triangle” zu retten, ist ein aussichtsloses Unterfangen.
Und es lohnt sich auch nicht, weil sich in unserer zunehmend komplexen, dynamischen und volatilen Geschäftswelt (“VUCA-Welt”) Projekte mit fixen Vorgaben längst überholt haben.
Mit neuen, agilen Arbeitsweisen lassen sich kontinuierliche Liefer- und Wertströme aufbauen. Die Führung formuliert dafür Wirkungsziele über Business-Hypothesen. Die agilen Teams entscheiden selbst, was sie liefern, um diese Wirkungsziele zu erreichen
Erfahren Sie mehr über agile Projektplanung und melden Sie sich jetzt für unser zertifiziertes Product Owner Training an, um zum Experten in der Steuerung erfolgreicher Projekte zu werden.
