1. Was ist PRINCE2 und wer nutzt es?
PRINCE2 ist die weltweit verbreitetste strukturierte Projektmanagement-Methode außerhalb Nordamerikas. Sie wurde 1989 vom britischen Government Central Computer and Telecommunications Agency entwickelt — ursprünglich für IT-Projekte der Regierung. Heute gehört die Methode der AXELOS (gemeinsames Joint Venture mit Capita) und wird in über 150 Ländern angewendet, mit dem Schwerpunkt in UK, Niederlande, Deutschland, Australien und Polen.
Typische Anwender sind öffentliche Verwaltungen (UK Government Mandates es), Banken und Versicherungen (klare Audit-Trails durch dokumentierte Entscheidungen), Beratungen (skalierbares Rahmenwerk über Projekte hinweg) und Infrastrukturunternehmen (Großprojekte mit vielen Stakeholdern). In Deutschland sind ca. 25 % aller Projektmanager mit einer PRINCE2-Zertifizierung ausgestattet, in UK über 60 %.
Was PRINCE2 von anderen Methoden unterscheidet: Während PMBOK eine Wissenssammlung ist und Scrum ein Vorgehensmodell, gibt PRINCE2 einen konkreten End-to-End-Ablauf vor — von der Projektvorbereitung bis zum formalen Abschluss. Es ist außerdem eine der wenigen Methoden, die Tailoring als eigenes Prinzip führt: Du musst PRINCE2 nicht 1:1 anwenden, sondern an dein Projekt anpassen.
2. Die 7 Prinzipien
Die Prinzipien sind das Fundament — sie gelten immer, in jedem PRINCE2-Projekt, ohne Ausnahme. Sie sind universell, selbsterklärend und stärken die Grundhaltung des Projektmanagers.
- Fortlaufende geschäftliche Rechtfertigung: Der Business Case muss zu jedem Zeitpunkt gültig sein. Ändert sich die Rechtfertigung, wird das Projekt abgebrochen oder angepasst — nicht „aus Tradition" weitergeführt.
- Lernen aus Erfahrungen: Lessons Learned werden am Anfang gesammelt (aus vergangenen Projekten), während der Durchführung dokumentiert und am Ende dem Unternehmen zurückgegeben. Pflicht-Artefakt: das Lessons Log.
- Definierte Rollen und Verantwortlichkeiten: Drei Stakeholder-Gruppen müssen vertreten sein: Auftraggeber (Business), Anwender (User) und Lieferant (Supplier). Ohne diese Triade kein PRINCE2-Projekt.
- Steuern über Managementphasen: Das Projekt wird in mindestens zwei Phasen geteilt (Initiierung + ≥1 Durchführungsphase). Am Ende jeder Phase entscheidet das Steuerungsgremium über die Fortsetzung.
- Steuern nach dem Ausnahmeprinzip: Jede Ebene hat definierte Toleranzen (Zeit, Kosten, Qualität, Scope, Risiko, Nutzen). Solange das Projekt im Toleranzbereich läuft, entscheidet der Projektmanager autonom. Erst bei Überschreitung wird eskaliert.
- Produktorientierung: Geplant wird nicht nach Aktivitäten, sondern nach Lieferobjekten („Produkten"). Jedes Produkt hat eine Produktbeschreibung mit Qualitätskriterien. Diese Sichtweise erzwingt Klarheit über das „Was" vor dem „Wie".
- Anpassen an die Projektumgebung: PRINCE2 ist eine Methode, kein Vorschriftenkatalog. Du musst sie an Projektgröße, Komplexität, Branche und Kultur anpassen. Tailoring wird im PID („Project Initiation Documentation") begründet dokumentiert.
Häufiger Fehler: Tailoring wird mit „PRINCE2 weglassen" verwechselt. Tailoring bedeutet aber: alle 7 Prinzipien gelten weiterhin, du passt nur die Umsetzung (Dokumentationstiefe, Rollenkombination, Phasenanzahl) an die Projektrealität an.
3. Die 7 Themen
Themen sind kontinuierliche Aspekte, die während des gesamten Projekts gemanagt werden müssen. Sie beantworten die Frage: Worauf muss ich permanent achten?
| Thema | Kernfrage | Hauptartefakt |
|---|---|---|
| Business Case | Warum? | Business Case Dokument |
| Organisation | Wer? | Organigramm + Rollenbeschreibungen |
| Qualität | Was muss das Ergebnis leisten? | Qualitätsmanagementansatz + Qualitätsregister |
| Pläne | Wie und wann? | Projektplan, Phasenplan, Teamplan |
| Risiko | Was kann schiefgehen? | Risikoregister |
| Änderung | Wie gehen wir mit Anpassungen um? | Issue Register, Change Control Approach |
| Fortschritt | Wo stehen wir? | Highlight Report, Checkpoint Report, Exception Report |
Die Themen sind miteinander verzahnt: Der Business Case treibt Entscheidungen, die Organisation legt fest, wer entscheidet, die Pläne übersetzen die Strategie in Aktivitäten — und Risiko, Qualität, Änderung und Fortschritt überwachen die laufende Umsetzung.
4. Die 7 Prozesse
Prozesse beschreiben den chronologischen Projektablauf — von der ersten Idee bis zum offiziellen Abschluss. Jeder Prozess hat einen klaren Zweck, definierte Eingaben, Aktivitäten und Ausgaben.
- Vorbereiten eines Projekts (Starting Up a Project, SU): Bevor das Projekt offiziell startet. Es wird geprüft, ob das Projekt überhaupt sinnvoll ist. Ergebnis: ein Project Brief, eine erste Risikoeinschätzung und die Benennung des Projektmanagement-Teams. Dauer: typisch 1–3 Wochen.
- Lenken eines Projekts (Directing a Project, DP): Der Steuerungsausschuss (Project Board) entscheidet an Phasenübergängen, ob das Projekt weiterläuft, angepasst oder abgebrochen wird. Dieser Prozess läuft parallel über die gesamte Projektlaufzeit.
- Initiieren eines Projekts (Initiating a Project, IP): Das eigentliche Projektsetup. Hier entstehen das PID (Project Initiation Documentation), der detaillierte Business Case, der Projektplan und alle Strategien (Risiko, Qualität, Konfiguration, Kommunikation).
- Steuern einer Phase (Controlling a Stage, CS): Tagesgeschäft des Projektmanagers in jeder Durchführungsphase: Arbeitspakete autorisieren, Fortschritt überwachen, Issues und Risiken managen, Highlight Reports schreiben.
- Managen der Produktlieferung (Managing Product Delivery, MP): Aus Sicht des Teammanagers / Lieferanten: Arbeitspakete übernehmen, ausführen, Qualität sichern, fertig melden.
- Managen eines Phasenübergangs (Managing a Stage Boundary, SB): Am Ende jeder Phase: Bewertung der laufenden Phase, Planung der nächsten Phase, Aktualisierung des Business Case und Risikoregisters, Vorlage zur Freigabe ans Project Board.
- Abschließen eines Projekts (Closing a Project, CP): Geplanter oder vorzeitiger Projektabschluss. Übergabe an die Linienorganisation, Lessons Learned, Abnahmedokumentation, formales Projektende.
5. PRINCE2 vs. PMBOK vs. Agile
Die häufigste Frage bei der Methodenauswahl: Wann PRINCE2, wann PMBOK, wann Agile?
| Kriterium | PRINCE2 | PMBOK | Agile (Scrum) |
|---|---|---|---|
| Typ | Prozessmodell | Wissensstandard | Vorgehensmodell |
| Herkunft | UK Government, 1989 | PMI USA, 1987 | Agile Manifest, 2001 |
| Stärke | Governance, klare Entscheidungspunkte | Breite, Vollständigkeit (49 Prozesse, 10 Wissensgebiete) | Anpassungsfähigkeit, schnelles Feedback |
| Schwäche | Dokumentationsschwer, wenig Werkzeuge | Sehr umfangreich, schwer komplett anzuwenden | Schwächer bei Fixed-Scope / Fixed-Date |
| Best Fit | Public Sector, Compliance-Projekte, Großprojekte | Vielfältige Projekttypen, US-amerikanischer Kontext | Software, Produktentwicklung, F&E |
| Zertifizierung | Foundation + Practitioner | PMP, CAPM | PSM, CSM, PSPO |
Praxis-Empfehlung: Die drei Methoden schließen sich nicht aus. PRINCE2 Agile (offizielle Erweiterung seit 2015) kombiniert die Governance-Stärke von PRINCE2 mit der Lieferflexibilität agiler Frameworks. Konkret heißt das: PRINCE2 regelt das „Management", Scrum oder Kanban regeln das „Doing".
6. Wann lohnt sich PRINCE2 — und wann nicht?
PRINCE2 ist nicht universell die beste Wahl. Es entfaltet seinen Wert vor allem in strukturbedürftigen Umgebungen.
PRINCE2 lohnt sich, wenn:
- Das Projekt mehrere Auftraggeber/Stakeholder-Gruppen hat, die abgestimmt entscheiden müssen
- Es regulatorische oder Compliance-Anforderungen gibt (Banken, Pharma, öffentlicher Sektor)
- Der Business Case starken Schwankungen unterliegt und regelmäßige Reviews braucht
- Das Projekt über mehrere Monate oder Jahre läuft und klare Phasenübergänge braucht
- Du Lieferanten managen musst (klare Schnittstelle Team Manager ↔ Supplier)
PRINCE2 ist nicht die beste Wahl, wenn:
- Das Projekt klein ist (< 3 Monate, < 5 Personen) und der Overhead nicht gerechtfertigt
- Anforderungen extrem volatil sind und ein vollagiles Setup besser passt
- Das Team noch nie mit strukturierter Methodik gearbeitet hat (Lernkurve!)
- Es keine Bereitschaft gibt, Rollen sauber zu trennen (Board, PM, Team Manager)
Praxistipp: Wenn dein Projekt 50.000 € überschreitet und mehr als 2 Stakeholder-Gruppen hat, ist PRINCE2-Tailoring fast immer eine bessere Wahl als „freistil PM". Reduziere die Dokumentation auf 4–5 Kerndokumente (Business Case, PID, Risikoregister, Highlight Report, Lessons Log) und behalte die Prinzipien bei.
7. Zertifizierung: Foundation und Practitioner
Die offizielle PRINCE2-Zertifizierung erfolgt über akkreditierte Trainings-Provider (ATOs). Sie besteht aus zwei Stufen:
PRINCE2 Foundation
Bestätigt das Grundverständnis der Methode. Multiple-Choice-Prüfung mit 60 Fragen in 60 Minuten, Bestehensgrenze 55 % (33 von 60). Kein Vorwissen erforderlich. Vorbereitungszeit: 3 Tage Kurs + 8–12 Stunden Eigenstudium. Kosten in DACH: 1.200–2.000 € inkl. Prüfung.
PRINCE2 Practitioner
Bestätigt die Fähigkeit, PRINCE2 in realen Projekten anzuwenden. Szenario-basierte Prüfung mit 70 Fragen in 150 Minuten, Bestehensgrenze 55 %. Voraussetzung: bestandene Foundation-Prüfung. Vorbereitungszeit: weitere 2 Tage Kurs + 15–20 Stunden Eigenstudium. Kosten: zusätzlich 900–1.500 €.
Re-Registration: Practitioner ist 3 Jahre gültig, danach ist eine kürzere Re-Registration-Prüfung erforderlich (oder kontinuierliche CPD-Punkte über das My AXELOS Programm).
8. PRINCE2 in der Praxis: kompaktes Beispiel
Beispiel: Einführung eines neuen CRM-Systems bei einem 500-Mitarbeiter-Unternehmen, Budget 280.000 €, Laufzeit 9 Monate.
Vorbereitung (SU, 2 Wochen): Projektsponsor (Vertriebsleiter) beauftragt einen Project Mandate. Project Brief entsteht: Probleme im aktuellen Tool, Zielzustand, ungefährer Aufwand 280k €, geschätzter ROI 18 Monate. Project Board konstituiert: Executive (CFO), Senior User (Vertriebsleiter), Senior Supplier (IT-Leiter).
Initiierung (IP, 4 Wochen): PID mit detailliertem Business Case, vier Phasen (Setup, Migration, Pilot, Rollout), Risikoregister mit 23 Risiken, Kommunikationsstrategie. Project Board genehmigt — Phase 1 startet.
Phasen 1–4 (CS + SB, je 6–10 Wochen): Highlight Reports alle 2 Wochen, Stage-Boundary-Reviews am Ende jeder Phase. Bei Migration: ein kritisches Risiko materialisiert (Datenqualität schlechter als angenommen). Toleranz reicht nicht — Exception Report ans Board. Entscheidung: 6 Wochen länger, 32k € mehr. Business Case bleibt valide. Weiter.
Abschluss (CP, 2 Wochen): Lessons Learned dokumentiert (u.a. „Datenqualität immer früher prüfen"). Übergabe an Linienorganisation. Project Board akzeptiert formal — Projekt geschlossen.
Was war hier PRINCE2-spezifisch? Drei Dinge: (1) Die klare Triade (Executive / Senior User / Senior Supplier) zwang die Entscheider an einen Tisch. (2) Das Ausnahmeprinzip verhinderte permanente Eskalation — nur eine echte Eskalation in 9 Monaten. (3) Die Phasenstruktur erlaubte Anpassung ohne das Gesamtprojekt zu gefährden.
9. Fazit
PRINCE2 ist kein „Lieblingsthema", sondern ein bewährtes Werkzeug für Situationen, in denen Klarheit über Rollen, Phasen und Eskalationswege wichtiger ist als Flexibilität. Wer es als „bürokratisch" abtut, hat oft nicht verstanden, dass alle 7 Prinzipien — inklusive Tailoring — gelten. Der Aufwand kann radikal an die Projektgröße angepasst werden.
Für deutsche Projektmanager ist PRINCE2 besonders wertvoll bei Kunden aus UK, NL, AU oder dem öffentlichen Sektor — und in Projekten mit komplexer Stakeholder-Landschaft. Die Foundation-Zertifizierung ist ein guter Einstieg (3 Tage Investment), Practitioner ein klares Karriere-Signal (weitere 2 Tage). Wer Projekte planen oder steuern muss, profitiert auch ohne Zertifikat von den 7 Prinzipien — sie sind universell anwendbar.