Mikro-Makro-Ebenen im Projektmanagement:

Schwindelfrei zwischen klassischer Planung und agiler Steuerung balancieren

Blue Ant

Die Frage, ob und wie man klassisches und agiles Projektmanagement verbinden kann, ist noch längst nicht abschließend beantwortet. Norman Frischmuth, Geschäftsführer der proventis GmbH, hat das Ringen um die optimale Lösung von Anfang an mitbegleitet und in vielen Unternehmen erlebt. Das Ergebnis liegt für ihn inzwischen klar auf der Hand.

 

Mikro-Makro-Ebenen im Projektmanagement:

Schwindelfrei zwischen klassischer Planung und agiler Steuerung balancieren

Blue Ant

Die Frage, ob und wie man klassisches und agiles Projektmanagement verbinden kann, ist noch längst nicht abschließend beantwortet. Norman Frischmuth, Geschäftsführer der proventis GmbH, hat das Ringen um die optimale Lösung von Anfang an mitbegleitet und in vielen Unternehmen erlebt. Das Ergebnis liegt für ihn inzwischen klar auf der Hand.

 

Herr Frischmuth, die Frage, ob und wie man klassisches und agiles Projektmanagement verbinden kann, ist nach wie vor aktuell. Was sind nach Ihrer Erfahrung heute die größten Diskussionspunkte?

Erstaunlicherweise werden diese beiden Konzepte noch viel zu häufig kontrovers diskutiert, als gäbe es nur ein Entweder-oder. Wer gute Erfahrungen mit dem klassischen Vorgehen hat, lehnt dann das agile ab. Wer meint, dass es bisher nicht so gut funktioniert hat, sieht das Heil in agilen Konzepten – ohne zu überlegen, warum das eine nicht funktioniert und welche Ursachen das tatsächlich hat.

Welche Erfahrungen sind es denn, die da aufeinandertreffen?

Die Anhänger der agilen Vorgehensweise stehen auf dem Standpunkt: "Für eine klassische Planung gibt es in meinen Projekten keine ausreichende Stabilität, der Aufwand, auf Neuerungen zu reagieren, ist zu groß. Klassische Planung zwängt uns in ein Korsett, das nicht passt!" Dagegen steht der Anspruch des Managements, Budgets, Zeiten und Endtermine einzuhalten: "Wir brauchen Verbindlichkeit, um das Unternehmen zu steuern!"

Wie lässt sich für diesen Interessenkonflikt nun aus Ihrer Erfahrung eine gute Lösung für alle finden?

Die Lösung ist naheliegend, nämlich aus den verschiedenen Welten das zu nehmen, das man auf den verschiedenen Ebenen braucht. "Hybrides Projektmanagement" lautet das aktuelle Schlagwort dazu. Ob eine solche Mischung erfolgreich ist, hängt entscheidend davon ab, wo man den Schnitt zwischen diesen beiden Konzepten macht. Denn durch inkonsequente Anwendung macht man sich die jeweilige Methode gegebenenfalls auch wieder kaputt.

Aber kein Entweder-oder? Etwa je nach Projekt oder Bereich?

Nein, meine Erfahrung und These ist: Agil funktioniert auf einer Arbeitsebene, klassisch auf der Ebene, auf der ich Stabilität brauche, nämlich bei der mittel- und langfristigen Planung. Man sollte also nicht von Projekt zu Projekt entscheiden, sondern eher zwischen Mikro- und Makroebene.

Können Sie diese Ebenen noch etwas präziser beschreiben beziehungsweise trennen?

Die Grenzen sind eher fließend. Bei Scrum würde man hinsichtlich der strategischen Makroebene von Epics sprechen, vielleicht noch die User Stories mit dazu nehmen. Im klassischen Projektmanagement geht es um Anforderungen, Planung von Modulen, Phasen, Funktionalitäten bis hin zu einem groben Projektstrukturplan mit Abhängigkeiten, Ressourcen und Kapazitäten. Aber diese Ebene ist zu grob, um sinnvolle Aufwandschätzungen abgeben zu können und das Projekt exakt zu steuern, vor allem wenn es um den konkreten Arbeitseinsatz pro Mitarbeiter geht. Die detaillierte Planung auf der Basis von Wochen, Tagen oder Stunden passt besser auf die Mikroebene. Da kann man gut einen Schnitt machen.

Denken Sie hier vor allem an Softwareprojekte?

Nein. Man kann aus der Softwareentwicklung vieles lernen und in andere Projekte übertragen. Im Grunde passt das Vorgehen auf viele Projektarten. Ich denke auch an Organisationsprojekte, die oft hoch kreativen Event- bzw. Marketingprojekte, Forschungsprojekte, Innovationsprojekte … Also Vorhaben, bei denen man im Projektverlauf noch korrigieren, etwas hinzufügen oder weglassen kann. Weniger geeignet sind Projekte, bei denen die Konzeption schon Weichen stellt, die bis ans Ende führen, etwa Bauprojekte.

Wenn Planung mit einer Granularität auf Wochenebene bei den agilen Teams liegt, wie kann dann die projektübergreifende Ressourcenplanung gelingen?

Die Frage der Ressourcenplanung ist tatsächlich eine der schwierigsten, schon weil man ja nie genau weiß, welcher Aufwand tatsächlich hinter einem Arbeitspaket steckt. Was aber möglich ist: Man kann die vorhandenen Ressourcen im Zuge des Multiprojektmanagements auf Basis der groben Schätzungen auf die einzelnen Themen in den Projekten so aufteilen, dass sie keine großen Überschneidungen erfahren. Das ist dann die Vorgabe für die agile Ebene darunter: "Ihr könnt selbstbestimmt agieren, aber Ihr dürft die Ressource nur so weit nutzen, wie ich sie Euch zugewiesen habe."

Erleben Sie Unternehmen, in denen dieses Vorgehen konsequent umgesetzt wird?

Ja. Immer häufiger hängen in den Büros große Pinnwände, auf denen Karten mit wöchentlichen oder täglichen To-Dos hin und her geschoben werden. Doch gibt es auch einen Projektablaufplan, über den u.a. mit dem Kunden kommuniziert wird. Wichtig ist, dass man dieses Vorgehen konsequent durchzieht und zu den Konsequenzen steht: Die klassische Projektplanung hat dann nicht mehr die Hoheit über die Frage, zu welchem Termin welches Ergebnis vorliegen wird, sondern gibt einen Rahmen vor: "Wann soll welches Ergebnis fertig sein?"

Dann ist die Rückkopplung von den agilen Teams zur Projektplanung aber sehr wichtig?

Ja, und da gibt es häufig noch Nachholbedarf. Wenn auf der Arbeitsebene geplante Ergebnisse noch nicht da sind oder aktuelle Schätzungen auf neue Werte kommen, muss in der klassischen Welt der Rahmen neu angepasst werden. Weitere Möglichkeit: Man zieht Scrum nicht richtig streng durch. Man bricht das Projekt herunter bis zur Anforderungsebene und gibt diese Planung inklusive der zugewiesenen Kapazitäten in die agilen Teams. Diese schätzen die Stundenaufwände für die To-Dos und melden sie zurück. Dann kann die Projektleitung schon eine recht genaue Terminplanung machen. Danach geht es normal weiter, es wird agil umgesetzt und regelmäßig zurückgemeldet. Wenn größere Abweichungen festgestellt werden, wird die Planung angepasst.

Das klingt aber doch nach einem für den klassischen Projektleiter etwas schmerzhaften Abschied von der Planungsgenauigkeit.

Das scheint im ersten Moment tatsächlich so zu sein, doch in Wirklichkeit ist der Unterschied gar nicht so groß. Denn das, was heute oft fälschlicherweise als "Planung" tituliert wird, ist in Wirklichkeit nichts anderes als eine grobe Strukturierung des Projektes mit zeitlicher Reihenfolge und Abhängigkeiten. Auch im klassischen Projekt ist nicht determiniert, was wann herauskommt, und es wird ja durchaus beobachtet und reflektiert, was in der Gegenwart passiert und die Planung entsprechend angepasst. Mit der Akzeptanz des agilen Vorgehens auf der Arbeitsebene wird die Planung ehrlicher. Der klassische Plan gilt nicht mehr als "Wahrsager", der scheinbar die Zukunft kennt, sondern als Zeitsetzer und Budgetgeber.

Was bedeutet das für die Organisation und für die Rollen im Projekt?

Nach meiner Beobachtung stellt sich die IT in vielen Projekten als "Blackbox" dar und das kann man konsequent auf alle anderen Bereiche übertragen: Es werden Termine für Ergebnisse vereinbart, alles andere geschieht auf der Arbeitsebene. Eine noch häufigere Lösung ist die, dass die Projektleitung auf beiden Ebenen führt, aber eben nach unterschiedlichen Konzepten. Sie hat einen klassischen Rahmenplan, um etwa das Reporting zu gewährleisten. Und gleichzeitig arbeitet sie mit ihrem Team am agilen Board. Die Projektleitung ist gleichzeitig Sender und Empfänger der Informationen. Sie steuert auf der klassischen Ebene, indem sie ihr Projekt abstimmt gegenüber anderen Teams, und auf der Mikroebene als agiler Scrummaster des eigenen Projektteams.

Im agilen Konzept spielt die intensive Kommunikation der Teammitglieder untereinander, aber auch mit dem Auftraggeber, dem Project Owner, eine wichtige Rolle. Wie wichtig ist die starke Präsenz des Anforderers bei der Entwicklung der Ergebnisse in einem Mikro-Makro-Umfeld?

Das ist im Grunde der tatsächliche Paradigmenwechsel: dass der Anforderer Mitverantwortung übernimmt und eine aktive Rolle bei der Umsetzung spielt. Aber andererseits ist das nicht so neu, wie es zunächst klingen mag! Denn was passiert in klassischen Projekten? Da wird ein Fachkonzept geschrieben, zunächst auf grober Ebene und teilweise umgesetzt. Bevor man in die Details geht, holt man auch hier den Auftraggeber wieder mit ins Boot. Stellt sich jetzt heraus, dass es aufwendiger wird als geplant, hat das klassische Projektmanagement allerdings ein Problem: Das fest geplante Budget und die ebenso fest verplanten Termine stimmen nicht mehr. Die Planung muss angepasst werden, es gibt

Stress. Genau das wird aufgebrochen, wenn man nicht alles schon festlegt, sondern bewusst nur einen Rahmen vorgibt und die einzelnen Themen umsetzungsnah konkretisiert. Projekt und Auftraggeber müssen ihre Ressourcen dann nicht in einen komplizierten Change-Prozess und in Budgetfragen stecken, sondern können inhaltlich arbeiten. Das ist eine entscheidende Verbesserung!

… und eine Veränderung der Projektkultur. Im klassischen Projekt ist es ja etwas peinlich, wenn man in der Realisierungsphase sagt: "Ich brauche jetzt den Auftraggeber."

Einerseits ja, und das hängt nicht zuletzt mit der Angst zusammen, der Auftraggeber könnte auf neue Ideen kommen und diese einbringen. Man muss sich ja an seine Termine halten. Andererseits findet über die "Quality Gates" ja auch in der klassischen Planung ein rollierender Prozess statt: Man definiert Abschnitte, an deren Ende man den Auftraggeber involviert. Es gilt hier wieder: In der Praxis sind die beiden Philosophien in vielen Punkten nah beieinander. Deswegen bin ich sehr zuversichtlich, dass sie sich immer mehr vermischen werden.

Was muss die Projektmanagement-Software können, um diese Zusammenarbeit zu ermöglichen?

Erfreulicherweise ist man nicht darauf angewiesen, eine Software zu suchen, die alles kann. Man kann in den unterschiedlichen Welten durchaus unterschiedliche Tools einsetzen. Auf Ebene der Vorgaben, Prozesse, Controlling etc. ist eine Multiprojektmanagement-Lösung wie unser Blue Ant optimal. Auf der Arbeitsebene gibt es ganz unterschiedliche Möglichkeiten: Man kann mit To-Dos und Checklisten arbeiten, die Aufgaben mit einem Ticketsystem wie JIRA verwalten, ein elektronisches Kanbanboard verwenden. Manche ziehen auf der untersten Ebene die Papierform vor: Sie drucken sich die Kanbankarten aus, hängen sie an die Pinnwand und arbeiten damit. Natürlich ist die Rückkopplung zum PM-System sicherzustellen. Wird mit Papier gearbeitet, ist der Medienbruch händisch zu überbrücken, ansonsten über elektronische Schnittstellen.

Haben Sie den Eindruck, dass hybride Mikro-Makro-Konzepte auf dem Vormarsch sind?

Ja, definitiv. Denn immer wieder führen die Unternehmen eine PM-Software ein, vielleicht noch ein spezielles Ressourcenmanagement, und hoffen, dass damit alle Probleme gelöst sind. Doch dann klappt es auf der Tagesebene wieder nicht. Dann behelfen sich die Leute oft einfach selbst mit agilen Methoden wie Kanbanboards und schließlich kommt es zur offiziellen Einführung agiler Methoden. Das erleben dann viele als eine Art "Heiliger Gral des Zeitmanagements": eine kluge Verbindung von klassischem und agilem Projektmanagement, mit der das Planen und Steuern tatsächlich klappt.

Herr Frischmuth, vielen Dank für das Gespräch.

Das Interview führte Elisabeth Wagner

 

Bewertungen und Kommentare

(nur angemeldete Benutzer)

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
Gesamt
Bewertungen 0
Alle anzeigen