PRINCE2: Leitfaden für Einsteiger

Die Olympiade 2012 in London ging als nahezu perfekt gemanagte Großveranstaltung in die Geschichte der Olympischen Spiele ein. Bei einem Budget von 9,3 Milliarden Pfund und tausenden Mitarbeitern ging die eigens dafür gegründete Organisation rund sieben Jahre vor Beginn der Spiele an die Arbeit. Im März 2012, rund vier Monate vor Beginn, kam das offizielle Olympische Komitee bei dem abschließenden Besuch zum Schluss: „London ist bereit, diesen Sommer die Welt zu empfangen.“ Was war das Geheimnis hinter dem Projekterfolg aus London? War der Projektleiter einfach ein Profi? Ein Naturtalent? Sind die Briten von Natur aus bessere Projektmanager als der Rest der Welt? Welche Tricks und Kniffe hatten sie auf Lager? Die Antwort lautet PRINCE2, die weltweit erfolgreichste Best Practice Methodik, geformt aus rund 30 Jahren Projektmanagement-Erfahrung. Die Olympiade wurde tatsächlich auf Basis dieser weltweit bekannten Methodik zum Erfolg gemanagt.

Ok. Natürlich werden auch die Mitarbeiter die besten Projektmanager des ganzen Vereinigten Königreichs gewesen sein, dennoch: alleine die Methodik hinter den Individuen kann für den Erfolg oder Misserfolg ganzer Projekte verantwortlich sein. Dieser Leitfaden erklärt das Phänomen PRINCE2.

Anhand von einfachen Beispielen aus unserem Beispielprojekt – Olympia – werden wir die Methodik Schritt für Schritt aufeinander aufbauen. Ende dieses Buches wirst Du in der Lage sein, in PRINCE2-Projekten erfolgreich mitarbeiten zu können. Die PRINCE2-Methodik als solche besteht aus einem Vorgehensmodell von 377 Seiten Umfang. Seiten, die als Handbuch absolut notwendig sind, um in gewissen Projektsituationen sich einfach das richtige Toolset zu „ziehen“ und nachzulesen. Im Projektalltag eines Projektmanagers absolut notwendig.

Die Grundlagen

Die Geschichte hinter der PRINCE2

PRINCE2 wurde 1989 von der britischen Regierungsabteilung „Central Computer and Telecommunications Agency“ als eine Art „Wissensmanagement-Projekt“ in Auftrag gegeben, um die Erfahrungen der bis dato gemachten Projekterfahrungen zu sammeln, zu bewerten und daraus ein Framework zu entwickeln, welches dabei helfen sollte, bei zukünftigen Projekten bereits bekannte Fehler zu vermeiden. Hieraus entstand die erste Best Practice Projektmanagement-Methodik PRINCE; damals noch ohne die Versionsandeutung „2“. PRINCE stand und steht für PRojects IN Controlled Enviroments. Zum damaligen Zeitpunkt war das Framework für IT-Projekte entwickelt worden. Es sollte als Regierungsstandard für Projektmanagement gelten. Schon bald jedoch fanden die darin enthaltenen Methoden auch außerhalb von IT-Projekten eine weite Verbreitung.

Aus der Erkenntnis heraus, dass PRINCE auch auf andere Projekte anwendbar ist, wurde die Methodik nochmal stark verschlankt, vereinfacht und schließlich 1996 als allgemeine Projektmanagement-Methode PRINCE2 veröffentlicht. Seitdem wurde die PRINCE2-Methodik zunehmend populärer. Neben der PMBok (PMI) und ICB (IPMA, GPM) zählt PRINCE2 zu den weltweit am häufigsten verwendeten Projektmanagement-Methodiken. In über 50 Ländern wird PRINCE2 geschult, zertifiziert und angewandt. In Großbritannien gilt PRINCE2 sogar als De-Facto-Projektmanagement- Standard. Hier achten Unternehmen in der Tat darauf, wenn jemand die Rolle des Pro- jektleiters oder Projektmanagers übernimmt, dass dieser eine eingetragene PRINCE2-Zertifizierung hält. Die Anforderung nach einem Zertifikat einer anerkannten Projektmanagement-Methodik wie PRINCE2 lässt sich immer mehr auch im D-A-CH-Raum verfolgen. Das liegt nicht zuletzt daran, dass die Eigenschaft, ein richtig guter Projektmanager zu sein, aufgrund der aktuellen Änderungsbereitschaft der Unternehmen gefragter denn je zuvor ist.

Die Allzwecklösung des Projektmanagements

Oft fragt man sich in diesem Zusammenhang, wie PRINCE2 eigentlich eine Allzwecklösung für diese ganz verschiedenen Projekte bieten kann. Die Antwort darauf ist simpel: PRINCE2 ist so generisch wie nötig, jedoch so konkret wie möglich, um als 360o- Methodik, also als ganzheitliche Projektmethodik, wahrgenommen zu werden. Das bedeutet zuallererst, dass die Methoden-Guideline an sich so allgemein formuliert ist, dass daraus kein fachlicher Hintergrund eines Projekts herauszulesen ist. PRINCE2 beschreibt nicht, dass Du jeden Tag mit Deinen Entwicklern zusammen die neu programmierte Software-Funktionalität testen sollst.

Vielmehr beschreibt PRINCE2, dass Du als Projektmanager Dich in einem von Dir zu wählenden Turnus mit Deinen Teilprojektleitern austauschen sollst und diese so organisierst, dass sie mit ihren fachlichen Teams die Produkterstellung vorantreiben. Die Methodik gibt die Empfehlungen und Eckpunkte vor, anhand derer Du den Rhythmus für Deine Meetings finden kannst. Du erhältst Hinweise, welche Inhalte ein Bericht enthalten soll. Im Grunde genommen geht es darum, aus der Sicht des Projektmanagers Dir zu jedem Zeitpunkt im Projekt die richtigen Werkzeuge an die Hand zu geben, welche Dir dabei helfen sollen, jederzeit die richtigen Entscheidungen treffen zu können.

Anpassbar an jede Projektumgebung

Und das so generisch wie möglich. Daher ist eines der wichtigsten Grundprinzipien der PRINCE2-Terminologie die sogenannte „Anpassung an die Projektumgebung“. Ohne vorwegzugreifen ist in diesem Kontext ersichtlich, weshalb dieses Grundprinzip als derart wichtig eingestuft wird. Um diese eben beschriebene generische Anwendbarkeit auf Dauer aufrechtzuhalten, ist PRINCE2 keinesfalls im Jahre 1996 stehen geblieben. Die heutigen Rechteinhaber, AXELOS, bestehend zu 51% aus Capita (privates Unternehmen in GB) und zu 49% aus Cabinet Office (Behörde in GB), sind mehr denn je damit beschäftigt, die Methodik weiterhin dem Geist der Zeit einzuverleiben. Dies geschieht durch die regelmäßig stattfindenden Updates.

Das letzte große Update von PRINCE2 wurde im Jahre 2017 unter dem Namen PRINCE2 V2017 bekannt gegeben. Hierbei wurden innerhalb der Themen von PRINCE2 Anpassungen durchgeführt, sowie einige Wordings und Fokusbereiche verändert. Auf Basis dieser neuen Version, welche im Jahre über die letzten Monate final geschliffen und ins Deutsche übersetzt wurde, haben wir unseren bestehenden Bestseller aktualisiert und angepasst, so dass wir nun im Jahre 2019 eine sehr runde und hochwertige Buchversion von PRINCE2 v2017 zur Verfügung stellen können.

Charakteristika eines Projekts

Bevor wir uns direkt den ersten Inhalten von PRINCE2 widmen, möchten wir an dieser Stelle erst mal mit ganz allgemeinem Projektmanagement-Wissen beginnen. Unser Beispielprojekt, an dem wir uns hier im Buch orientieren werden, sind die Olympi- schen Spiele. Wenn wir nun hergehen und die Olympiade als Projekt sehen und uns dann vorstellen, als Projektmanager vor dem Start dieses riesigen Projekts in einer Linienfunktion tätig gewesen zu sein, wird einem die Differenzierung zwischen Projekt- und Linientätigkeit leicht von der Hand gehen.

Kommen wir zur Definition eines Projekts zurück. Generell gilt: Ein Projekt ist eine für einen befristeten Zeitraum geschaffene Organisation, die mit dem Zweck eingerichtet wird, einen oder mehrere Produkte in Übereinstimmung mit einem Business Case zu vereinbarter Qualität zu liefern.

Einzigartig

Vergleicht man ein Projekt mit einer Aufgabe in der der Linie, wird klar, dass es sich hierbei um nichtwiederholende Tätigkeiten handelt. In der Linie macht man hingegen – stark vereinfacht gesagt – jeden Tag annähernd dasselbe. Als Controller vergleicht man Berichte, berät mit dem Management, als Risiko-Mana- ger identifiziert man Risiken und bewertet sie, als Sachbearbeiter bearbeitet man Auf- tragseingänge.

Im Projekt hingegen erwartet einen täglich eine neue Herausforderung. Man entwi- ckelt und entwirft neue Dinge. Es kommen ständig neue Aspekte zum Vorschein, die im Vorhinein überhaupt nicht klar waren. Die „Einzigartigkeit“ kann man sogar noch weiter fassen: Geht man doch davon aus, dass sogar die Aspekte, die auf den ersten Blick einem anderen ähneln, völlig einzigartig sind. Dieser Gedanke ist hochinteres- sant, könnte ein Kritiker dieser Definition doch behaupten, dass wir 2012 bereits die 30. Olympiade der Neuzeit organisieren (in der Geschichte von Olympia noch deutlich mehr).

Dieser Gedankengang ist dahingehend schnell zu entkräften, wenn man sich die für die Olympiade 2012 vorhandenen Gegebenheiten anschaut. Neues Jahrzehnt, anderer Kontinent als die letzte Olympiade (China), damit andere Mentalität bei den Mitarbeitern, das Land ist von den finanziellen Mitteln anders aufgestellt etc. So übri- gens unterscheiden sich Projekte innerhalb eines Unternehmens auch. Die Abteilun- gen stellen unterschiedliche Mitarbeiter, haben unterschiedliche Budgets, immer ein unterschiedliches Kernziel etc.

Begrenzt

Geht man von einer Linienorganisation aus, ist hierbei grundsätzlich kein zeitlicher Horizont angedacht. Die Abteilung geht in dem Moment des Existierens da- von aus, dies auf unbestimmte Zeit zu tun. Vergleicht man diese Einstellung mit einer Projektorganisation, fällt auf, dass hierbei sehr unterschiedliche Ausprägungen vor- handen sind.

Ein Projekt ist von Natur aus begrenzt. In erster Linie natürlich zeitlich, da ein klar de- finiertes Ende geplant ist. Freilich sind auch die anderen Projektdimensionen wie Budget oder Qualität etc. begrenzt bzw. vorgeschrieben, schaut man hier jedoch auf das klassische Pendant eines Projekts – die Linie –, stellt man fest, dass auch die Lini- enorganisation durchaus eine budgetäre und qualitative Rahmenvorgabe hat. In Großunternehmen sind eigene Abteilungen im Rahmen etwaiger Controlling-Offen- siven oft sogar als ein Cost- oder Profitcenter definiert.

Somit wird klar, dass die hier angesprochene Begrenzung sich in erster Linie auf den zeitlichen Aspekt eines jeden Projekts beschränkt.

Bereichsübergreifend

Ein Projekt stellt in seiner Vollkommenheit seine Interdiszipli- narität, also sein fachspezifisch übergreifendes Know-how unter Beweis. In einem Pro- jekt treffen viele unterschiedliche Fachexperten, oft aus verschiedenen Unternehmen, aus verschiedensten Ländern und Kulturen, manchmal sogar zu völlig unterschiedli- chen Zeitzonen aufeinander. Der einzige Nenner all dieser Mitarbeiter ist nur das Pro- jekt. Das bedeutet auch, dass Menschen, die aus so unterschiedlichen „Welten“ aufei- nanderstoßen, ein enormes Konfliktpotenzial in sich bergen. Wenn sich jedoch dieses neue Projektteam, die verschiedensten Entwickler, die unterschiedlichsten Berater sich erst einmal eingeschwungen haben, ist die Produktivität enorm.

Bei einer Linienorganisation ist die Funktion „bereichsübergreifend“ natürlich deutlich untergeordnet. Arbeiten doch hier die meisten Mitarbeiter dauerhaft mit. Das hat na- türlich den enormen Vorteil, dass jeder seine Rollen und Verantwortlichkeiten kennt und diese nicht noch – wie in einem neuen Projekt – festgelegt werden müssen.

Unsicher

In der Annahme, dass ein Risiko in der betriebswirtschaftlichen Welt nicht per se als negativ, sondern vielmehr „wertfrei“ hinzunehmen ist, bezieht sich die Be- schreibung „unsicher“ in erster Linie auf die Zielerreichung, die durch viele Bedrohun- gen, also der negativen Ausprägung einer Unsicherheit, sowie einigen Chancen, den positiven Ausprägungen einer Unsicherheit, gekennzeichnet ist. Das Thema „Risiko“, das sich dahinter vereint, wird in der Geschichte des strukturierten Projektmanage- ments inzwischen als „Dauerbrenner“ erkannt. Das Gute: Fast alle Projektmanager wis- sen inzwischen, wie wichtig es ist, überhaupt Risikomanagement zu betreiben.

Das Schlechte: Von einem effektiv effizienten Risikomanagement ist der Großteil der Projekte noch sehr weit entfernt. Natürlich, im Daily Business ist es oft stressig. Und natürlich rücken dort Themen, die auf den ersten Blick nicht sehr viel zur Projekt- umsetzung beitragen, oft sehr schnell in den Hintergrund. Jedoch sollte man sich als Projektmanager in diesem unsicheren Umfeld, in dem man sich im Projekt-Business naturgemäß bewegt, unbedingt mit dem stiefmütterlich behandelten Thema Risiko- managament mehr als nur ein bisschen auseinandersetzen.

Verändernd

Der Grund für die Durchführung eines Projekts ist, einem aktuellen Zu- stand entgegen zu wirken und/oder einen anderen Zustand herzustellen. Ein Projekt ist somit mit dem Ziel eingerichtet, eine Veränderung herbeizuführen.

PRINCE2: Der Projektsteuerungskreislauf

Ein wichtiger Grundsatz, auf dem die PRINCE2-Methodik aufbaut, ist der Projektsteu- erungskreislauf. Hierbei geht es kurz gesagt um die Planung, Delegation, Überwa- chung und Steuerung der einzelnen Aspekte eines Projekts. Dieser Kreislauf findet in allen Dimensionen von PRINCE2 statt, welche im Schaubild innerhalb des Kreislaufes als Dreieck mit drei Kreisen abgebildet sind. Der Projektsteuerungskreislauf stellt die Ablaufbeschreibung für das erfolgreiche Ma- nagement der folgenden sechs Projektdimensionen dar.

Die sechs Dimensionen innerhalb von PRINCE2 sind:

Zeit

Wie viel Zeit das Projekt benötigt. Wann das Projekt beginnt, wann es (plan- mäßig) enden soll. Wann welche Phase beginnt, wann welches Produkt erstellt wird: All das sind zeitbezogene Aspekte, die der Projektmanager unbedingt mit hoher Aufmerksamkeit managen sollte. Gerade bei großen, bekannten und/oder prestigeträchtigen Projekten ist die Zeit neben dem monetären Aspekt der öf- fentliche Aufhänger schlechthin. Aber auch Unternehmen kämpfen in ihren Organisationen häufig mit teilweise extrem verspäteten Projekten. Woher kommt das? Liegt das an mangelnder Management-Kompetenz? Oder sind die hiesigen Projektmanager einfach nur nicht in der Lage, valide Zeitpläne vorzulegen? PRINCE2 gibt hierfür einige Tools mit an die Hand, welche zur einer bedarfsge- rechten zeitlichen Planung, Delegation, Überwachung und Steuerung des Projekts massiv beitragen.

Kosten

Neben dem gerade angesprochenen Zeitaspekt ist die Kostendimension die mit Abstand essentiellste. Schließlich steht und fällt alles damit, dass es inner- halb eines Projekts einen Geldgeber gibt, der ein naturgemäß hohes Interesse an der Projektdurchführung und schließlich dem Projekterfolg hat. Der Geldgeber alleine hat die „Macht“, das gesamte Projekt einzustellen. Wie also sollte der Pro- jektmanager hinsichtlich dieser essentiellen Stakeholder-Attention agieren? Nach der PRINCE2-Terminologie nimmt der Projektmanager hier eine Art Vermitt- lerrolle ein, der die Interessen der Stakeholder wie zum Beispiel dem Auftrag- geber mit denen der Lieferanten zueinander bringt.

Qualität

Umgangssprachlich wird „Qualität“ per se als absolut positiv gewertet. Man spricht davon, dass das „Auto Qualität hat“. Anders ausgedrückt sagt man also, dass das Auto „Eigenschaften“ hat. Denn genau so ist Qualität zu sehen. Und zwar als Eigenschaften, die von dem Projekt umgesetzt werden sollen. Ob die Ei- genschaften, also die Qualität, „gut“ oder „schlecht“ sind, vermag der Kunde bzw. der Auftraggeber beurteilen. Der Projektmanager hat nicht das Recht, dies zu be- urteilen. Aber er hat jedoch die Pflicht, dies mit gegebenen Ressourcen so gut es möglich ist umzusetzen. Spätestens hier sollte einem die „magische“ Verbindung von Zeit, Kosten und Qualität bewusst werden.

Diese drei stehen in ständiger Abhängigkeit voneinander. Möchten wir bei unseren Olympischen Spielen die Häuser der Olympioniken in einer hochwertigen oder einer mittelmäßigen Ausstattung? Je nachdem verändert sich natürlich der monetäre Aspekt, da bei der hochwertigen Ausstattung ausschließlich Marmorfußboden verlegt werden soll, welcher deutlich teurer ist als der Teppichboden der mittleren Ausstattung. Hierbei fällt natürlich ins Auge, dass Marmor eine deutlich längere Lieferzeit hat als Teppich. Das Projekt würde sich also neben einer Kostenerhöhung auch noch massiv verspäten. Nun liegt es am Projektmanager, in Anbetracht der Anforderungen der Stakeholder den besten Weg für das Projekt zu finden. Das bedeutet keinesfalls, dass er hierbei persönliche Anforderungen berücksichtigt. Vielmehr muss er die von den Stakeholdern geforderten Qualitätsaspekte so gut es geht berücksichtigen oder eben, bei Nichteinhaltung dieser, die Problematik den Stakeholdern so früh als möglich melden.

Risiko

Wie baut man innerhalb des Projektes ein geeignetes Risikomanagement- system auf? Mit der Frage beschäftigten wir uns im Folgenden beim Thema „Risiko“. Als Dimension bringt „Risiko“ zum Ausdruck, dass es sich um eine täglich zu erfüllende Aufgabe des Projektmanagers handelt. Selbstverständlich ist hierbei, dass es so hochspezifische Risiken zu beachten gilt, die weit über die Kompetenz eines – egal wie guten – Projektmanagers hinausgehen. Das ist auch vollkommen in Ordnung, bedenkt man doch, dass die PRINCE2-Terminologie hierfür eigene Teilprojektleiter, oder wie in PRINCE2 beschrieben, Teammanager gibt, die durch ihr fachliches Know-how hervorstechen. Diese und deren Teammitglieder müs- sen in die Pflicht genommen werden, eine Gesamt-Risikostrategie für das Projekt mitzuentwickeln und vor allem Einzelrisiken auf den unterschiedlichen Ebenen zu identifizieren und unter gewissen Umständen dem Projektmanager zu mel- den. Dieser wiederum ist dann in der Pflicht, die Risiken zu delegieren, zu überwachen und zu steuern.

Umfang

Hierbei handelt es sich um den schnell verwechselten Artgenossen von „Qualität“. Oft wird innerhalb von Projekten die Diskussion geführt, ob Aufgabe X „inscope“ oder „not inscope“ ist; also im Umfang oder nicht im Umfang des Projekts. Diese Diskussion ist absolut wichtig und gerechtfertigt. Jedoch muss sie richtig geführt werden. In der Praxis reden Leute meist von den vom Projekt zu liefernde Eigenschaften. Bei unserer Olympiade zum Beispiel von „Marmor- oder Teppichboden“. Wie aber bereits in der Dimension „Qualität“ gut erläutert wurde, handelt es sich hierbei um Eigenschaften, also dem Zustand des Produktes, also um Qualität, nicht um – wie so oft fälschlicherweise verwendet – Scope/Umfang. Der Umfang beschäftigt sich – plastisch gesagt – mit der Anzahl der Marmorplatten, die benötigt werden.

Nutzen

Als Nutzen wird der erwartete Mehrwert des Projekts bezeichnet. Der Nutzen kann in seiner Art und Güte durchaus unterschiedlich ausfallen. So gibt es den monetären Nutzen: Wenn ich X entwickle, erwarte ich Y an Return on Investment. Hier ist der Blick allein auf den finanziellen Aspekt des Projekts. Darüber hinaus gibt es allerdings auch nichtmonetären Nutzen. So kann die Olympiade neben ihrem finanziell durchaus positiven Effekt vor allem auch Prestige für Lon- don mit sich bringen. Hieraus können sich neue Touristen erschließen, die nach der Olympiade den Urlaub in London verbringen wollen und damit neue Arbeitsplätze in London schaffen. Mit Verlaub, letztlich kann man beinahe alle Gründe so durchkonjungieren, dass man am Ende bei dem Faktor Euro bzw. Geldeinheit landet.

Kommen wir nun nochmal zum Projektsteuerungskreislauf zurück. Oder kurz gesagt zum Inbegriff von „Managen“. Aber was bedeutet eigentlich managen? Der erste Schritt im Managen eines Projekts – oder im Projektsteuerungskreislauf – ist der Schritt „Planen“, welcher natürlich im ersten Anlauf einen enormen Aufwand darstellt. Bleiben wir bei unserem Olympia-Beispiel. Die ersten Planungsmeetings des Projektteams werden durchaus sehr umfangreich und sehr unstrukturiert gelaufen sein. Gleichgültig, welche Dimensionen geplant worden sind: Ob Risiko oder Zeit, ob Budget oder Qualität, es wird am Anfang in nur sehr wenigen Fällen tatsächlich eine ganz konkrete Planung vorhanden sein.

Das ist aber auch nicht schlimm. Der Projekt- steuerungskreislauf ist, wie es der Name schon sagt, ein wiederkehrender Mechanis- mus. Ein Mechanismus, der bewirkt, dass es eine kontinuierliche Planung, Delegation, Überwachung und Steuerung innerhalb eines Projekts gibt. Hierdurch entstehen nicht nur von Durchlauf zu Durchlauf eine feinkörnigere Planung, sondern auch eine höhere Lernrate. Die kontinuierliche Verbesserung wird hierdurch fortlaufend gepflegt. Machen wir das Ganze mal anhand eines Beispiels unserer olympischen Häuser klar.

Planung

Hierbei wird sich der Projektmanager mit seinem Teammanager „Häuserbau“ und anderen wichtigen Personen in einem ersten Planungsmeeting Gedanken über die Lage der neu zu errichteten Häuser gemacht haben. Wichtig ist hierbei zu beachten, dass man mit der höchsten Planungsebene beginnt. Wie hier zum Beispiel die Lage. Es ist zu erwähnen, dass der Projektmanager hierbei kaum fachliches Know-how besitzen muss. Er muss den Gesamtüberblick über die Projektorganisation be- wahren, das Fach Know-how zur Erstellung der Produkte bringt der Teammanager mit. Der Projektmanager sollte zum Beispiel darauf achten, dass die wichtigsten Stakeholder wie zum Beispiel vorgeschriebene Ämter mit am Planungstisch sitzen. Nach- dem das Thema „Lage“ annähernd gut geplant worden ist, geht es um erste Maßnahmen, die operationalisiert werden sollen.

Delegieren

Dies stimmt der Teammanager mit dem Projektmanager ab und nimmt das Ergebnis zur fachlichen Umsetzung mit an sein Team. Der Projektmanager hat somit den zweiten Schritt im Projektsteuerungskreislauf vollzogen: er hat delegiert. Bei der Delegation von Aufgaben ist es wichtig, dem Teammanager genügend Entscheidungstoleranzen mit auf den Weg zu geben. In der Praxis kommt es oft vor, dass der Projektmanager dem Teammanager wenig bis gar keine Entscheidungskompe- tenz mitgibt. Das hat zur Folge, dass der Teammanager sich wegen jeder Kleinigkeit an den Projektmanager zu wenden hat. Das hat dann nicht mehr viel mit gutem Pro- jektmanagement, sondern vielmehr mit unnötigem Mikromanagement – also dem Management von kleinsten Angelegenheiten zu tun.

Hat der Teammanager die Aufgaben und Kompetenzen des Projektmanagers übernommen, beginnt der Projektsteuerungskreislauf auf der nächsten Delegationse- bene von vorne. Auf der von uns aktuell beschriebenen Ebene des Projektmanagers beginnt währenddessen der nächste Schritt im andauernden Projektsteuerungskreislauf: die Überwachung.

Überwachung

Hierbei ist „Überwachen“ keinesfalls negativ zu bewerten. Vielmehr geht es darum, einen qualitätssichernden Mechanismus in das tägliche Projektbusi- ness einfließen zu lassen. Innerhalb des Schrittes „Überwachung“ muss im Vorhinein über die vorherrschenden Parameter gesprochen werden. Es sollten Berichts- und Es- kalationswege und Mechanismen eingerichtet werden, um immer die richtige Infor- mation zum richtigen Zeitpunkt an die richtige Person oder Stelle geben zu können. Wie genau diese Überwachungstools auszusehen haben, wird ebenfalls im Thema „Fortschritt“ genauer beschrieben. Hier sind neben den richtigen Tools auch Meetings beschrieben, welche zu einer adäquaten Überwachung durchgeführt werden sollten.

Steuerung

Im letzten Prozessschritt geht es darum, den in der Überwachung festge- stellten Abweichungen mit Umsetzungsmaßnahmen entgegenzuwirken.

PRINCE2: Die vier integrierten Bausteine

Nachdem wir uns im letzten Abschnitt den Grundlagen des Projektmanagements, an- gehaucht mit einigen PRINCE2-Merkmalen angeschaut haben, gehen wir nun in die Methodik. PRINCE2 kann man im Grunde auf vier einfache Bestandteile aufteilen: Grundprinzipien, Themen, Prozesse und Anpassung an die Projektumgebung. Jeder der vier Bausteine hat eine Daseinsberechtigung in unterschiedlicher Ausprägung. Im Folgenden gehen wir auf die einzelnen Bausteine ein, bevor diese dann Kapitel für Kapitel näher aufgearbeitet und verknüpft werden.

Die 7 Grundprinzipien

Die Grundprinzipien kann man festen Leitsätzen gleich- setzen. Nach der PRINCE2-Terminologie ist jedes der sieben bestehenden Grund- prinzipien zu befolgen, sollte man beabsichtigen, ein PRINCE2-Projekt zu initiie- ren und zu managen. Den 7 Grundprinzipien schenkt dAbschnitt 1.5 noch geson- derte Aufmerksamkeit.

Die 7 Themen

Die 7 Themen beschreiben den Inhalt von PRINCE2 bzw. den In- halt einer richtigen Projektstruktur. Zum Beispiel: Wie man eine richtige Projekt- organisation erstellt oder wie Reportingstrukturen auszusehen haben.

Die 7 Prozesse

Die 7 Prozesse stellen die Ablaufbeschreibung um die 7 Themen herum dar: Wann wer was im Projekt erstellt bzw. durchführt.

Anpassung an die Projektumgebung

Die Anpassung an die Projektumgebung ist in der PRINCE2-Terminologie nicht allzu umfangreich beschrieben, stellt in der Praxis jedoch das größte Thema eines Projektmanagers in Verwendung von PRINCE2 dar. Das liegt daran, dass dieser Baustein die PRINCE2-Terminologie voll- kommen anpassbar und auf sämtliche Projekte adaptierbar macht.

PRINCE2: Die 7 Grundprinzipien

Wie bereits beschrieben, sind die Grundprinzipien wichtige Leitsätze, die in PRINCE2 vorherrschen; Leitsätze, die sich aus rund 30 Jahren richtig gutem Projekt- management ergeben haben. Viele davon wird man im Rahmen seiner eigenen Pro- jekterfahrung als bekannt und bewährt einstufen. Andere bringen interessante, neue Ansätze mit sich. Wer sich im agilen Projektmanagement wie SCRUM oder Kanban bereits auskennt, dem wird auffallen, dass die Grundprinzipien ihrem Zweck, dem Agilen Manifest, sehr nahe sind. Die Inhalte sind freilich unterschiedlich, der Hinter- grund, nämlich das einheitliche Verständnis von Gesetzen, ist hingegen absolut gleichwertig. Die 7 Grundprinzipien sind:

Fortlaufende geschäftliche Rechtfertigung

Dieses Grundprinzip bezieht sich auf den vom Projekt zu liefernden Nutzen oder Mehrwert. Dieser muss von An- fang an gegeben sein, um ein Projekt überhaupt zu initiieren. Ist dies der Fall, kann mit einer Umsetzung des Projekts begonnen werden. Wichtig ist hierbei, dass dieser Nutzen durch eine iterative Vorgehensweise ständig überprüft und gegebenenfalls angepasst wird. Der Nutzen stellt wie in Abschnitt 1.3 (Projekt- steuerungskreislauf) beschrieben eine Projektdimension dar, die der Projektma- nager dauerhaft managen muss. Die geschäftliche Rechtfertigung muss der Pro- jektmanager der PRINCE2-Methodik nach in einem Dokument festhalten, wel- ches durch dauerhafte Anpassung sozusagen „lebt“. Dieses Dokument wird als Business Case beschrieben. Hierzu wird es im Folgenden sogar noch ein eigens zu behandelndes Thema geben.

Bei der Olympiade ist der Nutzen natürlich sehr einfach und umfangreich zu beschrei- ben. Hier sind es die bereits genannten neuen Arbeitsplätze, die aufgrund von Tou- rismus in der Stadt entstehen; nicht zu verachten sind die umfangreichen Einnahmen, die die Londoner Geschäfte zu verzeichnen haben sowie etwaige nichtmonetäre Prestigeeffekte für die Stadt.

Lernen aus Erfahrung

Dieses Grundprinzip befasst sich im Grunde mit den Erfahrungen aus Vorgängerprojekten. Erfahrung muss hierbei keinesfalls negativ zu bewerten sein. Durchaus können gute Ansätze aus Vorgängerprojekten ebenfalls Anwendung finden. Im Grunde genommen ist die PRINCE2-Methodik als eine große Sammlung der besten Anwendungen aus Vorgängerprojekten nichts anderes als die Operationalisierung dieses Grundprinzips. Dieses Grundprinzip findet meist zu Beginn des Projekts eine intensive Anwendung, da in frühen Projektphasen eine enorme Unsicherheit herrscht und hier ein starkes Erfahrungsregister aus Vorgängerprojekten gute Unterstützung leisten kann.

In der Geschichte fanden bereits 100 Olympiaden statt. Da wird es doch ein Leichtes sein, auf die Erfahrung jener zurückzugreifen und die Olympischen Spiele von London hocheffizient zum Erfolg zu führen. – Das ist leider zu naiv gedacht; unterscheiden sich die Vorgängerprojekte doch stark hinsichtlich dem Geist der Zeit, Region, Kultur. Selbst wenn die Rahmenbedingungen annähernd gleichbleiben, ist hierdurch keine Erfolgsgarantie zu erwarten, nur weil man auf Erfahrungen aus Vorgängerprojekten zurückgreift. Die Chance, Wiederholungsfehler zu vermeiden ist jedoch allemal gegeben, weshalb die Chance auf einem Projekterfolg zumindest ausdrücklich steigt.

In der Praxis fällt auf, dass ein bewusstes „Lernen aus Erfahrung“, meist nur sehr halbherzig betrieben wird. Natürlich, unterbewusst haben Senior Projektmanager einen enormen Erfahrungsschatz, auf den sie zurückgreifen, auch ohne irgendwelche Lessons Learned Meetings durchzuführen. Die Erfahrung zeigt jedoch, dass regelmäßige Lessons Learned Meetings einen für den Projekterfolg positiven Effekt mit sich brin- gen. Hierbei ist zu beachten, dass die Betonung auf „regelmäßig“ nicht auf „nur am Ende eines Projekts“, wie es doch in den meisten Projekten gehandhabt wird, liegen muss. Ein regelmäßiges „sich zu hinterfragen“ ist im agilen Projektmanagement ein gelebter Ansatz. Auch im klassischen Projektmanagement gehört es, der Theorie zufolge (PRINCE2-Methodik) schon längt zum Tagesgeschäft.

Definierte Rollen und Verantwortlichkeiten

Wer kennt es nicht? Innerhalb eines Projekts kommt (gefühlt) aus dem Nichts eine Aufgabe auf, welche zwar bekannt war, jedoch hatte niemand dafür Sorge getragen, dass diese auch ordnungsgemäß erfüllt wurde. Grund hierfür ist, dass sich niemand dafür verantwortlich gefühlt hat. Dieser Planlosigkeit der Verantwortung wirkt die PRINCE2-Methodik stark entgegen, in dem sie klare Rollen (Projektmanager, Teammanager uvm.) vorgibt und dahinter klar deren Anforderungsprofil, deren Kompeten- zen sowie Rechte und Pflichten aufzeigt.

Bei der Olympiade hat der Projektmanager all seinen Teammanagern, also den fach- lichen Teilprojektleitern, genau die richtige Verantwortung delegiert. Bei Projekten dieser Größe ist es nicht möglich, dass der Projektmanager alleine die zum Beispiel Budgetverantwortung für sämtliche Teilprojekte trägt. Die Teammanager können nicht frei Budgets verteilen. Sie haben vielmehr seitens des Projektmanagers gewisse Budget-Toleranzwerte übergeben bekommen, innerhalb deren sie frei und ohne ständige Abstimmung mit dem Projektleiter interagieren können, sogar müssen.

Wie funktioniert das in der Praxis?

Wichtig ist hierbei, das Grundprinzip der klaren Rollen und Verantwortlichkeiten richtig zu leben, da sonst der Teilprojektleiter und der Teammanager wegen Kleinigkei- ten die Abstimmung mit dem Projektmanager suchen, da dieser keine klaren Verantwortlichkeiten für sein Projektteam vorgegeben hat.

In der harten Praxis wird das Thema „Rollen und Verantwortlichkeiten“ so gelebt, dass zwar offizielle Verantwortlichkeiten delegiert wurden, jedoch die jeweilige Hierarchiestufe trotzdem in ständiger Abstimmung mit der nächst höheren Hierarchiestufe ist. Das liegt natürlich daran, dass es Situationen gibt, die dies durchaus hergeben, zum anderen liegt es aber auch daran, dass die jeweiligen Mitarbeiter Angst haben zu entscheiden. Hier muss dann die höhere Hierarchiestufe eingreifen und dem Mitarbeiter entweder diese Angst nehmen oder den Mitarbeiter austauschen, da die Führungskraft durch eine derartige Arbeitsweise schnell in ineffizientes Mikromanagement verfällt.

Steuern über Managementphasen

Dass sich ein Projekt durch einen regelmäßigen und wiederkehrenden Kreislauf ausmacht, ist inzwischen klar. Dass dieser Kreislauf unter anderem über so genannte Managementphasen zu funktionieren hat, ist an der Stelle neu. Eine Managementphase stellt, in der Logik von PRINCE2, eine abgeschlossene, eigenständige Projektphase dar. Diese kann zum Beispiel „Initiierungsphase“ oder „Testphase“ heißen. Alleine der Name hinter der Managementphase gibt Aufschluss darüber, was in der jeweiligen Phase vonstatten- geht.

Immer am Ende einer jeweiligen Phase muss der Projektmanager an das Entscheidungskomitee, in PRINCE2 „Lenkungsausschuss“ (LA) genannt – in der Praxis aber auch oft als Steering-Komitee bezeichnet – reporten. Hierdurch wird klar, dass ein Abschluss einer Managementphase ein essentielles Ereignis inner- halb eines Projekts darstellt. Ein Ereignis, in dem der Projektmanager sich natürlich rechtfertigen muss, der Lenkungsausschuss wichtige Entscheidungen treffen muss und auch sonstige, für eine Eskalation nicht ausreichende Ereignisse, Vorkommnisse oder einfach Anliegen besprochen werden.

Wie funktioniert das?

Beim Projekt Olympia bietet es sich natürlich ebenfalls an, die Errichtung der Olympiade in logische Managementphasen zu unterteilen. Hier würden wir zum Beispiel eine Initiierungsphase zur Planung der Anforderungen durchführen, gefolgt von einer Planungsphase zur Strukturierung des Projekts inklusive Verteilung der Rollen und Verantwortlichkeiten. Das nur als ein paar wenige Phasen von vermutlich hunderten.

In der Praxis werden Phasen oft wenig gelebt. Das liegt zum einen an dem hohen Stresslevel der Projektmanager, welche die Einteilung in logische aufeinanderfolgende Phasen oft in ihrer Projektplanung schlichtweg vergessen oder sie fehlerhaf- terweise als obsolet ansehen. Neben dem tatsächlichen Vorteil, dass durch eine klare Gliederung der Phasen ein vereinfachtes Fortschritts-Tracking vonstattengeht, da immer zu einem genau bestimmten Zeitpunkt reportet werden muss, ist es auch ein nicht zu verkennender psychologischer Vorteil, dass man Phasen tatsächlich ab- schließt. Die Projektorganisation ist in ihrem täglichen Business nur von Problemen und Risiken sowie von Zeit- und Budgetdruck getrieben. Da ist der Zwischeneffekt, etwas geschaffen bzw. geschafft zu haben, ein hervorragender Mechanismus, um die Motivation dauerhaft ausreichend hochzuhalten.

Steuern nach dem Ausnahmeprinzip

Ist das Grundprinzip „Steuern über Managementphasen“ als ein zeitlich getriebener Überwachungs- und Planungsme- chanismus zu werten, bezieht sich das Grundprinzip „Steuern nach dem Ausnah- meprinzip“ deutlich mehr auf die Ereignissteuerung. Um dieses Grundprinzip hin- reichend gut zu leben, muss dieses Prinzip auch außerhalb der Projektorganisation, also der in das Projekt aufgehängten Linie, bekannt, anerkannt und gelebt werden. Hierbei geht es fast um eine Art Wert, also eine innere Überzeugung. Man kann auch von einer Führungsphilosophie sprechen. Bekannt ist dieses Prinzip neben der Terminologie auch aus der angewandten Be- triebswirtschaftslehre, in der dieses Prinzip neudeutsch als „Management by Exception“ gelehrt wird.

Hierbei geht es im Grunde darum, als Führungskraft Ver- antwortung an die nächst tiefere Hierarchieebene zu delegieren. Das bringt den immensen Vorteil mit sich, dass zum einen der in unserem Beispiel typische Projektmanager durch die Einbeziehung seiner Teammanager entlastet wird und die neu eingebundenen Mitarbeiter darüber hinaus über ihren Zuwachs an Verant- wortung viel besser mit in den Projekterfolg einbezogen und ggf. noch zusätzlich motiviert werden. Gerade bei Großprojekten, bei denen es eine Vielzahl von Teammanagern gibt, muss das Prinzip gelebt werden, da ansonsten sehr schnell eine Überlastung des Projektmanagers eintritt.

Wie funktioniert das Ausnahmeprinzip?

Damit dieses Ausnahmeprinzip funktioniert, sind einige wichtige Bestandteile zu beachten: Es sollte im Vorhinein eine klare Kommunikation der Rollen und Verantwortlichkeiten (siehe Grundprinzip Definierte Rollen und Verantwortlichkeiten) durchgeführt werden. Im Weiteren müssen auch Toleranzen, also Bereiche, in denen der Projektmanager und der Teammanager, ohne die nächst höhere Hierarchiestufe einzubinden, in sämtlichen Dimensionen, also Zeit, Budget, Qualität, Risiko, Umfang und Nutzen, mit- delegiert werden.

Der Olympia-Projektmanager hat in dieser Hinsicht von dem Lenkungsausschuss eine Budgetverantwortung von rund 200 Millionen Euro pro Managementphase übertra- gen bekommen. Diese Summe gilt es dann im Rahmen der richtigen Delegierung an die Teammanager bzw. Teilprojektleiter bedarfsgerecht zu verteilen. Hierbei gibt die PRINCE2-Terminologie nicht vor, ob es Bottom Up, also mit einem ersten Planungsvorschlag der Teammanager, oder Top Down, also mit einem ersten Planungsvor- schlag der Projektmanager, verteilt werden soll. Vielmehr geht es darum, in einem gemeinsamen, regelmäßig stattfindenden Planungsmeeting Planungs- und daraus entstehenden Budgetmehrbedarf zu ermitteln und im Rahmen der Budget-Toleranzen der jeweiligen Managementphase zu verteilen.

Wie funktioniert das in der Praxis?

In der Praxis wird dies meist deutlich intuitiver gehandhabt. Hier geben in aller Regel die Teammanager eine erste Indikation vor, auf deren Basis der Projektmanager dann im Rahmen seiner von dem Lenkungsausschuss vorgegebenen Toleranzen eine Budgetanpassung in seinem Sinn vornimmt. Die Tatsache, dass die Teammanager mit einem besonders großen Puffer an Budget in die Verhandlung mit dem Projektmana- ger gehen, ist ein ungeschriebenes Gesetz. Ebenfalls ist es ein ungeschriebenes Gesetz, dass der Projektmanager sich über diese Tatsache bewusst ist und deswegen den Teammanagern überdurchschnittlich viel der Budgetplanung wieder kürzt.

Im Übrigen spielt sich dieses Szenario auf allen Planungsebenen, also Teammanager, Projekt- manager, Lenkungsausschuss und Unternehmensmanagement ab: Die tiefere Ebene kommt mit einer deutlich höheren Budgetplanung als benötigt zur nächst höheren Hierarchieebene, welche wiederum deutlich mehr der Planung streicht, als eigentlich benötigt wird, womit das Ergebnis im Grund genau dem Planungsbedarf entspricht. Beide Parteien sind sich dem in den meisten Fällen bewusst.

Produktorientierung

In den meisten Projektmeetings hört man Teilnehmer im- mer nur über die Projektaktivitäten sprechen: die Aktivitäten der letzten Woche, die dieser Woche, und welche schiefliefen. Hierbei verliert man jedoch schnell den Blick auf das große Ganze und auf das, was am Schluss das Projekt liefern soll: das Produkt. Diesen Blick wiederherzustellen ist das Ziel des Grundprinzips der „Produktorientierung“. Dem Grundprinzip zufolge geht es darum, den Blick auf die vom Projekt zu liefernden Produkte zu lenken. Wobei Produkte hier nicht unbedingt physische Produkte sein müssen, sondern auch immaterielle Produkte oder Dienstleistungen sein können.

Das spiegelt sich vor allen in der Planung des Projekts wider. Hierbei plant man von dem Projektendprodukt, also dem Produkt, welches das Projekt am Ende als Output generieren soll, hin zu den jeweils tiefe- ren, feineren Produktgruppen. Erst am Ende der Planungstiefe, also dann, wenn man auf der von den Teams granularsten zu liefernden Produktebene angekommen, teilt man diese (Teil)-Teilprodukte auf die dafür notwendige Aktivitäten auf. Es kommt also eine Art Rückwärtsplanung zum Einsatz.

Die Olympiade wurde so, von dem großen vom Projekt zu liefernden Endprodukt der stattfindenden Olympiade, in tausende Teilprodukte zerlegt: Häuser, Stadien, neue U-Bahn-Stationen, Hotels, rechtliche Angelegenheiten etc.

Anpassung an die Projektumgebung

PRINCE2 ist eine sehr umfangreiche Pro- jektmanagement-Methodik. Dabei ist sie für Großprojekte absolut geeignet, durch die Anpassung an die Projektumgebung jedoch so adaptierbar und gene- risch, dass mit der Methodik annähernd jedes Projekt gemanagt werden kann.

Bei einem Großprojekt wie der Olympiade ist die Anpassung an die Projektumgebung sicherlich weniger gegeben, da, je größer ein Projekt ist, ein höherer administrativer Aufwand sich a) in den Gesamtkosten weniger bemerkbar macht als in kleineren Pro- jekten und b) auch einfach gegeben sein muss, damit das Projekt weiterhin steuerfä- hig bleibt.

Oft fällt auf, dass die Tendenz innerhalb der meisten Projekte eher in Richtung „Admin Overhead“, also in Richtung zu vieler Templates, zu viel Administration, zu vieler Mee- tings geht, als in eine schlanke und effiziente, also eine angepasste Projektumge- bung. Das liegt auch unter anderem an dem oft vorhandenen Irrglauben, dass wenig bis gar keine Administration Agile bedeutet und viel und umfangreiche Administra- tion automatisch „klassisches bzw. Wasserfall-Projektmanagement“. „Managt man of- fiziell ein ‚klassiches Projekt, sollte man daher automatisch einen hohen Administra- tionsaufwand mit sich bringen“: so zumindest die falsche Annahme vieler Projekt- manager. PRINCE2 sagt hierzu allerdings klar, dass die Administration sich der Projekt- umgebung anzupassen hat. Wenn das Projektbeispiel weniger risikobehaftet ist, kann einem Projektmanager mehr Freiraum zu Verfügung gestellt werden als wenn ein hohes Risiko vorliegt.

PRINCE2: Die 7 Themen

Wie bereits beschrieben, sind die 7 Grundprinzipien Werte, die einen erfolgreichen Projektablauf möglichst positiv beeinflussen sollen. Für die Werte muss es allerdings noch eine Beschreibung zur Umsetzung geben. Diese Beschreibung stellen die sieben Themen dar. Sie geben eine Antwort auf die Frage „Wie ist es zu tun?“ Die Inhalte müssen während des Projekts kontinuierlich behandelt werden. Im Folgenden sind die sieben Themen aufgeführt und kurz beschrieben. Im den darauffolgenden Kapi- teln wird jedes einzelne Thema, auch im Zusammenspiel mit den Prozessen, aufgear- beitet. Die sieben Themen sind:

Business Case

Das Thema „Business Case“ wird durch das Grundprinzip der „fort- laufenden geschäftlichen Rechtfertigung“ getrieben. Es geht darum, Mechanis- men einzurichten, welche a) dazu da sind, eine geschäftliche Rechtfertigung zu erlangen, und b) sie kontinuierlich zu pflegen. Im Kern geht es darum, ein Projekt so auszurichten, damit es über die gesamte Laufzeit auf Ziele zum Beispiel der Organisation abzielt, es einen Nutzen bietet. Im Laufe des Buches gehen wir noch auf ein bestimmtes Dokument, den Business Case, tiefer ein. Dieses Dokument ist sozusagen die aus dem Thema „Business Case“ herauskristallisierte Essenz, die schriftlich festgehalten wird. Hierbei ist zu beachten, dass nicht jedes Thema ein eigenes Dokument mit sich bringt.

Organisation

Hierbei widmen wir uns der Operationalisierung des Grundprin- zips der „definierten Rollen und Verantwortlichkeiten“. Das Thema beschreibt die benötigten Rollen, die Rollenverteilungen, welche sich ausschließen und welche Kompetenzen und Verantwortungsbereiche hinter den verschiedenen Rollen festgeschrieben sein müssen. Es beantwortet die Frage, „wer?“ innerhalb einer Projektorganisation für die jeweilige Umsetzung verantwortlich ist.

Qualität

Das Thema „Qualität“ beschreibt in seiner vollen Ausprägung den rich- tigen Umgang mit den Stakeholdern in Bezug auf die vom Projekt zu erfüllenden Anforderungen. Das hier wichtigste Grundprinzip ist die „Produktorientierung“. Oft kommt es vor, dass Kunden zu Beginn eines Projekts mit nur sehr subjektiven Äußerungen an das Projektteam herantreten. „Das Haus der Chinesen soll deren Kultur entsprechen“ könnte bei der Olympiade eine typisch formulierte erste An- forderung sein. Die Aufgabe des Themas „Qualität“ ist es in dem Zusammenhang, dem Projektmanager Leitlinien an die Hand zu geben, mit der er es schafft, die zuerst nur sehr weich formulierten Kundenqualitätserwartungen in hart defi- nierte Projektabnahmekriterien zu überführen. Es geht darum, die Frage nach dem „Was“ zu beantworten.

Pläne

Hierbei geht es um die Frage, „wie“ etwas geliefert wird. Weiß man bereits aus einer guten Ausarbeitung des Themas „Qualität“, was der Kunde wünscht, muss man sich im nächsten Schritt mit einer Umsetzung der Kundenwünsche be- fassen. Damit befasst sich das Thema „Pläne“. Hierbei ist zu beachten, dass nicht nur die eigentliche Umsetzung geplant wird, sondern auch die Art und Weise, „wie“ die Planung innerhalb eines Projekts durchgeführt wird. Welche Tools wer- den dafür genutzt? Wie sollte das Layout eines von dem Projekt zu liefernden Pro- jektplans aussehen? Wie feinkörnig sollte die Projektplanung aufgestellt sein? All diese Fragen werden neben der eigentlichen Planung innerhalb eines Projekts im Thema „Pläne“ genauer beschrieben. Auch dieses am Thema hat als Grundprinzip die „Produktorientierung“ und das „Steuern über Managementphasen“.

Risiko

Wie bereits beschrieben, wird in der Terminologie von PRINCE2 das Risiko nicht per se als negativ gewertet. Vielmehr geht es darum, Risiken als Unsicher- heiten anzusehen, die Auswirkungen sowohl in die negative als auch in die posi- tive Richtung haben können. Wie mit Unsicherheiten eines Projekts umgegangen werden soll, welcher Prozess nach der PRINCE2-Terminologie verwendet werden soll, welche Strategien es für Gegenmaßnahmen gibt, wird alles tiefgehend im Folgenden beim Thema „Risiko“ beschrieben.

Änderungen

Dieses Thema befasst sich mit einer Steuerung der Änderung der Kundenanforderungen. Es geht hierbei in erster Linie darum, Struktur in das Än- derungssteuerungsverfahren zu bringen: Welche Arten von Änderungen gibt es? Welche prozessualen Unterschiede liegen hinter den verschiedenen Arten von Änderungen? Die Antworten liefert das Thema „Änderungen“. Darüber hinaus befasst sich das Thema „Änderungen“ mit dem Konfiguarationsmanagement in- nerhalb eines Projekts. Das Konfiguarationsmanagement beschreibt, kurz gesagt, die Art und das Management von verschiedenen Versionen von Produkten. Das klingt zunächst sehr kryptisch, und zugegebenermaßen ist das nicht für alle Pro- jekte adaptierbar. Jedoch ist u.a. die Versionierung, besonders in der Software- entwicklung, ein wichtiges Must-Have. Versionierung bedeutet, dass jede neu re- leaste Version der Software sich klar von der letzten unterscheidet und auch durch eine Versionsnummer entsprechend gekennzeichnet wird.

Fortschritt

Dieses Thema beschreibt, wie die Reporting-Kultur, die Eskalationswege und der Toleranzbereich eines Projekts aussehen sollen. Es soll hierdurch sichergestellt werden, dass zu jedem Zeitpunkt eine Aussage über den Projekt- fortschritt getroffen werden kann und der Projektmanager oder der Lenkungs- ausschuss dadurch in die Lage versetzt wird, zu jedem Zeitpunkt eine Entschei- dung, die richtige Entscheidung treffen zu können.

PRINCE2: Die 7 Prozesse

Die 7 Prozesse stellen die Ablaufbeschreibung zu den sieben Themen dar.

Ein Prozess im Sinne von PRINCE2 hat dieselbe Beschreibung wie im Sinne der allgemeinen Betriebswirtschaftslehre: für einen definierten Input wird über eine vorgeschriebene Abfolge von Aktivitäten Wertschöpfung generiert und ein definierter Out- put als Mehrwert geliefert.

Das Zusammenspiel der 7 Grundprinzipien mit den 7 Themen und 7 Prozessen kann man wie folgt zusammenfassen:

Innerhalb der Managementphasen stellen die Prozesse die vorgegebenen Aktivitäten, von bereits vor einem Projekt bis zum Abschluss eines Projekts, dar. Innerhalb der vorgegebenen Prozesse. werden die sieben Themen – unter Berücksichtigung des vierten Bausteins von PRINCE2, der Anpassung an die Projektumgebung – behandelt und dadurch die sieben Grundprinzipien eingehalten.

Vorbereiten eines Projekts – Starting up a project (SU 1)

Der Prozess SU kommt bereits vor Beginn eines Projekts zur Anwendung, mit dem Ziel, herauszufinden, ob sich ein Projektbeginn lohnt. Dieser Prozess kommt einer Vorstudie ausgesprochen nahe. Eine Vorstudie kommt vor allem bei Großprojek- ten zum Einsatz, wo für eine solide Planung ein kurzes Vorprojekt initiiert wird, um die Planung für das Großprojekt an sich sicherstellen zu können.

Lenken eines Projekts – Directing a Project (DP 2)

Der Prozess DP ist für den Lenkungsausschuss entwickelt, damit dieser im Rah- men seiner Möglichkeiten zu jeglichem Punkt im Projekt die letztendliche Kon- trolle behalten kann.

Initiieren eines Projekts – Initiating a Project (IP 3)

Der Prozess IP ist innerhalb des Projekts der Hauptprozess der ersten Projekt- phase. Er dient zur allgemeinen Orientierung, zur Erstellung eines Plans und zur ersten Arbeitsverteilung.

Managen eines Phasenübergangs – Managing a stage boundary (SB 4)

Der Prozess SB ist ein sich je nach Anzahl an Managementphasen wiederkehren- der Prozess, der für den Übergang von einer Projektphase in die nächste verant- wortlich ist.

Steuern einer Phase – Controlling a Stage (CS 5)

CS ist der in PRINCE2 am umfangreichsten beschriebene Prozess. Das liegt daran, dass die Haupt-Managementarbeit des Projektmanagers sich in diesem Prozess abbildet.

Managen der Produktlieferung – Managing Product delivery (MP 6)

MP dient dazu, dem Projekt- und Teammanager einen Prozess an die Hand zu geben, über den sie ihre Arbeit und Arbeitspakete einander übergeben können.

Abschließen eines Projekts – Closing a Project (CP 7)

Im Prozess CP wird dem Projektmanager ein Rahmenwerk zu einem erfolgreichen Projektabschluss mit an die Hand gegeben. Ziel ist es, alle notwendigen Doku- mente und Formalitäten über diesen Prozess abzudecken.

Anpassung an die Projektumgebung

PRINCE2 ist als ein Projektmanagement Framework sehr generisch gehalten. Hieraus resultiert der Vorteil einer vielfältigen Einsetzbarkeit. Es ist jedoch auch wichtig zu erwähnen, dass dadurch ein hohes Maß an Anpassungsfähigkeit gegeben sein muss. Diese wird vor allem in der Ausprägung „PRINCE2 Agile“ deutlich.

PRINCE2 Agile ist anders wie viele Leute vermuten keine eigene Methode. Vielmehr handelt es sich um eine Ausprägung, eine von den Rechteinhabern definierte Art der Anpassungen von PRINCE2, in Richtung der agilen Welt, der agilen Techniken und der agilen Vorgehenweißen. Es wird hierbei die Frage beantwortet, wie PRINCE2 als immer noch wichtigstes Projektmanagement Framwork, mit agilen Produktentwick- lungsmethoden wie z.B Scrum, Kanban, Lean StartUp o.Ä. kombiniert werden kann.

Was bedeutet aber nun Anpassungsfähigkeit oder Tailoring? Es bedeutet, dass die- Methodik in ihrer theoretischen Reinheit A) niemals zu 100% angewendet werden kann und B) durch die generische Formulierung, durch einfache “Anpassungen“, auf sämtliche Projekte adaptierbar ist.

Dies könnte zum Beispiel mit den folgenen Optionen geschehen:

Die Vereinfachung der Methodik

Zum Beispiel Techniken und Praktiken werden schlanker gestaltet. Das hat vor allem in Bereichen, wo mit Agilität gearbeitet wird, einige Vorteile. Da dort oft auf Dokumente und Berichte verzichtet wird bzw. sie sehr schlank eingesetzt werden.

Die Formalisierung bzw. Informalisierung

Zum Beispiel Berichte oder Meetings werden bei dem Mittagessen abgehalten. Auch dieser Gedanke trifft aktuell den Zahn der Zeit. Das Mindset vieler Mitarbeiter geht aktuell eher in die Richtung „Mee- tings nerven”. Weshalb eine Vereinfachung einen hohen Grad an Zustimmung in- nerhalb der Unternehmen erfährt.

Die Umgestaltung von Formaten

Zum Beispiel Berichte oder Tabellen werden in ihrer Darstellung verändert. Oft kommt das aufgrund von externen Anforderungen wie z.B. Regulatorik oder Style-Guides zum Tragen. Dies hilft, dass PRINCE2 nicht durch z.B. Unternehmensvorgaben aus dem Rennen genommen wird.

Die Zusammenführung / Splittung

Zum Beispiel werden viele einzelne Berichte in einem großen Bericht zusammengeführt. Hier hat PRINCE2 selbst erkannt, dass eine gewisse Komplexität und Schwerfälligkeit vorhanden sind. Und somit eine Verschlankung vor allem für kleine Projekte Sinn machen kann.

Das Renaming

Zum Beispiel wird in einer Organisation das Wort „Kunde“ anders als in PRINCE2 definiert. So nennt man den Kunden im Projekt „Abnehmer“. Alternativ werden Rollen in PRINCE2 an die bestehenden Rollen eines Unternehmens angepasst. Diese Hintertür benutzt PRINCE2 für Unternehmen und Menschen, die mit dem Mindset „Es bleibt alles so wie es ist” an den Tag gehen. Mit diesem Trick kann ein PRINCE2-Projektmanager den Stakeholdern des Projekts das Gefühl geben, dass alte Strukturen (vor allem seine gefühlte Macht) bestehen bleiben können, aber dennoch neue und bessere Methoden eingeführt werden.

Nicht angepasst werden hingegen die 7 Grundprinzipien. Diese bleiben im vollen Maße bestehen. Wenn man sich diese Vorschläge zur Anpassung von PRINCE2 anschaut, wird man erkennen, dass diese vereinzelt Sinn machen, vereinzelt sehr ähnlich sind bzw. einen sehr ähnlichen Sinn verfolgen. Nämlich der Anpassbarkeit auf die Gegebenheiten. Und manche Vorschläge aus purem Überlebenswillen von PRINCE2 innerhalb von alten und „es-ändert-sich-nichts”-getriebenen Unternehmen vorgeschlagen werden.

PRINCE2: Wie kannst du zertifiziert werden?

Die Regularien, um die Zertifizierung von PRINCE2 zu erlangen, sind im Vergleich zu vielen anderen Zertifizierungen sehr eindeutig und klar geregelt. Seit 2017 haben die Rechteinhaber von PRINCE2, AXELOS, entschieden, die Zertifizierung ausschließlich über das Prüfungsinstitut PEOPLECERT zu vergeben. PEOPLECERT ist ein weltweit führendes Zertifizierungsinstitut, das die Kompetenz besitzt, Trainingsinstituten wie der Agile Heroes GmbH die Akkreditierung für PRINCE2-Trainings und -Prüfungen zu vergeben. Diese Akkreditierung testiert die Qualität unserer Trainings, Online-Kurse, Materialien und Büchern auf höchstem Niveau.

Innerhalb von PRINCE2 gibt es verschiedene Zertifizierungslevel und sogar zwei verschiedene Zertifizierungsstränge. Zum einen gibt es den Weg der klassischen PRINCE2 Methode und zum anderen selbstverständlich den von PRINCE2 Agile. Den Unterschied zwischen beiden Varianten haben wir dir hier und hier bereits ausführlich erklärt. Solltest du dazu dennoch weitere Fragen haben, dann melde dich gerne bei uns. Wir helfen dir gerne weiter. Um es kurzzufassen: PRINCE2 Agile ist eine hybride Projektmanagement Methode, die sowohl die Vorteile einer klassischen Methode wie zum Beispiel PRINCE2, mit denen einer agilen Methode wie zum Beispiel SCRUM vereint.

Jetzt unseren PRINCE2 Onlinekurs buchen!

PRINCE2 Zertifizierungen: Foundation

Die PRINCE2 Foundation Prüfung ist die Grundlagenprüfung, die zum Beispiel auch auf Basis unseres Buches geschrieben und bestanden werden kann. Die Prüfung schließt du mit dem Zertifikat PRINCE2 Foundation ab. Für die Prüfung hast du ganze 60 Minuten Zeit. Innerhalb dieser Zeit musst du 60 Fragen beantworten. Damit die Prüfung als „bestanden“ gilt, müssen mindestens 33 Fragen bzw. 55% richtig beantwortet werden. Die Prüfung wird zudem als „Closed Book“-Prüfung abgehalten, was bedeutet, dass keine Hilfsmittel erlaubt sind. Die Fragen sind im Single Choice-Format gestellt. Es ist immer nur eine Antwort richtig. Die Antwortkästchen müssen hierbei lediglich angekreuzt werden.

PRINCE2 Zertifizierungen: Practitioner

Die PRINCE2 Practitioner-Prüfung ist die Fortgeschrittenen-Prüfung. Wer diese Prüfung absolvieren möchte, muss bereits eine PRINCE2 Foundation- Zertifizierung vorweisen oder diese direkt vor dem Fortgeschrittenentraining zum PRINCE2-Practitioner erlangen. Die Prüfung kann ferner nur abgelegt werden, wenn man an einem PRINCE2 Practitioner-Training einer akkreditieren Trainingsorganisation teilgenommen hat. Die Prüfung schließt mit dem Zertifikat „PRINCE2 Practitioner“ ab. Für die Prüfung hast du 2,5 Stunden Zeit. Innerhalb dieser Zeit musst du 80 Fragen beantworten. Damit die Prüfung als „Bestanden“ gilt, müssen mindestens 44 Fragen bzw. 55% richtig beantwortet werden. Die Prüfung wird zudem als „Open Book“-Prüfung abgehalten, was bedeutet, dass das offizielle PRINCE2 Manuel Book als Hilfsmittel verwendet werden darf und auch sollte. Die Prüfung basiert auf einem Beispielprojekt, welches mit der Prüfung zusammen ausgeben wird. Die Fragen sind im Single Choice- und Multiple Choice-Format gestellt.

PRINCE2 Zertifizierungen: Agile Foundation

Als weiteren Zertifzierungsweg gibt es neben der klassichen PRINCE2 Foundation auch die Agile Foundation. Hierbei wird von Anfang an ein auf die Anforderungen der agilen Welt angepasstes PRINCE2 Agile, gelehrt. Die Prüfung dauert rund 60 Minuten, innerhalb dieser Zeit musst du 50 Fragen beantworten. Davon müssen 55% richtig beantwortet werden.

PRINCE2 Zertifizierungen: Agile Practitioner

Der Agile Practitioner bietet sich wunderbar als Variante zur agilen Vertiefung und Anpassung von PRINCE2 an. Unserer Meinung nach ist die Kombination von PRINCE2 Foundation in der klassichen Variante und PRINCE2 Agile Practitioner optimal. Hierdurch lernt man das grundlegende PRINCE2-Verständnis in Kombination mit einer Anpassung nach PRINCE2 Agile und kann somit beide Welten perfekt kombinieren. Die Prüfung dauert 2,5 Stunden, innerhalb dieser Zeit müssen 50 Fragen beantwortet werden. Davon 60% richtig.

Hier geht's zum Onlinekurs für PRINCE2 Agile

PRINCE2 Zertifizierungen: Professional

Der PRINCE2 Professional ist die höchste Zertifizierung, die es innerhalb von PRINCE2 gibt. Hierbei ist zu beachten, dass es sich hierbei um keine Prüfung, sondern um ein 2,5-tägiges Assessment handelt. Innerhalb der 2,5 Tage muss der Prüfling sein geballtes PRINCE2-Wissen vor einem Moderator und zwei Assessoren unter Beweis stellten. Das Assessment schließt mit dem Zertifikat „PRINCE2 Professional“ ab.