PM Toolbox maxi

PM Toolbox "maxi"

Je größer und komplexer die Projekte sind, desto größer ist das dafür benötigte Budget und der Ressourcenbedarf. Damit verbunden ist eine besonders hohe Verantwortung des Projektleiters und des gesamten Teams an ein besonders sorgfältiges Management dieser Großprojekte und Ressourcen. Projektmanagement Dokumente sind ein Werkzeug dafür. Da im Vergleich zu kleinen Projekten zusätzliche Themenfelder bei Großprojekten relevant werden (z.B. Stakeholder Management, Risk Management, Programm Management) und auch vorhandene Dokumente der relativ einfachen "mini"-Toolbox für Großprojekte nicht ausreichend sind, rate ich zu einer Differenzierung der Projektmanagement-Toolboxen für Klein-Projekte und Groß-Projekte. Eine einfache Ergänzung der Toolbox "mini" um die zusätzlich erforderlichen Dokumente für Großprojekte wird der Komplexität von Großprojekten nicht gerecht und reicht bei Weitem nicht aus. Aber zunächst zu der Frage:

Was ist ein Großprojekt?

Es gibt bestimmte Faktoren, die zur Bestimmung der Projektkategorien gebräuchlich sind. Dies sind Budgetbedarf, Grad der Abhängigkeiten, Ressourcenbedarf, Projektrisiken, Bedeutung für die Umsetzung der Unternehmensstrategie, Projektdauer und Projektkomplexität. Die Grenzwerte sind unternehmensindividuell anzupassen. Das Beispiel in dem unteren Bild eignet sich für kleinere und mittelständische Unternehmen (KMU). 

Die Faktoren werden gewichtet und mit einem Punktesystem belegt, so dass der gewichtete Durchschnitt letztendlich zur Projektkategorie führt und richtungsweisend für den Umfang der Projektdokumentation ist. Typischerweise wird der Faktor "Budget" sehr hoch gewichtet. Die Gewichtung kann jedoch angepasst werden. Bei sehr knappen Ressourcen könnte das Kriterium "Ressourcenbedarf" in der Gewichtung erhöht werden. Im u.a. Beispiel kann die komplexeste Ausprägung eines Großprojektes 10 Punkte erreichen. Ein kleines Projekt wird mit einem Punkt bewertet, was ebenfalls der Relation der benötigten Budgets entspricht (50.000 EUR / 500.000 EUR).

Projektablage & Dokumentation: Im Rahmen eines Globalen PMO oder auch für alle Projekte innerhalb eines Programms sollte eine Projektmanagement-Ablage mit einer standardisierten und vorgegebenen Struktur geschaffen werden, damit wichtige Unterlage schnell gefunden werden können. Der Umfang der vorgegebenen Struktur richtet sich nach der Komplexität der Projekte, aber auch nach der Sensibilität von Daten. Wenn Informationen nur für wenige Personen transparent sein sollen, muss ein separater Ordner mit einer angepassten Zugriffsberechtigung angelegt werden. Die folgende Struktur ist ein Beispiel:

00_Projektmanagement Global
      (Projekt Charter, Terminplan, Organisation, Stakeholder Management, Risiko Manage-
      ment, ggf. Statement of Work, Vereinbarungen mit externen Dienstleistern, etc.)
01_Projektkonzeption (Scoping, Proof of Value) 
02_Jour Fix Teammeetings 
03_Steuerkreis und Gremienpräsentationen 
04_Controlling (Business Case, Budget, Ressourcen)
05_Kommunikation
06_Sub Projekt 1
07_Sub Projekt 2
08_Sub Projekt 3
...
20_Projekt Abschluss

Toolbox "maxi"

2 I Definition Arbeitspakete / Module / (Sub-) Projekte: Da ein Großprojekt in den meisten Fällen aus mehreren (Sub-) Projekten oder Modulen besteht, reicht die Erstellung eines Projekt Charters für das Gesamtprojekt nicht aus. Es ist darüber hinaus wichtig, zu Beginn des Projektes die einzelnen Projekt Module konkret zu definieren. Die Bestimmung des Leistungsbereichs ("scope-in/scope-out"), der Sub Projekt Ziele ("Objectives) und der dazugehörigen Leistungsergebnisse ("deliverables") sind zu definieren und zu terminieren, damit im späteren Projektverlauf das Modulcontrolling darauf aufsetzen kann.

3 I Projekt Organisation: Für Großprojekte eignet sich tatsächlich auch die Projektorganisation aus der "mini"-Toolbox. Hier ist jedoch darauf zu achten, dass die Funktion 'Change- & Communication Management' für Großprojekte aktiv besetzt wird. Ein Großprojekt ohne 'Change- & Communication Management' hat ein hohes Risiko zu scheitern. Darüber hinaus ist zu überlegen, ob zusätzlich zu den definierten Gremien sogenannte 'Sounding Boards' eingerichtet werden, um regelmäßig den Input und das Feedback von Experten oder betroffenen Personen zu bekommen. 

4 I Business Case & Kosten Controlling: Während sich der Business Case für Klein-Projekte [D] auf eine einfache Darstellung der Vorteilhaftigkeit beschränken kann, sind bei Großprojekten [A] in den meisten Fällen mehrere Finanz-KPIs relevant, die getrackt werden müssen, wie zum Beispiel: Umsatzwachstum, EBIT Verbesserung, Implementierungskosten, CAPEX, Working Capital, Free Cash Flow, direkte/indirekte Personalkosten oder Anzahl Mitarbeiter (Headcount). Dies erfordert einen komplexen Business Case, der nur zusammen mit dem Projektcontrolling erstellt und regelmäßig hinsichtlich der aktuellen Monatswerte aktualisiert werden sollte. Für Projekte einer mittleren Größe [B, C] sollte ein etwas schlanker Business Case reichen. Die relevanten Finanz-KPIs sollten monatlich getrackt werden (ACT versus PLAN). Mindestens quartalsweise sollte der Forecast überprüft werden.

5 I Projekt Plan: Es gibt eine Vielzahl von Projektmanagement Software Lösungen, mit denen Gantt-Charts generiert werden können. Weit verbreitet sind Microsoft Project, Agannty, Asana oder monday.com. Wenn keine Software Lösung im Einsatz ist, kann auch ein entsprechender Projektplan in Excel erstellt werden. Wichtig ist hier die übersichtliche Planung der einzelnen WBS (Work Breakdown Structure). Neben den Plan-Start und Plan-End Daten sollte ein Forecast vorhanden sein, so dass Abweichungen zum Plan sofort erkennbar sind. Ebenfalls nicht fehlen sollte der Erfüllungsgrad (Degree of Implementation) oder Fortschritt in % zu jedem Arbeitspaket, um anzuzeigen, ob der inhaltliche Fortschritt zum Zeitverlauf passt, sowie eine Ampelfunktion. Bei Großprojekte empfiehlt sich eine Projektplanung je Sub Projekt oder Modul.

6 I Stakeholder Management: Gerade bei Großprojekten ist die angemessene Einbindung der Stakeholder wichtig für die erfolgreiche Implementierung des Projektes. Hierzu werden die Stakeholder oder Stakeholder-Gruppen zunächst identifiziert. Wichtig ist, dass die Stakeholder vom gesamten Projektteam identifiziert werden. Zum einen hat das cross-funktionale Projektteam eine breitere Übersicht über die relevanten Stakeholder, zum anderen kann das Projektteam die Motivationen, Erwartungen und Reaktionen der Stakeholder in Bezug auf das Projekt besser einschätzen, da es meistens mindestens eine Person im Team gibt, die den jeweiligen Stakeholder besser kennt und seine Motivation in Bezug auf das Projekt einschätzen kann. Das Team identifiziert zunächst die Stakeholder, analysiert dann deren Einfluss auf das Projekt (von "little influence" bis "without his/her support, the project can fail"), sein/ihr Interesse an dem Projekt (von "negative" bis "active supporter"). Das Team antizipiert die Reaktionen und "pain points" der Stakeholder und ihre Erwartungen an die Einbindung in das Projekt. Schließlich definiert das Projektteam ganz konkrete und terminierte Maßnahmen zu Kommunikation und Einbindung jedes Stakeholders in das Projekt, inklusive eines Verantwortlichen. Die Status der Stakeholder Management Maßnahmen wird in diesem Template regelmäßig getrackt. Es ist Bestandteil der Projektmanagement Dokumente, die in regelmäßigen Abständen in Team Meetings reviewed werden. 

7 I Projekt Status

Gerade bei Großprojekten gibt es hier kein "one size fits all" und in den meisten Fällen sind unterschiedliche Statusreports abhängig von der Zielgruppe geeignet. Zu differenzieren ist hier zum einen der Unterschied zwischen Projekt und Programm. Zum anderen ist die Zielgruppe des Reports und das damit verfolgte Ziel zu beachten. Für eine high-level Gremienpräsentationen kann eine sehr stark vereinfachte Übersicht über den Projekt- oder Programmstatus als "one-pager" ausreichend sein. Auf der Arbeitsebene werden zur Steuerung des Projektes detailliertere Reports benötigt. Diese können sich zum einen auf die Abarbeitung der Arbeitspakete und zum anderen auf den Zielerreichungsgrad der geplanten KPIs beziehen.

7a_Programm Report Overview: In den meisten Fällen ist ein Großprojekt eine Initiative oder ein Programm mit mehreren (Sub-) Projekten. Um hier zunächst einen transparenten Überblick über den Status der in dem Programm aktiven (Sub-) Projekte zu geben, ist ein Dashboard / Overview sinnvoll, in dem der Status der einzelnen (Sub-) Projekte hinsichtlich Zeitplanung, Budget und Zielerreichung sowie aktuelle Aktivitäten und "next steps" kurz und übersichtlich dargestellt werden. Eine solche Übersicht eignet sich als Einstieg zu einer Steuerkreis- oder Gremienpräsentation.

7b_Projekt-/Programm Report Gesamt: Zur Steuerung der Projektarbeit ist ein differenzierter Projekt-/Programm Status notwendig. In wöchentlichen Jour Fixes ist es wichtig, die Terminplanung der laufenden 3-4 Monate und der in diesem Zeitpunkt relevanten Meilensteinen, Workshops und Gremientermine (Steuerkreis, Sounding Boards) im Überblick zu haben, diese im Team zu planen und vorzubereiten. Weiterhin ist ein detailliertes Monitoring der in der vergangenen Woche erfolgten und in der nächsten Woche geplanten Aktivitäten notwendig. Offene Punkte und Risiken werden offen angesprochen und Verantwortliche sowie eine Deadline für die Lösung der Themen definiert. Diese Statusübersicht bezieht sich auf das Gesamtprojekt. 

grün: Verzögerungen bis < 1 Woche 
gelb: Verzögerungen < 3 Wochen und das Projektteam kann selbständig Lösungen
         erarbeiten, um der Verzögerung entgegenzuwirken
rot:   Verzögerungen > 3 Wochen und Entscheidung oder Freigabe im Steuerkreis oder 
        Entscheidungsgremium notwendig

7c_(Sub-) Projekt / Modul Report: Zur differenzierten Steuerung der (Sub-) Projekte oder Projektmodule ist eine Detailsicht auf jedes (Sub-) Projekt notwendig. Hier wird noch einmal detaillierter auf die seit dem letzten Jour Fix erfolgten, die bis zum nächsten Jour Fix geplanten Aktivitäten sowie die identifizierten Projektrisiken und Entscheidungsthemen eingegangen. Kernelement ist jedoch das differenzierte Monitoring der geplanten Projektergebnisse (Deliverables). Hierzu ist es wichtig, dass die Projektergebnisse zu Beginn in der Projektplanungsphase  differenziert geplant wurden, so dass Umsetzung in der Projektimplementierungsphase getrackt werden kann. Eine Verschiebung zum ursprünglichen Plan sollte transparent dargestellt werden. 

7d_Project Dashboards: Zur Visualisierung des Projektstatus und insbesondere der definierten KPIs eignen sich interaktive Projektdashboards. Auch hier gibt es kein "one size fits all". Vielmehr richten sich die auf dem Dashboard darzustellenden Kennzahlen nach den im Projekt definierten KPIs. Empfehlenswert sind Auswertungen hinsichtlich "Timing", "Budget", "Risiko". Je nach Projekt kann auch der bereits erfolgte Ressourcenverbrauch gegenüber Plan dargestellt werden, sowie der Status (PLAN/ACT) weiterer für das Projekt definierter KPIs. Dies können zum Beispiel Umsatz, Einsparungen, Investitionen, Mitarbeiter-entwicklung/-kosten, Bestände, Qualitätskennzahlen, Nutzungsgrad, oder Effizienz-kennzahlen sein. Beispiele zu interaktiven Dashboards zum downloaden sind hier: Dashboards Controlling

8 I Ressourcen Management: Ein wesentlicher Grund, warum Projekte scheitern, ist oft ein fehlendes Ressourcen Management. Personen werden Projekten zugeteilt, ohne die verfügbare Kapazität zu prüfen. Dies passiert sehr häufig in Fachbereichen, die ihre Stunden nicht auf Projekte schreiben müssen. In vielen Unternehmen ist die IT Abteilung eine der wenigen Fachbereiche, die Stunden auf Projekte oder Innenaufträge zurückmelden und somit Transparenz über ihren Ressourcenverbrauch haben. Es gibt eine Vielzahl von Software Lösungen, insbesondere im Bereich Projekt & Programm / Portfolio Management, die software-gestütztes Ressourcen Management anbieten. Ist eine solche Software nicht im Einsatz, so ist es die Aufgabe des Vorgesetzten, die Ressourcenplanung seines Teams zu steuern. Dies kann für eine erste Kapazitätenplanung sehr einfach gemacht werden, indem der Ressourcenbedarf je Mitarbeitet und Aufgabe je Monat grob eingeplant wird. Wichtig ist, dass neben der Kapazitätsplanung auch der Kapazitätsbedarf für "daily work", "ad hoc topics" oder auch "special projects" eingeplant wird. Sofern eine Überlastung erkennbar ist, muss die Ressourcenplanung differenzierter untersucht werden. Eine erste Abschätzung kann jedoch sehr schlank gehalten werden. In u.a. Beispiel wird deutlich, dass Anna W. erst im Juni 2022 mit ihrer Kapazität wieder im Normbereich ist. Zuvor ist sie insbesondere durch Projekt 1 im Jan-März und durch das Special Projekt im April/Mai überbucht. 

9 I Risiko Management: Gerade bei Großprojekten bestehen signifikante Projektrisiken, die zunächst identifiziert und hinsichtlich ihrer Eintrittswahrscheinlichkeit und ihrer Auswirkung bewertet werden müssen. Zu jedem Risiko sollten mindestens eine, im Optimalfall jedoch mehrere Risikominimierungsmaßnahmen (Risk Mitigation Measures) definiert werden, die ebenfalls hinsichtlich ihrer Wirksamkeit zur Bekämpfung des Risikos bewertet werden müssen. Darüber hinaus wird jeweils ein Verantwortlicher sowie eine Deadline zur Umsetzung der Maßnahme definiert. Das Vorhandensein eines Risikominimierungsplans (Risk Mitigation Plan) und seine Umsetzung müssen vom Projektleiter oder vom PMO regelmäßig überprüft werden.

10 I Projekt Change Management (techn.): Wer kennt das nicht: Ein Projekt zieht sich über 2 Jahre und am Ende wundert man sich, dass etwas ganz anderes bei dem Projekt herausgekommen ist, als ursprünglich mal angedacht war. Wenn euch das bekannt vorkommt, dann ist das wahrscheinlich bei Projekten geschehen, deren scope sich schleichend reduziert hat - ohne die Reduzierung des scopes transparent freizugeben. Eine schleichende Änderung des scopes geschieht jedoch in beide Richtungen: Reduzierung und Erhöhung. Beide Änderungen dürfen nicht schleichend und intransparent eingeführt werden, sondern sollten von den relevanten Entscheidern freigegeben werden. Sofern ein Projektmanagement-System im Einsatz ist, geschieht das meistens per Workflow, in dem die geänderte Timeline oder der geänderte Budgetbedarf offiziell freigegeben und somit dokumentiert ist. Sofern kein Projektmanagement System im Einsatz ist, muss dies manuell erfolgen und trotzdem strukturiert dokumentiert erfolgen. Hierbei hilft ein Change Request Approval Template.