Agiler Wasserfall im Multi-Projektmanagement: So klappt’s!

Das vorliegende Whitepaper zeigt auf, wie Unternehmen das klassische und das agile Vorgehen im Sinne des Multi-Projektmanagements sinnvoll kombinieren und so viele Projekte gleichzeitig bewältigen.

1 Vom Wasserfall zum Tropfen

Sowohl das Einzel- als auch das Multi-Projektmanagement leben von Planung: Es werden Schritte, Ressourcen und Budgets definiert, anhand derer man sein Projekt koordiniert abwickeln kann.

Doch je nach Projekt sind bei dieser Planung weder das klassische Vorgehen im Sinne eines Wasserfall-Modells noch das agile Vorgehen im Sinne von Scrum, Kanban o. a. Modellen förderlich. Denn: Beide Modelle bringen Herausforderungen mit sich. Während beim klassischen Vorgehen ein steifes Korsett eingehalten werden muss, das zudem durch eine konkrete Reihenfolge der Aktivitäten komplex wird, organisiert man sich beim agilen Vorgehen von Tag zu Tag. So mag bei der Software-Entwicklung Agilität hervorragend geeignet sein, bei der Unternehmensplanung aber braucht es die klassische Planung, die nicht auf jedes kleine Detail heruntergebrochen wird.

Doch wieso nicht das Beste aus beiden Welten kombinieren? Das vorliegende Whitepaper zeigt auf, wie Unternehmen das klassische und das agile Vorgehen im Sinne des Multi-Projektmanagements kombinieren und so auch viele Projekte gleichzeitig bewältigen.

 

2 Was und wann: Eine Frage der Perspektive

Die Erfahrung hat gezeigt: Es ist eine Frage der Perspektive, nicht die Frage von falsch und richtig, wann welches Modell zum Einsatz kommen sollte. Langsam hat sich diese Erkenntnis auch bei Projekt- verantwortlichen durchgesetzt. Und noch mehr: Einige haben auch erkannt, dass sich klassische und agile Instrumente kombinieren und Projekte sich damit besser steuern lassen.

Allerdings gilt das nur dann, wenn man die richtige Erwartungshaltung vertritt: Man muss wissen, was agile und klassische Methoden und Planungen leisten können – und auch nur das von ihnen fordern.

 

3 Exkurs: Multi-Projektmanagement

Das Multi-Projektmanagement hat, wie der Name bereits verrät, eine Aufgabe: mehrere Projekte parallel zu stemmen bzw. den Rahmen dafür bereitzustellen. Hierfür werden verschiedene Ordnungswelten geschaffen.

Projekt
Es bedarf mehrerer Fachbere- iche oder Abteilungen, um ein Ziel zu erreichen. Dieses Ziel wird über Zeit-, Kosten- und Qualitätsanforderungen definiert.

Programm
Sämtliche zeitlich befristeten Einzelprojekte und Maßnah- men, die auf ein Ziel hinarbe- iten, werden unter einem Programm zusammengefasst.

Portfolio
Ein Portfolio ist eine Zusam- menfassung von Projekten und Programmen, die bei der längerfristigen Entwicklung und Umsetzung einer Unternehmensstrategie helfen.

Mehr zum Multi-Projektmanagement lesen Sie auch im gleichnamigen Whitepaper.

 

4 Multi-Projektmanagement mit der „Kombi-Lösung“

4.1. Ebenen und Flughöhen
Bevor losgelegt werden kann, müssen zunächst Flughöhen und Ebenen definiert werden, in denen dann jeweils entweder die klassische oder die agile Methode wirken kann.

So ist es beim Multi-Projektmanagement zum Beispiel der Fall, dass es zunächst keine inhaltliche Berührung mit Projektthemen gibt, sondern die Basis definiert wird, die geschaffen werden muss. Es gilt folglich zunächst, den Rahmen zu schaffen, in dem sich die verschiedenen Projekte bewegen.

Dieser Rahmen kann bestehen aus
- Ressourcen,
- Priorisierung,
- Budget,
- Struktur.

Dieser Rahmen hat zunächst einmal nichts mit den Projektzielen zu tun – und auch nicht mit den Projektinhalten. Er bietet im Grunde das Spielfeld, auf dem dann Projekte die Bälle schieben. Diese Projekte wiederum liefern Informationen zu Wirtschaftlichkeit, Terminen und Risiken, die den Rahmen gefährden könnten. So entsteht ein kleiner Kreislauf mit sehr hoher Flughöhe.

Die Projekte selbst hingegen können entweder grob oder sehr feingranular geplant werden. Doch entscheidend ist die Mikro-Ebene, also die Arbeitswelt bzw. Tagesorganisation der Menschen, die ihre Themen umsetzen – und das oftmals agil.

4.2 Vorteile aus beiden Welten zu nutzen wissen
Der Rahmen des Multi-Projektmanagements unterteilt Projekte beispielsweise entlang ihrer Größe und Bedeutung in Programme, Projekte und Maßnahmen. Für jede Kategorie wird ein Ablauf festgelegt, der definiert, wie aus einer Idee ein Projektziel und später einer Projektplan zu entwickeln ist. Zudem werden Entscheider benannt, die dafür Sorge tragen, dass nur inhaltlich geklärte und mit einer validen Planung und Ressourcendecke ausgestattete Projekte umgesetzt werden dürfen.

In der eigentlichen Umsetzungsphase stehen sich diese Einzelprojekte nun gegenüber – und sind vor allem auf ihren eigenen Erfolg fixiert. Jedes Projekt versucht jetzt, seine Vorgaben umzusetzen, greift dabei allerdings auf dieselben Ressourcen zurück. Damit entsteht ein natürlicher Konflikt, den Projekte nicht lösen können. Gerade in einem agilen Arbeitsumfeld wird es dann schwierig. Hier herrscht der Gedanke eines stabilen Teams vor. Die klassische Planung hilft uns allerdings auch nicht weiter, da sich mit ihr die täglichen Neu-Priorisierungen nicht planen und steuern lassen.

Wie können wir dieses Dilemma lösen? Durch eine Kombination!
Im Grunde steht hier zunächst eine wichtige Überlegung auf dem Plan: Wie wird die Ressourcenzuweisung in der Planung verankert, ohne dass man sich in Details verliert? Das wird am besten gelöst, indem man auf der Projektebene die Vorteile der klassischen und der agilen Welt greift und an unterschiedlichen Stellen anwendet. Dies kann so aussehen, dass das klassische Management vorgibt, welche Rahmen zur Verfügung stehen. Das agile Management ist dann für die Ausgestaltung zuständig.

5 Multi-Projektmanagement: Klassisch und agil

Das Multi-Projektmanagement ist prädestiniert, um hier klassisch und gleichzeitig agil vorzugehen, denn meist sind zu viele Themen parallel und oftmals über einen längeren Zeitraum hinweg zu bearbeiten. Würde man hier nur die agile Vorgehensweise einsetzen, würde man sich aller Wahrscheinlichkeit nach in der Vielzahl der Themen verlieren und bald an Grenzen hinsichtlich Ressourcen und Budgets stoßen.

Bricht man aber die Vorgaben, die gesetzt wurden, nach der klassischen Art herunter, können wir Projekte grundsätzlich strukturieren und dann agil fortfahren.

a) Strukturieren
Ein Projekt wird in Phasen, Anforderungsblöcke oder Epics zerlegt. Somit gäbe es bspw. die Phase 1 „Analyse“, die Phase 2 „Konzeption“ und Phase 3 „Realisierung“.

b) Priorisieren
Nun können Phasen nach strategischen Gesichtspunkten priorisiert und zudem Budgets und Ressourcen zugeteilt werden. Dafür ist die Kenntnis spezifischer Projektdetails erstmal nicht wichtig, es geht rein um die Vorgaben. Weiß ich, dass es in Phase 1 zu Verschiebungen kommt, ist ohnehin klar: Diese muss ich auch bei Phase 2 und 3 berücksichtigen.

c) Verbinden und rückkoppeln
Anhand der erfassten Vorgaben kann nun die Mikro-Ebene, also in die tägliche Arbeitswelt, einbezogen werden. Sie organisiert sich selbst agil und erfasst alle für eine erfolgreiche Umsetzung erforderliche Informationen. Die Summe der Aufwände wird dann wieder an die klassische Ebene zurück kommuniziert.

Auf diese Weise entsteht ein Geben und Nehmen: Die Mikro-Ebene organisiert sich autark innerhalb der gesetzten Rahmen, also in zeitlichen oder Anforderungsvorgaben der klassischen Ebene. Sie bewegt sich per Sprint fort und berichtet parallel an die klassische Ebene, wie es um Aufwände, Kapazitäten oder Fortschritte bestellt ist. Diese Information kann dann für eine eventuelle Anpassung der Phasen genutzt werden, ohne, dass man sich in das operative Zeitmanagement der Mikro-Ebene einmischen müsste.

Wichtig: Niemals in Mini-Arbeitspaketen und Abhängigkeiten verlieren! Die klassische Ebene steckt den Rahmen, gibt die Komplexität und die Feinplanung dann aber in die Arbeitswelt weiter. Das genügt auch zur Absicherung von bspw. Deadlines: Die agile Welt kennt die Vorgaben und Rahmenbedingungen und weiß, dass sie sich nicht evtl. schönen, aber unwichtigen Details widmen darf, bis die Mindestanforderungen erfüllt sind.

5.1. Technologischer Rahmen
Das beschriebene Vorgehen bedeutet auch, dass man sich in zwei unterschiedlichen Werkzeugwelten organisieren kann. So ist es bspw. möglich, in der klassischen Planung auf Blue Ant zu setzen, die wöchentliche, agile Planung dann aber in der Papierwelt und an einer Pinnwand durchführt. Gerade Letzteres hat teilweise eine besonders hohe Verbindlichkeit.

Alternativ kann Blue Ant auch für die klassische Planung genutzt werden, während in Jira Scrum gelebt wird. Die höhere Ebene nutzt also Blue Ant für die Aktivitäten, die Arbeitsebene Jira für die Todos. Mittels Schnittstelle werden diese Informationen verknüpft und stetig synchronisiert. Werden innerhalb Blue Ants also zum Beispiel Termine verschoben, werden automatisch neue Endtermine in Jira ausgegeben.

Eine weitere Möglichkeit besteht in der Kombination von klassischer Planung und der Verwendung elektronischer Kanban-Boards für die Arbeitsorganisation innerhalb von Blue Ant. Blue Ant bietet hierfür eine ideale Verknüpfung von Aktivitätenplanung und Todo-Handling unter einer Oberfläche.

6 Fazit

Die „Kombi-Lösung“ bringt erhebliche Vorteile für das Multi-Projektmanagement. So bleibt der Überblick über Programm und Portfolio bewahrt und die neugewonnene Abstraktheit bringt Ruhe in das sonst so unruhige Tagesgeschäft. Die agile Welt kann sicher sein, dass nicht täglich neue Anforderungen gesetzt oder bestehende Zeitrahmen umgeworfen werden, Budgets und Termine bleiben stabil. Alles, was sich auf der Mikro-Ebene ändert, wird durch das Team eigenverantwortlich bestimmt: Was die Ressource „Arbeitskraft“ wirklich macht, plant die Mikro-Ebene von Sprint zu Sprint oder von Woche zu Woche.

Außerdem erlaubt das kombinierte Vorgehen ein verbessertes Reporting: Zwar ist auf der Makro-Ebene nicht immer klar, welche Tätigkeiten am nächsten Tag auf der Agenda der Mikro-Ebene stehen, doch das muss auch nicht sein. Auf klassischer Ebene grundsätzliche Themen, deren Reihenfolge der Abarbeitung, Ressourcen sowie Budgets festzulegen und die Einhaltung zu monitoren, genügt. Denn die Informationen über Kosten und Aufwände werden auf Projektebene geschaffen. Sollten dann Detailfragen anstehen, wieso zum Beispiel die Einhaltung der Deadline gefährdet ist, ist die Mikro-Ebene die richtige Anlaufstelle. Statusdaten können so in Echtzeit erhoben werden und spiegeln die gelebte Situation in den Projekten und damit im Programm und Portfolio wider.

Die klassischen und agilen Welten befruchten sich also gegenseitig: Projekte werden besser bewältigt, ohne dass jemand gegängelt oder durch zu viele Details überfordert wird.

 

Read it again

Download PDF-Version zum Teilen oder in Ruhe Lesen.

DOWNLOAD PDF