PRINCE 2 - Methodik und Bewertung

Aus Winfwiki

Autoren:	Peter Becker, Ismail Er, Arthur Kowalski
Kontakt:	prince2.fom@public-files.de
Hochschule:	FOM Essen

Inhaltsverzeichnis 1 Abkürzungsverzeichnis 2 Tabellenverzeichnis 3 Abbildungsverzeichnis 4 Vorwort 5 Einführung in PRINCE2 5.1 Projekt - die Definition 5.2 Zweck der Projektmanagementmethoden 5.3 PRINCE2 - auf den Punkt gebracht 5.4 Entstehungsgeschichte 5.5 Vorteile der PRINCE Methodik 5.6 Anwendungsbereich von PRINCE2 6 Grundlagen 6.1 PRINCE2 Übersicht 6.2 PRINCE2 Projektstruktur 6.3 PRINCE2 Strukturelemente 7 Komponenten 7.1 Business Case 7.1.1 Übersicht und Beschreibung 7.1.2 Soll - Inhalte 7.1.3 Entwicklung und Bestimmung des Pfades 7.2 Organisation 7.2.1 Übersicht 7.2.2 Die vier Management-Ebenen 7.2.3 Projektmanagementstruktur 7.2.4 Die Drei Parteien 7.2.5 Projektunterstützung 7.3 Pläne 7.3.1 Definition 7.3.2 Planungsebenen 7.3.3 Vorteile der Planung 7.4 Steuerung 7.4.1 Übersicht 7.4.2 Zweck der Kontrolle 7.4.3 Kontrollierter Projektstart 7.4.4 Kontrollierter Projektablauf 7.4.5 Kontrollierter Projektabschluss 7.5 Risiko Management 7.5.1 Definition 7.5.2 Risikoarten 7.5.3 Grundsätze 7.6 Qualität der Projektumgebung 7.6.1 Qualitätsdefinition 7.6.2 Qualitätsmanagement 7.6.3 Qualitätsarbeit 7.7 Konfigurationsmanagement 7.7.1 Definition 7.7.2 Grundlinie 7.7.3 Konfigurationsmanagementplan 7.8 Änderungssteuerung 7.8.1 Ziel und Zweck 7.8.2 Feststellung von Änderungen 7.8.3 Änderungsintegrität 7.9 Phasen 8 Prozesse 8.1 Einführung in die Prozesse 8.1.1 PRINCE2 Prozessmodell 8.2 Projektvorbereitung (SU) 8.2.1 Beschreibung und Kontext 8.2.2 Subprozesse 8.3 Projektinitiierung (IP) 8.3.1 Beschreibung und Kontext 8.3.2 Subprozesse 8.4 Projektdirigierung (DP) 8.4.1 Beschreibung und Kontext 8.4.2 Subprozesse 8.5 Steuern einer Phase (CS) 8.5.1 Beschreibung und Context 8.5.2 Subprozesse 8.6 Managen der Produktlieferung (MP) 8.6.1 Beschreibung und Kontext 8.6.2 Subprozesse 8.7 Managen der Phasenübergänge (SB) 8.7.1 Beschreibung und Kontext 8.7.2 Subprozesse 8.8 Projektabschluss (CP) 8.8.1 Beschreibung und Kontext 8.8.2 Subprozesse 8.9 Projektplanung (PL) 8.9.1 Beschreibung und Kontext 8.9.2 Subprozesse 9 Techniken 9.1 Änderungssteuerung 9.2 Qualitätsprüfungen 9.3 Produktbasierte Planung 10 PRINCE2 Refresh 2009 11 Schlussbetrachtung 12 Fußnoten 13 Literatur- und Quellenverzeichnis

1 Abkürzungsverzeichnis

Abkürzung	Bedeutung
CCTA	Central Computer and Telecommunications Agency
CP	Abschließen eines Projekts / Closing a Project
CS	Steuern einer Phase / Controlling a Stage
DP	Lenken eines Projekts / Directing a Project
ESA	End Stage Assessment / Endphasenbewertung
IP	Initiieren eines Projekts / Initiating a Project
LBMS	Learmonth & Burchett Management Systems
MP	Managen der Produktlieferung / Managing Product Delivery
OGC	Office of Government Commerce
PID	Project Initiation Document
PL	Planen / Planing
PRINCE	Projects IN Controlled Environments
Project Board	Lenkungsausschuss
PROMPT	Project Resource Organisation Management Planning Technique
QMS	Qualität Management System
SB	Managen der Phasenübergänge / Managing Stage Boundaries
SSADM	Structured System Analysis and Design Methodology
SU	Vorbereiten eines Projekts / Starting up a Project

2 Tabellenverzeichnis

Tab.-Nr.	Tabelle
01	Zusammenfassung des Models von PRINCE2 Methoden
02	PRINCE2 Änderungen 2009

3 Abbildungsverzeichnis

Abb.-Nr.	Abbildung
01	Attribute eines Projektes
02	Produkt- und Projektlebenszyklus
03	PRINCE2, Beziehungen zwischen Projekt und Business
04	PRINCE2, Prozesse und Komponenten
05	Darstellung des Eingangs und Ausgangs für ein Projekt
06	Komponenten und Prozesse
07	Business Case Entwicklungsplan
08	Die Projektmanagement-Struktur
09	Die drei Parteien
10	Planungsebenen
11	Steuerungskreislauf
12	Management- und technische Phasen
13	Risikomanagement
14	Der Balanceakt zwischen Risiko, Kosten und Zeit und dem Nutzen, welchen der Kunde erhält
15	PRINCE2 Prozessmodel

4 Vorwort

Diese Fallstudie befasst sich mit dem Thema: PRINCE2 - Methodik und Bewertung. Sie entsteht auf Grund der Projektarbeit im Fach der Fallstudie I des 5. Semesters (2008/2009), Wirtschaftsinformatik in der Fachhochschule für Oekonomie & Management in Essen unter Aufsicht von Herrn Professor Dr. Uwe Kern.

Sie ist entstanden als eigenständig organisierte Gruppenarbeit von den o.g. Autoren unter Berücksichtigung folgenden Zeitplans:

Termin	Meilenstein
12.09.2008	Eröffnung
15.09.2008	Themenvergabe
14.11.2008	Zwischenbesprechung
23.01.2009	Text und Präsentation
30.01.2009	Präsentation

PRINCE2 hat sich in den letzten Jahren als Projektmanagement-Methode mit weltweit über 200.000 zertifizieren Projektmanagern etabliert. Jährlich erwerben ca. 10.000 Projektmanager eine PRINCE2 Zertifizierung. In diesem Jahr erfolgt mit "Refresh 2009" eine weitreichende Überarbeitung der Methode. Die Zielsetzung der Fallstudie besteht darin, die angewandte Methodik zu untersuchen, darzustellen und zu bewerten.

Es gibt drei grundsätzliche Zielsetzungen bei der Erstellung dieser Arbeit:

1. Aktive und selbständige Erkundung, Untersuchung und Erarbeitung der Projekt-Management-Methoden nach den PRINCE2 Richtlinien von CCTA.
2. Verfolgung von eigenen Interessen, welche für die Zukunft, in der die Durchführung von Projekten eine sehr bedeutsame Rolle spielen können
3. Eine 15-minütige Abschlusspräsentation

PROMPT, PRINCE und PRINCE2 sind eingetragene Markenzeichen der CCTA (Central Computer and Telecommunications Agency) . In dieser Arbeit werden alle Anstrengungen unternommen, um eine Verletzung des Copyrights des Inhabers zu vermeiden.

5 Einführung in PRINCE2

5.1 Projekt - die Definition

Definition des Begriffs "Projekt" (lat. "proicere" = entwerfen) unter PRINCE2 lautet wie folgt:

"a management environment that is created for the purpose of delivering one or more business products according to a specified business case". ^[1]

Nach DIN 69901 wird das Projekt als ein Vorhaben definiert, bei dem innerhalb einer festgelegten Zeitspanne und bestimmter Ressourcen ein festgelegtes Ziel erreicht werden soll. Es zeichnet sich dadurch aus, dass es im Wesentlichen ein einmaliges Vorhaben ist. ^[2]

Ein Projekt nach PRINCE2 zeichnet sich durch folgende Charakteristik aus:

• zeitlich definiert und befristet
• definiertes und messbares Endprodukt
• Satz von miteinander verknüpften Aktivitäten zur Erreichung des Endproduktes
• definierte und begrenzte Ressourcen
• organisierte Struktur mit definierten Aufgaben zur Steuerung des Projektes

Grundsätzlich gilt das Projekt als beendet und aufgelöst, wenn die Arbeit vollbracht ist. Vor diesem Hintergrund unterscheidet man zwischen Produktlebensdauer und Projektzyklusdauer.

Die Produktlebensdauer erstreckt sich von der Idee, über Entwicklung und Entstehung bis hin zur Einstellung des Produktes. Der Projektlebenszyklus deckt u.a. folgende Aufgaben ab: Spezifizierung, Design, Entwicklung und Test bis zur Inbetriebnahme. Genau mit diesem Zyklus inkl. einiger Projektvorbereitungen beschäftigen sich die PRINCE2-Methoden.^[5]

5.2 Zweck der Projektmanagementmethoden

Es ist nichts Ungewöhnliches, dass viele Projekte scheitern. Die Gründe hierfür sind sehr verschieden. Einige gemeinsame Ursachen lassen sich wie folgt auflisten:

• Mangelnde Koordination der verfügbaren Ressourcen und Aktivitäten
• Schlechte Kommunikation zwischen beteiligten Parteien
• Falsche Abschätzung der Dauer und Kosten
• Schlechtes Monitoring
• Unzureichende Planung der Ressourcen, Aktivitäten und des zeitlichen Verlaufes
• Fehlende Kontrolle des Projektverlaufs
• Unrealistische Finanzierung
• Fehlende Qualitätskontrolle
• Unzureichende Flexibilität

Projektmanagementmethoden haben das Ziel, ein Projekt durch kontrollierte, managebare und klar erkennbare Aktivitäten zu führen, um das gewünschte Endprodukt wie geplant zu erreichen.
Neben den typischen Merkmalen, die bereits unter Punkt 2.1. erwähnt wurden, ist eine grundsätzliche Voraussetzung für ein erfolgreiches Projekt das Engagement aller Beteiligten. Allen Beteiligten muss die Wichtigkeit und der Zweck des Vorhabens klar sein. Der gewünschte Erfolg hängt unmittelbar von der Verantwortung des Einzelnen ab.^[6]

Das besondere von Prince2 ist, dass die Prozesse und die Verfahren schon in der Praxis erfolgreich erprobt wurden. Diese Methodik beschreibt nur, was gemacht werden muss, aber nicht wie es umgesetzt werden soll. Damit werden dem Projektteam Spielräume geschaffen, die Methoden und deren Verfahrensweise anzuwenden.^[7]

5.3 PRINCE2 - auf den Punkt gebracht

Um vorerst eine mögliche Vorstellung von PRINCE2 zu bekommen, schließen wir zunächst aus, was PRINCE2 nicht ist:

• PRINCE2 ist keine spezielle Software.
• Es ist auch kein Projektmanagementwerkzeug wie z.B. das bekannte MS Projekt.
• Es ist keine spezielle Bürokratie in Projekten und es ist nicht begrenzt auf große IT Projekte.
• Ebenso ist es keine Durchführung von Projekten nach einem strikten und genauen Plan.
• Keine Garantie für den Erfolg eines Projektes.

Vereinfacht gesagt, PRINCE2 ist eine Vorschrift mit Projektmanagementmethoden, das ursprünglich von der CCTA erstellt wurde. Es beinhaltet detaillierte Beschreibungen von strukturierten Methoden, deren Verwaltung sowie deren Beendigung unabhängig von Art und Große. ^{[8] [9]}.

Die Abkürzung PRINCE steht für PRojects IN Controlled Environments, d.h. Projekte in überwachter und gesteuerter Umgebung. Die Anwendung dieser Methoden ist lizenzfrei erlaubt.^[10] PRINCE2 ist de-facto Standard in Großbritannien. Ebenso ist PRINCE2 vom privatem Sektor anerkannt und wird sowohl in Großbritannien als auch international angewandt.^[11]. Mit weltweit mehr als 200.000 zertifizierten Projektmanagern zählt PRINCE2 zu den etablierten Methoden im Projektmanagement.

5.4 Entstehungsgeschichte

Die Wurzeln von PRINCE2 reichen bis in das Jahr 1975. Die Firma Simpact System Limited entwickelte ein Rahmenwerk von Methoden des Projektmanagements, genannt PROMPT. Diese Methoden hatten als Ziel das allgemeine und oberflächliche Management von sehr großen IT-Projekten. ^[12]

Im Jahre 1984 wurde PROMPT von der Regierung von Großbritannien eingesetzt. PROMPT wurde in vielen Bereichen der Regierung, wo zu dieser Zeit IT Projekte in besonderem Umfang verliefen, eingeführt. Diese Methoden sollten das Management und die Kontrolle über die Projekte verbessern.

Die PROMPT-Methodik bestand aus fünf Hauptkomponenten:

PROMPT I – Strategische Planung
PROMPT II – Systementwicklung
PROMPT III – Betrieb, Wartung und Erweiterung
QSTAR – Qualitätssicherung
PROMPT – Werkzeuge für Softwareunterstützung

CCTA, die für die Regierung tätig war, beauftragte eine Verbindung zwischen QSTAR und PROMPT II und lieferte das Produkt "Regierung PROMPT". Die Behörde lizenzierte zwar alle fünf o.g. Methoden, jedoch nur PROMPT II wurde vollständig in das "Regierung PROMPT" implementiert.

Im Jahr 1987 wurde eine Aktualisierung der Methodik von PROMPT II durch die CCTA beschlossen. Im Fokus war die Einführung moderner Projektmanagement-Ideen, wie Grundlegende Produktplanung, formale Prozedur der Projektinitiation, Rolle des Projektmanagers, schärfere Konzentration auf Qualitätsmanagement und Planung der Lebenszyklen.

Die CCTA war bestrebt, die erweiterten Methoden als offenen Standard mit der Absicht zu erklären, dass die wichtigsten Lieferanten von IT Systemen diese Projektmanagementmethodik einhalten, während der Erfüllung von Verträgen mit der Regierung. LBMS (Learmonth & Burchett Management Systems), ein bedeutendes Beratungsunternehmen, das von der CCTA beauftragt wurde, das SSADM (Structured System Analysis and Design Methodology) Verfahren zu entwickeln, erwarb die PROMPT-Produkte und den Namen von Simpact Systems. Anschließend wurden diese Methoden als lizenzfrei definiert und für den privaten Sektor zugängig gemacht. Da diese erweiterten Methoden nicht mit dem Namen PROMPT II ersetzt werden durften, wurden diese zu PRINCE umbenannt.

PRINCE wurde somit im April 1989 mit vollständiger Dokumentation eingeführt und die offizielle Freigabe für den „public domain“ fand im Januar 1990 statt. Seit diesem Zeitpunkt ist PRINCE als offizielle Norm für das Management aller wichtigen Projekte innerhalb der Regierung Großbritanniens verbindlich. Der Standard wurde schnell vom privaten Sektor angenommen und sowohl für Regierungsprojekte als auch für eigene und unternehmensinterne Vorhaben verwendet.

Die CCTA verfolgen in Zusammenarbeit mit der „The Association for Project Management Group“, IBM UK Limited and The Stationary Office die Akzeptanz von PRINCE als „weltweit bestes Verfahren“ für Projektmanagement.

Im Oktober 1996 startete die Version 2 von PRINCE – PRINCE2. Nach zweijähriger Entwicklung und Konsultation anderer Organisationen wurde PRINCE „prozessorientierter“. D.h. in den Vordergrund traten die Eigenschaften WAS und WARUM, weniger jedoch das WIE. Damit wurde die Basis für Projekte um nicht nur IT-Projekte erweitert, sondern auch um Verfahren für kleine Projekte, Programmers of Work, ect.

IBM UK Limited, einer der wichtigsten Partnern der CCTA, entwickelte Software, die die gesamte Umgebung zur Umsetzung von PRINCE2 beinhalten.

Mit PRINCE2 wurde auch Akkreditierungs- und Zertifizierungsschema aufgebaut um dem Anwender von PRINC2 Sicherheit zu vermitteln, dass Schulungen und Beratung nur von registrierten Organisationen durchgeführt werden, die ein einheitliches Lehrprogramm und Abschluss gewährleisten.^[13]

Im Jahr 2000 wurde in Kooperation mit CCTA die OGC zum Leben errufen. Seitdem gilt die CTAA nicht mehr als separate Organisation und somit ist auch die Fortsetzung und Weiterentwicklung von PRINCE2 in Händen der OGC. ^[14]

5.5 Vorteile der PRINCE Methodik

PRINCE2 ist eine strukturierte Methode, welche Organisationen in die Lage versetzt, ihre Projekte durch standardisiertes Management voranzutreiben. PRINCE2 liefert durch eine kontrollierte Nutzung von Menschen und Mitteln die Möglichkeit, Betriebs- und Projektrisiken effektiver zu kontrollieren. Somit schafft PRINCE2 klare Vorteile für Manager und Verwalter von Projekten und für Organisationen. PRINCE2 ist durch ein langjähriges Wachstum zur anerkannten „best-practices“ Methode geworden und gewährleistet eine gemeinsame Sprache für alle am Projekt Beteiligten.

Weitere Vorteile sind:

• ein kontrollierter und organisierter Start, effektive Durchführung und zielorientiertes Ende des Projektes
• Regelmässige Reviews des Fortschrittes durch Kontrolle des Projektplanes und des Business Cases
• einer definierten Organisationsstruktur
• Flexible Meilensteine
• automatische Korrektur durch das Management bei Abweichungen vom Plan
• das Hinzuziehen des Managements und der Beteiligten zur richtigen Zeit
• sehr gute Kommunikationskanäle zwischen allen involvierten Projektteilnehmern

Für Projektmanager hat die Methode folgende Vorteile:

• Benutzen einer festgesetzten Struktur für die Delegation, Kommunikation und Autorisierung
• Gewährleisten, dass die Zusage des Managements über die Verfügbarkeit von Ressourcen (Mensch und Mittel) Teil der Autorisierung vor dem Start der

nächsten Phase ist

• Lieferung von regelmäßigen und kurzen Projektfortgangs-Berichten

5.6 Anwendungsbereich von PRINCE2

PRINCE2 steuert:

• das Projekt
• den Einsatz der Belegschaft und Ressourcen
• die Verbindungen und Interaktionen zwischen dem Projekt und der Umgebung.

Hiermit werden nicht alle Aspekte des Projektmanagements abgedeckt. Die Anwendung der Methoden basiert auf gesundem Menschenverstand, den richtigen Techniken und sozialen Fähigkeiten. Zwar sind diese nicht Bestand von PRINCE2, aber es wird an das gewünschte soziale Verhalten (Soft Skills) im Hinblick auf Zielerreichung angelehnt.

Ein wesentlicher Aspekt von PRINCE2 ist die Interaktion. Sie ist verankert in den Aufgaben, Verantwortung und in der Weisungsbefugnis. Die PRINCE2 Methoden können mit anderen Formen und/oder Entwicklungstechnologien kombiniert werden, sogar dann, wenn es sich um ganz andere Verfahren handelt.
Informationen aus verschiedenen Managementdokumenten (mit PRINCE2) vermitteln nahezu ideale Grundlagen für die Vorbereitungen und Überwachung von Verträgen.

6 Grundlagen

6.1 PRINCE2 Übersicht

6.2 PRINCE2 Projektstruktur

Innerhalb der PRINCE2 Projektumgebung müssen folgende Voraussetzungen erfüllt werden:

• Adressierung aller Prozesse mit der Absicht eine effektive Projektmanagementumgebung zu erstellen
• Sicherstellung eines „business case“, wo eindeutig die Vorteile und Risiken beleuchtet sind
• Genaue Definition des Produktes oder Lieferung, das noch nicht existiert.
• das vorhandensein von entsprechend definierten Aktivitäten um das Produkt zu erstellen
• Identifizierung von adäquaten Ressourcen um die Aktivitäten durchzuführen
• Begrenzung der Projektlebensspanne und geeignete Einrichtung der Steuerung
• Identifizierung der Organisationsstruktur mit definierten Zuständigkeiten
• Ein Set von Prozessen mit dazugehörigen Techniken, die über Planung und Steuerung verhelfen das Projekt erfolgreich zu beenden.

Ein PRINCE2 Projekt ist in mehrere Management Stufen aufgeteilt, wobei jede Form eine klare Einheit für Managementzwecke hat. Jede Stufe besteht aus einer Serie von Prozessen, definiert durch einen Satz von Produkten und Aktivitäten mit begrenzter Zeit. Diese bestimmten die Steuerungselemente und Organisationsstruktur. Die Managementstufen werden vervollständig durch vereinbarte Qualitätsstandards. PRINCE2 definiert:

• Organisation des Projektes und dessen Stufen
• Prozesse die vorantreiben das Vorhaben
• Struktur und Inhalt des Projektplans
• Grundlagen der Projektmanagementtechniken
• Ein Satz von Regel zur Sicherstellung und Einhaltung des Projektplans

Diese, zusammen mit den Produkten des Projektes, deren Aktivitäten, Projekt business case und allen enthaltenen QMS (Qualität Management System) Regel, sind Grundlage der PRINCE2 Umgebung. Alle Produkte des PRINCE2 Projektes sind enthalten in definierten Strukturen innerhalb der Konfiguration. Separat aufgeführt sind das Management, die Spezialisten und die Qualitätsprodukte. Das PRINCE2 System liefert die Flexibilität, um die Phasengrenzen zu setzen, welche für das Projekt erforderlich sind. Die Bestimmung der Grenzen hängt von folgenden Kriterien ab:

• Phase der Produktion des Produktes
• Gruppierung der Produkte zu dazugehörigen Prozesse
• Entscheidungspunkte für Kritik und Festlegung von Ressourcen
• Risiken und Anfälligkeit des Projektes
• Abschluss eines oder mehreren getrennten Processe

PRINCE2 erkennt an, dass einige Projekte völlig isoliert betrachtet werden. Das Ende des einen Projektes kann auch als Start des Zweiten benutzt werden. In diesen Fällen entstehen wahrscheinlich andere Abhängigkeiten, als die, die gemeinsame Ressourcen nutzen. Aus diesem Grund liefert PRINCE2 Mechanismen, welche zur Definition der Projektgrenzen und deren Beziehung zu einander herangezogen werden können.

Dieses Diagramm stellt eine Hilfestellung bei Planung und Steuerung des „Programme of Work“, wo individuelle Projekte in Relation mit anderen stehen. Es ist notwendig sicherzustellen, dass der erwartete Ausgang des Projektes mit dem geplanten übereinsteht. ^[18]

6.3 PRINCE2 Strukturelemente

PRINCE2 unterscheidet zwischen drei Arten von Strukturelementen:

• Prozesse
• Komponenten
• Techniken

Prozesse kapseln Aktivitäten und Rollen (Projektbeteiligte) und definieren was (Produkt), wann und durch welche Rolle durchgeführt wird. Die Prozesse befassen sich mit der Fragestellung "Welche Schritte müssen durchlaufen werden?". Komponenten betrachten jeweils einen Projektaspekt, wie beispielsweise Pläne, Risiko oder Qualität. Sie unterstützen die Prozesse in verschiedenen projektrelevanten Aspekten und beschreiben die Voraussetzungen, die geschaffen werden müssen, damit die Projekte erfolgreich funktionieren (Was und Warum?). Schließlich werden zur Umsetzung des Prozessmodells Techniken angeboten, die optional anzusehen sind und somit durch andere Techniken ersetzt werden können. Dabei steht der "Wie gehe ich vor?" und "Welche Arbeitstechnicken helfen als Basis?" - Ansatz im Vordergrund.

In der PRINCE2 Theorie werden acht Prozesse, acht Komponenten und drei Techniken fest definiert und verwendet. Sie bilden somit das Fundament der erfolgreichen Verwendung von PRINCE2 und werden im folgenden Text näher erläutert.

Folgendes Model zeigt die Schlüssel Elemente der Struktur von PRINCE2 Methoden:

Unternehmensstandart & Ziele; Businessstandarts & Ethik Qualitätsmanagementsystem QMS ISO9001

TECHNIKEN	KOMPONENTEN	PROZESSE
Produktgrundplanung - Produktanalyse - Produktbeschreibung - Produktflussdiagram Qualitätsbewertung - Vorbereitung, Bewertung, Nachfolge Änderungscontrolle - Erfassung, Protokollierung, Abschätzung, Endscheidung Projektabwicklungsstruktur - Managementakte - Spezialisierungsakte - Qualitätsakte + existierende unternehmensweite Techniken, die bereits angewendet werden	Organisation - Beschreibung von Rollen u. Struktur Planung - Produkte, Aktivitäten, Ressourcen Steuerung - Management, Team, Qualität Phasen - Management u. technische Phasen Risikomanagement - Risikoabschätzung und Management Qualität der Projektumgehbung - Qualität der Anforderungen und Rückmeldungen Konfigurationsmanagement - Produktüberwachung und Dokummentation Änderungssteuerung - Erfassung und Beurteilung	Projektvorbereitung (SU) Projektinitiirung (IP) Projektlekung (DP) Phasensteuerung (CS) Management der Produktlieferung (MP) Phasenübergangmanagement (SB) Projektabschluss (CP) Planen (PL) THE BUSINESS CASE Geschäftsvorteil RISIKOMANAGEMENT Risikoanalyse und Aktivitäten Risikomanagement

PRINCE2 Softwareunterstützung Erfahrung, Optimales Verfahren, Gesunder Menschenverstand

Tab. 01: Zusammenfassung des Models von PRINCE2 Methoden^[19]

7 Komponenten

Gemäß PRINCE2 sind Komponenten die wichtigsten Bestandteile der Projektarbeit. Diese sind s.g. Wissensgebiete innerhalb unterschiedlicher Prozesse und beeinflussen das Projekt auf besondere Weise mit dem Ziel eines erfolgreichen Verlaufs. Entscheidend ist die Verzahnung der Komponenten sowohl untereinander als auch mit den Prozessen. Auf solch eine Verknüpfungen kann keine Methode verzichten.

Das Konfigurationsmanagement ist als eine ergänzende Verwaltung zu sehen, mit der sich der Projektverlauf überprüfen lässt. Die Änderungssteuerung legt dagegen fest, wie es mit Änderungen zu verfahren ist.^[20]

Die Verzahnung zwischen Komponenten und Prozessen zeigt folgende Graphik:

7.1 Business Case

Die Komponente "Business-Case" beschreibt, wie ein Business-Case erarbeitet werden soll und aus welchen Bestandteilen er besteht.^[22]

7.1.1 Übersicht und Beschreibung

Ein Business-Case ist ein Szenario zur betriebswirtschaftlichen Beurteilung einer Investition. Der Business - Case definiert den Mehrwert der für jedes Produkt und die dazu benötigten Aktivitäten erwartet wird. Diesem Mehrwert werden dann die Kosten und Risiken des Projekts gegenübergestellt und bewertet. Dabei ist bei jedem Meilenstein des Projektes genau zu prüfen, ob dieser Mehrwert auch erreicht wurde. Ein Projekt sollte bei einem vorliegenden Business-Case starten. Dabei müssen die Vorgaben des Business-Case im Verlauf des Projekts entsprechend geprüft werden. Auch ein Projekt stellt eine Investition dar, das gegenüber der Geschäftsführung ausreichend begründet werden muss. Ohne einen definierten Business - Case kann ein Projekt gemäß PRINCE 2 nicht starten.

7.1.2 Soll - Inhalte

Elemente des Business Case

• Wirtschaftliche Gründe. Warum ist das Projekt wichtig?
• Optionen. Mögliche Alternativen sollten aufgezeigt werden. Diese müssen genau beleuchtet und die Entscheidung entsprechend begründet werden.
• Nutzen. Darstellung von erwarteten Erträgen bzw. von erzielbarem Mehrwert, der messbar sein muss. Diesen Nutzen muss der Auftraggeber beschreiben.
• Risiken. Beschreibung der wichtigsten Risiken und deren Auswirkungen auf den Projektverlauf
• Zeit und Kostenrahmen. Grobe Schätzung über die Höhe der Kosten, Anlaufzeitpunkt und Projektdauer.
• Investitionsantrag. Entscheidung des Unternehmens darüber, wie erwirtschaftete Finanzmittel eingesetzt werden sollen.

7.1.3 Entwicklung und Bestimmung des Pfades

Folgende Abbildung zeigt, wie das PRINCE2 - Produktmanagement den Business Case bestimmt bzw. benutzt.

Das Projektmandat sollte einige Grundelemente, wenigstens die des Business Case, beinhalten. Daher gibt es wahrscheinlich nur wenige Gründe, warum diese Lösung bevorzugt wird. Ist das Projekt, Teil eines Programms (hier: Komplexes Vorhaben das aus mehreren Projekten besteht), wird das Projektmandat ein Zeiger für den Business Case des Programms. Im Falle, dass das Projekt auf Basis einer Wirtschaftlichkeitsstudie durchgeführt ist, beinhaltet das Projektmandat eine Kopie des Business Case für die bevorzugte Option.^[24]

7.2 Organisation

Eine grundlegende Struktur in PRINCE2 für die Bildung des Projektteams und Verantwortlichkeiten stellt nachfolgende Grafik dar:

Aus dieser Kunden-Lieferanten-Beziehung lassen sich die zugrunde liegenden Interessenlagen ableiten:

• Auftragserteilung durch den Kunden, durch dessen Projektergebnis er profitieren will
• Erstellung des Projektergebnisses durch den Lieferanten.

7.2.1 Übersicht

Das PRINCE2 - Verfahren unterstütz die Ermittlung von Projektteilnehmern in Form von klar definierten Rollen mit fest zugewiesenen Kompetenzbereichen. Bei der Definition von Rollen werden Personen zugewiesen, die das Projekt leiten, verantworten, überwachen und durchführen sollen. Dabei wird eine Kunden- und Lieferanten Umgebung vorausgesetzt. Das Projektmanagementteam agiert als Kunde, wobei die Verantwortlichen für die Produkterstellung als Lieferanten ihre Leistung erbringen. Die Kundenorganisation muss eine klare Vorstellung vom gewünschten Ergebnis verifizieren. Die erbrachte Leistung muss selbstverständlich bezahlt werden. Bei dieser Art von Rollenverteilung auf Personen werden sowohl die Kundenorganisation als auch die Anwender sehr stark an das Projekt gebunden.

Die Organisation der Rollen setz sich folgendermaßen zusammen.

• Lenkungsausschuss: verantwortlich für die Projektsicherung und verbindet die Interessen von Business, Kunde und Auftraggeber
• Projektmanager: verantwortlich für das Tagesgeschäft des Projekts
• Projektsicherung: Arbeitet im Auftrag des Lenkungsausschusses und ist für das Kommunizieren des Soll-Ist Stands einer Projektphase und der Qualitätsprüfung verantwortlich

Diese drei Rollen stehen in einem klaren hierarchischen Verhältnis zu einander und haben sich während des gesamten Projekts über den aktuellen Verlauf des Projekts zu unterrichten. Die übergeordnete Instanz muss gewährleisten, dass auftauchende Probleme mit gut durchdachten Entscheidungen gelöst werden. Als optionale Rolle können noch Teammanager und projektunterstützende Rollen definiert werden.

Im PRINCE2 - Rollenkonzept können mehrere Personen, eine Rolle und eine Person, mehrere Rollen besetzen. Der Projektmanager ist in seiner Rolle und Person einzigartig. Diese Art von Projektorganisation hat den Vorteil, dass Personen aufgrund der Mehrfachverteilung flexibel bleiben. Außerdem weiß jeder Projektmitarbeiter durch eine klare und feste Aufgabenverteilung, welche Leistung von Beginn des Projekts erwartet wird.

7.2.2 Die vier Management-Ebenen

Erkennbar aus der oberen Graphik lassen sich die vier Ebenen wie folgt benennen:

• Unternehmens- oder Programm Management
• Lenkungsauschuss
• Projektmanager
• Teammanager

PRINCE2 trennt das Projektmanagement von den Tätigkeiten, die für die Entwicklung eines Produktes notwendig sind. Der Fokus liegt auf das Projektmanagement.

7.2.3 Projektmanagementstruktur

Die Strukturen, die durch PRINCE2 für das Team geliefert werden, beinhalten diese Aspekte:

• Rollen und Personen mit Entscheidungskompetenzen
• Management bei Sonderfällen für die Entscheidungsträger
• Voll- und Teilzeit Projektmanagement
• Kontrollierte Delegierung täglicher Managementverantwortlichkeiten des Teammanagers
• Rollen einer unabhängigen Betrachtung aller Aspekte der Projektperformance
• Administrative Unterstützung sowohl des Projektmanagers als auch des Teammanagers
• Vereinbarung mit allen Beteiligten über Bedeutung und Zweck der Verantwortlichkeiten
• Richtlinien für die Kommunikation zwischen dem Projektmanagement und den Teammitgliedern.

In Hinblick auf die Flexibilität und Rücksicht auf sehr verschiedene Projektumgebungen und Projektgrossen, definiert PRINCE2 nicht einen Tätigkeitsmanagement, das direkt auf Personen übertragen werden kann. Es werden lediglich Rollen definiert, die zugeordnet, aufgeteilt oder kombiniert werden können je nach den Projektanforderungen. Sollten die Verantwortlichkeiten vernachlässig werden, muss dieses mögliche Risiko klar und deutlich aufgezeigt werden.^[26]

7.2.4 Die Drei Parteien

Diese Abbildung zeigt die Struktur und Komposition des Lenkungsausschusses. Diese Interessen müssen jederzeit allen Parteien bewusst sein.

7.2.5 Projektunterstützung

Die Projektunterstützung hat seine Daseinsberechtigung nur dann, wenn deutlich gemerkt wird, dass dieses Organ benötigt wird. Sollte der Lenkungsausschuss keinen Fokus an direkter Unterstützung des Projektmanagers zeigen, wird die tägliche Projektunterstützung als eine „ad-hoc“-Basis des Projektmanagers definiert.

Grundsätzlich berichtet die Projektunterstützung direkt an den Projektmanager, in Einzelfällen jedoch findet die Berichterstattung, je nach Verantwortung, auch an die Teammangers statt.

7.3 Pläne

7.3.1 Definition

PRINCE2 beschreibt ein Konzept mehrerer Planebenen und -typen, die jede für sich einer bestimmten Zielgruppe genau die Informationen liefert, um den Projektfortschritt zu überwachen. Ein Plan stellt dabei ein Dokument dar, das auf Basis eines vordefinierten Schemas beschreibt, wie, wann und durch wen ein spezielles Ziel oder eine Reihe von Zielen erreicht wird. Bei PRINCE2 müssen die Pläne vor Ihrer Umsetzung genehmigt werden.

7.3.2 Planungsebenen

PRINCE2 kennt 3 Ebenen von Plänen, die alle nach dem gleichen Format erstellt werden, sich jedoch durch den Detaillierungsgrad und die umfasste Zeitspanne unterscheiden.

• Projektplan (notwendig): Ein grober Überblicksplan, der den Projektverlauf und seine Projektprodukte von Anfang bis Ende darstellt. Er dient dem Lenkungsauschuss zur Ausübung einer gesamthaften Steuerung.
• Phasenplan (notwendig): Für eine Phase eines Projektes wird der Projektplan heruntergebrochen auf alle in der Phase zu erstellenden Produkte. Anhand dieses Planes kann der Projektmanager den Phasenfortschritt überwachen.
• Teamplan (optional): Wenn mehrere Teams für das Projekt gebildet wurden, die an umfangreicheren Arbeitspaketen arbeiten, kann zur Klarstellung der Abfolge der auszuführenden Arbeiten die Erstellung eines Teamplanes notwendig werden.

Eine Ausnahmeplan als vierte mögliche Planart in PRINCE2 stellt die gravierende Überarbeitung eines Planes der obigen Ebenen dar. Er wird dann erstellt, wenn eine zulässige Toleranz überschritten wurde.

7.3.3 Vorteile der Planung

Vorteile von PRINCE2 - Plänen sind die Identifizierung von:

• Erreichung der Zeile im Zeitrahmen möglich ?
• erforderliche Mittel zur Erreichung der Ziele gegeben ?
• Maßnahmen zur Erreichung der Qualität der Produkte vorhanden ?
• Aufdecken von Problemen und Risiken aufzeigen

Weitere Vorteile in Bezug auf PRINCE2 sind

• Vermeidung von Durcheinander und Ad-hoc-Entscheidungen
• zukunftorientierte Managementunterstützung
• regelmäßige Fortschrittskontrolle
• Kommunikation an alle Projektbeteiligte über Tätigkeiten und Rollenverteilung auf Personen

(Quelle PRINCE2, London: The Stationery Office S. 210)

7.4 Steuerung

Die Steuerungseinheit überwacht das Projekt und gleich den Fortschritt gegen entsprechende Pläne, zeitliche Vorgaben, aktuelle Kostenlage und Qualität ab. PRINCE2 liefert eine spezielle Unterstützungsstruktur des Managements und eine produktorientierte Steuerung der Überwachung. Dieser Vorgang beinhaltet gleichzeitig eine Prozedur die eine Verbesserung des Plans vorsieht oder anderen korrespondierenden Aktionen.

7.4.1 Übersicht

Es gibt verschiedene Stufen der Steuerungsmittel in einem Projekt. Die meisten jedoch in PRINCE2 sind aber ereignisgesteuert inklusiv aller Entscheidungen. PRINCE2 verkörpert das Konzept „Ausnahmen-Management“ mit der Konzentration auf den Lenkungsausschuss. Dieser wird automatisch über Abweichungen informiert so bald welche einträten. Die wichtigsten Steuerungsmittel für den Lenkungsausschuss sind:

• Projektinitialisierung (Vorteile des Durchführung des Projektes)
• Einschätzung des Erfolges einer Projektstufe
• Reporting der Meilensteine
• Reporting von Ausnahmen und Abweichungen
• Einschätzung der Ausnahmen
• Projektanschluss und Erwartungen

Gleichzeitig muss das Umfeld außerhalb des Projektes von dem Lenkungsausschuss überwacht werden ob irgendwelche Zustände das Projekt beeinflussen können. Der Projektleiter hat tägliche Kontrolle über das Projekt, und auf der Basis einer Projektstufe kann er diese besser anpassen so lange die Stufe selbst und das Projekt innerhalb der definierten Toleranzen bleiben. Diese Anpassungen jedoch beeinflussen nicht den Business Case. ^[30].

7.4.2 Zweck der Kontrolle

Die Kontrolle widmet sich dem Ziel, sicher zu stellen dass:

• produziert wird genau das Produkt, dass die definierten Kriterien erfühlt
• der Zeitplan übereinstimmig mit Ressourcen und geplanten Kosten eingehalten wird
• das Projekt ununterbrochen das im Business Case definiertes Produkt verfolgt

Weiterhin sichert die Kontrolle, dass in jeder Stufe des Projektmanagementteams und die nächst höhere kann:

• überwachen den Fortschritt
• vergleichen des Erreichten mit Plänen
• Bewertung der Pläne und Optionen im Bezug auf zukünftigen Situationen
• Feststellung der Probleme
• Initialisierung von Korrekturen
• Begründung von weiteren Tätigkeiten ^[31]

7.4.3 Kontrollierter Projektstart

Der kontrollierte Start besteht aus 4 Stufen:

• Projektvorbereitung
• Genehmigungsverfahren
• Projektinitiierung
• Stufenauswahl

Alle vorbereitenden Aktivitäten innerhalb des Projektanlaufs, haben die Absicht zukünftige Aktivitäten der Spezialisten einzuplanen. In diesem Prozess wird besonders die Organisation des Projektmanagementteams und die Beschreibung des Projektauftrags in den Vordergrund gestellt. Des Weiteren wird die Initialisierungsstufe durchgeplant. Dieses garantiert eine kontrollierte Implementierung der Initialisierungsstufe, die eine Basis für eine kontrollierte Implementierung der restlichen Projektstufen ist. ^[32]

Während der Initiierungsphase ist der Projekt Manager verantwortlich für die Erstellung der PID. Die PID ist die Basis und ein Zugewinn der Genehmigung durch den Lenkungssausschuss für das Projekt. Sie gilt auch als Basis für die geplanten Aktivitäten. Die wichtigsten Elemente der PID sind: Qualitätsplan, Projektplan, Business Case, Risikodokumentation und Festlegung wie die Projektkontrolle organisiert wird. Diese Elemente müssen auch in besonderem Masse, wenigsten am Ende jeder Phase aktualisiert werden. ^[33]

7.4.4 Kontrollierter Projektablauf

Der Umfang dieser Phase besteht aus:

• Toleranzen
• Produktbeschreibung
• Arbeitspaket
• Qualitätskontrolle
• Projektheft
• Risikodarstellung
• Kontrollpunkte
• Planung und deren Überarbeitung
• Bericht über Höhepunkte
• Bericht über Ausnahmen
• Endphasenbewertung
• Endphasenbericht
• Zwischenphasenbewertung ^[34].

7.4.5 Kontrollierter Projektabschluss

Wird das Projekt abgeschlossen müssen zuvor folgende Punkte sichergestellt werden:

• Der Erfolg dieses Projektes hat alle beteiligte Parteien zufriedengestellt
• Unterstützung und Aufrechterhaltung sind quartiert
• Eine gute Bewertung der durchgeführten Schulungen hat stattgefunden
• mögliche folgende Aktionen sind aufgenommen worden
• Ein Plan wurde gestellt, dass den erwarteten Mehrwert des Kunden durch dieses Projekt erreicht ist

Dokumente, die den kontrollierten Abschuss sichern, sind:

• Projektabschlussnotifizierung
• Auslieferungsprotokolle
• Bericht über Projektabschluss
• Empfehlung von Zusatzaktionen
• Bericht über Schulungen
• Nachhaltige Projektbewertung ^[35].

7.5 Risiko Management

7.5.1 Definition

Jedes Projekt bringt aufgrund seiner Einzigartigkeit und Komplexität, eine Vielzahl von vorhersehbaren und unvorhersehbaren Risiken mit. Risiko wird als "Unsicherheit des Ergebnisses" bezeichnet. Wie in vielen Projektmanagement Methoden wird auch bei PRINCE2 der proaktive Umgang mit Risiken als Managementherausforderung angesehen. Ziel des Risikomanagement ist es, die Risiken mit effektiven und wirtschaftlichen Mitteln in Grenzen zu halten. Dieses bedarf das permanente Überwachen des Projekts über alle Phasen.

Das Risikomanagement bei PRINCE2 besteht und interagiert mit der Durchführung der Risikoanalyse. Diese beinhaltet einen 4 stufigen Plan zur

• Identifizierung von Risiken zu verschiedenen Zeitpunkten des Projektverlaufs
• Evaluierung von Risikosituationen nach Wahrscheinlichkeit und Auswirkung
• Identifizierung von akzeptablen und finanziell tragbaren Maßnahmen
• Auswahl von geeigneten Maßnahme

Das Umsetzen der Maßnahme(n) ist Aufgabe des Risikomanagement und verläuft unter Berücksichtung der Risikobereitschaft des Unternehmens.

Das Risikomanagement ist bei PRINCE2 fester Bestanteil in vielen Prozessen und wird als Risikoprotokoll eingerichtet und ständig aktualisiert.

7.5.2 Risikoarten

Risiken im Projektmanagement können wie folgt kategorisiert werden

• Strategisch / Geschäftlich, Gerichtlich / Behördlich
• Ökonomisch / Finanziell / Marktorientiert
• Organisatorisch / Managementbezogen / Menschlich
• Politisch
• Umweltbezogen
• Technisch / Betrieblich / Infrastruktuell^[37]

7.5.3 Grundsätze

Das Risikomanagement in PRINCE2 ist in 3 Grundsätze aufgeteilt

• Risiko-Toleranz: Risiken im Projektverlauf bedürfen evtl. keine Maßnahmen der Umsetzung, sofern sich diese innerhalb der Toleranzgrenzen befinden
• Risiko-Verantwortung: Das Risikoprotokoll liegt in der Verantwortung des Auftraggebers. Im Gegensatz dazu ist der Projektmanager verantwortlich die Risiken zu handhaben und das Risikoprotokoll stets aktuell zu halten. Dazu gehören alle Stufen der Risikoanalyse. Der Lenkungsausschuss hat eine beratende Verantwort in Bezug auf Risiken. Ihn betrifft die Informationsweitergabe an Projektleiter und Unternehmen.

• Risiko-Eigentümer: Es wird empfohlen, für jedes Risiko einen Eigentümer zu ernennen. Das Auswählen der Person übernimmt der Lenkungsausschuss. Der Eigentümer aller Risiken, die sich auf das Business Case ziehen ist der Auftraggeber.^[38]

7.6 Qualität der Projektumgebung

Qualität bezeichnet die quantifizierbare Eigenschaft des Produkts, die es für seinen Zweck geeignet macht. Die Qualitätserwartungen sind in der Projektbeschreibung und im PID festgehalten.

7.6.1 Qualitätsdefinition

Qualität nach DIN EN ISO 8402: "...die Gesamtheit der Merkmale und Merkmalswerte eines Produktes oder einer Dienstleistung bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erwartung zu erfüllen."

7.6.2 Qualitätsmanagement

Das Qualitätsmanagement in PRINCE2 bezeichnet die "Qualität" stets als Ergebnis eines Vergleichs zwischen Qualitätsanforderungen und tatsächlicher Beschaffenheit einer Einheit unter dem Aspekt einer Anspruchsklasse. Qualität bezieht sich auf jede quantifizierbare Eigenschaft des Produkts, die es für sein Zweck geeignet macht. Dabei berücksichtigt der Bereich Qualitätsmanagement unterschiedliche Aspekte. Das Qualitätssystem umfasst die Organisationsstruktur, Verfahren und Prozesse.

Das Qualitätsmanagement ist in 4 wesentliche Elemente aufgeteilt.

• Qualitätsmanagement: Umsetzung der für Qualitätsmanagement relevanten Funktionen in einer Anwendung, die Verfahren und Tools zum Verwalten, Steuern und Verteilen von qualitätsrelevanten Informationen abbildet.
• Qualitätssicherungsfunktion: Mit der analytischen Qualitätssicherung findet eine ständige Messung der Produktqualität statt. Im Gegensatz dazu wird mit der konstruktiven Qualitätssicherung die Qualität gesteigert.
• Qualitätsplanung: Bestimmung, welche Qualitätsziele für das Projekt notwendig sind und Sicherstellung, wie und dass die Ziele gemessen werde können (analytische QS). Zusätzlich die Festlegung von Maßnahmen, die für eine Qualitätssteigerung sorgen (konstruktive QS).
• Qualitätssteuerung: Die Steuerung der Qualität beschäftigt sich mit der Dosierung der Qualitätssicherung (z.B. Ressourcenbereitstellung) auf Basis von Qualitätsmessungen

7.6.3 Qualitätsarbeit

Um die gewünschte Qualität liefern zu können, müssen folgende Entscheidungen getroffen werden.

• WIE wird das Produkt auf die Qualitätsanforderungen geprüft ?
• WANN wird das Produkt auf die Qualitätsanforderungen geprüft ?
• WER prüft das Produkt auf die Qualitätsanforderungen ?

Der erste Schritt wird im Prozess IP1 (Qualität planen) durchlaufen. Die folgenden beiden Schritte werden im Prozess SB1 (Phasen planen) behandelt.

(Quelle PRINCE2, London: The Stationery Office S. 210)

7.7 Konfigurationsmanagement

7.7.1 Definition

Konfigurationsmanagement befasst sich mit der Steuerung aller Produkte des Projektes und ihrer unterschiedlichen Versionen, die in der Regel im Laufe der Entwicklungs-, Erstellungs- bzw. Designaktivitäten eines Projektes entstehen. Über das Projektmanagement können Produkte und ihre Entwicklung zurückverfolgt sowie der aktuelle Status eines Projektes abgerufen werden.

Das Konfigurationsmanagement besteht aus 5 Hauptaktivitäten

• Planung: Definieren von Detailtiefe und Umfang des Konfigurationsmanagements
• Identifikation: Komponentenbestimmung der Produkte
• Steuerung: Verwaltung und Steuerung der Produktbestandteile
• Status-Fortschreibung und -überwachung: Historische und aktuelle Daten in der Konfigurationsdatenbank
• Verifikation: Kontrolle der Einträge in der Konfigurationsdatenbank^[39]

7.7.2 Grundlinie

Die Grundlinie ist s.g. Snapshot eines Status des Produktes. Eingefroren zu einem bestimmten Zeitpunkt für besonderen Zweck. Wie z.B. der Projektplan wird abgestimmt zwischen dem Lenkungsausschuss und Projektmanager. Es beschreibt auch eine Änderung in dem Produktstatus, wenn es übergeben wird zu den Konfigurationsarchiven nach einer erfolgreichen Qualitätskontrolle. Das kann nun benutzt werden als eine Basis für zukünftige Entwicklungen für spätere Produkte.^[40]

7.7.3 Konfigurationsmanagementplan

Die Planung eines Projektes umfasst das Erstellen eines Konfigurationsmanagementplans, der einen Teil des Projektqualitätsplans darstellt. Dieser Plan erklärt, warum das Konfigurationsmanagement eingeführt wurde und liefert die Beschreibung der Konfigurationsmanagement-Methode. Abweichungen von Unternehmens- oder Programmmanagement-Standards sollten im Konfigurationsmanagementplan dokumentiert werden. Weitere Inhalte sind Verweise auf die verwendeten Tools, Angaben, wie und wo die Produkte aufbewahrt werden, welche Sicherheitsvorkehrungen getroffen werden, Versionierung und Verantwortlichkeiten. Der Konfigurationsmanagementplan ist Bestandteil des Projektqualitätsplans, der teil des Projektleitdokuments (PID) ist und wird während des IP-Prozesses (Initiieren eines Projekts) erstellt.^[41]

7.8 Änderungssteuerung

7.8.1 Ziel und Zweck

Das Ziel ist das erfassen, dokumentieren und kategorisieren aller Änderungen im Projekt. Änderungen werden wie in der unteren Abbildung bewertet. Birgt die Änderung Risiken im weiteren Projektverlauf, wie hoch sind die Kosten und liegt es innerhalb des Zeitplans. Dieses wird dem Nutzen entgegengesetzt.

(Quelle vgl.:Managing Successfull Projects with PRINCE2 1999, Seite 97)

7.8.2 Feststellung von Änderungen

Es gibt ein breites Spektrum für Änderungen, welche u.a. aus folgenden Anlass erforderlich sein können:

• Änderungen innerhalb einer Anforderung
• Änderungen im Projektumfeld z.b.:
  • Personelle Änderungen im Lenkungsausschuss
  • Personelle Änderungen beim Projektmanagement
  • Neue Lieferanten
• Ein neues Problem, welches nicht bei der Risikoanalyse erkannt wurde
• Neu erschlossene Geschäftsbereiche

Diese Änderungen werden wie folgt spezifiziert:

• Request for Change(Änderungsantrag)
• Off-Spezification (Spezifikationsabweichung)
• Anfragen

7.8.3 Änderungsintegrität

Um das Produkt nicht zu gefährden werden Änderungen ganzheitlich betrachtet und auf Ihre Integrität geprüft. Es erfolgt bei jeder Änderung diesbezüglich eine Bewertung, ob und in welcher Form der Nutzen die Änderung rechtfertigt.

7.9 Phasen

Je nach Quelle gehören die Phasen entweder zu der Komponente: Steuerung (nach OGC^[43] ), oder gelten als eigenständige Komponente (nach CCTA^[44]).

Phasen sind Projektabschnitte mit Entscheidungspunkten an deren Ende oder selten auch währen deren Verlaufs.

PRINCE2 unterscheiden zwei Arten von Phasen:

• Managementphasen

diese werden gleichgestellt mit dem Einsatz der Ressourcen des Lenkungsausschusses und Entscheidungen zur Fortführung des Projektes und Befugnis zu Ausgaben

• Technische Phasen

diese Vergleichen die technischen Aktivitäten zu dem benötigten und genanten Produkt

Technischen Phasen werden oft überlappt und laufen parallel. Üblicherweise werden sie gesteuert und geplant durch den Teamleiter.

Die Zusammenhänge der Verschiedenen Phasenarten können wie in dem Beispiel unten dargestellt werden:

8 Prozesse

8.1 Einführung in die Prozesse

Laut PRINCE2 wird der Projektmanagementprozess in 8 Hauptprozesse unterteilt. Diese Unterteilung basiert sich auf den Phasen innerhalb eines Projektes und auf die verschiedenen Orientierungen in Kontext und Verantwortlichkeiten. Jeder Hauptprozess wird weiter unterteilt in Subprozesse.

8.1.1 PRINCE2 Prozessmodell

8.2 Projektvorbereitung (SU)

8.2.1 Beschreibung und Kontext

Der erste Prozess im PRINCE2-Modell dient dazu, von einer (vagen) Projektidee zu einer fassbaren Projektbeschreibung zu gelangen. Alle hierfür benötigten Informationen werden vom designierten Projektmanager zusammengetragen. Projektmanager und Auftraggeber entwerfen gemeinsam einen Business Case und skizzieren eine Projektvorgehensweise. Die Zusammensetzung eines Lenkungsausschusses wird entworfen. ^[47]

8.2.2 Subprozesse

• (SU1) Ernennung von Projektauftragsgeber und Projektmanager
• (SU2) Entwurf des Projektmanagementteam
• (SU3) Verpflichtung des Projektmanagementteam
• (SU4) Vorbereitung der Projektbeschreibung
• (SU5) Definition des Projektlösungsansatzes
• (SU6) Planung der Initialisierungsphase

8.3 Projektinitiierung (IP)

8.3.1 Beschreibung und Kontext

Nachdem der installierte Lenkungsausschuss die Projektbeschreibung autorisiert hat, beginnt die erste eigentliche Projektphase. Dieser Prozess beinhaltet alle vorbereitenden Aktivitäten, die notwendig sind, um anschließend das Projekt auf einer soliden Basis planmäßig durchzuführen. Alle Projektmanagementprozesse werden etabliert, das Projekt wird mit dem Projektteam ausgestattet, die Produkte und Ergebnisse werden definiert. Darauf basierend erfolgt eine produktorientierte Planung des gesamten Projektes, insbesondere der nächsten Managementphase. Wesentliches Managementprodukt dieser Phase ist das Projektinitiierungsdokument (PID).^[48]

8.3.2 Subprozesse

• (IP1) Qualitätsplanung
• (IP2) Projektplanung
• (IP3) Detaillierung von Business-Cases und Risiken
• (IP4) Einrichtung von Projektsteuerungsmittel
• (IP5) Einrichtung der Projektablagestruktur
• (IP6) Zusammenstellung des Projektleitdokuments (PID)

8.4 Projektdirigierung (DP)

8.4.1 Beschreibung und Kontext

Der Prozess Dirigieren eines Projektes (DP) läuft während der gesamten Dauer des Projektes und beschreibt die Aktivitäten des Lenkungsausschusses. Diese bestehen vornehmlich aus Entscheidungen über die Art der Fortführung des Projektes. Der Prozess richtet sich auf Maximierung der Erfolgschance und Lieferung der vom Auftraggeber und Kunde erwarteten Ergebnisse. Der Prozess basiert sich auf dem Prinzip Management by Exception: der Lenkungsausschuß führt das Projekt auf Grund von Reportagen und wichtigen Entscheidungspunkte:

• Genehmigung der Initiierung eines Projektes (einrichten des Projektes auf Grund der Wünsche und Aufgaben des Kunden, damit das Projekt auf soliden Basis mit der Ausführung anfangen kann)

• Genehmigung der Phasenausführung eines Projektes (zuweisen der Ressourcen und des Budgets auf Grund einer genauen Planung und den bis dann erreichten Ergebnisse)

• Ad hoc Beratung (auf Grund der Fortgangsüberwachung Rat und Richtung geben und in Ausnahmefällen die geforderten Entscheidungen treffen)

• Formalisieren des Projektabschlusses (Feststellen und Akzeptieren der Projektergebnisse und die formelle Decharge des Projektes und die dazu gehörende Organisation)

Dieser Prozess umfasst nicht das tägliche Management des Projektmanagers.^[49]

8.4.2 Subprozesse

• (DP1) Freigabe der Projektinitiierung
• (DP2) Projektfreigabe
• (DP3) Phasen- und Ausnahmeplansfreigabe
• (DP4) Einleitung von Ad-hoc-Anweisungen
• (DP5) Bestätigung des Projektabschlusses

8.5 Steuern einer Phase (CS)

8.5.1 Beschreibung und Context

Dieser Prozess beschreibt die tägliche Arbeit des Projektmanagers mit der Zielsetzung, die geplanten Produkte zu liefern. Überwachung des Projektfortschritts, Aktualisierung der Pläne, kontrollierter Umgang mit Änderungen und Information des Lenkungsausschusses und gegebenenfalls Eskalation werden vom Projektmanager sowohl ereignisgesteuert als auch routinemäßig durchgeführt.^[50]

8.5.2 Subprozesse

• (CS1) Freigabe des Arbeitspaketes
• (CS2) Überwachungsfortschritt
• (CS3) Aufnahme von offenen Punkten
• (CS4) Prüfung von offenen Punkten
• (CS5) Phasenstatusprüfung
• (CS6) Bericht des Projektstatus
• (CS7) Einleitung von Korrekturmassnahmen
• (CS8) Eskalation offenen Punkte
• (CS9) Entgegennahme des Abgeschlossenes Arbeitspaketes

8.6 Managen der Produktlieferung (MP)

8.6.1 Beschreibung und Kontext

In diesem Prozess erfolgt die kontrollierte Trennung zwischen dem Projektmanagement und fachlichen Projektarbeit, der Erstellung der Projektprodukte und Dokumente. Verantwortlich hierfür ist der Teammanager. Das Ziel ist sicherzustellen, dass die Resultate kreiert, erreicht und geliefert werden gemäß dem vom Lenkungsausschußes genehmigten Planes. Dabei sind folgende Elemente wichtig:

• Eindeutige Übergabe der Arbeit am Team, wobei die Verantwortlichkeiten am Individuum (hauptsachlich dem Teamleiter) übertragen werden

• Genehmigung der Anfang der Ausführung der übertragenen Arbeit am Projektmanager

• Überprüfung der ausgeführten Arbeit, damit festgestellt werden kann, dass sie den in Produktbeschreibungen und Arbeitspakete festgelegte Qualitätserwartungen und Akzeptanzkriterien entsprechen

• Kontrollieren, dass die Produkte von den Testern akzeptiert und genehmigt worden sind^[51]

8.6.2 Subprozesse

• (MP1) Annahme des Arbeitspaketes
• (MP2) Ausführung des Arbeitspaketes
• (MP3) Ablieferung des Arbeitspaketes

8.7 Managen der Phasenübergänge (SB)

8.7.1 Beschreibung und Kontext

Dieser Prozess beschreibt die Aktivitäten zur Vorbereitung des Übergangs von einer zur nächsten Managementphase. Hierzu sind Review und Aktualisierung von Business Case, Projektrisiken und Projektplan notwendig. Der Projektmanager spezifiziert die Planung für die neue Phase. Aktualisierte Dokumente und neue Pläne sind vom Lenkungsausschuss zu autorisieren. Eine Richtungsänderung des Projektes, oder gar dessen Stopp, sind durchaus gewollte Ergebnisse der anschließenden Lenkungsausschusssitzung.^[52]

8.7.2 Subprozesse

• (SB1) Phasenplanung
• (SB2) Projektplanaktualisierung
• (SB3) Business-Case-aktualisierung
• (SB4) Risikoprotokollaktualiesierung
• (SB5) Phasenabschlussbericht
• (SB6) Erstellung des Ausnahmeplans

8.8 Projektabschluss (CP)

8.8.1 Beschreibung und Kontext

Dieser Prozess stellt sicher, dass der Abschluss des Projektes, ebenso wie Start und Durchführung, in einer kontrollierten Art und Weise erfolgt. Er beschreibt die hierfür notwendigen Aktivitäten, wie Abnahme durch Kunden und Betrieb, Übergabe der Projektdokumente und die Erstellung eines Projektabschlussberichtes. Zudem wird auch der Transfer von Erfahrungen aus dem Projekt zurück in die Unternehmensorganisation berücksichtigt.

Die wichtigsten Elemente in diesem Prozess sind:

• Untersuchen und feststellen, in wiefern Ziele und Ergebnisse erreicht worden sind im Vergleich zum Abkommen, festgelegt im PID

• Untersuchen und Feststellen, inwiefern Anforderungen und Wünsche der Benutzer erfüllt worden sind

• Erhalten der formellen Genehmigung aller Ergebnisse und Produkte des Projektes

• Sicherstellen, dass alle Verwendungs- und Wartungsaktivitäten geregelt worden sind, damit die Resultate des Projekts von der auftraggebenden Organisation benutzt werden können

• Sicherstellen, dass "losen Enden" abgehandelt werden

• Festlegen aller Lernpunkte und Messwerte eines Projektes im Lernpunktebericht

• Der auftraggebende Organisation und ihren Teilen erkundigen, dass die Projektorganisation in absehbarer Zeit aufgelöst wird und die dabei eingesetzten Ressourcen wieder zur Verfügung anderer Aktivitäten kommen^[53]

8.8.2 Subprozesse

• (CP1) Projektauflösung
• (CP2) Identifizierung von Folgeaktionen
• (CP3) Projektbewertung

8.9 Projektplanung (PL)

8.9.1 Beschreibung und Kontext

Eine gründliche Planung und permanente Aktualisierung der Pläne während des Projektverlaufes sind Garanten für den Projekterfolg. Entsprechend dieser Bedeutung finden sich die notwendigen Aktivitäten für die Erstellung von Initiierungs-(SP6), Projekt-(IP2), Phasen-(SB1) und Ausnahmeplänen(SB6) in einem eigenen Hauptprozess wieder, der wie der Prozess "Lenken eines Projektes" vom Beginn bis zum Ende des Projektes läuft.

Das Erstellen eines Plans umfasst mehr als nur das Machen eines Zeitplans: es beschreibt wie, wann und von wem ein spezifiziertes Ziel oder Gruppe von Ziele erreicht werden soll(en) und wie die definierte Ziele in Ergebnis, Zeit, Kosten und Qualität realisiert werden können. In PRINCE2 ist eine produktorientierte Basis der Aktivitätenplanung vorgesehen.^[54]

8.9.2 Subprozesse

• (PL1) Planentwurf
• (PL2) Definition und Analyse von Produkten
• (PL3) Identifizierung von Aktivitäten und Abhängigkeit
• (PL4) Aufwandschätzung
• (PL5) Zeitplanerstellung
• (PL6) Risikoanalyse
• (PL7) Vervollständigung des Plans

9 Techniken

9.1 Änderungssteuerung

Im praxisbezogenen Projektmanagement ist der Umgang mit Änderungen unerlässlich. In einem Projekt erscheinen Änderungen in vielfältiger Art. Eine Ablehnung von Änderungen führt unweigerlich zu unakzeptierten Projektergebnissen, jedoch müssen Änderungen sorgfältig in ein Projekt eingebracht werden.

Auswirkungen der Änderungen müssen:

• bewertet werden
• zugewiesen sein
• nachvollziehbar sein

Es werden zwischen drei Arten von Änderungen unterschieden:

• Request for Change(Änderungsantrag)
• Off-Spezification (Spezifikationsabweichung)
• Anfragen

9.2 Qualitätsprüfungen

PRINCE2 fordert, dass alle Produkte auf ihre Qualität überprüft werden. Dabei wird geprüft, ob ein Produkt vollständig ist und den gestellten Anforderungen entspricht. Sie dient als Basis für mögliche Nachbesserungen und weitere Kontrollen für ein Produkt. Dies findet in einer Qualitätsprüfungssitzung statt, in der Fehler im Produkt identifiziert werden. Eine Qualitätsprüfung innerhalb von PRINCE2 ist eine standardisierte Vorgehensweise, die Qualität von Dokumenten zu prüfen. Ein benanntes Prüfungsteam führt die Prüfung durch.

Die Qualitätsprüfung an sich ist eine dreigeteilte Vorgehensweise bestehend aus folgenden Schritten:

• Vorbereitung und Prüfung des Produkts anhand dessen Beschreibung
• Prüfungsmeeting zur Beschlussfindung der möglichen Maßnahmen
• Prüfungsnachbearbeitung und Freigabe bei erfolgreicher Nachbesserung

Folgender Nutzen wird mit der Qualitätsprüfung erzielt.

• Eine strukturierte Beurteilung eines Dokuments mit festgelegten Qualitätskriterien
• frühzeitige Erkennung von Mängeln an den Endprodukten
• Schaffung einer Plattform zur Verbesserung der Ergebnisse
• Einbeziehung aller Interessenten
• Schaffung von Rückhalt und Commitment^[55]

9.3 Produktbasierte Planung

Eine produktbasierte Planung ermöglicht Klarheit über die auszuführenden Arbeiten, bevor die Arbeiten ausgeführt werden. Damit wird die Basis für die Vergabe von Arbeitspaketen und für die spätere Qualitätsprüfung der realisierten Produkte geschaffen.

Bei jeder Erstellung bzw. Aktualisierung eines Planes wird der verantwortliche Ersteller des Planes aufgefordert, eine produktbasierte Planung durchzuführen. Dieser Schritt soll die erste Planungshandlung sein. Erst danach wird darauf aufbauend eine aktivitätenorientierte Planung durchgeführt.

Die produktbasierte Planung umfasst vier Einzelschritte:

• Beschreibung des Endproduktes: Das Gesamtergebnis des zu erstellenden Planes wird zunächst aus Kundensicht beschrieben.
• Produktstrukturplan (PSP): Von allen herzustellenden Produkten wird ein PSP angefertigt. Dort wird angegeben, aus welchen Teilprodukten ein Produkt logisch aufgebaut ist. Auch werden die Zwischenprodukte angegeben, die für die Realisierung des Produkts erforderlich sind.
• Produktbeschreibungen (PB): In ihnen wird beschrieben, wozu ein Produkt dient, woraus es gemacht oder abgeleitet wird, wann es fertig sein soll, welchen Qualitätsanforderungen es entsprechen soll und wie bzw. von wem das Produkt zu prüfen ist: Eine Produktbeschreibung sollte für jedes umfangreichere, nicht selbsterklärende Produkt hergestellt werden.
• Produktflussdiagramm (PFD): Anschließend wird ein Produktflussdiagramm erstellt, in dem der sequentielle Bezug zwischen den Produkten dargestellt wird. Es kann auch als "Zusammenbauanleitung" für die Produkte beschrieben werden. Alle Produkte aus dem Produktstrukturplan müssen im Produktflussdiagramm wiederzufinden sein.

10 PRINCE2 Refresh 2009

Aufgrund der Änderungsanforderungen, welche an das OGC gerichtet wurden, die aus der internationalen und schnell wachsenden Verbreitung von PRINCE2 resultieren, erfolgt ein Refresh im Jahr 2009. Die Änderungsanforderungen erfolgten durch unterschiedlichste Anwendergruppen. Verantwortlich für die Erstellung der neuen Version ist Andy Murray, welcher im Auftrag der OGC arbeitet und die neuen Anforderungen der Anwender sowie auch der OGC selbst umsetzt. Es handelt sich hierbei nicht wie die bisherigen Änderungen um kleine Anpassungen, sondern um eine tiefgehende Überarbeitung.

Kernpunkte der Anwenderanforderungen:

• Integrationsfähigkeit der Methode
• Skalierbarkeit der Methode
• einheitliches Glossar
• flexible Aufbereitung der Dokumentationshilfen

Anforderungen der OCG:

• Die Methode soll anpassbar und unbürokratisch sein.
• Der Inhalt und seine mediale Aufbereitung müssen logisch und intuitiv erfassbar sein.
• Die Methode muss branchenunabhängig sein und modernen Anforderungen genügen.
• Sie muss trainierbar und zertifizierbar sein.
• Fundamentale PRINCE2-Prinzipien müssen beibehalten werden.
• Existierende Hilfsprodukte und -Techniken (z.B. das PRINCE2 Maturity Model) sollen identifiziert und integriert werden.
• Überflüssige oder veraltete Inhalte sollen identifiziert und entfernt werden.
• Der Inhalt soll neu strukturiert und in Form modifizierter Literatur bereit gestellt werden.
• Die Schnittstellen zwischen den OGC-Methoden bzw. -Standards (PRINCE2, M_o_R, MSP, ITIL®) sollen vereinheitlicht und verdeutlicht werden.
• Allgemeine Wissensgebiete, die bereits durch andere Methoden oder Standards ausreichend erschlossen wurden, sollen nicht aufgenommen werden.

^[56]

Vergleich des neuen Modells

11 Schlussbetrachtung

Die Projektmanagementmethode PRINCE2 bietet eine etablierte und erprobte Methode zum Umsetzen der verschiedensten Projekte. Durch die pragmatische Methode und die Zielsetzung der Wiederholbarkeit hat sich PRINCE2 etabliert. PRINCE2 bietet einen sofort umsetzbaren Handlungsrahmen für den gesamten Projektlebenszyklus.

Mit dem Refresh 2009, geplant im Frühjahr 2009, könnte ein weiterer "großer Wurf" gelingen. Durch die Beibehaltung bewährter Methoden, die Vereinfachung der Prozesse und die Optimierung und Anpassbarkeit der Dokumente, wird dies Projektmanagemantmethodik noch effizienter in Projekten anwendbar sein.

Stärken von PRINCE2:

• Ziel: Verbesserung der Produktentwicklung
• Orientierung am wirtschaftlichen Nutzen
• Ergebnis bzw. produktbasierte Planung
• Konzept des Lenkungsausschusses (engl. Project Board) als der verantwortlichen Rolle für die Projektlenkung
• Definiertes Modell der Projektorganisation: definierte Rollen und Verantwortlichkeiten
• Problem Management: Nachhalten von Problemen bzw. offenen Punkten (engl.: Issues) in einem Log
• Praxisnah: sofort einsetzbar
• Arbeitspaket als zentrales Element der Arbeitssteuerung
• Produktvorlagen
• Management by Exception: Der Lenkungsausschuss greift nur ein, wenn vorher festgelegte Toleranzwerte überschritten sind.
• Eine umfassende Betrachtung des Change- und Konfigurationsmanagements
• Reviews als Werkzeug der Qualitätskontrolle
• Konformität mit ISO 9000
• Besondere Betonung der frühen Phasen „Vorbereiten eines Projekts“ (SU) und „Initiieren eines Projekts“ (IP) verhindert, dass Projekte vom „Baum fallen“
• Kombinierbar mit anderen Prozessen und Verfahren
• Prozesse, Rollen und Dokumente können bei kleineren Projekten zusammengelegt werden
• Public Domain
• Erprobt

Schwächen PRINCE2:

• unzureichende Berücksichtigung iterativer und agiler Ansätze
• Handbuch sprachlich inkonsistent
• mehr Hinweise zur Skalierung notwendig
• kein Human Ressource Management
• PINO (engl.: „Prince In Name Only“): man bedient sich unbedacht der Methodologie, hält sich dabei aber nicht an die Grundsätze
• Projektbürokratie durch die starke Ausrichtung auf Dokumente
• Machbarkeitsstudien nur als sep. Projekt
• ohne Anpassung für kleine Projekte zu schwergewichtig
• keine Anforderungsanalyse

12 Fußnoten

1. ↑ vgl. Quelle Nr. 2 Seite 22
2. ↑ vgl. Quelle Nr. 5 Seite 1
3. ↑ vgl. Quelle Nr. 5 Seite 1
4. ↑ vgl. Quelle Nr. 2 Seite 23
5. ↑ vgl. Quelle Nr. 1 Seite 7
6. ↑ vgl. Quelle Nr. 2 Seite 18
7. ↑ vgl. Quelle Nr. 5 Seite Vorwort
8. ↑ vgl. Quelle Nr. 11
9. ↑ vgl. Quelle Nr. 12
10. ↑ vgl. Quelle Nr. 6 Seite 17
11. ↑ vgl. Quelle Nr. 1 Seite 1
12. ↑ vgl. Quelle Nr. 12 Lesson 1
13. ↑ vgl. Quelle Nr. 3 Seiten 20 - 21
14. ↑ vgl. Quelle Nr. 1 Seite II
15. ↑ vgl. Quelle Nr. 2 Seite 24
16. ↑ vgl. Quelle Nr. 7 Seite 24
17. ↑ vgl. Quelle Nr. 3 Seite 27
18. ↑ vgl. Quelle Nr. 3 Seite 28
19. ↑ vgl. Quelle Nr. 3 Seite 28
20. ↑ vgl. Quelle Nr. 6 Seite 44
21. ↑ vgl. Quelle Nr. 4 Seite 40
22. ↑ vgl. Quelle Nr. 6 Seite 44
23. ↑ vgl. Quelle Nr. 1 Seite 193
24. ↑ vgl. Quelle Nr. 1 Seite 193
25. ↑ vgl. Quelle Nr. 6 Seite 49
26. ↑ vgl. Quelle Nr. 1 Seite 197
27. ↑ vgl. Quelle Nr. 1 Seite 198
28. ↑ vgl. Quelle Nr. 9 Seite 47
29. ↑ vgl. Quelle Nr. 1, Seite 218
30. ↑ vgl. Quelle Nr. 1 Seite 218
31. ↑ vgl. Quelle Nr. 1 Seite 217
32. ↑ vgl. Quelle Nr. 2 Seite 58
33. ↑ vgl. Quelle Nr. 7 Seite 113
34. ↑ vgl. Quelle Nr. 2 Seiten 58 - 56
35. ↑ vgl. Quelle Nr. 3 Seite 47, Quelle Nr. 7 Seite 120
36. ↑ vgl. Quelle Nr. 9 Seite 93 f.
37. ↑ vgl. Quelle Nr. 9 Seite 93
38. ↑ vgl. Quelle Nr. 9 Seite 95
39. ↑ vgl. Quelle Nr. 9 Seite 101 f.
40. ↑ vgl. Quelle Nr. 1 Seite 265
41. ↑ vgl. Quelle Nr. 9 Seite 102 f.
42. ↑ vgl. Quelle Nr. 2 Seite 97
43. ↑ vgl. Quelle Nr. 1 Seite 234
44. ↑ vgl. Quelle Nr. 2 Seite 68
45. ↑ vgl. Quelle Nr. 3 Seite 49
46. ↑ vgl. Quelle Nr. 9 Seite 63
47. ↑ vgl. Quelle Nr. 9 Seite 63
48. ↑ vgl. Quelle Nr. 9 Seite 65
49. ↑ vgl. Quelle Nr. 9 Seite 67
50. ↑ vgl. Quelle Nr. 9 Seite 70
51. ↑ vgl. Quelle Nr. 9 Seite 72
52. ↑ vgl. Quelle Nr. 9 Seite 74
53. ↑ vgl. Quelle Nr 9 Seite 74
54. ↑ vgl. Quelle Nr. 9 Seite 68
55. ↑ vgl. Quelle Nr. 9 Seite 141 f.
56. ↑ vgl. Quelle Nr. 10
57. ↑ vgl. Quelle Nr. 10

13 Literatur- und Quellenverzeichnis

Nr.	Quellebezeichnung
01	London: The Stationery Office, PRINCE2, 3rd Edition, London Crown 2002, ISBN: 0 11 330891 4
02	CCTA, PRINCE2, Managing Successful Projects with Prince2, Key Skills Limited 1999
03	Ken Bradley, Understanding PRINCE2, SPOCE Project Management Limited, Ken Brandley 1997, ISBN: 1 902192 00 1
04	Key Skills, PRINCE2 Foundation (Ver. 4.0), User Guide, Key Skills Limited 1999
05	Peter T. Köhler, PRINCE2 Das Projektmanagement Framework, Springer 2006 , ISBN: 3 540 29181 4
06	Steffi Triest, PRINCE2, Gezielte Vorbereitung auf die Foundation- und die Practitioner-Prüfung,Redline GmbH, Heidelberg 2008, ISBN: 978 3 8266 1795 9
07	Van Haren Publishing, Project Management Based on PRINCE2, 3rd Edition, Van Haren Publishing 2005, ISBN: 978 90 77212 83 7
08	Nick Graham, PRINCE2 for DUMMIES, John Willes & Sons 2008, LTD, ISBN: 978 470 51919 6
09	Nadin Eben, PRINCE2 - Projektmanagement mit Methode, Grundlagenwissen und Vorbereitung für die Zertifizierungsprüfung, Addison Wesley , ISBN:978-3-8273-2542-6
10	PM Projektmagazin http://www.projektmagazin.de/magazin/abo/artikel/2008/2108-2.html
11	PRINCE2 Deutschland e.V. http://www.prince2-deutschland.de/de_2.html
12	CBT von Getronics PRINCE2 Foundation Lesson 1