In den beiden vorherigen Beiträgen wurde darauf eingegangen, dass die Definition eines realistischen Projektzieles unerlässlich ist. Des Weiteren wurde erwähnt, dass im Vorfeld der Projektkurs „beschickt“ werden muss. Das bedeutet, dass Gegebenheiten, die das Projekt vom Kurs abbringen könnten bereits im Vorfeld in Betracht gezogen werden sollten.
Lassen Sie mich wieder die Analogie des Segelns aufgreifen. Der Ausgangspunkt ist gegeben, das Ziel ist definiert (Projektauftrag), die aktuellen Ressourcen und die Wetterlage (Einschränkungen) wurden berücksichtigt. Die Planung des Törns in der Seekarte beginnt. Ausgehend von den navigatorischen Gegebenheiten wird der Kurs abgesteckt und beschickt. Zum geplanten Zeitpunkt verlässt das Schiff den Hafen – das Projekt beginnt.
Während der Fahrt überprüft der Skipper in regelmäßigen Intervallen auf der Seekarte, ob sich das Schiff noch auf dem geplanten Kurs befindet. Plan und Ist werden gegenüber gestellt. Ist das Schiff vom geplanten Kurs abgekommen, ist die aktuelle Position von entscheidender Bedeutung. Befindet sich das Schiff in einer sicheren Umgebung oder droht Gefahr, z. B. durch eine Untiefe oder eines Wetterwechsels. In jeden Fall wird der erfahrene Skipper keine voreiligen Schlüsse ziehen und in Aktionismus verfallen. Bei aufziehender Gefahr hat der Skipper diese in der Regel im Vorfeld als potenzielles Risiko mit möglichen Gegenmaßnahmen identifiziert. In Abhängigkeit der Situation werden seine Prüfintervalle entsprechend kurz getaktet.
Der geplante Kurs wurde verlassen, das Schiff befindet sich in der Nähe einer Untiefe. Abgesehen davon, dass diese Situation in jedem Fall der Skipper / Projektmanager zu verantworten hat, wird als erstes die aktuelle Position bestimmt. Sind Sofortmaßnahmen notwendig, werden diese ergriffen. Im weiteren Verlauf erfolgt die Fehleranalyse. Wurde präzise gesteuert? Haben externe bisher unbekannte Einflüsse zum Kurswechsel beigetragen? Ausgehend von diesen Erkenntnissen wird ein neuer Kurs berechnet. In diese Berechnung sollten auf jeden Fall die gewonnenen Erkenntnisse mit einfließen. Der Kurs zum Ziel wird somit einem kontinuierlichen Verbesserungsprozess unterzogen.
Was bedeutet das aber für das Projektmanagement? In dem von mir skizzierten Szenario wird der Controlling Prozess im Projekt beschrieben. Damit jedoch der Controlling Prozess durchgeführt werden kann, ist der Planungsprozess als Grundlage von entscheidender Bedeutung.
Planung
Bezogen auf das oben skizzierte Szenario wird die Brücke zum Projektmanagement geschlagen. Der Projektmanager ist der Situation ausgesetzt, dass das in dem Projektauftrag definierte Ziel u. U. nicht wie gewünscht erreicht werden kann. Dieses ist eine typische Situation sobald der grob überschlagene Business Case weiter spezifiziert und berechnet wird. In diesem Fall lotet der Projektmanager Möglichkeiten aus, wie das definierte Ziel erreicht werden kann. Er stellt aktiv Lösungsvorschläge vor. Der Projektmanager erarbeitet basierend auf seiner Erfahrung einen validen Projektmanagementplan. Dabei berücksichtigt er die unterschiedlichsten Projektbereiche. Ein erfahrener Projektmanager wird jeden Bereich bewusst berücksichtigen oder aber bewusst ausschließen. Bei unerfahreneren Projektmanagern besteht die Gefahr, dass sie die einzelnen Bereiche vermischen und sich dessen nicht bewusst sind. Folgende Projektbereiche sollten mindestens berücksichtigt werden:
- Projektumfang: Aufnahme der Anforderungen und Definition des Projektumfanges. In dem beschriebenen Szenario existiert die Anforderung, dass der Zielhafen B auf einem möglichst direkten Weg erreicht werden soll. Der Projektmanager leitet aus den Anforderungen Arbeitspakete ab, die im weiteren Verlauf mit den zur Verfügung stehenden Personen besetzt werden. Z. B. Das Arbeitspaket Steuermann, Navigator oder auch Koch.
- Zeit: Aufstellen des Zeitplanes, Planung der Reisezeit mit den einzelnen Meilensteinen. In der Regel wird in diesem Bereich ein Netzplan erstellt, der die zuvor identifizierten Aktivitäten sequenziell verknüpft und mit einer Dauer belegt. In dem vorliegenden Beispiel kann der geplante Kurs in der Seekarte sehr gut mit dem Netzplan verglichen werden. Er enthält einen Start- und einen Endpunkt. Dazwischen existieren einzelne Kurse die mit Aktivitäten verglichen werden können. Meilensteine können z. B. wichtige Positionen sein, die es zu erreichen gilt. Des Weiteren enthält jeder Kurs Zielpositionen mit Zeitangaben.
Sehr häufig wird das Ergebnis dieses Bereiches fälschlicher Weise als Projektplan bezeichnet. Der Zeitplan ist nur ein Teil des Projektplans. - Kosten: In diesem Bereich werden die zur Verfügung stehenden monetären Mittel geplant. In dem vorgestellten Beispiel wird dieser Bereich nicht aktiv angesprochen.
- Qualität: Die Qualität definiert sich als Grad der Befriedigung der Anforderungen. Neben der Anforderung den Zielhafen zu erreichen, besteht die Anforderung, diesen auf einem direkten Kurs zu erreichen. Somit kann gefolgert werden, dass die Qualität des Projektes umso besser ist, je direkter der Weg zum geplanten Zielhafen verläuft. Siehe Hundekurve.
- Human Resources: Das Team und der Projektleiter sind gegeben. Der Projektleiter wird sich überlegen wie er sein Team effizient einsetzt und das vorhandene Wissen nutzt und ausbaut. Er wird sein Team entsprechend der im Bereich „Projektumfang“ definierten Arbeitspakete einsetzen. Bei Bedarf wird er Wissen und Erfahrung transferieren, damit die eingesetzten Teammitglieder ihre Aufgaben angemessen erfüllen können.
- Kommunikation: Wird die Kommunikation auf einer Metaebene betrachtet, sind Parallelen zum Projekt erkennbar Zwar wird der Skipper keine PowerPoint-Folien verwenden, um das Team zu informieren, wo sich das Schiff vor 10 Minuten befand. Fakt ist, dass das Team in regelmäßigen Intervallen mit Informationen versorgt wird. Dabei werden die vorhandenen Informationsdaten empfängerrelevant aufbereitet. Das Team / Management wird Informationen zum aktuellen Status und eine Prognose erhalten.
- Risikomanagement: Gerade bei Sportarten, die zwingend vom Wetter abhängig sind, ist ein angemessenes Risikomanagement essentiell. Vor dem Start werden die Risiken gesammelt und bewertet. Dabei wird jedes identifizierte Risiko auf seine Eintrittswahrscheinlichkeit und deren Auswirkung betrachtet. Potenzielle Gegenmaßnahmen werden definiert. Vom Ergebnis der Risikobewertung hängt das weitere Projektvorgehen ab.
- Zu guter Letzt sollte das Stakeholdermanagement nicht vernachlässigt werden. Stakeholder sind alle vom Projekt direkt und indirekt betroffenen Personen. In dem skizzierten Szenario sind es gleichermaßen Teammitglieder, wie z. B. auch Angehörige der Teammitglieder. Für den Skipper ist es wichtig zu sehen, welche Positionen die Stakeholder einnehmen. Dabei muss er sich Fragen stellen wie, ist die Person ein Unterstützer meines Projektes, arbeitet sie gegen mich oder ist es wichtig sie zu informieren
Die in den genannten Bereichen definierten Vereinbarungen werden von den Sponsoren (Team) verabschiedet und als Baseline fixiert. Das Controlling erfolgt gegen die vereinbarten Baselines. Z. B. Wurde anstatt des Hafens B der Hafen C erreicht. In diesem Fall wurde das Ziel (die Baseline Hafen C) des Projektumfanges nicht erfolgreich erreicht.
Durchführung, Monitoring und Controlling
Während der Durchführung werden Daten zum aktuellen Projektstatus erzeugt. Diese sind die Grundlage für das Monitoring und Controlling. Sie werden als Ist-Daten in definierten Intervallen gegen die Soll-Daten, basierend auf den Baselines der unterschiedlichen Bereiche, verglichen. In Abhängigkeit der Kritikalität der Projektsituation erfolgt das Controlling der einzelnen Bereiche intensiver oder weniger intensiv. Basierend auf dem Controlling können Abweichungen schnell festgestellt werden. Der Projektleiter ist verantwortlich diese zu bewerten und wenn erforderlich Gegenmaßnahmen zu ergreifen.
Im obigen Bsp. wird die Situation beschrieben, dass ein potenzielles Risiko eintritt. Basierend auf der Risikoplanung werden Gegenmaßnahmen ergriffen. Stellt sich heraus, dass die Auswirkungen des eingetretenen Risikos umfangreicher sind, als die Reserven, die in der Planung berücksichtigt wurden, ist die Planung zu ändern. Dieses sollte aus formaler Sicht mit einem Change Request (CR) durchgeführt werden. Die Sponsoren geben diesen frei. Bisher habe ich es des Öfteren erlebt, dass in diesen Situationen CRs, wenn sie denn gestellt werden, nicht oder nicht ausreichend dokumentiert werden. Das ist in sofern unglücklich, da ein wichtiger Erfahrungswert verloren geht und die Gefahr besteht, einen Fehler zu wiederholen. Ein aus meiner Sicht sehr wertvolles Werkzeug ist die Retroperspektive, auch Lessons Learned genannt. Gerade in Situationen, in denen der Projektverlauf sehr herausfordernd war, sollten wichtige Erkenntnis dokumentiert werden. Ein entsprechendes Meeting für die Retroperspektive muss keinesfalls im großen Rahmen durchgeführt werden. Das Meeting wird mit einem ausgesuchten Personenkreis durchgeführt. Eine kurze und knackige Analyse verbunden mit einem strukturierten Vorgehen kann sehr produktive Erkenntnisse hervorbringen.
Neben der Feststellung, dass der Erfahrungsgewinn wesentlich zum Erfolg des weiteren Projektverlaufes beiträgt, führen zwei weitere Punkte zum Projekterfolg. Das sogenannte Fingerpointing „Er ist es gewesen!“ ist kontraproduktiv. Fakt ist, der Projektmanager ist verantwortlich! Daher ist es seine Aufgabe dafür Sorge zu tragen, dass eine entsprechende Situation nicht eintritt und wenn sie eingetreten ist, alles daran zu setzen, dass sie nicht wieder eintritt. Der nächste Punkt ist das Krisenmanagement. Im Bereich der Luftfahrt existiert ein Modell, welches sich auch zunehmend in der Schifffahrt durchsetzt. PSOBAK beschreibt ein standardisiertes Vorgehen, wie das Krisenmanagement durchgeführt werden soll. Dabei ist der Kapitän zwar für die zu treffende Entscheidung und deren Auswirkungen verantwortlich, er bezieht aber aktiv sein Team in die Entscheidungsfindung mit ein. Da die detaillierte Beschreibung dieses Vorgehens den Beitrag sprengen würde, werde ich zu dieser Methode einen eigenen Beitrag veröffentlichen.
Nachdem die kritische Situation ausgestanden ist, erfolgt der weitere Projektverlauf mit dem aktualisierten Plan bis das Projektziel erreicht wurde.
Fazit
In dem von mir dargestellten Szenario werden sämtliche relevanten Bereiche des Projektmanagements identifiziert. Meine Erfahrung hat mich gelehrt, dass sehr häufig die Tücken in einer unzulänglichen Planung und in impliziten Annahmen liegen.
Mit der unzulänglichen Planung meine ich nicht, dass eine Software komplett durchspezifiziert werden muss, bevor die erste Zeile Quellcode geschrieben wird. Das Vorgehen der Rolling Wave Planung (iterative Vorgehen, die Planung wird im Projektverlauf sukzessiv aktualisiert und verfeinert) ist z. B. durchaus opportun und sehr effizient. Wichtig ist, dass der Projektmanager im Vorfeld die genannten Bereiche (Projektumfang, Zeit, Kosten, Qualität, Human Ressources, Kommunikation, Risikomanagement und Stakeholdermanagemt) aktiv betrachtet und plant wie er mit diesen umgeht. Dabei ist es durchaus legitim, einzelne Bereiche nur rudimentär zu planen oder sogar auszuschließen, weil diese für das jeweilige Projekt nicht relevant sind.
Implizite Annahmen, die als gegeben betrachtet und nicht näher spezifiziert werden, haben zur Folge, dass am Projekt beteiligte Personen häufig unterschiedliche und nicht ausgesprochene Erwartungshaltungen haben. Sobald das Projekt sich in der Durchführung befindet treten diese Schwachstellen in Form von Konflikten zu Tage. Diese Herausforderungen zu lösen kostet viel Energie und Zeit.
Fakt ist, dass der Projektmanager aktiv und wissentlich seine Entscheidung treffen muss. Nur dann kann er Verantwortung übernehmen und verfügt über die Kompetenz in Krisensituationen die Ursachen zu lokalisieren und diese aktiv zu beheben. Das ist einer der wesentliche Unterschiede und Erfolgsfaktoren gegenüber Projektmanagern die viel Aufwand betreiben, um Symptome zu bekämpfen aber keine Ressourcen für deren Ursachenbeseitigung mehr zur Verfügung haben.
Zum Schluss des Beitrages merke ich an, dass ich mich bei den aufgezählten Bereichen am Vorgehen des PMP® Standards vom PMI® (Project Management Institute) orientiert habe. Im aktuellen Standard existiert noch ein weiterer Bereich, die Beschaffung. Diesen habe ich bewusst weggelassen, da er mir für das skizzierte Szenario nicht relevant erschien.
Friedrich Behnk
