Lesezeit:
14 Min
  1. Home
  2. /
  3. PRINCE2
  4. /
  5. PRINCE2: Leitfaden fĂŒr Einsteiger

PRINCE2: Leitfaden fĂŒr Einsteiger

von | Okt 26, 2020 | PRINCE2 | 0 Kommentare


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.

projektEin Projekt wird hierbei in fĂŒnf Dimensionen unterschieden:

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.prince2-projektsteuerung

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

prince2-bausteineNachdem 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 Eskalations- wege 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.

Im Folgenden sind die Prozesse aufgelistet und mit einigen prÀgnanten Wörtern be- schrieben. Eine detaillierte Beschreibung der einzelnen Prozesse ist einer der Haupt- bestandteile 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 Engli- schen genannt. Im Übrigen werden im Folgenden auch die AbkĂŒrzungen der engli- schen Begriffe genannt, die im Buch und in den Trainings verwendet werden.

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.

anpassbarkeitAnpassung 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. Unser 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.

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.

Unsere PRINCE2 Trainings!

Ganz egal ob Du ein Training vor Ort, in einer unserer vielen Locations in Deutschland wĂ€hlst oder die praktische Online-Variante – wir garantieren Dir ein optimales Training. Alle Trainings werden von echten Projektmanagement-Experten durchgefĂŒhrt und entwickelt. Informiere Dich jetzt oder starte noch heute mit Deinem Training.

Beitrag teilen:
Agile-Heroes-Logo

Willkommen bei den Agile Heroes – deinen Experten fĂŒr agiles Projektmanagement. Wir sind einer der MarktfĂŒhrer fĂŒr agile Trainings und Coachings.

Beitrag teilen:
PRINCE2 Training

So hast Du noch nie gelernt

HOL DIR DAS GRATIS PLAYBOOK

Formular

ÄHNLICHE BEITRÄGE

0 Kommentare

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.