in Agilität, Erfolgskriterien, IT Governance, Methoden, Planung, Projektmanagement - Praxis, Projektmanagement - Standards, Prozessoptimierung

Ich weiß, dass ich nicht weiß – was Agilität und Sokrates miteinander zu tun haben!

Projektmanagement soll Sicherheit geben

Jeder weiß, was das Ergebnis sein soll, was zu tun ist, wie der aktuelle Stand ist, wann was fertig sein wird. Natürlich kennt man auch den Aufwand und weiß rechtzeitig, ob es Abweichungen gibt oder geben wird. Soweit das Ideal – und wer wünscht sich das nicht?

Doch die böse Realität macht uns allzu oft einen Strich durch die Rechnung. Das geplante Ergebnis wird immer wieder verändert: Moving Target. Auch die Aufwandsprognose wird immer wieder korrigiert, leider in die falsche Richtung. Statusabfragen führen immer wieder zu hektischer Betriebsamkeit. Irgendwann ist der Aufwand für die Erstellung von Statusberichten so hoch, dass zu wenig Zeit bleibt, den Status durch Arbeit an den eigentlichen Aufgaben zu verbessern.

Die Reaktion darauf ist oft genug eine stärkere Formalisierung. Prozesse werden präzisiert, ihre Einhaltung strenger überwacht. Statusberichte werden immer detaillierter und in immer kürzeren Abständen verlangt. Der tägliche Statusbericht ist dann wohl die Krönung dieser Entwicklung, die als das typische „Mehr desselben“ im Sinne von Paul Watzlawick zu sehen ist. Wann immer ein neues Problem auftaucht, fordert das Management eine weitere Verschärfung der Kontrollmechanismen. Die Situation ist schlecht, sie wird jeden Tag schlechter, aber man weiß genau, wie schlecht.

Gibt es eine Methode, diesem Teufelskreis zu entgehen? Können wir unsere Planungs-, Schätz- und Steuerungsmethoden so verbessern, dass wir wirklich „alles im Griff“ haben? Die Antwort ist, ganz im Stil von Radio Eriwan: Im Prinzip ja. Der Schlüssel dazu liegt in der Frage, was wir als „alles im Griff“ verstehen. 

Weil nicht sein kann, was nicht sein darf

Mit Mark Twain müssen wir eines akzeptieren: „Prognosen sind schwierig, vor allem, wenn sie die Zukunft betreffen.“. Oder nehmen wir Albert Einstein: „Planen heißt, den Zufall durch den Irrtum zu ersetzen“. Oder Helmuth von Moltke: „Kein Plan übersteht die erste Feindberührung“. 

Diese Zitate kann man als defaitistisch abtun, sie sind es aber nicht. Sie lehren uns nur die Demut, die Begrenztheit unseres Wissens über die Zukunft zu akzeptieren und uns darauf einzustellen. Die großen Probleme entstehen, wenn wir uns weigern, die Begrenztheit unseres Wissens zu akzeptieren. Sokrates, zweifellos einer der klügsten Menschen, die jemals gelebt haben, hat seine Erkenntnisse in dem Satz: „Ich weiß, dass ich nicht weiß“, zusammengefasst. Das ist nicht Koketterie, um Widerspruch zu ernten. Je mehr man weiß, umso klarer sieht man die Begrenztheit des eigenen Wissens. 

Wenn wir aber diese Begrenztheit als Prämisse akzeptieren und unsere Vorgangsweise darauf abstimmen, sieht die Sache gleich viel besser aus. Ich nehme einen Vergleich, der nichts mit Projektmanagement zu tun hat. Wir akzeptieren unangenehme Erkenntnisse leichter, wenn sie nicht aus unserem ureigenen Kompetenzbereich kommen.

Wir müssen eine Last über eine unwegsame und uns unbekannte Route transportieren. Nun können wir vor Antritt der Fahrt beliebig viel Zeit investieren, um die Details dieser Route, jede Kurve, jede Steigung, jede Gefahrenstelle zu erkennen.

Mit diesem Wissen ausgestattet, treten wir die Fahrt an. Dummerweise sind unsere Informationen nicht immer korrekt, denn die Quellen sind rar. Dann ändert sich auch noch das Wetter und an einer Stelle kam es zu einer Hangrutschung. Viele unserer mühsam erhobenen Daten erweisen sich daher als falsch, jedenfalls zu dem Zeitpunkt, wo wir sie benötigen. 

Die richtige Balance finden

Was ist die Lösung? Einfach drauf los fahren? Natürlich nicht! Aber wir werden uns gut überlegen, welches Fahrzeug wir wählen, so dass wir eine ausreichende Bandbreite von schwierigen Straßenverhältnissen bewältigen können. Wir werden auch unsere Fahrkünste trainieren. Wenn das nicht rechtzeitig möglich ist, werden wir jemand engagieren, der mit dem gewählten Fahrzeug und den zu erwartenden Straßenverhältnissen auch im Worst-Case zurechtkommt.

Unsere Datensammlung werden wir daher darauf konzentrieren, die wahrscheinliche Häufigkeit und das maximale Ausmaß an Schwierigkeiten auf diesem Weg zu bestimmen. Darauf aufbauend werden wir unsere Schätzung der Fahrtdauer mit Risikozuschlägen versehen. Genügend Treibstoff für den LKW und genügend Getränke und Nahrung für uns nehmen wir an Bord.

Gesucht wird eine ausgewogene Mischung aus Datenanalyse und Planung – also Prognose – einerseits, Investitionen in unsere Leistungsfähigkeit bei der Bewältigung der zu erwartenden Probleme andererseits. Wir verzichten allerdings darauf, den genauen Ablauf unserer Fahrt im Voraus in allen Details zu planen und begnügen uns mit Bandbreiten. 

Damit akzeptieren wir Unsicherheiten. Wir gestehen uns ein, dass wir nicht alles im Voraus wissen und dass es zu unvorhergesehenen Herausforderungen kommen kann. 

Deterministische und systemische Planung

In kritischen Projektsituationen höre ich immer den Ruf nach einer besseren Planung. Nicht immer war ich in meiner Position gefestigt und mutig genug, die Frage zu stellen: Was meinen Sie mit „Planung“? Es wäre aber ohnehin nur eine rhetorische Frage gewesen, denn so gut wie immer ist damit ein Termin- und Aufwandsplan gemeint. Keine Frage, dass man eine solche Planung braucht, es braucht allerdings genauso eine Planung, wie diese Planwerte erreicht werden sollen. 

Machen wir uns das anhand des folgenden Modells anschaulich.

Die deterministische Planung versucht, eine exakte Prognose der drei Zielgrößen (Ergebnis, Termin, Budget) zu erstellen. Ob diese Prognose hält, hängt allerdings davon ab, wie gut die Produktionsprozesse (die inhaltliche Projektarbeit) und die Managementprozesse (also das Projektmanagement) funktionieren. Und diese benötigen für den Erfolg ausreichende Ressourcen, die zur richtigen Zeit am richtigen Ort in der benötigten Ausprägung zur Verfügung stehen müssen. 

Eine vollständige Planung muss alle diese Aspekte beinhalten, also auch die Projektarbeit als dynamisches System gestalten. 

Der agile Zugang zur Planung

Agile Projekte gewichten die Optimierung des dynamischen Systems höher als die Festlegung bzw. Prognose von Termin und Aufwand für im voraus fix definierte Ergebnisse. Die Prozesse sind immer die gleichen: Der Scope wird in überschaubare Einheiten (Epics, User Stories) heruntergebrochen. Diese bilden den Arbeitsvorrat (Backlog), der geclustert und priorisiert wird. Jedes Item erhält eine vorläufige Aufwandschätzung, die zunächst „nur“ die Aufwandsrelationen zwischen den Items abbildet („Storypoints“). Die Gesamtaufwandschätzung erfolgt mit eher globalen Methoden (Vergleichswerten, Top-Down-Schätzungen) und dient vor allem der Dimensionierung der Personalressourcen („agile Teams“) in Relation zur erwarteten Laufzeit.

Es wird allerdings darauf verzichtet, die Zwischentermine samt erwartetem Ergebnis im Voraus – womöglich mit dem Anspruch auf Vollständigkeit – zu planen. Dieser Versuch wird als sinnlos, weil zum Scheitern verurteilt, gesehen und daher unterlassen; man würde damit nur Zeit verlieren und wertvolle Ressourcen verschwenden. 

Die Gestaltungsvariablen sind die Inhalte, die schrittweise abgearbeitet werden. Dazu gibt es eine rollierende Planung; stets einen groben Plan bis zum Projektabschluss, einen genauen Plan immer nur für die nächsten Iterationen/Sprints. Anhand der tatsächlich erzielten Fortschritte wird die „Velocity“ (wie viele Storypoints schaffen wir je Iteration) immer genauer ermittelt und damit die Fertigstellungsprognose präzisiert. Und es wird akzeptiert, dass man unter den gegebenen Umständen nicht mehr liefern kann, als diese empirischen Daten aus dem konkreten Projekt zeigen. Das kann weniger sein, als es sein sollte. Obwohl für viele Manager nicht sein kann, was nicht sein darf (Christian Morgenstern), ist es am Ende doch immer so, wie es ist.

Eine kompakte Erläuterung, was Agilität im Projektmanagement beinhaltet, gibt es im Glossar des Projektmagazins.

Fahrt ins Blaue statt Planung?

Auftraggeber, die von traditionellem Projektmanagement („Wasserfallmodell“) geprägt sind, sind vom offenen Eingeständnis der Unwissenheit schockiert. Viele sehen zwar mittlerweile ein, dass agiles Vorgehen effizienter ist als das Planen und Abarbeiten von gefinkelten Terminplänen mit kunstvoll geschnittenen und einzeln geplanten Arbeitspaketen. Aber es muss doch trotzdem einen Plan geben, der sagt, was wann fertig sein wird und wieviel Aufwand damit verbunden ist. Gerade wieder habe ich erlebt, wie einem agilen Projekt Arbeitspaketdefinitionen aufgezwungen wurden. Eine sinnlose Aktion die Zeit kostet und nichts bringt. Es schaut zwar alles schön geplant aus, die Eckpunkte des magischen Dreiecks sind also determiniert. Aber ob das Projekt erfolgreich sein wird, hängt von Faktoren ab, die außerhalb dieser Planung liegen.

Wenn durch eine traditionelle Planung das Management (Auftraggeber, Projektcontroller, …) beruhigt werden kann (ich würde sogar sagen: „ruhiggestellt“), ist das OK. Es ist ein Opfer, das man bringen muss, um einen Schutzschild aufzubauen, hinter dem effizient am Ergebnis gearbeitet werden kann. Schlimm wird es nur, wenn diese Art von Planung Einfluss auf die tatsächliche Projektarbeit bekommt. Auch das habe ich schon erlebt und es ist die Hölle. Das hat schon Shakespeare gewusst: „Und ist es Wahnsinn, so hat es doch Methode“. Man weiß, wie das Stück endet: Fast alle, einschließlich Hamlet sind tot. 

Wenn man sich aber auf die agile Methodik einlässt und weiß, dass nicht nur die Qualität, sondern alle Ergebnisse nur durch Produktionsprozesse, nicht durch Kontrollen erzielt werden, ist das Ergebnis auch nach traditionellen Maßstäben besser. In gleicher Zeit wird mehr geliefert, der Aufwand ist geringer als er bei „klassischen“ Methoden gewesen wäre. Aber das erfährt man nur, wenn man sich darauf einlässt. 

Erfreulicherweise nimmt die Zahl der Top-Manager, die das verstanden haben, stetig zu. Und damit ergeben sich die Freiräume in der Projektarbeit, an der Effizient der Projektarbeit zu arbeiten und nicht Pläne zu erstellen, die Wissen über die Zukunft vortäuschen, das keiner hat und haben kann. Wenn ich weiß, dass ich nicht weiß, wie genau alles verlaufen wird, bin ich gerüstet, die unvermeidlichen Überraschungen frühzeitig zu erkennen und erfolgreich zu bewältigen. 

Wer meine Gedanken zu der Herausforderung des Planens in IT-Projekten als Podcast hören möchte kommt hier direkt zum Web-Player:

 
 
 

Schreibe einen Kommentar

Kommentar

  1. PMI publizierte soeben (Februar 2021) folgendes Statement, das meinen Zugang zum Thema bestätigt und illustriert:

    PLANNING IS ALWAYS THERE

    A key thing to remember about life cycles is that each of them share the element of planning. What differentiates a life cycle is not whether planning is done, but rather how much planning is done and when.
    At the predictive end of the continuum, the plan drives the work. As much planning as is possible is performed upfront. Requirements are identified in as much detail as possible. The team estimates when they can deliver which deliverables and performs comprehensive procurement activities.
    In iterative approaches, prototypes and proofs are also planned, but the outputs are intended to modify the plans created in the beginning. Earlier reviews of unfinished work help inform future project work.
    Meanwhile, incremental initiatives plan to deliver successive subsets of the overall project. Teams may plan several successive deliveries in advance or only one at a time. The deliveries inform the future project work.
    Agile projects also plan. The key difference is that the team plans and replans as more information becomes available from review of frequent deliveries. Regardless of the project life cycle, the project requires planning.
    Predictive life cycles expect to take advantage of high certainty around firm requirements, a stable team, and low risk. As a result, project activities often execute in a serial manner…
    In order to achieve this approach, the team requires detailed plans to know what to deliver and how. These projects succeed when other potential changes are restricted (e.g., requirements changes; project team members change what the team delivers). Team leaders aim to minimize change for the predictive project.
    When the team creates detailed requirements and plans at the beginning of the project, they can articulate the constraints. The team can then use those constraints to manage risk and cost. As the team progresses through the detailed plan, they monitor and control changes that might affect the scope, schedule, or budget.
    By emphasizing a departmentally efficient, serialized sequence of work, predictive projects do not typically deliver business value until the end of the project. If the predictive project encounters changes or disagreements with the requirements, or if the technological solution is no longer straightforward, the predictive project will incur unanticipated costs.