Читать книгу: «PRINCE2»

1.5Die 7 Grundprinzipien

Wie in Abschnitt 1.4 beschrieben, sind die Grundprinzipien wichtige Leitsätze, die in PRINCE2 vorherrschen; Leitsätze, die sich aus rund 30 Jahren richtig gutem Projektmanagement ergeben haben. Viele davon wird man im Rahmen seiner eigenen Projekterfahrung 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 Hintergrund, 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 Anfang 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 (Projektsteuerungskreislauf) beschrieben eine Projektdimension dar, die der Projektmanager dauerhaft managen muss. Die geschäftliche Rechtfertigung muss der Projektmanager der PRINCE2-Methodik nach in einem Dokument festhalten, welches 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 beschreiben. Hier sind es die bereits genannten neuen Arbeitsplätze, die aufgrund von Tourismus 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 bringen. 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 Kompetenzen sowie Rechte und Pflichten aufzeigt.

Bei der Olympiade hat der Projektmanager all seinen Teammanagern, also den fachlichen 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.

Wichtig ist hierbei, das Grundprinzip der klaren Rollen und Verantwortlichkeiten richtig zu leben, da sonst der Teilprojektleiter und der Teammanager wegen Kleinigkeiten 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 vonstattengeht. 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 innerhalb 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. Welche Personen bzw. Stakeholder in einem Lenkungsausschuss sitzen, wird im Thema „Organisation“ in Abschnitt 2.3 konkret beschrieben. Wie lange eine Managementphase dauert und wie viele es davon gibt, wird ebenfalls noch konkreter beim Thema „Fortschritt“ in Abschnitt 3.5 beschrieben.

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 fehlerhafterweise 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 abschließ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 Planungsmechanismus zu werten, bezieht sich das Grundprinzip „Steuern nach dem Ausnahmeprinzip“ deutlich mehr auf die Ereignissteuerung. Um dieses Grundprinzip hinreichend gut zu leben, muss dieses Prinzip auch außerhalb der PRINCE2-Projekt-organisation, 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 PRINCE2-Terminologie auch aus der angewandten Betriebswirtschaftslehre, in der dieses Prinzip neudeutsch als „Management by Exception“ gelehrt wird. Hierbei geht es im Grunde darum, als Führungskraft Verantwortung 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 Verantwortung 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. 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, mitdelegiert werden.

Der Olympia-Projektmanager hat in dieser Hinsicht von dem Lenkungsausschuss eine Budgetverantwortung von rund 200 Millionen Euro pro Managementphase übertragen 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 Planungsvorschlag 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.

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 Projektmanager 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, Projektmanager, 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 immer 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 tieferen, 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 Projektmanagement-Methodik. Dabei ist sie für Großprojekte absolut geeignet, durch die Anpassung an die Projektumgebung jedoch so adaptierbar und generisch, 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 Projekten 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 Meetings geht, als in eine schlanke und effiziente, also eine angepasste Projektumgebung. Das liegt auch unter anderem an dem oft vorhandenen Irrglauben, dass wenig bis gar keine Administration Agile bedeutet und viel und umfangreiche Administration automatisch „klassisches bzw. Wasserfall-Projektmanagement“. „Managt man offiziell ein ‚klassisches‘ Projekt, sollte man daher automatisch einen hohen Administrationsaufwand mit sich bringen“: so zumindest die falsche Annahme vieler Projektmanager. PRINCE2 sagt hierzu allerdings klar, dass die Administration sich der Projektumgebung anzupassen hat. Wenn das Projektbeispiel weniger risikobehaftet ist, kann einem Projektmanager mehr Freiraum zu Verfügung gestellt werden, als wenn ein hohes Risiko vorliegt.

Neben dem 7. Grundprinzip stellt die Anpassungen an die Projektumgebung (Tailoring) auch einen der 4 Bestandteile von PRINCE2 in Gänze dar. Vorallem in der neuen Vesrion 2017 ist das Tailoring deutlich mehr in den Vordergrund getreten, weshalb wir hierzu nochmal ein Extra-Kapitel entwickelt haben, welches unter Kapitel 1.8 zu finden ist.

1.6Die 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 Kapiteln wird jedes einzelne Thema, auch im Zusammenspiel mit den Prozessen, aufgearbeitet. Die sieben Themen sind:

Business Case¹⁾

Organisation²⁾

Qualität³⁾

Pläne⁴⁾

Risiko⁵⁾

Änderungen⁶⁾

Fortschritt⁷⁾

Diese werden im Folgenden detailliert beschrieben.

Business Case: Das Thema „Business Case“ wird durch das Grundprinzip der „fortlaufenden geschäftlichen Rechtfertigung“ getrieben. Es geht darum, Mechanismen 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 Grundprinzips 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 richtigen 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 Anforderung 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 definierte 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 befassen. 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 werden dafür genutzt? Wie sollte das Layout eines von dem Projekt zu liefernden Projektplans 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 Unsicherheiten anzusehen, die Auswirkungen sowohl in die negative als auch in die positive 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 Änderungssteuerungsverfahren 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 innerhalb 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 Projekte adaptierbar. Jedoch ist u.a. die Versionierung, besonders in der Softwareentwicklung, ein wichtiges Must-Have. Versionierung bedeutet, dass jede neu releaste 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 Projektfortschritt getroffen werden kann und der Projektmanager oder der Lenkungsausschuss dadurch in die Lage versetzt wird, zu jedem Zeitpunkt eine Entscheidung, die richtige Entscheidung treffen zu können.

1.7Die 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 Output 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.

Im Folgenden sind die Prozesse aufgelistet und mit einigen prägnanten Wörtern beschrieben. Eine detaillierte Beschreibung der einzelnen Prozesse ist einer der Hauptbestandteile dieses Buches und verteilt sich daher auf mehrere Kapitel.

Dieses Buch ist – nebst eigenständiger Fortbildung und/oder Prüfungsvorbereitung – auch Bestandteil unseres Onlinekurses und der Präsenztrainings. Um die Wortwahl konsistent zu halten, sind daher die Prozesse sowohl im Deutschen als auch im Englischen genannt. Im Übrigen werden im Folgenden auch die Abkürzungen der englischen Begriffe genannt, die im Buch und in den Trainings verwendet werden.

Vorbereiten eines Projekts – Starting up a project | SU ¹⁾

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ßprojekten 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 ²⁾

Der Prozess DP ist für den Lenkungsausschuss entwickelt, damit dieser im Rahmen seiner Möglichkeiten zu jeglichem Punkt im Projekt die letztendliche Kontrolle behalten kann.

Initiieren eines Projekts – Initiating a Project | IP ³⁾

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

Managen eines Phasenübergangs – Managing a stage boundary | SB ⁴⁾

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

Steuern einer Phase – Controlling a Stage | CS ⁵⁾

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 ⁶⁾

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 ⁷⁾

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

1.8Die Anpassung an die Projektumgebung (Tailoring PRINCE2)

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.

Video anschauen: Der Gedanke von PRINCE2 Agile

Autor Fabian erklärt, was es mit PRINCE2 Agile auf sich hat.

www.agile-heroes.de/buch/prince2

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 Vorgehenweisen. Es wird hierbei die Frage beantwortet, wie PRINCE2 als immer noch wichtigstes Projektmanagement Framwork, mit agilen Produktentwicklungsmethoden 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: z.B. 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: z.B. 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 „Meetings nerven“, weshalb eine Vereinfachung einen hohen Grad an Zustimmung innerhalb der Unternehmen erfährt.

Die Umgestaltung von Formaten: z.B. 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: z.B. 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: z.B. 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.

1.9Spezialisten- vs. Managementprodukte

Um die Vorgehensweise von PRINCE2 besser für sich nachvollziehen zu können, ist das Verständnis des Unterschiedes von den in PRINCE2 genannten Spezialisten- und Managementprodukten überaus sinnvoll. Gerade auch in Bezug auf das Grundprinzip der Produktorientierung wird klar, dass innerhalb von PRINCE2 kein generierter Output als Produkt gewertet wird. Zu unterscheiden sind hier lediglich die beiden Ausprägungen eines Produkts: Spezialisten- und Managementprodukt.

Ein Spezialisten-Produkt ist nicht ein von PRINCE2 vorgegebenes Ergebnis, sondern ein vom Projekt geliefertes (Teil-)Produkt. Somit wird klar, dass dieses in seiner Art und Güte keinesfalls von PRINCE2 vordefiniert ist. Die Art und Güte hängt ganz alleine von der Qualität bzw. den Anforderungen der Projektkundenseite ab. „Spezialist“ auch deswegen, da die Erstellung a) sehr speziell ausfällt und b) von Spezialisten, nämlich den Teammitgliedern getrieben wird. Ein Beispiel für ein Spezialisten-Pro-dukt könnte das Haus der Olympioniken sein. Aber auch die komplett fertig gemanagte Olympiade an sich stellt ein Spezialistenprodukt, nämlich das Projektendprodukt, dar.

Ein Managementprodukt hingegen ist u.a. ein von PRINCE2 vordefiniertes Produkt, das zur Unterstützung des Projektmanagements entwickelt werden soll. Hierzu werden in der Originalliteratur 26 Stück im Anhang A) und in dem angehängten Glossar genauer beschrieben. Darüber hinaus gibt es natürlich noch von Projekten selbst entwickelte Managementprodukte, die dem rein administrativem Management des Projekts dienen. Sieht man sich die von PRINCE2 beschriebenen Managementprodukte an, so fällt auf, dass diese in ihrer Fülle durchaus ausreichend sind, um ein Projekt erfolgreich zu managen. So finden sich u.a. projekttypische und bekannte Managementprodukte wie ein Projektplan, eine Projektbeschreibung und ein Projektstatusbericht in der Terminologie wieder, aber auch neue und nicht allzu bekannte Ansätze wie ein Projekttagebuch oder einen Änderungssteuerungsansatz.

Im Rahmen des Grundprinzips der Anpassung an die Projektumgebung muss an dieser Stelle ausdrücklich erwähnt werden, dass die Verwendung der Managementprodukte in der in Anhang A) beschriebenen Fülle natürlich nur im projektentsprechenden Umfang möglich ist. Ansonsten ist es selbsterklärend, dass die Dokumentenstruktur so klein als möglich gehalten werden sollte, um den vom Projekt miteinhergehenden administrativen Overhead auf ein Minimum zu reduzieren. Im Grunde genommen sind Managementprodukte ein von PRINCE2 vorgegebenes Toolset, das man nutzen kann, aber nicht muss.

In vorigem Schaubild sind nochmal die Unterschiede zwischen Spezialisten- und Managementprodukte prägnant beschrieben und anhand einiger Beispiele greifbar gemacht.

1.10Übungsfragen zu Kapitel 1 – Grundlagen

Hinweis: Es kann nur eine Antwort richtig sein. Die Auflösung findest Du in Kapitel 8.

[1]	Welche Aussagen über die Stakeholder eines Projekts sind richtig?
1	Ein Stakeholder ist jemand, der glaubt, er werde von einem Projekt betroffen sein.
2	Die Stakeholder müssen vom Projektmanagement-Team gleichermaßen einbezogen werden.
3	Die Stakeholder bleiben während des Projekts unverändert.
4	Ein Stakeholder kann sich innerhalb oder außerhalb der Unternehmensorganisation befinden.
A	1 und 2
B	2 und 3
C	3 und 4
D	1 und 4
[2]	Was wird bei der Anpassung von PRINCE2 an das Projekt definiert?
A	Wann der Projektfortschritt geprüft wird
B	Welche der sechs Toleranzbereiche einbezogen werden
C	Welche Interessen wichtiger Stakeholder vertreten werden
D	Wann die Projekt-Outputs geliefert werden
[3]	Welche Aussage über das Grundprinzip „Fortlaufende geschäftliche Rechtfertigung“ ist richtig?
A	Die Rechtfertigung für obligatorische Projekte bedarf keiner Genehimigung.
B	Es darf keine Änderung für die Gründe eines Projekts geben.
C	Die formelle Dokumentation eines Business Case ist obligatorisch.
D	Die gewählte Option muss ein gutes Preis-Leistungs-Verhältnis bieten.
[4]	Wie findet das Grundprinzip „Lernen aus Erfahrung“ Anwendung?
A	Durch Überprüfung des Managements frührerer Projekte
B	Durch Definieren der Kundenerwartungen hinsichtlich des Projektprodukts
C	Durch Definieren von Kostentoleranzen für die Ziele des Projekts
D	Durch Delegieren von Verantwortlichkeiten auf eine andere Managementebene
[5]	Aus welchem der folgenden Gründe muss das Grundprinzip „Definierte Rollen und Verantwortlichkeiten“ angewendet werden?
A	Weil jedes Projekt einen einzigartigen Output hat.
B	Weil mehr als ein Bereich an dem Projekt beteiligt sein kann.
C	Weil Projekte doppelte und inkonsistente Ziele haben können.
D	Weil Phasen Kontrollpunkte für die Geschätsleistung bieten.
[6]	Was wird als Verantwortlichkeit des Kunden in der Kunden-/Lieferanten-Umgebung von PRINCE2 angesehen?
A	Spezifikation des gewünschten Ergebnisses
B	Bereitstellung der Fähigkeiten zum Erzielen des gewünschten Ergebnisses
C	Gewährleistung der technischen Integrität eines Projekts
D	Entwicklung des Projektprodukts
[7]	Welche zwei Aussagen über Anpassung sind richtig?
1	Prozesse können vereinfacht oder detaillierter ausgeführt werden.
2	Die Terminologie kann geändert werden, sodass sie zu den organisatorischen Standards passt.
3	Themen, die für das Projekt nicht relevant sind, können ausgeschlossen werden.
4	Mitglieder des Projektmanagement-Teams können jede Kombination von Rollen übernehmen.
A	1 und 2
B	2 und 3
C	3 und 4
D	1 und 4
[8]	Was ist ein Unterschied zwischen einem Projekt und normalem Geschäftsbetrieb?
A	Es erzielt Nutzen.
B	Es führt Veränderungen im Geschäftsbetrieb ein.
C	Es betreibt Stakeholdermanagement.
D	Es verursacht Kosten.
[9]	Welche Dimension der Projektleistung muss gemanagt werden, um eine klare Vorstellung davon zu haben, was das Projekt liefern soll?
A	Zeit
B	Umfang
C	Risiko
D	Kosten
[10]	Welches ist einer der vier integrierten Bausteine innerhalb von PRINCE2?
A	Qualität
B	Rollenbeschreibungen
C	Prozesse
D	Produktbeschreibungen
[11]	Wie wird „Steuern nach dem Ausnahmeprinzip“ angewandt?
A	Durch Unterteilung des Projekts in mindestens zwei Managementphasen
B	Durch Steuerungselemente, die die höhere Managementebene vor potenziellen Problemen warnen
C	Durch Sicherstellung, dass das Projekt weiterhin wünschenswert, realisierbar und erreichbar ist
D	Durch Bereitstellen von Erfahrungen, um Fehler aus vorherigen Projekten zu vermeiden..
[12]	Was ist ein Nutzen bei der Anwendung des Grundprinzips „Steuern über Managementphasen“?
A	Das Projektmanagement-Team wird die zugelassenen Toleranzen verstehen.
B	Das Projektmanagement-Team wird die Erwartungen des Kunden verstehen.
C	Das Projekt wird über Prüf- und Entscheidungspunkte zur Bewertung des Fortschritts verfügen.
D	Die wichtigsten Stakeholder im Projekt werden im Lenkungsausschuss repräsentiert.
[13]	Welchen Vorteil bietet der Einsatz von PRINCE2?
A	Es bietet bewährte und fundierte Best Practices und Governance-Aspekte für Projektmanagement.
B	Es stellt Techniken zur Analyse des kritischen Pfads sowie zur Leistungswertanalyse.
C	Es legt die Rechenschaftspflicht eines Projektmanagers bezüglich des Erfolgs eines Projekts fest.
D	Es verhindert Änderungen, nachdem der Projektumfang vereinbart wurde.