Wie jeder Projektmanager weiß, bedeutet eine Projektdiskontinuität im Allgemeinen eine Instabilität des Projekts – gefürchtet einerseits und andererseits oft Ausgangspunkt für Folgeprobleme oder gar Projektkatastrophen.
Als erstes sei angemerkt, dass der Mensch per se eine Abneigung gegen Unsicherheiten sein eigen nennt – man kann das so gut wie immer in Projekten im Bereich Change Management oder Organisationsentwicklung beobachten. Aus dieser Tatsache läßt sich ableiten, dass Menschen in dieser Situation zu Spontanreaktionen neigen. Diese sind einem Projekt aber so gut wie nie zuträglich. Schnellschüsse aus der Hüfte können ein Projekt genauso schnell gegen die Wand fahren lassen, wie ein Ignorieren von Diskontinuitäten. Was ist also zu tun?
Grundsätzlich sollte einfach Ruhe bewahrt werden. In aller Ruhe läßt es sich einfacher und emotionsloser mit Unsicherheiten umgehen. In Folge kann man sich dann wesentlich effektiver und effizienter mit den Schritten zur Bewältigung der Unsicherheit beschäftigen.
Sehr oft wird als erster Schritt zur Bewältigung von Diskontinuitäten dioe Kommunikation an den Auftraggeber genannt. Grundsätzlich ist dies durchaus in Ordnung. Die Frage ist dann meistens aber, was für Fakten kann ich dem Auftraggeber auf den Tisch legen? Aus diesem Grund bin ich hier anderer Meinung als die üblichen Methodiken es vorsehen. Vor der Kommunikation an den Auftraggeber sollte man sich über folgende Punkte Klarheit verschaffen, sofern diese Punkte nicht ohnehin durch die tägliche Arbeit sofort festgemacht werden können:
- Klassifizierung der Diskontinuität:
- Risiko: Geht es um eines, der in der Risikoliste enthaltenen Szenarios, sind die dort geplanten Maßnahmen durchzuführen.
- Gefährdung: Handelt es sich um eine Gefährdung des Projekts?
- Chance: Im Laufe des Projekts tut sich aus irgendeinem Grund eine Chance für das Projekt/Unternehmen auf, die nur durch eine große Veränderung des ursprünglichen Projekts genutzt werden kann.
- Strukturelle Änderung: im Projekt findet eine zwar geplante aber strukturell große Änderung statt.
-
Mögliche Bandbreite der Auswirkungen im magischen Dreieck des Projektmanagements feststellen
- Kosten
- Qualität
- Zeit
Sind diese Daten überblicksmäßig erhoben, müssen sie für die Kommunikation an den Auftraggeber in eine zwar managementtaugliche aber schonungslose Form gebracht werden. Das Management interessiert sich nicht dafür, dass die Open Source Prozessengine auf dem gewählten Betriebssystem nicht funktioniert, sondern wie sich das im magischen Dreieck auswirkt. Hier ist der Projektmanager sozusagen als Übersetzer gefordert. Nach der Kommunikation mit dem Auftraggeber ist dieser am Zug festzulegen, wie man weiter vorgehen soll …
Zu Teil 2 …