Blog | Projektmanagement

Projektabschluss: „Nach dem Spiel ist vor dem Spiel“, sagte Jogi nach dem Desaster gegen England! (Teil 2)

Zu 2.a.i : Nachkalkulation im Kontext der Vor- und Mitkalkulation

Letztens habe ich über einen Bahnkunden gelesen, der auf einen verspäteten Zug wartete. Als ein Schaffner vorbeikam, beschwerte er sich: „Wozu macht die Bahn Pläne, wenn die Züge sowieso immer zu spät kommen?“ Der eloquente Schaffner entgegnete, „Würden wir keine Pläne machen, wüssten wir nicht ob unsere Züge zu spät kommen“.

Pläne sind also zu etwas gut, auch wenn sie nicht eingehalten werden! Sie sind keine festgemauerten Fixsteine, nein, Pläne ändern sich. Das gilt ganz besonders für Projekte. Eine Vorkalkulation für ein Projekt ist natürlich auch wichtig für die Beschaffung. Logistisch müssen viele Projekte stringent versorgt werden. Aber, um unseren Schaffner zu zitieren, wir brauchen eine Basis, um zu erkennen, wo wir nicht so gut geplant haben. Ein überwachter Plan lehrt Sie, es das nächste Mal besser zu machen.

Um uns die Nachkalkulation so einfach wie möglich zu machen, sollten unsere Dokumente für Vor-, Mit- und Nachkalkulation strukturell identisch sein. Dann fallen Vergleiche umso leichter. Wenn Sie tiefer in das Thema einsteigen wollen, empfehle ich Ihnen das Merkblatt zur Vor- und Nachkalkulation von Projekten im Bereich der Trennungsrechnung.

Zu 2.a.ii: Abweichungsanalyse

Ursachen: Personelle, Technische, Organisationelle

Genau wie es für die Zugverspätung Gründe geben mag, gibt Ursachen im Projekt für Planabweichungen. Die drei Kategorien, die hier genannt sind (Personelle, Technische, Organisationelle Ursachen) eigenen sich sehr gut, um eine Tabelle zu erstellen. Die schafft mittels Klassen eine Übersicht, die verdeutlicht, ob bspw. eine Personell verursachte Abweichung zu verhindern war, gar nicht zu verhindern war, vorhersehbar oder nicht vorhersehbar war. Zugleich kann eine Vorgehensweise für die Zukunft gewählt werden, die antizipierend dafür Sorge tragen soll, dass ähnliche Ereignisse nicht mehr vorkommen.

Risikomanagement: Known Unknowns, Unknowns Unknowns

PMI nennt im PmBok Guide diese beiden o.g. Risikokategorien. Dafür existieren dann auch zwei verschiedene Risikoreserven (Contingency). Die Reserve für die Known Unknowns erhält der Projektleiter in seinem Kostenbasisplan (Performance Measurement Baseline PMB). Wobei ich der Meinung bin, da gehört sie nicht rein. Aber das ist ein anderes Thema. Wenn Sie im EVM fit sind, können Sie meinen Artikel „Änderungen im PmBok Guide 5.0“ im Kapitel 6 lesen. Die Unknowns Unknowns erhält der Sponsor zu Unknown Unknowns„Verwahrung“ für Risiken, die nicht vorhersehbar waren. Hierum geht es jetzt in dieser „Nachlese". Es gilt zu analysieren, welche Risiken zu welcher Kategorie gehören, um für zukünftige Projekte die Qualität von Risiken besser bestimmen und prognostizieren zu können.

Zu 2.a.iii: Produktanforderungen erfüllt?

Die Produktanforderungen – dokumentiert im Lastenheft oder einer Spezifikation -  sind das A & O der Zielerreichung. Nirgendwo anders wird die „Voice of Customer“ stärker rufen. Der PmBok Guide nennt hier 11 Werkzeuge um die Anforderungen des Auftraggebers zu eruieren. Auch wenn das Übergabeprotokoll zufriedenstellende Aussagen macht, sollte im Rahmen der Abschlussprozessgruppe analysiert werden, ob die Werkzeuge effizient und effektiv eingesetzt wurden. In dem Kontext sollten auch das Konfigurationsmanagement und die Rückverfolgbarkeit (Tracebility) im Fokus stehen. Beides Werkzeuge, die einen erheblichen Beitrag leisten können um die Anforderungen optimal zu erfüllen.

Zu 2.a.iv:Wirtschaftlichkeitsprüfung (Business Case)

Häufig wird der „Business Case“ als „Geschäftsfall“ übersetzt. Richtiger ist „Investitonsfolgenabschätzung“. Relevante Investitionsberechnungen sind der „Return on Investments", Kapitalwert (Net Present Value), interner Zinsfuß oder die Amortisationsrechnung. Wobei es nicht immer nur um monetäre Kriterien geht. Projekte können auch „nicht monetäre“ Nutzeneffekte – auch kombiniert mit monetärem Nutzen - erzielen. Hierfür werden dann Nutzwertanalysen verwendet, die „nicht monetäre“ Kriterien über gewichtete Karikatur: Bei Gelingen des Projekts eröffnet der Projektleiter einen Briefkasten in Panama.Punktzahlensysteme bewerten.

Um wieder auf den Schaffner zurück zukommen. Eine Wirtschaftlichkeitsbetrachtung besteht größtenteils aus Annahmen und Prognosen. Das alles würde kein Sinn machen, wenn die Qualität der Annahmen a posteriori nicht geprüft würden. Die Prüfung der Annahmen auf Validität, forciert die Fähigkeit für zukünftige Projekte bessere Einschätzungen vorzunehmen. Auch lassen sich Opportunitätskostensysteme etablieren, die zukünftig die Auswahl von Projekten erleichtern. Für viele Projekte lassen sich endgültige Wirtschaftlichkeitsprüfungen erst längere Zeit nach dem Projektlebenszyklus vollziehen.

Zu 2.a.v:  Anforderungen für das Projektmanagement erfüllt?

Bei dem eroieren oder sammeln der Anforderungen für das Projektmanagement liegt eines der schwersten „Stiefmütterlichen Verhalten“ vor. Ich teste es regelmäßig in meinen Seminaren. Ich stelle die Frage: „Woran denken Sie wenn Sie den Begriff „Qualität“ hören.“ Etwa sieben von zehn Projektleitern nennen das Produkt eines Projekts, zwei Projektleiter nennen ähnliches wie Meetings oder Controlling – das kommt der Sache schon näher – maximal ein Projektleiter nennt  das „Projektmanagement“. Und da liegt der Hase im Pfeffer. Über Anforderungen für das Projektmanagment denkt kaum einer nach!

Qualitätsanforderungen sind zum Beispiel sehr vielschichtig: Produkt- und Projektmanagementprozesse, das Produkt selbst und die Liefergegenstände der Projektmanagementprozesse bieten in Summe eine ganzheitliche Sicht auf die Qualitätsanforderungen. Modernes Qualitätsmanagement verfährt nach dem Motto: „Qualität wird nicht hineingeprüft, sondern hineingeplant“. Diese Philosophie reduziert Qualitätskosten und sollte die Prämisse für den Prozess der kontinuierlichen Verbesserung darstellen. Und da kommt wieder unserQualitaet Schaffner ins Spiel, alles was geplant wird muss am Ende analysiert werden. Nicht nur aus den bisher beschriebenen Gründen, auch aufgrund motivationaler Einflüsse. Wenn sich Qualitätskennzahlen von Projekt zu Projekt verbessern, kann das zu einem „intrinsischen Project Excellence Treiber“ führen.  

Die Anforderungen in der Teamarbeit und Führung werden im Project Excellence Modell mit zwei Aufzählungspunkten bedacht. Insgesamt werden dafür 150 Punkte vergeben.

Ich persönlich favorisiere das „Vorleben“ ganz besonders: Führen durch Vorbild! (Fehlerhafte) Führung, so habe ich das in der Praxis erlebt, wird so gut wie nie im Rahmen von Lessons learned thematisiert und dokumentiert… und natürlich nicht namentlich assoziiert. Auch hier sollte ein Fundus real erlebter Situationen erstellt werden, der als Weiterbildungsgrundlage dienen kann.

OpportunitaetskostenDas Problem in deutschen Projekten sind nicht die Produktprozesse, das Problem sind die Projektmanagementprozesse. Hier sollte also der stärkste Fokus darauf liegen, sich in Richtung „Project Excellence“ zu bewegen.  

In diesem Kontext kann der PmBok Guide von PMI eine enorme Hilfestellung bieten. Er definierte 5 Prozessgruppen mit 47 Prozessen. Jedes Projekt sollte einem Prozessmodell mit genau beschriebenen Prozessen unterliegen. Das gilt auch für agile Projekte. Wenn man einen Prozess beschrieben hat, „weiß man, was man tut“ (siehe Edward Deming). Wenn man bewusst und dokumentiert Tätigkeiten ausführt, Interaktionen wahrnimmt oder Dokumentenflüsse verfolgt, nimmt man „Sand im Getriebe“ weit schneller wahr als wenn Prozessbeschreibungen fehlen. Jeder negative Treiber eines Prozesses muss beschrieben werden und just in time oder im Rahmen der Abschlussprozessgruppe bereinigt werden.

Zu 2.b Würdigung der Teamleistung. Stärken und Schwächen.

Falls ein Team ein Team auf Zeit war, sollte man am Ende nicht auseinanderlaufen wie ein Hühnerhaufen. Im Konzept der „Teamuhr“ wird dieses Phase „Adjourning“ genannt. Hier gilt es auch einen Rückblick auf bestimmte Situationen im Projekt zu halten. Es wäre gut, wenn der Projektleiter auch hier eine Art „private Dokumentation führt, um zum Ende Highlights hervor zu heben. Konfliktsituationen und deren Lösung oder Verschleppung sollten auch hier Gegenstand von Lessons Learned werden.

Zu 2.c: Falls Projektorganisation: Auflösung dieser P-Organisation

Hier besteht der Bedarf am meisten natürlich bei reinen Projektorganisationen, die quasi ihre eigene Infrastruktur erhalten haben. Bei Linien- oder Matrixprojekten sind die Aufwände erheblich geringer. Bei reinen Projektorganisationen kann es manchmal sogar sein, dass die ehemalige Stelle in der Linie anders besetzt wurde. Es sollte also sehr frühzeitig begonnen werden, die Mitarbeiter aus das „Danach“ einzustellen. 

Ein Projektabschlussbericht sollte geschrieben werden, in dem auch Sichtweisen aller Teammitglieder dokumentiert werden.

 

Renee Ossowski, PMP

Geben Sie uns Ihr Feedback! Bitte melden Sie sich an, um einen Kommentar zu posten!