ein prozessorientiertes Vorgehensmodell für jede Art von Projekten Foundation & Practitioner PRINCE2: goup GmbH

Transkript

1 ein prozessorientiertes Vorgehensmodell für jede Art von Projekten Kompendium für die Examensvorbereitung Foundation & Practitioner Hinweise zum vorliegenden Handbuch: Das Kompendium wurde im Rahmen der Prüfungsvorbereitungen erstellt. Es diente uns als Vorbereitung und soll auch anderen Personen, die sich PRINCE2 zertifizieren wollen, gute Unterstützung bieten. In diesem Rahmen wird dieses Dokument jedem Interessierten dienlich sein. Gleichzeitig ist es auch eine Zusammenfassung des offiziellen OCG PRINCE2-Buchs Managing Successful Projekts with PRINCE2 und anderer Quellen. Das Kompendium wurde nach bestem Wissen und Gewissen verfasst. Somit steht allen Interessierten ein kompaktes Grundlagenwerk zur Verfügung. Jegliche Verantwortung bezüglich unvollständigem oder falschem Inhalt wird abgelehnt. Seite 1 von 72

2 PRINCE is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries. PRINCE2 TM is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries. Das Kompendium ist auf der Grundlage der folgenden Quellen entstanden: Managing Successful Projects with PRINCE2 TM Published by TSO ( ISBN Passing the PRINCE2 Examinations Published by TSO ( ISBN Seite 2 von 72

3 INHALTSVERZEICHNIS VORWORT 9 1 P RI N CE2:2009 I M Ü BE RBLI C K Allgemeines Definition von Projektmanagement und Projekt Charakteristische Merkmale eines Projekts Die 6 Dimensionen eines Projekts Nutzen von PRINCE Der PRINCE2 Steuerungskreis Die Gliederung von PRINCE Die vier Wissensgebiete Grundprinzipien Themen Prozesse Anpassen von PRINCE Lerninhalte Foundation Practitioner Quiz 15 2 T H EMEN Business Case Zweck Überblick Inhalt Definitionen Entwicklungspfad des Business Case Nutzenrevision Lerninhalte Quiz Organisation Zweck Überblick Drei Interessensgruppen an einem Projekt Die vier Managementebenen in der Projektmanagementstruktur Projektorganisation Lerninhalte 23 Seite 3 von 72

4 2.2.7 Quiz Qualität Zweck Qualitätsplanung Qualitätssteuerung Qualitätserwartungen des Kunden Qualitätssicherung Qualitätskontrollpfad Qualitätsprüfung Rollen des Qualitätsprüfungsteams Schritte der Qualitätsprüfung Qualitätsprüfungstechnik Lerninhalte Quiz Pläne Zweck Planungsebenen Erstellung von Plänen Übersicht der Planung Übersicht Produktbasierte Planung Beispiel für einen Produktstrukturplan Produktbeschreibung erstellen Beispiel für ein Produktflußdiagramm Lerninhalte Quiz Risiken Zweck Definition Risiko Ablauf des Risikomanagements Definitionen Behandlung von Bedrohungen Behandlung von Chancen Risikobudget Beispiel einer Risikomatrix Lerninhalte Quiz Änderung Zweck Typen von Offenen Punkten Definitionen Offene Punkte und Änderungssteuerungsprozedur Lerninhalte Quiz 37 Seite 4 von 72

5 2.7 Fortschritt Zweck Phasen zur Projektsteuerung Ausnahmen und Toleranzen zur Projektsteuerung Toleranzen und Eskalationen Steuerungsmittel des Lenkungsausschusses Steuerungsmittel des Projektmanagers Definitionen Lerninhalte Quiz 40 3 P RO ZESSE Vorbereiten eines Projekts Zweck Inhalt Ziele Aktivitäten Dokumente Lerninhalte Quiz Lenken eines Projekts Zweck Inhalt Ziele Aktivitäten Dokumente Lerninhalte Quiz Initiieren eines Projekts Zweck Inhalt Ziele Aktivitäten Dokumente Lerninhalte Quiz Managen eines Phasenübergangs Zweck Inhalt Ziele Aktivitäten Dokumente Zusätzliche Informationen 51 Seite 5 von 72

6 3.4.7 Lerninhalte Quiz Steuern einer Phase Zweck Inhalt Ziele Aktivitäten Dokumente Zusätzliche Informationen Lerninhalte Quiz Managen der Produktlieferung Zweck Inhalt Ziele Aktivitäten Dokumente Zusätzliche Informationen Lerninhalte Quiz Abschließen eines Projekts Zweck Inhalt Ziele Aktivitäten Dokumente Lerninhalte Quiz 61 4 M AN AG E M E N TP RO D UKTE Risikomanagementstrategie Konfigurationsmanagementstrategie Qualitätsmanagementstrategie Kommunikationsmanagementstrategie Projektlösungsansatz Produktbeschreibung (Product Description) Projektendproduktbeschreibung (Project Product Description) 64 Seite 6 von 72

7 4.8 Projektleitdokumentation Projektplan Produktstatusauskunft (Product Status Account) Projektbeschreibung (Project Brief) Qualitätsregister 66 Z U S AM M E N F AS S E N DE LE HRSÄT Z E 67 H I NWEISE Z U R FO U ND AT I O N PRÜFUNG 69 H I NWEISE Z U R PR AC T I T IONE R PRÜFUNG 70 L I NKS 72 Seite 7 von 72

8 ABBILDUNGSVERZEICHIS Abbildung 1: PRINCE2 Steuerungskreis 11 Abbildung 2: Die PRINCE2 Prozesse 13 Abbildung 3: Entwicklungspfad des Business Case 19 Abbildung 4: Interessensgruppen an einem Projekt 20 Abbildung 5: Projektorganisation 21 Abbildung 6: Möglicher Aufbau des Berichtswesens 22 Abbildung 7: Qualitätskontrollpfad 25 Abbildung 8: Planungsebenen 28 Abbildung 9: Übersicht der Planung 29 Abbildung 10: Übersicht Produktbasierte Planung 29 Abbildung 11: Beispiel Produktstrukturplan 30 Abbildung 12: Beispiel Produktflußdiagramm 31 Abbildung 13: Definition Risiko 32 Abbildung 14: Ablauf des Risikomanagements 32 Abbildung 15: Beispiel einer Risikomatrix 34 Abbildung 16: Toleranzen und Eskalationen 39 Abbildung 17: Vorbereiten eines Projekts (SU) 41 Abbildung 18: Lenken eines Projekts (DP) 44 Abbildung 19: Initiieren eines Projekts (IP) 47 Abbildung 20: Managen eines Phasenübergangs (SB) 50 Abbildung 21: Steuern einer Phase (CS) 53 Abbildung 22: Managen der Produktlieferung (MP) 56 Abbildung 23: Abschließen eines Projekts (CP) 59 TABELLENVERZEICHNIS Tabelle 1: Nutzen von PRINCE2 11 Seite 8 von 72

9 VORWORT PRINCE2 (Projects in Controlled Environments) ist eine Projektmanagement-Methode für Organisation, Management und die Steuerung von Projekten. Sie wurde ursprünglich 1989 von der britischen Central Computer and Telecommunications Agency (CCTA) als Regierungsstandard für Projektmanagement im Bereich der Informationstechnik (IT) entwickelt, wurde jedoch bald regelmäßig auch außerhalb von reinen IT Umgebungen angewendet. PRINCE2 wurde 1996 als allgemeine Projektmanagement-Methode veröffentlicht und von der Office of Government Commerce (OGC) übernommen. PRINCE2 ist zunehmend populärer geworden und ist nun der de facto-standard für Projektmanagement in Großbritannien. Seine Anwendung ist mittlerweile in mehr als 50 anderen Ländern verbreitet. PRINCE2 Refresh: Seit 2006 wurde die Methode grundlegend überarbeitet und am 16. Juni 2009 als veröffentlicht. Die Beibehaltung der Bezeichnung "PRINCE2" (anstatt "PRINCE3" o.ä.) soll ausdrücken, dass die Methode den Grundprinzipien treu bleibt. Nichtsdestoweniger handelt es sich hierbei um eine Anpassung der Methode von 1996 an die veränderte Geschäftswelt einschließlich einer starken Verschlankung der Methode, der Klärung von bisherigen Kritikpunkten bzw. Missverständnissen sowie eine bessere Integration von PRINCE2 mit anderen Methoden (ITIL, P3O, P3M3, MSP, M_o_R usw). Begleitend zu diesem Kompendium sollten Sie als Prüfungsvorbereitung das offizielle OGC Buch Managing Successful Project with PRINCE2 quer lesen. Da Sie in der Practitioner Prüfung das Buch (und ebenfalls Ihre handschriftlichen Notizen in dem Buch) benutzen dürfen, empfiehlt es sich, beim Lesen die einzelnen Kapitel des Buches zu markieren (mit Reitern). So lassen sich im Notfall - während der Prüfung - die Kapitel und deren Inhalte schneller finden. Bei der Foundation Prüfung (deren bestehen die Zugangsvoraussetzung für die Practitioner Prüfung ist) dürfen Sie keinerlei Unterlagen verwenden (closed book). Näheres dazu finden Sie im Kapitel Hinweise zur Foundation/Practitioner dieses Kompendiums. gliedert sich in 4 Wissensgebiete: 7 Grundprinzipien 7 Themen 7 Prozesse Anpassen von PRINCE2 an die Projektumgebung Das Kompendium fasst die für die Prüfungen erforderlichen Inhalte kompakt zusammen. Damit haben Sie ein stabiles Grundgerüst mit dem Sie durchaus die Prüfung bestehen können. Ebenso dient das Kompendium als nützliches Nachschlagewerk für den Einstieg als Projektmanager. Sollten Sie Verbesserungsvorschläge haben, so zögern Sie nicht und lassen Sie uns diese per zukommen. Jede Art von Kritik oder Anregung ist willkommen! Doch nun wünschen wir Ihnen viel Spaß beim Lernen und nachschlagen. Seite 9 von 72

10 1 IM ÜBERBLICK In diesem Kapitel werden die Grundlagen von kurz angerissen. Übersichtlich, gedacht zum schnellen lernen und nachschlagen. Die einzelnen Inhalte werden falls notwendig in den nachfolgenden Kapiteln vertieft. 1.1 Allgemeines Definition von Projektmanagement und Projekt Projektmanagement ist die Planung, Delegierung, Überwachung und Steuerung aller Aspekte eines Projekts. Dazu gehören die Motivation der Beteiligten, die Projektziele zu erreichen, und zwar innerhalb der Zielvorgaben für Kosten, Zeit, Qualität, Umfang, Risiko und Nutzen. Ein Projekt ist eine für einen befristeten Zeitraum geschaffene Organisation, die den Auftrag hat, ein oder mehr Produkte entsprechend einen vereinbarten Business Case zu liefern Charakteristische Merkmale eines Projekts Unterliegt Änderungen Zeitlich begrenzt Unternehmensübergreifend Einmaligkeit Ungewissheit Jedes Projekt erfüllt die genannten Merkmale. Ist eines der Kriterien nicht erfüllt, so handelt es sich nicht um ein Projekt, dass nach PRINCE2 aufgebaut ist Die 6 Dimensionen eines Projekts Kosten Zeit Qualität Umfang Risiko Nutzen Die Dimensionen spiegeln die Parameter wieder, innerhalb derer sich das Projekt abspielt. Die einzelnen Dimensionen zu überwachen ist die Aufgabe des Projektmanagers, der das jedoch in Form von Projekttoleranzen delegieren kann. Seite 10 von 72

11 1.1.4 Nutzen von PRINCE2 Best practice und Governance für die Projekte Für alle Arten von Projekten geeignet Gemeinsame Sprache Vereinbarte Verantwortlichkeiten Fokus auf den Produkten Managementebenenorientierte Planung Steuern nach dem Ausnahmeprinzip Ausrichtung am Business Case Rationelle Berichtsstruktur Einbindung der Stakeholder Lernen und Verbessern Wertvolles Diagnosewerkzeug Der PRINCE2 Steuerungskreis Tabelle 1: Nutzen von PRINCE2 Crown copyright Material is reproduced with permission from OGC Abbildung 1: PRINCE2 Steuerungskreis Der Steuerungskreis ermöglicht es dem Projektmanager die Kontrolle über das Projekt zu behalten (s.h. Definition Projektmanagement Kapitel 1.1.1) Die Gliederung von PRINCE2 7 Grundprinzipien 7 Themen 7 Prozesse Anpassen von PRINCE2 an die Projektumgebung Zusätzlich zu diesen Wissensgebieten bietet das offizielle PRINCE2 Buch der OGC zahlreiche Anlagen: 26 Managementprodukte (mit denen das Projekt gesteuert wird), Governance, Rollen & Verantwortlichkeiten, Produktbasierte Planung und den Gesundheitscheck. Seite 11 von 72

12 1.2 Die vier Wissensgebiete Grundprinzipien Die Grundprinzipien bilden die Grundlagen für ein erfolgreiches Projektmanagement. Sie wurden abgeleitet aus den Erfahrungen erfolgreicher Projekte (Framework of good practice). Fortlaufende geschäftliche Rechtfertigung Lernen aus Erfahrung Definierte Rollen und Verantwortlichkeiten Steuern über Managementphasen Steuern nach dem Ausnahmeprinzip Produktorientiert Anpassen an die Projektumgebung Die PRINCE2 Grundprinzipien sind im offiziellen OGC Buch nur kurz beschrieben, da sie eigentlich selbsterklärend sind. Aus diesem Grund werden wir Sie in diesem Kompendium auch nicht näher beschreiben. ABER: Sie sind nicht minder wichtig. Ein Projekt das eines dieser Grundprinzipien verletzt, ist per Definition kein PRINCE2 Projekt mehr! Themen Themen sind Aspekte des täglichen Projektmanagements, die fortlaufend adressiert und betrachtet werden müssen. Business Case (Warum?) Organisation (Wer?) Qualität (Was?) Pläne (Wie, wie viel, wann?) Risiken (Was wenn?) Änderung (Was ist die Auswirkung?) Fortschritt (Wo sind wir jetzt? Wo gehen wir hin? Sollen wir weitergehen?) Die PRINCE2 Themen werden im Kapitel Themen näher beschrieben. Seite 12 von 72

13 1.2.3 Prozesse Die Prozesse beschreiben den schrittweisen Ablauf eines Projekts von der Vorbereitung bis zum Abschluss (Ablaufsteuerung). Im Folgenden finden Sie alle PRINCE2 Prozesse abgebildet. Innerhalb der Prozesse beschreibt PRINCE2 die jeweiligen Aktivitäten. Wichtige Hinweise zu den Prozessen: Crown copyright Material is reproduced with permission from OGC Abbildung 2: Die PRINCE2 Prozesse Vorbereiten eines Projekts (SU) kommt sowohl auf der Lenkungs- als auch auf der Managementebene zur Anwendung (s.h. Grafik oben). Jedes PRINCE2-Projekt muss mindestens zwei Managementphasen haben. Die erste ist die Initiierungsphase (in kleineren Projekten können SU + IP zusammen gelegt werden). Managen eines Phasenübergangs (SB) wird erstmalig am Ende der Initiierungsphase eingesetzt und dann am Ende jeder nachfolgenden Phase (ausgenommen die letzte Phase) wiederholt. Außerdem wird dieser Prozess für die Erstellung von Ausnahmeplänen benötigt. Diese können jederzeit (auch in der letzten Phase) notwendig werden können. Wenn die Initiierung eines Projekts (IP) komplex oder langwierig ist, können optional Steuern einer Phase (CS) und Managen der Produktlieferung (MP) für das Management der Initiierungsphase verwendet werden. Die PRINCE2 Prozesse werden im Kapitel Prozesse näher beschrieben. Seite 13 von 72

14 1.2.4 Anpassen von PRINCE2 Der Vorgängerversion von hat man nachgesagt, dass es vielfach zu mächtig und bürokratisch sei. Aus diesem Grund findet sich nun im offiziellen OGC Buch auch ein Kapitel Anpassen von PRINCE2 an die Projektumgebung gleichzeitig ist es das vierte Wissensgebiet von. Anpassen Die Abstimmung von PRINCE2 auf ein bestimmtes Projekt, damit Planung, Steuerung und Governance sowie die Verwendung von Prozessen und Themen dem Projekt angemessen sind. Aufgabe der Organisation bei der Einführung von PRINCE2 (Kernpunkte): Prozessverantwortlichkeiten Regeln/Anleitung für die Umfangbestimmung (z.b. Scorecard) Standards (Vorlagen, Definitionen) Training und Entwicklung Einbindung in die Geschäftsprozesse Werkzeuge Prozesssicherung Integration Die unternehmensweite Einführung von PRINCE2. Aufgabe des Projektmanagementteams zur Abstimmung der Methode auf den Kontext eines konkreten Projekts (Kernpunkte): Anpassen der Themen (durch Strategien und Steuerungsmittel) Einbindung bestimmter Begriffe/einer bestimmten Terminologie Anpassen der Produktbeschreibung für die Managementprodukte Anpassen der Rollenbeschreibungen für die Rollen in einem PRINCE2-Projekt Anpassen der Prozesse auf o.g. Anpassungen 1.3 Lerninhalte Diese Kapitel finden Sie jeweils am Ende einer Lerneinheit. Hier erfahren Sie, was Sie für die Foundation bzw. Practitioner Prüfung wissen sollten. Die Inhalte zu den genannten Punkten müssen erklärt werden und Sie müssen wissen was dahinter steckt. Falls Sie den einen oder anderen Punkt noch nicht sicher beantworten können, dann ist das noch nicht weiter schlimm. Viele Punkte lassen sich erst nach dem Durcharbeiten des kompletten Kompendiums beantworten Foundation Sie müssen die 6 Dimensionen eines Projekts nennen können Sie sollten die Definition und 5 Charakteristika eines Projekts kennen und verstehen Seite 14 von 72

15 Sie müssen die 4 integrierten PRINCE2 Elemente kennen (Grundprinzipien, Themen, Prozesse, Projekt Umgebung) Sie sollten den Nutzen von PRINCE2 kennen Kunden-/Lieferantenbeziehung eines PRINCE2 Projekts Sie sollten die 7 Grundprinzipien nennen können und verstanden haben Sie sollten den Unterschied zwischen einem Projekt und Programm kennen Practitioner Sie müssen den Unterschied zwischen Anpassen und Integration von PRINCE2 erklären können Unterschied einer Kuden-/Lieferantenbeziehung und wie es sich auf die Themen, Prozesse und Managementprodukte in einem Projekt auswirkt Sie sollten wissen, wie Sie PRINCE2 an ein Projektszenario anpassen können Sie sollten bewerten können, ob PRINCE2 richtig an das Projektszenario angepasst wurde 1.4 Quiz Mit den nachfolgenden Quiz können Sie Ihr wissen überprüfen. Machen Sie mit und versuchen Sie die Rätsel zu lösen. Wir wünschen Ihnen viel Spaß dabei. Dimensionen eines Projekts? Unser erstes Kreuzworträtsel. Lösen Sie es wie gewohnt. Sicher schaffen Sie es mit den nachfolgenden Hinweisen ganz einfach, oder? 1) Anderes Wort für etwas probieren. 2) Übersetzen Sie Time ins Deutsche. 3) Ausmaß, Körperfülle 4) Das Gegenteil von Pfusch. 5) Wagnis 6) Das Gegenteil von Nachteil. Seite 15 von 72

16 Wortsalat - Grundprinzipien Huch, da sind wohl einige Wörter durcheinander geraden. Können Sie sie die Wörter wieder richtig sortieren? Erinnern Sie sich noch an die PRINCE2 Themen? 1) Geschäftsvorfall auf engl. 2) Anderes Wort für Gruppe 3) Anderes Wort für Güteklasse 4) Anderes Wort für Zeichnungen 5) Experimente beinhalten immer. 6) Das Gegenteil von Beibehaltung 7) Das Gegenteil von Rückschritt Buchstabensalat Da sind uns wohl die Buchstaben durcheinander geraten. Können Sie es wieder sortieren? Seite 16 von 72

17 2 THEMEN 2.1 Business Case Zweck Zweck des Business Case ist es einen Mechanismus bereitzustellen der feststellt, ob das Projekt (immer noch) erstrebenswert, machbar und erreichbar ist. Der Business Case ist ein Mittel, um die kontinuierliche Investition in ein Projekt zu rechtfertigen. Der Business Case ist die Grundlage für das Grundprinzip Fortlaufende geschäftliche Rechtfertigung Überblick Er ist die wirtschaftliche Rechtfertigung für ein Projekt Wird zu Beginn erstellt Motor des Projekts Wird während der gesamten Lebensdauer des Projekts überprüft Hilft dem Lenkungsausschuss bei wichtigen Entscheidungen Er liefert allen interessierten Parteien grundlegende Informationen über das Projekt Anhand des Business Case wird bei Projektabschluss bewertet, ob das Projektergebnis erreicht wurde Er ist die Basis für den Nutzenrevisionsplan, d.h. die spätere Beurteilung des Projekterfolgs Kein Projekt sollte ohne validen Business Case gestartet werden! Der Business Case beantwortet folgende Fragen: Gründe für das Projekt und die Notwendigkeit der zu liefernden Produkte Mögliche Optionen (einschl. Nulloption) für die Lieferung des Ergebnisses und die Begründung der gewählten Option, einschl. Nulloption Erwarteter Nutzen Die wichtigsten Risiken Übersicht über die Projektkosten und Zeitachse Investitionsbewertung Evaluation Seite 17 von 72

18 Es gibt verschiedene Arten eines Business Case, je nach Art des Projekts: Gesetzliche Projekte Non-Profit-Projekte Entwicklungsprojekte Kunden-/Lieferantenprojekte Multiorganisationsprojekte PRINCE2 geht im Regelfall von einem Kunden-/Lieferantenprojekt aus Inhalt Zusammenfassung: Schlüsselargumente, u.a. Nutzen und Kapitalverzinsung (ROI) Gründe: für die Durchführung des Projekts und wie das Projekt die Strategie und Ziele des Unternehmens unterstützt Optionen: Analyse und begründete Empfehlung für eine der drei grundsätzlichen Optionen (Nulloption do nothing, Minimumoption do minimun, Minimum-Plus-Option do something ) Erwarteter Nutzen: Erwarteter Nutzen der qualitativ und quantitativ messbar sein sollte. Erwartete negative Nutzeneffekte Zeitrahmen: Laufzeit des Projekts + Zeitraum bis zur Realisierung des Nutzens Kosten: Zusammenfassung der Projektkosten (aus Projektplan), der laufenden Betriebs- /Wartungskosten und deren Finanzierung Investitionsrechnung: Vergleich des Nutzens und der negativen Effekte mit den Projektkosten sowie den laufenden Betriebs- und Wartungskosteten. Hauptrisiken: Zusammenfassung der mit dem Projekt verbundenden Hauptrisiken, ihrer wahrscheinlichen Auswirkung und der Plan für den Fall des Eintretens Definitionen Output: Ein Spezialistenprodukt, dass einem Benutzer übergeben wird (z.b. neues Verkaufssystem) Ergebnis: Das Resultat einer Veränderung, das sich auf das Verhalten und/oder die Gegebenheiten in der Umgebung auswirkt (z.b. Aufträge können schneller bearbeitet werden). Nutzen: Eine messbare Verbesserung, die aus einem Projektergebnis resultiert und von allen an Projekt beteiligten (Stakeholdern) als Vorteil betrachtet wird (z.b. Kostenreduktion um 10%). Seite 18 von 72

19 2.1.5 Entwicklungspfad des Business Case Crown copyright Material is reproduced with permission from OGC Abbildung 3: Entwicklungspfad des Business Case Verantwortlich für den Business Case ist der Auftraggeber. Der Projektmanager erstellt diesen im Auftrag des Auftraggebers. Entwickelt wird der Business Case in Vorbereiten eines Projekts (SU) + Initiieren des Projekts (IP). In den folgenden Phasen wird der Business Case stetig gepflegt. Eine Bestätigung des aktuellen Business Case erfolgt immer vor Beginn einer neuen Phase durch den Lenkungsausschuss Nutzenrevision Nutzenrevisionsplan (Verantwortlich: Unternehmens- oder Programmmanagement oder der Auftraggeber) Ein Plan der definiert, wie und wann gemessen werden kann, ob der erwarteter Projektnutzen erreicht worden ist. Erstellung während der Projektinitiierung Aktualisierung am Ende jeder Phase Abgeschlossen am Ende des Projekts Nutzenrevision Während des Projekts für (Teil-)Ergebnisse der Phase Nach dem Projekt für das Endprodukt Der Nutzen eines Projekts tritt im Regelfall erst nach dem Projekt ein. Der Nutzenrevisionsplan wird nach einem zeit- oder eventgesteuerten Trigger wieder überprüft um festzustellen, ob der erwartete Nutzen eingetreten ist Lerninhalte Quiz Seite 19 von 72

20 2.2 Organisation Zweck Zweck des Themas Organisation ist es, eine Projektstruktur mit klarer Abgrenzung zwischen Ergebnisverantwortung und Durchführungsverantwortung zu definieren. Das Thema Organisation unterstützt vollständig das PRINCE2-Prinzip Definierte Rollen und Verantwortlichkeiten Überblick Kunden-/Lieferantenbeziehung Jedes Projekt benötigt Steuerung, Kontrolle und Kommunikation Die Projektorganisation unterscheidet Entscheidungsträger von Leuten mit Meinungen Klarstellung von Aufgaben, Kompetenzen und Verantwortung Eine effektive Organisationsstruktur ist für den Projekterfolg von entscheidender Bedeutung Je nach Größe des Projekts können Rollen wahlweise mit einer oder mehreren besetzt werden und auch kombiniert werden, solange es keine Zielkonflikte gibt Drei Interessensgruppen an einem Projekt Crown copyright Material is reproduced with permission from OGC Abbildung 4: Interessensgruppen an einem Projekt PRINCE2 kennt drei Interessensgruppen an einem Projekt. Ein Projekt besteht unter anderem aus Vertretern der jeweiligen Gruppe. So kommt aus dem Unternehmen in der Regel der Auftraggeber. Die Benutzer spezifizieren das Projektendprodukt des Projekts und der Lieferant erstellt die Projektprodukte. Seite 20 von 72

21 2.2.4 Die vier Managementebenen in der Projektmanagementstruktur Unternehmens- oder Programmmanagement Lenken Lenkungsausschuss (Projektmanagementteam) Steuern/Managen Projektmanager (Projektmanagementteam) Liefern Teammanager (Projektmanagementteam) Der Lenkungsausschuss ist gegenüber dem Unternehmens- bzw. Programmmanagement für die Lenkung und das Management des Projekts im Rahmen der Vorgaben des Unternehmens- oder Programmmanagements gesamthaft (mit einer Gesamtvollmacht) verantwortlich für das Projekt. Er vertritt das Projekt nach außen hin und ist für die Kommunikation mit externen Stellen sowie für allg. Bekanntmachungen verantwortlich. Je nach Umfang, Komplexität und Risiken des Projekts kann der Lenkungsausschuss einige oder zusätzliche Projektsicherungsaufgaben an zusätzliche Ressourcen delegieren. Ansonsten verbleibt die Projektsicherung beim Lenkungsausschuss. Die Entscheidungsverantwortung des Projektmanagers und des Lenkungsausschusses kann nicht delegiert werden. Es ist jedoch möglich, Rollen zu kombinieren - solange keine Zielkonflikte entstehen oder bestehen. Entfallen dürfen die Rollen allerdings nicht Projektorganisation Crown copyright Material is reproduced with permission from OGC Abbildung 5: Projektorganisation Seite 21 von 72

22 Crown copyright Material is reproduced with permission from OGC Abbildung 6: Möglicher Aufbau des Berichtswesens Eine Projektorganisation besteht aus den nachfolgend genannten Rollen. Lenkungsausschuss: Der Lenkungsausschuss besteht aus Benutzervertreter, Lieferantenvertreter und Auftraggeber. Er ist allerdings keine Demokratie. Der Auftraggeber hat die alleinige Entscheidungsgewalt. Auftraggeber: Eine Person, die die Gesamtverantwortung für ein Projekt hat und dafür Sorge tragen muss, dass die vorgegebenen Ziele erreicht werden und der geplante Nutzen erzielt wird. Benutzervertreter: Die Rolle im Lenkungsausschuss die dafür verantwortlich ist, dass die Anforderungen der Benutzer richtig spezifiziert und die Lösungen darauf abgestimmt werden. Lieferantenvertreter: Das Mitglied des Lenkungsausschusses, dass das notwendige Knowhow und die Erfahrungen in das Projekt einbringt, damit die geforderten Lieferergebnisse erzielt werden. Gleichzeitig stellt er die Lieferantenressourcen zur Verfügung. Projektmanager: Die Person, der die Verantwortung für das Tagesgeschäft des Projekts innerhalb definierter Toleranzen übertragen wurde. Die Rolle des Projektmanagers kann nicht aufgeteilt werden. Projektunterstützung: Die Projektunterstützung ist eine administrative Funktion innerhalb des Projektmanagementteams. Änderungsausschuss: Eine Person oder Gruppe, an die der Lenkungsausschuss die Verantwortung für die Bearbeitung von Änderungsanträgen oder Spezifikationsabweichungen delegieren kann. Projektsicherung (Unternehmens-, Benutzer-, und Lieferantensicherung): Aufgabe des Lenkungsausschusses, der sicherstellen muss, dass das Projekt ordnungsgemäß durchgeführt wird (kann delegiert werden, verantwortlich bleibt jedoch Lenkungsausschuss). Die Projektsicherung muss unabhängig vom Projektmanager sein (Zielkonflikte). Team Manger: Die Person, die die Erstellung der durch den Projektmanager im Arbeitspaket zugewiesenen Produkte in einer angemessenen Qualität und innerhalb eines für den Lenkungsausschuss akzeptablen Zeit- und Kostenrahmens verantwortet. Seite 22 von 72

23 Bei kleineren Projekten können Projektmanager und Teammitglieder sich die Aufgaben der Projektunterstützung teilen. Projektunterstützung und sicherung müssen unbedingt voneinander getrennt werden (Zielkonflikt). Kommunikationsmanagementstrategie: Die im Rahmen des Projekts identifizierten Stakeholder (Interessensvertreter - im Projektmanagementteam und außerhalb) werden übersichtlich in der in Initiieren eines Projekts (IP) zu erstellenden Kommunikationsmanagementstrategie analysiert und dargestellt Lerninhalte Quiz Seite 23 von 72

24 2.3 Qualität Zweck Zweck des Themas Qualität ist die Definition und anschließende Umsetzung der Mittel, mit denen das Projekt Produkte für einen bestimmten Zweck erstellt und ihre Eignung für diesen Zweck überprüft. Das Grundprinzip der Produktorientierung steht als zentraler Gedanke hinter dem verfolgten Ansatz zur Steuerung und Sicherung der Qualität. Es stellt klar, was das Projekt herstellen wird (Umfang) und nach welchen Kriterien die Produkte des Projekts bewertet werden (Qualität). Darüber hinaus beschäftigt sich das Thema mit der kontinuierlichen Verbesserung (Grundprinzip: Lernen aus Erfahrung) während der Projektlaufzeit Qualitätsplanung Zweck der Qualitätsplanung ist die Schaffung einer sicheren Ausgangsbasis für: Einigung des Lenkungsausschusses Kommunikation Steuerung Bei der Qualitätsplanung geht es um die Definition der vom Projekt geforderten Produkte sowie der jeweiligen Qualitätskriterien, die Qualitätsprüfmethoden (einschließlich des Aufwandes für die Qualitätssteuerung und die Produktabnahme) und die Qualitätsverantwortlichkeiten der mitwirkenden Personen Qualitätssteuerung Schwerpunkt der Qualitätssteuerung sind die Techniken und Aktivitäten derjenigen, die bei Abwicklung des Projekts: Die an die Qualität gestellten Anforderungen erfüllen, beispielsweise durch Qualitätsinspektionen oder Tests Nach Möglichkeiten suchen, die Ursache unzureichender Leistungen zu beseitigen, indem sie beispielsweise aus Erfahrung lernen und Prozessverbesserungen einführen Qualitätserwartungen des Kunden Sie sind eine Aussage zu der vom Projektendprodukt erwarteten Qualität und werden zu Beginn von Vorbereiten eines Projekts (SU) festgelegt und definiert. Die wichtigsten Qualitätsanforderungen bestimmen die Auswahl der Projektlösungen und beeinflussen wiederum Planziele des Projekts in Bezug auf Zeit, Kosten, Umfang, Risiken und Nutzen. Seite 24 von 72

25 2.3.5 Qualitätssicherung Unabhängig vom Projektmanagementteam Prüft, ob Lenkung und Management des Projekts dem betreffenden Projekt angemessen sind und ob die Standards und Richtlinien des Unternehmens oder Programms eingehalten werden Die Aktivitäten gehören nicht in den Umfang von PRINCE2, sondern fallen in die Zuständigkeit der Unternehmens- oder Programmorganisation Unabhängige Stelle die kontrolliert, ob die für eine ordnungsgemäße Planung und Steuerung notwendige Organisation und Prozesse vorhanden sind Qualitätskontrollpfad Crown copyright Material is reproduced with permission from OGC Abbildung 7: Qualitätskontrollpfad Seite 25 von 72

26 2.3.7 Qualitätsprüfung Ziele der Qualitätsprüfungstechnik: Überprüfung eines Produkts das in Form eines Dokuments oder in einer ähnlichen Ausführung, auf Einhaltung vordefinierter Qualitätskriterien Einbeziehung wichtiger interessierter Parteien in die Kontrolle der Produktqualität Bestätigung, dass das Produkt fertig gestellt und abnahmebereit ist Einfrieren des Produkts für die Zwecke der Änderungssteuerung Rollen des Qualitätsprüfungsteams Vorsitzender (Verantwortlich für den Ablauf) Produktpräsentator (Stellt das Produkt vor und übernimmt falls notwendig Anschlussarbeiten) Prüfer (Überprüft das Produkt) Prüfungsadministrator (Administrative Unterstützung des Vorsitzenden) Schritte der Qualitätsprüfung Vorbereitung Qualitätsprüfungssitzung Nachbereitung der Prüfung Eine Qualitätsprüfung ist die systematische und strukturierte Beurteilung eines Produkts, die von zwei oder mehr sorgsam ausgewählten Personen (Prüfungsteam) geplant, dokumentiert und organisiert wird Qualitätsprüfungstechnik Die Qualitätsprüfungstechnik ist eine Technik zur Kontrolle der Qualität mit definierten Rollen und einem strukturierten Ablauf. Mit dieser Technik wird festgestellt, ob ein Produkt, das in Form eines Dokuments (oder in ähnlicher Form, beispielsweise als Präsentation) vorliegt, vollständig ist, bestimmte Standards einhält und die in der zugehörigen Produktbeschreibung vereinbarten Qualitätskriterien erfüllt. Durchgeführt wird die Qualitätsprüfung von Personen, die über die notwendige Fachkompetenz zur Beurteilung der Eignung für den Verwendungszweck verfügen Lerninhalte Seite 26 von 72

27 Quiz Seite 27 von 72

28 2.4 Pläne Zweck Zweck des Themas Pläne ist es, zur Unterstützung der Kommunikation und Steuerung zu definieren, wie die Produkte geliefert werden, was, wo und wie, von wem und voraussichtlich wann und mit welchen Kosten erreicht werden soll. Das Thema Pläne unterstützt dabei drei PRINCE2-Prinzipien: Produktorientierung durch Produktbasierte Planung Steuern nach dem Ausnahmeprinzip durch Erstellung von Toleranzen Steuern über Managementphasen durch Erstellung verschiedener Planungsebenen Planungsebenen Crown copyright Material is reproduced with permission from OGC Abbildung 8: Planungsebenen PRINCE2 kennt 3 Planungsebenen. Der Ausnahmeplan wird nur auf Anforderung des Lenkungsausschusses nach Antrag erstellt und ersetzt (wenn er durch den Lenkungsausschuss abgenommen wurde) den jeweiligen Phasenplan (deshalb gibt es auch nur drei Planungsebenen) Erstellung von Plänen Zuerst wird festgestellt, welche Produkte man benötigt. Dann werden die Aktivitäten, Abhängigkeiten und Ressourcen für die Lieferung dieser Produkte festgelegt (Produktbasierte Planung). Die produktbasierte Planung wird bei der Erstellung aller PRINCE2 Pläne verwendet. Seite 28 von 72

29 Notwendigen Aktivitäten und Zeitpläne, sowie die Aufbereitung, werden in einzelnen Planungsschritten daraus abgeleitet Übersicht der Planung Übersicht Produktbasierte Planung Crown copyright Material is reproduced with permission from OGC Abbildung 9: Übersicht der Planung Crown copyright Material is reproduced with permission from OGC Abbildung 10: Übersicht Produktbasierte Planung Seite 29 von 72

30 Die produktbasierte Planung ist eine Technik zur Erstellung eines umfassenden Plans, der auf der Erstellung und Lieferung von benötigten Outputs basiert. Dieser Planungsansatz orientiert sich an den benötigten Produkten, den Qualitätsanforderungen und den Abhängigkeiten der Produkte untereinander Beispiel für einen Produktstrukturplan Ein Produktstrukturplan unterscheidet nach: Crown copyright Material is reproduced with permission from OGC Abbildung 11: Beispiel Produktstrukturplan Produkt: einzeln zu erstellendes Produkt (durch das Projekt) Externes Produkt: Produkt welches nicht im Rahmen des Projekts entsteht (unbeeinflussbar) Produktgruppe: Zusammenfassung mehrerer Produkte zur besseren Darstellung ACHTUNG: Produktgruppen tauchen in einem Produktflussdiagramm nicht mehr auf! Lediglich im Produktstrukturplan sind sie wegen der Übersichtlichkeit vorhanden. Hinweis: Auch andere Darstellungsformen eines Produktstrukturplans sind denkbar. Die Form wird von PRINCE2 nicht festgelegt. So lässt sich der Produktstrukturplan z.b. als Mind Map abbilden Produktbeschreibung erstellen Sie erläutert den Zweck, die Zusammensetzung und die Ableitung eines Produkts, sowie dessen Qualitätskriterien. Erstellt wird diese Beschreibung während der Planung, sobald festgestellt worden ist, dass ein bestimmtes Produkt benötigt wird. Seite 30 von 72

31 Beispiel für ein Produktflußdiagramm Crown copyright Material is reproduced with permission from OGC Abbildung 12: Beispiel Produktflußdiagramm Aus dem Produktstrukturplan und der Produktbeschreibung lässt sich das Produktflußdiagramm entwickeln Lerninhalte Quiz Seite 31 von 72

32 2.5 Risiken Zweck Zweck des Themas Risiken ist es, Unsicherheiten zu identifizieren, zu analysieren und zu steuern. Als Ergebnis daraus wird die Leistungsfähigkeit des Projekts nachhaltig verbessert. Demzufolge ist ein effektives Risikomanagement eine Voraussetzung, um dem Prinzip Fortlaufende geschäftliche Rechtfertigung gerecht zu werden Definition Risiko Crown copyright Material is reproduced with permission from OGC Abbildung 13: Definition Risiko Ein Risiko ist ein Ereignis (Event), welches (wenn es eintritt) eine Auswirkung auf die Erreichung bestimmter Ziele haben kann. Eine Risikoursache (Cause) kann ein Risikoereignis (Event) auslösen, mit Auswirkung auf ein Projektziel (Effekt). Ein Risiko kann negative (Bedrohung) oder positive (Chance) Auswirkungen haben Ablauf des Risikomanagements Crown copyright Material is reproduced with permission from OGC Abbildung 14: Ablauf des Risikomanagements Seite 32 von 72

33 Als wichtige Komponente wird das Kommunizieren angesehen. Deshalb steht es als Bindeglied zwischen den Prozessschritten im Mittelpunkt. Alle Ergebnisse werden im Risikoregister dokumentiert (formale Behandlung) Definitionen Risikoprofil (Matrix): eine übersichtliche Beschreibung der Risiken Risikotoleranzgrenze: Risiken oberhalb der Grenze werden ohne Maßnahmen nicht akzeptiert. Ziel muss es sein, dass solche Risiken nach Auswirkung und/oder Wahrscheinlichkeit minimiert werden. Risikotoleranz: Grenzwerte der Risikobelastung (z.b. Gesamtheit der Risiken, Bedrohungen) Risikobereitschaft: Die Bereitschaft einer Organisation, Risiken einzugehen. Risikoeigentümer: Eine Person, die für das Management, die Überwachung und die Kontrolle aller Aspekte eines bestimmten Risikos verantwortlich ist Risikobehandler: Eine Person, die für eine Risikomaßnahme verantwortlich ist. Wahrscheinlichkeit: Mit welcher Wahrscheinlichkeit ein Risiko eintritt. Auswirkung: Welche Auswirkung (hoch oder gering) das Risiko auf das Erreichen der Projektziele hat. Eintrittsnähe: Wann wird das Risiko eintreten? Die Auswirkung von Bedrohungen und Chancen kann sich im Projektverlauf verändern! Behandlung von Bedrohungen Vermeiden: Die Bedrohung hat keine Auswirkung oder besteht nicht mehr. Reduzieren (Wahrscheinlichkeit und/oder Auswirkung): Proaktive Maßnahme, um die Wahrscheinlichkeit/Auswirkung des Risikos zu vermindern. Eventualfall (Wahrscheinlichkeit und/oder Auswirkung): Definiert Maßnahmen die ergriffen werden, wenn das Risiko eingetreten ist. Übertragen (reduziert nur die Auswirkung, oft nur finanzielle Auswirkung): Eine dritte Partei übernimmt einen Teil der Verantwortung für die finanzielle Auswirkung. Teilen: Gain-Pain-Sharing-Modell, Verluste werden geteilt. Akzeptieren: Bewusste Entscheidung, die Bedrohung bestehen zu lassen ohne Maßnahmendefinition Behandlung von Chancen Ergreifen: Die Chance wird zugunsten eines günstigen Ereignisses ergriffen. Steigern: Proaktive Maßnahmen werden ergriffen, um ein positives Ereignis wahrscheinlicher zu machen. Teilen: Gain-Pain-Sharing-Modell, Gewinne werden geteilt. Ablehnen: Man hat sich aus ökonomischen Gründen entschieden, eine Chance nicht wahrzunehmen. Seite 33 von 72

34 2.5.7 Risikobudget Vorab beschlossener Betrag im Rahmen des Projektbudgets Um ein Risikobudget planen zu können, ist es notwendig im Rahmen des Risikomanagements alle finanziellen Aspekte zu betrachten Das Risikobudget ist optional In der Regel ist das Risikobudget Bestandteil des Projektbudgets, es wird jedoch gesondert ausgewiesen Beispiel einer Risikomatrix Crown copyright Material is reproduced with permission from OGC Abbildung 15: Beispiel einer Risikomatrix In einer Risikomatrix lassen sich die einzelnen Projektrisiken übersichtlich, nach Wahrscheinlichkeit und Auswirkung, aufzeigen. Das Profil zeigt die aktuelle Situation der Risiken zu einem bestimmten Zeitpunkt ein Snapshot der Projektrisiken aus dem Risikoregister. Risiken oberhalb der Risikotoleranzgrenze werden dem Lenkungsausschuss zur Entscheidung vorgelegt. Seite 34 von 72

35 2.5.9 Lerninhalte Quiz Seite 35 von 72

36 2.6 Änderung Zweck Zweck des Themas Änderungen ist es, jede potenzielle und genehmigte Änderung zu identifizieren, zu bewerten und zu steuern. Es ist das Verfahren mit dem sichergestellt wird, dass alle Änderungen mit Auswirkungen auf die vereinbarten Ziele des Projekts identifiziert, analysiert und entweder genehmigt, abgelehnt oder zurückgestellt werden. Das Thema Änderungen beinhaltet das Offene Punkte- und Änderungsmanagement, sowie das Konfigurationsmanagement Typen von Offenen Punkten Offene Punkte sind Ereignisse, die eingetreten sind und gemanagt werden müssen. Dabei handelt es sich um: Änderungsanträge, Spezifikationsabweichungen, Probleme/Anliegen. Offene Punkte können formal (Offene Punkte Bericht/Register) oder formlos (Projekttagebuch) behandelt werden Definitionen Änderungsausschuss: Person, an die der Lenkungsausschuss die Verantwortlichkeit für die Bearbeitung von Änderungsanträgen oder Spezifikationsabweichungen delegieren kann. Dem Ausschuss kann ein Änderungsbudget zugeteilt werden, das er nur für derartige Änderungen verwenden kann. Änderungsbudget: Die Mittel, die dem Änderungsausschuss für die Durchführung genehmigter Änderungen zur Verfügung gestellt werden (wird in der Regel getrennt vom Projektbudget ausgewiesen). Konfigurationsmanagement: Technische und administrative Aktivitäten im Zusammenhang mit der Erstellung, Pflege und kontrollierten Änderung der Konfiguration während der Lebensdauer eines Produkts. Konfigurationsmanagementstrategie: Beschreibung, wie und von wem die Produkte eines Projekts gesteuert und geschützt werden. Konfigurationsdatensatz: Eine Aufzeichnung, die den Status, die Version und die Variante eines Konfigurationselements beschreibt sowie Details wichtiger Verbindungen zu anderen Konfigurationselementen. Produktstatusauskunft: Ein Bericht über den Status von Produkten (z.b. Produkt fertiggestellt, ). Seite 36 von 72

37 2.6.4 Offene Punkte und Änderungssteuerungsprozedur Erfassen (Art des offenen Punkts und Schweregrad/Prio festlegen, Protokollieren) Untersuchen (Auswirkungen auf Ziele, Business Case, und Risikoprofil bewerten; Schweregrad/Prio prüfen) Vorschlagen (Optionen identifizieren, beurteilen, empfehlen) Entscheidung treffen (Eskalieren, Empfohlene Option genehmigen, ablehnen oder aufschieben) Implementieren (Korrekturmaßnahme einleiten, Aufzeichnungen und Pläne aktualisieren) (Ggf. noch Grafik entwickeln!!) Lerninhalte Quiz Seite 37 von 72

38 2.7 Fortschritt Zweck Zweck des Themas Fortschritt ist es, einen Mechanismus bereitzustellen, um bisher Erreichtes zu kontrollieren und gegen die Planung abzugleichen, einen Ausblick auf die zu erreichenden Ziele und die weitere Durchführbarkeit des Projekts zu gewährleisten und jegliche nichtgewünschte Abweichung zu regeln. Das Thema Fortschritt unterstützt mit seinen Steuerungsmitteln vor allem die drei Grundprinzipien: Steuern nach dem Ausnahmeprinzip durch Vergabe von Toleranzen Lernen aus Erfahrung durch Erstellung und Pflege von Erfahrungsprotokollen und Berichten sowie deren Integration in die Bewertung von Phasenabschlüssen Steuern über Managementphasen durch Definition von Managementphasen Phasen zur Projektsteuerung Ein PRINCE2-Projekt wird in Phasen gegliedert. Diese Phasen werden als Managementphasen (im Gegensatz zu Technischen Phasen Fertigstellung eines Produkts oder einer Aktivität) bezeichnet. Es sind Zusammenstellungen von Produkten und Aktivitäten, welche gemeinsam bereitgestellt werden und in einen Entscheidungspunkt münden und der Abschnitt des Projekts, dessen Management der Projektmanager im Auftrag des Lenkungsausschusses ausführt. Das Ende einer Managementphase ist der Punkt, an dem der Lenkungsausschuss den Projektfortschritt, Projektplan, Business Case und Risiken überprüfen möchte, sowie den nächsten Phasenplan prüft, um zu entscheiden, ob das Projekt fortgeführt werden soll. ACHTUNG: Ein PRINCE2 Projekt besteht immer aus mindestens 2 Phasen: Einer Initiierungsphase und Ausführungsphase! Die Dauer von einzelnen Phasen ist maßgeblich beeinflusst durch: Den möglichen Planungshorizont Die technischen Phasen im Rahmen des Projekts Ausrichtung an Aktivitäten des Programmmanagements Höhe des Risikos Ausnahmen und Toleranzen zur Projektsteuerung Die zulässige Abweichung von den Zeit- und Kostenvorgaben eines Plans, die ohne sofortige Eskalation an die nächsthöhere Managementebene akzeptiert werden kann (ebenfalls können Toleranzen für Qualität, Umfang, Nutzen und Risiko definiert werden). Toleranzen kommen auf Projekt-, Phasen- und Teamebene zur Anwendung Eine Situation, in der eine Abweichung über die zwischen Projektmanager und Lenkungsausschuss vereinbarten Toleranzgrenzen hinaus vorhersehbar ist Seite 38 von 72

39 2.7.4 Toleranzen und Eskalationen Crown copyright Material is reproduced with permission from OGC Abbildung 16: Toleranzen und Eskalationen Das Grundprinzip Management nach dem Ausnahmeprinzip verwendet die sechs Toleranztypen (Kosten, Zeit, Qualität, Umfang, Risiko, Nutzen) auf den vier Ebenen des Projektmanagementteams. Diese werden nach dem Top-Down Prinzip vergeben. Ein Report bzw. Eskalation läuft in entgegengesetzter Richtung ab Steuerungsmittel des Lenkungsausschusses Autorisierung bei: Initiierung freigegeben, Projekt freigegeben, Phasen- oder Ausnahmeplan freigegeben, Projektabschluss freigegeben Projektstatusbericht Projektabschlussbericht Ausnahmebericht Offener-Punkt-Bericht Steuerungsmittel des Projektmanagers Autorisierung bei: Arbeitspakete freigegeben Arbeitspakete Teamstatusberichte Projekttagebuch Erfahrungsprotokoll und Erfahrungsbericht Register offener Punkte Qualitätsregister Risikoregister Seite 39 von 72

40 2.7.7 Definitionen Ereignisgesteuerte Steuerungsmittel: Kommt beim Auftreten eines bestimmten Ereignisses zum Einsatz (z.b. das Ende einer Phase, Vervollständigung der Projektleitdokumentation, Termine im Betriebsablauf). Zeitgesteuerte Steuerungsmittel: Dies sind Berichte, die der nächst höheren Managementebene in regelmäßigen Abständen für die Überwachung des Fortschritts zur Verfügung gestellt werden. In PRINCE2 werden zwei zeitgesteuerte Statusberichte erstellt: Der Teamstatusbericht und der Projektstatusbericht Lerninhalte Quiz Seite 40 von 72

41 3 PROZESSE 3.1 Vorbereiten eines Projekts Crown copyright Material is reproduced with permission from OGC Abbildung 17: Vorbereiten eines Projekts (SU) Zweck Handelt es sich in diesem Fall um ein durchführbares und lohnendes Projekt Inhalt Als Ausgangsbasis für ein Projekt wird ein Auftrag aus einer Organisation (Unternehmes- oder Programmmanagement) benötigt: Das Projektmandat. Es enthält verbindliche Informationen, die der Auslöser für Vorbereiten eines Projekts (SU) sind. Die Angaben sollten ausreichen, um zumindest den zukünftigen Auftraggeber des Lenkungsausschusses und den Gegenstand des Projekts erkennen zu können. Ebenfalls liefert es die Grundlage für die Erstellung der Projektbeschreibung. Um dem Lenkungsausschuss eine endgültige Projektinitiierungsentscheidung zu ermöglichen, erstellt Vorbereiten eines Projekts (SU) eine Projektbeschreibung und einen ersten Entwurf des Business Cases. Seite 41 von 72

42 3.1.3 Ziele Sicherstellen, dass eine Projektinitiierung wirtschaftlich gerechtfertigt ist Verantwortlichkeiten und Vollmachten festlegen sowie wichtige Rollen besetzen Definition und Beschreibung des Projekts Festlegung eines Projektlösungsansatzes Planung der anfallenden Arbeiten der Initiierungsphase Projektannahmen (Akzeptanzkriterien, Einschränkungen) für eine kommende Projektinitiierung identifizieren und sichern Aktivitäten Auftraggeber und Projektmanager ernennen Vorhandene Erfahrungen erfassen Business Case Entwurf erstellen Projektmanagementteam entwerfen und verpflichten Projektlösungsansatz und Projektbeschreibung zusammenstellen Initiierungsphase planen Dokumente Projektmandat erstellen (Unternehmen) Projekttagebuch erstellen (Projektmanager) Rollenbeschreibung Auftraggeber und Projektmanager erstellen (Auftraggeber in Abstimmung mit dem Unternehmen) Rollenbeschreibung Projektmanagementteam (Projektmanager) Erfahrungsprotokoll erstellen (Projektmanager) Business Case Entwurf erstellen (Projektmanager) aus: Zusammenfassung erster Aspekte für das Warum Definition von Ziele, Gründe, Finanzierung Projektendproduktbeschreibung erstellen mit Kundenqualitätserwartungen, Akzeptanzkriterien, wichtigste Meilensteine Projektlösungsansatz erstellen (Projektmanager) Projektbeschreibung erstellen (Projektmanager) aus: Projektdefinition (Ziele, Umfang, Ausschüsse, Schnittstellen, Kunden, ) Projektlösungsansatz Business Case-Entwurf Projektendproduktbeschreibung Organigramm der Rollen Rollenbeschreibung Initiierungsphasenplan erstellen (Projektmanager) Seite 42 von 72

43 3.1.6 Lerninhalte Quiz Seite 43 von 72

44 3.2 Lenken eines Projekts Zweck Crown copyright Material is reproduced with permission from OGC Abbildung 18: Lenken eines Projekts (DP) Sicherstellung des Projekterfolgs durch Schlüsselentscheidungen auf oberster Lenkungsebene Der Prozess Lenken eines Projekts ermöglicht dem Lenkungsausschuss das Wahrnehmen der Ergebnisverantwortung im Projektverlauf Inhalt Der Prozess Lenken eines Projekts (DP) startet mit Abschluss des Prozesses Vorbereiten eines Projekts (SU) und wird durch den Antrag auf Projektinitiierung angestoßen. Er beschreibt die Aktivitäten auf Managementebene, nicht die Aktivitäten im Tagesgeschäft des Projektmanagers. Dabei steht das Grundprinzip Management nach dem Ausnahmeprinzip im Vordergrund. Der Lenkungsausschluss überwacht den Projektverlauf über Berichte und steuert über eine geringe Anzahl wichtiger Entscheidungspunkte (u.a. geplante Zeitpunkte und gemeldete Ausnahmen). Gleichzeitig wird über den Lenkungsausschuss eine Kommunikationsschnittstelle zum Unternehmens- oder Programmmanagement hergestellt. Über Lenken eines Projekts (DP) kann der Lenkungsausschuss die wirtschaftliche Ausrichtung des Projekts sicherstellen und übernimmt sowohl Aufgaben für informelle Beratung und Anleitung des Projektmanagers (falls nötig), als auch formelle Lenkungsaufgaben. Seite 44 von 72

45 3.2.3 Ziele Kompetenzen zur Freigabe der Projektinitiierung Zugewiesene Kompetenzen zur Produktlieferung Das Projekt wird über die gesamte Projektlaufzeit gesteuert und überwacht Die Wirtschaftlichkeit des Projekts ist stets gewährleistet Die Schnittstelle zum Unternehmens- oder Programmmanagement gegeben ist Kompetenzen für den Abschluss des Projekts vorhanden sind Pläne zur Nutzenrealisierung werden gemanagt und geprüft Aktivitäten Initiierungsphase freigeben Projekt freigeben Lenkungsausschuss prüft: Es existiert ein belastbarer, realistischer und gerechtfertigter Business Case Der Projektplan unterstützt die Realisierung des Business Cases Die Strategien und Steuerungsmittel unterstützen die Umsetzung des Projektplans Es sind Mechanismen zur Messung und Überprüfung des erwarteten Nutzens erstellt und geplant worden Phasen- oder Ausnahmeplan freigeben Ad-hoc Anweisungen geben Projektabschluss freigeben Dokumente Projektlösungsansatz freigeben (Auftraggeber) Initiierungsphasenplan freigeben (Auftraggeber) Projektleitdokument freigeben (Auftraggeber) Phasenplan freigeben (Auftraggeber) Ausnahmeplan freigeben (Auftraggeber) Nutzenrevisionsplan freigeben (Auftraggeber) Phasenabschlussbericht freigeben (Auftraggeber) Projektabschlussbericht freigeben (Auftraggeber) Lerninhalte Seite 45 von 72