Projektorganisationen sind hierarchisch aufgebaut, um schnell Entscheidungen treffen zu können. Dadurch wird zwar das Projekt effizient vorangetrieben, aber hierarchische Strukturen verhindern, dass die Beobachtungen aller Teammitglieder in Entscheidungsprozessen optimal berücksichtigt werden. Dr. Georg Angermeier analysiert diese Hemmnisse und zeigt Lösungswege für eine wirksame Eskalation von Problemen auf. Hierzu vergleicht er Projektteams mit anderen hierarchischen Teams wie z.B. Flugzeugbesatzungen und überträgt die dort verwendeten Methoden des sog. Crew Resource Managements auf die Projektarbeit.
An Amazon-Kindle übertragen
Melden Sie sich bei Ihrem Amazon Konto an und folgen Sie den Anweisungen, um Ihre Datei hochzuladen und auf Ihr Kindle-Gerät zu übertragen. Unter diesem Link können Sie Ihre Amazon-Geräte und Dateien verwalten. Feedback oder Fragen?
Projektorganisationen sind hierarchisch aufgebaut, um schnell Entscheidungen treffen zu können. Dadurch wird zwar das Projekt effizient vorangetrieben, aber hierarchische Strukturen verhindern, dass die Beobachtungen aller Teammitglieder in Entscheidungsprozessen optimal berücksichtigt werden. Dr. Georg Angermeier analysiert diese Hemmnisse und zeigt Lösungswege für eine wirksame Eskalation von Problemen auf. Hierzu vergleicht er Projektteams mit anderen hierarchischen Teams wie z.B. Flugzeugbesatzungen und überträgt die dort verwendeten Methoden des sog. Crew Resource Managements auf die Projektarbeit.
Der Flug United Airlines 173 von New York über Denver nach Portland am 28. Dezember 1978 verlief bis zum Landeanflug um 17:05 völlig problemlos. Um 17:09 gab der Kapitän den Befehl, das Fahrwerk auszufahren. Aber die Signalleuchte für das ordnungsgemäße Einrasten des rechten Hauptfahrwerks leuchtete nicht auf. Um 17:12 meldete der Kapitän diesen Vorfall an den Tower und ließ sich in eine Warteschleife lotsen, um das Problem lösen zu können.
Während der folgenden dreiviertel Stunde kreisten alle Bemühungen der Crew darum, das Fahrwerk vollständig auszufahren und eine eventuelle Notlandung vorzubereiten. Erst um 17:46 erkundigte sich der Kapitän nach dem Treibstoffstand. Der Bordingenieur schätzte, dass noch für etwa 15 Minuten Treibstoff zur Verfügung stünde. Eigentlich hätte der Kapitän jetzt den ursprünglichen Plan über den Haufen werfen und zur sofortigen Landung ansetzen müssen. Aber er war vollständig darauf konzentriert, die Passagiere optimal für die Notlandung und die Evakuierung vorzubereiten. Deshalb informierte er weder den Tower über die Zuspitzung der Situation, noch beschleunigte er die Vorbereitungen für die Notlandung, sondern setzte die Vorbereitungen fort, so wie sie in den Anleitungen beschrieben waren. Das war ein klarer Fehler, zudem hätte er bereits von Anfang an den Treibstoffstand in seine Pläne einbeziehen müssen. Spätestens die Meldung des Bordingenieurs hätte ihn auf diesen Fehler aufmerksam machen müssen. Aber auch der Bordingenieur hätte das Problem des Treibstoffmangels dem Kapitän mit deutlich höherer Dringlichkeit melden müssen.
Erst elf Minuten später um 17:57, als der vom Bordingenieur durchgeführte Check bestätigte, dass nur noch für kurze Zeit Treibstoff vorhanden war, wurde dies zum Hauptthema im Cockpit. Zu spät. Um 18:13 fielen alle vier Triebwerke aus und die DC-8 stürzte um 18:15 nur sechs Meilen vor der rettenden Landebahn in ein bewaldetes Wohngebiet. Dem glücklichen Umstand, dass die betroffenen Häuser gerade leer standen, die Bäume die Maschine abbremsten und kein Feuer ausbrach, war zu verdanken, dass es unter den insgesamt 189 Menschen "nur" zehn Todesopfer zu beklagen gab.
In der Untersuchung des Unglücks (NTSB 1979) wurde als Unglücksursache identifiziert:
"Der Fehler des Kapitäns, den Treibstoffstand richtig zu überwachen und richtig auf den niedrigen Treibstoffstand und die Hinweise der Besatzung auf den Treibstoffstand zu reagieren. … Zum Unfall beigetragen hat das Scheitern der anderen beiden Crewmitglieder … ihre Bedenken erfolgreich dem Kapitän mitzuteilen."
Mit anderen Worten: Die Eskalation des Problems "Kapitän, wir haben nicht mehr genügend Treibstoff!" hatte nicht richtig funktioniert. Tragischerweise ergab die nachträgliche Untersuchung zudem, dass das Fahrwerk korrekt ausgefahren war und lediglich der Schalter für die Signallampe des rechten Hauptfahrwerks defekt war, so dass diese nicht aufleuchtete (NTSB 1979).
Um zu verstehen, warum der Bordingenieur den Kapitän nicht eindringlicher auf den bedrohlichen Treibstoffmangel aufmerksam gemacht hatte, müssen wir uns die besondere Stellung eines Flugkapitäns bewusst machen: Er trifft letztverantwortlich alle für den Flug relevanten Entscheidungen. Diese überaus starke hierarchische Position hat einen triftigen Grund: Wenn es kritisch wird, sind an Bord eines Flugzeugs schnelle Entscheidungen notwendig. Wenn es z.B. gilt, einem entgegenkommenden Flugzeug auszuweichen, würde eine Diskussion mit anschließender Abstimmung der Crew darüber, ob man steigen oder sinken solle, ganz einfach zu viel Zeit in Anspruch nehmen.
Deswegen sind Kapitäne in Flugzeugen und auf Schiffen, Einsatzleiter von Feuerwehrteams und Chefärzte am Operationstisch darauf getrimmt, Verantwortung zu tragen und zu entscheiden. Und umgekehrt orientieren sich die Teammitglieder vollständig an ihrem Leiter – sie vertrauen darauf, dass dieser die richtigen Entscheidungen trifft.
Diese Delegation der Verantwortung an den Teamchef hat den Vorteil, dass das Team reibungsfrei und schnell agieren kann. Der schwerwiegende Nachteil besteht darin, dass es nicht geeignet ist, Fehler des Chefs zu korrigieren, sondern diese sogar eher verstärkt, da die Teammitglieder ihre persönliche Verantwortung auf ihren unmittelbaren Zuständigkeitsbereich beschränken. Zudem erkennt das Team Fehler zu spät, da es bis zuletzt von einer richtigen Entscheidung des Vorgesetzten ausgeht.
Wenn in einer hierarchischen Struktur ein Mitarbeiter ein Problem erkennt, so gibt es grundsätzlich zwei Möglichkeiten:
Wenn der Mitarbeiter dieses Problem seinem Vorgesetzten melden würde, so würde er im ersten Fall gegenüber diesem eine Schwäche offenbaren – dies wäre höchst hinderlich für den nächsten Karriereschritt.
Im zweiten Fall würde der Mitarbeiter seinem Vorgesetzten einen Fehler unterstellen und ihn damit angreifen. Dies wäre noch weitaus gefährlicher, da der Vorgesetzte auf einen Angriff aller Wahrscheinlichkeit nach mit einer Machtdemonstration antwortet, um seine eigene Position nicht zu gefährden.
Die Konsequenz aus diesem Dilemma ist, dass jeder gegenüber seinem Vorgesetzten vorgibt, dass "alles im grünen Bereich" sei. Und Kritik am Vorgesetzten wird niemals direkt geäußert, sondern in Fragen oder beiläufigen Bemerkungen verpackt, die nur allzu oft nicht wahrgenommen werden. Aber selbst wenn ein kluger Chef auf diese verschlüsselten Hinweise achtet, kostet diese indirekte Kommunikation wertvolle Zeit bis er seinen Fehler korrigieren kann (Blawat, 2011).
Aufgrund von Unfällen, wie dem eingangs geschilderten, führte die NASA 1979 einen Workshop durch, in dem die Unglücksursachen von Flugzeugabstürzen analysiert wurden und Gegenmaßnahmen identifiziert werden sollten. Die wichtigste Erkenntnis dieses Workshops war, dass die häufigste Ursache für Flugzeugabstürze mangelhafte Kommunikation zwischen den Crewmitgliedern ist (Cooper, 1980).
Dieser Workshop gilt als Geburtsstunde des sog. Crew Resource Managements. Dieses lässt sich kurz und knapp definieren als ein Managementsystem, das dafür sorgt, dass alle Crewmitglieder optimal zur Sicherheit und Leistungsfähigkeit des gesamten Teams beitragen (Wikipedia, 2012).
Crew Resource Management hat vielfältige Aspekte: Zu ihm gehören unter anderem Kommunikationsregeln, Konfliktlösungsmethoden, Konfliktvermeidungsstrategien und Vorgehen zur Entscheidungsfindung unter Stress-Situationen. Für Flugzeugbesatzungen ist Crew Resource Management mittlerweile ein anerkannter und selbstverständlicher Bestandteil des Trainings. Aber auch bei anderen Berufsgruppen, wie z.B. der Feuerwehr (IAFC, 2003), hat Crew Resource Management mittlerweile Einzug gehalten. Überall da, wo Teams schnell reagieren müssen und gleichzeitig Risiken mit großen Auswirkungen bestehen, liefert Crew Resource Management wichtige Verhaltens- und Handlungsmodelle, damit der Teamchef nicht nur schnelle, sondern auch korrekte Entscheidungen treffen kann.
Projektteams weisen einige Parallelitäten mit Cockpit-Besatzungen oder Einsatzteams auf: Es gibt mit dem Projektleiter eine starke Führungsrolle, eine klare Aufgabenstellung und ein interdisziplinäres Team, das optimal zusammenwirken soll. Ein Versagen dieser Zusammenarbeit ist bei Projekten allerdings meist nicht so dramatisch wie in einem Flugzeug. Bei Projekten sind zwar Kostensteigerungen und Terminverzögerungen die Folge, die u.U. erheblichen wirtschaftlichen Schaden anrichten können, normalerweise gibt es aber bei Projekten keine Todesopfer zu beklagen. Spektakulär können Kommunikationsfehler in Projekten dennoch sein, wie die Verzögerung der Starttermins des Flughafens Berlin-Brandenburg um zehn Monate deutlich zeigte: Auf operativer Ebene war allen Beteiligten seit langem bewusst, dass der Eröffnungstermin zum 3. Juni 2012 unmöglich einzuhalten war. Für das Topmanagement, wie dem Berliner Bürgermeister Wowereit, war es hingegen eine große Überraschung, dies erst am 8. Mai 2012 zu erfahren, obwohl auch ihm die technischen Probleme bekannt waren (Financial Times Deutschland, 2012).
Gerade für Projektteams lohnt es sich daher meiner Meinung nach, sich mit den Vorgehensweisen des Crew Resource Managements zu beschäftigen. Im Folgenden möchte ich einen zentralen Aspekt behandeln: Wie kann gewährleistet werden, dass wichtige Meldungen von Teammitgliedern in der Hierarchie nach oben weitergeleitet und dort bewusst wahrgenommen werden? Dies betrifft alle Organisationsebenen eines Projekts: Projektmitarbeiter, Verantwortliche für Arbeitspakete, Teilprojektleiter, Projektleiter, Auftraggeber und Geschäftsführung.
Für die Behebung des oben angeführten Dilemmas greife ich zwei Lösungsansätze des Crew Resource Managements heraus, die mir auch für die Projektarbeit geeignet erscheinen. Der erste betrifft die Art, wie eine Eskalation am besten kommuniziert wird. Jeder Projektbeteiligte kann dies für sich unmittelbar umsetzen. Der zweite Lösungsansatz betrifft die Formalisierung der Kommunikation. Hierzu empfehle ich das PRINCE2-Prinzip "Management by Exception" zusammen mit dem Verfahren zur Behandlung Offener Punkte, das ebenfalls bei PRINCE2 beschrieben ist. Dies ist allerdings nur in Organisationen mit einem hohen Projektmanagement-Reifegrad einsetzbar.
Damit die Meldung eines Problems weder ins Leere läuft noch auf Ablehnung stößt, empfiehlt Crew Resource Management folgende fünf Elemente, um eine Eskalationsbotschaft zu formulieren (IAFC, 2003):
Anhand des folgenden einfachen Beispiels lässt sich der Sinn dieser Elemente leicht erkennen.
Wenn z.B. der für das Arbeitspaket 0815 verantwortliche Michael Maier feststellt, dass er sein Arbeitspaket unmöglich innerhalb der vereinbarten Zeit fertigstellen kann, muss er dies natürlich den davon betroffenen Personen mitteilen. Er könnte dies mit einer Rundmail an alle Projektbeteiligten wie folgt tun:
"Hallo zusammen,
den von oben gesetzten Termin können wir unmöglich halten, wenn wir nicht noch mindestens drei weitere Mitarbeiter für das Arbeitspaket 0815 bekommen!
Grüße
Maier"
Offenkundig verletzt er damit alle oben angeführten Empfehlungen gleichzeitig. Er braucht sich nicht wundern, wenn er zum einen keine weiteren Mitarbeiter bekommt und zum anderen der Projektleiter Hans Huber seine Macht demonstriert, indem der zurückschreibt:
"Hallo Herr Maier,
als Projektleiter habe ich sowohl den Terminplan als auch die Ressourcenausstattung der Teams sehr wohl im Blick. Natürlich hätte jeder gerne mehr Ressourcen, leider ist dies hier ein Projekt und kein Ponyhof! Ich möchte Sie dringend darum bitten, Ihren Anteil zum Gelingen des Projekts beizutragen und dafür zu sorgen, dass das Arbeitspaket 0815 pünktlich erledigt wird.
Mfg
Huber"
Wenn Maier hingegen die obigen fünf Punkte berücksichtigt, dann würde er direkt an den Projektleiter Huber folgende Mail senden:
"Hallo Herr Huber,
große Sorge bereitet mir die Terminsituation des Projekts. Meiner Einschätzung nach kann das Arbeitspaket 0815 erst zwei Wochen nach dem gesetzten Termin abgeschlossen werden, was zu einer kritischen Verzögerung im Terminplan führen würde. Eine pünktliche Fertigstellung des AP 0815 kann ich zusichern, wenn ich noch drei zusätzliche Mitarbeiter erhalte. Was ist Ihre Entscheidung für das weitere Vorgehen?
Grüße
Maier"
Die Sachlage ist exakt dieselbe. Aber Projektleiter Huber hat jetzt eine Chance, diese Problemmeldung ernst zu nehmen. Vielleicht schreibt er nunmehr zurück:
"Hallo Herr Maier,
danke für Ihre Statusmeldung. Es ist mir bewusst, dass dieses Projekt mit Ressourcen sehr knapp ausgestattet ist. Ich habe die Projektplanung überprüft und werde Ihrem Team ab übermorgen noch Frau Sabine Schmidt zuteilen. Außerdem genügt es, wenn Sie zum festgelegten Termin die Konstruktionszeichnungen und einen Prototyp fertig haben, damit das nächste Arbeitspaket starten kann. Für die Abgabe des endgültigen Produkts kann ich Ihnen dann noch eine Woche mehr Zeit einräumen. Es ist sehr wichtig, dass Sie und Ihr Team dies schaffen. Bitte informieren Sie mich unverzüglich, wenn die Einhaltung des Termins gefährdet ist.
Grüße
Huber"
Zum "Ponyhof" wird das Projekt dadurch noch lange nicht, aber alle suchen in einer objektiv schwierigen Situation gemeinsam nach der besten Lösung.
Crew Resource Management versucht Missverständnisse nicht nur durch Kommunikationsregeln zu vermeiden, wie in ersten Lösungsansatz gezeigt, sondern auch durch formalisierte Vorgehensweisen für Kommunikations- und Entscheidungsprozesse. Dies geschieht bereits bei Details, wie z.B. die Übergabe der Kontrolle über das Flugzeug durch die Standardformulierungen "You have control" und die bestätigende Antwort: "I have control". Aber auch für komplexe Vorgänge bietet es Handlungsmuster, wie z.B. einen sechsstufigen Prozess für das Treffen von Entscheidungen (IAFC, 2003).
Um diesen Lösungsansatz auf das Projektmanagement zu übertragen, benötigen wir ein formalisiertes Vorgehen, das innerhalb einer hierarchischen Projektorganisation Eskalationen von Schwierigkeiten ohne Gefahren für die Beteiligten möglich macht. Zum Glück gibt es dies bereits: Es handelt sich um das Verfahren zur Behandlung Offener Punkte bei PRINCE2 im Zusammenspiel mit dem Prinzip "Management by Exception" (The Stationary Office, 2009).
Während die oben angeführten Kommunikationsregeln des ersten Lösungsansatzes in jedem Projektumfeld eingesetzt werden können und sollten, setzt die Formalisierung von Kommunikationsabläufen ein Mindestmaß an Projektmanagement-Reife zumindest in der Trägerorganisation des Projekts voraus. Dies lässt sich gut an der Frage veranschaulichen, zu welchem Zeitpunkt eine Eskalation stattfinden sollte.
Nehmen wir einmal an, Sie sind als Projektleiter verantwortlich für die Einhaltung von Budget und Termin. Der Auftraggeber ist zugleich Ihr Vorgesetzter. Zu welchem Zeitpunkt würden Sie eine Überschreitung des Budgets oder des Termins an ihn melden?
Diese Eskalationsskala ist zugleich eine Mess-Skala für den Projektmanagement-Reifegrad Ihres Unternehmens! Wenn Ihr Unternehmen noch in altherkömmlicher Weise Projekte nach dem "Heldenprinzip" managt, dann tun Sie gut daran, Probleme nicht zu eskalieren, sondern erst nach Abschluss des Projekts Ihrem Vorgesetzten klar machen, dass Sie das beste aus der schwierigen Situation herausgeholt haben. In einem eskalationsfeindlichen Umfeld wollen Vorgesetzte nichts von Problemen hören, mit ausreichend diplomatischen Geschick können Sie aber als Projektmanager nahezu alle Budget- und Terminüberschreitungen durchsetzen.
In einem Unternehmen mit hohem PM-Reifegrad hingegen müssen Sie allerspätestens dann eskalieren, wenn Sie keine Möglichkeit mehr sehen, selbst die Überschreitung zu verhindern. Im optimalen Fall erhalten Sie dann auch vom Lenkungsausschuss die benötigte Unterstützung, um das Projekt erfolgreich abzuschließen. Wenn Sie unter diesen Rahmenbedingungen hingegen zu spät eskalieren, dann können Sie froh sein, wenn Sie nur mit einer Abmahnung davon kommen.
Die folgenden Methoden funktionieren nur in einem Unternehmen mit hohem Reifegrad, da hier mehrere Beteiligte diesen Kommunikationsprozess kennen, akzeptieren und befolgen müssen. Wenn dies der Fall ist, entfalten sie aber einen überaus großen Nutzen, da sie zum einen klar regeln, wann eine Eskalation zu erfolgen hat und wie dieser Prozess ablaufen muss. Dadurch geben sie allen Beteiligten Orientierung und sie gewährleisten, dass die trotz aller PM-Reife mit einer Eskalation verbundenen negativen Assoziationen (Eingestehen von Schwäche oder Kritik am Vorgesetzten) vermieden werden.
Das von PRINCE2 definierte Prinzip "Management by Exception" (The Stationary Office, 2009) ist ein Kunstkniff, um Projektverantwortlichen Gestaltungsspielräume für ihre Arbeit zu geben und gleichzeitig ihren jeweiligen Vorgesetzten die Sicherheit zu geben, dass die Abweichungen des Projekts innerhalb eines akzeptablen Rahmens bleiben.
Die Umsetzung dieses Prinzips ist einfach erklärt: Wenn der Lenkungsausschuss z.B. die nächste Projektphase freigibt, legt er nicht nur das Budget fest, das hierfür zur Verfügung steht, sondern zugleich die von ihm akzeptierten Abweichungen nach oben und unten von diesem Zielwert. Dasselbe gilt für die Dauer, den zu erbringenden Leistungsumfang, den Qualitätsstandard der Liefergegenstände, das Projektrisiko und den im Business Case beschriebenen Nutzen des Projekts.
Solange das Projekt mit seinen Kennzahlen innerhalb dieser Toleranzgrenzen bleibt, hat der Projektmanager völlig freie Hand in der Projektdurchführung. Zudem werden der Lenkungsausschuss und das Topmanagement nicht durch regelmäßige und nutzlose Projektbesprechungen belästigt. Sobald der Projektmanager jedoch feststellt, dass eine der gesetzten Toleranzen voraussichtlich verletzt wird, muss er dieses Problem an den Lenkungsausschuss melden – und dieser ist verpflichtet, so schnell als möglich eine Entscheidung zu treffen.
Das gleiche Schema gilt, wenn der Projektleiter ein Arbeitspaket an einen Arbeitspaketverantwortlichen (bei PRINCE2 wird dieser Teamleiter genannt) übergibt: Auch hier gilt das Prinzip von vorgegebenen Zielgrößen verbunden mit Toleranzen.
Das Steuern mit Toleranzen erscheint auf den ersten Blick trivial, in der Praxis erweist es sich als durchaus anspruchsvoll, sie richtig festzulegen. Wenn der Lenkungsausschuss z.B. alle Toleranzen auf Null festlegt, braucht er sich nicht wundern, wenn er mit Meldungen über mögliche Toleranzüberschreitungen nur so überhäuft wird. Umgekehrt beraubt er sich eigener Steuerungsmöglichkeiten, wenn er die Toleranzen so großzügig bemisst, dass er selbst keinen Handlungsspielraum mehr hat, um z.B. durch eine Budgeterhöhung sinnvolle Change Requests zu finanzieren.
Soweit die Anleitung von PRINCE2. Ich möchte hier noch dringend eine Präzisierung empfehlen. Gemäß PRINCE2 ist nicht eindeutig geregelt, was es bedeutet, dass eine Toleranzüberschreitung "absehbar" ist. Jede der oben genannten ersten drei Stufen für eine Eskalation kann als "absehbar" interpretiert werden. Deshalb empfehle ich, auch zu definieren, wie die Abweichungen bestimmt werden und wann genau eine Eskalation stattfinden muss. Was ich damit meine, möchte ich mit folgendem Beispiel veranschaulichen:
Wenn in einem Projekt der Abgabetermin für ein bestimmtes Werk – z.B. der Generator für ein Kraftwerk – unbedingt eingehalten werden muss, dann empfehle ich dringend, ganz genau zu definieren, wie der Projektleiter eine drohende Terminverzögerung feststellen kann und eine eindeutige Messgröße für die Notwendigkeit zur Eskalation festzulegen. Im Anlagenbau wird der Terminplan in der Regel mit Hilfe eines Netzplantechnik-Tools erstellt. Um den vielleicht sogar mit einer hohen Konventionalstrafe bewehrten Termin auf jeden Fall einzuhalten, wird ein Puffer von z.B. zehn Arbeitstagen vor dem Abgabetermin eingebaut. Als für alle Beteiligten eindeutige Regel für die Eskalation kann nun vereinbart werden, dass der Projektmanager den Lenkungsausschuss informieren und einen Lösungsvorschlag vorlegen muss, sobald der Puffer auf fünf Tage oder weniger geschrumpft ist.
Durch die Vereinbarung von Toleranzen und Eskalationskriterien ist das erste Hemmnis für eine Eskalation beseitigt: Der Projektmanager hat nicht nur einen objektiven Grund, sondern sogar die Pflicht, zu eskalieren. Was noch fehlt ist ein formalisierter Kommunikationsprozess, der gewährleistet, dass alle Beteiligten ihr Gesicht wahren können. Mit dem Managementverfahren zur Behandlung Offener Punkte liefert PRINCE2 (The Stationary Office, 2009) genau dies und sorgt dafür, dass die Eskalation nicht als Eingeständnis einer Schwäche oder als Angriff missverstanden werden kann – vorausgesetzt, dass sie richtig kommuniziert wird.
Jeder Projektbeteiligte kann einen Offenen Punkt an den Projektmanager senden. Egal, ob es sich um einen Änderungsantrag, den Hinweis auf einen Fehler oder eine andere Mitteilung handelt. Der Projektmanager ist damit bei PRINCE2 das Kommunikationszentrum des Projekts. Insbesondere ist er dafür zuständig, die ihm gemeldeten Offenen Punkte gemäß der im Folgenden stark vereinfacht dargestellten fünf Schritte zu behandeln.
Als erstes entscheidet der Projektmanager, ob es sich bei dem an ihn herangetragenen Anliegen überhaupt um einen Offenen Punkt handelt, der mit diesem Verfahren zu behandeln ist. Wenn dies der Fall ist, dann stellt er zunächst fest, um welche Art von Offenen Punkt es sich handelt: Änderungsantrag, Fehlermeldung oder einen allgemeinen Offenen Punkt. Dann trägt er ihn in die Liste der Offenen Punkte ein und benachrichtigt den Absender des Offenen Punkts diesbezüglich. Diese Rückmeldung ist überaus wichtig: Wenn jemand dem Projektmanager eine aus seiner Sicht dringende Mitteilung gemacht hat, aber von diesem keine Rückmeldung erhält, dass er einen Offenen Punkt angelegt hat, sollte der Einreicher beim Projektmanager nachfragen. Damit wird gewährleistet, dass alle Beiträge aus dem Team berücksichtigt werden. Beim Erfassen schätzt der Projektmanager zugleich auch die Wichtigkeit des Offenen Punkts ab.
Auch wenn dies formell ein eigener Punkt ist, wird der Projektmanager in den meisten Fällen die beiden ersten Schritte "Erfassen" und "Untersuchen" gleichzeitig durchführen, um zu gewährleisten, dass er keine Gefahren übersieht.
Der Projektmanager muss analysieren, welche Auswirkungen der gemeldete Offene Punkt auf das Projekt hat. Z.B. kann es sich um ein bisher nicht erkanntes Risiko handeln. Bei Bedarf wird der Projektmanager weitere Personen zu Rate ziehen oder sogar eine detaillierte Auswirkungsanalyse durchführen lassen.
Wenn die Auswirkungen des Offenen Punkts über den unmittelbaren Zuständigkeitsbereich des Projektmanagers hinausgehen, z.B. Auswirkungen auf die nächste Phase des Projekts oder auf andere Projekte haben kann, dann sollte er bereits jetzt den Lenkungsausschuss informieren und von ihm die Priorität der Angelegenheit bewerten lassen.
In diesem Schritt fasst PRINCE2 die gesamte Problemlösung zusammen: Es gilt hier, aus fachlicher Sicht die möglichen Handlungsoptionen zu identifizieren, zu bewerten und schließlich die beste Maßnahme zu identifizieren und zu empfehlen. Wichtig ist, dass es hier keine Tabus gibt: Die Palette der betrachteten Maßnahmen reicht von "Nichts tun" bis zu "Projekt sofort abbrechen".
Hier ist nun der Scheideweg: Wenn die vom Lenkungsausschuss gesetzten Toleranzen eingehalten werden können und der Projektmanager für die vorgeschlagene Maßnahme die ausreichenden Befugnisse hat, kann der Projektmanager den Offenen Punkt alleine abschließend behandeln.
Falls aber gemäß der oben festgelegten Regeln eine Toleranz voraussichtlich überschritten wird, muss der Projektmanager diesen Vorgang mit seiner Handlungsempfehlung in Form eines sogenannten Ausnahmeberichts an den Lenkungsausschuss eskalieren.
Ab jetzt hat der Lenkungsausschuss die Entscheidungshoheit. Im einfachsten Fall kann er die Toleranzen erhöhen und den Projektmanager anweisen, die vorgeschlagene Maßnahme umzusetzen und die Projektpläne entsprechend zu aktualisieren. Aber auch alle anderen Entscheidungsmöglichkeiten sind dem Lenkungsausschuss freigestellt: Z.B. könnte er fordern, dass das Projekt wie ursprünglich geplant fortgeführt wird und das gemeldete Problem ganz einfach ignoriert wird.
Was auch immer der Lenkungsausschuss entscheidet: Der Projektmanager ist damit auf der sicheren Seite: Der Lenkungsausschuss war über die Angelegenheit und all ihre möglichen Konsequenzen informiert und hat eine dokumentierte Entscheidung getroffen.
Der Projektmanager trägt dafür Sorge, dass die beschlossenen Maßnahmen durchgeführt und die entsprechenden Projektdokumente, insbesondere die Pläne, aktualisiert werden.
Die Überprüfung, ob die durchgeführten Maßnahmen die gewünschte Wirkung erzielen, ist nicht mehr Bestandteil dieses Verfahrens, da dies ohnehin beständige Aufgabe des Projektmanagers ist.
Das PRINCE2-Verfahren zur Steuerung Offener Punkte lässt sich auch leicht in anderen Projektmanagementsystemen verwenden. Es bedarf allerdings einer evtl. längeren Anlaufzeit, bis alle Projektbeteiligten ein Gefühl entwickelt haben, was ein Offener Punkt und was lediglich alltägliche Kommunikation ist.
Meiner Meinung nach sollte in jedem Projektmanagement-Handbuch beschrieben sein, wie der Kommunikations- und Entscheidungsprozess für Offene Punkte zu gestalten ist. Die oben dargestellten fünf Schritte können dafür den Rahmen liefern – je nach Unternehmen, Branche und Projektart können hier viele weitere Details erforderlich sein.
Projekte benötigen einerseits eine klare Organisation mit eindeutigen Rollenbeschreibungen. Nur so können die notwendigen Entscheidungen getroffen und die Arbeiten zielführend vorangetrieben werden. Andererseits sind Projekte risikobehaftete Vorhaben, bei denen es erforderlich ist, dass Beobachtungen über potentielle Probleme und Gefahren in der Hierarchie von unten nach oben effektiv mitgeteilt und korrekt behandelt werden.
Formalisierte Vorgehensweisen ermöglichen dies, da sie die Kommunikationshürden in hierarchisch strukturierten Teams überwinden. Bewährte Lösungen liefern das Crew Resource Management, das PRINCE2-Prinzip "Management by Exception" und das Managementverfahren zur Behandlung Offener Punkte von PRINCE2.
