„Wir brauchen doch einen detaillierten Plan!“, wirft der Abteilungsleiter eines Fachbereichs aufgeregt ein. „Wie sollen denn alle wissen, was sie jeweils tun sollen, wenn wir für das Projekt keinen Plan haben!“
Wir sind gerade dabei, im Rahmen beim ersten Termin des Lenkungsausschusses unser Vorgehen vorzustellen und die Projektleiterin des Kunden aus der öffentlichen Verwaltung, die mit den ersten Folien zur agilen Vorgehensweise begonnen hat, blickt mich in meiner Rolle als Leiter des externen Umsetzungsteams hilfesuchend an. Genau vor diesem Moment hat sie gewarnt – sie kennt ihre Organisation.
„Wir haben einen Plan“, versuche ich, ruhig mit den Begriffen meines Gegenübers zu arbeiten. „Wie bereits vorgestellt, kennen wir die großen Themenbereiche, an denen wir arbeiten müssen und wir haben Strategien in jedem dieser Bereiche und die Abhängigkeiten identifiziert, damit wir in der richtigen Mischung aus Abfolge und Parallelität arbeiten können. Außerdem gibt es Meilensteine, die eine zeitliche Einordnung ermöglichen und uns zeigen, wie wir im Gesamtprojekt vorankommen.“
Mir ist schon, während ich diese Worte sage, klar, dass ich damit nicht durchkommen werde.
„Wir müssen in einem Projekt doch wissen, wer wann woran arbeitet. Alles andere wäre doch fahrlässig. So können wir doch nicht mit dem Geld der Steuerzahler umgehen. Da sehe ich doch jetzt schon den Rechnungshofbericht vor mir, der uns zerpflückt!“
An den Gesichtern in der Runde kann ich erkennen, dass einige dieser Aussage zustimmen, während andere unsicher sind. Hoffnung machen mir aber die Gesichter bei den Mitgliedern des Lenkungsausschusses, die die Stirn runzeln zu solchen Aussagen, weil sie verstanden haben, dass ein exakter Plan für die nächsten zwei Jahre nicht eine erfolgreiche Projektumsetzung garantiert, sondern vor allem einmal ein Plan ist. Vermutlich sind es jene, die schon den einen oder anderen wunderbar klingenden Projektplan an einem Eisberg zerschellen und untergehen gesehen haben.
„Danke für diesen guten Hinweis – ich denke genau das ist es, was die Kollegin“, ich nicke dabei in Richtung der Projektleiterin, die die Präsentation führt, „gerade darlegen wollte. Neben diesem Plan, der das gesamte Projekt auf einer abstrakten Ebene umfasst, planen wir natürlich auch immer die nächsten Wochen im Detail. Dazu gibt es in regelmäßigen Abständen eigene Planungsmeetings, bei denen die nächsten Tätigkeiten im Detail festgehalten werden, sodass jeder im Team weiß, was zu tun ist. Bei einem Plan, bei dem wir jetzt festlegen, dass auf den Tag genau in einem Jahr eine Mitarbeiterin ihrer Abteilung genau die Tätigkeit X für unser Projekt durchführen muss, hätten wir viel zu viel Unsicherheit. Sie müssten alle unsere geplanten Tätigkeiten im Auge behalten, damit sie jeweils wissen, ob sie ihr für einen bestimmten Zeitpunkt Urlaub genehmigen können und keiner kann sagen, ob sie nicht vielleicht krank ist und wir nicht schon viel früher alle Voraussetzungen für die Realisierung der Tätigkeit haben.“
Ich bin mir nicht sicher, ob es die schlüssige Argumentation hinsichtlich der Unsicherheit ist, oder die Angst davor tatsächlich alle unsere Tätigkeiten im Auge behalten zu müssen, die den Abteilungsleiter zum Rückzug veranlasst. Mit einem gemurmelten „Professionelles Projektmanagement ist das aber nicht“, winkt er der Projektleiterin zu weiterzumachen.
Während sie mit den nächsten Folien versucht, das agile Vorgehen zu erläutern, versinke ich ein wenig ins Grübeln über die in der öffentlichen Verwaltung besonders häufig geführte Diskussion zur richtigen Planung. Liegt es daran, dass planorientiertes Projektmanagement in der öffentlichen Verwaltung auf Organisationen trifft die sehr regelbasiert, weil gesetzeskonform handeln müssen – also wenig eigene Spielräume haben? Oder daran, dass gerade in diesem Umfeld das Eingeständnis von Unsicherheit – also dem „nicht Wissen“ wie etwas sein wird – besonders schwerfällt?
„Kein Plan überlebt die erste Feindberührung!“ – dieses zugegebene martialische Zitat wird Helmuth von Moltke zugeschrieben. Herausgelöst aus seinem militärischen Kontext dürfte es allen, die größere IT-Projekte geführt haben aus dem eigenen Erleben durchaus bekannt sein. Ein Plan der ein Projektteam mit rund acht Personen für eine Durchlaufzeit von einem Jahr auf Tagesebene zu planen versucht, wird keine gute Chance haben tatsächlich zu erraten, welche Tätigkeiten jeder einzelne in einem Jahr durchführt. Die Ableitung daraus ist jedoch nicht, das Planen ganz zu verwerfen und in den Tag hineinzuleben, sondern für unterschiedliche Ebenen Pläne mit unterschiedlichen Zeithorizonten zu machen, andere Planungsmechanismen einzusetzen und nicht zu glauben für alle Ebenen gelte dasselbe. In Wirklichkeit war das natürlich auch schon vor dreißig Jahren allen klar, die Projekte geplant haben und in den meisten Fällen auch kein reales Problem. Pläne waren dazu da angepasst zu werden, verfeinert und aktualisiert. Der wesentliche Schritt der agilen Methoden in diesem Bereich war aber tatsächlich den Aufwand für die Detailplanung zu verringern, indem man nur das plant, was auch absehbar ist und eine hohe Wahrscheinlichkeit gibt in dieser Form realisiert zu werden. Das macht den übergeordneten Plan nicht unwichtig, sondern im Gegenteil: eine Strategie für das Gesamtprojekt zu haben, ist umso wichtiger, denn nur an dieser orientiert kann die richtige Entscheidung über die nächsten Schritte getroffen werden – unter Berücksichtigung aller gemachten Erfahrungen, unter Beobachtung der aktuellen Situation. „Inspect and Adept“ eben – die eigentliche Grundlage des agilen Vorgehens.
Und eigentlich sind wir Menschen genau dafür gemacht. Im Gegensatz zu vielen anderen Spezies auf unserer Erde zeichnen sich Menschen nicht durch eine Spezialisierung an eine bestimmte Umgebung aus, durch eine genetisch definierte Prägung auf einen Lebensraum, sondern das, was uns auszeichnet ist die Anpassungsfähigkeit. Und diese Anpassungsfähigkeit stellen wir seit Generationen unter Beweis. Nicht nur, indem Menschen sowohl in den Regenwäldern, Wüsten und im arktischen Klima überlebt und angesiedelt haben, sondern auch indem ein Kind in der Steinzeit geboren sich genauso zurechtfinden würde, wie im alten Rom oder im heutigen New York. Nun haben wir vielleicht im Berufsleben nicht mehr die gleiche Anpassbarkeit, aber wohl doch genug, um in einem Projekt die aktuelle Situation wahr zu nehmen, wie sie ist und darauf entsprechend mit unserer Erfahrung zu reagieren. Und ja – das ist die erfolgversprechendste Form mit dieser komplexen Umwelt umzugehen, die wir bisher gefunden haben. Gut untersucht von Dave Snowden und abgebildet in der weithin bekannten Cynefin-Matrix. Es geht bei unseren IT-Projekten nicht darum wiederkehrende einfache Aufgaben abzuwickeln, sondern um komplexe Aufgaben, bei denen kreative Ideen und Experimente gefragt sind, um ans Ziel zu kommen. Zu viele Faktoren beeinflussen unsere Pläne (Urlaub und Krankheit sind dabei noch die direkt ersichtlichsten).
Unsere Evolution hat uns immer wieder mit Herausforderungen konfrontiert, an die wir uns anpassen mussten, um als Menschheit zu überleben. Und die Menschheit hat immer wieder aufs Neue Technologien und Methoden ersonnen, um sich als Menschheit weiterzuentwickeln. Wir können das also: Die Situation erfassen („Inspect“) und uns darauf einstellen („Adept“). Die Ungewissheit ist uns oft unangenehm – vielleicht sollten wir uns aber öfter auf unsere Stärke verlassen, laufend mit dem (Projekt-)Leben fertig zu werden, als uns in der Sicherheit eines unrealistischen Plans zu flüchten. Auch das wäre ein Zeichen von Professionalität. Und wenn es gelingt und das Projekt erfolgreich ist, wird auch der Rechnungshof nicht viel zum „Zerpflücken“ finden.
Agile Verwaltung 