<?page no="1"?> Fabian Kaiser, Roman Simschek PRINCE2 D@# Erfolgs8#AB%3# einfach erklärt <?page no="3"?> Fabian Kaiser Roman Simschek PRINCE2 D%. Erfolgs`.A(HI. einfach erklärt UVK Verlag · München <?page no="4"?> Roman Simschek und Fabian Kaiser sind die Gründer und Inhaber der Bigfour GmbH, einer der führenden Beratungen zum Thema Projektmanagement. Sie beraten in Deutschland, Österreich und der Schweiz namhafte Unternehmen und helfen ihnen dabei, ihre Projekte erfolgreich zu managen. w ww.bigfour.de Bibliografische Information der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über <http: / / dnb.ddb.de> abrufbar. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. ISBN 978-3-86764-865-3 (Print) ISBN 978-3-7398-0432-3 (E-PUB) ISBN 978-3-7398-0433-0 (E-PDF) © UVK Verlag München 2019 - ein Unternehmen der Narr Francke Attempto Verlag GmbH & Co. KG Einbandgestaltung: Susanne Fuellhaas, Konstanz Printed in Germany UVK Verlag Nymphenburger Strasse 48 · 80335 München Tel. 089/ 452174-65 www.uvk.de Narr Francke Attempto Verlag GmbH & Co. KG Dischingerweg 5 · 72070 Tübingen Tel. 07071/ 9797-0 www.narr.de <?page no="5"?> WWi iddmmuunngg Dieses Buch widmen wir meinem Vater und Lebensvorbild, Uwe Kaiser, welcher während der Erstellung dieses Werkes leider unerwartet verstarb. Als Vater gab er mir die stets richtigen Werte mit auf meinen Lebensweg und trug den Großteil dazu bei, mich zu dem zu machen. was ich heute zu sein vermag. Ich bin unendlich traurig, dass Du dieses Werk nicht mehr persönlich in den Händen halten wirst. Dennoch bin ich auch unendlich dankbar, dass wir so viele schöne Jahre zusammen genießen konnten. Pass gut auf Dich auf, da wo Du bist. Dein Fabian <?page no="7"?> VVoorrwwo orrtt 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.“ 1 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. Dieses Buch 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. <?page no="8"?> 8 *)'")'% Wir sind mit einem etwas anderen Anspruch an dieses Buch herangegangen. Wir möchten die Geschichte dahinter erzählen. Eine Geschichte hinter einem wundervollen Projekt und einer super Methodik. Dieser Transfer aus Theorie und Praxis wird Dir dabei helfen, Dein nächstes Projekt wieder ein Stück besser zu managen. Ganz nebenbei wirst Du durch das Studieren dieses Buches auch auf die offizielle PRINCE2 Foundation Prüfung vorbereitet. Alles Weitere hierzu dann im Kapitel „Prüfung & Zertifzierung“. Neben diesem Buch gibt es für Dich auch die Möglichkeit, unseren Onlinekurs als Prüfungsvorbereitung heranzuziehen. Unter www.prince2Hero.de findest Du alle notwendigen Informationen zu unserem Onlinekurs. Sollte Dir das nicht ausreichen, kannst Du auch eines unserer Präsenztrainings besuchen; zu finden unter www.bigfour.de Fabian Kaiser fkaiser@bigfour.de Roman Simschek rsimschek@bigfour.de Beide sind wir telefonisch erreichbar unter 06196/ 52 549 55. So, genug Werbung, kommen wir zum Buch. Herzlichsten Dank und viele Grüße Fabian Kaiser Roman Simschek Frankfurt-Eschborn, >#$A#87#! 2018 <?page no="9"?> Inhaltsübersicht 1 Grundlagen ............................................................................................................................... 15 2 Projektvorbereitung .............................................................................................................. 51 3 Projektinitiierung.................................................................................................................... 85 4 Projektablauf ..........................................................................................................................145 5 Projektabschluss ...................................................................................................................169 6 Prüfung und Zertifizierung ...............................................................................................175 7 Glossar ......................................................................................................................................179 8 Lösungen zu den Übungsfragen ....................................................................................205 Index .....................................................................................................................................................209 <?page no="11"?> Inhalt Vorwort.......................................................................................................................................................7 1 Grundlagen ....................................................................................................................................................... 15 1.1 Die Geschichte von PRINCE2.............................................................................................. 15 1.2 Charakteristika eines Projekts ............................................................................................ 17 1.3 Der Projektsteuerungskreislauf......................................................................................... 20 1.4 Die vier integrierten Bausteine von PRINCE2............................................................... 27 1.5 Die 7 Grundprinzipien .......................................................................................................... 28 1.6 Die 7 Themen ........................................................................................................................... 37 1.7 Die 7 Prozesse .......................................................................................................................... 41 1.8 Spezialistenvs. Managementprodukte ........................................................................ 44 1.9 Übungsfragen zum Kapitel Eins - Grundlagen ........................................................... 47 2 Projektvorbereitung ............................................................................................................51 2.1 Prozess: Vorbereiten eines Projekts | Starting Up a Project (SU)............................ 51 2.2 Die Projektbeschreibung ..................................................................................................... 57 2.3 Thema Organisation .............................................................................................................. 59 2.3.1 Die drei Projektinteressen ................................................................................................... 59 2.3.2 Das Projektmanagementteam .......................................................................................... 62 <?page no="12"?> 12 [_(PaA 2.4 Thema Business Case ............................................................................................................ 71 2.4.1 Inhalt eines Business Case................................................................................................... 72 2.4.2 Entwicklungspfad eines Business Case .......................................................................... 76 2.5 Übungsfragen zum Kapitel Zwei - Projektvorbereitung......................................... 79 3 Projektinitiierung..................................................................................................................85 3.1 Prozess Lenken eines Projekts (DP) ................................................................................. 85 3.2 Initiieren eines Projekts (IP)................................................................................................. 89 3.3 Die Projektleitdokumentation ........................................................................................... 96 3.4 Thema Pläne ............................................................................................................................. 98 3.4.1 Drei Ebenen der Planung..................................................................................................... 98 3.4.2 Die Erstellung eines Plans..................................................................................................103 3.5 Thema Fortschritt .................................................................................................................107 3.5.1 Projektsteuerungsmittel ....................................................................................................107 3.5.2 Toleranzen und Ausnahmen ............................................................................................110 3.5.3 Management vs. Technische Phasen ............................................................................116 3.6 Prozess-Managen eines Phasenübergangs (SB) .......................................................119 3.7 Thema Risiko ..........................................................................................................................123 3.7.1 Risiko Definition ....................................................................................................................123 3.7.2 Prozesse im Risikomanagement .....................................................................................126 3.7.3 Das Risikoprofil ......................................................................................................................130 <?page no="13"?> [_(PaA 13 3.7.4 Rollen innerhalb des Risikomanagements..................................................................132 3.7.5 Kategorien der Risikobehandlung .................................................................................135 3.8 Übungsfragen zum Kapitel Drei - Projektinitiierung..............................................139 4 Projektablauf........................................................................................................................ 145 4.1 Prozess Steuern einer Phase (CS) und Managen der Produktlieferung (MP) .145 4.2 Thema Qualität ......................................................................................................................150 4.2.1 Qualitätskontrollpfad ..........................................................................................................150 4.2.2 Qualitätsprüfungstechnik .................................................................................................155 4.3 Thema Änderungen ............................................................................................................158 4.4 Übungsfragen zum Kapitel Vier - Projektablauf.......................................................164 5 Projektabschluss................................................................................................................. 169 5.1 Prozess Abschließen eines Projekts (CP)......................................................................169 5.2 Übungsfragen zu Kapitel fünf - Projektabschluss ...................................................173 6 Prüfung und Zertifizierung ............................................................................................ 175 6.1 Wie kann man zertifiziert werden? ................................................................................175 6.2 Welche Prüfungen gibt es? ...............................................................................................175 7 Glossar .................................................................................................................... 179 8 Lösungen zu den Übungsfragen ....................................................................... 205 Index .................................................................................................................................. 209 <?page no="15"?> 1 Grundlagen Die Geschichte von PRINCE2 1.1 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 Enviroment. 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 Projektleiters oder Projektmanagers übernimmt, dass dieser eine eingetragene PRINCE2-Zertifizierung hält. Mehr dazu in Kapitel 0 "" - Prüfung und Zertifizierun- <?page no="16"?> 16 1 ]E? _IaP*._ gen. 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. 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 360º-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. 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. <?page no="17"?> 1.J Die @(PEP! A.E%CA%! P .%_.C UEH#.! AC 17 <?page no="18"?> 18 N ]E? _IaP*._ <?page no="19"?> 1.J Die @(PEP! A.E%CA%! P .%_.C UEH#.! AC 1" <?page no="20"?> N ]E? _IaP*._ <?page no="21"?> det 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 Management der folgenden sechs Projektdimensionen dar. Die sechs Dimensionen innerhalb von PRINCE2 sind: Zeit 1) , Kosten 2) , Qualität 3) , Risiko 4) , Umfang 5) , Nutzen 6) Û Zeit: Wie viel Zeit das Projekt benötigt. Wann das Projekt beginnt, wann es (planmäßig) enden soll. Wann welche Phase beginnt, wann welches Produkt erstellt wird: All das sind zeitlich gesteuerte 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 öffentliche 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 bedarfsgerechten zeitlichen Planung, Delegation, Überwachung und Steuerung des Projekts massiv beitragen. Û Kosten: Neben dem gerade angesprochenen Zeitaspekt ist die Kostendimension die mit Abstand essentiellste. Schließlich steht und fällt alles damit, dass es innerhalb 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 Projektmanager hinsichtlich dieser essentiellen Stakeholder-Attention agieren? Nach der PRINCE2-Terminologie nimmt der Projektmanager hier eine Art Vermittlerrolle ein, der die Interessen der Stakeholder wie zum Beispiel dem Auftraggeber mit denen der Lieferanten zueinander bringt. 1./ D.E UEH#.! ACA.? .E? _*C! E.%CaP? , JN <?page no="22"?> 22 N ]E? _IaP*._ <?page no="23"?> Û 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 Eigenschaften, also die Qualität, „gut“ oder „schlecht“ sind, vermag der Kunde bzw. der Auftraggeber beurteilen. Der Projektmanager hat nicht das Recht, dies zu beurteilen. 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 Risikomanagementsystem 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 1. / >.E UE H#.! AC A.? .E? _* C! E.%CaP? , J/ <?page no="24"?> 24 1 ]E? _IaP*._ hierfür eigene Teilprojektleiter, oder wie in PRINCE2 beschrieben, Teammanager gibt, die durch ihr fachliches Know-how hervorstechen. Diese und deren Teammitglieder müssen 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 melden. 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 dem 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 London 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. <?page no="25"?> 1. / D.E UEH#.! ACA.? .E? _*C! E.%CaP? , J+ <?page no="26"?> 1 ]E? _IaP*._ <?page no="27"?> Û Û Û 1.- Die =%.E %_A.*E%.EA._ BP? CA.%_. von PRINCE2 27 Û Die 7 Grundprinzipien: Die Grundprinzipien kann man festen Leitsätzen gleichsetzen. Nach der PRINCE2-Terminologie ist jedes der sieben bestehenden Grundprinzipien zu befolgen, sollte man beabsichtigen, ein PRINCE2-Projekt zu initiieren und zu managen. Den 7 Grundprinzipien schenkt 17C4B6@AA )+2 noch gesonderte Aufmerksamkeit. <?page no="28"?> 28 1 ]E? _IaP*._ <?page no="29"?> Û 1.+ Die & ]E? _IGE%_\%G%._ 29 <?page no="30"?> 30 1 ]E? _IaP*._ Lernen aus Erfahrung 2) : 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 <?page no="31"?> 1.+ >%. & ]E? _IGE%_\%G%._ 31 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 3) : 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 verant- <?page no="32"?> 32 1 ]E? _IaP*._ wortlich 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 4) : 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 <?page no="33"?> 1.+ Die & ]E? _IGE%_\%G%._ 33 <?page no="34"?> 34 1 ]E? _IaP*._ men 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 5) : 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-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 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. <?page no="35"?> 1.+ Die & ]E? _IGE%_\%G%._ 35 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 6) : 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 <?page no="36"?> 36 1 ]E? _IaP*._ 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 7) : 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 <?page no="37"?> 1.) Die & 4(.`._ 37 wenig bis gar keine Administration Agile bedeutet und viel und umfangreiche Administration automatisch „klassisches bzw. Wasserfall-Projektmanagement“. „Managt man offiziell ein ‚klassiches 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. Die 7 Themen 1.6 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 1) Û Organisation 2) Û Qualität 3) Û Pläne 4) Û Risiko 5) Û Änderungen 6) Û Fortschritt 7) Diese werden im Folgenden detailliert beschrieben. <?page no="38"?> 38 1 ]E? _IaP*._ <?page no="39"?> 1.) Die & 4(.`._ 39 Û 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. <?page no="40"?> Û Û Û 1 ]E? _IaP*._ <?page no="41"?> Û 1.& Die & UEH\.CC. <?page no="42"?> 1 ]E? _IaP*._ <?page no="43"?> Û Û Û Û 1.& Die & UEH\.CC. 43 <?page no="44"?> Û Û Û 1 ]E? _IaP*._ <?page no="46"?> 1 ]E? _IaP*._ <?page no="47"?> á á á á á á á á á á á á á á á 1." QO? _*C,EP*._ \? YPG%A.a <%_C 47 <?page no="48"?> á á á á á á á á á á á á á á á 1 ]E? _IaP*._ <?page no="49"?> á á á á á á á á á á á á á á 1." QO? _*C,EP*._ \? YPG%A.a <%_C 49 <?page no="50"?> á á á á á á á á á á á á 1 ]E? _IaP*._ <?page no="52"?> 52 J UEH#.! A=HEO.E.%A? _* <?page no="53"?> JRN UEH\.CCb 2HEO.E.%A._ .%_.C UEH#.! AC " 5APEA%_* 3G P UEH#.LA ^53T 53 Das Projekttagebuch wird in der PRINCE2-Terminologie als ein sehr informelles Managementprodukt beschrieben. Es dient dem Projektmanager als - salopp gesagt - Notizblock; als Notizblock für sämtliche Anliegen, die innerhalb eines Projekts anfallen. In der Praxis spricht man hierbei auch oft von einer Todo-Liste des Projektmanagers. Zu beachten ist hierbei, dass ausschließlich der Projektmanager selbst die Kompetenz besitzen sollte, dieses Managementprodukt zu pflegen und zu lesen. Im dritten Prozessschritt des Schaubilds geht es darum, eine erste Indikation der Projektmanagementteams zu entwerfen und zu ernennen. Erste Indikation deswegen, da natürlich innerhalb der Projektinitiierung und den darauffolgenden Projektphasen eine Änderung des Projektteams möglich, sogar üblich ist. Kaum ein Projekt, vor allem umfangreiche, komplexe und langlaufende, kommen ohne Änderungen innerhalb Ihrer Projektorganisation aus. Die hier beschriebenen Aktivitäten von PRINCE2, spiegeln vor allem das Grundprinzip der „definierten Rollen und Verantwortlichkeiten“ wider. Als Thema wird hier das Thema „Organisation“ behandelt, welches sich vor allem mit den Rollen und Projektorganisationsstrukturen auseinandersetzt. 2. … dass so viele Erfahrungen wie möglich in Form eines Erfahrungsprotokolls niedergeschrieben sind 2) Im zweiten Prozessschritt „Vorhandene Erfahrungen erfassen“ sollen das erste Mal, schon bereits vor Beginn des Projektvorhabens, Erfahrungen positiver und negativer Natur besprochen und niedergeschrieben werden. Ziel es ist, anhand des Managementprodukts „Erfahrungsprotokoll“, eventuelle Do´s und Dont´s aus Vorgängerprojekten zu erfassen, um so die aktuell anstehende Projektinitiierung, aber auch die kommende Projektdurchführung so effizient wie möglich zu gestalten. Das Erfahrungsprotokoll ist eine sich im Laufe des Projekts dauerhaft anpassende Liste aus gemachten Erfahrungen, zum Beispiel aus Vorgänger-Projekten. Dauerhaft <?page no="54"?> 54 bedeutet hierbei, dass dem Grundprinzip „Lernen aus Erfahrung“ dahingehend nachgekommen werden muss, als dass nicht nur einmal zu Beginn und einmal zum Ende eines Projekts über Erfahrungen gesprochen werden soll, sondern im Grunde genommen am Ende jeder Phase die Erfahrungen der letzten Phase notiert werden sollen. Oft wird dies auch als „Lessons Learned“ bezeichnet. 3. … dass die Initiierung wirtschaftlich in Form des Business-Case-Entwurfs gerechtfertigt ist 3) Wenn wir uns an das Grundprinzip der fortlaufenden geschäftlichen Rechtfertigung zurückerinnern, wird klar, dass es im Rahmen eines Projekts bzw. hier im Rahmen der Projektvorbereitung einen Zeitpunkt geben muss, an dem man das erste Mal die geschäftliche Rechtfertigung aufzeigt. Dies geschieht im Prozessschritt 4 des Schaubildes. Hier erstellt man den so genannten „Business-Case-Entwurf“. Der Business-Case-Entwurf enthält, wie der Name schon vermuten lässt, nur erste Bestandteile des umfangreichen „Business Case“. Grund hierfür ist, dass man innerhalb der Projektvorbereitung ja mit einem sehr kosten- und zeitgünstigen Ansatz herausgefunden werden soll, ob sich das Projekt lohnt. Die Zeit mit einer umfangreichen Business-Case-Erstellung zu verbringen wäre daher nicht zielführend. Die Bestandteile der abgespeckten Variante - dem Entwurf - sind in erster Linie Gründe und Optionen. Bei der Vorbereitung auf ein Projekt konzentriert man sich oft darauf, WAS getan wird. Das WARUM wird hierbei oft außen vor gelassen. Hierbei soll die PRINCE2-Terminologie, mit Hilfe der Gründe, innerhalb des Business-Case-Entwurfes Abhilfe schaffen. Ferner sollen die Gründe eine Erläuterung bieten, wie das Projekt die Strategien und Ziele des Unternehmens unterstützt. Ein Grund, die Olympiade innerhalb von London stattfinden zu lassen, könnte aktuell die stagnierende wirtschaftliche Situation Londons gewesen sein. Wichtig bei der Definition von Gründen ist, dass diese vergangenheitsbzw. gegenwartsbezogen sind. J UEH#.! A=HEO.E.%A? _* <?page no="55"?> Die Optionen innerhalb des Business-Case-E ntwurfs beinhalten eine Analyse und begründete Empfehlung für eine der vom Projekt gewählten Optionen. Die Optionen, der wirtschaftlichen Situation von London entgegenzuwirken könnten a) die Olympiade und b) die Austragung der Fußball-Weltmeisterschaft sein. Bei den Optionen sollte auch immer die Null-Option mit dargestellt werden: also was würde passieren, wenn nichts getan wird. Die hierfür benötigten Informationen erlangt der Projektmanager, welcher im Übrigen gemeinsam mit dem Auftraggeber den Business-Case-Entwurf erstellt, aus dem Projektmandat und dem bereits angefertigten Erfahrungsprotokoll. 4. … dass ein erster Entwurf der Produktbeschreibung des Projektendprodukts (PEP) vorhanden ist 4) Bereits vor Beginn eines jeden Projekts muss man sich über das fertige Endprodukt Gedanken machen. Umso konkreter, desto besser kann man planen, desto mehr wird man im Laufe des Projekts aufgrund sich verändernder Anforderungen der Kundenseite abändern müssen. Eine Musterlösung, wie granular man planen sollte, gibt es nicht, auch nicht in der PRINCE2-Terminologie. In PRINCE2 wird die Beschreibung des am Ende vom Projekt zu liefernden Produkts als Produktbeschreibung des Projektendprodukts bezeichnet. Abgekürzt als PEP, beschreibt diese sämtliche Anforderungen des Kunden an das zu liefernde Produkt. Klar ist hierbei, dass dies ein lebendiges Managementprodukt ist. Das bedeutet, dass im Laufe des Projekts sich ergebende Änderung der Anforderungen an das Endprodukt ebenfalls in der PEP niedergeschrieben werden soll. Die im Vorbereiten eines Projekts erstellte PEP stellt somit zwar eine vollkommene PEP, jedoch noch lange keine finale bzw. fertige PEP dar. Vielmehr ist es deren erste Indikation. JRN UEH\.CCb 2HEO.E.%A._ .%_.C UEH#.! AC " 5APEA%_* 3G P UEH#.LA ^53T 53 <?page no="56"?> 56 5. … dass die Alternative, wie das Projekt durchgeführt werden könnte, bewertet und ausgewählt wurde 5) Wie wird das Projekt durchgeführt? Schaffen wir es, die Olympiade selbst auf die Beine zu stellen oder benötigen wir dafür einen Dienstleister, an den wir die Organisation outsourcen? Die Antwort auf diese Art von Fragen findet sich im Projektlösungsansatz. Der Projektlösungsansatz beschäftigt sich klassischerweise mit der Make-or-Buy- Entscheidung. Wird das Projektendprodukt von einem selbst im Rahmen des Projekts erstellt oder kümmert sich ein externer Dienstleister um die Erstellung? Hat man diese und weitere Informationen bzw. weitere Managementprodukte zusammengetragen, erstellt man aus dieser Sammlung an wichtigen Managementprodukten aus dem Prozess „Vorbereiten eines Projekts (SU)“ ein Art Managementprodukt Management Summary, genannt Projektbeschreibung. Mehr hierzu in 17C4B6@AA (+(. 6. … dass die für die Initiierungsphase notwendigen Arbeiten in Form eines Initiierungsphasenplans dokumentiert worden sind 6) Wie in den vorhergegangenen Zeilen bereits ersichtlich wurde, ist innerhalb der PRINCE2-Terminologie, eine Einteilung in Phasen außerordentlich wichtig. Um jeder Phase die Chance zu geben, von Anfang bis Ende hoch professionell und annähernd fehlerfrei gemanagt zu werden, ist eine gute vorgegangene Planung von Nöten. Das erste Mal kommt diese Planung im Prozess „Vorbereiten eines Projekts“ zum Tragen. Nämlich dann, wenn die Initiierungsphase des anstehenden Projekts geplant werden muss. Am Ende der Projektvorbereitung muss ein fertiger Initiierungsphasenplan erstellt worden sein. Dieser Plan dient dazu, erste Zeit- und Kostenbeschränkungen für die J UEH#.! A=HEO.E.%A? _* <?page no="57"?> Initiierungsphase festzulegen und im Rahmen dessen eventuell erste Produktbeschreibungen für die Erstellung innerhalb der Initiierungsphase zu entwickeln. De r Pr oz ess „ Vo rb er eit en ei n es P roje k ts (S U) “ sch li eßt m it d em s o ge na n nt en A n tr ag auf Projektinitiierung 7) ab. Dieser Antrag ist innerhalb von PRINCE2 nicht sehr ausführlich beschrieben. In der Praxis ist dieser Antrag oft als Projektantrag benannt, der mit einer großen Anzahl an bereits klaren Projektrahmenbedingungen befüllt ist. Diese sind neben Zeit, Kosten und Qualität auch oft eine erste Indikation benötigter Ressourcen. Die Projektbeschreibung 2.2 Wie in Abschnitt 2.1 erwähnt, stellt die Projektbeschreibung eine erste grobe Management Summary dar. Sie beinhaltet die wichtigsten von dem Prozess „Vorbereiten eines Projekts (SU)“ zu liefernden Managementprodukte. Diese sind: Û das Organigramm 1 Û die Produktbeschreibung des Projektendprodukts 2 Û der Projektlösungsansatz 3 Û der Business-Case-Entwurf 4 Û sowie etwaige Verweise auf andere Managementprodukte 5 Die Projektbeschreibung wird benötigt, damit der Lenkungsausschuss, also das Komitee, welches letztendlich über die Projektparameter entscheidet, alle notwendigen Informationen zur Genehmigung der Projektinitiierung erhält. Innerhalb des Prozesses „Initiieren eines Projekts (IP)“ werden die Inhalte der Projektbeschreibung in ergänzter und optimierter Form in die Projektleitdokumentation übernommen. Die Projektbeschreibung wird daraufhin nicht weiter fortgeführt. Mehr hierzu in 17C4B6@AA 5+5. JRJ >%. UEH#.! AO.CL(E.%O? _* 53 <?page no="58"?> 58 J UEH#.! A=HEO.E.%A? _* <?page no="59"?> JR/ 4(.`P VE*P_%CPA%H_ 59 Thema Organisation 2.3 Das erste Thema innerhalb der PRINCE2-Terminologie, mit dem wir uns näher beschäftigen, ist das Thema „Organisation“. Das Wort „Organisation“ stellt für viele Leute erstmal ein Stolperstein dar. Geht es hierbei um die grundlegende Organisation innerhalb eines Unternehmens oder innerhalb der Linienorganisation? Bei „Organisation“ geht es vielmehr um das Thema „Projektorganisation“. Zweck des Themas „Organisation“ ist die Evaluierung und Festlegung der Organisationstruktur, die Zuordnung der Rollen und Verantwortlichkeiten und deren Kompetenzen. Wie man hier schon sehr schön herauslesen kann, ist der Unterpunkt ‚Rollen und Verantwortlichkeiten‘ eine wichtige Kernfragestellung von PRINCE2, weshalb auch ein eigenes Grundprinzip dieser Fragestellung gewidmet wurde. Und genau diesem Grundprinzip „Definierte Rollen und Verantwortlichkeiten“ kommen wir in dem Thema „Organisation“ nach. Innerhalb von PRINCE2 gibt es eine Vielzahl an Rollen, welche wir im folgenden Abschnitt näher beschreiben werden. Hierbei ist das Wort „Rolle“ keinesfalls personenbezogen. So sollte die Rolle des Projektmanagers zum Beispiel nur von einer Person besetzt sein, wohingegen die Rolle des Teammanagers an eine Vielzahl an Personen übergeben werden kann. J.3.1 Die drei Projektinteressen Die PRINCE2-Terminologie geht davon aus, dass es auf einem Projekt immer drei grundsätzliche Interessensgruppen gibt. Diese gelten als die wichtigsten Stakeholder eines Projekts. Sowohl die Bedürfnisse als auch die Anforderungen aller drei Interessensgruppen müssen erfüllt werden, damit ein Projekt erfolgreich ist. Diese drei Projektinteressen splitten sich in das Unternehmen-, die Benutzer- und die Lieferantenseite auf. Gleichzeitig stellen diese drei Interessengruppen auch den Lenkungsausschuss dar. <?page no="60"?> 60 Nicht selten kommt die Konstellation zustande, dass die Unternehmensseite, in der Logik von PRINCE2, jene Personen abbilden, die als Geldgeber fungieren, mit der Benutzerseite, also jene Personen, welche das vom Projekt gelieferte Endprodukt in ihrer täglichen Arbeit benutzen, eine Person abbilden. PRINCE2 spricht in dieser Logik daher immer von einer Kunden-Lieferantenbeziehung. Im Übrigen auch dann, wenn das Unternehmen für sich selbst ein Projekt auf die Beine stellt. Hier nimmt dann die Fachabteilung, welche für die Lieferung des Projekt die Verantwortung hat, die Lieferantenseite ein. Am verständlichsten wird es anhand eines Beispiels: Hartmut, Abteilungsleiter der Finanz-Abteilung einer Bank, möchte für seine Abteilung ein neues Tool zur Vereinfachung der Überweisungen einführen. Hartmut stellt, da er mit dem Tool arbeiten wird, die Benutzerseite dar. Um für das Projekt zu werben und um für das Projekt das notwendige Budget zu bekommen, trifft er sich mit seinem Bereichsleiter Michael. Michael verfügt über sehr viel Budget und ist bekannt dafür, es ohne lange zu überlegen auszugeben. Hartmut überredet Michael schließlich, ihm für sein Vorhaben 1,5 Mio. Euro zur Verfügung zu stellen. Michael stellt somit die Rolle des Unternehmensvertreters, also des Auftraggebers dar, da er die Budgetverantwortung trägt. Nun treffen sich Michael (Auftraggeber) und Hartmut (Benutzer) mit den potenziellen externen Toolherstellern, um sich für ein Tool und damit für einen Partner zur Umsetzung des Projekts zu entscheiden. Markus vertritt seinerseits die marktführende und unabhängige Finance-Unternehmensberatung Litestern (Fantasiename). Er bekommt den Zuschlag für das Projekt und nimmt somit die Rolle des Lieferantenvertreters ein. J UEH#.! A=HEO.E.%A? _* <?page no="61"?> JR/ 4(.`P VE*P_%CPA%H_ 61 Wie im folgenden Schaubild zu sehen, ergibt sich durch die Konstellation von Hartmut (Benutzer), Michael (Auftraggeber) und Markus (Lieferant) die in PRINCE2 benannte Kunden-Lieferantenbeziehung. Nimmt man nun in dem Beispiel an, dass Hartmut als Abteilungsleiter eigene Budgetverantwortung trägt, könnte sich die Rolle von Michael als Auftraggeber als obsolet erweisen. Hartmut übernimmt damit die Rolle des Benutzers als auch das Auftraggeber (Unternehmensvertreters). <?page no="62"?> 62 8 6')05/ %#)'>5'51%$-3 J.3.2 Das Projektmanagementteam Das Projektmanagementteam bildet sozusagen die Projektorganisation. Hier sind alle Rollen enthalten, die laut der PRINCE2-Terminologie in einem vollumfänglichen Projekt dazugehören. Hierbei ist natürlich das Grundprinzip der „Anpassung an die Projektumgebung“ nicht zu vergessen, da die Projektstruktur der Olympiade sicherlich der PRINCE2-Musterorganisation von der Auslastung der vorgegebenen Rollen näherkommt, als es ein kleines Baumhausprojekt der Tochter tut. Im Folgenden wird jede Rolle der PRINCE2-Terminologie auf ihre Verantwortung, ihrer Notwendigkeit und ihrer Voraussetzung an die Person dahinter, beschrieben. Der Lenkungsausschuss 1) Der Lenkungsausschuss stellt das Entscheidungskomitee innerhalb der Projektorganisation dar. Er übernimmt das Lenken eines Projekts im Sinne des „accountable“. Er hat im Rahmen der Vorgaben des Unternehmens- oder Programmmanagements die Gesamtverantwortung und Gesamtvollmacht für das Projekt. Darüber hinaus ist er für die Kommunikation zwischen dem Projektmanagementteam und den Stakeholdern, insbesondere dem Projekt- und Programmmanagement, zuständig. Je nach Scope des Projekts können die Mitglieder des Lenkungsausschusses zusätzlich einige Projektsicherungsaufgaben an andere Einzelpersonen delegieren. Ferner ist der Lenkungsausschuss befugt, die Kompetenz über Änderungen an den Änderungsausschuss zu delegieren. Mitglieder des Lenkungsausschusses sind die bereits in Abschnitt 2.3.1. beschriebenen Rollen: „Benutzer“-, „Lieferant“- und „Unternehmensvertreter“ bzw. Auftraggeber. Mehr hierzu in den folgenden Beschreibungen. <?page no="63"?> JR/ 4(.`P VE*P_%CPA%H_ 63 Auftraggeber 2) Der Auftraggeber stellt den Vorsitz innerhalb des Lenkungsausschusses dar. Er trägt die Gesamtverantwortung für das Projekt und hat dafür Sorge zu tragen, dass die vorgegebenen Ziele erreicht und der geplante Nutzen erzielt werden. Er hat sicherzustellen, dass das Projekt möglichst direkt auf die angestrebten Ziele zusteuert, dass die Vollmachten eindeutig festgelegt sind und dass sowohl die anstehenden Arbeiten als auch die Risiken aktiv gemanagt werden. Umgangssprachlich ist der Auftraggeber auch als Unternehmensvertreter, Executive oder Projektsponsor bekannt. Hier findet das Highlander-Prinzip Anwendung: Es kann nur einen geben! Ein zweiter Auftraggeber würde innerhalb eines Projekts durch die gleiche dahinter sich verstehende Kompetenz für Unruhe und gegebenenfalls sogar für Stillstand sorgen. Benutzervertreter 3) Der Benutzervertreter lässt - im Rahmen seiner Rolle im Lenkungsausschuss - seine Anforderungen verlauten. Er vertritt den Teil der Stakeholder, der mit den vom Projekt zu liefernden Produkten arbeitet; sie namensgemäß benutzt. Darüber hinaus stellt er die Person dar, welche ihre Anforderungen an das Projektendprodukt definiert und diese, im Rahmen der finanziellen Möglichkeiten des Auftraggebers, abstimmt. Da ein Projektendprodukt oftmals von mehreren Personen oder Personenkreisen benutzt werden kann, sind mehrere Benutzervertreter durchaus möglich, meistens sogar üblich. Lieferantenvertreter 4) Der Lieferantenvertreter bildet den letzten Teil des Lenkungsausschusses. Er vertritt die Interessen der Parteien des Projekts, die für den Entwurf, die Entwicklung und die Realisierung des Produkts des Projekts verantwortlich sind. Er ist für die Qualität der zuliefernden Produkte verantwortlich. Je nach Art des Projekts kann der Liefe- <?page no="64"?> 64 J UEH#.! A=HEO.E.%A? _* rantenvertreter entweder als Externer des Unternehmens oder als interner Lieferverantwortlicher innerhalb des Lenkungsausschusses agieren. Auch der Lieferantenvertreter, insbesondere bei Großprojekte wie der Olympiade, wird auf der Lieferseite durch eine Vielzahl von Vertretern der internen und externen Zuliefererseite vertreten sein. Projektsicherung 5) Die Projektsicherung stellt den verlängerten Arm des Lenkungsausschusses dar. Sie ist für die Wahrnehmung der Interessen des Lenkungsausschusses innerhalb der Projektorganisation da. Die Aufgabe kann innerhalb kleinerer Projekte vom Lenkungsausschuss selbst übernommen werden, wird in der Regel aber als Rolle weiter an unabhängige Personen delegiert. Die Unabhängigkeit bezieht sich in diesem Zusammenhang auf das Projektteam, da dieses von der Projektsicherung auditiert wird. Eine sich ausschließende Rollenkombination ist zum Beispiel Projektsicherung und Projektmanager. In der Praxis trifft diese Rolle sehr passend auf Projektcontroller zu. Aber auch eine Projektrevision kann durchaus die Rolle der Projektsicherung einnehmen. Änderungsausschuss 6) Innerhalb jedes Projekts kommen während der Projektlaufzeit eine Vielzahl an Änderungen auf das Projektteam und das vom Projektteam zu liefernde Projektendprodukt zu: Änderungen, die sich durch Risiken ergeben, Änderungen die sich durch neue Wünsche der Benutzerseite ergeben. Innerhalb von PRINCE2 gibt es für eine richtige Steuerung dieser Änderungen das namensgleiche Thema „Änderungen“. Innerhalb des Themas „Organisation“ gibt es darüber hinaus jedoch noch eine Rolle, die sich innerhalb der Projektorganisation um das Thema und die anfallenden Änderungen bemüht: den Änderungsausschuss. Dieser besitzt die Kompetenz, über Änderungen zu entscheiden. Der Änderungsausschuss ist nicht zwingend - wie der Name vermuten lässt - ein Komitee, sondern besteht vielmehr aus einzelnen Perso- <?page no="65"?> JR/ 4(.`P VE*P_%CPA%H_ 65 nen innerhalb des Projektteams, die in unterschiedlichen Bereichen unterschiedliche Arten von Änderungskompetenz seitens des Lenkungsausschusses delegiert bekommen haben. Der englische Begriff aus der Originalliteratur unterstreicht diese Definition des Änderungsausschusses sehr gut: Im Englischen als „Change Authority“ bezeichnet, beschreibt dieser Begriff übersetzt eine Autorität, eine Kompetenz, welche über Änderungen entscheidet, kein Komitee, wie es der deutsche Begriff auf Anhieb vermuten lässt. Der Änderungsausschuss muss innerhalb eines Projekts über die Änderungsanforderungen entscheiden. Daher sind eine hohe Verantwortung und eine hohe Identifizierung der Ziele des Benutzervertreters notwendig. In kleinen Projekten übernimmt der Lenkungsausschuss selbst die Rolle des Änderungsausschusses. Auch ist es nicht unüblich, dass diese Rolle vom Projektmanager übernommen wird. Projektmanager 7) Das Abwickeln der täglichen koordinativen Tätigkeiten gehört zu den Hauptaufgaben des Projektmanagers. Er ist innerhalb der einzelnen Managementphasen dafür zuständig, dass das Projekt die für die Phase vereinbarten Produkte innerhalb der vereinbarten Zeit, der Kosten und der Qualität liefert und dabei den Umfang, den Nutzen und die Risiken im tolerierten Bereich hält. Kurz gesagt: Er muss innerhalb der Managementphasen die vereinbarten Toleranzen einhalten. Auch hier kommt wieder das Highlander-Prinzip zur Anwendung: Es kann nur einen geben! : ein Projektmanager. Oft wird in der Praxis ein sehr spezialisierter Projektmanager eingesetzt. Ein Projektmanager, der über umfangreiche Fachkenntnisse verfügt. Das hat zur Folge, dass jene Projektmanager mit ihren Teilprojektleitern in tiefe fachliche Diskussionen abtauchen; Diskussionen, die meistens während großen Teilprojektleiter-Meetings oder Jour Fixen stattfinden. Also genau dann, wenn hochbezahlte Projektmitarbeiter zusammensitzen und Zeit kostbar ist. Das sollte nicht passieren. Aber dass Pro- <?page no="66"?> 66 J UEH#.! A=HEO.E.%A? _* jektmanager in so genanntes Mikromanagement, also Management von extrem kleinen und eigentlich außerhalb ihrer Kompetenz liegenden Themen, abtauchen, ist leider gang und gäbe. Dass ein Projektmanager ein intensives fachliches Knowhow besitzen muss, ist sowohl nach der Aussage der PRINCE2-Terminologie als auch nach unserer praktischen Erfahrung nicht notwendig; sogar radikal falsch! Hierbei liegt die Betonung auf der Intensität des fachlichen Know-hows. Im Laufe eines Projekts findet auch ein fachlich komplett unerfahrenerer Projektmanager Zugang zu den fachlichen Themen, wird sie aber in aller Regel nicht allzu tiefgehend bestimmen. Nun stellt sich sicher die Frage, welche Kompetenz ein Projektmanager mitbringen muss und wie ein Projektmanager sein minimal fachliches Know-how ausgleichen soll. Oder muss er das überhaupt? Die Kompetenzen eines Projektmanagers sollten unter anderem sein: Û Planung: Eine wichtige Kernkompetenz eines Projektmanagers sind die Planung und die Fähigkeit, „um die Ecke zu denken“. Es geht darum, aufeinander aufbauende Fragestellungen im Anfangszustand zu identifizieren und auf Basis von Annahmen eine höchst zutreffende Planung zu bezwecken. Û Zeitmanagement: Die meisten Projekte erhalten wegen zwei Faktoren ein negatives Image: Geld- und Zeitüberschreitung. Das Zeitmanagement an sich ist in der Geschichte der Menschheit eines der anspruchsvollsten Themen. Das liegt daran, dass Zeit nicht beinflussbar ist. Was hingegen beinflussbar ist, ist jene Arbeit, die man innerhalb eines Tages bzw. Arbeitstages verrichten kann. Das ist der Gedanke von Zeitmanagement: das effiziente Management von Workload innerhalb einer vorgegebenen Zeit. Die Zeit an sich bleibt dabei vollkommen unberührt. Û Mitarbeitermanagement: Ein Projektmanager hat in seiner Rolle als Führungskraft eines Projekts in der Regel eine Vielzahl an Mitarbeitern zu managen und <?page no="67"?> JR/ 4(.`P VE*P_%CPA%H_ 67 zu führen: Managen im Sinne der Ressourcenplanung. Zugegeben ist das ein Teilbereich der oben beschriebenen Planung, jedoch geht das operative Management der Mitarbeiter über die Planung, welche ja nur punktuell zukunftsorientiert durchgeführt wird, hinaus. Beim Management der Mitarbeiter geht es um Themen wie Projekt-Onboarding, also die Neuaufnahme und Einarbeitung von neuen Mitarbeitern, um Themen wie Staffing, also die Vergabe von Personentagen von der Linie hinaus an Teilprojektleiter bzw. Teammanager etc. Û Problemlösung: Eine der wohl wichtigsten Kompetenzen von Projektmanagern ist die Lösungsorientierung. Oft laufen einem Projektmanager oder Mitarbeiter über den Weg, die den ganzen Tag nur über Probleme sprechen: „das funktioniert nicht“, „das läuft schief“, „die Person möchte nicht richtig mitarbeiten“ etc. Ein Projekt ist mit Problemen überhäuft. Jeder innerhalb des Projekts steht vor neuen Herausforderungen. Unternehmen führen ein Projekt in der Regel immer nur einmal durch, daher ist alles neu. Diese Faktoren stellen den Projektmanager schon vor genug Hürden. Sich hierbei intensiv über Probleme zu unterhalten ist schlichtweg falsch. Hierfür besteht nicht die Zeit. Wenn etwas schlecht gelaufen ist, kann man es nicht mit einer Vergangenheitsbewältigung beheben. Vielmehr geht es darum, sich mit seinen fachlichen Ansprechpartnern Gedanken über eine Lösung der Probleme zu machen. Û Kommunikation: Einer der Schlüsselkompetenzen ist die Kommunikation. Es ist essentiell, dass ein Projektmanager innerhalb des Projekts in ständiger Kommunikation mit seinen Projektmitarbeitern und den Stakeholdern steht. Hierbei ist zu beachten, dass diese umgekehrt auch in kontinuierlicher Kommunikation mit ihm stehen müssen. In der sich schnell ändernden Projektwelt ist Kommunikation essentiell, um das Projekt „nicht aus der Hand zu geben“, also das Projekt erfolglos abzuschließen. Û Verhandlungsführung: Der Projektmanager bildet die Schnittstelle zwischen den Stakeholdern und der Projektorganisation. Das Interessante ist hierbei, dass <?page no="68"?> Û J UEH#.! A=HEO.E.%A? _* <?page no="69"?> JR/ 4(.`P VE*P_%CPA%H_ 69 zung benötigen, sondern immer echte Profis am Werk sind. Ein weiterer Punkt ist natürlich, dass das Projekt hierdurch sehr wenig individualisiert wird, da eine starke Orientierung an den Projektprozessvorgaben des Unternehmens vorherrscht. Teammanager 9) Die fachlich anspruchsvollste Rolle innerhalb des Projektmanagementteams besitzen die Teammanager. Sie dienen als Vertreter der einzelnen Spezialistenteams und stellen ferner deren Schnittstelle zum Projektmanager dar. Die Teammanager berichten in einem vorgegebenen Zeitraum an den Projektmanager, stellen ihm aber auch im Rahmen des Projekts die Planungsunterstützung. In vielen Projekten sind Teammanager, auf Grund der Größe des Projekts und der damit einhergehenden Größe der Teilprojekte, oft als eigenständige Projektmanager zu sehen, nur auf einer tieferen Ebene. Sollte das Projekt mit agilen Methoden wie SCRUM, Kanban oder Extreme Programming arbeiten, finden die jeweiligen Methoden meist im Rahmen der Arbeit der Teammanager mit ihren Teammitgliedern Anwendung. PRINCE2 bietet an dieser Stelle auch die Möglichkeit, PRINCE2 erfolgreich mit anderen (agilen) Methoden zu kombinieren. Auf die Arbeit des Teammanagers wird innerhalb der PRINCE2-Terminologie aufgrund hoch fachlicher Ausprägungen vergleichsweise wenig eingegangen. Hinsichtlich der Management-Eigenschaften wird sich innerhalb der Methodik eng an den Anforderungen des Projektmanagers orientiert, mit dem Hintergedanken, dass der Teammanager einen fachlichen Hintergrund mitbringen muss. <?page no="70"?> 70 J UEH#.! A=HEO.E.%A? _* <?page no="71"?> JR- 4(.`P B? C%_.CC @PC. 71 Thema Business Case 2.4 Zweck des Themas „Business Case“ ist die Einrichtung von geeigneten Mechanismen, um zu beurteilen, ob ein Projekt wünschenswert, lohnend und realisierbar ist und weiter fortgeführt wird. Auf dieser Grundlage soll über die (weitere) Projektinvestition entschieden werden können. Das Thema gibt dem gleichnamigen Managementprodukt einen Rahmen, innerhalb dessen das Managementprodukt entwickelt und gepflegt wird. Durch die Anwendung wird darüber hinaus das Grundprinzip der fortlaufenden geschäftlichen Rechtfertigung bezweckt bzw. sichergestellt. Innerhalb vieler Projekte stellt genau diese geschäftliche Rechtfertigung ein großes Problem dar. Zu allererst muss erst einmal der Nutzen aufgezeigt werden. Das ist zu Beginn gar nicht so einfach. Das liegt vor allem daran, dass der Nutzen meist viel komplexer zu ermitteln ist, als es sich in den meisten Fällen anfühlt. Hat man sich jedoch erstmal auf einen Nutzen für das Unternehmen geeinigt, ist eine fortlaufende geschäftliche Rechtfertigung durchaus machbar. In der Praxis fällt auf, dass Projekte oft den so genannten „Point of no Return“ sehr schnell erreichen. Zumindest stellen Projektmanager und weitere Projektmitarbeiter in der Praxis oft diese Behauptung auf. Der Point of no Return ist allerdings nur sehr selten erreicht: die Projektmanager wollen das Projekt hierbei einfach künstlich am Leben erhalten. Grund sind hierbei persönliche Faktoren, wie zum Beispiel die Angst, einen schlechten Ruf innerhalb der Organisation zu erlangen. In solchen Fällen sollte der Projektmanager klar aufzeigen, dass sich eine weitere Projektdurchführung nicht mehr lohnt. Abbruch ist schmerzhaft und das Budget kommt einem im Nachhinein fehlinvestiert vor; jedoch ist es besser als das Geld weiterhin in ein Projekt zu stecken, das in der Zukunft ohnehin keinen Erfolg erzielen wird. <?page no="72"?> 72 J UEH#.! A=HEO.E.%A? _* J.4.1 Inhalt eines Business Case Das Managementprodukt „Business Case“ dient als Werkzeug des Themas „Business Case“. Es wird die geschäftliche Rechtfertigung darstellbar gemacht. Der Business Case enthält typischerweise Kosten, Nutzen, Hauptrisiken, Zeitrahmen, negative Nebeneffekte, Gründe, Optionen sowie eine Investitionsrechnung. Anhand des Business Case wird in regelmäßigen Abständen geprüft, ob sich ein Projekt weiterhin lohnt. Der Business Case wird als Entwurf im Prozess „Vorbereiten eines Projekts (SU)“ erstellt und im Prozess „Initiieren eines Projekts (IP)“ auf den auf dem Schaubild abgebildeten Umfang erweitert. Û Gründe (bereits aus SU vorhanden) 1 Û Optionen (bereits aus SU vorhanden) 2 Û Zeitrahmen 3 Û Hauptrisiken 4 Û ROI 5 Û negative Nebeneffekte 6 Û erwarteter Nutzen 7 Û Budget 8 Die Inhalte in ihrer Definition: Û Gründe: Die Gründe stellen den vergangenheitsbezogenen Auslöser für das Projekt dar. Die Olympiade wird beispielsweise durchgeführt, weil die Konjunktur in England aktuell stagniert. Diese Definition und dieses Beispiel gilt es nach der PRINCE2-Terminologie gerade in Bezug auf die Prüfung zu verinnerlichen. In der Praxis gibt es jedoch auch Gründe für ein Projekt, die in der Zukunft liegen, zum Beispiel eine Gesetzesverabschiedung, auf die sich eine Bank vorbereiten muss. <?page no="73"?> JR- 4(.`P B? C%_.CC @PC. 73 Û Optionen: Die in einem Business Case niedergeschriebenen Optionen beschreiben die Handlungsalternativen, die zur Umsetzung der oben beschriebenen Gründe, in Form eines Projekts, in Frage kommen. Der PRINCE2-Terminologie <?page no="74"?> Û Û J UEH#.! A=HEO.E.%A? _* Û Hauptrisiken: Unter diesem Punkt sollten Unsicherheiten aufgeführten werden, die einen so hohen Grad an Kritikalität aufweisen, dass sie bereits alleine den Gesamtprojekterfolg gefährden können. Neben der Auswirkung ist bei jedem Risiko auch die Eintrittswahrscheinlichkeit zu beachten. Mehr hierzu i6 17, C4B6@AA 5+/ zum Thema „Risiko“. <?page no="75"?> JR- 4(.`P B? C%_.CC @PC. 75 monetären Nutzenerbringung summiert, um am Ende ein möglichst positives Ergebnis zu erlangen. Û Negative Nebeneffekte: Die negativen Nebeneffekte stellen das Gegenteil der Nutzenbetrachtung innerhalb eines Business Case dar. Ist der Nutzen ein positiv getriebener Indikator, sind es die negativen Nebeneffekte (oder im engl. „Disbenefit“) negativ getriebene Indikatoren, die das Projekt in der Durchführung mit sich bringt. Im Vergleich zu einem Risiko, das eine Eintrittswahrscheinlichkeit von X aufweist, hat der negative Nebeneffekt immer eine Eintrittswahrscheinlichkeit von 100 Prozent: mit dem Eintritt wird gerechnet, und zwar mit einer Wahrscheinlichkeit von 100 Prozent. Auch wenn die Auswirkung Y in den meisten Fällen nicht zu 100 Prozent beziffert werden kann, sind die negativen Nebeneffekte ein wichtiger Bestandteil der Betrachtung eines Business Case. Ein negativer Nebeneffekt der Olympiade wäre, dass nur wegen der Durchführung der olympischen Spiele die Themse weiter erschlossen werden muss, woraufhin Naturschutzgebiete weichen müssen. Diese Effekte wirken sich nicht direkt auf die monetär getriebene Return on Investment-Rechnung aus. Jedoch muss auch jenen negativen Nebeneffekten das richtige Gehör verschafft werden. Gerade Naturliebhaber stellen bei solchen Großprojekten zurecht wichtige Stakeholder dar, welche auf besondere Art und Weise in die Projektdurchführung miteinbezogen werden sollten. Û Nutzen: Wie bereits bekannt, stellt der Nutzen den Mehrwert des Projekts dar. Hierbei ist zu beachten, dass der Nutzen immer messbar sein muss. Ist der Nutzen nicht messbar, handelt es sich strenggenommen nach PRINCE2 um keinen zu erwähnenden Nutzen innerhalb des Business Case. Den Nutzen für die Olympiade lässt sich sehr gut ermitteln. Hier werden zuerst Milliarden investiert, woraufhin aber auch sehr schnell wieder Milliarden vom IOC, also dem Internationalen Olympischen Komitee, den Fernsehgeldern und den Touristen zurück in den Fiskus Großbritanniens gespült werden. <?page no="76"?> 76 J UEH#.! A=HEO.E.%A? _* Û Budget: Innerhalb des Budgets werden alle für das Projekt benötigten und geplanten Budgets niedergeschrieben. Das sind neben dem eigentlichen Projektbudget das Risikobudget, welches für die Behandlung von Risiken eingesetzt werden soll, sowie das Änderungsbudget, welches für die Steuerung und Implementierung von Änderungen verwendet werden soll. Der Business Case ist, wie bereits schon erwähnt, ein lebendes Managementdokument. Innerhalb eines Projekts wird der Business Case im Grunde genommen dauerhaft am Ende jeder Managementphase überprüft und seitens des Lenkungsausschusses genehmigt. Das beutet im Umkehrschluss auch, dass keiner der acht Inhalte eins erweiterten Business Case tatsächlich fix ist. Alle können und werden innerhalb eines Projekts angepasst. J.4.2 Entwicklungspfad eines Business Case Da sich die Frage nach der geschäftlichen Rechtfertigung aufgrund der sich verändernden Projektumgebung quasi fortlaufend stellt, kann auch der Business Case nicht statisch gehalten werden, sondern muss sich an die veränderte Umgebung anpassen. Diese Anpassung geschieht regelmäßig gegen Ende einer Phase im Prozess-Managen eines Phasenübergangs (SB). Hierbei verfolgt man stringent das Grundprinzip der fortlaufenden geschäftlichen Rechtfertigung. Wie in dem unten aufgeführten Schaubild zu sehen ist, gliedert man diesen Lebenszyklus zwischen der Business-Case-Entwicklung 1) und dem Pflegen des Business Case 2) . Der erste Schritt einer Business-Case-Entwicklung ist die Entwicklung des Business- Case-Entwurfs innerhalb des Prozesses „Vorbereitung eines Projekts (SU)“ 3) . Dieser wird zu Projektbeginn seitens des Lenkungsausschusses freigegeben 4) , bevor er in der ersten Projektphase weiter spezifiziert wird 5) . Am Ende der Initiierungsphase (IP) wird dann der detaillierte Business Case seitens des Lenkungsausschusses verifiziert 6) . Damit ist die Entwicklung des Business Case abgeschlossen. <?page no="77"?> JR- 4(.`P B? C%_.CC @PC. 77 <?page no="78"?> 78 J UEH#.! A=HEO.E.%A? _* In den folgenden Phasen folgt die dauerhafte Pflege des Business Case. Innerhalb der einzelnen Managementphasen entstehen Gründe, weshalb der Business Case in sämtlichen Dimensionen angepasst werden könnte. Diese Anpassungen werden innerhalb des Prozesses eines Phasenübergangs (SB) durchgeführt, um dann am Ende der jeweiligen Managementphase seitens des Lenkungsausschusses verifiziert werden zu können 7) . Wie im Schaubild auf den beiden letzten oberen Pfeilen und auf dem letzten unteren Pfeil zu erkennen ist, wird an diesen Stellen von einer Nutzen-Bestätigung gesprochen. 8) Innerhalb des Themas „Business Case“ gibt es neben dem Dokument „Business Case“ auch noch ein weiteres, ausgesprochen wichtiges Managementprodukt: den Nutzenrevisionsplan. Nutzenrevisionsplan Ist im Managementprodukt Business Case der erwartete Nutzen niedergeschrieben, umfasst der Nutzenrevisionsplan die Techniken, wie und wann der Nutzen gemessen werden soll. Das kann durchaus bereits während des Projekts im Prozess- Managen eines Phasenübergangs (SB) sein, wobei zu beachten ist, dass der Gesamtnutzen in aller Regel erst nach dem Projekt realisiert wird. Der revidierte, also der tatsächlich erwirtschaftete Nutzen wird dann im Nutzenrevisionsplan festgehalten. Der Nutzenrevisionsplan weist eine weitere Besonderheit auf. Sind grundsätzlich alle anderen Managementprodukte nach Projektabschluss nicht mehr weiter zu pflegen, wird der Nutzenrevisionsplan nach Projektabschluss erst richtig mit Inhalt versorgt. Somit stellt er das einzige Managementprodukt dar, welches auch nach Projektabschluss weiterhin mit Input versorgt wird, sogar mit Input versorgt werden muss. Die Verantwortung hierfür geht nach Projektende an das Unternehmensbzw. Programmmanagement über. In der Praxis findet diese Art von Nutzenrevision lei- <?page no="79"?> JR+ QO? _*C,EP*._ \? ` YPG%A.a 0; .% 79 der wenig Anwendung. Viele Projekte werden beendet und dann über Jahre kein Nutzen gemessen bzw. bestätigt; aber genau das gerade ist der wichtigste Indikator dafür, ob ein Projekt Erfolg hatte oder nicht. Übungsfragen zum Kapitel Zwei - Projektvorbereitung 2.5 Hinweis: Es kann nur eine Antwort richtig sein. Die Auflösung findest Du in Kapitel 8. [15] Was ist der Auslöser für den Prozess „Vorbereiten eines Projekts“? á Pro je kt be sc hre ib ung á Projektplan á Projektmandat á Business Case-Entwurf [16] Was ist ein Zweck des Themas „Business Case“? á Richtet Verfahren für die Beobachtung und den Vergleich der tatsächlich erbrachten Leistungen mit den Planzielen ein. á Richtet geeignete Methoden für die Beurteilung ein, ob ein Projekt gerechtfertigt ist und bleibt. á Beurteilt und steuert unsichere Ereignisse oder Situationen. á Beschreibt, wie, wann und mit welchen Kosten Produkte geliefert werden können. [17] Die wichtigsten Stakeholder sind im Projektmanagementteam vertreten. Welches Grundprinzip wird dadurch unterstützt? á fortlaufende geschäftliche Rechtfertigung <?page no="80"?> 80 J UEH#.! A=HEO.E.%A? _* á definierte Rollen und Verantwortlichkeiten á Steuern über Managementphasen á Lernen aus Erfahrung [18] Welche der folgenden Optionen beschreibt einen Zweck des Nutzenrevisionsplans? 1. Zeigt, wie festgestellt werden kann, ob ein Projekt den erwarteten Nutzen erzielt hat. 2. Zeigt, welche Nutzenbewertungen durchgeführt werden müssen. 3. De fini ert d as Pro jekt a ls B as is fü r das w eite re Ma na ge men t un d die B ew ertung seines Erfolgs. 4. Identifiziert die zur Messung des erwarteten Projektnutzens notwendigen Aktivitäten. á 1, 2, 3 á 1, 2, 4 á 1, 3, 4 á 2, 3, 4 [19] Was ist ein Zweck der Projektbeschreibung? á Definiert, wann und wie gemessen werden kann, ob der erwartete Nutzen des Projekts erzielt wurde. á Führt relevante Erfahrungen aus Vorläuferprojekten auf und wie diese sich auf das aktuelle Projekt auswirken können. á Beschreibt die zu verwendenden Qualitätstechniken und -standards, damit bei Durchführung des Projekts das geforderte Qualitätsniveau erreicht wird. á Stellt ausreichend Informationen für die Entscheidung zur Initiierung des Projekts bereit. <?page no="81"?> JR+ QO? _*C,EP*._ \? ` YPG%A.a 0; .% 81 [20] Was ist ein Zweck eines Projekttagebuchs? á Erfassen der für die Phase geplanten Produkte und Aktivitäten á Aufzeichnen informeller offener Punkte á Erfassen und Verfolgen des Status aller während einer Phase gelieferten Produkte á Informieren des Lenkungsausschusses über den in einer Phase erzielten Fortschritt [21] Was ist ein Ziel des Prozesses „Vorbereiten eines Projekts“? á Verstehe n, wa nn, wi e un d zu w elc hen Kost en di e Pr od ukte des Projekts geliefert werden. á Sicherstellen, dass die notwendigen Befugnisse zur Lieferung der Produkte des Projekts vorhanden sind. á Mit geringstmöglichem Aufwand eine Grundlage für die Entscheidung zu treffen, ob es sich überhaupt lohnt, das Projekt zu initiieren. á Die Managementprodukte zusammenstellen, die für die Steuerung des Projekts benötigt werden. [22] Was ist eine Verantwortlichkeit des Projektmanagers? á Delegation der Verantwortung für Änderungen an den Änderungsausschuss á Dokumentation der Kommunikationsmanagementstrategie á Genehmigung der Phasentoleranzen á Genehmigung der Kundenqualitätserwartungen [23] Welche der folgenden Rollen kann der Projektmanager ebenfalls übernehmen? 1. Änderungsausschuss <?page no="82"?> 82 J UEH#.! A=HEO.E.%A? _* 2. Projektsicherung 3. Projektunterstützung 4. Teammanager á 1, 2, 3 á 1, 2, 4 á 1, 3, 4 á 2, 3, 4 [24] Welches ist eine Verantwortlichkeit der Projektsicherungsrolle? á Den Projektmanager über den Status der Produkte des Projekts zu informieren. á Den Informationsbedarf des Lenkungsausschusses zu dokumentieren. á Sicherzustellen, dass der Projektmanager mit den jeweiligen Standards eines Unternehmens vertraut ist, die für das Projekt wichtig sind. á Das Programmmanagement über den Status des Projekts zu informieren. [25] Welches ist eine Rolle in einem Projektmanagementteam? á Unternehmens- oder Programmmanagement á Qualitätssicherung á Stakeholder á Sicherung der Unternehmensinteressen [26] Was ist KEIN Zweck einer Produktbeschreibung? á Zeit- Kostenaufwand für die Herstellung des Produkts definieren. á Notwendige Kenntnisse der für die Qualitätsprüfung des Produkts erforderlichen Personen definieren. <?page no="83"?> JR+ QO? _*C,EP*._ \? ` YPG%A.a 0; .% 83 á Format und Präsentation der Produkte definieren. á Notwendige Kenntnisse der für die Herstellung des Produkts erforderlichen Personen definieren. [27] Welches Thema stellt sicher, dass das Projekt wünschenswert, lohnend und realisierbar bleibt? á Organisation á Fortschritt á Business Case á Ri siken [28] Was ist ein Ziel des Prozesses „Vorbereiten eines Projekts“? á Bestätigen, dass keine bekannten Einschränkungen die Durchführung des Projekts verhindern. á Sicherstellen, dass allen Teammanagern ihre Verantwortlichkeiten bekannt sind. á Die Freigabe des Projektplans vom Unternehmensî oder Programmmanagement einholen. á Die Projektleitdokumentation vorbereiten, um die Genehmigung für die Initiierung des Projekts zu erhalten. [29] Was ist ein Zweck einer Projektbeschreibung? á Beschreibt eine vereinbarte Ausgangsbasis für den Start des Projekts. á Beschreibt den Informationsbedarf der Stakeholder des Projekts. á Beschreibt das Konfigurationsmanagementverfahren für das Projekt. á Beschreibt die erforderliche Berichterstattung an den Lenkungsausschuss. <?page no="84"?> 84 J UEH#.! A=HEO.E.%A? _* [30] Der Zweck des Prozesses „Vorbereiten eines Projekts (SU)“ ist es, … á das Projektendprodukt fertig an den Kunden zu liefern. á granular die Projektarbeiten zu planen. á den detaillierten Business Plan dem Lenkungsausschuss vorzulegen. á mit geringstmöglichem Mittelaufwand herauszufinden, ob sich die Projektinitiierung lohnt. <?page no="85"?> 3 Projektinitiierung Prozess Lenken eines Projekts (DP) 3.1 Zweck des Prozesses „Lenken eines Projekts“ ist es, den Lenkungsausschuss in die Lage zu versetzen, seiner Verantwortung für den Projekterfolg nachzukommen. Dies geschieht, indem er wichtige Entscheidungen fällt und den allgemeinen Verlauf des Projekts steuert, die Abwicklung des Tagesgeschäfts aber dem Projektmanager überlässt. Es gilt sicherzustellen, dass: Û … die Befugnisse für die Initiierung vorhanden sind: Hierbei ist zu beachten, dass der Prozess „Lenken eines Projekts“ der erste Prozess ist, welcher in einem Projekt vonstattengeht, da der Prozess „Vorbereiten eines Projekts (SU)“ vor Projektbeginn abläuft. Vor Projektinitiierung ist es dem Lenkungsausschuss (LA) natürlich ein Anliegen, dass alle Befugnisse vorhanden sind, damit dieser die Initiierung genehmigt. Û … das Projekt über seine Gesamtdauer gesteuert wird und seine Wirtschaftlichkeit behält: Dies stellt der Prozess „Lenken eines Projekts (DP)“ durch den Mechanismus der Ad-hoc-Entscheidungen sicher. Dieser Prozessschritt zieht sich von Beginn an bis zum Ende eines jeden Projekts. Ad-hoc-Anweisungen sind in dem Sinne wichtige Steuerungselemente, als sie die einzige Möglichkeit des Lenkungsausschusses sind, in jeder Situation innerhalb eines Projekts handlungsfähig zu sein. <?page no="86"?> 86 / UEH#.! A%_%A%%.E? _* <?page no="87"?> / RN UEH\.CC X._! ._ .%_.C UEH#.! AC ^>UT 87 Ferner stellen der Lenkungsausschuss und der dafür angelegte Prozess „Lenken eines Projekts“ die Projektwirtschaftlichkeit durch die Überprüfung des Business Case sicher. Dies geschieht innerhalb der Prozess-Schritte „Projekt freigeben“ und „Phasen- oder Ausnahmeplan freigeben“, da diese wichtigen Entscheidungen natürlich zu einem Großteil auf Basis des detaillierten Business Case getroffen werden. Û … über Phasentoleranzabweichungen entschieden werden kann: Da wir uns innerhalb der PRINCE2-Projektorganisation natürlich dem gelehrten Grundprinzip des „Steuern nach dem Ausnahmeprinzip“ völlig verschreiben, hat der Lenkungsausschuss seinem Projektmanager einen gewissen Toleranzbereich X übertragen. Das Projektgeschäft wäre nicht das Projektgeschäft, wenn alle Toleranzen jederzeit und vollkommen eingehalten würden. Sicher tritt genau dieser Fall ein, dass der Projektmanager seine für die Phase vorgegebenen Toleranzbereiche verlässt. In diesem speziellen Fall muss der Projektmanager mit einem so genannten Ausnahmebericht zum Lenkungsausschuss eskalieren. Exkurs - Ausnahme: Als Ausnahme bezeichnet man jene Situation innerhalb eines Projekts, innerhalb deren der Projektmanager seine für die jeweilige Managementphase vorgeschriebene Phasentoleranz überschreitet. Toleranzen können auf sämtlichen Projektdimensionen vergeben werden: Zeit, Budget, Qualität, Risiko, Umfang und Nutzen. Der von PRINCE2 vorgeschriebene Eskalationsprozess sieht vor, dass bei einer eingetretenen Ausnahme (also einer Toleranzüberschreitung) unverzüglich ein Ausnahmebericht an den Lenkungsausschuss verschickt werden muss. Der Lenkungsausschuss entscheidet dann auf Basis des Ausnahmeberichts, wie es mit dem weiteren Projektverlauf weitergeht. An dieser Stelle hat der Lenkungsausschuss drei Möglichkeiten: <?page no="88"?> 88 / UEH#.! A%_%A%%.E? _* Û Der Lenkungsausschuss bemerkt durch die Beschreibung innerhalb des Ausnahmeberichts, dass die Toleranzüberschreitung doch nicht so hohe Auswirkungen auf den Projekterfolg hat, als anfangs angenommen wurde. Darüber hinaus hat er selbst noch genügend Projekttoleranzen, die er dann an den Projektmanager weitergeben kann. Mit diesen neuen Toleranzen kann der Projektmanager weiterarbeiten. Û Der Lenkungsausschuss bemerkt, dass die eskalierte Ausnahme eine enorme Projektauswirkung hat, er sie aber im Rahmen seiner Toleranzen weiterhin steuern kann. Dennoch erscheint ihm diese Ausnahme so kritisch, dass er eine Neuplanung der Phase wünscht. Der hier anfallende neue Phasenplan wird als Ausnahmeplan beschrieben. Auf Basis dieses Ausnahmeplans entscheidet dann der Lenkungsausschuss über die Fortführung oder den Abbruch eines Projekts. Û Die dritte Option des Lenkungsausschusses ist, auf Basis einer Ausnahme zu erkennen, dass sowohl die Phasentoleranzen des Projektmanagers als auch die Projekttoleranzen des Lenkungsausschusses aufgebraucht sind. Jetzt würde rein nach der PRINCE2-Terminologie ein vorzeitiger Projektabschluss erwägt werden. In der Praxis wird der Lenkungsausschuss in jedem Fall dennoch die Option nutzen, mit dem Unternehmensmanagement über eine eventuelle Fortführung des Projekts zu sprechen. Natürlich könnte während des Projekts auch der Fall eintreten, dass der Projektmanager lediglich Bereiche seiner Toleranzen in Anspruch nimmt, diese jedoch nicht überschreitet. Hierbei hat der Projektmanager nur eine Informationspflicht gegenüber dem Lenkungsausschuss. Wichtig ist, dass hierfür keine Eskalation ansteht, sondern ein einfaches Reporting ausreicht. Auch die hier beschriebenen Tätigkeiten finden innerhalb des Prozessschrittes „Phasen oder Ausnahmeplan genehmigen“ statt. Weitere Informationen zu Ausnahmen, Eskalationen und Berichtserstattungen folgen beim Thema „Fortschritt“ in 17C4B6@AA 5+2. <?page no="89"?> / RJ [_%A%%.E._ .%_.C UEH#.! AC ^[UT 89 Û … eine Schnittstelle zum Unternehmens- und Programmmanagement existiert: Da der Lenkungsausschuss das Projekt natürlich stark in seiner Auswirkung repräsentiert, benötigt er eine Möglichkeit, sich mit dem Unternehmensbzw. dem eventuell dazwischen geschalteten Programmmanagement regelmäßig auszutauschen. Da PRINCE2 in der hier gelehrten Art und Weise die Perspektive des Projektmanagers manifestiert, ist ein Prozessschritt, welcher dem Lenkungsausschuss eine Kommunikationsfläche zum Unternehmens- oder Programmmanagement bietet, nicht in der PRINCE2-Terminologie vorgesehen, aber dennoch vorhanden. Û … die Befugnisse für den Abschluss eines Projekts vorhanden sind: Innerhalb des letzten Prozessschrittes stellt der Prozess DP dem Lenkungsausschuss die Aktivität zur abschließenden Überprüfung des Projektfortschritts zur Verfügung. Bei der letzten Aktivität „Projektabschluss freigeben“ werden dem Lenkungsausschuss das vom Projekt gelieferte Endprodukt übergeben und der Projektmanager und das damit einhergehende Projektteam entlastet. Initiieren eines Projekts (IP) 3.2 Hier soll eine solide Grundlage für das Projekt geschaffen werden, die der Organisation ein klares Bild davon vermittelt, was mit den geplanten Arbeiten verbunden ist, bevor größere finanzielle Mittel zugesagt werden. Mit dem Prozess „Initiieren eines Projekts (IP)“ gilt es sicherzustellen, Û … dass sämtliche für die Projektdurchführung notwendigen Policies eingerichtet werden 1) : Diese Policies werden innerhalb der PRINCE2-Terminologie als Managementstrategien beschrieben und bilden jeweils ein Managementprodukt ab. Innerhalb von PRINCE2 unterscheiden wir zwischen 4 Strategien. <?page no="90"?> 90 / UEH#.! A%_%A%%.E? _* <?page no="91"?> / RJ [_%A%%.E._ .%_.C UEH#.! AC ^[UT 91 <?page no="92"?> Û / UEH#.! A%_%A%%.E? _* <?page no="94"?> Û / UEH#.! A%_%A%%.E? _* <?page no="95"?> Û Û / RJ [_%A%%.E._ .%_.C UEH#.! AC ^[UT 95 <?page no="96"?> 96 / UEH#.! A%_%A%%.E? _* Die Projektleitdokumentation 3.3 Ein wesentlicher Part der Projektleitdokumentation (PLD) ist die Projektbeschreibung (siehe Schaubild), welche bereits im Prozess „Vorbereiten eines Projekts (SU)“ erstellt wurde. Damit wird klar, dass bereits Inhalte und Planungsdokumente aus der Vorprojektzeit einen durchaus wichtigen Bestandteil für die folgenden Projektphasen darstellen. Die Projektbeschreibung geht fließend in die PLD ein. Die PLD an sich ist eine Zusammenstellung der wichtigsten Managementprodukte, welche die wesentlichen Informationen über das Projekt beinhalten. Sie bietet damit eine gesicherte Grundlage für den Projektstart und wird an alle Projektinternen verteilt. Darüber hinaus dient die PLD als Single Point of Truth für grundsätzliche Fragen, die während eines Projekts oder bei neuen Projektmitgliedern entstehen können. Sie eignet sich hervorragend zur Einarbeitung neuer Mitarbeiter, da in der Projektleitdokumentation alle Inhalte bzw. alle Fragen enthalten sind, die ein (neuer) Projektmitarbeiter innerhalb eines Projekts hat. In vielen Projekten wird die Projektleitdokumentation auch als Projektvertrag bezeichnet. Die PLD kann wie folgt dargestellt werden: Û als einzelnes Dokument, das alle anderen Managementprodukte als Unterpunkte beinhaltet Û als ein Inhaltsverzeichnis einer Unterlagensammlung Û als in einem Projektmanagement-Tool gesammelte Informationen <?page no="97"?> / R/ >%. UEH#.! Aa.%AIH! ? `._APA%H_ 97 <?page no="98"?> 98 / UEH#.! A%_%A%%.E? _* Thema Pläne 3.4 Der Zweck des Themas „Pläne“ ist die Unterstützung der Kommunikation und zu definieren, was wo wie von wem voraussichtlich wann zu welchen Kosten geliefert bzw. erreicht werden soll. Innerhalb des Themas „Pläne“ wird ferner für die jeweilige Hierarchieebene eine Vordefinition getroffen, wie ein Plan auszusehen hat und wie eigentlich geplant wird. Innerhalb vieler Projekte ist das Thema „Pläne“ sehr weit verbreitet; so weit, dass oft sogar eine Überadministration bezüglich der Planung die Regel ist. PRINCE2 gibt in seinem Thema „Pläne“ keinesfalls eine Überplanung vor. Vielmehr wird die Planung im Rahmen des Grundprinzips „Anpassung an die Projektumgebung“ soweit optimiert, dass sie perfekt an die jeweiligen Projektgegebenheiten angepasst ist. In den folgenden Abschnitten werden wir auf die unterschiedlichen Planungsebenen eingehen und die Art und Weise, wie eine Planerstellung abläuft, durchleuchten. / .4.1 Drei Ebenen der Planung Grundlegend gilt: Je weiter die Planung in die Zukunft reicht, desto schwieriger und unschärfer ist sie. Daher ist es nur in den seltensten Fällen wünschenswert oder möglich, ein Projekt von Beginn an im Detail zu planen. Erst durch iteratives Vorgehen innerhalb der einzelnen Phasen kann eine granulare und sichere Planung ermöglicht werden. Innerhalb der PRINCE2-Terminologie unterscheidet man grundsätzlich 3! #@ verschiedene Planungsebenen: <?page no="99"?> / R- 4(.`P Ua6_. 99 Û Unternehmens- oder Programmplan 1) Û Projektplan 2) Û Phasenplan 3) / Iniitierungsphasenplan 4) / Ausnahmeplan 5) Û Teamplan 6) <?page no="100"?> 100 / UEH#.! A%_%A%%.E? _* Der Unternehmensbzw. Programmplan Innerhalb eines Unternehmens bzw. innerhalb eines Programmplans wird die Planung für strategische Entwicklung des Unternehmens durchgeführt. Diese hochgradig unkonkreten und weit in die Zukunft reichenden Pläne werden jedoch innerhalb der PRINCE2-Methodik nicht genauer beschrieben. Sie haben jedoch enorme Auswirkungen auf die nach PRINCE2 strukturierten Projekte. Projektplan Der Projektplan enthält einen groben Überblick über das Gesamtprojekt von Anfang bis Ende sowie die wichtigsten Produktbeschreibungen mit Lieferterminen und Kosten. Hierbei ist zu beachten, dass die geplante Abstraktionsebene High Level ist. Würde man sich innerhalb dieser Planungsebene bereits mit feinkörnigen Teilproduktbeschreibungen auseinandersetzen, liefe man Gefahr, in einen Planungs-GAU zu steuern. Das liegt daran, dass ein Projekt nie ohne Änderungen auskommt. Geht man nun so vor, dass man bereits am Anfang eine hochkonkrete Planung bis zum Projektende vollzogen hat, muss bei vielen Änderungen der gesamte Projektplan neu durchgeplant werden. Das Projekt läuft so mit voller Kraft in Richtung Überadministration. Abhilfe schafft hierbei die besagte PRINCE2-Vorgehensweise: erste grobe Planung im Projektplan und darauffolgend detailliertere Planung innerhalb der jeweiligen Phasen und Teams. Die erste Fassung des Projektplans wird im Prozess „Initiieren eines Projekts (IP)“ erstellt und ist Bestand der Projektleitdokumentation. Er wird darüber hinaus natürlich im Laufe des Projekts im Prozess-Managen eines Phasenübergangs (SB) wiederholt aktualisiert und angepasst. Der Projektplan in seiner ersten Fassung wird vom Projektmanager in enger Zusammenarbeit mit dem Auftraggeber erstellt und abgestimmt. Im folgenden Projekt wird der Projektplan nur noch seitens des Projektmanagers angepasst. <?page no="101"?> / R- 4(.`P Ua6_. 101 Phasenplan Der Phasenplan stellt den für die jeweilige Phase entsprechenden Plan dar. Innerhalb des Phasenplans gehört es zu den Aufgaben des Projektmanagers, die Toleranzen innerhalb der vorgegebenen Akzeptanzkriterien zu halten. Er stellt von der Planungsebene eine deutlich schärfere Ebene dar. Er bietet die Grundlage für das Management des Tagesgeschäfts innerhalb einer Phase. Der Phasenplan stellt einen Teil des Projektplans dar. Die Ebene des Phasenplans beherbergt neben dem Phasenplan an sich auch noch weitere Pläne, welche für die jeweilige Projektsituation tendenziell notwendig sein können. Initiierungsphasenplan Von der Grundidee ist der Initiierungsphasenplan einfach nur eine frühe Form eines Phasenplans. Er plant in seiner Art und Weise die erste vom Projekt durchzuführende Phase - die Initiierungsphase. Erstellt wird der Initiierungsphasen vom Projektmanager im Rahmen des Prozesses „Vorbereiten eines Projekts (SU)“. Er findet Verwendung in der ersten Fassung der Projektleitdokumentation - der bereits bekannten und auch in SU erstellten Projektbeschreibung. Ausnahmeplan Der Ausnahmeplan stellt eine Sonderform eines Phasenplans dar und wird nur auf Anforderung des Lenkungsausschusses (LA) im Prozess „Managen eines Phasenübergangs (SB)“ erstellt. Der ursprüngliche Trigger des Ausnahmeplans ist ein vorhergegangener Ausnahmebericht. Wie bereits bekannt, wird ein Ausnahmebericht immer auf Basis einer Toleranzüberschreitung erstellt. Zum Verständnis: [1] Ein Ereignis lässt die dem Projektmanager delegierten Toleranzen überschreiten. <?page no="102"?> 102 / UEH#.! A%_%A%%.E? _* <?page no="103"?> / R- 4(.`P Ua6_. 103 Exkurs - Agiles Projekt- und Produktmanagement mit PRINCE2 Agiles Projektmanagement ist aktuell in aller Munde. Themen wie SCRUM, Kanban oder Extreme Programming sind aufgrund ihrer schlanken Ansätze ein gern gesehener Ansatz im Kontext einer immer komplexer werdenden Welt. Oft wird die Diskussion geführt, „welche der beiden Methoden die bessere wäre“. Diese Diskussion erscheint obsolet, hängt die Entscheidung, welchem Vorgehensmodell man sich widmet, doch stark von der jeweiligen Projektumgebung ab. Vielmehr sollte man sich statt der Frage „agile“ oder „klassisch“ die Frage stellen „wie viel von beiden? “. Der Ansatz, durch eine klassische Projektmanagement-Methodik wie PRINCE2 den für große Projekte oft notwendigen Rahmen zu schaffen, und hier in Kombination vereinzelt für Teilprodukte auf agile Produktentwicklungsmethoden wie SCRUM und Extreme Programming zurückzugreifen, ist nur logisch. PRINCE2 wurde in diesem sehr gefragten agilen Bereich nun auch durch eine weitere Ausprägung „PRINCE2 Agile“ ergänzt. Die weitere Beschreibung dieser Methodik würde aber tatsächlich ein eigenes Buch in Anspruch nehmen, weshalb an dieser Stelle nicht weiter darauf eingegangen wird. / .4.2 Die Erstellung eines Plans Im vorangegangenen Abschnitt wurden die verschiedenen Planungsebenen von PRINCE2 in ihrem Umfang genau beschrieben. Die Philosophie hinter der Erstellung von Plänen orientiert sich an Produkten. Damit kommt das Thema „Pläne“ dem Grundprinzip „Produktorientierung“ nach. Es beginnt mit der groben Gesamtplanung des Projekts in Form des Projektplans. Hier wird das Projektendprodukt definiert, die wichtigsten (Teil-)Produktbeschreibungen werden davon abgeleitet, in verschiedenen Formen darstellbar gemacht <?page no="104"?> 104 / UEH#.! A%_%A%%.E? _* <?page no="105"?> / R- 4(.`P Ua6_. 105 (Produktstrukturplan bzw. Produktflussdiagramm) und letztlich in Aktivitäten umgewandelt. Angereichert mit den notwendigen Ressourcen ergibt das einen fertigen Projektplan. Hierbei ist zu beachten, dass zwar Produkt- und Aktivitätsbeschreibungen in einem Projektplan niedergeschrieben sind, die Planungsschärfe jedoch, da wir noch auf einer sehr abstrakten Planungseben befinden, sehr wenig feinkörnig ist. Der Ablauf der Erstellung eines Plans wie im Schaubild ist auf allen Planungsebenen (Projektplan, Phasenplan, Teamplan) gleich. Der einzige Unterschied neben der Tatsache, dass der Phasen- und Teamplan natürlich keine Planung des Projektendprodukts beinhaltet, ist die Reihenfolge an Aktivitäten zur Erstellung eines Plans, welche auf Phasen- und Teamplanebene deutlich granularer wiederholt wird. Sehen wir uns in den folgenden Schritten die Erstellung eines Plans genauer an: [1] Plan entwerfen: Innerhalb des ersten Schrittes geht es nicht um die richtige Befüllung des Plans mit Inhalten, sondern vielmehr um das Design der Art und Weise der Planung. Nutzt man PRINCE2-Templates, designt man sich eigene Tools oder verwendet man vielleicht doch ein Projektmanagement-Planungstool? [2] Produkte definieren und analysieren: Hierbei geht es um die tatsächliche Planung; also welche Produkte auf der jeweiligen Planungshierarchie geplant werden sollen. Auf der Projektplanebene würde man hier die Produktbeschreibung des Projektendprodukts (PEP), welche bekannterweise ja in dem Prozess „Vorbereiten eines Projekts SU“ erstellt wird, niederschreiben. In dem Projektplan für Olympia wäre hier die erste grobe Beschreibung der fertigen Olympiade als auch die wichtigsten vom Projekt zu liefernden Teilprodukte wie die Stadien, das olympische Dorf und Ausbau der Themse und der Verkehrsinfrastruktur. 2.1 Produktstrukturplan erstellen: Der Produktstrukturplan stellt eine hierarchische Planungsansicht dar. Dadurch wird ersichtlich, dass ganz oben die <?page no="106"?> 106 / UEH#.! A%_%A%%.E? _* Produktbeschreibung des Projektendprodukts steht, das durch die tieferen Ebenen auf eine immer feinkörnigere Teilproduktstufe gebracht wird, bis man irgendwann auf der Aktivitätenebene angelangt ist. Auf der Ebene des Projektplans ist dieser Produktstrukturplan logischerweise sehr schlank gehalten, da dort keine tiefe Planung vorherrscht. Je schärfer man jedoch in die Planerstellung geht, wird vom Phasenplan bis hin zum Teamplan das Produktstrukturdiagramm immer weiter verfeinert. 2.2 Produktflussdiagramm erstellen: Das Produktflussdiagramm stellt ebenfalls eine grafische Produktplanung, ähnlich wie der Produktstrukturplan, dar. Der Unterschied liegt hierbei vor allem im zeitlichen Aspekt. Im Produktflussdiagramm wird die geplante Produktentwicklung in einem zum Beispiel Gant-Diagramm grafisch aufgearbeitet. Hierbei gut zu erkennen ist der kritische Pfad der Produktentwicklung, der durch diese Aufbereitung sichtbar wird. [3] Aktivitäten und Abhängigkeiten identifizieren: Hierbei geht es darum, die Aktivitäten zu anderen Produkten oder anderen Projekten zu identifizieren und niederzuschreiben und die dafür notwendigen Aktivitäten zum Managen der Abhängigkeiten zu planen. Abhängigkeiten, vor allem zu externen Zulieferern oder Parallelprojekten stellen in der Praxis oft ein enormes Risiko dar. Grund hierfür ist die Tatsache, dass der Fortschritt der Abhängigkeit außerhalb der Zuständigkeiten des Projektmanagers, oft sogar auch außerhalb der Zuständigkeit des LA liegt. [4] Schätzungen durchführen: Hat man die Produkte, die Aktivitäten und die Abhängigkeiten identifiziert, geht es im Schritt „Schätzungen durchführen“ um die Art Ressourcenplanung innerhalb des Projekts. Personen und Geld sind die wichtigsten Ressourcen, welche in richtiger Kombination für einen Plan allokiert werden müssen, damit ein Projekt erfolgreich ist. <?page no="107"?> / R+ 4(.`P : HEACL(E%AA 107 [5] Zeitplan erstellen: Bevor ein fertiger Plan entstanden ist, fehlt noch die zeitliche Einschätzung, welche durch einen Zeitplan erstellt werden soll. Mit dem Zeitplan sind alle wichtigen Punkte eines Plans vollständig, womit der Plan seine Vollständigkeit erlangt. Thema Fortschritt 3.5 Eingerichtete Mechanismen für einen repräsentativen Soll-Ist-Vergleich, der Abweichungen und damit verbundene Steuerungsmaßnahmen aufzeigen soll, stellen den Zweck des Themas „Fortschritt“ dar. Als Fortschritt bezeichnet man das Vorankommen innerhalb eines vorher definierten Plans. Der Fortschritt kann auf Projekt-, Phasen- oder Arbeitspaketebene überwacht und gesteuert werden. Im Grunde geht es darum, die richtige Information zum richtigen Zeitpunkt zu erhalten, um die richtige und notwendige Entscheidung treffen zu können. / .5.1 Projektsteuerungsmittel Der unten aufgeführte Kreislauf wurde innerhalb der vergangenen Zeilen zu Genüge beschrieben. Inzwischen sollten die hierfür aufgeschriebenen Schritte bekannt und verstanden sein. Im Thema „Fortschritt“ spielt der Projektsteuerungskreislauf jedoch nochmal eine weitere Rolle. Hier wird dieser als beispielhafte Beschreibung zur exakten Anwendung der Projektsteuerungsmittel verwendet: Planen, Delegieren, Überwachen und Steuern. Wie bereits in 17C4B6@AA 5+( kurz darauf eingegangen wurde, werden die Projekt, steuerungsmittel im Prozess „Initiieren eines Projekts (IP)“ erstellt und ab dann verwendet. Für was genau werden sie aber verwendet? <?page no="108"?> 108 / UEH#.! A%_%A%%.E? _* <?page no="109"?> / R+ 4(.`P : HEACL(E%AA 109 Steuerungsmittel: Steuerungsmittel dienen als Werkzeuge, als Tool, welche den jeweils höheren Hierarchiestufen im Projekt helfen, den Fortschritt ihrer darunterliegenden Stufen zu managen. Die jeweils höhere Hierarchiestufe kann somit: Õ den bereits erzielten Fortschritt überwachen Õ Soll-Ist-Abgleiche aufstellen Õ bei Bedarf steuernd eingreifen Õ Korrekturmaßnahmen neu planen Õ das Geplante zu delegieren Innerhalb der Steuerungsmittel unterscheidet man zwei Ausprägungen: die ereignisgesteuerten Steuerungsmitteln und die zeitgesteuerten Steuerungsmittel. Ereignisgesteuert 1) : Der wohl häufigste Trigger für die Erstellung eines Steuerungsmittels ist das Ereignis. Dies liegt daran, dass es innerhalb von Projekten oft unvorhergesehene Ereignisse gibt, die eine Aktivität nach sich ziehen. Das Ereignis an sich kann absolut unterschiedlich ausfallen. Meist sind es auftretende Risiken, kurzfristig auftauchende offene Themen oder aber auch ein Phasenbzw. Projektabschluss, die einen Auslöser für die Erstellung eines Steuerungsmittels darstellen. Nun stellt sich dem aufmerksamen Leser sicher die Frage „Wie kann ein Phasen- oder Projektabschluss bitte ereignisgesteuert sein? Zeitlichgesteuert würde hier doch viel mehr passen.“ Grundsätzlich stimmt die Aussage. Jedoch ist der zeitliche Aspekt deshalb nicht gegeben, weil keine Garantie auf den Phasenbzw. Projektabschluss gegeben werden kann. Die zeitgesteuerten Steuerungsmittel haben eine Erstellungsgarantie, die ereignisgesteuerten brauchen ein vorhergegangenes Ereignis. Typische ereignisgesteuerte Steuerungsmittel innerhalb von PRINCE2 sind: Ausnahmebericht in Folge einer Toleranzüberschreitung, Offener Punkt-Bericht infolge eines zum Beispiel Änderungsantrages, Arbeitspaket infolge eines neuen Todo´s, <?page no="110"?> 110 / UEH#.! A%_%A%%.E? _* Phasenabschlussbericht infolge eines Phasenabschlusses, Erfahrungsbericht infolge eines Phasenbzw. Projektabschlusses. Auf den ersten Blick wird klar, dass es sich hierbei rein um Managementprodukte handelt, welche als Steuerungsmittel definiert sind. Zeitlich gesteuert 2) : Hier kommen Steuerungsmittel ins Spiel, die nur an einem vordefinierten Zeitpunkt innerhalb des Projekts erstellt werden. Gleich, was um das Projekt herum passiert, diese Mittel werden genutzt. Im Schaubild hier sind der Projektstatusbericht und der Teamstatusbericht erwähnt. Diese beiden Steuerungsmittel sind in der PRINCE2-Terminologie auch die beiden einzigen Steuerungsmittel, welche als zeitlich gesteuert definiert sind. In der Praxis bedeutet das, dass, gleich wie sich das Projekt verhält, das Team um die Teammanager bzw. Teilprojektleiter sowie der Projektmanager jeweils ihre Statusberichte erstellt und an die jeweils höhere Managementebene übermittelt. Das macht viel Sinn, da für die Form von Berichten kein Ereignis vorhergehen muss, wie es in den anderen Berichten bzw. Steuerungsmitteln sein muss. / .5.2 Toleranzen und Ausnahmen Wie bereits durch das Grundprinzip „Steuern nach dem Ausnahmeprinzip“ bekannt ist, gebühren verschiedenen Management-Ebenen unterschiedliche Kompetenzbereiche, in denen frei von Gesprächen mit ihren Vorgesetzten entschieden erden darf. Hierbei helfen ihnen a) die Toleranzen und b) die Ausnahmen, die für sich sehr genau beschrieben sind. a) Toleranzen: Eine Toleranz im Sinne von PRINCE2 ist ein von der höheren Projekt- Hierarchiestufe vorgegebener Bereich, in dem die untere Hierarchiestufe frei, ohne das Zutun der höheren Ebene, entscheiden und interagieren darf. Das hat zum Vorteil, dass 1. die höhere Stufe dank Delegation weniger Arbeit zu bewäl- <?page no="111"?> / R+ 4(.`P : HEACL(E%AA 111 tigen hat, und 2. die niedrigere Stufe weniger zeitraubenden Abstimmungsaufwand auszuführen hat. Ganz abzusehen von den motivierenden Effekten, welche die unteren Stufen betreffen. Toleranzen werden zum Beispiel vom LA an den Projektmanager übergeben und umfassen Dimensionen wie beispielsweise Zeit, Kosten, Qualität, Umfang, Nutzen oder Risiko. Wenn also ein auftretendes Ereignis, zum Beispiel eine unerwartet auftretende Kältewelle, die Zeittoleranz des Olympia-Stadion-Baus um die vereinbarten 14 Tage überschreitet, kommt eine Ausnahme „ins Spiel“, die im folgenden Punkt genauer erläutert wird. b) Ausnahmen: Eine Ausnahme stellt eine Überschreitung des vereinbarten Toleranzbereichs dar; also jener Moment innerhalb eines Projekts, in dem ein Ereignis eine der vereinbarten Toleranzen der Projektdimensionen verletzt bzw. voraussichtlich verletzen wird. Wenn also die bereits erwähnte Kältewelle das Projekt trifft, die zeitlichen Engpässe beim Bauen sich aber erst in einem Monat auswirken werden, aber bereits bekannt sind, handelt es sich um eine voraussichtliche Toleranzverletzung, was ebenfalls eine Ausnahme darstellt. Eine Toleranzbzw. eine vorläufige Toleranzüberschreitung zieht somit eine Ausnahme und die Ausnahme dann einen Ausnahmebericht mit sich. Dieser Ausnahmebericht stellt für die jeweilige Hierarchiestufe ein Eskalationswerkzeug dar, mit dem sie die jeweils höhere Stufe über das angefallene bzw. demnächst anfallende Ereignis informieren. Welche Toleranzen zusammenfassend auf welche Projektebene treffen und welche Projektebene mit welchen Dokument berichtet oder eskaliert, stellt das folgende Schaubild dar und wird in den folgenden Zeilen genauer erläutert. <?page no="112"?> 112 / UEH#.! A%_%A%%.E? _* <?page no="113"?> / R+ 4(.`P : HEACL(E%AA 113 Unternehmensbzw. Programmmanagement Toleranzen: Je nachdem, ob das Projekt direkt an das Unternehmen oder an ein eventuell dazwischen geschaltetes Programm berichtet, stattet die jeweilige Ebene das Projekt bzw. in Vertretung natürlich den Lenkungsausschuss, mit entsprechenden Projekttoleranzen aus. Die Projekttoleranzen beziehen sich hierbei auf das Gesamtprojekt, mit allen Phasen, Teilprojekten und Dimensionen. Berichtsbzw. Eskalationswerkzeug: Es gibt keine höhere Ebene an die kommuniziert werden muss. Lenkungsausschuss Toleranzen: Der LA hat durch die Kompetenz des Unternehmens bzw. des Programms einen Toleranzpool für das Gesamtprojekt übertragen bekommen. Nun ist es seine Aufgabe, diese Toleranzen im richtigen Umfang an den Projektmanager weiterzugeben. Fakt ist, dass der LA niemals seine gesamten Projekttoleranzen an den Projektmanager in Form der hierfür vorgesehenen Phasentoleranzen übergibt. Wie der Name schon sagt, sind Phasentoleranzen für jede einzelne Managementphase zu bewerten und zu verteilen. Wie eine strukturierte Verteilung dieser Toleranzen aussehen könnte, folgt in diesem Kapitel zum Ende mit einem kleinen Exkurs. Der LA übergibt dem Projektmanager für die anstehende Phase die geeignete Menge an Phasentoleranzen, mit denen der Projektmanager unter Annahme des aktuell gültigen Phasenplans zurechtkommen sollte. Berichts- und Eskalationswerkzeug: In der Terminologie von PRINCE2 ist auf die Frage, wie der LA mit dem Unternehmensbzw. Programmmanagement kommuniziert, keine Antwort zu finden. Da es sich mit PRINCE2 um ein Projektmanagementframework handelt, ist auf diese Frage auch nicht unbedingt eine Antwort zu erwarten. Andere, von AXELOS, dem Rechteinhaber von PRINCE, entwickelte Frameworks wie zum Beispiel MSP ® Managing Successfull Programs, beschäftigen sich sehr tiefgehend <?page no="114"?> 114 / UEH#.! A%_%A%%.E? _* <?page no="115"?> / R+ 4(.`P : HEACL(E%AA 115 <?page no="116"?> 116 / UEH#.! A%_%A%%.E? _* Transparenz und fachlichen Güte geplant worden sind. Der Nachteil hierbei ist jedoch, dass die planende Ebene oft hohe Puffer mit einbezieht, um sich selbst hierdurch mehr Spielraum zu schaffen. In der Praxis führt das oft zu enormen Mehraufwand, da falsch allokierte Toleranzen bereitgestellt werden. Gegenstromverfahren: Eine Möglichkeit, den Nachteilen beider Prinzipien zu entfliehen und die Vorteile zu bündeln, ist das Gegenstromverfahren. Hierbei machen die unteren Ebenen einen ersten Vorschlag, der mit der höheren Ebene verhandelt und in den meisten Fällen auch angepasst wird. Hierdurch entsteht der klare Vorteil, dass offen über die Toleranzen gesprochen wird. In der Praxis findet das Gegenstromverfahren die häufigste Anwendung. Auch wenn beiden Parteien das „Spiel“ bekannt ist und daher aus Prinzip ein Puffer aufgeschlagen wird, damit die höhere Ebene aus Prinzip eine Kürzung durchführt, kann man sagen, dass es sich dennoch bewährt hat. Natürlich verbleibt es situativ der Kultur des Projekts selbst darüber zu entscheiden, wie solche Toleranzen vereinbart werden. / .5.3 Management vs. Technische Phasen Innerhalb der PRINCE2-Terminologie wird regelmäßig über die für das Thema „Fortschritt“ essentielle Managementphase gesprochen. Innerhalb dieser hat der Projektmanager seine Toleranzen und seinen Managementbereich zu verantworten. Was für den Projektmanager die Managementphase darstellt, sind für den Teammanager die technischen Phasen das Pendant. Im Folgenden werden zum einen nochmal die Unterschiede beider Phasen klargemacht, zum anderen wird aber auch beschrieben, wie die Einteilung und die Planung solcher Phasen auszusehen hat. Gerade in Bezug auf die Reportingkultur ist diese Fragestellung von entscheidender Bedeutung. <?page no="117"?> / R+ 4(.`P : HEACL(E%AA 117 Managementphasen 1) Managementphasen sind Etappen eines Projekts, die an vorhersehbaren Entscheidungspunkten ausgerichtet sind. Sie unterstützen das Grundprinzip Steuern über Managementphasen, indem Befugnisse (Toleranzen) phasenweise an den Projektmanager weiterdelegiert werden. Darüber hinaus haben Managementphasen folgende Eigenschaften: Õ Sie stellen Prüfpunkte dar, an denen der Lenkungsausschuss das Projekt revidiert. Õ Am Ende einer Managementphase wird eine neue Zusage für Ressourcen und Mittel erteilt. Õ Sie folgen immer nacheinander und überlappen sich nicht. Õ Sie bieten die Möglichkeit, die Projektrahmenbedingungen anzupassen. <?page no="118"?> 118 / UEH#.! A%_%A%%.E? _* Zur Festlegung von Managementphasen müssen grundsätzlich mehrere Elemente gegeneinander abgewogen werden: Õ Wie risikoreich ist ein Projekt? @ Je riskanter, desto mehr Kontrollpunkte sollte es geben, desto mehr Managementphasen sollten geplant werden. Õ Wann im Projekt sind die wichtigen Entscheidungspunkte? @ Große, essentielle Ereignisse sollten schon früh bekannt sein, und nach denen sollten auch die Managementphasen geplant werden. Õ Welc he w icht igen E reign is se inne rhal b der Or ga nisa tion f in den wann s tat t? @ Sollte die Quartalsbzw. Jahresabschlussprüfung auf das Ende einer Managementphase fallen, ist auszugehen, dass sehr wenige Entscheidungsressourcen bereitstehen. Zu wenige, lange Managementphasen bieten zu wenige Steuerungsmöglichkeiten; zu viele, kurze Managementphasen stellen hingehen einen hohen administrativen Aufwand dar. Hier ist die subjektive Einschätzung des Projektmanagers und des Lenkungsausschusses gefragt. Technische Phasen 2) Eine technische Phase wird in der Methodik von PRINCE2 als den Zusammenschluss von vielen Arbeitspaketen beschrieben. Typischerweise zielen einige Arbeitspakete auf ein großes Ganzes ab. Würde man hier mehr Agilität einfließen lassen, kann man auch sagen, dass eine technische Phase ein Sprint innerhalb einer Managementphase darstellt. Beispielhafte technische Phasen sind „Entwickeln“, „Umsetzen“, „Test“ und „Roll Out“, innerhalb deren das jeweilige Team sich nur um diese Thematik kümmert. Andere technische Phasen könnten auch „Bau der 1. Etage“ oder „Bau des Daches“ sein. <?page no="119"?> / R) UEH\.CCSWP_P*._ .%_.C U(PC._'O.E*P_*C ^5BT 119 Im Gegensatz zu Managementphasen können auch sehr viele technische Phasen gleichzeitig freigegeben werden, solange genügend Teammanager zur Verfügung stehen. Zu beachten ist hierbei lediglich die Tatsache, dass technische Phasen mit dem Ende einer Managementphase auch zum Ende kommen sollten. Hierbei liegt die Betonung auf „sollte“. Da dies nie zu 100 Prozent garantiert sein kann, gibt PRINCE2 als Workaround-Lösung die so genannte „Produktzwischenabnahme“ vor. Die Produktzwischenabnahme besagt, dass eine qualitätsverantwortliche Person sich die erstellten Produkte ansieht, bewertet und bei einem positiven Befund das Überlappen der technischen Phase akzeptiert. Prozess-Managen eines Phasenübergangs (SB) 3.6 Der Zweck des Prozess-Managen eines Phasenübergangs (im Englischen „Stage Boundary“ (SB)) besteht darin, dem Lenkungsausschuss genügend Informationen zukommen zu lassen, damit dieser über den Erfolg der jeweiligen Phasen entscheiden, den aktualisierten Projektplan prüfen und die geschäftliche Rechtfertigung weiterhin erkennen kann. Daher wird dieser Prozess gegen Ende der jeweiligen Phase parallel zum Prozess „Steuern einer Phase (CS)“ durchgeführt. Am Ende der letzten Managementphase wird das Prozess-Managen eines Phasenübergangs (SB) durch den Prozess „Abschließen eines Projekts (CP)“ ersetzt. Im Folgenden unterscheiden wir den Prozess (SB) in die Erreichung eines Phasenübergangs zum einen (Normalfall) und in die Anforderung eines Ausnahmeplans zum anderen (bei vorhergegangener Ausnahme). Ziel des Prozesses bei einem „normalen“ Phasenübergang ist es, Û … den Phasenplan inklusive Produktbeschreibungen für die nächste Phase zu planen 1) : Gegen Ende der noch laufenden Phase wird seitens des Projektmanagers die nächste Managementphase inklusive der hierfür notwendigen Produktbeschreibungen in Abstimmung mit dem Teammanager geplant. <?page no="120"?> 120 / UEH#.! A%_%A%%.E? _* <?page no="121"?> / R) UEH\.CCSWP_P*._ .%_.C U(PC._'O.E*P_*C ^5BT 121 Û … den Projektplan zu aktualisieren 2) : Ist die nächste Phase samt Produktbeschreibungen im neuen Phasenplan geplant worden, müssen diese neue Ausprägung und eventuelle Änderungen natürlich auch im Projektplan aktualisiert werden. Der Projektplan wird in seinem ersten Entwurf in enger Abstimmung von Auftraggeber und Projektmanager erstellt, im Folgenden aber alleine seitens des Projektmanagers aktualisiert und dann am Ende der Phase bzw. auch am Ende des Prozesses SB dem LA zur Genehmigung vorgelegt. Û … den Business Case zu aktualisieren 3) : In der vorangegangenen Phase sind sicherlich eine Vielzahl an Änderungen seitens der im Business Case beschriebenen Inhalte aufgetreten. Es könnten neue Hauptrisiken dazu gekommen sein, der erwartete Nutzen könnte sich angepasst haben, das Budget wurde gekürzt… Alle diese neuen Aspekte gehören in das Business Case-Dokument, welches bekanntermaßen die geschäftliche Rechtfertigung darstellt. Diese muss natürlich getreu dem Grundprinzip „fortlaufende geschäftliche Rechtfertigung“ auch am Ende einer jeweiligen Phase dem LA mittels des aktualisierten Business Case aufgezeigt werden. Û … eventuell auftretender Nutzen im Nutzenrevisionsplan zu berücksichtigen 4) : Wie im Thema „Business Case“ schon sehr ausgiebig erklärt wurde, wird der erwartete Nutzen im Dokument bzw. Managementprodukt „Business Case“ niedergeschrieben, der tatsächlich erlangte Nutzen jedoch im Managementprodukt „Nutzenrevisionsplan“. Der am Ende erlangte Nutzen wird sich sicher erst nach einer gewissen Zeit nach dem Projekt einstellen. Gewisse Teilnutzen können aber dennoch schon während der Projektlaufzeit auftreten. So könnte eine der Londoner Fußballmannschaften bereits vor Beginn der Olympiade im neuen, fertig erbauten Stadion ihre Spiele abhalten und so bereits während der Projektlaufzeit einen Nutzen erzielen. Dieser Nutzen sollte immer am Ende der jeweiligen Phase identifiziert und im „Nutzenrevisionsplan“ niedergeschrieben werden. <?page no="122"?> 122 / UEH#.! A%_%A%%.E? _* Û … Phasenabschlussbericht zu erstellen 5) : Im folgenden Prozessschritt wird dem LA der zeitgesteuerte Phasenabschlussbericht vom Projektmanager erstellt. Er stellt eine Form dar, welche über den Erfolg und Misserfolg der zurückgelegten Phase berichtet. Û … Erfahrungen aus der letzten Phase im Erfahrungsprotokoll zu konsolidieren 6) : Das Grundprinzip „Lernen aus Erfahrung“ besagt, dass neben dem ersten großen Erfahrungsaustausch bei Projektbeginn auch während der Projektlaufzeit an sich ein Erfahrungsaustausch stattfinden soll. Dieser Erfahrungsaustausch sollte anhand des Erfahrungsprotokolls geschehen. In der vorhergegangenen Phase sollte der Projektmanager samt Projektteam das Erfahrungsprotokoll mit denen in der letzten Phase gemachten Erfahrungen befüllen und beschreiben. Dies geschieht ebenfalls im letzten Prozessschritt des Prozesses „SB“. Der Output des Prozesses „Managen eines Phasenübergangs (SB)“ ist ein Antrag auf Genehmigung des nächsten Phasenplans, welche der LA nun auf Grundlage der eben erstellten Dokumente zu bewilligen oder zu verweigern hat. Ziel des Prozesses bei einer „Anforderung eines Ausnahmeplans“ ist es 7) , Û den Ausnahmeplan zu erstellen, um dem Lenkungsausschuss alle Informationen darüber zu liefern, Û vom Lenkungsausschuss die Genehmigung einzuholen, um den aktuellen Phasenplan durch den Ausnahmeplan zu ersetzen und den Projektplan anzupassen. Û Wichtig: speziell im Ausnahmefall muss der Business Case grundlegend geprüft werden, um weiterhin die geschäftliche Rechtfertigung bestätigen zu können. <?page no="123"?> / R& 4(.`P 7%C%! H 123 Thema Risiko 3.7 Das Thema „Risiko bzw. Risikomanagement“ ist innerhalb vieler Projekte das Thema mit dem höchsten Gewicht für den Projekterfolg. Je mehr und je besser man Risikomanagement betreibt, desto exponentieller steigt die Chance, das Projekt mit Erfolg abzuschließen. Umgekehrt wirkt sich dieser Effekt natürlich auch progressiv negativ auf den Projekterfolg aus. Das ist einer der Gründe, weshalb dem Thema „Risiko“ innerhalb der PRINCE2-Terminologie mit am meisten Zeit gewidmet wird. Zweck des Themas „Risiko“ ist, Unsicherheiten im Kontext zu den Projektzielen zu identifizieren, zu bewerten, eventuelle Gegenmaßnamen zu planen und die richtigen Schritte zur Implementierung einzuleiten. Das Thema „Risiko“ sollte innerhalb eines Projekts proaktiv angegangen werden. So erhöht man die Erfolgschancen, da durch weitsichtige Risikobehandlung der Überraschungseffekt der Risiken deutlich minimiert wird. / .7.1 Risiko Definition Definition von Risiko 1) Laut PRINCE2 und auch der ISO-Norm 31.000 ist ein Risiko nicht pauschal als negativ zu betrachten, sondern stellt vielmehr eine Unsicherheit dar. Ein Risiko ist in zwei Richtungen denkbar: Bedrohung und Chance. Bedrohung 2) Eine Bedrohung bezeichnet ein unsicheres Ereignis, welches negativen Einfluss auf die Projektziele haben könnte. Wichtig ist hierbei das Keyword „negativ“. Eine Bedrohung kann nie eine positive Auswirkung mit sich bringen. <?page no="124"?> 124 / UEH#.! A%_%A%%.E? _* <?page no="125"?> / R& 4(.`P 7%C%! H 125 Chance 3) Als Chance bezeichnet man ein unsicheres Ereignis, welches positiven Einfluss die die Projektziele haben könnte. Wichtig ist hierbei das Keyword „positiv“. Innerhalb der PRINCE2-Risikodefinition unterscheidet man in Risikoursache, Risikoereignis und Auswirkung auf die Projektziele. Im folgenden Merksatz sind alle drei Begrifflichkeiten aneinanderhängend verwendet, um den Zusammenhang klar zu machen. Eine Risikoursache kann ein Risikoereignis auslösen und hat Auswirkungen auf die Projektziele. Risikoursache 4) Ist der nahbarste Grund, weshalb ein Risikoereignis überhaupt entstehen kann. Bsp.: Grippewelle. Risikoereignis 5) Das Geschehen, welches eine Auswirkung auf das Projektziel haben kann. Bsp.: Mitarbeiter der Baufirma werden durch die Grippewelle krank. Auswirkung 6) Die letztlich das Projekt betreffende Wirkung. Wichtig ist hierbei, dass die Auswirkung ein Kontext auf das Projekt bzw. das Projektziel vorweist. Bsp.: Stadion wird nicht rechtzeitig fertig gebaut. <?page no="126"?> 126 / UEH#.! A%_%A%%.E? _* / .7.2 Prozesse im Risikomanagement Der Prozess innerhalb des Risikomanagements beschreibt das Verfahren zur Erkennung und Bewertung einzelner Risiken sowie der Planung und Umsetzung der Gegenmaßnamen. Risikomanagement ist kein konkreter Zeitabschnitt eines Projekts, sondern umschließt vielmehr die Dauer des Gesamtprojekts. Es muss dauerhaft neben dem Tagesgeschäft mitfunktionieren. Die Frage, wie im Projekt Risikomanagement betrieben wird, wird in der Risikomanagementstrategie eines Projekts festgehalten. Die Risikomanagementstrategie wird im Prozess „Initiieren eines Projekts (IP)“ indikativ erstellt, im Laufe des Projekts jedoch bei Bedarf jederzeit angepasst. Auch tritt der Fall ein, dass eine Risikomanagementstrategie vom Unternehmen vorgegeben ist. Dies ist meist in großen bzw. regulierten Unternehmen, wie an der Börse gelistete Unternehmen oder Banken, der Fall. Die Risikomanagementstrategie Die Risikomanagementstrategie ist eine Policy, die beschreibt, welche Ziele durch das Risikomanagement erreicht werden sollen, welche Rollen und Verantwortlichkeiten es gibt, wie hoch die Risikotoleranz ist, welche präferierte Risikobehandlungsmaßnahme es innerhalb des Projektes gibt, etwaige zeitliche Aspekte sowie die geforderten Berichtsanforderungen. Oftmals wird die Risikomanagementstrategie aus der Unternehmens- oder Programmmanagementstrategie übernommen. Im folgenden Schaubild sind die Schritte des Risikomanagements aufgezeigt, welche in den folgenden Zeilen genauer beschrieben werden. <?page no="127"?> / R& 4(.`P 7%C%! H 127 <?page no="128"?> 128 / UEH#.! A%_%A%%.E? _* Kontext und Risiko identifizieren Es muss herausgefunden werden, ob es Risiken gibt, die die Ziele des Projekts tangieren. Hierbei ist der vorhandene Kontext zum Projekt zu beachten. Es gibt durchaus Risiken, die während eines Projekts bestehen. Eine Investition in die Staatsanleihe von Venezuela ist laut den bekannten Rating-Agenturen eine risikoreiche Finanzinvestition. Solange der Projektleiter der Olympischen Spiele das Projektbudget nicht in diese Staatsanleihe investiert hat, besteht zwischen dem grundsätzlich hohen Risiko und dem Projektziel kein Zusammenhang. Daher wird die Anleihe aus Venezuela nicht berücksichtigt. Neben dem Kontext muss aber auch die Eintrittsnähe gegeben sein: dass die Erde irgendwann durch die Explosion der Sonne „untergeht“, ist wissenschaftlich zu 100% belegt. Um festzustellen, dass die Explosion der Sonne eine enorme Auswirkung auf den Projekterfolg hat, braucht es keinen Wissenschaftler. Wieso aber berücksichtig man dann dieses Risiko nicht im Projekt? Die Antwort auf diese Frage ist ganz einfach: es besteht kein zeitlicher Zusammenhang; die Eintrittsnähe ist einfach nicht gegeben. Identifizierte, eintrittsnahe und mit einem Projektkontext versehenen Projektrisiken müssen im Risikoregister notiert und beschrieben werden, damit alle Projektbeteiligten informiert sind. Das Risikoregister Das Risikoregister ist eine Sammelkartei, in der jedes Einzelrisiko dokumentiert und in Stichpunkten mit der nötigsten Information beschrieben wird. Wird kein Projektmanagementtool verwendet, ist die meistgewählte Form der Darstellung eine umfangreiche Excel-Tabelle mit typischen Spalten wie: ID (fortlaufende Nummer), Beschreibung, Eintrittswahrscheinlichkeit, Auswirkung, Verantwortlichkeit etc. <?page no="129"?> / R& 4(.`P 7%C%! H 129 <?page no="130"?> 130 / UEH#.! A%_%A%%.E? _* <?page no="131"?> / R& 4(.`P 7%C%! H 131 <?page no="132"?> 132 / UEH#.! A%_%A%%.E? _* <?page no="133"?> / R& 4(.`P 7%C%! H 133 die Ergebnisverantwortung. Das heißt, dass es im Verantwortungsbereich des Managers liegt, die richtige fachliche Person zur Implementierung der Gegenmaßnahme dafür einzuspannen, also zu delegieren. Die Rolle des Managers wird innerhalb von PRINCE2 als Risikoeigentümer beschrieben. Risikoeigentümer 1) : Der Risikoeigentümer bringt die beste Voraussetzung für das Management des Risikos mit sich. Oft kennt er sich auch mit dem Eintritt eines Risikos aus, hat jedoch nicht die Skills, die Gegenmaßnahmen einzuführen. Darüber hinaus verfügt der Risikoeigentümer über die Budget- und Delegationsbefugnis für dieses Risiko. <?page no="134"?> 134 / UEH#.! A%_%A%%.E? _* In unserem Beispiel der Olympiade hat sich ein neues Risiko ergeben. Die Wettersituation im Königreich hat sich verschlechtert. Es regnet und stürmt im Grunde genommen dauerhaft. Der dafür anfällige Großfluss Themse stellt nun ein erhöhtes Hochwasserrisiko dar. Falls die Themse über die Ufer tritt, würde das Olympische Dorf überflutet werden. Man muss kein Bauleiter sein, um feststellen zu können, dass eine überflutete Baustelle keine Vorteile mit sich bringt Der Projektmanager ist voll ausgelastet. Er hat keine Zeit, um sich um das Management des Risikos zu kümmern. Er kommt aber auf die großartige Idee, dass seine Oma Elly, eine alte, gut erzogene britische Dame, einen großen Zeitüberschuss am Tag vorweist. Dazu kommt noch, dass die Oma früher eine Elite-Polizistin der Wasserschutzpolizei von London war. Sie kennt sich super mit den Gegebenheiten der Themse aus. Sie weiß, wann der Pegel erreicht ist, bei dem eine Überschwemmung nicht mehr zu vermeiden ist. Kurz gesagt, ist sie die beste Person in London, die sich um das Management dieses Risikos kümmern sollte. Sie bekommt vom Projektmanager die volle Delegationsbefugnis sowie die dafür nötige Budgetverantwortung. Die Rolle, die sich innerhalb der PRINCE2-Terminologie um die Implementierung der Gegenmaßnahme kümmert, ist der Risikobearbeiter. Der Risikobearbeiter 2) : Der Risikobearbeiter bringt die beste Voraussetzung für die Implementierung der Gegenmaßnahme mit. Er trägt die Durchführungsverantwortung und erhält in dem Zusammenhang die Aufträge vom Risikoeigentümer. Es kann durchaus der Fall eintreten, dass Risikoeigentümer und Risikobearbeiter dieselbe Person sind. Vor allem in kleinen Projekten ist das sogar die Regel. Hier wird diese Aufgabe auch oft von dem Projektmanager selbst übernommen. In unserem Beispiel kommt es aber nicht in Frage, dass unsere Oma Elly noch selbst die Implementierung durchführt. Sie ist mit ihren 78 Jahren zwar noch gut „in Schuss“, jedoch kann sie nicht die kg-schweren Sandsäcke tragen, die wir als Gegenmaßnahme implementieren wollen. Hierzu braucht es einen echten Fachmann. <?page no="135"?> / R& 4(.`P 7%C%! H 135 Wer könnte da besser passen als ihr Enkel Harry. Harry steht mitten im Leben und vor allem seit ein paar Wochen mitten im Fitnessstudio. Beste Voraussetzungen, um die Implementierung durchzuführen. Er bekommt von seiner Oma, der Risikoeigentümerin, den Auftrag, die Sandsäcke zu implementieren. Nachdem die Implementierung positiv verlaufen ist, wird ein Vermerk im Risikoregister gemacht und dieses Risiko „abgehakt“. / .7.5 Kategorien der Risikobehandlung Damit die im vorhergegangenen Abschnitt beschriebenen Rollen innerhalb des Risikomanagements auch genügend Auswahl bezüglich der Risikobehandlung zur Verf ügun g ha ben, sind i nn erhalb d er PRINC E2-Met hodik ein e Vielza hl an R isi kobehandlungsmaßnahmen beschrieben. Auch hierbei wird wieder zwischen der negativ wirksamen Bedrohung und der positiv wirksamen Chance differenziert. Für die Bedrohung 1) werden folgende 6 Kategorien vorgeschlagen: Û Akzeptieren 2) : Die wohl einfachste Art und Weise, mit einer Bedrohung innerhalb eines Projekts umzugehen, ist es, die Bedrohung zu akzeptieren und nichts zu machen. Wir erinnern uns hierbei an die im Risikoprofil beschriebene Risikotoleranzgrenze, die sehr früh im Projekt festgelegt wurde. Die Themse, die vor einer Überschwemmung steht, müsste demnach keine großen Folgen auf den Projekterfolg aufweisen, wenn wir diese Bedrohung innerhalb der Risikotoleranzgrenze sehen würden. Û Vermeiden 3) : Die konsequenteste Art und Weise, mit einer Bedrohung umzugehen, ist die Vermeidung. Um das Risiko entweder bei seinem Eintritt oder in seiner Auswirkung vollkommen zu vermeiden, bedarf es entweder horrender Summen im Risikobudget oder der Bereitschaft, das Projekt ganz oder teilweise aufzugeben. <?page no="136"?> 136 / UEH#.! A%_%A%%.E? _* Bei der Olympiade ist anzunehmen, dass man nicht von einem Projektende ausgehen sollte, „nur“ weil Hochwasser die Bauarbeiten blockiert. In dem Moment, wo diese Bedrohung auf das Projekt trifft, ist der bekannte „Point of no Return“ nahezu mit Sicherheit bereits erreicht worden. Somit müssten hohe Summen in die Hand genommen werden, um die Bedrohung Themse wirklich vollumfänglich zu vermeiden. Ein Damm beispielsweise würde helfen, würde aber sicher den budgetären Umfang des Projekts völlig sprengen. Bleibt die Frage, ob denn Vermeiden in diesem Kontext überhaupt die richtige Risikobehandlungsmaßnahme wäre? Die Antwort hierauf wäre sicher: nein. Wenn die Maßnahme den <?page no="137"?> / R& 4(.`P 7%C%! H 137 Projektrahmen derart sprengen würde, würde sich sicher dagegen entschieden und eine der noch folgenden Aktivitäten stattdessen gewählt werden. Û Reduzieren 4) : Reduzieren ist ähnlich wie Vermeiden anzusehen. Entweder wird die Eintrittswahrscheinlichkeit oder die Auswirkung reduziert. Der Unterschied zur Vermeidung ist jedoch, dass bei der Reduzierung die Bedrohung in Höhe von X noch bestehen bleibt, wohingegen das Ziel der Vermeidung ist, die Bedrohung auf 0 zu reduzieren. Eine Möglichkeit der Reduzierung des Hochwassers ist u.a. der Bau eines kleinen Sandsackdamms, der das Wasser in einem kleinen, aber vielleicht entscheidenden Maße zurückhalten kann. Û Teilen 5) : Die Risikobehandlungsmaßnahme „Teilen“ schließt nicht nur den Bedrohungsbereich ein, sondern gilt im Zusammenhang auch für die Chance. Vor allem im Bereich der StartUp-Finanzierung ist „Teilen“ eine beliebte Art und Weise des Risikomanagements. StartUps suchen sich Investoren, die eine Summe X in das neu gegründete Unternehmen investieren und an dessen Erfolg partizipieren werden, also die Chance teilen; werden aber im selben Zusammenhang auch die Bedrohung, dass morgen das Unternehmen pleite sein kann, mit den Gründern teilen. Bei der Olympiade ist das Teilen sicher durch den IOC, also dem Verband von Olympia und der Gastgeberstadt, im hiesigen Beispiel London ebenfalls gegeben. Wird während des Projekts festgestellt, dass das Risiko Themse dermaßen überteuert ist, wird dies auch das IOC betreffen, da es natürlich ebenfalls vom Erfolg der Olympiade partizipieren möchte. Û Übertragen 6) : Die bekannteste und von uns allen betriebene Risikobehandlungsmaßnahme ist die Übertragung. Wir übertragen täglich das Risiko, dass ein Autounfall passiert oder dass hohe Krankheitskosten entstehen. Natürlich übertragen wir hierbei nicht das Risikoereignis an sich, sondern vielmehr die dahin- <?page no="138"?> 138 / UEH#.! A%_%A%%.E? _* terstehende monetäre Belastung. Die Übertragung wird klassischerweise mit einer Versicherung vereinbart. Es gibt aber auch Modelle wie zum Beispiel Factoring oder Miete, wo das Risiko an den Factor oder Vermieter übertragen wird. Bei der Olympiade wird die Versicherung für die Überflutung der Themse sicher eine attraktive Option darstellen. Fraglich bleiben in dem Zusammenhang nur die Höhe der Versicherungsprämie und die Problematik, ob eine Versicherung gegen Hochwasser im Hochwassergebiet überhaupt möglich ist. Û Eventualplan 7) : Der Eventualplan stellt die Plan B-Option innerhalb des Risikomanagements dar; ein Plan, der bereits vor Projektbeginn genauer definiert und beschrieben wurde und nur bei Eintritt des Risikos ausgeführt wird. Sollten die Projektmanager der Olympiade die Themse bereits vor Überflutung in ihrem Risikoregister eingepflegt haben, konnte bestimmt schon über einen Eventualplan gesprochen werden. Zum Beispiel hätte man bereits im Vorhinein große Pumpen kaufen können, die bei Überflutung lediglich eingeschaltet hätten werden müsen. Für die Chance 8) werden folgende vier Kategorien vorgeschlagen: Für das folgende Beispiel ist die Themse nicht mehr zu wählen. Grund hierfür ist die Tatsache, dass in einer Überflutung keine Chance zu erkennen ist. Eine Chance könnte jedoch ein erhöhtes Sonnenaufkommen sein, mit dem in England so gut wie niemand gerechnet hat. Durch das erhöhte Sonnenaufkommen sind die neu erbauten Stadien und Häuser schneller getrocknet und die Bauarbeiten können schneller fortgesetzt werden, was am Ende eine Zeit von gut 14 Tagen bedeuten würde. Û Ergreifen 9) : Die erste und logischste Art und Weise der Behandlung dieser Chance wäre deren Ergreifung. Hierbei nimmt man die gegebene Chance schlichtweg wahr. Man würde erkennen, dass die Bauten schneller trocknen, und daraufhin die Bauarbeiten umplanen, um schneller weitermachen zu können. <?page no="139"?> Û Û Û á á á á á á <?page no="140"?> 140 / UEH#.! A%_%A%%.E? _* á Aktivitätenebenen á Planungsebenen á Nutzenebenen [33] Was ist ein Zweck des Themas „Organisation“? á Die gesamten Ressourcenanforderungen des Projekts zu definieren. á Die Projektabnahmekriterien aufzuzeichnen. á Verantwortlichkeiten für das Managen von Teams zu definieren. á Mechanismen zur Beurteilung einzurichten, ob das Projekt wünschenswert und realisierbar ist. [34] Was ist ein Zweck der Risikomanagementstrategie? á Beschreibt, wie das Risikomanagement unternehmensweit umgesetzt werden wird. á Erfasst und pflegt Informationen über alle identifizierten Risiken eines Projekts. á Dokumentiert bestimmte Maßnahmen für die Behandlung von Risiken. á Beschreibt die Verfahren und Techniken für das Management von Projektrisiken. [35] Was ist KEIN Zweck des Themas „Pläne“? á Kommunikation unterstützen. á Die Verantwortlichkeiten in der Projektorganisation festlegen. á Definieren, wie Produkte geliefert werden. á Sicherstellen, dass Ziele erreicht werden. <?page no="141"?> / R$ QO? _*C,EP*._ \? ` YPG%A.a >E.% 141 [36] Was ist ein Zweck des Prozesses „Lenken eines Projekts“? á Es dem Lenkungsausschuss ermöglichen, seiner Verantwortung für den Projekterfolg nachzukommen. á Eine solide Grundlage für das Projekt schaffen. á Die Voraussetzung für die Initiierung eines Projekts schaffen. á Arbeitspakete zuteilen. [37] Was findet im Prozess „Managen eines Phasenübergangs“ statt? á Regelmäßige Überprüfung des Projektfortschritts anhand des Phasenplans. á Abnahme aller in den aktuellen Phasen hergestellten Produkte. á Eskalieren der in der aktuellen Phase erstellten Offener-Punkte-Berichte. á Überprüfen der geschäftlichen Rechtfertigung des Projekts. [38 ] Was ist KEINE empfohlene Maßnahmenkategorie zur Behandlung einer Bedrohung? á Vermeiden á Ablehnen á Teilen á Übertragen [39] Was ist ein Ziel des Prozess „Managen eines Phasenübergangs“? á Freigabe der nächsten Phase beantragen. á Sicherstellen, dass alle Bedrohungen und Chancen der aktuellen Phase geschlossen worden sind. á Sicherstellen, dass Arbeiten an Produkten, die dem Team für die nächste Phase zugeteilt sind, ordnungsgemäß genehmigt und vereinbart werden. á Maßnahmen ergreifen, um Toleranzabweichungen vom Phasenplan entgegenzuwirken. <?page no="142"?> 142 / UEH#.! A%_%A%%.E? _* [40] In welchem Prozess werden die Risikomanagementtechniken und -standards für das Projekt definiert? á Vorbereiten eines Projekts á Lenken eines Projekts á Initiieren eines Projekts á Managen der Produktlieferung [41] Wann beginnt der Prozess „Lenken eines Projekts“? á Gegen Ende des Prozesses „Vorbereiten eines Projekts“ á Gegen Ende des Prozesses „Initiieren eines Projekts“ á Zu Beginn des Prozesses „Vorbereiten eines Projekts“ á Wenn das Projekt genehmigt worden ist. [42] Welcher Plan ist mindestens erforderlich? á Teamplan á Ausnahmeplan á Projektplan á Programmplan [43] Welches Thema bewertet und steuert Unsicherheiten in einem Projekt? á Fortschritt á Risiken á Änderungen á Pläne <?page no="143"?> / R$ QO? _*C,EP*._ \? ` YPG%A.a >E.% 143 [44] Was wird bei der Erstellung eines Produktstrukturplans NICHT identifiziert? á von internen Ressourcen herzustellende Produkte á zu modifizierte Produkte á für die Herstellung der Produkte benötigten Ressourcen á von externen Dritten herzustellenden Produkte [45] Was beschreibt die Abfolge, in der Produkte eines Plans entwickelt werden sollten? á Produktbeschreibung á Produktstrukturplan á Produktbeschreibung des Projektendprodukts á Produktflussdiagramm <?page no="145"?> 4 Projektablauf Prozess Steuern einer Phase (CS) und Managen der Produkt- 4.1 lieferung (MP) Der Zweck des Prozesses „Steuern einer Phase (CS)“ besteht darin, die anfallenden Arbeiten den richtigen Leuten zuzuweisen, zum richtigen Zeitpunkt das Reporting herzustellen und bei Bedarf Korrekturmaßnahmen einzuleiten, um die Phase innerhalb der vereinbarten Toleranzen zu halten. Û Arbeiten im Rahmen der Phase mit dem Teammanager in Form von Arbeitspaketen beschreiben und freigeben 1) : Der erste Schritt ist, innerhalb einer neuen Projektphase mit dem Teammanager zusammen Arbeitspakete zu entwerfen. Hierbei ist es sehr wichtig, dass Teammanager vorhanden sind, da ein Projektmanager von seinem Skillset in der Regel nicht genügend Wissen vorweisen kann, um die Arbeitspakete adäquat zu beschreiben. Im nächsten Schritt wird dann das Arbeitspaket direkt an den Teammanager bzw. sein Team zur Erarbeitung weiterdelegiert. Hier kommt darauffolgend direkt das Prozess-Managen der Produktlieferung (MP) zur Anwendung: Beim Prozess-Managen der Produktlieferung (MP) wird der Teammanager in die Lage versetzt, den Arbeitsumfang seiner Teammitglieder zu koordinieren und den vereinbarten Reporting-Maßnahmen nachzukommen. Teammanager können sowohl organisationsinterne als auch externe Mitarbeiter sein. <?page no="146"?> 146 - UEH#.! APOaP? , <?page no="147"?> Û Û Û Û Û <?page no="148"?> 148 - UEH#.! APOaP? , leitet werden sollte @ Weiterführung im Prozess SB, oder das Ende des Projekts bevorsteht, woraufhin der Prozess „Abschließen eines Projekts (CP)“ zum Tragen käme. Auch könnte der Fall eintreten, dass der Projektmanager merkt, dass er Korrekturmaßnahmen innerhalb seiner Toleranzbefugnis einleiten sollte. Hierdurch führt es dem PM zum links danebenstehenden Prozessschritt „Korrekturmaßnahmen einleiten“. Die Korrekturmaßnahmen werden geplant und letztlich in Arbeitspaketen an den Teammanager weitergegeben. Daraufhin beginnt der eben beschriebe Zyklus von vorne. Û Übergebene Arbeitspakete im Rahmen der Reporting-Standards überwachen 7) : Der nächste Prozessschritt findet immer dann statt, wenn dem Projektmanager aus dem beschriebenen Arbeitszyklus ein Teamstatusbericht des Teammanagers ausgehändigt wird. Er hilft dem Projektmanager, einen Überblick über den Bearbeitungsstand der verschiedenen Arbeitspakete zu erlangen. Û Den Projektstatus an den Lenkungsausschuss reporten 8) : Im nächsten Prozessschritt muss der Projektmanager über den aktuellen Stand der Phase berichten. Das macht er mit dem bereits bekannten Projektstatusbericht. Dieser wird vom Projektmanager erstellt, mit allen notwendigen Informationen über die aktuelle Phase vervollständigt und dem Lenkungsausschuss reportet. Dieser prüft den Projektstatusbericht dann in seinem Prozess „Lenken eines Projekts“ (DP). Falls alles passt, passiert nichts, außer dass der Projektmanager und sein Team weiter am Erfolg der Phase arbeiten. Sollte dem Lenkungsausschuss etwas in dem Projektstatusbericht auffallen, was ihm nicht gutdünkt, wird er über die Ad-hoc-Anweisungen seinen Willen verlauten, woraufhin der Projektmanager wieder zum Prozessschritt „Korrekturmaßnahmen einleiten“ gelangt, um dem Willen des Lenkungsausschusses zu entsprechen. Û Risiken und Offene Punkte erfassen, managen und ggf. eskalieren 9) : Ein wichtiger Bestandteil, neben dem Abarbeiten des Projektbzw. Phasenplans, ist das <?page no="149"?> ,: 9 6')<5&& +%5$5'- 51-5' 62? &5 (! +; $-= 7? -? 35- =5' 6')=$/ %.1545'$-3 (76; 149 richtige Management der Offenen Punkte (OP) und Risiken. Von Natur aus kann hier keine großartige Planung berücksichtigt werden, da diese in der Regel sehr ad-hoc auftreten und behandelt werden müssen. Im ersten Schritt „Offene Punkte oder Risiken erfassen“ werden die von wem auch immer gemeldeten Themen erfasst, bewertet und geplant. Die Erfassung wird im Register der offenen Punkte oder im Risikoregister ausgeführt. Auch die Bewertung und die geplanten Maßnahmen werden im Register der offenen Punkte oder im Risikoregister niedergeschrieben. Im nächsten Schritt wird die Auswirkung der erfassten OP‘s oder Risiken auf die Phase kontrolliert. Dies geschieht wiederum im bereits beschriebenen Prozessschritt „Phasenstatus prüfen“. Sollten die identifizierten OP´s bzw. Risiken im Folgenden als schwerwiegend eingestuft werden, müssen diese im nächsten Prozessschritt „OP / Risiken eskalieren“ an den LA eskaliert werden. Offene Punkte werden mit einem Offene-Punkte-Bericht an den LA eskaliert, ebenso Risiken mit einem Ausnahmebericht. Schwerwiegend bedeutet in diesem Zusammenhang, dass die OP´s oder Risiken einen Toleranzbereich des Projektmanagers verletzen oder künftig verletzten werden. Der LA hat dann nach Eskalation mehrere Optionen, weiter zu verfahren. Er könnte a) dem Projektmanager über eine Ad-hoc-Entscheidung mitteileilen 10) , dass er entweder einen Ausnahmeplan, also eine genaue Definition der Problematik benötigt, oder einfach mitteilen, dass er keine Bedenken hat und dem Projektmanager damit neue Toleranzen für die Phase übergibt. Sollte der Ausnahmeplan gefordert werden, werden die aktuelle Phase beendet und ein Übergang in das Prozess-Managen eines Phasenübergangs (SB) vorbereitet 11) . Im Prozess SB plant der PM dann die Phase neu und lässt sie seitens des LA wiederum korrigieren. b) Der LA hat die Möglichkeit, auf Grundlage der schwerwiegenden Toleranzüberschreitung das Projekt zu beenden. Mit dieser Entscheidung geht der Projektmanager zum Prozess „Abschließen eines Projekts (CP)“ über und beendet das Projekt vorzeitig 12) . <?page no="150"?> 150 - UEH#.! APOaP? , Abschließend kann man zur Prozesskombination CS/ MP sagen, dass es sich hierbei um die maximale Darstellung des täglichen Projektgeschäfts handelt. Aus Effizienzgründen konnte nur eine Vielzahl an Kombinationen der verschiedenen Aktivitäten dieses umfangreichen Prozesses dargestellt werden. Im Projekt selbst können 100 von Prozessaktivitätsmöglichkeiten vorkommen. Einmal verstanden, fällt einem es jedoch sehr leicht, auffallende Themen innerhalb der von PRINCE2 vorgegebenen Prozessstruktur zu bearbeiten und zu einem erfolgreichen Ergebnis zu führen. Thema Qualität 4.2 Im Thema „Qualität“ geht es darum, anfänglich meist sehr subjektive Kundenqualitätserwartungen in messbare Projektabnahmekriterien umzuwandeln und hierdurch das Projektendprodukt - analog der Anforderungen - zu erstellen. Durch die Bearbeitung dieses Themas geht die Terminologie dem Grundprinzip der Produktorientierung nach. Entgegen dem umgangssprachlichen Gebrauch ist das Wort Qualität bei PRINCE2 als Eigenschaft zu sehen. Dabei steht die Beurteilung, ob gut oder schlecht, nicht in der Kompetenz des Projektmanagers. Vielmehr sollte der Kunde seine Vorstellung von den Eigenschaften mitteilen und deren Umsetzung in die Verantwortung des Projektmanagers geben. -.2.1 Qualitätskontrollpfad Der Qualitätskontrollpfad stellt innerhalb des Themas „Qualität“ das beste von PRINCE2 vorgegebene Schaubild dar, das vom Beginn bis zum Ende des Projekts das Thema „Qualität“ als sich mitentwickelndes Thema beschreibt. <?page no="151"?> -RJ 4(.`P 8? Pa%A6A 151 <?page no="152"?> 152 - UEH#.! APOaP? , Qualitätskontrollpfad Der Qualitätskontrollpfad spiegelt eine Art Lebenszyklus wieder, welcher hilft, den Überblick über die Anforderung zu erlangen. Einen Lebenszyklus deshalb, weil von der ersten Kundenanforderung bis zur Erstellung des Endprodukts, jeder Zwischenschritt aufgezeigt wird. Im Folgenden werden die einzelnen Schritte des Qualitätskontrollpfades genauer erläutert. Hie rbei wird zum einen auf die Begrifflichkeit an sich als auch auf den Zeitpunkt im Projekt, an dem dieser Schritt durchgeführt werden sollte, eingegangen. Auf der linken bzw. rechten Seite sind die Überbergriffe, innerhalb deren man sich bem jeweiligen Schritt befindet, niedergeschrieben. Qualitätsplanung 1) : Im Qualitätskontrollpfad stellt die Qualitätsplanung eines der beiden Kernelemente dar. Innerhalb der Qualitätsplanung werden wiederum verschiedene Granularitätsebenen zur Ermittlung des Verständnisses der vom Kunden gewünschten Qualität durchlaufen. Û Kundenqualitätserwartungen 2) : Im ersten Schritt des Qualitätskontrollpfades werden die ersten Wünsche des Kunden herangezogen und in den Kundenqualitätserwartungen der Projektbeschreibung des Projektendprodukts niedergeschrieben. Die Kundenqualitätserwartungen stellen die erste vom Kunden gewünschte Indikation dar. Wie es in der Praxis üblich ist, sind die ersten Gespräche meist sehr „weich“, also nicht messbar formuliert. Dies geschieht in den meisten Fällen vor dem Projekt im Prozess „Vorbereiten eines Projekts (SU)“. Û Als das IOC die Gespräche mit London zur Durchführung der Olympiade aufgenommen hatte, werden die Olympia-Rechteinhaber mit Sicherheit Vorstellungen wie „Die Olympiade soll umwerfend, großartig oder spektakulär ausfallen“ geäußert haben. Was genau aber versteht man darunter? Wenn man einen Veganer und einen Fleischesser jeweils darum bittet, eine großartige Mahlzeit zu kochen, könnten die Ergebnisse vermutlich unterschiedlicher nicht sein. Was <?page no="153"?> -RJ 4(.`P 8? Pa%A6A 153 somit fehlt, ist die Messbarkeit, die Definition von „großartig“. Dies wird im nächsten Schritt erreicht. Û Projektabnahmekriterien 3) : Hierbei geht es darum, die bereits bekannten Kundenqualitätserwartungen so messbar wie nur irgend möglich zu formulieren. Je messbarer und klarer formuliert wird, desto weniger kann am Ende der Kunde sich über eventuelle Qualitätsmängel beschweren, vorausgesetzt, die Erwartungen sind wie von dem Kunden beschrieben umgesetzt worden. Û „Großartig“ wird dann übersetzt in: Eine Olympiade, die bereits bei ihrer Eröffnungsfeier mit einem 6000-Raketen-Feuerwerk von 150 Meter Höhe aufwartet, überzeugt, dass sie gut wird (auch das kann man noch viel konkreter beschreiben, der Sinn dürfte jedoch klar sein). Û PEP 4) : Hat man nun die Kundenqualitätserwartungen und Projektabnahmekriterien genau definiert, schreibt man diese in der bereits bekannten und ebenfalls im Prozess „Vorbereiten eines Projekts (SU)“ beschriebenen Produktbeschreibung des Projektendprodukts (PEP) inklusiver weiterer Inhalte nieder. Hat man nun eine erste Ausprägung der Qualitätswünsche des Kunden, kann das Projekt im nächsten Schritt darangehen, sich eine „Antwort des Projekts“ zu überlegen. Der erste Schritt wäre hierbei die Erstellung einer Qualitätsmanagementstrategie. Û Qualitätsmanagementstrategie 5) : Eine Strategie, welche die zu verwendeten Qualitätsstandards, Qualitätstechniken und Qualitätsverantwortlichkeiten festlegt, um das geforderte Qualitätsniveau zu erreichen. Auf Basis der Qualitätsstrategie werden im nächsten Schritt die Produktbeschreibungen für die erste Phase des Projekts geplant. Diese Planung wird vom Projektmanager durchgeführt. Û Produktbeschreibungen 6) : Produktbeschreibungen sind in ihrer strukturellen Ausprägung im Grunde genommen analog der Produktbeschreibung des Pro- <?page no="154"?> 154 - UEH#.! APOaP? , jektendprodukts. Sie beschreiben für sich ein Produkt. Einziger Unterschied ist hierbei die „Flughöhe“ der Beschreibung. Die Produktbeschreibungen fallen hierbei deutlich detaillierter aus, als es die PEP macht. Alle Produktbeschreibungen zusammengenommen würden die PEP nur auf einer sehr granularen Ebene ergeben. Innerhalb der Produktbeschreibungen sind die für das Produkt benötigten Qualitätskriterien 7) , also zum Beispiel die Lautstärke des Eröffnungsfeuerwerkes, sowie die dafür vorgesehenen Qualitätstoleranzen 8) enthalten. Die Qualitätstoleranz könnte hier 10-15 dB bedeuten. Ebenfalls sind die Qualitätsprüfungsmethode 9) , also die Art und Weise, wie die Qualität am Ende geprüft wir d, und d ie Qua lit ätsv eran twort lichk eite n 10) , also wer für die Qualitätsentwicklung und Überprüfung am Ende zuständig ist, enthalten. Die Qualitätsprüfungsmethode könnte zum Beispiel ein Testfeuerwerk 48 Stunden vor Beginn der Eröffnungsfeier sein. Die Qualitätsverantwortlichkeiten könnten Herr Firefighter Smith vom Firefighter Headquarter London und der Projektmanager sein. Bis hier ging es um die Planung und Definition der vom Projekt zu entwickelnden Produkte. Im Folgenden wird nun die Qualitätssteuerung genauer beschrieben. Û Qualitätssteuerung 11) : Die Qualitätssteuerung bildet innerhalb des Qualitätskontrollpfades den zweiten großen Baustein ab. Hierbei handelt es sich um die praktische Umsetzung, die Kontrolle und die Abnahme der geforderten Produkte und deren Qualität. Diese in der Qualitätsplanung ermittelte Fülle an Informationen werden im bereits bekannten und schon oft beschrieben Qualitätsregister 12) niedergeschrieben. Das Qualitätsregister wird ständig aktualisiert, da sich ständig auch alle Produkte des Projekts anpassen und verändern. Aus dem Qualitätsregister heraus wird dann das Spezialistenprodukt 13) auf Basis der im Qualitätsregister beschriebenen Produkteigenschaften entwickelt. <?page no="155"?> -RJ 4(.`P 8? Pa%A6A 155 Sollte die Qualität ausreichend sein, wird auch hier wieder ein Vermerk im Qualitätsregister gemacht, wodurch die Qualitäts- und Produktabnahmedokumentation 14) als erfolgreich erklärt wird. Hierbei geht es tatsächlich um die Prüfung der vorvergangenen Eigenschaften auf Basis der in der Produktbeschreibung genannten Qualitätsanforderungen und Prüfungsmethoden. Die Abfolge von „Produktbeschreibungen“ bis hin zur „Qualitäts- und Produktabnahmedokumentation“ wiederholt sich im Grunde genommen so oft, bis das letzte Produkt final abgenommen wurde und eine finale Projektabnahmedokumentation 15) mit der Übergabe des Projektendprodukts durchgeführt wurde. -.2.2 Qualitätsprüfungstechnik Nachdem wir uns in Abschnitt 4.2.1 mit der Fragestellung „Wie wird Qualität geplant und gesteuert? “ beschäftigt haben, wenden wir uns hier der Frage zu, wie die Qualität abgenommen wird. Die Qualitätsprüfung ist nach einer langen Projektzeit bzw. Produktentwicklungszeit der Moment der Wahrheit, da hier das entwickelte Produkt erstmals den Stakeholdern vorgelegt wird. PRINCE2 gibt hier eine so genannte „Qualitätsprüfungstechnik“ vor, auf deren Basis dann innerhalb der Projekte die Abnahme der entwickelten und erstellten Produkte vonstattengeht. Die an der Prüfung teilnehmenden Personen bekommen Rollen mit klar definierten Verantwortlichkeiten zugeteilt. Das Ziel ist, festzustellen, ob das Spezialistenprodukt für den gewünschten Zweck geeignet ist, es die nötigen Standards einhält und den in der Produktbeschreibung niedergeschriebenen Anforderungen genügt. Im oberen Teil des nachstehenden Schaubildes wird die Qualitätsprüfungstechnik als Prozess aufgeführt. Diese Prozessschritte werden zur Vorbereitung, Durchführung und Nachbereitung der dafür stattfindenden Qualitätsprüfungssitzung durchlaufen: <?page no="156"?> 156 - UEH#.! APOaP? , <?page no="157"?> -RJ 4(.`P 8? Pa%A6A 157 Û Prüfungsvorbereitung 1) Û Prüfungssitzung 2) Û Prüfungsnachbereitung 3) Die Prüfungsvorbereitung dient dem Verantwortlichen, alle notwendigen Vorbereitungen zu treffen, damit die eigentliche Qualitätsprüfungssitzung durchgeführt werden kann. Gemäß der PRINCE2-Terminologie werden hier Produktproben, Kopien, Bilder oder Präsentationen (je nachdem, um welche Art von Produkt es sich hierbei handelt) verschickt, damit sich der Prüferkreis auf die Sitzung vorbereiten kann. Die Prüfungssitzung ist der tatsächliche Moment, wo alle Qualitätsverantwortlichkeiten zusammentreffen und über das erstellte Spezialistenprodukt sprechen. Ziel dieser Sitzung ist, das Produkt entgegen zu nehmen und damit die Ersteller zu entlasten. Sollten während der Prüfungssitzung noch Verbesserungsvorschläge aufkommen, die die Abnahme des Produkts behindern, wird die finale Abnahme verschoben. Die Entwickler haben daraufhin nochmal die Möglichkeit, Anpassungen durchzuführen. In diesem Fall tritt der im Schaubild gezeigte Pfeil in Kraft, der eine erneute Vorbereitung für die Zweitprüfung anzeigt. Die Prüfungsnachbereitung findet nach erfolgreicher oder nicht erfolgreicher Prüfungssitzung statt. Beide Szenarien bringen Nachbearbeitungsbedarf mit sich. Das Ergebnis der Qualitätsprüfung muss dem dafür vorgesehenen Kreis kommuniziert werden, die Dokumente müssen gepflegt werden, ein Protokoll muss verschickt werden. Die Prüfungsnachbereitung bezieht sich hierbei vor allem auf die administrativen Themen. Im unteren Teil des Schaubildes sind die dafür notwendigen Rollen aufgeführt. Û Vorsitzender 4) Û Prüfer 5) <?page no="158"?> 158 - UEH#.! APOaP? , Û Admin 6) Û Präsentator 7) Prüfungsvorsitzender Die Rolle, die für den Ablauf der Qualitätsprüfung verantwortlich ist. Prüfer Der Prüfer übernimmt die tatsächliche Produktüberprüfung, reicht im Vorhinein Fragen ein, die bei der Prüfungsvorbereitung bei der Untersuchung des eingereichten Produkts entstanden, und bestätigt, dass die geforderte Qualität erreicht wurde. Prüfungsadministrator Er unterstützt den Prüfer in administrativen Belangen und protokolliert die Prüfung, die Ergebnisse und eventuelle Nachbesserungsmaßnamen. Produktpräsentator Der Präsentat or stellt das Produkt für die Prüfung vor und vertritt bei Bedarf den Ersteller des Produkts. Ferner übernimmt der Präsentator die im Anschluss an die Prüfung anfallende Koordination der Arbeiten, falls Änderungen anstehen oder Fehler ausgebessert werden sollen. 4.3 Thema Änderungen Zweck des Themas „Änderungen“ ist die Identifikation, Bewertung und Steuerung potenzieller und genehmigter Änderungen* @n PRINCE2 9? 4B als „Offener Punkt“ 7#6966A+ : 66#! B9; 7 3#CC#6 ? 6A#! C4B#@3#A 896 &<@C4B#6 '79C#; @6#', ? 63 '6@4BA, 79C#; @6#',%""#6#6 -? 6=A#6. <?page no="159"?> -R/ 4(.`P Z_I.E? _*._ 159 <?page no="160"?> 160 - UEH#.! APOaP? , Baseline: Die Baseline bildet die festgeschriebene Ausgangskonfiguration eines Produkts. Ist etwas „gebaselined“, bringt das zum Ausdruck, dass zur Änderung dieses Produkts der Änderungssteuerungsprozess angewendet werden muss. Änderungssteuerungsprozess: Veränderungen sind während eines Projekts unvermeidlich. Daher benötigt jedes Projekt einen prozessualen Ansatz für die Identifikation, Bewertung und Steuerung Offener Punkte. Das Ziel ist dabei nicht die Verhinderung Offener Punkte, sondern vielmehr, dass jeder Offene Punkt der zuständigen Instanz vorgelegt wird, um diese in die Lage zu versetzen, über die Offenen Punkte zu entscheiden. Damit die Steuerung der Offenen Punkte richtig vonstattengeht, bedarf es über der Änderungssteuerung eines schützenden Dachs, das im unten aufgeführten Schaubild metaphorisch dargestellt wird. In PRINCE2 ist dieses „Dach“ als Konfigurationsmanagementstrategie 1) beschrieben. Konfigurationsmanagement klingt im ersten Moment komplizierter, als es tatsächlich ist. In einem anderen, besserbeschreibenden Wort könnte man auch „Änderungsstrategie“ dazu sagen, um es verständlicher zu machen. Die Konfigurationsmanagementstrategie Die Konfigurationsmanagementstrategie bildet das schützende Dach, unter dem die Steuerung der Offenen Punkte steht. Sie beschreibt, wie und von wem die Produkte eines Projekts gesteuert und geschützt werden. Wird ein Offener Punkt gemeldet, wird im ersten Schritt überprüft, ob dieser tatsächlich den in der Konfigurationsmanagementstrategie beschriebenen Rahmenbedingungen entspricht. Nur durch ein professionelles Konfigurationsmanagement kann somit sichergestellt werden, dass Produkte nicht unkontrolliert verändert werden. Innerhalb der von PRINCE2 beschriebenen „Offenen Punkte“ 2) unterscheidet man zwischen „Spezifikationsabweichung“ 3) , „Änderungsantrag“ 4) und „Problem/ Anliegen“ 5) . <?page no="161"?> -R/ 4(.`P Z_I.E? _*._ 161 Spezifikationsabweichung: Eine im Rahmen des Projekts zu erfüllende Produktanforderung, die derzeit nicht bzw. voraussichtlich nicht erfüllt wird. Hierbei kann es sich um ein fehlendes Produkt oder ein Produkt, das die Spezifikation nicht einhalten kann, handeln. Es ist zu beachten, dass es sich hierbei um einen offenen Punkt handelt, dem nachgekommen werden muss, da ansonsten der Projekterfolg gefährdet ist. Änderungsantrag: Ein Vorschlag zur Änderung einer „gebaselineden Produkteigenschaft“. Der Änderungsantrag kann von jedem Mitarbeiter der Projektorganisation gestellt werden. In PRINCE2 wird als Verantwortlichkeit, die für die Genehmigung oder Ablehnung der gestellten Änderungsanträge zuständig ist, der Lenkungsausschuss genannt. Zu beachten ist hierbei, dass bei einem erhöhten Aufkommen an Änderungsanträgen der Lenkungsausschuss auch eine weitere Instanz zur Entscheidung über die Änderungsanträge bestellen kann: den Änderungsausschuss. Der Projektmanager selber hat keine Befugnis, Änderungsanträge zu genehmigen oder abzulehnen. Änderungsausschuss: Dieser besitzt die Kompetenz, über Änderungen zu entscheiden. Der Änderungsausschuss ist nicht zwingend - wie der Name vermuten lässt - ein Komitee, sondern besteht vielmehr aus einzelnen Personen innerhalb des Projektteams, die in unterschiedlichen Bereichen unterschiedliche Arten von Änderungskompetenz seitens des Lenkungsausschusses delegiert bekommen haben. Es ist nicht die Aufgabe des Änderungsausschusses, die Auswirkungen der Änderungsanträge zu analysieren oder deren Umsetzung zu betreuen. Dies liegt jeweils im Kompetenzbereich der fachlichen Teammanager bzw. des Projektmanagers. Problem/ Anliegen: Hierbei handelt es sich um einen sonstigen offenen Punkt, dessen Lösung oder Eskalation Aufgabe des Projektmanagers ist. Hierzu zählen zum Beispiel Krankmeldungen oder Verbesserungsvorschläge. Ein Problem/ Anliegen hat keine Auswirkung auf die Baseline der Produktanforderungen. <?page no="162"?> Û 162 - UEH#.! APOaP? , <?page no="163"?> -R/ 4(.`P Z_I.E? _*._ 163 cher Ebene „gebaselined“ wird, wird in der Konfigurationsmanagementstrategie festgehalten. Û Identifizieren 7) : Im nächsten Schritt werden dann die einzelnen Konfigurationselemente identifiziert. Hat man sich für die unterste Ebene, die der Nägel, festgelegt, wird im Folgenden jeder einzelne Nagel genauestens erfasst. Û Steuern 8) : Sind alle Konfigurationselemente erfasst, liegt es nun am Lenkungsausschuss bzw. dem bestehenden Änderungsausschuss, diese so zu steuern, dass keine unbefugten Änderungen an den Konfigurationselementen vorgenommen werden können. Dies macht der Änderungsausschuss durch die Überprüfung und Entscheidung von Änderungsanträgen. Û Status 9) : Der Status ist eine Möglichkeit, sich über den aktuellen Stand der Konfigurationselemente zu erkundigen. Dieser Stand kann über die „Produktstatusauskunft“ abgefragt werden. Die „Produktstatusauskunft“, stellt innerhalb von PRINCE2 ein Managementprodukt dar, durch das interessierte Stakeholder einen Zwischenstand der Erarbeitung abrufen können. Û Audit/ Überprüfung 10) : Der letzte Schritt innerhalb des Prozesses des Konfigurationsmanagements ist eine Auditierung bzw. Überprüfung der vier vorhergegangenen Schritte. <?page no="164"?> Übungsfragen zum Kapitel Vier - Projektablauf 4.4 Hinweis: Es kann nur eine Antwort richtig sein. Die Auflösung findest Du in Kapitel 8. [46] Wer ist dafür verantwortlich, im Prozess „Managen der Produktlieferung“ einen Teamplan zu erstellen? á Projektmanager á Teammanager á Projektunterstützung á Benutzervertreter [47] Ergänze den folgenden Satz: Wenn der Projektmanager sich über die Ergebnisse einer Qualitätsprüfung informieren will, findet er im (? ) sowohl eine Zusammenfassung als auch den Termin einer eventuellen Folgesitzung. á Phasenplan á Register offener Punkte á Projekttagebuch á Qualitätsregister [48] Welche Rolle vereinbart mit dem Projektmanager die Techniken, Produkte und Einschränkungen für die Lieferung eines Arbeitspakets? á Auftraggeber á Projektsicherung á Lieferantenvertreter á Teammanager 162 - UEH#.! APOaP? , <?page no="165"?> -R- QO? _*C,EP*._ \? ` YPG%A.a 2%.E 165 [49] Was ist ein Typ eines Offenen Punkts? á Problem/ Anliegen á Empfehlungen für Folgeaktionen á Ausnahmebericht á identifizierte Bedrohung [50] Was ist ein Ziel der Qualitätsprüfungstechnik? á Feststellen, ob ein Produkt hergestellt worden ist. á Methoden für die Qualitätsprüfung eines Produkts vereinbaren. á Ideen vorbringen, wie das Produkt entwickelt werden sollte. á Verschiedene interessierte Parteien in die Beurteilung einbeziehen, ob ein Produkt für einen bestimmten Zweck geeignet ist. [51] Was wird aus einem Änderungsbudget finanziert? á Eventualplan á Änderungsantrag á Maßnahmen zur Reduzierung einer Bedrohung á Änderungsausschuss [52] Welcher der folgenden Optionen sind ein Zweck eines Offener-Punkt- Berichts? á Managen der Produktlieferung á Initiieren eines Projekts á Lenken eines Projekts á Vorbereiten eines Projekts <?page no="166"?> 166 - UEH#.! APOaP? , [53] Welche der folgenden Optionen sind ein Zweck eines Offener-Punkt- Berichts? 1. Dokumentation einer Spezifikationsabweichung 2. Aufzeichnung der Erledigung eines offenen Punkts 3. Erfassung aller in einem Projekt vorgebrachten Probleme und Anliegen 4. Erfassung von Empfehlungen für einen Änderungsantrag á 1, 2, 3 á 1, 2, 4 á 1, 3, 4 á 2, 3, 4 [54] Welches Produkt definiert die Vergleichsgrundlage, aufgrund der die eigentliche Leistung des Projekts beurteilt wird? á Projektbeschreibung á Produktstatusauskunft á Projektleitdokumentation á Konfigurationsdatensatz [55] Was ist Zweck des Prozesses „Steuern einer Phase“? á Projektarbeit vereinbaren, ausführen und abliefern. á Den nächsten Phasenplan entwerfen. á Phasentoleranzen vereinbaren. á Maßnahmen ergreifen, damit die Phase weiterhin innerhalb der Toleranzen bleibt. <?page no="167"?> -R- QO? _*C,EP*._ \? ` YPG%A.a 2%.E 167 [56] Wie sollte ein Teammanager den Projektmanager davon in Kenntnis setzten, dass ein Arbeitspaket voraussichtlich seine Toleranzen überschreiten wird? á Einen Ausnahmebericht erstellen. á Einen Ausnahmeplan erstellen. á Einen Offenen Punkt melden. á Ein Risiko melden. [57] Welches ist eine der empfohlenen Rollen in einer Qualitätsprüfung? á Projektmanager á Prüfungsadministrator á Projektunterstützung á Ersteller [58] In welcher Situation würde der Prozess „Steuern einer Phase“ zum Einsatz kommen? á Managen einer langen Initiierungsphase eines komplexen Projekts. á Managen der Aktivitäten eines komplexen Programms á Managen der Unterstützungsaktivitäten nach der Übergabe von Produkten an die Betriebsumgebung. á Erstellen eines Ausnahmeplans, der den aktuellen Phasenplan ersetzt. [59] Was ist eine Verantwortlichkeit des Vertreters der Unternehmensinteressen im Lenkungssauschuss? á Festlegen der Toleranzen für das Projekt. <?page no="168"?> 168 - UEH#.! APOaP? , á Sicherstellen, dass das Projekt ein gutes Preis-Leiostungsverhältnis darstellt. á Bestätigen, dass das Projekt die geforderte Funktionalität liefert. á Prüfen, ob die Produkte des Projekts die Qualitätsanforderungen erfüllen. [60] Welche der folgenden Aussagen beschreibt zutreffend die Bezeichnung zwischen der Projektsicherung und der Qualitätssicherung? á Die Projektsicherung kümmert sich um die Interessen der Stakeholder im Rahmen des Projekts, die Qualitätssicherung um die Interessen der Unternehmensbzw. der Programmorganisation im allgemeinen. á Beide sind Verantwortlichkeiten des Lenkungsausschusses, allerdings kann die Projektsicherung delegiert werden. á Beide sind unabhängig vom Projekt. á Die Projektsicherung und Qualitätssicherung sind beide Verantwortlichkeiten des Unternehmens- oder Programmmanagements. <?page no="169"?> 5 Projektabschluss Prozess Abschließen eines Projekts (CP) 5.1 Zweck des Prozesses „Abschließen eines Projekts - Closing a Project (CP)“ ist die Definition des Punktes, an dem die Abnahme des Projektendprodukts bestätigt wird, die in der ursprünglichen Projektleitdokumentation definierten Ziele oder auch genehmigte Änderungen dieser Ziele erreicht worden sind oder mit dem Projekt keine weiteren Ergebnisse erzielt werden können. In diesem Zusammenhang wird klar, dass es für den Prozess „Abschließen eines Projekts (CP)“ zwei Inputs geben kann: Zum einen den Planmäßigen Abschluss 1) , der bei einem planmäßigen Projektabschluss zu Tragen kommt. Zum anderen den Vorzeitigen Abschluss 2) , der bei einem vorzeitigen Projektabbruch zum Zuge kommt. Beide Arten beginnen mit der Aktivität, den Projektabschluss vorzubereiten. Je nachdem welcher Projektabschluss angestrebt wird, unterscheidet man hier zwischen: Û Planmäßigen Abschluss vorbereiten 3) : Der Planmäßige Abschluss eines Projekts steht naturgemäß schon eine lange Zeit fest. Fraglich ist aber immer, ob der genaue Abschlusstermin eingehalten werden kann. Mit diesem Prozessschritt ist mit dem Wort „planmäßig“ vor allem aber auch die Finalisierung gemeint, also das gewünschte Produkt fertig dem Auftraggeber zu übergeben. Genau diese Übergabe gilt es in diesem ersten Prozessschritt innerhalb des Prozesses „Abschließen eines Projekts (CP)“ vorzubereiten. Der Lenkungsausschuss <?page no="170"?> 170 + UEH#.! APOCL(a? CC und die Linienorganisation müssen über den Projektabschluss informiert werden, es müssen Meetings und Räume dafür organisiert werden etc. Im Grunde gleicht dieser Prozessschritt einer organisatorischen Vorplanung der eigentlichen Produktübergabe. Û Vorzeitigen Abschluss vorbereiten 4) : Der Vorzeitige Abschluss bringt durch sein oft ungeplantes Auftreten einen deutlich höheren administrativen Aufwand mit sich. Die Aktivitäten sind hier gleich dem Prozess „Planmäßigen Abschluss vorbereiten“, wenngleich sie auch deutlich umfangreicher ausfallen, da ein ungeplanter Projektabschluss einen deutlich höheren Abstimmungsaufwand mit sich bringt. In den folgenden Prozessschritten ist es vollkommen unerheblich, ob wir den Prozess „Abschließen eines Projekts (CP)“ durch einen Planmäßigen oder einen Vorzeitigen Abschluss durchlaufen. Die einzelnen Schritte müssen absolviert werden, wenn auch mit vollkommen unterschiedlicher Intensität. Û Produkte übergeben 5) : Dieser Prozessschritt beschreibt die tatsächliche Entgegenahme des Projektendprodukts durch die Auftraggeber und Benutzer. Hierfür sieht die PRINCE2-Terminologie ein Übergabemeeting vor, das seitens der Projektunterstützung (PMO) organisiert werden sollte, damit einer Produktübergabe nichts mehr im Wege steht. Ferner wird in diesem Prozessschritt auch der bereits beschriebene Nutzenrevisionsplan dem Auftraggeber und dem Benutzer übergeben. Da sich das Projekt in naher Zukunft auflösen wird, muss nun das Unternehmen die Revision und Berichtserstattung des Nutzens innerhalb des Nutzenrevisionsplans übernehmen. Û Projekt bewerten 6) : Der vorletzte Prozessschritt beschreibt ein Meeting zum gemeinsamen Erfahrungsaustausch der gesamten Projektorganisation im Kontext des Projekts. Mit dieser Tätigkeit kommen wir dem in PRINCE2 beschriebenen Grundprinzip „Lernen aus Erfahrung“ nach. In der Praxis ist dieser Prozess- <?page no="171"?> +RN UEH\.CC DOCL(a%.K._ .%_.C UEH#.! AC ^@UT 171 schritt auch bekannt als „Lessons Learned“, ebenfalls ein Erfahrungsaustausch innerhalb des Projektteams. Hierbei wird noch ein weiteres Managementprodukt, „der Erfahrungsbericht“, als Protokoll der Projektbewertung erstellt und dem Unternehmen übergeben. Û Projektabschluss empfehlen 7) : Im letzten Prozessschritt erstellt der Projektmanager den letzten Bericht und somit auch das letzte Managementprodukt innerhalb des Projekts. Der Projektabschlussbericht beinhaltet eine gute Aufarbeitung des Projekts mit Erfolgen und Misserfolgen, budgetären und zeitlichen Abschlussberichten. Auf Grundlage des Projektabschlussberichts empfiehlt der Projektmanager dem Lenkungsausschuss, das Projekt zu beenden, woraufhin der Projektmanager entlastet wird und der Lenkungsausschuss das Projekt beendet. <?page no="172"?> 172 - UEH#.! APOaP? , <?page no="173"?> +RJ QO? _*C,EP*._ \? ` YPG%A.a : '_, 173 Übungsfragen zu Kapitel Fünf - Projektabschluss 5.2 Hinweis: Es kann nur eine Antwort richtig sein. Die Auflösung findest Du in Kapitel 8. [61] Wie wird die Projektleitdokumentation im Prozess „Abschließen eines Projekts“ verwendet? á Als Grundlage, anhand der die ursprünglichen Absichten des Projekts mit den tatsächlich erreichten Zielen verglichen werden. á Liefert die Steuerungsmittel für die letzte Phase des Projekts. á Wird aktualisiert, um nützliche Erfahrungen aus Vorgängerprojekten aufzunehmen. á Liefert die vom Lenkungsausschuss zu genehmigenden Produktbeschreibung des Projektendprodukts. [62] Was ist ein Zweck der Produktbeschreibung des Projektendprodukts? á Definiert die Berichtsstruktur für das Projekt. á Enthält Information über den Zweck und das Management des Projekts. á Definiert, was das Projekt im Endeffekt liefern muss, um vom Kunden abgenommen zu werden. á Liefert Input für die Erstellung des Projektmandats. [63] Wann wird bestätigt, ob die Ziele eines Projekts erreicht worden sind? á während des Prozesses „Abschließen eines Projekts“ á in der letzten Phasenabschlussbewertung á während des Prozesses „Steuern einer Phase“ á im Prozess „Managen der Produktlieferung“ <?page no="174"?> 174 - UEH#.! APOCL(a? CC [64] Was ist ein Ziel des Prozesses „Abschließen eines Projekts“? á Prüfen, ob alle Produkte des Projekts von den Benutzern abgenommen worden sind á Die letzte Projektphase vorbereiten á Qualitätserwartungen des Kunden erfassen á Gewährleistet, dass der Nutzen in vollem Umfang erzielt worden ist [65] Was ist ein Zweck des Prozesses „Abschließen eines Projekts“? á Die Verfahren für die Übergabe von Produkten festlegen. á Ist der Punkt in einem Projekt, an dem die Abnahme des Projektendprodukts bestätigt wird. á Die formalen Anforderungen an die Abnahme, Ausführung und Lieferung der Projektarbeiten definieren. á Bestätigen, dass der mit dem Projekt angestrebte Nutzen in vollem Umfang erzielt wurde. [66] Was ist KEIN Zweck eines Projektabschlussberichts? á Die Projektleistung mit den ursprünglichen Zielvorgaben zu vergleichen. á Informationen, die für andere Projekte nützlich sein können, aufzuzeichnen. á Dem Lenkungsausschuss als Auslöser für die Genehmigung der nächsten Phase zu dienen. á Informationen zu weiterhin bestehenden Risiken an diejenigen weiterzuleiten, die das fertige Produkt warten oder betreiben werden. <?page no="175"?> 6 Prüfung und Zertifizierung Wie kann man zertifiziert werden? 6.1 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 BigFour 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. Die Prüfung kann somit direkt über unseren Homepagelink www.bigfour.de/ Prince2/ Pruefungen erworben werden. Hier hat man die Auswahl einer papierbasierten Prüfung vor Ort bei einem unserer Präsenztrainings oder einer zeitlich und örtlich unabhängigen Online- Prüfung. Welche Prüfungen gibt es? 6.2 Innerhalb von PRINCE2 gibt es drei verschiedene Zertifizierungslevel. [1] Foundation [2] Practitioner [3] Professional <?page no="176"?> 176 ) UE',? _* ? _I 0.EA%,%\%.E? _* <?page no="177"?> )RJ 1.aL(. UE',? _*._ *%OA .CF 177 <?page no="179"?> 7 Glossar Abhängigkeiten(Plan) Beziehungen zwischen Aktivitäten oder Produkten, die Inhalt eines Plans sind. Man unterscheidet externe und interne Abhängigkeiten. Letztere können vom Projektmanager kontrolliert werden, erstere nicht. Ablehnen (Risikobehandlung) Form der Behandlung einer Chance, bei der aus z.B. wirtschaftlichen Gründen die Chance nicht ergriffen und keine Maßnahme zur Risikobehandlung getroffen wird. Abnahmeberechtigter (Produkt) Die Instanz (z.B. Lenkungsausschuss), die über die Kompetenzen verfügt, ein Produkt als vollständig und für den entsprechenden Zweck geeignet abzunehmen. Agile Methoden Methoden für flexible Softwareentwicklung, die Iterationen mit kurzem Zeitrahmen präferieren, in denen die Produkte schrittweise erstellt werden. Prinzipiell ist PRINCE2 hiermit kompatibel. Aktivität Definierter Bestandteil von Plänen oder Prozessen, der einen konkreten Zeitrahmen aufweist, klare Ergebnisse bringt und gemanagt werden muss. Stellt sich als Funktion, Aufgabe oder (Teil-)Prozess dar. <?page no="180"?> 180 ]aHCCPE Akzeptieren (Risikobehandlung) Form der Behandlung einer Bedrohung, bei der die Verbindung aus Auswirkung und Eintrittswahrscheinlichkeit des Risikos als zu gering eingestuft wird, um entsprechende Reaktionsmaßnahmen zu rechtfertigen. Die Bedrohung wird jedoch weiterhin beobachtet. Änderungsantrag Ein Offener Punkt, der den Vorschlag zur Änderung einer Baseline enthält. Änderungsausschuss Eine Instanz, die vom Lenkungsausschuss die Verantwortung delegiert bekommen kann, Änderungsanträge oder Spezifikationsabweichungen zu bearbeiten. Die Zuteilung eines sog. Änderungsbudgets ist möglich. Änderungsbudget Die Mittel, die dem Änderungsausschuss zur Ausübung seiner Verpflichtungen zur Verfügung gestellt werden. Änderungssteuerung Verfahren zur Erfassung und Bearbeitung aller Änderungen mit Auswirkung auf die Projektziele. Ankündigung der Projektfreigabe Mitteilung des Lenkungsausschusses an alle Stakeholder und Projektbeteiligten, dass das Projekt offiziell freigegeben wurde und die für das Projekt notwendige logistische Unterstützung (z.B. zur Kommunikation) angefordert wird. Ankündigung der Projektinitiierung Mitteilung des Lenkungsausschusses an alle Stakeholder und Projektbeteiligten, <?page no="181"?> ]aHCCPE 181 dass das Projekt als lohnenswert eingestuft wurde und nun der Prozess „Initiierung eines Projekts“ beginnt. Ankündigung des Projektabschlusses Information des Lenkungsausschusses über die Beendigung des Projekts verbunden mit der Auflösung der Projektressourcen und -kommunikationswege. Weiterhin werden auch formale Hinweise gegeben, z.B. bis wann Kosten gegen die Projektkostenstelle gebucht werden können. Annahme Vorläufige Planungsgrundlage, die aufgrund von Faktenmangel zum Erstellungszeitpunkt getroffen wird. Sie kann später noch verändert werden, wenn detailliertere Informationen vorliegen. Anpassung Jeweilige Verwendung der PRINCE2-Methodik in der vorliegenden Projektsituation. PRINCE2 ist hier als flexibles Framework zu verstehen, welches an die tatsächlich vorliegenden Projektbedingungen angepasst werden musst. Arbeitspaket Umfasst die für die Erstellung eines Produkts notwendigen Informationen wie die Beschreibung der zu erledigenden Arbeiten oder die Produktbeschreibungen. Ein Arbeitspaket wird zwischen Projekt- und Teammanager als Arbeitsgrundlage definiert. Auftraggeber Vorsitzender des Lenkungsausschusses, der für den Erfolg des Projekts, die Verteilung der Vollmachten, die korrekte Beachtung der Projektrisiken als auch für den Business Case verantwortlich ist. <?page no="182"?> 182 ]aHCCPE Aufzeichnungen Fortlaufende Managementprodukte, die den Projektfortschritt dokumentieren. Auslöser Eine Entscheidung oder ein Ereignis, der ein PRINCE2-Projekt auslöst. Ausnahme Situation, in der eine Abweichung von gegebenen Projekttoleranzen eingetreten ist bzw. antizipiert werden kann. Ausnahmebericht Ein vom Projektmanager erstellter Bericht an den Lenkungsausschuss, der eine Ausnahme inklusive deren Auswirkungen und bestehendenBehandlungsmöglichkeiten untersucht. Eine Empfehlung des Projektmanagers ist ebenfalls enthalten. Ausnahmebewertung Beurteilung des Lenkungsausschusses, ob ein Ausnahmeplan akzeptiert oder abgelehnt werden soll. Auswirkung (eines Risikos) Das (erwartete) Resultat des Eintritts eines Risikos. Baseline-Managementprodukt Managementprodukt, das gewissen Stand des Projekts als Ausgangsbasis definiert und nach Bestätigung dem Änderungsausschuss unterliegt. Befugnis Entscheidungskompetenz, um beispielsweise Ressourcen zu verteilen. <?page no="183"?> ]aHCCPE 183 Benutzer Person oder Gruppe, die mit dem Projektendprodukt nach Projektabschluss arbeiten und durch einen Repräsentanten (Benutzervertreter) im Lenkungsausschuss vertreten wird. Benutzerabnahme Form der Übergabe des Produkts an die späteren Benutzer. Benutzervertreter Siehe „Benutzer“ Berichte Managementprodukte, die den gegenwärtigen Status des Projekts dokumentieren. Betriebs- und Wartungsabnahme Übergabe des Produkts an die späteren Unterstützer in der betrieblichen Verwendung des Produkts. Business Case Geschäftliche Rechtfertigung für ein Projekt. Umfasst Gründe, Optionen, Risiken, Zeit, Kosten, erwarteten Nutzen, erwartete negative Nebeneffekte als auch eine Investitionsrechnung des Projekts. Einschränkungen Restriktionen, die für das Projekt herrschen. Eintrittsnähe (Risiko) Der zeitliche Bezug eines Risikos. Neben Auswirkung, Eintrittswahrscheinlichkeit und Relevanz ein wichtiger Faktor zur Risikobewertung. <?page no="184"?> 184 ]aHCCPE Eintrittswahrscheinlichkeit Die bewertete Häufigkeit mit der ein bestehendes Risiko tatsächlich eintreten wird. Empfehlung des Projektabschlusses Information vom Projektmanager an den Lenkungsausschuss. Dieser befindet nun, ob er dem Projektabschluss zustimmt oder nicht. Empfehlungen für Folgeaktionen Empfohlene Maßnahmen für z.B. die Beendigung notwendiger Arbeiten oder die Behandlung Offener Punkte. Eine Übersicht all dieser Empfehlungen findet sich im Phasenabschlussals auch im Projektabschlussbericht. Ereignisgesteuerte Steuerungsmittel Ein Werkzeug, von dem bei Auftreten gewisser Ereignisse (z.B. Phasenende oder auch Ende eines Geschäftsjahres) Gebrauch gemacht wird. Erfahrungsbericht Bericht, der sinnvolle Erfahrungswerte für andere Projekte dokumentiert. Somit sollen Fehler vergangener Projekte vermieden und Wissen aus positiven Erfahrungen weiterhin genutzt werden. Erfahrungsprotokoll Eine Zusammenstellung bisheriger, nützlicher Erfahrungen. Ergreifen (Risikobehandlung) Form der Behandlung einer Chance, bei der Maßnahmen zur Ergreifung des Risikos getroffen werden, um das gewünschte Ergebnis zu erzielen. <?page no="185"?> ]aHCCPE 185 Ersteller Die/ der Entwickler eines Produkts. Eventualfall (Risikobehandlung) Form der Behandlung einer Bedrohung, bei der Maßnahmen für den Fall zusammengestellt werden, dass das Risiko tatsächlich eintritt. Freigabe Zeitpunkt der Genehmigung von Plänen bzw. der Erteilung von Befugnissen. Governance (Projekt) Teile der Lenkungsform des Unternehmens, die direkt die Projektaktivitäten berührt. Somit werden die Effizienz der Tätigkeiten und die Abstimmung des Projekts auf die Unternehmensziele gewährleistet. Governance (Unternehmen) Ordnungsrahmen für die Leitung und Führung eines Unternehmens. Sie dient u.a. der Aufrechterhaltung effektiver Managementsysteme, dem Schutz der Wirtschaftsgüter als auch der Wahrung einer positiven Unternehmensreputation. Grundprinzip Grundsätze, die bei der Planung und Durchführung eines PRINCE2-Projekts unbedingt einzuhalten sind. Initiierungsphase Projektphase zwischen Freigabe der Projektinitiierung und Freigabe des Projekts, welche jeweils vom Lenkungsausschuss erteilt werden. Hier soll ein solides Fundament für das Projekt gelegt werden. <?page no="186"?> 186 ]aHCCPE Integration (PRINCE2) Schaffen der Bedingungen, die für den Gebrauch von PRINCE2 als Projektmanagement-Framework in einer Organisation existieren müssen. Kategorie der Risikobehandlung Hier wird differenziert zwischen Chancen und Bedrohungen. Für Chancen: Steigern, Ergreifen, Ablehnen oder Teilen. Für Bedrohungen: Vermeiden, Reduzieren, Übertragen, Akzeptieren oder Teilen. Kommunikationsmanagementstrategie Definition der projektbezogenen Kommunikation inklusive Austauschmedien und -zyklen. Konfigurationsdatensatz Ein Nachweis über Status, Version und Variante eines Konfigurationselements. Es werden auch Verbindungen zu anderen Elementen dargestellt. Konfigurationselement Eine Einheit, die zum Konfigurationsmanagement gehört. Konfigurationsmanagement Technische und organisatorische Behandlung der Konfiguration eines Projekts während dessen Lebensdauer. Konfigurationsmanagementstrategie Eine Definition, in welcher Weise und von welchen Personen die Produkte eines Projekts dokumentiert, gesteuert und geschützt werden. <?page no="187"?> ]aHCCPE 18& <?page no="188"?> 188 ]aHCCPE <?page no="189"?> ]aHCCPE 189 <?page no="190"?> 190 ]aHCCPE <?page no="191"?> ]aHCCPE %! % <?page no="192"?> 19$ ]aHCCPE <?page no="193"?> ]aHCCPE %! # <?page no="194"?> 194 ]aHCCPE <?page no="195"?> ] a HC CP E <?page no="196"?> 196 ]aHCCPE <?page no="197"?> ]aHCCPE %! " Ein Ereignis oder Bündel von Ereignissen, die bei einem Eintritt das Projekt positiv <?page no="198"?> 198 ]aHCCPE (Chance) oder negativ (Bedrohung) beeinflussen. Das Risiko ergibt sich aus dem Produkt von Eintrittswahrscheinlichkeit und Auswirkung. <?page no="199"?> ]aHCCPE %! ! <?page no="200"?> 20& ]aHCCPE <?page no="201"?> ]aHCCPE $&% <?page no="202"?> 202 ]aHCCPE <?page no="203"?> ]aHCCPE $&# <?page no="205"?> 8 Lösungen zu den Übungsfragen Lösung Übungsfragen Kapitel Eins - Grundlagen (Seite 4! ) Die richtigen Antworten sind: Frage 1: c Frage 2: d Frage 3: b Frage 4: b Frage 5: b Frage 6: b Frage 7: d Frage 8: b Frage 9: c Frage 10: b Frage 11: c Frage 12: c Frage 13: d Frage 14: d Lösung Übungsfragen Kapitel Zwei - Projektvorbereitung (Seite 79) Die richtigen Antworten sind: Frage 15: c Frage 16 b <?page no="206"?> 206 XMC? _*._ \? I._ QO? _*C,EP*._ Frage 17: b Frage 18: b Frage 19: d Frage 20: b Frage 21: c Frage 22: b Frage 23: c Frage 24: c Frage 25: d Frage 26: a Frage 27: c Frage 28: a Frage 29: a Frage 30: d Lösung Übungsfragen Kapitel Drei - Projektinitiierung (Seite 139) Die richtigen Antworten sind: Frage 31: a Frage 32: c Frage 33: c Frage 34: d Frage 35: b Frage 36: a Frage 37: d Frage 38: b Frage 39: a <?page no="207"?> XMC? _*._ \? I._ QO? _*C,EP*._ 207 Frage 40: c Frage 41: a Frage 42: c Frage 43: b Frage 44: c Frage 45: d Lösung Übungsfragen Kapitel Vier # Projektablauf (Seite 164) Die richtigen Antworten sind: Frage 46: b Frage 47: d Frage 48: d Frage 49: a Frage 50: d Frage 51: b Frage 52: c Frage 53: b Frage 54: c Frage 55: d Frage 56: c Frage 57: b Frage 58: a Frage 59: b Frage 60: a <?page no="208"?> 208 XMC? _*._ \? I._ QO? _*C,EP*._ Lösung Übungsfragen Kapitel 5 - Projektabschluss (Seite173) Die richtigen Antworten sind: Frage 61: a Frage 62: c Frage 63: a Frage 64: a Frage 65: b Frage 66: c <?page no="209"?> Index Arbeitspakete 43 Arbeitsverteilung 43 Auftraggeber 63 Ausnahme 87 Ausnahmeplan 101 Bedrohung 123 Benutzervertreter 63 Bottom-Up-Prinzip 115 Budget 35 Budgetverantwortung 134 Business Case 72 Business-Case-Entwurf 54 Chance 125 Dokumentenstruktur 45 Führungsphilosophie 34 Gegenstromverfahren 116 Initiierungsphasenplan 101 Kommunikation 67 Kommunikationsmanagementstrategie 91 Kompetenzen 59 Konfiguarationsmanagement 40 Konflikte 68 Lenkungsausschuss 62, 87 Lernrate 25 Lessons Learned Meetings 31 Lieferantenvertreter 63 Linienorganisation 19 Management by Exception 34 Mikromanagement 26, 32 Mitarbeitermanagement 66 Organisation 59 Organisationstruktur 59 PEP 55 Phasenplan 95, 101 Pläne 98 <?page no="210"?> 210 [_I.9 Planung 40 Projektende 78 Projektendprodukt 55 Projektfortschritt 41 Projektinteressen 59 Projektinvestition 71 Projektleitdokumentation 96 Projektmanagement-Tools 93 Projektmanager 65 Projektplan 94, 100 Projektsicherung 64 Projektumgebung 36 Projektunterstützung 170 Prozesse 42 Qualität 23, 39 Qualitätskontrollpfad 152 Qualitätsverantwortlichkeiten 91 Reportingstrukturen 27 Return on Investment 24 Risiko 20, 40, 123 Risikobereitschaft 132 Risikomanagement 126 Risikoregister 128 Risikostrategie 24 Rollen 59 Scope 24 Softwareentwicklung 41 Soll-Ist-Vergleich 107 Spezialisten-Produkt 44, 154 Staffing 67 StartUp-Finanzierung 137 Teammanager 115 Teamplan 102 Toleranzen 111 Top-Down-Prinzip 115 Überwachung 26 Verantwortlichkeiten 32, 59 Verhandlung 35 Vorbereiten eines Projekts 57 Workaround-Lösung 119 Zeitmanagement 66 <?page no="211"?> Endlich durchsetzen! Nikita Gribenko Durchsetzungsvermögen - privat und geschäftlich Praxistraining 2018, 150 Seiten, Hardcover ISBN 978-3-86764-850-9 Viele Situationen im Beruf und im Alltag erfordern Durchsetzungskraft. Doch Menschen, die sich nicht durchsetzen, haben meist das Nachsehen: Sie werden öfter ausgenutzt, weniger ernst genommen oder respektiert als andere. Dieser Ratgeber zeigt, wie Sie ihr Durchsetzungsvermögen erhöhen und Ihre Interessen und Ziele besser erreichen können. Der Autor dieses Buches setzt dafür an der Individualität an. Er fragt zunächst nach dem Persönlichkeitstyp, nach der eigenen Motivation, der subjektiven Wahrnehmung. Erst durch eine ausführliche Selbstanalyse ist man in der Lage, als Person zu überzeugen und sich selbst zu beeinflussen. Anschließend werden die Techniken der Körpersprache, der Kommunikation und der Manipulation anschaulich beschrieben. Das Buch richtet sich an alle, die lernen wollen, sich durchzusetzen. www.uvk.de <?page no="212"?> www.uvk.de STUDIEREN IM QUADRAT Erfolgreich studieren, das ist leichter gesagt, als getan. Denn zwischen Hörsaal, Bibliothek und Prüfungen gibt es im Studi- Alltag so manche Herausforderung zu meistern. Die UVK-Reihe »Studieren im Quadrat« hilft Ihnen dabei, in allen Lebenslagen cool zu bleiben - vom Praktikum, über die Studienkrise bis hin zur Gründung des ersten Start-ups. Also keine Sorge, die bunten Bücher stehen Ihnen bei Fragen rund ums Studium bei. I S B N 9 7 8 3 I S B N 9 7 8 3 I S B N 9 7 8 3 I S B N 9 7 8 3 I S B N 9 7 8 3 I S B N 9 7 8 3 I S B N 9 7 8 I S B N 9 7 8 - 3 - 8 6 7 6 4 - 7 0 4 - 5 I S B N 9 7 8 - 3 - 8 6 7 6 4 - 7 0 1 - 4 I S B N 9 7 8 - 3 - 8 6 7 6 4 - 7 0 0 - 7 I S B N 9 7 8 - 3 - 8 6 7 6 4 - 7 6 5 - 6 I S B N 9 7 8 - 3 - 8 6 7 6 4 - 7 0 2 - 1 I S B N 9 7 8 - 3 - 8 6 7 6 4 - 7 0 3 - 8 I S B N 9 7 8 - 3 - 8 6 7 6 4 - 7 6 4 - 9