Die vorliegende Ausarbeitung ist eine gute Grundlage für die Vorbereitung auf die Zertifizierung nach PRINCE2, Foundation und Practitoner Level, ohne Anspruch auf Vollständigkeit. Alle Inhalte basieren auf der offiziellen deutschen Übersetzung der fünften englischen Ausgabe 2009 „Erfolgreiche Projekte managen mit PRINCE2“ des Office of Government Commerce (OGC) und werden sinngemäß oder als Zitat wiedergegeben, welche jedoch ohne separat als solche kenntlich gemacht sind.

1. PRINCE2
EDITION
2009

2. Trademarks
Die
in
diesem
Dokument
verwendeten
Markennamen
und
Produktbezeichnungen
unterliegen
im
Allgemeinen
den
gesetzlichen
Bes;mmungen,
insbesondere
dem
warenzeichen-­‐,
marken-­‐
oder
patentrechtlichen
Schutz.
Alle
Inhalte
basieren
auf
der
offiziellen
deutschen
Übersetzung
der
fünFen
englischen
Ausgabe
2009
„Erfolgreiche
Projekte
managen
mit
PRINCE2“
des
Office
of
Government
Commerce
(OGC)
und
werden
sinngemäß
oder
als
Zitat
wiedergegeben
(Seitenverweise
in
eckigen
Klammern
oder
farbigen
Rahmen).
Es
wir
keine
Gewähr
für
die
Rich;gkeit
der
Inhalte
übernommen.
26.06.13
PRINCE2
Edi;on
2009
2

3. Einführung
(I)
Projekt
[3]
Ein
Projekt
ist
eine
für
einen
befristeten
Zeitraum
geschaffene
Organisa;on,
die
mit
dem
Zweck
eingerichtet
wurde,
ein
oder
mehrere
Produkte
in
Übereins;mmung
mit
einem
vereinbarten
Business
Case
zu
liefern.
Programm
[244]
Ein
Programm
ist
eine
für
einen
befristeten
Zeitraum
geschaffene
Organisa;on
zur
Koordina;on,
Lenkung
und
Kontrolle
mehrerer
zusammengehöriger
Projekte,
die
die
strategischen
Ziele
des
Unternehmens
unterstützen.
PorEolio
Alle
von
einer
Organisa;on
durchgeführten
Programme
und
Projekte.
Merkmale
eines
Projekts
[4]
• Veränderung
• Befristet
(eindeu;ger
Start,
eindeu;ges
Ende)
• Bereichsübergreifend
• Einzigar;g
• Unsicherheit
6
Dimensionen
(Variablen)
eines
Projekts
[5]
• Kosten
• Zeit
• Qualität
• Umfang
• Risiken
• Nutzen
Projektmanagement
[4]
...
ist
die
Planung,
Delegierung,
Überwachung
und
Steuerung
aller
Aspekte
eines
Projekts.
Dazu
gehören
die
Mo;va;on
der
Beteiligten
und
die
Projektziele
innerhalb
der
erwarteten
Dimensionen
(6)
eines
Projekts
zu
erreichen.
26.06.13
PRINCE2
Edi;on
2009
3

4. Einführung
(II)
Nutzen
von
PRINCE2
[8]
• Bewährte
Best
Prac;ces
und
Governance
• Bei
jeder
Art
von
Projekt
einsetzbar
• Weithin
anerkannt
und
verstanden,
einheitliche
Terminologie
• Klare
Rollen
und
Verantwortlichkeiten
• Produktorien;ert
• Auf
die
jeweilige
Managementebene
abges;mmte
Pläne
• „Steuern
nach
dem
Ausnahmeprinzip“
(Management
by
Excep;on)
erhöht
Effizienz
und
WirtschaFlichkeit
• Im
Fokus
steht
die
Erreichung
der
Ziele
des
Business
Case
• Umfassende
und
ra;onelle
Berichtsstruktur
• Gewährleistet,
das
alle
Stakeholder
bei
der
Planung
und
Entscheidungsfindung
angemessen
vertreten
sind
• Fördert
den
Erfahrungsaustausch
und
kon;nuierliche
Verbesserung
in
Organisa;onen
• Verstärkt
die
Kon;nuität
in
der
Projektarbeit
und
Wiederverwendbarkeit
der
Bestände
eines
Projekts
• Wertvolles
Diagnosewerkzeug
• Weltweite
Verbreitung
und
Verfügbarkeit
von
Spezialisten
Kunden-­‐/Lieferanten
Beziehung
[35]
• Der
Kunde
spezifiziert
das
angestrebte
Ergebnis
und
trägt
die
Kosten
des
Projekts
• Der
Lieferant
stellt
die
benö;gten
personellen
Ressourcen
und
das
Können
(Kenntnisse)
zur
Erbringung
der
Lösung
bereit
• Die
Beziehung
ist
geprägt
durch
unterschiedliche
Gründe
für
die
Durchführung
des
Projekts,
Managementsysteme,
Governance-­‐Strukturen
und
Unternehmenskulturen
-­‐>
Auswirkung
auf
Themen,
Prozesse
&
Managementprodukte
[-­‐>
251]
26.06.13
PRINCE2
Edi;on
2009
4

5. 4
Elemente
der
Methode
[6]
• 7
Prinzipien
• 7
Themen
(-­‐>
Verfahren)
• 7
Prozesse
(-­‐>
Ablauf)
• Anpassung
an
die
Projektumgebung
26.06.13
PRINCE2
Edi;on
2009
5

6. 7
Prinzipien
[11]
Ø Fortlaufende
geschä[liche
RechEergung
(Connued
Business
Jusficaon)
Das
Projekt
muss
einen
berech;gten
Grund
für
seinen
Start
haben
und
es
muss
fortwährend
gewährleistet
sein,
dass
(die
Gül;gkeit
der
Rechmer;gung)
der
Nutzen
beibehalten
wird
sowie
dokumen;ert
(Business
Case)
und
genehmigt
ist.
Ø Lernen
aus
Erfahrungen
(Learn
from
Experience)
Erfahrungen
aus
anderen
Projekten
oder
anderen
Quellen
werden
gezielt
mit
aufgenommen
und
die
gesammelten
Erfahrungen
im
laufenden
Projekt
festgehalten.
Ø Definierte
Rollen
und
Verantwortlichkeiten
(Defined
Roles
and
Responsibilies)
In
einem
Projekt
benö;gt
es
definierte
Rollen
und
Verantwortlichkeiten
innerhalb
einer
Organisa;onsstruktur,
in
der
die
Interessen
des
Unternehmens,
der
Benutzer
und
der
Lieferanten
vertreten
sind.
Ø Steuern
über
Managementphasen
(Manage
by
Stage)
Die
Planung,
Überwachung
und
Steuerung
ist
nach
Phasen
gegliedert.
Ø Steuern
nach
dem
Ausnahmeprinzip
(Manage
by
Excepon)
Toleranzen
(je
Projektdimension)
regeln
die
Handlungsvollmachten
jeder
Managementebene
des
Projektmanagemenoeams.
Ø Produktorienerung
(Focus
on
Products)
Das
Projekt
konzentriert
sich
auf
die
Festlegung
und
Lieferung
von
Produkten,
insbesondere
auf
deren
Qualitätskriterien.
Ø Anpassen
an
die
Projektumgebung
(Tailor
to
Suit
the
Project
Environment)
PRINCE2
wird
auf
die
Größe
(Umfang),
Umgebung,
Komplexität,
Bedeutung,
Fähigkeit
und
Risiken
eines
Projekts
angepasst.
26.06.13
PRINCE2
Edi;on
2009
6

7. 7
Themen
[19]
26.06.13
PRINCE2
Edi;on
2009
7
Business
Case
Business
Case
Dokumen;ert,
wie
und
wo
die
geschäFliche
Rechmer;gung
des
Projekts
erarbeitet,
überprüF
und
angepasst
wird.
Außerdem
klärt
es
die
Zuständigkeiten
für
die
geschäFliche
Rechmer;gung.
-­‐>
Sicherstellung,
dass
das
Projekt
während
der
gesamten
Laufzeit
auf
die
Ziele
der
Organisa;on
ausgerichtet
bleibt.
Organisaon
Organiza;on
Definiert
Rollen
und
Verantwortlichkeiten
des
Projektmanagemenoeams,
klärt
Delega;onswege
und
beschreibt
wer
in
einem
Projekt
was
zu
tun
hat.
Außerdem
iden;fiziert
das
Thema
die
Notwendigkeit
einer
Kommunika;onsmanagementstrategie
und
wann
und
wie
diese
erarbeitet
wird.
Qualität
Quality
Umfasst
die
Erläuterung
der
Elemente
einer
Qualitätsmanagementstrategie
und
beschreibt
wie,
in
welchen
Prozessen
und
in
welchem
Detaillierungsgrad
und
auf
welcher
Ebene
(Projekt,
Produkt,
Teilprodukt)
Qualität
definiert
und
überprüF
wird
-­‐>
Produktbeschreibung.
Pläne
Plans
Beschreibt,
welche
Pläne
in
einem
Projekt
vorhanden
sein
können
und
müssen,
wie
und
durch
wen
diese
erarbeitet
werden
und
welche
Elemente
sie
umfassen.
Risiken
Risk
Umfasst
die
Erläuterung
der
Elemente
einer
Risikomanagementstrategie
und
der
Verfahren
zur
Analyse
von
Risiken,
Planung
der
Gegenmaßnahmen
und
der
laufenden
Überprüfung
des
Risikostatus.
Es
regelt
die
Zuständigkeiten
für
die
Strategie
und
die
Umsetzung
der
Maßnahmen.
Änderung
Change
Beschreibt,
wie
offene
Punkte
(Änderungsanträge,
Spezifika;onsabweichungen,
Probleme/Anliegen),
die
mögliche
Auswirkungen
auf
ein
Projekt
haben
können,
bewertet
und
behandelt
werden
und
die
Erarbeitung
einer
Konfigura;onsmanagementstrategie
zur
sicheren
Dokumenta;on
und
Ablage
der
Lieferergebnisse.
Fortschrif
Progress
Umfasst
die
Mechanismen
für
die
Beobachtung
und
den
Vergleich
der
tatsächlich
erbrachten
Leistungen
mit
den
Planzielen,
die
Erstellung
einer
Prognose
für
die
Projektziele
und
die
Kontrolle
und
Steuerung
inakzeptabler
Abweichungen.
Ø Aspekte
des
Projektmanagements,
die
kon;nuierlich
behandelt
werden
müssen
Ø Spiegeln
den
chronologischen
Ablauf
eines
Projekts
wider
-­‐>
Verfahren

8. Themen
Business
Case
[23]
26.06.13
PRINCE2
Edi;on
2009
8
Roles
&
Responsibili;es
Errichtung
geeigneter
Mechanismen
für
die
Beurteilung,
ob
ein
Projekt
wünschenswert,
lohnend
und
realisierbar
ist
(bleibt),
um
auf
dieser
Grundlage
über
die
(weitere)
Inves;;on
entscheiden
zu
können.
Wünschenswert,
lohnend,
realisierbar
[23]
WÜNSCHENSWERT:
ausgewogenes
Verhältnis
zwischen
Kosten
/
Nutzen
/
Risiken
LOHNEND:
die
Produkte
bieten
den
erwarteten
Nutzen
REALISIERBAR:
die
angestrebten
Produkte
können
geliefert
werden
Output,
Ergebnis,
Nutzen
[24]
OUTPUT:
Spezialistenprodukte
eines
Projekts
(materiell
oder
immateriell)
ERGEBNIS:
die
aus
der
Anwendung
des
Outputs
resul;erende
Veränderung
NUTZEN:
messbare
Verbesserung,
die
aus
einem
Ergebnis
resul;ert
Neg.
Nebeneffekt
[29]
Nega;ves
Ergebnis;
tatsächliche
Konsequenzen
einer
Ak;vität
Inhalte
Business
Case
[267]
• Zusammenfassung
• Gründe
• Op;onen
(Null
Op;on
/
do
nothing,
Min
Op;on,
Min+
Op;on)
• Erwarteter
Nutzen
• Erwartete
nega;ve
Nebeneffekte
• Zeit
• Kosten
• Inves;;onsrechnung
• Hauptrisiken
Ø Entwurf
in
SU
(Bestandteil
der
Projektbeschreibung),
Detailierung
in
IP
und
Aktualisierung
in
allen
weiteren
Phasen
Managementprodukte
Nutzenrevisionsplan
(Benefits
Review
Plan)
[-­‐>
275]
Purpose
Notes

9. Themen
Organisaon
[35]
26.06.13
PRINCE2
Edi;on
2009
9
Lenkungsausschuss
(Project
Board)
Erfolg
des
Projekts
Projektleiter
(Project
Manager)
TagesgeschäF
des
Projekts
Projektsicherung
(Project
Assurance)
Überwachung
der
Leistung
des
Projekts
und
der
Produkte
unabhängig
vom
PL/TL
Änderungsausschuss
(Change
Authority)
Prüfung
und
Genehmigung
von
Änderungsanträgen
Teamleiter
(Team
Manager)
Lieferung
der
Produkte
des
Projekts
Projektunterstützung
(Project
Support)
Administra;v,
beratend,
planend,
etc.
Roles
&
Responsibili;es
Defini;on
und
Festlegung
der
Organisa;onsstruktur
des
Projekts
und
die
Zuordnung
der
Zuständigkeiten
und
Verantwortlichkeiten.
Stakeholder
[47]
Personen
oder
Gruppen,
die
am
Ergebnis
des
Projekts
interessiert
sind
oder
Einfluss
darauf
nehmen
Interessenvertreter
(Stakeholder)
eines
Projekts
[36]
• Unternehmen
(Company),
Sicherstellung,
dass
die
Zielsetzung
des
Projekts
Sinn
macht
und
sich
die
Inves;;on
rechnet
• Benutzer
(User),
Festlegung
der
Anforderung
zur
Realisierung
eines
Produkts
• Lieferant
(Supplier),
Durchführung
des
Projekts
nach
den
Wünschen
des
Kunden
Managementprodukte
Kommunika;onsmanagementstrategie
(Communica;on
Management
Strategy)
[48,
-­‐
>
271]
• Gibt
die
Art
und
Weise
und
Häufigkeit
der
Kommunika;on
mit
den
internen
und
externen
Parteien
eines
Projekts
vor.
• Im
Rahmen
des
Programmmanagements
Defini;on
der
Informa;onen
für
das
Programm
und
wie
diese
verbreitet
werden
Purpose
Notes
38

10. Kunde
(Client)
Projektmanagemenoeam
Themen
Organisaon
[38]
–
4
Managementebenen
26.06.13
PRINCE2
Edi;on
2009
10
Unternehmens-­‐
/
Programmmanagement
Benutzer
(User)
AuFraggeber
–
Vorsitzender
des
LA
(Execu;ve)
Benutzervertreter
(Senior
User)
Lieferant
(Supplier)
KundenvertriebsbeauFragter
(Customer
Account
Manager)
Lieferantenvertreter
(Senior
Supplier)
Entwicklungsabteilung
(Supplier
Skill
Management)
Lenkungsausschuss
(Project
Board)
AuFraggeber
–
Vorsitzender
des
LA
(Execu;ve)
Benutzervertreter
(Senior
User)
Lieferantenvertreter
(Senior
Supplier)
Projektleiter
(Project
Manager)
Teamleiter
(Team
Manager)
Lenken
Managen
Liefern
Änderungsausschuss
(Change
Authority)
Projektunterstützung
(Project
Support)
Projektsicherung
(Project
Assurance)

11. Themen
Qualität
[53]
26.06.13
PRINCE2
Edi;on
2009
11
Unternehmens-­‐
/
Programmorganisaon
Qualitätssicherung
(projekt-­‐extern)
Lenkungsausschuss
(Project
Board)
Projektsicherung
(projekt-­‐intern)
Rollen
des
Prüfungsteams
[62]
VORSITZENDER:
Moderator
PRÜFER:
Durchführender
PRODUKTPRÄSENTATOR
/
ERSTELLER:
Vertreter
aus
dem
betreffenden
Bereich
PRÜFUNGSADMINISTRATOR:
Protokollierung
Roles
&
Responsibili;es
Defini;on
und
Umsetzung
der
Mioel,
mit
denen
das
Projekt
Produkte
für
einen
bes;mmten
Zweck
erstellt
und
ihre
Eignung
für
diesen
Zweck
überprüF.
Qualitätsplanung
[54]
Defini;on
der
vom
Projekt
geforderten
Produkte
sowie
der
jeweiligen
Qualitätskriterien
(inkl.
Toleranzen),
die
Qualitätsprüfmethoden
und
die
Qualitätsverantwortlichkeiten
(inkl.
Know-­‐how
des
Erstellers
und
Prüfers)
-­‐>
vgl.
Qualitätskontrollpfad
[56,
Abb.
6.1]
Qualitätssteuerung
[61]
Implemen;erung,
Überwachung
und
Dokumenta;on
der
Qualitätsprüfmethoden
und
Verantwortlichkeiten,
die
in
der
Qualitätsmanagementstrategie
und
den
Produktbeschreibungen
bzw.
Arbeitspaketen
vereinbart
wurden.
Qualitätssicherung
[54]
Gibt
der
Unternehmens-­‐/Programmorganisa;on
die
Sicherheit,
dass
das
Projekt
angemessen
und
ordnungsgemäß
durchgeführt
wird
und
die
Standards
und
Richtlinien
des
Unternehmens-­‐/
Programmmanagements
einhält.
Projektsicherung
[55]
Gibt
den
Stakeholdern
des
Projekts
die
Sicherheit,
dass
das
Projekt
angemessen
und
ordnungsgemäß
durchgeführt
wird.
Ziele
der
Qualitätsprüfungstechnik
[62]
-­‐>
Prozess
MP
• Überprüfung
eines
Produkts
auf
Einhaltung
vordefinierter
Qualitätskriterien
• Schaffung
einer
breiten
Akzeptanz
• Bestä;gung
der
Fer;gstellung
und
AbnahmebereitschaF
des
Produkts
• Einfrieren
des
Produkts
für
die
Zwecke
der
Änderungssteuerung
Kundenqualitätserwartungen
vs.
Projektabnahmekriterien
[57]
Aus
allgemein
formulierten
Kundenqualitätserwartungen
werden
detaillierte
Abnahmekriterien
entwickelt,
d.h.
eine
priorisierte
Liste
messbarer
Defini;onen
der
Aoribute,
die
die
Produktgruppe
aufweisen
muss
-­‐>
Entwicklung
Produktbeschreibungen.
Managementprodukte
Projektbeschreibung
(Project
Brief)
[-­‐>285]
Projektendproduktbeschreibung
(Project
Product
Descrip;on)
[-­‐>
282]
Produktbeschreibung
(Product
Descrip;on)
[-­‐>
280]
Qualitätsregister
(Quality
Log)
[-­‐>
291]
Qualitätsmanagementstrategie
(Quality
Management
Strategy)
[-­‐>
290]
Purpose
Notes
54

12. Themen
Pläne
[71]
26.06.13
PRINCE2
Edi;on
2009
12
Roles
&
Responsibili;es
Defini;on
wie
die
Produkte
geliefert
werden,
was,
wo
und
wie,
von
wem
und
voraussichtlich
wann
und
mit
welchen
Kosten
erreicht
werden
soll.
Planungsebenen
[72]
(1)
Plan
erstellen
• PROJEKTPLAN:
(2)
Produkte
definieren
und
analysieren*,
(3)
Ak;vitäten
&
Abhängigkeiten
iden;fizieren,
(4)
Schätzungen
durchführen
(Ressourcen
und
Aufwand
für
Ak;vitäten),
(5)
Zeitplan
aufstellen,
(6)
Risiken
analysieren,
(7)
Plan
dokumen;eren
• PHASENPLÄNE:
Ebene
Managementphase,
jedoch
detaillierter
als
Projektplan
• TEAMPLÄNE:
Ebene
Arbeitspaket,
jedoch
detaillierter
als
Phasenplan
• AUSNAHMEPLÄNE:
Maßnahmen
als
Folge
einer
Toleranzabweichung
Aufgaben
der
produktbasierten
Planung
[73]
• (2.1)
Projektendproduktbeschreibung
(Project
Product
Descrip;on)
[-­‐>
282]
• (2.2)
Produktstrukturplan;
Produktzerlegung
bis
zur
gewünschten
Detaillierungs;efe
• (2.3)
Produktbeschreibung
(Product
Descrip;on)
[-­‐>
280]
• (2.4)
Produkmlussdiagramm;
Reihenfolge
und
Abhängigkeiten
der
Produkte
Darstellung
• Interne
Produkte
=
Rechtecke
• Externe
Produkte
=
Kreise
/
Ellipsen
Purpose
Notes

13. Themen
Risiken
(I)
[89]
26.06.13
PRINCE2
Edi;on
2009
13
Projektunterstützung
(Project
Support)
Risikoregister
Risikoeigentümer
(Risk
Owner)
verantwortlich
für
das
Management,
die
Überwachung
und
die
Kontrolle
eines
bes;mmten
Risikos
Risikobearbeiter
(Risk
Aconee)
verantwortlich
für
die
Ergreifung
einer
/
mehrerer
Maßnahmen
zur
Behandlung
eines
bes;mmten
Risikos
Roles
&
Responsibili;es
Unsicherheiten
iden;fizieren,
bewerten
und
steuern,
um
dadurch
die
Erfolgschancen
des
Projekts
zu
erhöhen.
Risiko
[89]
Ereignis(se),
deren
Eintreten
ungewiss
ist,
aber
deren
Eintreten
Auswirkungen
auf
die
Erreichung
der
Projektziele
haben
wird.
• BEDROHUNG:
unsicheres
Ereignis,
das
nega;ve
Auswirkungen
haben
könnte
• CHANCE:
unsicheres
Ereignis,
das
posi;ve
Auswirkungen
haben
könnte
Risikobereitscha[
vs.
Risikotoleranzen
[91]
• RISIKOBEREITSCHAFT:
BereitschaF
einer
Organisa;on
Risiken
einzugehen
• RISIKOTOLERANZEN:
Grenzwerte
der
Risikobelastung,
welche
als
akzeptabel
eingestuF
werden
und
die
bei
Überschreitung
die
Erstellung
des
Ausnahmeberichts
auslösen
Risikomanagementprozess
[92]
• IDENTIFIZIEREN:
(KONTEXT)
Beschaffung
von
Informa;onen
über
das
Projekt,
um
die
gefährdeten
Ziele
des
Projekts
zu
verstehen
und
die
Risikomanagementstrategie
aufstellen
zu
können;
(RISIKEN)
Erkennung
von
Bedrohungen
und
Chancen,
die
Auswirkungen
auf
die
Projektziele
haben
können
• BEWERTEN:
(EINSCHÄTZEN)
Eintrioswahrscheinlichkeit,
Auswirkung
und
Eintriosnähe
iden;fizierter
Bedrohungen
und
Chancen;
(BEURTEILEN)
genereller
Schweregrad
der
das
Projekt
gefährdenden
Risiken
• PLANEN:
Ergreifung
geeigneter
Maßnahmen
zur
Behandlung
der
iden;fizierten
Bedrohungen
und
Chancen,
um
im
Idealfall
Bedrohungen
zu
besei;gen
oder
zu
verringern
und
Chancen
zu
maximieren
-­‐>
Kategorien
der
Risikobehandlung
[98]
• IMPLEMENTIEREN:
Gewährleistung,
dass
geplante
Maßnahmen
zur
Behandlung
von
Risiken
durchgeführt
werden,
ihre
Effek;vität
kontrolliert
wird
und
Korrekturmaßnahmen
ergriffen
werden,
wenn
die
Behandlung
nicht
den
gewünschten
Erfolg
zeigt;
eindeu;ge
Zuordnung
von
Rollen
&
Verantwortlichkeiten
-­‐>
Risikoeigentümer,
-­‐bearbeiter
• KOMMUNIZIEREN:
Sicherstellung,
dass
Informa;onen
über
die
Bedrohungen
und
Chancen
des
Projekts
sowohl
innerhalb
des
Projekts
als
auch
extern
an
die
Steakholder
weitergegeben
werden
Purpose
Notes

14. Kategorien
der
Risikobehandlung
[98]
Risikobudget
[101]
Eine
im
Projektbudget
für
die
Finanzierung
bes;mmter
Maßnahmen
zur
Behandlung
der
Bedrohungen
und
Chancen
des
Projekts
reservierte
Summe.
Das
Risikobudget
sollte
so
bemessen
werden,
dass
die
bekannten
Risiken
abgedeckt
und
Reserven
für
unbekannte
Risiken
vorhanden
sind.
Managementprodukte
Risikomanagementstrategie
(Risk
Managements
Strategy)
[-­‐>
293]
Risikoregister
(Risk
Log)
[-­‐>
295]
Risikobeschreibung
[94]
URSACHE:
Risikoquelle,
Risikotreiber,
d.h.
poten;elle
Auslöser
EREIGNIS:
Erläuterung
der
Unsicherheit
bezogen
auf
die
Bedrohung
/
Chance
AUSWIRKUNG:
Konsequenzen,
die
sich
für
die
Ziele
des
Projekts
ergeben
würden,
wenn
dieses
Risiko
eintreten
würde
Risikowahrscheinlichkeit,
-­‐auswirkungen
und
–umgebung
[96]
Darstellung
in
einem
grafischen
Risikoprofil
zeigt
die
Situa;on
zu
einem
bes;mmten
Zeitpunkt
-­‐>
Momentaufnahme
der
Risikoumgebung
Inhärente
und
sekundäre
Risiken
sowie
Restrisiko
[97]
INHÄRENTE
RISIKEN:
innewohnendes
Risiko
SEKUNDÄRE
RISIKEN:
Risiken,
die
erst
nach
Behandlung
des
primären
/
eigentlichen
Risikos
auFreten
können
RESTRISIKO:
verbleibendes
Risiko
nach
der
Durchführung
von
Maßnahmen
zur
Behandlung
des
Risikos
Themen
Risiken
(II)
[89]
26.06.13
PRINCE2
Edi;on
2009
14
Notes
Bedrohungen
Chancen
Vermeiden
Ergreifen
Reduzieren
(Wahrscheinlichkeit
und/oder
Auswirkung)
Steigern
Eventualplan
(reduziert
nur
Auswirkung)
Übertragen
(reduziert
nur
Auswirkung)
Teilen
Teilen
Akzep;eren
Ablehnen

15. Themen
Änderungen
(I)
[105]
26.06.13
PRINCE2
Edi;on
2009
15
Roles
&
Responsibili;es
Iden;fika;on,
Bewertung
und
Steuerung
potenzieller
und
genehmigter
Änderungen
der
Baseline.
Offener
Punkt
[106]
Ungeplantes
Ereignis
das
eingetreten
ist
und
behandelt
werden
muss
Arten
offener
Punkte
[106]
ÄNDERUNGSANTRAG:
Vorschlag
zur
Änderung
einer
Baseline
SPEZIFIKATIONSABWEICHUNG:
zu
erfüllende
Anforderung,
die
derzeit
nicht
gegeben
ist
(Beachte:
Konzession
=
genehmigte
Spezifika;onsabweichung)
PROBLEM/ANLIEGEN:
sons;ge
Punkte,
dessen
Lösung
/
Eskala;on
Aufgabe
des
PM
sind
Änderungsbudget
[108]
Summe,
auf
die
sich
Kunde
und
Lieferant
zur
Finanzierung
der
Kosten
von
Änderungsanträgen
und
evtl.
Analysen
einigen
Managementprodukte
Konfigura;onsmanagementstrategie
(Configura;on
Management
Strategy)
[-­‐>
273]
Konfigura;onsdatensatz
(Configura;on
Item
Record)
[-­‐>272]
Offener-­‐Punkt-­‐Bericht
(Issue
Report)
[-­‐>276]
Register
offener
Punkte
(Issue
Register)
[-­‐>292]
ProduktstatusauskunF
(Product
Status
Account)
[-­‐>284]
Projekoagebuch
(Daily
Log)
[-­‐>289]
Purpose
Notes

16. Themen
Änderungen
(II)
[105]
Akvitäten
des
Konfiguraonsmanagements
[108]
Planen
Festlegung
der
für
das
Projekt
notwendigen
Erfassungs;efe
des
Konfigura;onsmanagements
und
überlegen,
wie
dieses
Niveau
erreicht
werden
kann
Iden;fizieren
Festlegung
des
Systems
zur
Spezifika;on
und
Iden;fika;on
von
Produktversionen
(Konfigura;onselemente)
auf
der
benö;gten
Erfassungs;efe
Steuern
Abnahme
und
Einfrieren
(Baseline
/
Bezugswert)
von
Produkten
sowie
Ausführung
von
Änderungen
nur
mit
Zus;mmung
der
zuständigen
Stellen
Status
protokollieren
Weitermeldung
aller
aktuellen
und
historischen
Daten
zu
jedem
einzelnen
Produkt
in
Form
einer
ProduktstatusauskunF
Verifizieren
und
Audit
Überprüfen
/
Kontrollieren,
ob
der
aktuelle
Status
aller
Produkte
mit
dem
genehmigten
und
in
den
Konfigura;onsdatensätzen
vermerkten
Produktstatus
übereins;mmt
26.06.13
PRINCE2
Edi;on
2009
16
Verfahren
zur
Steuerung
offener
Punkte
/
Änderungen
[109]
Erfassen
• Art
des
offenen
Punkts
festlegen
• Schweregrad
/
Priorität
festlegen
• Protokollieren
/
registrieren
Untersuchen
• Auswirkungen
auf
Ziele,
Business
Case
und
Risikoprofil
des
Projekts
bewerten
• Schweregrad
/
Priorität
prüfen
Vorschlagen
• Op;onen
iden;fizieren
• Op;onen
beurteilen
• Op;onen
empfehlen
Entscheiden
• Eskalieren,
wenn
delegierte
Befugnisse
überschrioen
werden
oder
• Empfohlene
Op;on
genehmigen,
ablehnen
oder
aufschieben
Implemen;eren
• Korrekturmaßnahme
einleiten
• Aufzeichnungen
und
Pläne
aktualisieren

17. Themen
Fortschrif
(I)
[117]
26.06.13
PRINCE2
Edi;on
2009
17
Lenkungsausschuss
(Project
Board)
Freigabe
von
Managementphasen
Roles
&
Responsibili;es
Einrichtung
von
Mechanismen
für
die
Beobachtung
und
den
Vergleich
der
tatsächlich
erbrachten
Leistungen
mit
den
Planzielen,
die
Erstellung
einer
Prognose
für
die
Projektziele
sowie
die
Kontrolle
und
Steuerung
inakzeptabler
Abweichungen.
Managementphasen
[120]
Abschnioe,
in
denen
das
Projekt
gesteuert
wird.
Am
Ende
der
Managementphasen
ist
der
Zeitpunkt,
an
dem
der
LA
den
Projekmortschrio
prüF
und
entscheidet,
die
nächste
Phase
freizugeben
(Grundlage
u.a.:
Business
Case,
Projektplan,
Phasenplan,
Risikoregister)
• Zusammenstellung
von
Ak;vitäten
/
Produkten,
deren
Lieferung
als
Einheit
erfolgt
• Anzahl
und
Länge
ergibt
sich
aus
Planungshorizont,
Entscheidungspunkte,
Art
&
Laufzeit
des
Projekts,
technischen
Phasen,
Programmak;vitäten,
Risiken
-­‐>
größere
Risiken
trennen,
Meilensteine
berücksich;gen
• LA
gibt
immer
nur
eine
Managementphase
frei!
Managementphasen
vs.
technische
Phasen
[122]
MANAGEMENTPHASEN:
stehen
für
die
Zusage
von
Ressourcen
und
die
Freigabe
von
Mioeln
-­‐>
keine
Überschneidungen
TECHNISCHE
PHASEN:
sind
durch
den
Einsatz
spezieller
Fachkenntnisse
charakterisiert
(Produkterstellung)
-­‐>
häufige
Überschneidungen
Ø Das
Ende
von
Management-­‐
und
technischen
Phasen
nach
Möglichkeit
zusammenlegen
Ereignisgesteuerte
vs.
zeitgesteuerte
Steuerungsmifel
[123]
Planen,
delegieren,
überwachen,
steuern
EREIGNISGESTEUERT:
kommen
bei
AuFreten
eines
bes;mmten
Ereignisses
zum
Einsatz
-­‐>
Steuerung
/
Entscheidungsfindung*
ZEITGESTEUERT:
kommen
in
bes;mmten
zeitlichen
Abständen
zum
Einsatz
-­‐>
Überwachung
/
Berichterstaoung**
Managementprodukte
Projekoagebuch
(Daily
Log)
[-­‐>289]
Erfahrungsprotokoll
(Lessons
Log)
[-­‐>270]
Arbeitspaket
(Work
Package)
[-­‐>264]
Phasenabschlussbericht
(End
Stage
Report)
[-­‐>277]*
Projektabschlussbericht
(End
Project
Report)
[-­‐>284]*
Erfahrungsbericht
(Lessons
Report)
[-­‐>269]
Teamstatusbericht
(Checkpoint
Report)
[-­‐>296]**
Projektstatusbericht
(Highlight
Report)
[-­‐>288]**
Ausnahmebericht
(Excep;on
Report)
[-­‐>266]*
Offener
Punkt
Bericht
(Issue
Report)
[-­‐>276]*
Purpose
Notes

18. Themen
Fortschrif
(II)
[117]
Toleranzbereiche
[118]
Toleranzen
auf
Projektebene
Toleranzen
auf
Phasenebene
Toleranzen
auf
Arbeitspaket-­‐
ebene
Toleranzen
auf
Produktebene
Zeit
Projektplan
Phasenplan
Arbeitspaket
Kosten
Projektplan
Phasenplan
Arbeitspaket
Umfang
Projektplan
Phasenplan
Arbeitspaket
Risiko
Risiko-­‐
management-­‐
strategie
Phasenplan
Arbeitspaket
Qualität
Projekt-­‐
endprodukt-­‐
beschreibung
Produkt-­‐
beschreibung
Nutzen
Business
Case
26.06.13
PRINCE2
Edi;on
2009
18
4
Managementebenen
Delega;on
von
Toleranzen
und
Berichterstaoung
über
erzielte
und
prognos;zierte
Fortschrioe
Ausnahme
[117]
Eine
Situa;on,
in
der
eine
Abweichung
über
die
vereinbarten
Toleranzgrenzen
hinaus
vorhersehbar
ist
Toleranzen
[117]
Zulässige
Abweichungen
von
den
Planvorgaben,
die
ohne
sofor;ge
Eskala;on
an
die
nächsthöhere
Managementebene
akzep;ert
werden
können
Notes
Unternehmens-­‐
/
Programmmanagement
(Enterprise
/
Program
Management)
Lenkungsausschuss
(Project
Board)
Projektleiter
(Project
Manager)
Teamleiter
(Team
Manager)
Projekooleranzen
Phasentoleranzen
Toleranzen
auf
Arbeitspaketebene
Projekmortschrio/
Ausnahmen
Fortschrio/Ausnahmen
In
der
Phase
Fortschrioe/Offene
Punkte
bei
Arbeitspaketen
• Offener
Punkt
Bericht
• Ausnahmebericht
• Ausnahmeplan
• Register
OP‘e
• Änderungsantrag
Spezifika;ons-­‐
abweichung

19. Prozesse
Überblick
26.06.13
PRINCE2
Edi;on
2009
19
Ø Vorbereiten
eines
Projekts
Star;ng
up
a
Project
(SU)
Ø Lenken
eines
Projekts
Direc;ng
a
Project
(DP)
Ø Ini;ierung
eines
Projekts
Ini;a;ng
a
Project
(IP)
Ø Steuern
einer
Phase
Controlling
a
Stage
(CS)
Ø Managen
der
Produktlieferung
Managing
Product
Delivery
(MP)
Ø Managen
eines
Phasenübergangs
Managing
a
Stage
Boundary
(SB)
Ø Abschließen
eines
Projekts
Closing
a
Project
(CP)
Prozess
• Strukturierte
Abfolge
von
Ak;vitäten
die
aus
(empfohlenen)
Maßnahmen
bestehen
und
auf
die
Erreichung
eines
bes;mmten
Ziels
gerichtet
ist
• Umwandlung
eines
definierten
Input
in
einen
definierten
Output
Notes

20. Prozesse
Managementphasen
&
-­‐ebenen
26.06.13
PRINCE2
Edi;on
2009
20
Vor
dem
Projekt
Ini;ierungs-­‐
phase
Nachfolgende
Phase(n)
Letzte
Phase
Lenken
Managen
Liefern
Lenkungsausschuss
Projektleiter
Teamleiter
Lenken
eines
Projekts
(DP)
Managen
der
Produktlieferung
(MP)
Managen
der
Produktlieferung
(MP)
Steuern
einer
Phase
(CS)
Managen
des
Phasen-­‐
übergangs
(SB)
Ini;ieren
des
Projekts
(IP)
Steuern
einer
Phase
(CS)
Managen
des
Phasen-­‐
übergangs
(SB)
Abschließen
eines
Projekts
(CP)
Vorbereiten
eines
Projekts
(SU)
Management-­‐
phasen
Management-­‐
ebenen
Accountable
Responsible

21. Prozesse
Vorbereiten
eines
Projekts
-­‐
Starng
up
a
Project
(SU)
[139]
26.06.13
PRINCE2
Edi;on
2009
21
• WirtschaFliche
Rechmer;gung
der
Ini;ierung
des
Projekts
(Business
Case
E.)
• Vorhandensein
aller
notwendigen
Verantwortlichkeiten
und
Befugnisse
für
die
Ini;ierung
des
Projekts
• Vorhandensein
ausreichender
Informa;onen
für
die
Defini;on
und
Bestä;gung
des
Projektumfangs
(Projektbeschreibung)
• Bewertung
von
Alterna;ven
zur
Durchführung
des
Projekts
und
Projektlösungsansatz
auswählen
• Geeignete
Personalbesetzung
für
die
Durchführung
der
Ini;ierungsphase
und/
oder
Projektmanagementrollen
• Planung
der
Ini;ierungsphase
• Effiziente
Zeitnutzung
Objec;ves
In
diesem
Prozess
wird
aus
einer
Idee
des
Unternehmens
eine
Projektbeschreibung
erstellt,
um
zu
entscheiden,
ob
das
Projekt
durchgeführt
werden
soll.
Projektmandat
(Project
Mandate)
[140]
• Alle
Informa;onen
die
ein
Projekt
auslösen
können,
z.B.
Machbarkeitsstudie
• Geeigneter
AuFraggeber
sollte
aus
Infos
iden;fiziert
werden
können
• Ableitung
/
Entwicklung
der
Projektbeschreibung
Business
Case
[267]
Dokumenta;on
der
Rechmer;gung
für
ein
Projekt,
basierend
auf
geschätzten
Kosten
im
Vergleich
zu
erwartetem
Nutzen
und
den
dagegenstehenden
Risiken
Projektbeschreibung
(Project
Brief)
[285]
• Ausgangsbasis
für
die
Entscheidungsfindung
durch
den
Lenkungsausschuss
bzgl.
der
Ini;ierungsphase
• Business
Case
Entwurf
ist
Bestandteil
der
Projektbeschreibung!
Ø Business
Case
und
Projektbeschreibung
erfordern
regelmäßige
und
häufige
Abs;mmungen
zwischen
Projektmanager,
Lenkungsausschuss
und
anderen
Interessengruppen
Ø Kundenqualitätserwartungen
>
Projektabnahmekriterien
>
Produktbeschreibungen
-­‐>
vgl.
Thema:
Qualität
Purpose
Context

22. Prozesse
Vorbereiten
eines
Projekts
-­‐
Starng
up
a
Project
(SU)
[139]
Unternehmens-­‐
/
Programmorganisaon
Projektmandat
Lenkungsausschuss
(Project
Board)
Freigabe
Ini;ierungsphase,
Projektbeschreibung,
Phasenplan,
Befugnisse
PM
Managementprodukte
• Projektbeschreibung
(Project
Brief)
• Projektendproduktbeschreibung
(Project
Product
Descrip;on)
• Business
Case
Entwurf
(Business
Case
DraF)
• Phasenplan
(Stage
Plan)
für
Ini;ierungsphase
• Erfahrungsprotokoll
(Lessons
Log)
• Projekoagebuch
(Daily
Log)
Roles
&
Responsibili;es
Notes
• Projektmandat
(Project
Mandate)
1. AuFraggeber
und
Projektmanager
ernennen
2. Vorhandene
Erfahrungen
erfassen
3. Projektmanagemenoeam
entwerfen
und
ernennen
4. Business-­‐Case-­‐Entwurf
erstellen
5. Projektlösungsansatz
auswählen
und
Projektbeschreibung
zusammenstellen
6. Ini;ierungsphase
planen
• Antrag
auf
Projek;ni;ierung
• Rollenbeschreibungen
• Projektlösungsansatz
• Managementprodukte
Input
Output
Ac;vi;es
26.06.13
PRINCE2
Edi;on
2009
22

23. Prozesse
Lenken
eines
Projekts
-­‐
Direcng
a
Project
(DP)
[153]
26.06.13
PRINCE2
Edi;on
2009
23
Sicherstellung,
dass
• Die
Befugnis
für
die
Ini;ierung
des
Projekts
vorhanden
ist
• Die
Befugnis
für
die
Lieferung
der
Projektprodukte
vorhanden
ist
• Die
Steuerung
und
Überwachung
des
Projekts
gegeben
ist
und
die
WirtschaFlichkeit
gewährleistet
bleibt
• Schniostelle
zum
Unternehmens-­‐
/
Programmmanagement
unterhalten
wird
• Die
Befugnis
für
einen
Abschluss
des
Projekts
vorhanden
ist
• Pläne
für
die
Realisierung
des
angestrebten
Nutzens
über
den
Projektabschluss
hinaus
gesteuert
und
geprüF
werden
Objec;ves
Der
Lenkungsausschuss
tri•
die
wesentlichen
Entscheidungen
für
das
Projekt
und
entscheidet
bei
Ausnahmen
über
den
Fortgang
des
Projekts.
Lenkungsausschuss
(Project
Board)
• Steuern
nach
dem
Ausnahmeprinzip
• Überwacht
das
Projekt
durch
vorgelegte
Berichte
• Steuert
das
Projekt
mithilfe
einer
kleinen
Anzahl
von
Entscheidungspunkten
Projektleiter
(Project
Manager)
• Informiert
den
Lenkungsausschuss
bei
Ausnahmesitua;onen
Ø Während
des
Projekts
ist
ein
kon;nuierlicher
Informa;onsaustausch
zwischen
Lenkungsausschuss
und
Unternehmens-­‐/Programmmanagement
notwendig
Ø Der
Kommunika;onsbedarf
und
die
Art
des
Informa;onsaustauschs
werden
in
der
Kommunika;onsmanagementstrategie
festgelegt
Purpose
Context

24. Prozesse
Lenken
eines
Projekts
-­‐
Direcng
a
Project
(DP)
[153]
Roles
&
Responsibili;es
Notes
• Antrag
auf
Projek;ni;ierung
• Antrag
auf
Ausführung
des
Projekts
• Antrag
auf
Ausführung
des
nächsten
Phasen-­‐
oder
Ausnahmeplans
• Ausnahme
melden
• Weisungsanfragen
• Empfehlung
des
Projektabschlusses
• Managementprodukte
1. Ini;ierung
freigeben
2. Projekt
freigeben
3. Phasen-­‐
oder
Ausnahmeplan
freigeben
4. Ad-­‐hoc-­‐Anweisungen
geben
5. Projektabschluss
freigeben
• Freigabe
der
Projek;ni;ierung
• Freigabe
des
Projekts
• Freigabe
Phasen-­‐
oder
Ausnahmeplan
• Anforderung
Ausnahmeplan
• Ratschläge
/
Entscheidungen
des
LA
• Freigabe
Projektabschluss
• Managementprodukte
Input
Output
Ac;vi;es
26.06.13
PRINCE2
Edi;on
2009
24

25. Prozesse
Iniieren
eines
Projekts
-­‐
Iniang
a
Project
(IP)
[167]
26.06.13
PRINCE2
Edi;on
2009
25
Verständnis
schaffen
• Gründe
für
das
Projekt,
den
erwarteten
Nutzen
und
damit
verbundenen
Risiken
• Umfang
der
durchzuführenden
Arbeiten
und
welche
Produkte
geliefert
werden
sollen
• Wie
und
wann
die
Projektprodukte
geliefert
werden
und
welche
Kosten
entstehen
• Wer
an
der
Entscheidungsfindung
im
Projekt
beteiligt
ist
• Wie
die
geforderte
Qualität
erreicht
wird
• Wie
Baselines
festgelegt
und
gesteuert
werden
• Wie
Risiken,
offene
Punkte
und
Änderungen
iden;fiziert,
bewertet
und
gesteuert
werden
• Wie
der
Projekmortschrio
überwacht
und
gesteuert
wird
• Wer
wann
welche
Informa;onen
in
welchem
Format
benö;gt
• Wie
die
Projektmanagementmethode
an
die
Anforderungen
des
Projekts
angepasst
wird
Objec;ves
Es
wird
aufgezeigt,
wie
das
Projekt
ablaufen
soll
und
seine
Ziele
erreicht.
Schaffung
einer
soliden
Grundlage,
die
der
Organisa;on
ein
klares
Bild
davon
vermioelt,
was
mit
den
geplanten
Arbeiten
verbunden
ist,
bevor
größere
finanzielle
Mioel
zugesagt
werden.
Grundstein
für
die
erfolgreiche
Durchführung
eines
Projekts
[168]
Um
das
Engagement
aller
Beteiligten
zu
gewinnen,
muss
jedem
Einzelnen
klar
sein,
• Warum
das
Projekt
notwendig
ist,
• Welches
Ziel
damit
verfolgt
wird,
• Wie
das
Ergebnis
zu
erreichen
ist
und
• Welche
Verantwortlichkeiten
er
selbst
hat.
Ø Lenkungsausschuss
entscheidet,
ob
das
Projekt
ausreichend
auf
die
Unternehmens-­‐
oder
Programmziele
abges;mmt
ist
und
seine
Fortsetzung
genehmigt
werden
kann
Ø Projektmanager
erstellt
Managementprodukte,
die
für
die
vom
Lenkungsausschuss
vorgegebenen
Steuerungsmechanismen
benö;gt
werden
Projektleitdokumentaon
(Project
Iniaon
Document)
[287]
Defini;on
des
Projekts,
d.h.
Lieferung
der
Grundlagen
für
• Die
Steuerung
des
Projekts
und
• Die
Beurteilung
der
insgesamt
erzielten
Erfolge.
Ø Gibt
die
Richtung
und
den
Umfang
des
Projekts
vor
Ø Bildet
zusammen
mit
dem
Phasenplan
den
„Vertrag“
zwischen
Projektmanager
und
Lenkungsausschuss
Purpose
Context

26. Prozesse
Iniieren
eines
Projekts
-­‐
Iniang
a
Project
(IP)
[167]
Lenkungsausschuss
(Project
Board)
• Freigabe
Projekt,
Projektleitdokumenta;on,
Nutzenrevisionsplan
• Review
Erfahrungsprotokoll
• 4
Managementstrategien
(Risiko-­‐,
Qualitäts-­‐,
Konfigura;ons-­‐,
Kommunika;ons-­‐)
• Stakeholderanalyse
• Produktbasierte
Planungstechnik
Managementprodukte
• Projektleitdokumenta;on
(Process
Ini;a;on
Document
–
PID)
• Produktbeschreibung
(Product
Descrip;on)
• Nutzenrevisionsplan
(Benefits
Review
Plan)
• Konfigura;onsdatensatz
(Configura;on
Item
Record)
• Qualitätsregister
(Quality
Log)
• Register
offener
Punkte
(Issue
Register)
• Risikoregister
(Risk
Log)
Roles
&
Responsibili;es
Notes
• Freigabe
der
Projek;ni;ierung
1. Risikomanagementstrategie
erstellen
2. Qualitätsmanagementstrategie
erstellen
3. Konfigura;onsmanagementstrategie
erstellen
4. Kommunika;onsmanagementstrategie
erstellen
5. Projektsteuerungsmioel
(Berichtswesen
und
PhasenauFeilung)
einrichten
6. Projektplan
erstellen
7. Business
Case
verfeinern
(ab
IP
eigenständiges
Dokument)
8. Projektleitdokumenta;on
zusammenstellen
• Antrag
auf
Ausführung
des
Projekts
• Managementprodukte
Input
Output
Ac;vi;es
26.06.13
PRINCE2
Edi;on
2009
26

27. Prozesse
Steuern
einer
Phase
-­‐
Controlling
a
Stage
(CS)
[187]
26.06.13
PRINCE2
Edi;on
2009
27
• Konzentra;on
der
Arbeiten
auf
die
Lieferung
der
für
die
Phase
geplanten
Produkte
unter
Einhaltung
der
Zielvorgaben
und
Toleranzen
• Sicherstellung,
dass
Risiken
und
offene
Punkte
unter
Kontrolle
sind
• Wiederholte
Prüfung
Business
Case
Objec;ves
Diese
Phase
beschreibt
das
tagtägliche
Management
durch
den
PL,
d.h.
anfallende
Arbeiten
zuzuweisen
und
zu
verfolgen,
offene
Punkte
zu
bearbeiten,
erzielte
Fortschrioe
an
den
LA
zu
berichten
und
ggfs.
Korrekturmaßnahmen
einzuleiten,
damit
die
Phase
innerhalb
der
Toleranzen
bleibt.
Ø Dieser
Prozess
wird
in
jeder
Managementphase
angewendet,
in
der
Spezialistenprodukte
hergestellt
werden
Ø Laufende
Kontrolle
der
durchgeführten
Arbeiten
ist
für
den
letztendlichen
Erfolg
eines
Projekts
unverzichtbar
Purpose
Context

28. Prozesse
Steuern
einer
Phase
-­‐
Controlling
a
Stage
(CS)
[187]
Lenkungsausschuss
(Project
Board)
• Ad-­‐hoc
Anweisungen
geben
• Reak;on
auf
Ausnahmebericht
• Überprüfung
Projektstatusbericht
Managementprodukte
• Arbeitspakete
(Work
Packages)
• Ausnahmebericht
(Excep;on
Reports)
• Offener-­‐Punkt-­‐Bericht
(Issue
Report)
• Projektstatusbericht
(Highlight
Reports)
• Teamstatusbericht
(Checkpoint
Report)
• Qualitätsregister
(Quality
Log)
• Register
offener
Punkte
(Issue
Register)
• Risikoregister
(Risk
Log)
Roles
&
Responsibili;es
Notes
• Freigabe
Phasen-­‐
oder
Ausnahmeplan
• Anforderung
Ausnahmeplan
• Ratschläge
/
Entscheidungen
des
LA
• Abgeschlossenes
Arbeitspaket
• Neuer
offener
Punkt
• Neues
Risiko
• Managementprodukte
1. Arbeitspaket
freigeben
2. Status
eines
Arbeitspakets
prüfen
3. Abgeschlossene
Arbeitspakete
entgegennehmen
4. Phasenstatus
prüfen
5. Über
Projektstatus
berichten
6. Offene
Punkte
und
Risiken
erfassen
und
untersuchen
7. Offene
Punkte
und
Risiken
eskalieren
8. Korrekturmaßnahme
einleiten
• Freigabe
der
Lieferung
eines
Arbeitspakets
• Ausnahme
melden
• Weisungsanfragen
• Managementprodukte
Input
Output
Ac;vi;es
26.06.13
PRINCE2
Edi;on
2009
28

29. Prozesse
Managen
der
Produktlief.
-­‐
Managing
Product
Delivery
(MP)
[207]
26.06.13
PRINCE2
Edi;on
2009
29
Sicherstellung,
dass
• Arbeiten
an
Produkten,
die
dem
Team
zugeteilt
wurden,
ordnungsgemäß
genehmigt
und
vereinbart
werden
• TL,
Teammitglieder
und
Lieferanten
sich
darüber
im
Klaren
sind,
was
hergestellt
werden
soll
und
welcher
Arbeits-­‐,
Kosten-­‐
bzw.
Zeitaufwand
dafür
veranschlagt
wurde
• Die
Lieferung
der
geplanten
Produkte
den
Erwartungen
entspricht
und
innerhalb
der
Toleranzgrenzen
erfolgt
• Der
PL
in
einem
vereinbarten
Turnus
präzise
Informa;onen
über
den
erzielten
Fortschrio
erhält,
damit
die
Erwartungen
gesteuert
werden
Objec;ves
Steuerung
und
Kontrolle
der
Beziehung
zwischen
PL
und
TL,
indem
formelle
Anforderungen
an
die
Annahme,
Ausführung
und
Lieferung
der
Projektarbeiten
gestellt
werden.
Perspekve
/
Prozess
• Teamleiter
-­‐>
Sicherstellung
der
Produktlieferung
• Projektleiter
-­‐>
Managen
einer
Phase
Ø TL
stellt
sicher,
das
Produkte
vom
Team
erstellt
und
an
das
Projekt
geliefert
werden
Ø Bei
externen
Lieferanten,
die
nicht
mit
PRINCE2
arbeiten,
definiert
der
Prozess
die
notwendige
Schniostelle
zwischen
TL
und
dem
PRINCE2
Projektmanagement
Arbeitspaket
• Produktbeschreibung
• 6
Dimensionen
+
Toleranzen
• Risiken
• Anforderungen
an
Berichterstaoung
Purpose
Context

30. Prozesse
Managen
der
Produktlief.
-­‐
Managing
Product
Delivery
(MP)
[207]
Managementprodukte
• Arbeitspakete
(Work
Packages)
• Teamplan
(Team
Plan)
• Teamstatusbericht
(Checkpoint
Report)
• Qualitätsregister
(Quality
Log)
• Konfigura;onsdatensatz
(Configura;on
Item
Record)
Roles
&
Responsibili;es
Notes
• Freigabe
der
Lieferung
eines
Arbeitspakets
• Managementprodukte
1. Arbeitspaket
annehmen
2. Arbeitspaket
ausführen
3. Arbeitspaket
abliefern
• Abgeschlossenes
Arbeitspaket
• Neuer
offener
Punkt
• Neues
Risiko
• Managementprodukte
Input
Output
Ac;vi;es
26.06.13
PRINCE2
Edi;on
2009
30

31. Prozesse
Managen
eines
Phasenüber.
-­‐
Managing
a
Stage
Boundary
(SB)
[215]
26.06.13
PRINCE2
Edi;on
2009
31
• Bestä;gung
gegenüber
dem
LA,
dass
die
im
Phasenplan
genannten
Produkte
fer;ggestellt
sind
und
abgenommen
wurden
• Phasenplan
für
nächste
Phase
erstellen
• PID
prüfen
und
ggfs.
aktualisieren
• LA
alle
Infos
bereitstellen,
so
dass
die
Erfolgsaussichten
des
Projekts
bewertet
werden
können
und
die
Risikositua;on
dargestellt
werden
kann
• Erfahrungen
zusammenfassen
• Freigabe
nächster
Phase
beantragen
Objec;ves
Zusammenstellung
der
Ergebnisse
durch
den
PL,
so
dass
LA
den
Erfolg
der
aktuellen
Phase
beurteilen,
die
nächste
Phase
freigeben,
den
aktualisierten
Projektplan
prüfen,
die
geschäFliche
Rechmer;gung
verifizieren
und
die
Risiken
abschätzen
kann.
Bedeutung
von
„nächste
Phase“
Ø Phasenplan
aufgrund
des
Phasenabschlussberichts
ODER
Ø Ausnahmeplan
aufgrund
des
Ausnahmeberichts,
d.h.
Toleranzgrenzen
wurden
überschrioen
Ende
einer
Phase
Ø Prüfung,
ob
das
Projekt
weiterhin
auf
das
rich;ge
Ziel
ausgerichtet
ist
Ø Entscheidung,
ob
das
Projekt
im
Verlauf
korrigiert
oder
abgebrochen
werden
muss
Ø Defini;on
von
Mechanismen
zur
Einleitung
von
Korrekturmaßnahmen,
die
das
Projekt
wieder
auf
Kurs
bringen
Ø Produktabnahmen
erfolgen
während
einer
Phase
Ø Freigabe
von
Phasen
erfolgen
am
Ende
einer
Phase
Purpose
Context

32. Prozesse
Managen
eines
Phasenüber.
-­‐
Managing
a
Stage
Boundary
(SB)
[215]
Lenkungsausschuss
(Project
Board)
• Freigabe
Phasen-­‐
oder
Ausnahmeplan,
Projektleitdokumenta;on,
Nutzenrevisionsplan,
Phasenabschlussbericht
• Verteilung
Erfahrungsbericht
Managementprodukte
• Projektleitdokumenta;on
(Process
Ini;a;on
Document
–
PID)
• Nutzenrevisionsplan
(Benefits
Review
Plan)
• Phasenplan
(Next
Stage
Plan)
• Ausnahmeplan
(Excep;on
Report)
• Erfahrungsbericht
(Lessons
Log)
• Phasenabschlussbericht
(End
Stage
Report)
• Qualitätsregister
(Quality
Log)
• Register
offener
Punkte
(Issue
Register)
• Risikoregister
(Risk
Log)
Roles
&
Responsibili;es
Notes
• Erreichung
des
Phasenübergangs
(IP
oder
CS)
• Anforderung
Ausnahmeplan
• Managementprodukte
1. Nächste
Phase
planen
2. Projektplan
aktualisieren
3. Business
Case
aktualisieren
4. Über
Phasenabschluss
berichten
5. Ausnahmeplan
erstellen
• Antrag
auf
Ausführung
des
nächsten
Phasen-­‐
oder
Ausnahmeplans
• Managementprodukte
Input
Output
Ac;vi;es
26.06.13
PRINCE2
Edi;on
2009
32

33. Prozesse
Abschließen
eines
Projekts
-­‐
Closing
a
Project
(CP)
[229]
26.06.13
PRINCE2
Edi;on
2009
33
• Verifizierung,
ob
die
Projektprodukte
von
den
Benutzern
abgenommen
wurden
• Sicherstellung,
dass
nach
Auflösung
des
Projekts
die
Produkte
durch
das
Unternehmen
übernommen
werden
können
• Vergleich
der
Leistung
des
Projekts
mit
der
Baseline
• Bewertung
des
realisierten
/
verbleibenden
Nutzens
• Sicherstellung,
dass
für
alle
offenen
Punkte
und
Risiken
Empfehlungen
für
Folgeak;onen
vorliegen
Objec;ves
Dieser
Prozess
bestä;gt
die
Abnahme
des
Projektendprodukts
und
bewertet
ob
die
in
der
ursprünglichen
PID
definierten
Ziele
(oder
auch
genehmigte
Änderungen
dieser
Ziele)
erreicht
worden
sind
oder
mit
dem
Projekt
keine
weiteren
Ergebnisse
erzielt
werden
können.
Projektabschluss
• Ende
des
Projekts
wird
durch
alle
Projektbeteiligten
bestä;gt
• Iden;fizierung
und
Dokumenta;on
aller
nicht
erreichten
Ziele,
so
dass
diese
zu
einem
späteren
Zeitpunkt
erneut
angegangen
werden
können
• Übergabe
der
Verantwortung
/
EigentümerschaF
an
den
Kunden
und
Beendigung
der
Aufgaben
des
Projektmanagemenoeams
• Dokumenta;on
von
Empfehlungen
für
Folgeak;vitäten
Ø Planmäßiger
Abschluss
ODER
Ø Vorzei;ger
Abschluss
Purpose
Context

34. Prozesse
Abschließen
eines
Projekts
-­‐
Closing
a
Project
(CP)
[229]
Lenkungsausschuss
(Project
Board)
• Freigabe
Projektabschluss,
Nutzenrevisionsplan,
Projektabschlussbericht
• Bestä;gung
Business
Case
• Verteilung
Erfahrungsbericht
Managementprodukte
• Projektplan
(Project
Plan)
• Nutzenrevisionsplan
(Benefits
Review
Plan)
• Erfahrungsbericht
(Lessons
Learned
Report)
• ProduktstatusauskunF
(Product
Status
Account)
• Projektabschlussbericht
(End
Project
Report)
• Qualitätsregister
(Quality
Log)
• Register
offener
Punkte
(Issue
Register)
• Risikoregister
(Risk
Log)
• Konfigura;onsdatensatz
(Configura;on
Item
Record)
• Projekoagebuch
(Daily
Log)
Roles
&
Responsibili;es
Notes
• Vorzei;ger
Abschluss
oder
sich
näherndes
Projektende
• Managementprodukte
1. Planmäßigen
Abschluss
vorbereiten
2. Vorzei;gen
Abschluss
vorbereiten
3. Produkte
übergeben
4. Projekt
bewerten
5. Projektabschluss
empfehlen
• Empfehlung
des
Projektabschlusses
• Empfehlungen
für
Nachfolgeak;onen
• Managementprodukte
Input
Output
Ac;vi;es
26.06.13
PRINCE2
Edi;on
2009
34

35. Anpassung
an
die
Projektumgebung
(I)
• PRINCE2
ist
eine
generische
Methode
und
kann
in
allen
Projekten
angewendet
werden
• Sinnvolle
Anpassung
an
die
jeweilige
Projektumgebung,
jedoch
dürfen
die
Grundprinzipien
nicht
angepasst
werden,
diese
müssen
immer
angewendet
werden
• Abgrenzung
zwischen
Integra;on
in
Unternehmen
und
Anpassung
der
Methode
Ø Integraon
ist
Aufgabe
der
Organisa;on
bei
Einführung
von
PRINCE2
Ø Anpassung
ist
Aufgabe
des
Projektmanagemenoeams
zur
Abs;mmung
der
Methode
auf
den
Kontext
eines
konkreten
Projekts
Integraon
Anpassung
Prozessverantwortlichkeiten
Themen
Berücksich;gung
der
Projektgröße
Terminologie
Standards
(Vorlagen,
Defini;onen)
Managementprodukte
Training
und
Entwicklung
Rollenbeschreibungen
Einbindung
in
GeschäFsprozesse
Prozesse
Werkzeuge
Dokumenta;on
-­‐>
PID
Prozesssicherung
26.06.13
PRINCE2
Edi;on
2009
35
Extern
Intern
Organisa;onsübergreifend
Größenordnung
Externer
Kunde/Lieferant
Komplexität
der
Lösung
Unternehmensstandards
Reife
des
Teams
Innerhalb
eines
Programms
Projektart
&
Lebenszyklusmodell
Reife
der
Organisa;on
Terminologie
Geografie
Unternehmenskultur
Projektpriorität
Kernpunkte
Einflussfaktoren
für
Anpassung
35
241
242
241

36. Anpassung
an
die
Projektumgebung
(II)
Ø Anpassen
der
Themen
Sämtliche
Themen
können
in
ihrem
Umfang
und
in
der
Ausprägung
der
Anwendung
angepasst
werden.
Dies
geschieht
durch
gezielte
Defini;on
in
den
jeweiligen
Managementstrategien
oder
den
Projektsteuerungsmioeln.
Ø Anpassen
der
Terminologie
Begrifflichkeiten
für
Elemente,
Prozesse,
Ak;vitäten
und
Managementprodukte
können
angepasst
werden,
sofern
diese
in
Funk;on
und
Umfang
entsprechend
sind.
Ø Anpassen
der
Produktbeschreibungen
für
die
Managementprodukte
Anpassung
der
Inhalte
von
Managementprodukten
zur
Steigerung
der
Akzeptanz
der
Anwender
und
/
oder
Zusammenfassung
bei
kleineren
Projekten.
Ø Anpassen
der
Rollenbeschreibungen
Wahrnehmung
mehrerer
Rollen
durch
eine
Person
bei
kleineren
Projekten.
Minimum
sind
drei
Personen:
ein
Kunde
(Benutzervertreter
&
AuFraggeber),
ein
Lieferantenvertreter
und
ein
Projektmanager
(übernimmt
die
Rolle
des
Teammanagers
und
der
Projektunterstützung),
andernfalls
Prüfung
ob
es
sich
um
ein
Projekt
oder
vielleicht
nur
um
eine
Aufgabe
in
der
Linie
handelt.
Ø Anpassen
der
Prozesse
Entsprechend
der
Projektumgebung
müssen
auch
die
Prozesse
angepasst
werden,
z.B.
Zusammenfassung
der
Prozesse
„Vorbereiten
eines
Projektes“
und
„Ini;ieren
eines
Projektes“.
Ø Anpassungen
für
besonders
kleine
Projekte
z.B.
Projekte
mit
geringen
Risiken,
geringen
Kosten,
geringer
Bedeutung
und
kaum
Gefährdung
der
Organisa;on
bei
einem
Fehlschlag
– Mind.
zwei
Managementphasen,
z.B.
Ini;ierungsphase
und
Lieferphase
– Projektmanager
übernimmt
die
Rolle
des
Teammanagers
und
der
Projektunterstützung
– Lenkungsausschuss
besteht
aus
zwei
Personen
und
übernimmt
die
Rolle
der
Projektsicherung
– Nutzung
von
4
Managementprodukten:
Projekoagebuch,
Projektleitdokumenta;on,
Projektstatusbericht
und
Projektabschlussbericht
26.06.13
PRINCE2
Edi;on
2009
36

37. 26
Managementprodukte
[263]
Übersicht
Referenz
(Baseline)
–
12
Ø Definieren
bes;mmte
Aspekte
des
Projekts
als
Ausgangsbasis
und
unterliegen
nach
der
Freigabe
der
Änderungssteuerung
• Projektbeschreibung
(Project
Brief)
• Projektendproduktbeschreibung
(Project
Product
Descri
• PROJEKTLEITDOKUMENTATION
(PROJECT
INITIATION
DOCUMENT)*
• Business
Case
(Business
Case)
• Risikomanagementstrategie
(Risk
Management
Strategy
• Konfigura;onsmanagementstrategie
(Configura;on
Man
• Qualitätsmanagementstrategie
(Quality
Management
St
• Kommunika;onsmanagementstrategie
(Communica;on
• Plan
/
Projekt-­‐,
Phasen-­‐,
Team-­‐,
Ausnahmeplan
(Excep;
• Produktbeschreibung
(Product
Descrip;on)
• Arbeitspaket
(Work
Package)
• Nutzenrevisionsplan
(Benefits
Review
Plan)
Aufzeichnungen
(Records)
-­‐
6
Ø Sind
dynamische
Managementprodukte,
die
Informa;onen
über
den
Projekmortschrio
enthalten
• Erfahrungsprotokoll
(Lessons
Log)
• Konfigura;onsdatensatz
(Configura;on
Item
Record)
• Projekoagebuch
(Daily
Log)
• Qualitätsregister
(Quality
Log)
• Register
offener
Punkte
(Issue
Register)
• Risikoregister
(Risk
Log)
Berichte
(Reports)
-­‐
8
Ø Sind
Managementprodukte,
die
eine
Momentaufnahme
des
Status
bes;mmter
Aspekte
des
Projekts
liefern
• Ausnahmebericht
(Excep;on
Report)
• Erfahrungsbericht
(Lessons
Report)
• Offener-­‐Punkt-­‐Bericht
(Issue
Report)
• Phasenabschlussbericht
(End
Stage
Report)
• ProduktstatusauskunF
(Product
Status
Account)
• Projektabschlussbericht
(End
Project
Report)
• Projektstatusbericht
(Highlight
Report)
• Teamstatusbericht
(Checkpoint
Report)
26.06.13
PRINCE2
Edi;on
2009
37
*
Weitere
Inhalte
des
PID:
- Projektdefini;on
- Projektlösungsansatz
- Struktur
des
Projektmanagemenoeams
- Rollenbeschreibungen
- Projektsteuerungsmioel
- PRINCE2-­‐Anpassung

38. 26
Managementprodukte
[263]
Baseline
Projektbeschreibung
(Project
Brief):
stellt
eine
gute
und
solide
Ausgangsbasis
für
die
Ini;ierung
des
Projekts
bereit
Projektendproduktbeschreibung
(Project
Product
Descripon):
Sonderform
der
Produktbeschreibung
in
der
definiert
ist,
was
das
Projekt
letztendlich
liefern
muss
Projektleitdokumentaon
(Project
Iniaon
Document):
Defini;on
des
Projekts,
d.h.
Lieferung
der
Grundlagen
für
die
Steuerung
des
Projekts
und
die
Beurteilung
der
insgesamt
erzielten
Erfolge.
Gibt
die
Richtung
und
den
Umfang
des
Projekts
vor
und
Bildet
zusammen
mit
dem
Phasenplan
den
„Vertrag“
zwischen
Projektmanager
und
Lenkungsausschuss.
Business
Case
(Business
Case):
Dokumenta;on
der
Rechmer;gung
für
ein
Produkt,
basierend
auf
den
geschätzten
Kosten
im
Vergleich
zu
dem
erwarteten
Nutzen
und
den
dagegenstehenden
Risiken
Risikomanagementstrategie
(Risk
Management
Strategy):
beschreibt
die
zu
verwendenden
Risikomanagemenoechniken
und
–standards
und
legt
Zuständigkeiten
fest
Konfiguraonsmanagementstrategie
(Configuraon
Management
Strategy):
legt
fest,
wie
und
von
wem
die
Produkte
eines
Projekts
kontrolliert
und
geschützt
werden
Qualitätsmanagementstrategie
(Quality
Management
Strategy):
definiert
die
zu
verwendenden
Qualitätstechniken
und
–standards
und
legt
Zuständigkeiten
fest
Kommunikaonsmanagementstrategie
(Communicaon
Management
Strategy):
beschreibt
die
Kommunika;onswege
und
die
Häufigkeit
der
Kommunika;on
mit
den
Parteien
innerhalb
und
außerhalb
des
Projekts.
Ermöglicht
Einbindung
von
Stakeholdern
in
den
Kommunika;onsfluss.
Plan
/
Projekt-­‐,
Phasen-­‐,
Team-­‐,
Ausnahmeplan
(Project,
Stage,
Team,
Excepon
Plan):
ein
Plan
beschreibt
wie
und
wann
die
Ziele
eines
Projekts
realisiert
werden
sollen,
indem
die
wich;gsten
dem
Umfang
des
Plans
entsprechenden
Produkte,
Ak;vitäten
und
Ressourcen
aufgezeigt
werden
Produktbeschreibung
(Product
Descripon):
Beschreibung
des
Produkts
in
Bezug
auf
Art,
Zweck,
Funk;on
und
Umfang
Arbeitspaket
(Work
Package):
Summe
der
Informa;onen
zu
einem
oder
mehreren
Produkten,
damit
die
Verantwortung
für
die
Lieferung
übergeben
werden
kann
Nutzenrevisionsplan
(Benefits
Review
Plan):
zeigt
wie
und
wann
festgestellt
werden
kann,
ob
ein
Projekt
den
vom
Benutzervertreter
erwarteten
Nutzen
erzielt
hat
26.06.13
PRINCE2
Edi;on
2009
38

39. 26
Managementprodukte
[263]
Aufzeichnungen
/
Berichte
Erfahrungsprotokoll
(Lessons
Log):
sammelt
gute
und
schlechte
Erfahrungen,
die
für
dieses
oder
zukünFige
Projekt(e)
von
Nutzen
sein
können
Konfiguraonsdatensatz
(Configuraon
Item
Record):
Bereitstellung
von
Datensätzen,
in
denen
Status,
Version
und
Variante
der
einzelnen
Konfigura;onselemente
sowie
die
Beziehungen
zwischen
diesen
beschrieben
sind
Projekfagebuch
(Daily
Log):
dient
der
Aufzeichnung
von
formlos
gehandhabten
offenen
Punkten,
erforderlichen
Maßnahmen
oder
wich;gen
Ereignissen,
die
in
keinem
anderen
Register
/
Protokoll
erfasst
werden
Qualitätsregister
(Quality
Log):
Zusammenfassung
aller
geplanten
/
durchgeführten
Qualitätsmanagementak;vitäten
und
Informa;onen
für
Phasenabschlussberichte
und
den
Projektabschlussbericht
Register
offener
Punkte
(Issue
Register):
Erfassung
und
Pflege
aller
formell
zu
bearbeitenden
offenen
Punkte
Risikoregister
(Risk
Log):
Erfassung
und
Pflege
aller
Risiken
/
Chancen
mit
Angabe
des
Status
und
der
bisherigen
Entwicklung
Ausnahmebericht
(Excepon
Report):
Erstellung,
wenn
ein
Phasen-­‐
oder
Projektplan
voraussichtlich
die
Toleranzgrenzen
überschreitet
Erfahrungsbericht
(Lessons
Report):
Weitergabe
von
Erfahrungen,
die
auch
anderen
Projekten
zugute
kommen
können
Offener-­‐Punkt-­‐Bericht
(Issue
Report):
umfasst
die
Beschreibung,
Auswirkungsanalyse
und
Empfehlungen
zur
Behandlung
eines
Änderungsantrags,
einer
Spezifika;onsabweichung
oder
eines
Problems
/
Anliegens
Phasenabschlussbericht
(End
Stage
Report):
liefert
eine
Zusammenfassung
der
bis
zu
dem
betreffenden
Zeitpunkt
erzielten
Fortschrioe,
einen
Überblick
über
den
Projektstatus
und
eine
ausreichende
Informa;onsgrundlage
für
den
LA,
damit
dieser
über
die
nächsten
Projektschrioe
entscheiden
kann
Produktstatusauskun[
(Product
Status
Account):
informiert
innerhalb
bes;mmter
Parameter
über
den
Status
von
Produkten
Projektabschlussbericht
(End
Project
Report):
Vergleich
und
Dokumenta;on
der
effek;v
erzielten
Ergebnisse
mit
den
Vorgaben
in
der
zu
Anfang
des
Projekts
freigegebenen
Version
der
PID
Projektstatusbericht
(Highlight
Report):
informiert
den
LA
/
die
Steakholder
in
den
vom
LA
gewünschten
Intervallen
über
den
Stand
des
Projekts
und
die
erzielten
Fortschrioe
Teamstatusbericht
(Checkpoint
Report):
wird
in
bes;mmten,
im
Arbeitspaket
festgelegten
Abständen
erstellt,
um
über
den
Status
des
Arbeitspakets
zu
berichten
26.06.13
PRINCE2
Edi;on
2009
39

40. Vielen
Dank
T:
+49
(0)
341
3502606
F:
+49
(0)
341
3502630
M:
+49
(0)
170
3277551
info@itbc2.de
www.itbc2.de