Die rollierende Planung

Können wir annehmen, dass zukünftige Ereignisse umso schwerer vorhersehbar sind, je weiter sie in der Zukunft liegen? Bedingt ist die Antwort ja. Wiederkehrende Ereignisse wie Ramadan, Sonnenfinsternisse oder Weihnachten können recht genau vorhergesehen werden. Wann jedoch der Administrator mit der Installation fertig ist? Das weiß er meist selber nicht.

Schauen Sie in Ihren elektronischen Kalender. Die Planung darin folgt genau diesem Prinzip. Eine Vielzahl von genau geplanten Terminen in den nächsten Tagen und vielleicht wenigen Wochen. Dann wird es immer weniger, unterbrochen von genau vorhersehbaren Terminen wie Feiertagen. Dazwischen steuerbare feste Termine wie Urlaub oder der Wechsel auf Sommerreifen (aber nur wenn das Wetter exakt genau so ist, wie es geplant wurde).

Daraus kann ein Prinzip abgeleitet werden: Je weiter in der Zukunft, desto ungenauer. Das Prinzip kann erweitert werden um eine Ableitung der Präzision: Je weiter in der Zukunft, desto weniger Details sind planbar.

Daraus kann das Planungsverfahren (sehr vereinfacht) der rollierenden Planung abgeleitet werden. Ich plane kurzfristig genau und langfristig grob (Das ergibt ein Problem in der Ressourcenplanung, das später in diesem Text behandelt wird).

Somit werden detaillierte Arbeitspakte in naher Zukunft (in wenigen Tagen oder Wochen) ebenfalls detailliert geplant (aber immer noch ungenau auf Basis des Wissens und der Vermutung des Planers). Je weiter der Planungshorizont ist, desto mehr werden Arbeiten zu Gruppen (Gewerken, Phasen, Epics) zusammengefasst. Diese Zusammenfassung wird dann in detailliertere Arbeiten extrahiert, wenn der Planer oder die Planerin zeitlich „näher“ dran ist.

Somit ist eine Planung am Anfang grob, hat also wenige Planungsobjekte, und wird im Laufe der Zeit immer detaillierter. Am Anfang des Projekts besteht der Plan beispielsweise aus 10 Planungsobjekten, am Ende des Projekts aus 2.000 (reales Beispiel aus der Praxis).

Es wird also ein Art Detailwelle vor sich hergeschoben, bis zum Ende des Projekts. Dies ist realistisch, entspricht es doch der menschlichen Denkweise. Eine Planung wird nicht realistischer, je detaillierter sie ist. Diese riesigen Detailpläne, teilweise auf den Tag genau über Jahre, basieren nicht auf vernünftigen Annahmen, sondern häufig aus der Angst des Planers, etwas zu vergessen. Oder entspringen schlicht einer Wunschvorstellung. Doch nur weil etwas im Plan steht, ist noch nicht gewährleistet, dass es so auch passiert.

Agile Planung

Die agile Planung ist eine extreme Variante der oben beschriebenen Methode, die vor allem im IT-Bereich große Zustimmung findet. Da die meisten IT-Projekte in der Vergangenheit verspätet waren, teurer wurden und nicht die Erwartungen erfüllt haben, hat man konsequent die Unvorhersehbarkeit solcher Projekte angenommen.

Wenn also ein Projekt und die darin beinhalteten Arbeit nicht vorhersehbar sind, ist es nur logisch, auf Sicht zu fahren. Man arbeitet also von Tag zu Tag bzw. von Sprint zu Sprint. Fertig ist man dann, wenn man eben fertig ist, wann auch immer das ist.

Diese Methode ist gar nicht so schlecht wie es hier anklingt, aber muss auch kritisch reflektiert werden. Es gibt eben doch IT-Projekte (und andere Projekte wie den Bau von Flughäfen, Opern oder Bahnhöfen), die durchaus erfolgreich geplant und realisiert werden könnten. Wenn an diesen Projekten berechtigte Kritik geübt wird, neigen wir alle dazu, das auf menschliches Versagen Anderer zurückzuführen.

Das ist oberflächlich und falsch. Schaut man etwas genauer hin und überlegt etwas länger, kommt man durchaus zu dem Schluss, dass diese Projekte sehr wohl relativ genau geplant und umgesetzt werden könnten. Ganz andere Einflussfaktoren stören das Vorhaben: Oft ist vielen Beteiligten von Anfang an klar, dass das Projekt so nicht ablaufen wird. Aber wirtschaftliche Zwänge (Ausschreibungen), mangelnde Vorbereitungszeit und politische Einflussnahme von wenig bis gar nicht qualifizierten Personen machen eine wirklich gute und realistische Planung von Anfang an obsolet.

Natürlich können Ingenieure ein Projekt wie Stuttgart 21 oder den Berliner Flughafen exakt vorhersehen, wenigstens zu 80% bis 90%. Dies würde aber einen extremen Planungsaufwand bedeuten. Weiterhin müsste in gewissen Toleranzen geplant werden, was jedoch anderen Entscheidungsträgern und der klassischen Budgetplanung staatlicher und kommerzieller Unternehmen entgegenläuft. Es wird eben kein Auftrag erteilt, wenn das Angebot zwischen acht und 10 Millionen Euro lauten würden. Stattdessen gilt: Der günstigste Anbieter bekommt den Auftrag.

Außerdem ist es fraglich, ob eine solche fundierte, relativ exakte Planung überhaupt einen Nutzen hätte.

Worin liegt der Nutzen beim Bau eines Flughafens, vorher exakt zu planen, dass dieser Flughafen 1,9 Mrd. Euro kosten wird – wenn er später knapp sieben Milliarden kosten wird? Zugegeben, diese Spanne ist schon gewaltig. Ein Anbieter, der sagen würde „So genau wissen wir das nicht, 3-4 Milliarden wird das Ding schon kosten, wir werden sehen“, hätte keine Chance auf einen Auftrag.

Eine agile Vorgehensweise ist bei einem Flughafenbau wahrscheinlich schwer machbar. In der Softwareindustrie ist das komplett anderes und ergibt durchaus Sinn.

Pflichtenhefte mit mehr als 100 Seiten beschreiben theoretisch, wie eine Lösung final funktionieren soll. Dabei liegen mehrere Annahmen zugrunde, die mit der zu erwartenden Realität absolut nichts zu tun haben. Der kleine Kreis der Personen, die ein Lastenheft produzieren, aus dem dann das Pflichtenheft für den Anbieter entsteht, glaubt, sich eine komplexe IT-Lösung aus dem Blickwinkel von Tausenden Anwendern vollständig vorstellen zu können. Der Anbieter glaubt auch, dass diese Anforderungen nicht nur sinnvoll, bedienbar und stabil sind, sondern auch, dass sie technisch umgesetzt werden können. Aber: Nicht einmal Albert Einstein wusste 1905 genau, ob das alles so stimmt und funktioniert, was er sich da ausgedacht hat (es stimmte und wurde später bewiesen).

Daher ist es durchaus sinnvoll, nur das zu planen, was man vorhersehen kann.

Ein Plan für ein Projekt ist die anzunehmende Zukunft, keine Wunschvorstellung. Diese Zukunft kann aber eben auch beinhalten, dass man etwas nicht weiß und schlicht versuchen muss, ob es funktioniert. Diese Problemstellung kann in der IT-Branche schneller behoben werden als in anderen Projekten. Ein Softwareproblem von in einem Elektroauto kann sehr schnell für alle behoben werden (update over the air). Ein grundsätzlicher Konstruktionsfehler am Fahrwerk oder an den Bremsen ist weitaus aufwendiger zu korrigieren.

Das unterscheidet eine Cloud-basierte IT-Branche von den meisten anderen Branchen in den „alten“ Industrieländern wie Deutschland. Der angestrebte Perfektionismus in Branchen wie Bau, Auto oder Maschinen ist fundamental verankert, da solche Probleme dort nicht schnell, kostengünstig und einfach zu lösen sind. Daher hat sich die agile Arbeit sinnvollerweise in der IT-Branche entwickelt und etabliert – und in anderen Branchen eben nicht. Agile Arbeit ist manchmal nicht möglich, auch wenn das Management, um ihre eigene Modernität darzustellen, dies postuliert.

Der Ausweg: hybride Planung

Dieser neue Ansatz könnte ein Ausweg aus diesem Dilemma sein. Hier werden zwei Planungstechniken kombiniert: Auf grober Ebene wird klassisch geplant, im Detail aber agil. Kombiniert mit der Möglichkeit, auch auf grober Ebene ungenau zu planen, kommen wir einer realistischen wahrscheinlichen Planung, die dem Wissenstand der Menschen entspricht, schon sehr nahe. Diese Planungsmethode klingt kompliziert, ist sie aber in Wirklichkeit überhaupt nicht.
In der klassischen langfristigen Planung, mit langfristigen Meilensteinen, Phasen und Budgets, wird eine – ungenaue – Wunschvorstellung aus grober Sichtweise formuliert. Im Detail, bei der eigentlichen Umsetzung, wird auf Sicht geplant (Sprints). Dabei bewegt man sich aber immer im Rahmen der groben Planung.

Dabei wird einfach der menschliche Faktor auf verschiedenen, quasi vertikalen und horizontalen Ebenen der Planung, berücksichtigt. Auf der strategischen Ebene werden Wunschvorstellungen, die nicht unrealistisch sind, ungenau beschrieben, beispielsweise ein Projektende im 4. Quartal. Auf der operativen Ebene, die einen hohen Detailgrad hat, werden Arbeiten nur für zwei Wochen (ein Sprint) und oder etwas länger (2 – 3 Sprints) geplant. So kommen die verschiedenen Sichtweisen der „strategischen“ Manager und der „im Detail lebenden“ Projektmitarbeitenden zusammen.

Agiles Arbeiten ist dynamisch und passt sich ständig veränderten Wissensständen und Umständen an. Alles ist im Fluss. Strategische Planung hat „das große Ganze“ im Sinn, ist stark planerisch von Ungenauigkeit geprägt und nimmt einen weit reichenden zeitlichen Horizont an.
Diese Planungstechnik nimmt sich das Beste aus beiden Welten und wird vor allem dem Denken und Handeln aller Akteure gerecht. Sie ist aber wahrscheinlich nicht auf alle Projektherausforderungen anwendbar. Die Entscheidung, ob diese Methode gewinnbringend umsetzbar ist, hängt inhaltlich von der Dynamik des Produkts oder der Dienstleistung ab. Können im laufenden Projekt Fehler und Abweichungen schnell und mit wenig Aufwand korrigiert werden? Bei Cloud-basierter Software ist die Antwort ja, bei einem Fundament für eine Hochhaus eher nicht.

Ausblick

Das große Ganze, von dem im letzten Abschnitt die Rede war, bestimmte diesen Teil unserer Blogpost-Reihe zum Ressorucenmanagement. Und genau um diese Ressourcen, also um jede/n Einzelne/n im Projekt, soll es in Teil 4 gehen. Dabei will ich auch klären, ob Ressourcenplanung in der agilen Welt einfacher und besser abläuft.

Du möchtest schon jetzt alles über Hybrides Projektmanagement, Can Do und Ressourcenmanagement unter menschlichen Aspekten wissen? Lass Dich von uns unverbindlich beraten – nimm einfach Kontakt auf!

Unsere Blogpost-Reihe in der Übersicht:

• Teil 1: Muss das Chaos sein? Planung von Menschen
• Teil 2: Was kann PM-Software leisten?
• Teil 3: Arten der Projekt-Planung (dieser Beitrag)
• Teil 4: Die / der Einzelne im Ressourcenmanagement
• Teil 5: Die Bewertung von Problemen in Projekten