~/prince2/referenz

Prüfungsreifes Wissen,
strukturiert statt gestapelt.

PRINCE2 Project Management Foundation (Version 7) – die komplette Nachschlage-Sammlung für deine Prüfungsvorbereitung: Fachbegriffe, alle Themenelemente, Modelle und Prüfungsfragen. Ohne Login, jederzeit teilbar.

Glossar öffnen Alle 183 Fragen
Foundation Practitioner
183Fragen 35Elemente 125Glossar
Eigene Unterseiten: Glossar Themen Modelle Fragen

Fachbegriff-Glossar

Lade…

Lern-Podcasts & Videos

Kurze Audio- und Video-Lektionen zu wichtigen Themen für unterwegs.

Lade Podcasts...

Wichtige Modelle & Merkhilfen

🧭 7 Prinzipien

Die Leitsätze — alle sieben müssen angewendet werden

1
Fortlaufende geschäftliche Rechtfertigung — Jederzeit ein tragfähiger Business Case
2
Lernen aus Erfahrung — Lessons suchen, festhalten, anwenden
3
Definierte Rollen & Verantwortlichkeiten — Business-, User- und Supplier-Interessen vertreten
4
Steuern über Management-Phasen — Planen und kontrollieren Phase für Phase
5
Steuern nach dem Ausnahmeprinzip — Toleranzen setzen, nur bei Überschreitung eskalieren
6
Fokus auf Produkte — Produkte mit Qualitätskriterien vor der Aktivität
7
Anpassen an das Projektumfeld — Tailoring nach Größe, Umfeld und Risiko
Merkhilfe: Ein Projekt ist nur dann PRINCE2, wenn ALLE sieben Prinzipien angewendet werden.
🛠️ 7 Practices

Früher "Themes" — durchgängig im Projekt anzuwenden

1
Business Case — Rechtfertigung und Nutzen
2
Organizing — Rollen und Verantwortlichkeiten
3
Plans — Produktbasierte Planung
4
Quality — Qualitätskriterien und -methoden
5
Risk — Risiken steuern, Risk Register
6
Issues — Change Control, Off-Specifications
7
Progress — Toleranzen, Kontrollen, Berichte
Umbenennungen zur 6. Edition: Organization→Organizing, Change→Issues. Größter Prüfungsblock (60%).
🔄 7 Prozesse

Der Ablauf von der Idee bis zum Abschluss

1
Starting Up a Project (SU) — Lohnend und machbar?
2
Directing a Project (DP) — Steuerung durch das Project Board
3
Initiating a Project (IP) — Fundament und PID
4
Controlling a Stage (CS) — Tagesgeschäft des PM
5
Managing Product Delivery (MP) — Work Packages liefern
6
Managing a Stage Boundary (SB) — Phasenübergang planen
7
Closing a Project (CP) — Geordneter Abschluss
DP läuft durchgängig über dem Ganzen; SU liegt noch vor der Projektinitiierung.
🧩 Die 5 integrierten Elemente

Das Gerüst von PRINCE2 Version 7

1
Prinzipien — Die 7 unverzichtbaren Leitsätze
2
People — Menschen — neu als eigenes Element in V7
3
Practices — Die 7 durchgängigen Aspekte (früher Themes)
4
Prozesse — Die 7 Schritte von SU bis CP
5
Projektkontext — Umfeld, in das PRINCE2 eingepasst wird
Häufige Prüfungsfalle: People ist das NEUE fünfte Element der 7. Edition.
👥 Project Board & Rollen

Wer entscheidet, wer vertritt, wer liefert

1
Executive — Trägt den Business Case, letzte Entscheidung
2
Senior User — Vertritt die Nutzer und den erwarteten Nutzen
3
Senior Supplier — Vertritt die Lieferseite und Ressourcen
4
Project Manager — Führt das Projekt im Tagesgeschäft
5
Team Manager — Verantwortet die Produkterstellung
6
Project Assurance — Unabhängige Prüfung im Auftrag des Boards
7
Project Support — Administrative Unterstützung, PMO
Das Project Board = Executive + Senior User + Senior Supplier. Der Executive ist immer eine einzelne Person.

Syllabus-Landkarte

35 Themenelemente über 5 Bereiche. Klicke auf ein Element für eine Lernhilfe.

📐 Schlüsselkonzepte (5)
Definition von Projekt und Projektmanagement
Was ein Projekt von Routinearbeit unterscheidet, temporär und wertorientiert
Die fünf integrierten Elemente von PRINCE2
Prinzipien, People, Practices, Prozesse und Projektkontext im Zusammenspiel
Aspekte der Projektleistung (Performance-Ziele)
Nutzen, Kosten, Zeit, Qualität, Umfang, Risiko und Nachhaltigkeit steuern
Outputs, Outcomes und Benefits
Ergebnis vs. Wirkung vs. messbarer Nutzen — eine klassische Prüfungsfalle
Vorgehensansätze zur Lieferung
Linear-sequenziell, iterativ-inkrementell und hybrid
🧭 Die 7 Prinzipien (7)
Fortlaufende geschäftliche Rechtfertigung
Continued Business Justification — ohne tragfähigen Business Case kein Projekt
Lernen aus Erfahrung
Learn from Experience — Lessons werden gesucht, dokumentiert und genutzt
Definierte Rollen, Verantwortlichkeiten und Beziehungen
Wer entscheidet, wer liefert, wer vertritt Business/User/Supplier
Steuern über Management-Phasen
Manage by Stages — Planung und Kontrolle Phase für Phase
Steuern nach dem Ausnahmeprinzip
Manage by Exception — Toleranzen je Performance-Ziel, Eskalation erst bei Überschreitung
Fokus auf Produkte
Focus on Products — klar definierte Produkte mit Qualitätskriterien vor der Aktivität
Anpassen an das Projektumfeld
Tailor to Suit the Project — PRINCE2 wird an Größe, Umfeld und Risiko angepasst
🤝 People – Menschen im Projekt (7)
Bedeutung von Menschen für den Projekterfolg
Warum People ein eigenes integriertes Element der 7. Edition ist
Führung und Management
Leadership vs. Management — Richtung geben und gleichzeitig steuern
Organisationsökosystem und Kultur
Umfeld, Werte und Kultur, in denen das Projekt wirkt
Change (Veränderung) und Betroffene
Menschen durch Veränderung begleiten, Widerstände adressieren
Kommunikation und Stakeholder-Einbindung
Zielgerichteter Austausch mit allen Beteiligten
Zusammenarbeit und Teams
Wirksame Teams bilden, Rollen und Verantwortung klären
People im Bezug zur Organizing-Practice
People-Faktoren wirken in allen Practices, mit Schwerpunkt Organizing
🛠️ Die 7 Practices (8)
Business Case
Rechtfertigung, erwarteter Nutzen und Nutzenmanagement über den gesamten Lebenszyklus
Organizing (früher Organization)
Rollen und Verantwortlichkeiten: Project Board, Project Manager, Team Manager u.a.
Plans (Pläne)
Projekt-, Phasen- und Team-Pläne; produktbasierte Planung
Quality (Qualität)
Qualitätskriterien, Qualitätsmethoden, Quality Register und Product Descriptions
Risk (Risiko)
Risiken identifizieren, bewerten, steuern; Risk Register und Risikohaltung
Issues (früher Change)
Umgang mit Issues, Change Requests, Off-Specifications; Change Control
Progress (Fortschritt)
Toleranzen, Kontrollen, Berichte; Steuerung nach dem Ausnahmeprinzip
Management-Produkte je Practice
Welche Baseline-, Record- und Report-Produkte zu welcher Practice gehören
🔄 Die 7 Prozesse (8)
Starting Up a Project (SU)
Vorprüfung: Ist das Projekt lohnend und machbar? Project Brief, Executive/PM
Directing a Project (DP)
Steuerung durch das Project Board — Freigaben und Ausnahme-Entscheidungen
Initiating a Project (IP)
Fundament legen: PID, Baselines, Strategien und Kontrollen
Controlling a Stage (CS)
Tagesgeschäft des Project Managers innerhalb einer Phase
Managing Product Delivery (MP)
Schnittstelle zum Team Manager: Work Packages annehmen, liefern, übergeben
Managing a Stage Boundary (SB)
Phasenübergang: Bericht, Plan der nächsten Phase, aktualisierter Business Case
Closing a Project (CP)
Geordneter Abschluss: Abnahme, Übergabe, Lessons, Nutzenprüfung planen
Prozessmodell und Management-Phasen
Wie die 7 Prozesse über die Phasen ineinandergreifen

Alle Prüfungsfragen 🎯 Practitioner
183 Fragen 141 Single 13 Multi 0 Offen

Die 7 Practices
Rollen im Szenario I [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO "Kundenportal 2.0": Die Mustermann GmbH führt ein neues Kunden-Self-Service-Portal ein. Executive: Frau Dr. Keller (Vertrieb). Senior User: Herr Aydın (Kundenservice). Senior Supplier: Frau Nowak (IT, inkl. externer Dienstleister). Projektmanager: Herr Vogt. Budget 420.000 € (davon 90.000 € Reserve). 4 Stages über 9 Monate. Wer trägt im Projekt die Gesamtverantwortung für den Business Case (Reduktion Support-Anrufe um 30%)?
❌ Herr Aydın (Senior User)
❌ Frau Nowak (Senior Supplier)
✅ Frau Dr. Keller (Executive)
❌ Herr Vogt (Projektmanager)
Frau Dr. Keller als Executive trägt die Gesamtverantwortung für den Business Case.
Merksatz:
Die Executive (Frau Dr. Keller) sitzt auf dem Geldkoffer und bürgt persönlich dafür, dass sich das Projekt am Ende auch rechnet (Business Case).

Warum die anderen falsch sind:
Herr Aydın (A): Vertritt als Senior User nur die Anwenderinteressen, nicht den übergeordneten wirtschaftlichen Erfolg.
 Frau Nowak (B): Liefert als Senior Supplier nur die technische Lösung, trägt aber kein geschäftliches Risiko.
  • Herr Vogt (D): Steuert als Project Manager nur das operative Tagesgeschäft, nicht die strategische Rentabilität.
Rollen im Szenario II [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO "Kundenportal 2.0": Die Mustermann GmbH führt ein neues Kunden-Self-Service-Portal ein. Executive: Frau Dr. Keller (Vertrieb). Senior User: Herr Aydın (Kundenservice). Senior Supplier: Frau Nowak (IT, inkl. externer Dienstleister). Projektmanager: Herr Vogt. Budget 420.000 € (davon 90.000 € Reserve). 4 Stages über 9 Monate. Wessen Interessen vertritt Herr Aydın primär als Senior User?
❌ Die der Geschäftsleitung der Mustermann GmbH als Auftraggeber des Projekts
❌ Die der internen IT-Abteilung als technische Umsetzerin des Portals
✅ Die der künftigen Nutzenden (Kundschaft und Support-Team)
❌ Die des externen Dienstleisters als vertraglich gebundener Lieferant
Herr Aydın vertritt die Interessen der künftigen Nutzer:innen — Kundschaft und internes Support-Team.
Merksatz:
Der Senior User ist der Anwalt der User (Nutzenden) – Herr Aydın aus dem Kundenservice vertritt diejenigen, die am Ende mit dem Portal arbeiten (Kunden und Support).

Warum die anderen falsch sind:
A: ...weil Geschäfts- und Vorstandsinteressen vom Executive (Frau Dr. Keller) gewahrt werden.
 B: ...da die IT-Interessen in die Rolle des Senior Suppliers (Frau Nowak) fallen.
  • D: ...weil externe Entwickler Lieferanten sind und somit ebenfalls zum Senior Supplier gehören.
Rollen im Szenario III [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO "Kundenportal 2.0": Die Mustermann GmbH führt ein neues Kunden-Self-Service-Portal ein. Executive: Frau Dr. Keller (Vertrieb). Senior User: Herr Aydın (Kundenservice). Senior Supplier: Frau Nowak (IT, inkl. externer Dienstleister). Projektmanager: Herr Vogt. Budget 420.000 € (davon 90.000 € Reserve). 4 Stages über 9 Monate. Frau Nowak vertritt sowohl interne IT-Ressourcen als auch den externen Dienstleister. Ist das mit PRINCE2 vereinbar?
❌ Das ist nur bei rein internen Projekten zulässig
✅ Ja, die Rolle kann mehrere liefernde Parteien gemeinsam vertreten
❌ Nein, externe Dienstleister dürfen im Lenkungsausschuss nicht vertreten sein
❌ Nein, jede liefernde Partei braucht eine eigene Senior-Supplier-Rolle
Ja — die Senior-Supplier-Rolle kann mehrere liefernde Parteien vertreten, solange die Interessenvertretung klar ist.
Merksatz:
Der Senior Supplier ist der Sammelkorb für alle Lieferanten – eine einzige Person kann problemlos die Hüte von internen Teams und externen Dienstleistern gleichzeitig tragen.

Warum die anderen falsch sind:
A: ...übersieht, dass PRINCE2 universell einsetzbar ist und nicht zwischen rein internen und externen Projekten unterscheidet.
 C: ...verkennt, dass externe Lieferanten für den Projekterfolg essenziell sind und im Lenkungsausschuss vertreten sein müssen.
  • D: ...führt zu einem unnötig aufgeblähten Gremium, da PRINCE2 die Bündelung von Lieferanteninteressen in einer einzigen Rolle ausdrücklich erlaubt.
Stage-Struktur im Szenario [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO "Kundenportal 2.0": Die Mustermann GmbH führt ein neues Kunden-Self-Service-Portal ein. Executive: Frau Dr. Keller (Vertrieb). Senior User: Herr Aydın (Kundenservice). Senior Supplier: Frau Nowak (IT, inkl. externer Dienstleister). Projektmanager: Herr Vogt. Budget 420.000 € (davon 90.000 € Reserve). 4 Stages über 9 Monate. Warum ist die Unterteilung in 4 Management-Stages sinnvoll, statt das Projekt als eine einzige Stage zu planen?
❌ Die Unterteilung in vier Management-Stages ist sinnvoll, weil PRINCE2 eine einzelne Stage nur bei Projekten mit sehr geringem Risiko und klaren Anforderungen erlaubt, was hier nicht der Fall ist.
❌ Die vier Stages sind notwendig, da PRINCE2 vorschreibt, dass jedes Projekt mit einem Budget über 100.000 € in mindestens vier Stages aufgeteilt werden muss, um die Reserve korrekt zu verteilen.
❌ Die Aufteilung in vier Stages dient hauptsächlich dazu, die 90.000 € Reserve gleichmäßig auf die einzelnen Projektabschnitte zu verteilen, damit am Ende keine ungenutzten Mittel übrig bleiben.
✅ Sie ermöglicht regelmäßige Freigabepunkte zur erneuten Bewertung des Projekts
Sie ermöglicht regelmäßige Freigabepunkte (Manage by Stages) — das Project Board kann nach jeder Stage neu bewerten, ob eine Fortsetzung gerechtfertigt ist.
Merksatz:
Stages sind wie Boxenstopps: Man fährt kein 9-Monate-Rennen ohne Zwischenstopps, sondern nutzt die 4 Stages als Boxenstopps (Freigabepunkte), um den Wagen zu checken, das Budget zu prüfen und zu entscheiden, ob die Weiterfahrt (Business Case) noch Sinn macht.

Warum die anderen falsch sind:
Nicht zulässig: PRINCE2 schreibt mindestens zwei Stages vor (Initiierungs- und mindestens eine Lieferphase), eine einzige ist also unzulässig, aber das begründet nicht den praktischen Nutzen im Szenario.
 Nur bei großen Projekten: Falsch, da jede PRINCE2-Projektgröße zwingend mindestens zwei Stages erfordert.
  • Ausschließlich Budgetaufteilung: Stages steuern das gesamte Projekt (Risiken, Pläne, Business Case), nicht nur das Geld.
Risikobewertung R1 [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO "Kundenportal 2.0": Die Mustermann GmbH führt ein neues Kunden-Self-Service-Portal ein. Executive: Frau Dr. Keller (Vertrieb). Senior User: Herr Aydın (Kundenservice). Senior Supplier: Frau Nowak (IT, inkl. externer Dienstleister). Projektmanager: Herr Vogt. Budget 420.000 € (davon 90.000 € Reserve). 4 Stages über 9 Monate. Risiko R1 (Lieferverzögerung des externen Dienstleisters) ist bereits bei einem früheren Projekt mit einem anderen Kunden aufgetreten. Welches PRINCE2-Principle wird hier direkt angewendet, wenn dieses Wissen aktiv genutzt wird?
❌ Tailor to Suit the Project
❌ Steuern nach dem Ausnahmeprinzip
✅ Learn from Experience
❌ Focus on Products
Learn from Experience — Erfahrungen aus vergangenen (auch fremden) Projekten fließen aktiv in die Risikoeinschätzung ein.
Merksatz:
„Erfahrung schützt vor Schaden“ – Wer in den Rückspiegel (altes Projekt) schaut, um nicht erneut gegen dieselbe Wand (Lieferverzögerung) zu fahren, lernt aktiv aus Erfahrung.

Warum die anderen falsch sind:
A) Tailor to Suit the Project: Hier wird kein PM-Prozess an die Projektgröße angepasst.
 B) Manage by Exception: Es geht nicht um Toleranzgrenzen oder die Eskalation von Budgetüberschreitungen.
  • D) Focus on Products: Der Fokus liegt auf dem historischen Wissen und nicht auf der Definition von Liefergegenständen.
Risikostrategie R2 [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO "Kundenportal 2.0": Die Mustermann GmbH führt ein neues Kunden-Self-Service-Portal ein. Executive: Frau Dr. Keller (Vertrieb). Senior User: Herr Aydın (Kundenservice). Senior Supplier: Frau Nowak (IT, inkl. externer Dienstleister). Projektmanager: Herr Vogt. Budget 420.000 € (davon 90.000 € Reserve). 4 Stages über 9 Monate. Für Risiko R2 (unklare DSGVO-Anforderungen) entscheidet sich das Team, frühzeitig eine externe Datenschutzberatung zu beauftragen. Welche Risikostrategie ist das primär?
❌ Transfer (übertragen)
❌ Avoid (vermeiden)
❌ Accept (akzeptieren)
✅ Reduce (reduzieren)
Reduce — die Wahrscheinlichkeit/Auswirkung des Risikos (rechtliche Fehleinschätzung) wird durch die Beratung aktiv verringert.
Merksatz: Der Berater schrumpft die Gefahr: Externe Expertise reduziert die Unklarheit (Wahrscheinlichkeit), statt das Risiko komplett wegzuschieben.

Warum die anderen falsch sind:
A) Transfer: Die rechtliche Verantwortung verbleibt beim Projekt und wird nicht vertraglich auf den Berater übertragen.
 B) Avoid: Das Projekt wird fortgeführt und DSGVO-Daten weiterhin genutzt, das Risiko also nicht komplett eliminiert.
  • C) Accept: Das Team handelt aktiv und investiert Budget, statt das Risiko einfach passiv hinzunehmen.
Risikostrategie R3 [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO "Kundenportal 2.0": Die Mustermann GmbH führt ein neues Kunden-Self-Service-Portal ein. Executive: Frau Dr. Keller (Vertrieb). Senior User: Herr Aydın (Kundenservice). Senior Supplier: Frau Nowak (IT, inkl. externer Dienstleister). Projektmanager: Herr Vogt. Budget 420.000 € (davon 90.000 € Reserve). 4 Stages über 9 Monate. Für Risiko R3 (Sorge der Mitarbeitenden vor Stellenabbau) wäre eine reine technische Gegenmaßnahme wenig wirksam. Welches PRINCE2-Element ist hier besonders gefragt?
❌ Das People-Element ist hier weniger entscheidend, da PRINCE2 primär auf Prozesse und Practices fokussiert ist; stattdessen sollte die Practice Quality sicherstellen, dass die technische Lösung den Anforderungen entspricht und die Mitarbeiterbedenken durch klare Qualitätskriterien adressiert werden.
✅ Das People-Element (Kommunikation, Einbindung, Change-Begleitung)
❌ Der Prozess Closing a Project bietet den passenden Rahmen, um nach Abschluss der technischen Umsetzung die Mitarbeiterbedenken im Rahmen der Lessons Learned zu dokumentieren und so für zukünftige Projekte zu berücksichtigen, statt direkt in der Umsetzung einzugreifen.
❌ Die Practice Plans ist das zentrale Element, da sie die Risikoreserve von 90.000 € verwaltet und einen detaillierten Maßnahmenplan für R3 vorschreibt, der technische und kommunikative Schritte in einer festen Reihenfolge terminiert und damit die Wirksamkeit sicherstellt.
Das People-Element — Kommunikation, Einbindung und Change-Begleitung der betroffenen Mitarbeitenden.
Merksatz:
Bei Sorgen von Menschen hilft keine Technik, sondern nur der Faktor Mensch – das People-Element fängt Ängste durch Kommunikation und Change-Management auf.

Warum die anderen falsch sind:
Ausschließlich "Quality": Qualität sichert Produkteigenschaften, löst aber keine emotionalen Ängste vor Stellenabbau.
 Prozess "Closing a Project": Das Projektende ist viel zu spät, um die Akzeptanz der Mitarbeitenden während des Projekts zu sichern.
  • Ausschließlich "Plans": Ein Zeit- oder Budgetplan schafft keine Empathie oder den notwendigen kulturellen Wandel.
Toleranzüberschreitung Stage 1 [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO "Kundenportal 2.0": Die Mustermann GmbH führt ein neues Kunden-Self-Service-Portal ein. Executive: Frau Dr. Keller (Vertrieb). Senior User: Herr Aydın (Kundenservice). Senior Supplier: Frau Nowak (IT, inkl. externer Dienstleister). Projektmanager: Herr Vogt. Budget 420.000 € (davon 90.000 € Reserve). 4 Stages über 9 Monate. Die drohende 2-Wochen-Verzögerung in Stage 1 liegt noch INNERHALB der gesetzten Zeittoleranz (+/- 2 Wochen). Muss Herr Vogt trotzdem einen Ausnahmebericht an das Lenkungsausschuss schreiben?
❌ Nein, eine Überschreitung der Zeittoleranz ist nicht erforderlich, da der Projektmanager bei PRINCE2 generell keine Abweichungen melden muss, solange das Projektbudget eingehalten wird.
✅ Nein, solange die Toleranz nicht überschritten wird, kann er eigenständig weitersteuern
❌ Ja, denn jede Abweichung vom Phasenplan, auch wenn sie innerhalb der Toleranz liegt, muss dem Lenkungsausschuss unverzüglich als Ausnahmebericht vorgelegt werden, um Transparenz zu gewährleisten.
❌ Ja, aber nur wenn die Verzögerung mehr als eine Woche beträgt, da PRINCE2 eine wöchentliche Meldegrenze für Zeitabweichungen vorsieht, unterhalb derer keine Berichtspflicht besteht.
Nein — solange die Toleranz nicht überschritten wird, kann der Project Manager im Rahmen von Manage by Exception eigenständig weitersteuern, ggf. mit Hinweis im nächsten Highlight Report.
Merksatz:
„Grünes Licht im Toleranzbereich – der Projektmanager bleibt der Chef im eigenen Reich.“ Solange die Ampel durch eine Verzögerung nicht auf Rot springt (Toleranzgrenze gerissen), steuert der Projektmanager das Schiff selbstständig weiter und muss das Project Board nicht mit einem Exception Report alarmieren.

Warum die anderen falsch sind:
Sofortiger Report bei jeder Verzögerung: Falsch, da dies das Management-by-Exception-Prinzip aushebeln und das Board mit Mikromanagement überlasten würde.
 Grundsätzlich keine Kommunikation: Falsch, da wesentliche Abweichungen und Statusberichte (Highlight Reports) sehr wohl regelmäßig kommuniziert werden müssen.
  • Ja ab 1 Woche: Falsch, da dies eine willkürlich erfundene Grenze ist; maßgeblich ist einzig und allein die vereinbarte Toleranzgrenze von 2 Wochen.
Fehlende Funktion "Stornieren" [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO "Kundenportal 2.0": Die Mustermann GmbH führt ein neues Kunden-Self-Service-Portal ein. Executive: Frau Dr. Keller (Vertrieb). Senior User: Herr Aydın (Kundenservice). Senior Supplier: Frau Nowak (IT, inkl. externer Dienstleister). Projektmanager: Herr Vogt. Budget 420.000 € (davon 90.000 € Reserve). 4 Stages über 9 Monate. Die Funktion "Bestellungen stornieren" fehlt im vereinbarten Leistungsumfang, wird aber jetzt von Großkunden gefordert. Um welche Art von Issue handelt es sich formal?
❌ Off-Specification
❌ Ein Problem/Concern ohne Entscheidungsbedarf
✅ Request for Change
❌ Ein reines Risiko, kein Issue
Ein Request for Change — es wird eine Änderung/Ergänzung des bereits vereinbarten (baselined) Leistungsumfangs beantragt.
Merksatz: Was im Vertrag fehlt, aber neu dazu soll, braucht einen Request for Change (RFC) – wie das nachträgliche Bestellen von Extra-Ausstattung beim Neuwagen.

Warum die anderen falsch sind:
A (Off-Specification): Gilt nur, wenn bereits Vereinbartes fehlerhaft oder gar nicht geliefert wurde.
 B (Problem ohne Entscheidungsbedarf): Die Forderung wichtiger Großkunden verlangt zwingend eine aktive Management-Entscheidung.
  • D (Reines Risiko): Risiken betreffen unsichere Ereignisse in der Zukunft, das Fehlen ist aber bereits ein reales, gegenwärtiges Problem (Issue).
Ladezeit-Problem [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO "Kundenportal 2.0": Die Mustermann GmbH führt ein neues Kunden-Self-Service-Portal ein. Executive: Frau Dr. Keller (Vertrieb). Senior User: Herr Aydın (Kundenservice). Senior Supplier: Frau Nowak (IT, inkl. externer Dienstleister). Projektmanager: Herr Vogt. Budget 420.000 € (davon 90.000 € Reserve). 4 Stages über 9 Monate. Die Bestellübersicht überschreitet bei Lasttests die vereinbarte Ladezeit-Qualitätsanforderung deutlich. Um welche Art von Issue handelt es sich formal?
❌ Ein Communication Management Approach
✅ Off-Specification
❌ Ein reines Risiko, kein Issue
❌ Request for Change
Eine Off-Specification — ein bereits vereinbartes Qualitätskriterium wird nicht erfüllt.
Merksatz:
Wenn ein Produkt die vereinbarten Qualitätskriterien (wie Ladezeiten) nicht erfüllt, ist es eine Off-Specification (Abweichung von der Spezifikation) – das Produkt hält nicht, was im Vorfeld schriftlich versprochen wurde.

Warum die anderen falsch sind:
Communication Management Approach: Dies ist das Kommunikationskonzept des Projekts, kein inhaltliches Problem oder Ereignis.
 Ein reines Risiko, kein Issue: Da die Ladezeit-Überschreitung bereits im Lasttest real eingetreten ist, handelt es sich um ein aktuelles Problem (Issue) und keine zukünftige Unsicherheit (Risiko).
  • Request for Change: Ein Änderungsantrag fordert eine bewusste neue Funktion oder Modifikation, wohingegen hier ein bestehender Fehler (Mangel) vorliegt.
Wer entscheidet über den Storno-Wunsch? [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO "Kundenportal 2.0": Die Mustermann GmbH führt ein neues Kunden-Self-Service-Portal ein. Executive: Frau Dr. Keller (Vertrieb). Senior User: Herr Aydın (Kundenservice). Senior Supplier: Frau Nowak (IT, inkl. externer Dienstleister). Projektmanager: Herr Vogt. Budget 420.000 € (davon 90.000 € Reserve). 4 Stages über 9 Monate. Wer entscheidet typischerweise, ob der Request for Change "Bestellungen stornieren" umgesetzt wird?
❌ Die Änderungsinstanz, in diesem Fall das Lenkungsausschuss, entscheidet über die Umsetzung, wobei der externe Dienstleister lediglich eine technische Machbarkeitsprüfung durchführt und keine inhaltliche Freigabe erteilt.
❌ Die Entscheidung obliegt dem Senior User, Herrn Aydın, da er die fachlichen Anforderungen des Kundenservice vertritt und die Auswirkungen auf die Nutzer am besten beurteilen kann, ohne dass weitere Gremien eingebunden werden müssen.
❌ Die Umsetzung erfolgt direkt durch den Projektmanager, da der Request for Change innerhalb des genehmigten Budgets liegt und keine Auswirkungen auf Zeitplan oder Qualität hat, weshalb keine formale Genehmigung durch das Lenkungsausschuss erforderlich ist.
✅ Die Änderungsinstanz (oft das Lenkungsausschuss oder eine beauftragte Instanz)
Die Change Authority — bei PRINCE2 oft das Project Board selbst oder eine dafür beauftragte Instanz mit definiertem Budgetrahmen.
Merksatz:
Wer die Macht über den Wandel hat, braucht die offizielle Kappe: Nur die Change Authority (der Lenkungsausschuss oder seine delegierte Instanz) hält das Zepter für Änderungen in der Hand – kein Alleingang im Projekt!

Warum die anderen falsch sind:
Ausschließlich der externe Dienstleister: Dienstleister liefern nur zu und haben keine formale Budget- oder Steuerungshoheit über Projektänderungen.
 Ausschließlich der Kundenservice: Ein einzelner Senior User darf Änderungen nicht im Alleingang ohne Berücksichtigung von Budget und Business Case absegnen.
  • Entscheidung liegt formal bei niemandem: Ohne formale Freigabe droht unkontrolliertes Scope Creep, was PRINCE2 durch klare Governance-Strukturen strikt verhindert.
Budgetreserve Stage 3 [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO "Kundenportal 2.0": Die Mustermann GmbH führt ein neues Kunden-Self-Service-Portal ein. Executive: Frau Dr. Keller (Vertrieb). Senior User: Herr Aydın (Kundenservice). Senior Supplier: Frau Nowak (IT, inkl. externer Dienstleister). Projektmanager: Herr Vogt. Budget 420.000 € (davon 90.000 € Reserve). 4 Stages über 9 Monate. Bis Ende Stage 3 sind bereits 18.000 € der 90.000 € Reserve verbraucht, für Stage 4 werden weitere 25.000 € ungeplante Kosten erwartet. Was ist der erste sinnvolle Schritt von Herrn Vogt?
❌ Herr Vogt sollte zunächst die verbleibende Projektreserve und die Toleranzen für Stage 4 prüfen und dann entscheiden, ob eine formelle Änderungsanfrage an den Lenkungsausschuss notwendig ist, bevor er weitere Maßnahmen ergreift.
❌ Herr Vogt kann die zusätzlichen Kosten direkt aus dem Gesamtbudget decken, da die Reserve von 90.000 € ohnehin für unvorhergesehene Ausgaben vorgesehen ist und das Projekt dadurch nicht gefährdet wird.
❌ Herr Vogt muss keine weiteren Schritte einleiten, da die Projektreserve von 90.000 € auch nach dem Verbrauch von 18.000 € noch ausreichend Spielraum für die erwarteten 25.000 € bietet und die Toleranzen automatisch angepasst werden.
✅ Prüfen ob Reserve/Toleranzen ausreichen, ggf. frühzeitig Ausnahmebericht vorbereiten
Prüfen, ob die verbleibende Reserve und die gesetzten Kosten-Toleranzen ausreichen — bei drohender Überschreitung frühzeitig einen Exception Report vorbereiten.
Merksatz: Erst den Kassensturz machen und die Toleranz-Leitplanken prüfen, bevor man den Notruf (Exception Report) wählt oder blind weiterfährt.

Warum die anderen falsch sind:
A) Ein sofortiger Abbruch ist völlig voreilig, da die verbrauchten 43.000 € noch weit unter der 90.000 € Reserve liegen.
 B: Eigenmächtiges Budgetieren ohne Rücksprache verletzt die Governance-Regeln und die Kompetenzgrenzen des Projektleiters.
  • C: Untätigkeit ist riskant, da Reserven niemals unbegrenzt sind und jede Abweichung aktiv überwacht werden muss.
Highlight Report Inhalt im Szenario [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO "Kundenportal 2.0": Die Mustermann GmbH führt ein neues Kunden-Self-Service-Portal ein. Executive: Frau Dr. Keller (Vertrieb). Senior User: Herr Aydın (Kundenservice). Senior Supplier: Frau Nowak (IT, inkl. externer Dienstleister). Projektmanager: Herr Vogt. Budget 420.000 € (davon 90.000 € Reserve). 4 Stages über 9 Monate. Was sollte Herr Vogt im nächsten Projektstatusbericht an das Lenkungsausschuss zur aktuellen Lage sinnvollerweise berichten?
❌ Aktueller Projektstatus inklusive aller Abweichungen vom Plan, offener Risiken und dem verbleibenden Budget inklusive der bereits verbrauchten Reserve
❌ Zusammenfassung der positiven Meilensteine und Erfolge der letzten Berichtsperiode, ergänzt um eine optimistische Prognose für die kommenden Wochen
✅ Fortschritt, Stand der offenen Issues und Entwicklung der Reserve-Nutzung
❌ Detaillierte Auflistung aller technischen Spezifikationen und Implementierungsdetails der letzten Änderungen am Portal, ohne Bezug zu Zeit, Kosten oder Qualität
Fortschritt der laufenden Stage, den Stand der offenen Issues (Storno-Funktion, Ladezeit-Problem) und die Entwicklung der Reserve-Nutzung.
Merksatz:
Der Highlight-Scheinwerfer beleuchtet den Fortschritt, deckt stolpernde Issues auf und zeigt den Füllstand der Reserve-Kasse.

Warum die anderen falsch sind:
A: Reine Namenslisten bieten dem Project Board keinerlei steuerungsrelevante Statusinformationen.
 B: Schönfärberei verheimlicht kritische Risiken und verhindert das notwendige Gegensteuern des Managements.
  • D: Technische Details überfordern das Board und enthalten keine Management-Kennzahlen zur Projektsteuerung.
Anwendung Manage by Products [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO "Kundenportal 2.0": Die Mustermann GmbH führt ein neues Kunden-Self-Service-Portal ein. Executive: Frau Dr. Keller (Vertrieb). Senior User: Herr Aydın (Kundenservice). Senior Supplier: Frau Nowak (IT, inkl. externer Dienstleister). Projektmanager: Herr Vogt. Budget 420.000 € (davon 90.000 € Reserve). 4 Stages über 9 Monate. Bevor Stage 2 beginnt, sollte für die neue Funktion "Bestellverfolgung" eine Produktbeschreibung erstellt werden. Welches Principle wird damit konkret umgesetzt?
❌ Continued Business Justification
❌ Steuern nach dem Ausnahmeprinzip
❌ Learn from Experience
✅ Focus on Products
Focus on Products — die klare Definition dessen, was geliefert werden soll, bevor mit der Umsetzung begonnen wird.
Merksatz:
Erst das Produkt beschreiben, dann die Arbeit treiben: Die Product Description lenkt den Blick starr auf das konkrete Lieferergebnis – das ist Focus on Products!

Warum die anderen falsch sind:
A (Business Justification): Prüft die wirtschaftliche Rentabilität des Gesamtprojekts, nicht die Definition einzelner Features.
 B (Manage by Exception): Steuert Toleranzgrenzen für Budget und Zeit, statt inhaltliche Produktanforderungen festzulegen.
  • C (Learn from Experience): Nutzt Lehren aus der Vergangenheit, statt zukünftige Liefergegenstände konkret zu spezifizieren.
Stage-Boundary-Entscheidung [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO "Kundenportal 2.0": Die Mustermann GmbH führt ein neues Kunden-Self-Service-Portal ein. Executive: Frau Dr. Keller (Vertrieb). Senior User: Herr Aydın (Kundenservice). Senior Supplier: Frau Nowak (IT, inkl. externer Dienstleister). Projektmanager: Herr Vogt. Budget 420.000 € (davon 90.000 € Reserve). 4 Stages über 9 Monate. Am Ende von Stage 2 muss das Lenkungsausschuss entscheiden, ob Stage 3 freigegeben wird. In welchem Prozess findet das statt?
❌ Starting up a Project (SU)
✅ Managing a Stage Boundary (SB)
❌ Closing a Project (CP)
❌ Controlling a Stage (CS)
Managing a Stage Boundary (SB) — Vorbereitung der Freigabe der nächsten Stage.
Merksatz:
Am Ende einer Phase (Stage) steht man an der Grenze (Boundary) zur nächsten – hier entscheidet das Project Board, ob die Reise weitergeht. Managing a Stage Boundary (SB) ist die Brücke, die das Board betreten muss, um die Freigabe für die nächste Phase zu erteilen.

Warum die anderen falsch sind:
Starting up a Project (SU): Findet ganz am Anfang vor dem eigentlichen Projektstart statt, um zu prüfen, ob das Projekt überhaupt machbar ist.
 Closing a Project (CP): Wird erst am Ende des gesamten Projekts genutzt, um dieses kontrolliert abzuschließen, nicht zwischen den Phasen.
Controlling a Stage (CS): Ist der tägliche Management-Prozess des Projektmanagers während* einer laufenden Phase, in dem keine Phasenübergänge freigegeben werden.
Anwendung Business Justification [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO "Kundenportal 2.0": Die Mustermann GmbH führt ein neues Kunden-Self-Service-Portal ein. Executive: Frau Dr. Keller (Vertrieb). Senior User: Herr Aydın (Kundenservice). Senior Supplier: Frau Nowak (IT, inkl. externer Dienstleister). Projektmanager: Herr Vogt. Budget 420.000 € (davon 90.000 € Reserve). 4 Stages über 9 Monate. Angenommen, die Kosten für DSGVO-Beratung und Storno-Funktion würden das Budget so stark belasten, dass die erwarteten Einsparungen (30% weniger Support-Anrufe) den Aufwand nicht mehr rechtfertigen. Was sollte laut PRINCE2 geprüft werden?
❌ Nur der Executive darf das überhaupt in Erwägung ziehen, alle anderen nicht
❌ Das Projekt läuft laut PRINCE2 in jedem Fall bis zum Ende durch
❌ Business Justification wird nur einmalig zu Projektbeginn geprüft
✅ Ob der Business Case weiterhin gerechtfertigt ist — ggf. vorzeitiger Abbruch
Ob der Business Case weiterhin gerechtfertigt ist (Continued Business Justification) — im Extremfall müsste das Projekt vorzeitig beendet werden.
Merksatz:
Der Business Case ist der Kompass des Projekts: Zeigt er ins Minus, zieht PRINCE2 die Notbremse und bricht ab, statt blind Geld zu verbrennen.

Warum die anderen falsch sind:
A: Auch der Projektmanager muss die Wirtschaftlichkeit aktiv überwachen, nicht nur der Executive.
 B: PRINCE2 verbietet das Weiterführen unrentabler Projekte; sinnlose Projekte werden sofort gestoppt.
  • C: Die Wirtschaftlichkeit wird kontinuierlich bei jedem Phasenübergang geprüft, nicht nur am Anfang.
Issues im Szenario richtig zuordnen [P] [Practices] 1 Unterseite →
✌️ Multi SZENARIO "Kundenportal 2.0": Die Mustermann GmbH führt ein neues Kunden-Self-Service-Portal ein. Executive: Frau Dr. Keller (Vertrieb). Senior User: Herr Aydın (Kundenservice). Senior Supplier: Frau Nowak (IT, inkl. externer Dienstleister). Projektmanager: Herr Vogt. Budget 420.000 € (davon 90.000 € Reserve). 4 Stages über 9 Monate. Ordne zu: Welche Aussagen zu den im Szenario beschriebenen Ereignissen sind korrekt? (Mehrfachauswahl)
✅ Das Ladezeit-Problem ist eine Off-Specification
✅ Die fehlende Storno-Funktion ist ein Request for Change
❌ Beide Ereignisse sind identisch zu behandeln, da beide "Änderungen" sind
❌ Nur das Lenkungsausschuss darf Issues überhaupt erfassen
Merksatz:
Lahmt das System, ist es ein Fehler im Soll (Off-Spec); fehlt eine neue Funktion, ist es ein Wunsch nach mehr (Change Request).

Warum die anderen falsch sind:
C: Fehlerbehebung (Off-Spec) und neue Wünsche (RfC) erfordern völlig unterschiedliche Freigabeprozesse.
 D: Issues darf jeder Projektbeteiligte erfassen und einreichen, nicht nur der Lenkungsausschuss.
Rollen korrekt zuordnen [P] [Practices] 1 Unterseite →
✌️ Multi SZENARIO "Kundenportal 2.0": Die Mustermann GmbH führt ein neues Kunden-Self-Service-Portal ein. Executive: Frau Dr. Keller (Vertrieb). Senior User: Herr Aydın (Kundenservice). Senior Supplier: Frau Nowak (IT, inkl. externer Dienstleister). Projektmanager: Herr Vogt. Budget 420.000 € (davon 90.000 € Reserve). 4 Stages über 9 Monate. Welche Aussagen zu den Rollen im Szenario sind korrekt? (Mehrfachauswahl)
✅ Frau Nowak vertritt Liefer-/Ressourceninteressen
✅ Frau Dr. Keller verantwortet den Business Case
✅ Herr Aydın vertritt Nutzer-Interessen
❌ Herr Vogt ist stimmberechtigtes Mitglied des Lenkungsausschuss
Merksatz:
Das Lenkungsausschuss-Trio lenkt das Boot: Keller zahlt die Zeche (Executive = Business Case), Aydın fährt damit (Senior User = Nutzer) und Nowak baut es (Senior Supplier = Ressourcen) – während Vogt als Steuermann (PM) nur rudert, aber im Ausschuss keine Stimme hat.

Warum die anderen falsch sind:
  • D) Der Projektleiter (Vogt) führt das Projekt nur operativ und berichtet an den Lenkungsausschuss, hat dort aber selbst kein Stimmrecht.
Exception Report für Stage 4 formulieren [P] [Practices] 1 Unterseite →
☝️ Single Wie unterscheiden sich Ausnahmebericht und Ausnahmeplan?
✅ Der Report informiert das Board über die Abweichung, der Plan ersetzt nach Genehmigung den bisherigen Plan
❌ Der Ausnahmebericht beschreibt die Abweichung und ersetzt nach Genehmigung den bisherigen Plan, während der Ausnahmeplan ausschließlich das Board informiert.
❌ Beide Dokumente sind inhaltlich identisch und unterscheiden sich nur im Zeitpunkt ihrer Erstellung innerhalb des Steuerungsprozesses.
❌ Der Ausnahmebericht wird ausschließlich vom Projektteam erstellt und betrifft nur interne Abweichungen, während der Ausnahmeplan ausschließlich dem Board zur Information dient.
Der Exception Report informiert das Board über die Abweichung; der Exception Plan ersetzt nach Genehmigung den bisherigen Plan.
Merksatz: Erst der Report als Rauchmelder (Info ans Board), dann der Plan als Pfadfinder (ersetzt den alten Weg).

Warum die anderen falsch sind:
B) ...ignoriert, dass Bericht (Status) und Plan (Zukunft) zwei völlig verschiedene Dokumente sind.
 C) ...vertauscht Ursache und Wirkung, da der Report meldet und der Plan steuert.
  • D) ...verkennt, dass das Board den Report zur Entscheidung braucht und der Plan das gesamte Projekt betrifft.
Eigene Risikoanalyse für Stage 4 [P] [Practices] 1 Unterseite →
☝️ Single Das Team führt vor dem Rollout intensive Lasttests durch, um ein Ausfallrisiko zu verringern. Welche Risikostrategie ist das?
✅ Reduce (reduzieren)
❌ Accept (akzeptieren)
❌ Exploit (nutzen)
❌ Transfer (übertragen)
Durch Lasttests wird die Eintrittswahrscheinlichkeit bzw. Auswirkung eines Ausfallrisikos aktiv verringert — das ist die Strategie Reduce.
Merksatz: Wer den Fallschirm vor dem Absprung flickt, reduziert die Aufprallgefahr – Lasttests drücken das Risiko aktiv nach unten.

Warum die anderen falsch sind:
Accept: Bedeutet tatenloses Abwarten und das Risiko ohne Gegenmaßnahmen einfach in Kauf zu nehmen.
 Exploit: Bezieht sich ausschließlich auf das Nutzen von positiven Risiken (Chancen), nicht auf Gefahren.
  • Transfer: Würde bedeuten, die Verantwortung auf Dritte (wie Versicherungen oder Subunternehmer) abzuwälzen, statt selbst zu handeln.
Szenario Organizing [P] [Practices] 1 Unterseite →
matching Rathaus-Migration: Ordnen Sie jeder Person die Rolle zu, die sie im Project Board wahrnimmt.
Executive trägt die Gesamtverantwortung/den Business Case; Senior User vertritt die Nutzerinteressen und den erwarteten Nutzen; Senior Supplier vertritt die Liefer-/Ressourcenseite.
Merksatz: Rathaus-Migration: Der Bürgermeister (Executive) gibt die Richtung vor und sorgt für die Finanzierung. Der IT-Leiter (Senior Supplier) liefert die technische Lösung (Migration). Die Fachbereichsleiter (Senior User) stellen sicher, dass die neuen Systeme den Bürgern (Nutzern) einen Mehrwert bringen und die Verwaltung effektiv arbeitet. Der Projektmanager ist der Dirigent, der die Umsetzung orchestriert, aber nicht im Project Board sitzt.
Szenario Executive-Rolle korrekt zuordnen [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO 'SolarDach Rollout': Die GreenTech Solar AG (Senior Supplier, Geschaeftsfuehrerin Frau Yilmaz) installiert im Auftrag der LogiKon AG (Auftraggeber-Konzern) Photovoltaik-Anlagen auf 40 Logistikzentren. Executive ist Frau Dr. Berger (COO LogiKon), Senior User ist Herr Falk (Leiter Facility Management LogiKon, spaeterer Nutzer der Anlagen), Project Manager ist Herr Nowak, Team Manager Elektroinstallation ist Frau Lindqvist. Das Projekt ist in 4 Management-Stages gegliedert: IP, Pilotphase (5 Standorte), Rollout-Welle 1 (20 Standorte), Rollout-Welle 2 (15 Standorte) inkl. Abschluss. Toleranzen: Budget +/-5%, Zeit +/-2 Wochen je Stage. Wer traegt im Szenario die persoenliche Gesamtverantwortung dafuer, dass der Business Case des Projekts durchgaengig tragfaehig bleibt?
❌ Herr Nowak, da er als Project Manager das Tagesgeschaeft steuert.
❌ Frau Yilmaz, weil sie als Senior Supplier fuer die Technik haftet.
❌ Das gesamte Project Board gemeinsam zu gleichen Teilen.
✅ Frau Dr. Berger als Executive.
Szenario Senior User Interesse [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO 'SolarDach Rollout': Die GreenTech Solar AG (Senior Supplier, Geschaeftsfuehrerin Frau Yilmaz) installiert im Auftrag der LogiKon AG (Auftraggeber-Konzern) Photovoltaik-Anlagen auf 40 Logistikzentren. Executive ist Frau Dr. Berger (COO LogiKon), Senior User ist Herr Falk (Leiter Facility Management LogiKon, spaeterer Nutzer der Anlagen), Project Manager ist Herr Nowak, Team Manager Elektroinstallation ist Frau Lindqvist. Das Projekt ist in 4 Management-Stages gegliedert: IP, Pilotphase (5 Standorte), Rollout-Welle 1 (20 Standorte), Rollout-Welle 2 (15 Standorte) inkl. Abschluss. Toleranzen: Budget +/-5%, Zeit +/-2 Wochen je Stage. Welches Interesse vertritt Herr Falk als Senior User in diesem Projekt vor allem?
❌ Dass GreenTech Solar AG fristgerecht bezahlt wird.
❌ Dass der Aufsichtsrat der LogiKon AG informiert bleibt.
❌ Dass die Anlagen technisch einwandfrei geliefert und angeschlossen werden.
✅ Dass die spaetere Nutzung (Stromertrag, Wartbarkeit, Betrieb) den Bedarf der Standorte deckt.
Szenario Rollen des Project Board zuordnen [P] [Practices] 1 Unterseite →
matching SZENARIO 'SolarDach Rollout': Die GreenTech Solar AG (Senior Supplier, Geschaeftsfuehrerin Frau Yilmaz) installiert im Auftrag der LogiKon AG (Auftraggeber-Konzern) Photovoltaik-Anlagen auf 40 Logistikzentren. Executive ist Frau Dr. Berger (COO LogiKon), Senior User ist Herr Falk (Leiter Facility Management LogiKon, spaeterer Nutzer der Anlagen), Project Manager ist Herr Nowak, Team Manager Elektroinstallation ist Frau Lindqvist. Das Projekt ist in 4 Management-Stages gegliedert: IP, Pilotphase (5 Standorte), Rollout-Welle 1 (20 Standorte), Rollout-Welle 2 (15 Standorte) inkl. Abschluss. Toleranzen: Budget +/-5%, Zeit +/-2 Wochen je Stage. Ordnen Sie die Personen den PRINCE2-Rollen zu.
Szenario Toleranzueberschreitung Stage 2 [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO 'SolarDach Rollout': Die GreenTech Solar AG (Senior Supplier, Geschaeftsfuehrerin Frau Yilmaz) installiert im Auftrag der LogiKon AG (Auftraggeber-Konzern) Photovoltaik-Anlagen auf 40 Logistikzentren. Executive ist Frau Dr. Berger (COO LogiKon), Senior User ist Herr Falk (Leiter Facility Management LogiKon, spaeterer Nutzer der Anlagen), Project Manager ist Herr Nowak, Team Manager Elektroinstallation ist Frau Lindqvist. Das Projekt ist in 4 Management-Stages gegliedert: IP, Pilotphase (5 Standorte), Rollout-Welle 1 (20 Standorte), Rollout-Welle 2 (15 Standorte) inkl. Abschluss. Toleranzen: Budget +/-5%, Zeit +/-2 Wochen je Stage. Waehrend der Pilotphase stellt sich heraus, dass an 2 der 5 Standorte eine zusaetzliche Stahlverstaerkung des Dachs noetig ist. Die Kosten dafuer sprengen das 5%-Budget-Toleranzband dieser Stage. Was muss Herr Nowak als Project Manager tun?
❌ Er entscheidet eigenstaendig ueber die Mehrkosten, da er das Tagesgeschaeft leitet.
❌ Er bricht das Projekt sofort ab, da eine Toleranz ueberschritten wurde.
✅ Er erstellt einen Ausnahmebericht (Exception Report) an das Project Board.
❌ Er wartet bis zum naechsten planmaessigen Stage-Ende und berichtet dann.
Szenario Exception Plan [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO 'SolarDach Rollout': Die GreenTech Solar AG (Senior Supplier, Geschaeftsfuehrerin Frau Yilmaz) installiert im Auftrag der LogiKon AG (Auftraggeber-Konzern) Photovoltaik-Anlagen auf 40 Logistikzentren. Executive ist Frau Dr. Berger (COO LogiKon), Senior User ist Herr Falk (Leiter Facility Management LogiKon, spaeterer Nutzer der Anlagen), Project Manager ist Herr Nowak, Team Manager Elektroinstallation ist Frau Lindqvist. Das Projekt ist in 4 Management-Stages gegliedert: IP, Pilotphase (5 Standorte), Rollout-Welle 1 (20 Standorte), Rollout-Welle 2 (15 Standorte) inkl. Abschluss. Toleranzen: Budget +/-5%, Zeit +/-2 Wochen je Stage. Das Project Board genehmigt nach dem Exception Report ein hoeheres Budget fuer die Pilotphase. Welches Dokument ersetzt nun den urspruenglichen Stage-Plan?
❌ Die Project Initiation Documentation (PID).
❌ Der End Stage Report.
✅ Der Exception Plan.
❌ Das Highlight Report.
Szenario Risikostrategie Lieferverzug [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO 'SolarDach Rollout': Die GreenTech Solar AG (Senior Supplier, Geschaeftsfuehrerin Frau Yilmaz) installiert im Auftrag der LogiKon AG (Auftraggeber-Konzern) Photovoltaik-Anlagen auf 40 Logistikzentren. Executive ist Frau Dr. Berger (COO LogiKon), Senior User ist Herr Falk (Leiter Facility Management LogiKon, spaeterer Nutzer der Anlagen), Project Manager ist Herr Nowak, Team Manager Elektroinstallation ist Frau Lindqvist. Das Projekt ist in 4 Management-Stages gegliedert: IP, Pilotphase (5 Standorte), Rollout-Welle 1 (20 Standorte), Rollout-Welle 2 (15 Standorte) inkl. Abschluss. Toleranzen: Budget +/-5%, Zeit +/-2 Wochen je Stage. Fuer das Risiko 'Lieferverzug bei Wechselrichtern durch einen einzigen Zulieferer' entscheidet sich das Team, zusaetzlich einen zweiten, alternativen Zulieferer unter Vertrag zu nehmen. Welche Risikostrategie liegt vor?
❌ Uebertragen (transfer).
✅ Vermindern (reduce).
❌ Ausnutzen (exploit) - da es sich um ein positives Risiko handelt.
❌ Akzeptieren (accept).
Szenario Chance nutzen Foerderprogramm [P] [Practices] 1 Unterseite →
✌️ Multi SZENARIO 'SolarDach Rollout': Die GreenTech Solar AG (Senior Supplier, Geschaeftsfuehrerin Frau Yilmaz) installiert im Auftrag der LogiKon AG (Auftraggeber-Konzern) Photovoltaik-Anlagen auf 40 Logistikzentren. Executive ist Frau Dr. Berger (COO LogiKon), Senior User ist Herr Falk (Leiter Facility Management LogiKon, spaeterer Nutzer der Anlagen), Project Manager ist Herr Nowak, Team Manager Elektroinstallation ist Frau Lindqvist. Das Projekt ist in 4 Management-Stages gegliedert: IP, Pilotphase (5 Standorte), Rollout-Welle 1 (20 Standorte), Rollout-Welle 2 (15 Standorte) inkl. Abschluss. Toleranzen: Budget +/-5%, Zeit +/-2 Wochen je Stage. Es besteht die Chance auf einen zusaetzlichen Foerderprogramm-Bonus, wenn das Projekt 6 Wochen frueher als geplant abschliesst. Welche der folgenden Massnahmen passen zu einer aktiven Chancenstrategie (Mehrfachauswahl)?
❌ Das Risiko im Risk Register einfach unbeobachtet stehen lassen (accept), ohne aktiv zu handeln.
✅ Zusaetzliche Ressourcen fuer Rollout-Welle 2 bereitstellen, um schneller zu werden (enhance).
✅ Ein zweites Installationsteam parallel einsetzen, um Kapazitaet zu erhoehen (exploit).
✅ Die Terminplanung so anpassen, dass die Chance realistisch erreichbar wird.
Szenario Issue-Art Dachschaden [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO 'SolarDach Rollout': Die GreenTech Solar AG (Senior Supplier, Geschaeftsfuehrerin Frau Yilmaz) installiert im Auftrag der LogiKon AG (Auftraggeber-Konzern) Photovoltaik-Anlagen auf 40 Logistikzentren. Executive ist Frau Dr. Berger (COO LogiKon), Senior User ist Herr Falk (Leiter Facility Management LogiKon, spaeterer Nutzer der Anlagen), Project Manager ist Herr Nowak, Team Manager Elektroinstallation ist Frau Lindqvist. Das Projekt ist in 4 Management-Stages gegliedert: IP, Pilotphase (5 Standorte), Rollout-Welle 1 (20 Standorte), Rollout-Welle 2 (15 Standorte) inkl. Abschluss. Toleranzen: Budget +/-5%, Zeit +/-2 Wochen je Stage. Am Standort Bremen wird waehrend der Montage ein bereits bestehender Dachschaden entdeckt, der nicht Teil der urspruenglichen Leistungsbeschreibung war. Wie wird dies in PRINCE2 typischerweise eingeordnet?
❌ Als Request for Change, weil der Kunde ausdruecklich und aktiv eine foermliche Aenderung des vereinbarten Leistungsumfangs wuenscht.
❌ Als Off-Specification, da eine Produktanforderung nicht erfuellbar ist wie spezifiziert.
❌ Als Risiko, da es noch nicht eingetreten ist.
✅ Als allgemeines Problem/Concern-Issue, da es sich um einen unerwarteten Befund ausserhalb der Spezifikation handelt.
Szenario Change Authority Speicherbatterien [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO 'SolarDach Rollout': Die GreenTech Solar AG (Senior Supplier, Geschaeftsfuehrerin Frau Yilmaz) installiert im Auftrag der LogiKon AG (Auftraggeber-Konzern) Photovoltaik-Anlagen auf 40 Logistikzentren. Executive ist Frau Dr. Berger (COO LogiKon), Senior User ist Herr Falk (Leiter Facility Management LogiKon, spaeterer Nutzer der Anlagen), Project Manager ist Herr Nowak, Team Manager Elektroinstallation ist Frau Lindqvist. Das Projekt ist in 4 Management-Stages gegliedert: IP, Pilotphase (5 Standorte), Rollout-Welle 1 (20 Standorte), Rollout-Welle 2 (15 Standorte) inkl. Abschluss. Toleranzen: Budget +/-5%, Zeit +/-2 Wochen je Stage. Waehrend Rollout-Welle 1 wuenscht LogiKon zusaetzliche Speicherbatterien an allen Standorten - eine Erweiterung des urspruenglichen Projektumfangs. Wer entscheidet ueber diesen Request for Change, wenn dafuer im Projekt ein Aenderungsbudget mit definierter Change Authority eingerichtet wurde?
❌ Zwingend der komplette Lenkungsausschuss in einer Sondersitzung.
❌ Automatisch Frau Dr. Berger als Executive, da jede Aenderung ihr vorgelegt werden muss.
✅ Die benannte Change Authority im Rahmen des zugewiesenen Aenderungsbudgets.
❌ Herr Nowak allein, weil er den taeglichen Fortschritt am besten kennt.
Szenario Stage Boundary Bericht [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO 'SolarDach Rollout': Die GreenTech Solar AG (Senior Supplier, Geschaeftsfuehrerin Frau Yilmaz) installiert im Auftrag der LogiKon AG (Auftraggeber-Konzern) Photovoltaik-Anlagen auf 40 Logistikzentren. Executive ist Frau Dr. Berger (COO LogiKon), Senior User ist Herr Falk (Leiter Facility Management LogiKon, spaeterer Nutzer der Anlagen), Project Manager ist Herr Nowak, Team Manager Elektroinstallation ist Frau Lindqvist. Das Projekt ist in 4 Management-Stages gegliedert: IP, Pilotphase (5 Standorte), Rollout-Welle 1 (20 Standorte), Rollout-Welle 2 (15 Standorte) inkl. Abschluss. Toleranzen: Budget +/-5%, Zeit +/-2 Wochen je Stage. Am Ende der Pilotphase muss das Project Board entscheiden, ob Rollout-Welle 1 gestartet wird. Welches Dokument liefert dafuer die zentrale Entscheidungsgrundlage?
✅ Der End Stage Report zusammen mit dem Plan fuer die naechste Stage.
❌ Das taegliche Daily Log von Herrn Nowak.
❌ Der Business Case allein, ohne weitere Unterlagen.
❌ Ein informelles Gespraech zwischen Project Manager und Executive ohne Dokumentation.
Szenario Qualitaetspruefung PV-Module [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO 'SolarDach Rollout': Die GreenTech Solar AG (Senior Supplier, Geschaeftsfuehrerin Frau Yilmaz) installiert im Auftrag der LogiKon AG (Auftraggeber-Konzern) Photovoltaik-Anlagen auf 40 Logistikzentren. Executive ist Frau Dr. Berger (COO LogiKon), Senior User ist Herr Falk (Leiter Facility Management LogiKon, spaeterer Nutzer der Anlagen), Project Manager ist Herr Nowak, Team Manager Elektroinstallation ist Frau Lindqvist. Das Projekt ist in 4 Management-Stages gegliedert: IP, Pilotphase (5 Standorte), Rollout-Welle 1 (20 Standorte), Rollout-Welle 2 (15 Standorte) inkl. Abschluss. Toleranzen: Budget +/-5%, Zeit +/-2 Wochen je Stage. Im Quality Register ist festgehalten: 'Kriterium: Modulwirkungsgrad mindestens 21%. Methode: Stichprobenmessung an 10% der verbauten Module.' Was beschreibt dieser Eintrag?
❌ Einen Change-Request bezueglich der Produktqualitaet.
❌ Eine Risikoeinschaetzung fuer die Produktqualitaet.
❌ Ausschliesslich ein Akzeptanzkriterium ohne Pruefmethode.
✅ Sowohl das Qualitaetskriterium als auch die zugehoerige Pruefmethode.
Szenario Business Assurance Zweck [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO 'Stadtarchiv Digitalisierung': Die Stadt Muenchen digitalisiert historische Archivbestaende. Executive ist Stadtkaemmerin Frau Dr. Vogel, Senior User ist Stadtarchivar Herr Brandt (spaeterer Nutzer der digitalen Bestaende), Senior Supplier ist Herr Ilic (Projektleiter bei ScanTech GmbH, dem beauftragten Dienstleister). Project Manager ist Frau Keller. Zwei Project-Assurance-Rollen sind benannt: die interne Revisionsstelle (Business Assurance) und der behoerdliche Datenschutzbeauftragte (User Assurance). Stages: Pilot (1.000 Dokumente), Hauptphase Welle 1 (Zeitungsarchiv), Welle 2 (Urkunden), Abschluss. Qualitaetskriterium: Scan-Aufloesung mind. 600dpi, Methode: Stichprobenpruefung von 5% der gescannten Dokumente. Welche Funktion erfuellt die interne Revisionsstelle als Project Assurance in diesem Projekt vor allem?
❌ Sie ersetzt den Datenschutzbeauftragten bei dessen Abwesenheit.
❌ Sie trifft anstelle des Executive eigenstaendig und ohne jede Ruecksprache die endgueltige Entscheidung ueber den gesamten Business Case des Projekts.
❌ Sie fuehrt selbst die taegliche Scan-Arbeit durch.
✅ Sie prueft unabhaengig vom Project Manager, ob das Projekt im Sinne der Business-Interessen (u.a. Wirtschaftlichkeit, Business Case) laeuft.
Szenario Assurance-Rollen zuordnen [P] [Practices] 1 Unterseite →
matching SZENARIO 'Stadtarchiv Digitalisierung': Die Stadt Muenchen digitalisiert historische Archivbestaende. Executive ist Stadtkaemmerin Frau Dr. Vogel, Senior User ist Stadtarchivar Herr Brandt (spaeterer Nutzer der digitalen Bestaende), Senior Supplier ist Herr Ilic (Projektleiter bei ScanTech GmbH, dem beauftragten Dienstleister). Project Manager ist Frau Keller. Zwei Project-Assurance-Rollen sind benannt: die interne Revisionsstelle (Business Assurance) und der behoerdliche Datenschutzbeauftragte (User Assurance). Stages: Pilot (1.000 Dokumente), Hauptphase Welle 1 (Zeitungsarchiv), Welle 2 (Urkunden), Abschluss. Qualitaetskriterium: Scan-Aufloesung mind. 600dpi, Methode: Stichprobenpruefung von 5% der gescannten Dokumente. Ordnen Sie zu, welches Interesse welche Assurance-Funktion im Projekt primaer vertritt.
Szenario Qualitaetsverstoss beim Pilotscan [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO 'Stadtarchiv Digitalisierung': Die Stadt Muenchen digitalisiert historische Archivbestaende. Executive ist Stadtkaemmerin Frau Dr. Vogel, Senior User ist Stadtarchivar Herr Brandt (spaeterer Nutzer der digitalen Bestaende), Senior Supplier ist Herr Ilic (Projektleiter bei ScanTech GmbH, dem beauftragten Dienstleister). Project Manager ist Frau Keller. Zwei Project-Assurance-Rollen sind benannt: die interne Revisionsstelle (Business Assurance) und der behoerdliche Datenschutzbeauftragte (User Assurance). Stages: Pilot (1.000 Dokumente), Hauptphase Welle 1 (Zeitungsarchiv), Welle 2 (Urkunden), Abschluss. Qualitaetskriterium: Scan-Aufloesung mind. 600dpi, Methode: Stichprobenpruefung von 5% der gescannten Dokumente. Beim Pilotscan werden 200 der 1.000 Dokumente mit einer Aufloesung unter 600dpi erfasst und entsprechen damit nicht dem Qualitaetskriterium. Was ist der naechste sinnvolle Schritt gemaess PRINCE2?
❌ Frau Keller entscheidet allein und ohne Dokumentation ueber das weitere Vorgehen.
✅ Der Qualitaetsverstoss wird im Quality Register erfasst und als Issue behandelt, inkl. Entscheidung ueber Nachscan oder Anpassung.
❌ Die 200 Dokumente werden ohne weitere Pruefung oder Dokumentation einfach akzeptiert, da immerhin 800 von 1.000 Dokumenten die Vorgabe erfuellen.
❌ Das gesamte Projekt wird sofort beendet, da ein Qualitaetskriterium verletzt wurde.
Szenario Off-Specification Pilotscan [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO 'Stadtarchiv Digitalisierung': Die Stadt Muenchen digitalisiert historische Archivbestaende. Executive ist Stadtkaemmerin Frau Dr. Vogel, Senior User ist Stadtarchivar Herr Brandt (spaeterer Nutzer der digitalen Bestaende), Senior Supplier ist Herr Ilic (Projektleiter bei ScanTech GmbH, dem beauftragten Dienstleister). Project Manager ist Frau Keller. Zwei Project-Assurance-Rollen sind benannt: die interne Revisionsstelle (Business Assurance) und der behoerdliche Datenschutzbeauftragte (User Assurance). Stages: Pilot (1.000 Dokumente), Hauptphase Welle 1 (Zeitungsarchiv), Welle 2 (Urkunden), Abschluss. Qualitaetskriterium: Scan-Aufloesung mind. 600dpi, Methode: Stichprobenpruefung von 5% der gescannten Dokumente. Wie wuerden die 200 fehlerhaft gescannten Dokumente aus der vorherigen Frage am ehesten klassifiziert?
❌ Als Request for Change, da der Kunde eine hoehere Aufloesung wuenscht.
❌ Als reines Projektziel ('Performance Target'), das nachjustiert werden muss.
✅ Als Off-Specification, da ein bereits geliefertes Produkt eine vereinbarte Anforderung nicht erfuellt.
❌ Als Risiko, weil es noch nicht sicher ist, ob der Mangel wirklich vorliegt.
Szenario Datenschutzrisiko Personenbezug [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO 'Stadtarchiv Digitalisierung': Die Stadt Muenchen digitalisiert historische Archivbestaende. Executive ist Stadtkaemmerin Frau Dr. Vogel, Senior User ist Stadtarchivar Herr Brandt (spaeterer Nutzer der digitalen Bestaende), Senior Supplier ist Herr Ilic (Projektleiter bei ScanTech GmbH, dem beauftragten Dienstleister). Project Manager ist Frau Keller. Zwei Project-Assurance-Rollen sind benannt: die interne Revisionsstelle (Business Assurance) und der behoerdliche Datenschutzbeauftragte (User Assurance). Stages: Pilot (1.000 Dokumente), Hauptphase Welle 1 (Zeitungsarchiv), Welle 2 (Urkunden), Abschluss. Qualitaetskriterium: Scan-Aufloesung mind. 600dpi, Methode: Stichprobenpruefung von 5% der gescannten Dokumente. Der Datenschutzbeauftragte weist frueh darauf hin, dass in historischen Akten personenbezogene Daten enthalten sein koennten, was bei Veroeffentlichung zu einem Datenschutzverstoss fuehren wuerde. In welchem Register/Produkt sollte dies zuerst erfasst werden?
❌ Im Configuration Item Record des jeweiligen Dokuments.
❌ Direkt im Business Case als Kostenposition.
❌ Im Lessons Log, da es sich um eine Erkenntnis aus einem frueheren Projekt handelt.
✅ Im Risk Register, da es sich um ein noch nicht eingetretenes, moegliches Ereignis handelt.
Szenario Chance Foerdermittel DIN-Zertifizierung [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO 'Stadtarchiv Digitalisierung': Die Stadt Muenchen digitalisiert historische Archivbestaende. Executive ist Stadtkaemmerin Frau Dr. Vogel, Senior User ist Stadtarchivar Herr Brandt (spaeterer Nutzer der digitalen Bestaende), Senior Supplier ist Herr Ilic (Projektleiter bei ScanTech GmbH, dem beauftragten Dienstleister). Project Manager ist Frau Keller. Zwei Project-Assurance-Rollen sind benannt: die interne Revisionsstelle (Business Assurance) und der behoerdliche Datenschutzbeauftragte (User Assurance). Stages: Pilot (1.000 Dokumente), Hauptphase Welle 1 (Zeitungsarchiv), Welle 2 (Urkunden), Abschluss. Qualitaetskriterium: Scan-Aufloesung mind. 600dpi, Methode: Stichprobenpruefung von 5% der gescannten Dokumente. Es besteht die Chance auf zusaetzliche Foerdermittel, wenn das Projekt eine DIN-Norm-Zertifizierung fuer die Archivierung erreicht. Das Team beschliesst, gezielt zusaetzliche Qualitaetschecks einzuplanen, um die Zertifizierung sicherer zu erreichen. Welche Strategie liegt vor?
✅ Exploit, da aktiv sichergestellt werden soll, dass die Chance tatsaechlich eintritt.
❌ Reduce, da ein Risiko gemindert wird.
❌ Transfer, da das Risiko an Dritte uebertragen wird.
❌ Accept, da man einfach abwartet und hofft, dass die Zertifizierung sich von selbst und ohne weiteres Zutun ergibt.
Szenario Request for Change Buergerverein [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO 'Stadtarchiv Digitalisierung': Die Stadt Muenchen digitalisiert historische Archivbestaende. Executive ist Stadtkaemmerin Frau Dr. Vogel, Senior User ist Stadtarchivar Herr Brandt (spaeterer Nutzer der digitalen Bestaende), Senior Supplier ist Herr Ilic (Projektleiter bei ScanTech GmbH, dem beauftragten Dienstleister). Project Manager ist Frau Keller. Zwei Project-Assurance-Rollen sind benannt: die interne Revisionsstelle (Business Assurance) und der behoerdliche Datenschutzbeauftragte (User Assurance). Stages: Pilot (1.000 Dokumente), Hauptphase Welle 1 (Zeitungsarchiv), Welle 2 (Urkunden), Abschluss. Qualitaetskriterium: Scan-Aufloesung mind. 600dpi, Methode: Stichprobenpruefung von 5% der gescannten Dokumente. Ein Buergerverein beantragt waehrend Welle 1, dass digitale Kopien zusaetzlich oeffentlich online abrufbar gemacht werden - eine Erweiterung, die urspruenglich nicht im Scope war. Wie wird dieser Antrag korrekt eingeordnet?
✅ Als Request for Change.
❌ Als Off-Specification.
❌ Als Lessons Log-Eintrag.
❌ Als Daily Log-Eintrag ohne weitere Bearbeitung.
Szenario Change Authority ohne Budget [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO 'Stadtarchiv Digitalisierung': Die Stadt Muenchen digitalisiert historische Archivbestaende. Executive ist Stadtkaemmerin Frau Dr. Vogel, Senior User ist Stadtarchivar Herr Brandt (spaeterer Nutzer der digitalen Bestaende), Senior Supplier ist Herr Ilic (Projektleiter bei ScanTech GmbH, dem beauftragten Dienstleister). Project Manager ist Frau Keller. Zwei Project-Assurance-Rollen sind benannt: die interne Revisionsstelle (Business Assurance) und der behoerdliche Datenschutzbeauftragte (User Assurance). Stages: Pilot (1.000 Dokumente), Hauptphase Welle 1 (Zeitungsarchiv), Welle 2 (Urkunden), Abschluss. Qualitaetskriterium: Scan-Aufloesung mind. 600dpi, Methode: Stichprobenpruefung von 5% der gescannten Dokumente. Fuer das Projekt wurde KEINE eigene Change Authority mit eigenem Aenderungsbudget eingerichtet. An wen muss der Request for Change des Buergervereins daher gehen?
❌ An Frau Keller als Project Manager, die abschliessend entscheidet.
✅ An das Project Board bzw. den Executive Frau Dr. Vogel.
❌ An den Datenschutzbeauftragten allein.
❌ An ScanTech GmbH, da diese den technischen Aufwand am besten einschaetzen kann.
Szenario Lessons aus dem Pilot [P] [Practices] 1 Unterseite →
☝️ Single SZENARIO 'Stadtarchiv Digitalisierung': Die Stadt Muenchen digitalisiert historische Archivbestaende. Executive ist Stadtkaemmerin Frau Dr. Vogel, Senior User ist Stadtarchivar Herr Brandt (spaeterer Nutzer der digitalen Bestaende), Senior Supplier ist Herr Ilic (Projektleiter bei ScanTech GmbH, dem beauftragten Dienstleister). Project Manager ist Frau Keller. Zwei Project-Assurance-Rollen sind benannt: die interne Revisionsstelle (Business Assurance) und der behoerdliche Datenschutzbeauftragte (User Assurance). Stages: Pilot (1.000 Dokumente), Hauptphase Welle 1 (Zeitungsarchiv), Welle 2 (Urkunden), Abschluss. Qualitaetskriterium: Scan-Aufloesung mind. 600dpi, Methode: Stichprobenpruefung von 5% der gescannten Dokumente. Nach dem Pilot mit den 200 fehlerhaften Scans haelt Frau Keller fest: 'Scan-Geraete muessen vor jeder neuen Welle neu kalibriert werden.' Wo gehoert diese Erkenntnis fuer die laufende Nutzung waehrend des Projekts zunaechst hin?
❌ In den Business Case als neue Nutzenkategorie.
✅ In das laufend gepflegte Lessons Log, damit sie in Welle 1 und 2 direkt angewendet werden kann.
❌ Ausschliesslich in den finalen Lessons Report, der erst ganz am Projektende erstellt und verteilt wird.
❌ In das Risikoregister als bereits abgeschlossenes Risiko.
Mini-Szenario Produktbeschreibung vor Aktivitaeten [P] [Practices] 1 Unterseite →
☝️ Single Bevor ein Team mit der Entwicklung eines neuen Berichtsmoduls beginnt, verlangt der Project Manager zunaechst eine schriftliche Festlegung von Zweck, Zusammensetzung und Abnahmekriterien des Moduls. Welches Prinzip UND welches Produkt stehen hier im Vordergrund?
❌ Tailor to Suit the Project und die PID.
✅ Focus on Products und die Product Description.
❌ Learn from Experience und das Lessons Log.
❌ Manage by Exception und der Exception Report.
Mini-Szenario Plans-Practice Ebenen [P] [Practices] 1 Unterseite →
☝️ Single Ein Project Manager erstellt einen Projektplan fuer das gesamte Vorhaben, einen detaillierteren Plan je Stage sowie bei Bedarf Teamplaene fuer einzelne Arbeitspakete. Welche Practice wird hier angewendet und auf wie vielen Ebenen typischerweise?
❌ Quality, auf einer einzigen Ebene (Projekt).
❌ Progress, auf zwei Ebenen (Projekt und Stage).
✅ Plans, typischerweise auf drei Ebenen (Projekt, Stage, Team).
❌ Risk, auf vier Ebenen.
Mini-Szenario Progress Toleranzverletzung Team [P] [Practices] 1 Unterseite →
☝️ Single Ein Teammitglied meldet dem Team Manager, dass ein Arbeitspaket voraussichtlich eine Woche spaeter fertig wird, was die gesetzte Zeittoleranz des Arbeitspakets ueberschreitet. Was ist der naechste PRINCE2-konforme Schritt des Team Managers?
❌ Er informiert direkt das Project Board unter Umgehung des Project Managers.
❌ Er wartet ab, ob sich die Verzoegerung von selbst aufloest.
✅ Er informiert den Project Manager, da die Toleranz auf Arbeitspaket-Ebene ueberschritten wird.
❌ Er passt die Toleranz einfach selbststaendig an, ohne den Project Manager ueberhaupt zu informieren oder einzubeziehen.
Mini-Szenario Tolerance-Ebenen im Konflikt [P] [Practices] 1 Unterseite →
☝️ Single Ein Project Manager stellt fest, dass die Gesamtprojekt-Zeittoleranz trotz mehrerer kleiner, jeweils noch tolerierbarer Verzoegerungen auf mehreren Stages in Summe ueberschritten werden koennte. Was ist hier zu beachten?
❌ Nichts, solange jede einzelne Stage fuer sich innerhalb ihrer eigenen Toleranz bleibt.
❌ Eine Ueberschreitung der Projekttoleranz ist ausschliesslich und unter allen Umstaenden direkt beim Executive persoenlich zu melden, niemals jedoch beim gesamten Project Board.
✅ Auch kumulierte Effekte ueber mehrere Stages hinweg koennen die uebergeordnete Projekttoleranz gefaehrden und muessen beobachtet werden.
❌ Toleranzen gelten ausschliesslich auf Projektebene, nicht auf Stage-Ebene.
Mini-Szenario Assurance vs. Support [P] [Practices] 1 Unterseite →
☝️ Single Eine Person im Projekt kuemmert sich um Terminkoordination und Dokumentenverwaltung, eine andere prueft unabhaengig, ob das Projekt im Sinne der Nutzerinteressen laeuft. Wie werden diese beiden Rollen korrekt bezeichnet?
❌ Beide sind Project Support.
❌ Erstere ist Project Assurance, letztere ist Project Support.
✅ Erstere ist Project Support, letztere ist (User) Project Assurance.
❌ Beide sind Project Assurance.
Mini-Szenario Exception Report Inhalt [P] [Practices] 1 Unterseite →
☝️ Single Ein Project Manager moechte einen Exception Report verfassen, weil die Kosten einer Stage die Toleranz um 12% ueberschreiten werden. Welchen Kerninhalt muss dieser Bericht mindestens liefern?
❌ Eine bereits final und ohne jede Ruecksprache mit dem Project Board getroffene Entscheidung des Project Managers ohne jegliche Optionen.
✅ Ursache der Abweichung, Optionen zum weiteren Vorgehen sowie eine Empfehlung, damit das Project Board entscheiden kann.
❌ Ausschliesslich eine Entschuldigung fuer die Verzoegerung.
❌ Nur eine neue Zeitplanung ohne Bezug zu den Kosten.
Mini-Szenario Priorisierung mehrerer Risiken [P] [Practices] 1 Unterseite →
☝️ Single Im Risk Register eines Projekts stehen drei Bedrohungen mit unterschiedlicher Eintrittswahrscheinlichkeit und Auswirkung. Wonach sollte das Team die Bearbeitungsreihenfolge in erster Linie ausrichten?
❌ Ausschliesslich nach dem Datum der Erfassung im Register (zuerst erfasst, zuerst bearbeitet).
✅ Nach dem bewerteten Risikograd aus Wahrscheinlichkeit und Auswirkung.
❌ Nach persoenlicher Praeferenz des Project Managers ohne weitere Bewertung.
❌ Ausschliesslich alphabetisch nach dem Namen des Risikos.
Fallstudie WerftOne [P] [Practices] 5 Unterseite →
☝️ Single FALLSTUDIE „WerftOne“: Die Nordwerft Systems GmbH (Schiffsausrüster, 420 Mitarbeitende) löst ihr 20 Jahre altes ERP-System durch eine neue Standardsoftware ab. Executive ist Frau Brandes (Vorständin Finanzen), Senior User Herr Petersen (Leiter Produktion), Senior Supplier Herr Okafor (Vertriebsleiter des Softwareherstellers Arcon), Project Manager Frau Lindner. Team Manager für die Konfiguration ist Frau Sato von Arcon. Budget 1,8 Mio. €, Laufzeit 14 Monate, vier Stages (Initiierung, Design & Konfiguration, Test & Datenmigration, Go-live & Abschluss). Stage-Toleranzen: Zeit ±3 Wochen, Kosten ±5 %. Das Change-Budget beträgt 60.000 €, davon sind 10.000 € verbraucht; als Change Authority ist ein Gremium aus Herrn Petersen und Frau Lindner benannt. Erwarteter Nutzen: 12 % geringere Lagerbestandskosten, messbar frühestens 18 Monate nach Go-live. Frage: In Stage 2 fordert die Einkaufsleiterin Frau Wolff, den Beschaffungsprozess abweichend vom Standard abzubilden. Die Impact-Analyse ergibt 25.000 € Mehrkosten, keine Auswirkung auf Termin und Qualität. Wer entscheidet über den Änderungsantrag?
✅ Die Change Authority, weil die Kosten innerhalb des verbleibenden Change-Budgets (50.000 €) liegen
❌ Frau Brandes allein als Executive, da sie den Business Case verantwortet
❌ Herr Okafor, da Arcon die Änderung umsetzen muss und die Kosten kalkuliert
❌ Das gesamte Project Board, da jede Änderung an einer Baseline vom Board freigegeben werden muss
Die Change Authority hat vom Board die Befugnis (und ein Change-Budget) erhalten, Änderungen innerhalb dieses Rahmens selbst zu entscheiden. Nur wenn Budget, Toleranzen oder Umfang überschritten würden, ginge die Entscheidung an das Project Board.
☝️ Single FALLSTUDIE „WerftOne“: Die Nordwerft Systems GmbH (Schiffsausrüster, 420 Mitarbeitende) löst ihr 20 Jahre altes ERP-System durch eine neue Standardsoftware ab. Executive ist Frau Brandes (Vorständin Finanzen), Senior User Herr Petersen (Leiter Produktion), Senior Supplier Herr Okafor (Vertriebsleiter des Softwareherstellers Arcon), Project Manager Frau Lindner. Team Manager für die Konfiguration ist Frau Sato von Arcon. Budget 1,8 Mio. €, Laufzeit 14 Monate, vier Stages (Initiierung, Design & Konfiguration, Test & Datenmigration, Go-live & Abschluss). Stage-Toleranzen: Zeit ±3 Wochen, Kosten ±5 %. Das Change-Budget beträgt 60.000 €, davon sind 10.000 € verbraucht; als Change Authority ist ein Gremium aus Herrn Petersen und Frau Lindner benannt. Erwarteter Nutzen: 12 % geringere Lagerbestandskosten, messbar frühestens 18 Monate nach Go-live. Frage: In Stage 3 (Stage-Budget 300.000 €) prognostiziert Frau Lindner wegen der aufwendigen Bereinigung der Stammdaten Stage-Kosten von 336.000 €. Was muss sie tun?
❌ Das Team anweisen, die Qualität der Datenbereinigung zu reduzieren, bis die Kosten wieder passen
❌ Die Mehrkosten aus dem Change-Budget bezahlen, da dieses für unvorhergesehene Kosten vorgesehen ist
❌ Den Sachverhalt im nächsten Highlight Report erwähnen und bis zum Stage-Ende abwarten
✅ Sofort einen Exception Report an das Project Board erstellen, da die Toleranz voraussichtlich überschritten wird
336.000 € sind +12 % gegenüber 300.000 € und liegen damit klar über der Toleranz von ±5 %. Bei prognostizierter Überschreitung ist unverzüglich per Exception Report an das Project Board zu eskalieren (Manage by Exception). Das Change-Budget dient Änderungen am Umfang, nicht dem Ausgleich von Kostenüberschreitungen.
☝️ Single FALLSTUDIE „WerftOne“: Die Nordwerft Systems GmbH (Schiffsausrüster, 420 Mitarbeitende) löst ihr 20 Jahre altes ERP-System durch eine neue Standardsoftware ab. Executive ist Frau Brandes (Vorständin Finanzen), Senior User Herr Petersen (Leiter Produktion), Senior Supplier Herr Okafor (Vertriebsleiter des Softwareherstellers Arcon), Project Manager Frau Lindner. Team Manager für die Konfiguration ist Frau Sato von Arcon. Budget 1,8 Mio. €, Laufzeit 14 Monate, vier Stages (Initiierung, Design & Konfiguration, Test & Datenmigration, Go-live & Abschluss). Stage-Toleranzen: Zeit ±3 Wochen, Kosten ±5 %. Das Change-Budget beträgt 60.000 €, davon sind 10.000 € verbraucht; als Change Authority ist ein Gremium aus Herrn Petersen und Frau Lindner benannt. Erwarteter Nutzen: 12 % geringere Lagerbestandskosten, messbar frühestens 18 Monate nach Go-live. Frage: Zu Beginn der Initiierung will Frau Lindner projektweit festlegen, welche Qualitätsmethoden angewendet werden und wer für Qualitätsprüfungen zuständig ist. Wo hält sie das fest?
❌ In der Product Description des Projektprodukts, die alle Qualitätsverantwortlichkeiten abschließend regelt
✅ Im Quality Management Approach (Bestandteil der Projektinitiierungsdokumentation)
❌ Im Stage Plan der Initiierungsstage, der für das gesamte Projekt gilt
❌ Im Quality Register, in dem einzelne Prüfungen und ihre Ergebnisse nachverfolgt werden
Der Quality Management Approach beschreibt, WIE Qualität im Projekt gesichert wird (Methoden, Rollen, Verantwortlichkeiten). Das Quality Register dokumentiert die einzelnen geplanten und durchgeführten Prüfungen.
☝️ Single FALLSTUDIE „WerftOne“: Die Nordwerft Systems GmbH (Schiffsausrüster, 420 Mitarbeitende) löst ihr 20 Jahre altes ERP-System durch eine neue Standardsoftware ab. Executive ist Frau Brandes (Vorständin Finanzen), Senior User Herr Petersen (Leiter Produktion), Senior Supplier Herr Okafor (Vertriebsleiter des Softwareherstellers Arcon), Project Manager Frau Lindner. Team Manager für die Konfiguration ist Frau Sato von Arcon. Budget 1,8 Mio. €, Laufzeit 14 Monate, vier Stages (Initiierung, Design & Konfiguration, Test & Datenmigration, Go-live & Abschluss). Stage-Toleranzen: Zeit ±3 Wochen, Kosten ±5 %. Das Change-Budget beträgt 60.000 €, davon sind 10.000 € verbraucht; als Change Authority ist ein Gremium aus Herrn Petersen und Frau Lindner benannt. Erwarteter Nutzen: 12 % geringere Lagerbestandskosten, messbar frühestens 18 Monate nach Go-live. Frage: Frau Sato übergibt Frau Lindner jede Woche einen Bericht über den Stand ihres Work Packages (erreichte Produkte, Aufwand, Probleme). Wie heißt dieses Management-Produkt?
✅ Checkpoint Report
❌ Highlight Report
❌ Exception Report
❌ End Stage Report
Der Checkpoint Report geht vom Team Manager an den Project Manager (Fortschritt eines Work Packages). Der Highlight Report geht vom Project Manager an das Project Board.
☝️ Single FALLSTUDIE „WerftOne“: Die Nordwerft Systems GmbH (Schiffsausrüster, 420 Mitarbeitende) löst ihr 20 Jahre altes ERP-System durch eine neue Standardsoftware ab. Executive ist Frau Brandes (Vorständin Finanzen), Senior User Herr Petersen (Leiter Produktion), Senior Supplier Herr Okafor (Vertriebsleiter des Softwareherstellers Arcon), Project Manager Frau Lindner. Team Manager für die Konfiguration ist Frau Sato von Arcon. Budget 1,8 Mio. €, Laufzeit 14 Monate, vier Stages (Initiierung, Design & Konfiguration, Test & Datenmigration, Go-live & Abschluss). Stage-Toleranzen: Zeit ±3 Wochen, Kosten ±5 %. Das Change-Budget beträgt 60.000 €, davon sind 10.000 € verbraucht; als Change Authority ist ein Gremium aus Herrn Petersen und Frau Lindner benannt. Erwarteter Nutzen: 12 % geringere Lagerbestandskosten, messbar frühestens 18 Monate nach Go-live. Frage: Der erwartete Nutzen (–12 % Lagerbestandskosten) tritt erst 18 Monate nach Go-live und damit nach Projektende ein. Wie stellt PRINCE2 sicher, dass er trotzdem überprüft wird?
❌ Gar nicht – die Nutzenmessung endet mit dem Projekt, denn nur Outputs sind Projektgegenstand
❌ Das Projekt bleibt bis zur Nutzenmessung offen und wird nicht formal abgeschlossen
✅ Über den Benefits Management Approach: Benefit Reviews nach Projektende, Übergabe per Follow-on Actions
❌ Die letzte Stage wird um 18 Monate verlängert, damit der Project Manager den Nutzen misst
Nutzen entsteht meist nach Projektende. Der Benefits Management Approach legt fest, wann und von wem er gemessen wird; in Closing a Project werden Benefit Reviews und Follow-on Actions an die Linienorganisation übergeben.
Zuordnung Risikoreaktionen WerftOne [P] [Practices] 1 Unterseite →
matching FALLSTUDIE „WerftOne“: Die Nordwerft Systems GmbH (Schiffsausrüster, 420 Mitarbeitende) löst ihr 20 Jahre altes ERP-System durch eine neue Standardsoftware ab. Executive ist Frau Brandes (Vorständin Finanzen), Senior User Herr Petersen (Leiter Produktion), Senior Supplier Herr Okafor (Vertriebsleiter des Softwareherstellers Arcon), Project Manager Frau Lindner. Team Manager für die Konfiguration ist Frau Sato von Arcon. Budget 1,8 Mio. €, Laufzeit 14 Monate, vier Stages (Initiierung, Design & Konfiguration, Test & Datenmigration, Go-live & Abschluss). Stage-Toleranzen: Zeit ±3 Wochen, Kosten ±5 %. Das Change-Budget beträgt 60.000 €, davon sind 10.000 € verbraucht; als Change Authority ist ein Gremium aus Herrn Petersen und Frau Lindner benannt. Erwarteter Nutzen: 12 % geringere Lagerbestandskosten, messbar frühestens 18 Monate nach Go-live. Frage: Frau Lindner behandelt drei Bedrohungen im Risk Register. Ordnen Sie jeder Maßnahme die passende Risikoreaktion zu.
Festpreis = Risiko vertraglich auf den Dienstleister übertragen. Zweiter Berater = Wahrscheinlichkeit/Auswirkung mindern. Verzicht auf die Funktion = Ursache beseitigen (Avoid). Exploit gilt nur für Chancen, Accept wäre bewusstes Hinnehmen ohne Maßnahme.
Zuordnung Rollen WerftOne [P] [Practices] 1 Unterseite →
matching FALLSTUDIE „WerftOne“: Die Nordwerft Systems GmbH (Schiffsausrüster, 420 Mitarbeitende) löst ihr 20 Jahre altes ERP-System durch eine neue Standardsoftware ab. Executive ist Frau Brandes (Vorständin Finanzen), Senior User Herr Petersen (Leiter Produktion), Senior Supplier Herr Okafor (Vertriebsleiter des Softwareherstellers Arcon), Project Manager Frau Lindner. Team Manager für die Konfiguration ist Frau Sato von Arcon. Budget 1,8 Mio. €, Laufzeit 14 Monate, vier Stages (Initiierung, Design & Konfiguration, Test & Datenmigration, Go-live & Abschluss). Stage-Toleranzen: Zeit ±3 Wochen, Kosten ±5 %. Das Change-Budget beträgt 60.000 €, davon sind 10.000 € verbraucht; als Change Authority ist ein Gremium aus Herrn Petersen und Frau Lindner benannt. Erwarteter Nutzen: 12 % geringere Lagerbestandskosten, messbar frühestens 18 Monate nach Go-live. Frage: Ordnen Sie jeder Beschreibung die Rolle zu, die im Projekt WerftOne dafür verantwortlich ist.
Change Authority: Änderungen im delegierten Budget. Team Manager: liefert Work Packages und berichtet dem PM. Project Manager: plant Stages, vergibt Work Packages. Project Board: Stage-Autorisierung. Project Support und Assurance sind hier Distraktoren.
Fallstudie Campus Nord [P] [Practices] 6 Unterseite →
☝️ Single FALLSTUDIE „Campus Nord“: Die Hochschule Rheinbach errichtet ein Lernzentrum mit Bibliothek (Neubau, Budget 8,5 Mio. €, davon 6 Mio. € Landesförderung; der Förderbescheid verlangt die Fertigstellung bis 31. Juli). Executive ist Kanzlerin Frau Dr. Weiß, Senior User Prof. Haas (Leiter der Bibliothek), Senior Supplier Herr Demir (Projektleiter der Demir Bau AG). Project Manager ist Herr Krüger; Frau Lenz unterstützt ihn als Project Support; das Hochschul-Controlling prüft unabhängig die Kostenentwicklung. Herr Voss (Bauleiter der Demir Bau AG) ist Team Manager. Fünf Stages: Planung & Genehmigung, Rohbau, Ausbau, Technik & Ausstattung, Abnahme & Übergabe. Stage-Toleranzen: Zeit ±4 Wochen, Kosten ±3 %. Ziel ist eine DGNB-Gold-Zertifizierung. Frage: Herr Krüger schlägt vor, dass Frau Lenz zusätzlich die Business Assurance übernimmt, da sie alle Kostenlisten kennt. Wie ist das zu bewerten?
✅ Nicht sinnvoll: Assurance muss vom Project Manager unabhängig sein; Project Support unterstützt den PM
❌ Zulässig, da Project Support ohnehin die Registers pflegt und daher die beste Datenbasis hat
❌ Unzulässig, da Business Assurance ausschließlich dem Executive persönlich zugewiesen werden darf
❌ Zulässig, wenn Herr Voss als Team Manager die Ergebnisse der Business Assurance zusätzlich gegenprüft
Assurance dient der unabhängigen Überwachung im Auftrag des Boards und darf nicht vom Project Manager oder seinem Support-Team gesteuert werden. Das Controlling ist hier die geeignete unabhängige Stelle.
☝️ Single FALLSTUDIE „Campus Nord“: Die Hochschule Rheinbach errichtet ein Lernzentrum mit Bibliothek (Neubau, Budget 8,5 Mio. €, davon 6 Mio. € Landesförderung; der Förderbescheid verlangt die Fertigstellung bis 31. Juli). Executive ist Kanzlerin Frau Dr. Weiß, Senior User Prof. Haas (Leiter der Bibliothek), Senior Supplier Herr Demir (Projektleiter der Demir Bau AG). Project Manager ist Herr Krüger; Frau Lenz unterstützt ihn als Project Support; das Hochschul-Controlling prüft unabhängig die Kostenentwicklung. Herr Voss (Bauleiter der Demir Bau AG) ist Team Manager. Fünf Stages: Planung & Genehmigung, Rohbau, Ausbau, Technik & Ausstattung, Abnahme & Übergabe. Stage-Toleranzen: Zeit ±4 Wochen, Kosten ±3 %. Ziel ist eine DGNB-Gold-Zertifizierung. Frage: Die Baugenehmigung verzögert sich. Nach einem Exception Report verlängert das Board Stage 1 und bittet um einen Exception Plan. Was ist ein Exception Plan?
❌ Ein Ersatz für den gesamten Project Plan, nach dessen Genehmigung das Projekt formal neu gestartet wird
❌ Ein Notfallplan, der vorab für den Eintritt eines bestimmten Risikos erstellt und bei Bedarf aktiviert wird
❌ Ein Bericht, der die Ursachen der Verzögerung analysiert und die Verantwortlichen benennt, damit Konsequenzen gezogen werden können
✅ Ein Plan für die verbleibende Arbeit der Stage, der den bisherigen Stage Plan ersetzt und vom Board genehmigt wird
Der Exception Plan hat das Format des Plans, den er ersetzt (hier Stage Plan), und deckt die verbleibende Arbeit bis zum Stage-Ende ab. Ein vorab erstellter Notfallplan wäre ein Contingent Plan.
☝️ Single FALLSTUDIE „Campus Nord“: Die Hochschule Rheinbach errichtet ein Lernzentrum mit Bibliothek (Neubau, Budget 8,5 Mio. €, davon 6 Mio. € Landesförderung; der Förderbescheid verlangt die Fertigstellung bis 31. Juli). Executive ist Kanzlerin Frau Dr. Weiß, Senior User Prof. Haas (Leiter der Bibliothek), Senior Supplier Herr Demir (Projektleiter der Demir Bau AG). Project Manager ist Herr Krüger; Frau Lenz unterstützt ihn als Project Support; das Hochschul-Controlling prüft unabhängig die Kostenentwicklung. Herr Voss (Bauleiter der Demir Bau AG) ist Team Manager. Fünf Stages: Planung & Genehmigung, Rohbau, Ausbau, Technik & Ausstattung, Abnahme & Übergabe. Stage-Toleranzen: Zeit ±4 Wochen, Kosten ±3 %. Ziel ist eine DGNB-Gold-Zertifizierung. Frage: Im Risk Register steht „Stahlpreisanstieg und Lieferengpass“: Wahrscheinlichkeit hoch, Auswirkung mittel, Eintritt frühestens in neun Monaten (Stage 3). Welche Risikoeigenschaft beschreibt den Zeitpunkt, ab dem das Risiko eintreten kann?
❌ Risikotoleranz (Risk Tolerance)
❌ Wahrscheinlichkeit (Probability)
❌ Auswirkung (Impact)
✅ Nähe (Proximity)
Proximity beschreibt, wann ein Risiko eintreten kann. Sie hilft bei der Priorisierung: Ein nahes Risiko braucht früher Maßnahmen als ein fernes mit gleicher Bewertung.
☝️ Single FALLSTUDIE „Campus Nord“: Die Hochschule Rheinbach errichtet ein Lernzentrum mit Bibliothek (Neubau, Budget 8,5 Mio. €, davon 6 Mio. € Landesförderung; der Förderbescheid verlangt die Fertigstellung bis 31. Juli). Executive ist Kanzlerin Frau Dr. Weiß, Senior User Prof. Haas (Leiter der Bibliothek), Senior Supplier Herr Demir (Projektleiter der Demir Bau AG). Project Manager ist Herr Krüger; Frau Lenz unterstützt ihn als Project Support; das Hochschul-Controlling prüft unabhängig die Kostenentwicklung. Herr Voss (Bauleiter der Demir Bau AG) ist Team Manager. Fünf Stages: Planung & Genehmigung, Rohbau, Ausbau, Technik & Ausstattung, Abnahme & Übergabe. Stage-Toleranzen: Zeit ±4 Wochen, Kosten ±3 %. Ziel ist eine DGNB-Gold-Zertifizierung. Frage: Die Hochschule erklärt: „Wir sind grundsätzlich nicht bereit, Risiken einzugehen, die die Landesförderung gefährden.“ Welcher Begriff beschreibt diese grundsätzliche Haltung?
❌ Risikoreaktion „Akzeptieren“ als bewusstes Hinnehmen eines einzelnen Risikos
❌ Risikoeigner (Risk Owner) als verantwortliche Person für ein einzelnes Risiko
✅ Risikobereitschaft (Risk Appetite): wie viel Risiko die Organisation einzugehen bereit ist
❌ Risikotoleranz (Risk Tolerance) als konkreter Schwellenwert einer einzelnen Stage
Risk Appetite ist die grundsätzliche Haltung einer Organisation zu Risiko. Risk Tolerance sind daraus abgeleitete, konkrete Schwellenwerte, ab denen eskaliert werden muss.
☝️ Single FALLSTUDIE „Campus Nord“: Die Hochschule Rheinbach errichtet ein Lernzentrum mit Bibliothek (Neubau, Budget 8,5 Mio. €, davon 6 Mio. € Landesförderung; der Förderbescheid verlangt die Fertigstellung bis 31. Juli). Executive ist Kanzlerin Frau Dr. Weiß, Senior User Prof. Haas (Leiter der Bibliothek), Senior Supplier Herr Demir (Projektleiter der Demir Bau AG). Project Manager ist Herr Krüger; Frau Lenz unterstützt ihn als Project Support; das Hochschul-Controlling prüft unabhängig die Kostenentwicklung. Herr Voss (Bauleiter der Demir Bau AG) ist Team Manager. Fünf Stages: Planung & Genehmigung, Rohbau, Ausbau, Technik & Ausstattung, Abnahme & Übergabe. Stage-Toleranzen: Zeit ±4 Wochen, Kosten ±3 %. Ziel ist eine DGNB-Gold-Zertifizierung. Frage: Die Abnahme des Rohbaus erfolgt durch einen externen Prüfsachverständigen. Wo dokumentiert das Projekt geplante und durchgeführte Qualitätsprüfungen mit Termin, Prüfer und Ergebnis?
❌ Im Project Brief der Initiierung
✅ Im Quality Register
❌ Im Risk Register (Risk Log)
❌ Im Lessons Log des Projekts
Das Quality Register enthält alle geplanten und durchgeführten Qualitätsaktivitäten samt Ergebnissen und dient als Nachweis, dass Produkte geprüft wurden.
☝️ Single FALLSTUDIE „Campus Nord“: Die Hochschule Rheinbach errichtet ein Lernzentrum mit Bibliothek (Neubau, Budget 8,5 Mio. €, davon 6 Mio. € Landesförderung; der Förderbescheid verlangt die Fertigstellung bis 31. Juli). Executive ist Kanzlerin Frau Dr. Weiß, Senior User Prof. Haas (Leiter der Bibliothek), Senior Supplier Herr Demir (Projektleiter der Demir Bau AG). Project Manager ist Herr Krüger; Frau Lenz unterstützt ihn als Project Support; das Hochschul-Controlling prüft unabhängig die Kostenentwicklung. Herr Voss (Bauleiter der Demir Bau AG) ist Team Manager. Fünf Stages: Planung & Genehmigung, Rohbau, Ausbau, Technik & Ausstattung, Abnahme & Übergabe. Stage-Toleranzen: Zeit ±4 Wochen, Kosten ±3 %. Ziel ist eine DGNB-Gold-Zertifizierung. Frage: Auf der Baustelle wurde nach Planversion 3 gebaut, obwohl Version 4 freigegeben war; niemand verfolgte, welche Version gültig ist. Welche Aufgabe übernimmt in PRINCE2 typischerweise Project Support, um das künftig zu vermeiden?
✅ Konfigurationsmanagement: Versionen und Status der Produkte in Configuration Item Records führen
❌ Die Toleranzen der Stage festlegen und bei Überschreitung an die Konzernleitung eskalieren
❌ Über Änderungsanträge entscheiden und dazu das Change-Budget des Projekts verwalten
❌ Unabhängig im Auftrag des Boards bewerten, ob die Bauqualität den Nutzerinteressen entspricht
Project Support übernimmt administrative Aufgaben wie Konfigurationsmanagement (Version, Status, Baselines der Configuration Items). Entscheidungen über Änderungen trifft die Change Authority, Toleranzen setzt das Board.
Fallstudie Smart Meter [P] [Practices] 7 Unterseite →
☝️ Single FALLSTUDIE „Smart Meter Rollout“: Die Stadtwerke Rheinau müssen bis zum 31.12. 80.000 konventionelle Stromzähler durch Smart Meter ersetzen; die Frist ist vom Gesellschafterkreis (übergeordnete Ebene) als feste Projektgrenze vorgegeben. Executive ist Herr Dr. Amsel (Geschäftsführer), Senior User Frau Kowalski (Leiterin Netzbetrieb), Senior Supplier Herr Tan (Vertriebsdirektor des Zählerherstellers MeterTec GmbH). Project Manager ist Frau Ostermann, Team Manager Herr Riedel (Montagepartner). Stages: Initiierung, Pilot (2.000 Zähler), Rollout Süd, Rollout Nord, Abschluss. Stage-Toleranzen: Zeit ±3 Wochen, Kosten ±4 %. Qualitätskriterium: Kommunikationsfehlerquote der eingebauten Zähler unter 1 %. Frage: MeterTec kann die zugesagte Liefermenge für Rollout Süd nicht einhalten. Wer im Project Board ist in erster Linie dafür verantwortlich, dass die Lieferseite Ressourcen und Liefertreue sicherstellt?
✅ Der Senior Supplier (Herr Tan)
❌ Der Executive (Herr Dr. Amsel) allein
❌ Der Senior User (Frau Kowalski)
❌ Der Project Manager (Frau Ostermann)
Der Senior Supplier vertritt die Lieferseite im Board und stellt Ressourcen, Fachwissen und Liefertreue seiner Organisation sicher. Der Senior User vertritt die Nutzerseite.
☝️ Single FALLSTUDIE „Smart Meter Rollout“: Die Stadtwerke Rheinau müssen bis zum 31.12. 80.000 konventionelle Stromzähler durch Smart Meter ersetzen; die Frist ist vom Gesellschafterkreis (übergeordnete Ebene) als feste Projektgrenze vorgegeben. Executive ist Herr Dr. Amsel (Geschäftsführer), Senior User Frau Kowalski (Leiterin Netzbetrieb), Senior Supplier Herr Tan (Vertriebsdirektor des Zählerherstellers MeterTec GmbH). Project Manager ist Frau Ostermann, Team Manager Herr Riedel (Montagepartner). Stages: Initiierung, Pilot (2.000 Zähler), Rollout Süd, Rollout Nord, Abschluss. Stage-Toleranzen: Zeit ±3 Wochen, Kosten ±4 %. Qualitätskriterium: Kommunikationsfehlerquote der eingebauten Zähler unter 1 %. Frage: In Rollout Süd zeichnet sich ab, dass die Frist 31.12. nicht mehr gehalten werden kann, auch wenn das Board Stage-Zeit nachgibt. Wer entscheidet dann über das weitere Vorgehen?
❌ Das Project Board entscheidet allein, da es die Projekttoleranz jederzeit ändern darf
❌ Herr Tan als Senior Supplier, da er die Verzögerung zu verantworten hat
❌ Frau Ostermann verlängert die Frist im Rahmen ihrer Stage-Befugnis
✅ Das Project Board eskaliert an die übergeordnete Ebene, die die Projekttoleranz vorgegeben hat
Projekttoleranzen setzt die Ebene über dem Board (Corporate/Programme Management/Auftraggeber). Das Board darf sie nicht selbst aufweichen, sondern muss eine drohende Überschreitung dorthin eskalieren.
☝️ Single FALLSTUDIE „Smart Meter Rollout“: Die Stadtwerke Rheinau müssen bis zum 31.12. 80.000 konventionelle Stromzähler durch Smart Meter ersetzen; die Frist ist vom Gesellschafterkreis (übergeordnete Ebene) als feste Projektgrenze vorgegeben. Executive ist Herr Dr. Amsel (Geschäftsführer), Senior User Frau Kowalski (Leiterin Netzbetrieb), Senior Supplier Herr Tan (Vertriebsdirektor des Zählerherstellers MeterTec GmbH). Project Manager ist Frau Ostermann, Team Manager Herr Riedel (Montagepartner). Stages: Initiierung, Pilot (2.000 Zähler), Rollout Süd, Rollout Nord, Abschluss. Stage-Toleranzen: Zeit ±3 Wochen, Kosten ±4 %. Qualitätskriterium: Kommunikationsfehlerquote der eingebauten Zähler unter 1 %. Frage: Die Bundesnetzagentur erlässt eine neue Pflicht zur Verschlüsselung der Datenübertragung; die Zähler-Spezifikation muss ergänzt werden. Wie ist das als Issue einzuordnen?
❌ Als Off-Specification, weil ein Produkt die Spezifikation nicht erfüllt
❌ Als Problem/Concern, das der Project Manager allein ohne Bewertung entscheidet
✅ Als Request for Change (Änderungsantrag), weil sich eine freigegebene Anforderung ändert
❌ Als Risiko, das ausschließlich im Risk Register geführt wird
Ändert sich eine freigegebene Anforderung, ist es ein Request for Change. Off-Specification liegt vor, wenn ein Produkt hinter der geforderten Spezifikation zurückbleibt.
☝️ Single FALLSTUDIE „Smart Meter Rollout“: Die Stadtwerke Rheinau müssen bis zum 31.12. 80.000 konventionelle Stromzähler durch Smart Meter ersetzen; die Frist ist vom Gesellschafterkreis (übergeordnete Ebene) als feste Projektgrenze vorgegeben. Executive ist Herr Dr. Amsel (Geschäftsführer), Senior User Frau Kowalski (Leiterin Netzbetrieb), Senior Supplier Herr Tan (Vertriebsdirektor des Zählerherstellers MeterTec GmbH). Project Manager ist Frau Ostermann, Team Manager Herr Riedel (Montagepartner). Stages: Initiierung, Pilot (2.000 Zähler), Rollout Süd, Rollout Nord, Abschluss. Stage-Toleranzen: Zeit ±3 Wochen, Kosten ±4 %. Qualitätskriterium: Kommunikationsfehlerquote der eingebauten Zähler unter 1 %. Frage: Im Pilot melden 3,4 % der eingebauten Zähler Kommunikationsfehler; gefordert waren unter 1 %. Wie ist der Sachverhalt einzuordnen und zu behandeln?
❌ Kein Issue, sondern nur ein Eintrag im Lessons Log, damit spätere Projekte daraus lernen können
❌ Request for Change: das Qualitätskriterium wird dadurch automatisch auf 3,5 % angehoben und gilt danach als erfüllt
✅ Off-Specification: im Issue Register erfassen, bewerten; Nacharbeit oder Zugeständnis (Concession) entscheiden lassen
❌ Ein Risiko, das mit einer Wahrscheinlichkeit von 100 % im Risk Register geführt werden muss
Die Produkte erfüllen das vereinbarte Kriterium nicht: Off-Specification. Sie wird als Issue erfasst und bewertet; Optionen sind Nacharbeit oder ein formales Zugeständnis durch die zuständige Stelle.
Merksatz: Soll-Ist-Klafft bei Qualität → Off-Specification ins Issue Register, dann Nacharbeit oder Concession.

Warum die anderen falsch sind:
  • Lessons Log: bereits eingetretener Qualitätsmangel ist kein Lernnotiz-Fall.

  • Request for Change: Qualitätskriterium senken ist kein Automatismus, sondern formale Entscheidung.

  • Risiko: 100 % eingetreten ist kein Risiko mehr, sondern Ist-Abweichung.
☝️ Single FALLSTUDIE „Smart Meter Rollout“: Die Stadtwerke Rheinau müssen bis zum 31.12. 80.000 konventionelle Stromzähler durch Smart Meter ersetzen; die Frist ist vom Gesellschafterkreis (übergeordnete Ebene) als feste Projektgrenze vorgegeben. Executive ist Herr Dr. Amsel (Geschäftsführer), Senior User Frau Kowalski (Leiterin Netzbetrieb), Senior Supplier Herr Tan (Vertriebsdirektor des Zählerherstellers MeterTec GmbH). Project Manager ist Frau Ostermann, Team Manager Herr Riedel (Montagepartner). Stages: Initiierung, Pilot (2.000 Zähler), Rollout Süd, Rollout Nord, Abschluss. Stage-Toleranzen: Zeit ±3 Wochen, Kosten ±4 %. Qualitätskriterium: Kommunikationsfehlerquote der eingebauten Zähler unter 1 %. Frage: Für Rollout Süd will Frau Ostermann festhalten, in welcher Reihenfolge Zähler-Firmware, Installationsteams und Kundeninformation entstehen und welche Abhängigkeiten dabei bestehen. Welche Planungstechnik zeigt das?
❌ Product Description, die Reihenfolge und Abhängigkeiten aller Produkte beschreibt
✅ Product Flow Diagram
❌ Product Breakdown Structure, die die Produkte in Reihenfolge und Abhängigkeit darstellt
❌ Risk Register, das Abhängigkeiten zwischen Produkten führt
Die Product Breakdown Structure gliedert Produkte hierarchisch; das Product Flow Diagram zeigt die Reihenfolge und Abhängigkeiten, in der sie erstellt werden. Product Descriptions beschreiben je ein einzelnes Produkt.
☝️ Single FALLSTUDIE „Smart Meter Rollout“: Die Stadtwerke Rheinau müssen bis zum 31.12. 80.000 konventionelle Stromzähler durch Smart Meter ersetzen; die Frist ist vom Gesellschafterkreis (übergeordnete Ebene) als feste Projektgrenze vorgegeben. Executive ist Herr Dr. Amsel (Geschäftsführer), Senior User Frau Kowalski (Leiterin Netzbetrieb), Senior Supplier Herr Tan (Vertriebsdirektor des Zählerherstellers MeterTec GmbH). Project Manager ist Frau Ostermann, Team Manager Herr Riedel (Montagepartner). Stages: Initiierung, Pilot (2.000 Zähler), Rollout Süd, Rollout Nord, Abschluss. Stage-Toleranzen: Zeit ±3 Wochen, Kosten ±4 %. Qualitätskriterium: Kommunikationsfehlerquote der eingebauten Zähler unter 1 %. Frage: Herr Riedel plant den Einsatz seiner Montageteams mit einer eigenen Detailplanung je Woche. Wie heißt diese Planungsebene, und wer erstellt sie?
✅ Team Plan – erstellt vom Team Manager, wenn die Work Packages eine Detailplanung erfordern
❌ Stage Plan – erstellt vom Project Manager für jede Management Stage des Projekts
❌ Exception Plan – erstellt vom Team Manager, sobald sich die Montage einmal verzögert
❌ Project Plan – erstellt vom Project Board zu Projektbeginn für das gesamte Vorhaben
Team Plans sind optional und unterstützen die Umsetzung eines Work Packages. Der Project Manager gibt die Rahmenvorgaben, der Team Manager plant im Detail.
☝️ Single FALLSTUDIE „Smart Meter Rollout“: Die Stadtwerke Rheinau müssen bis zum 31.12. 80.000 konventionelle Stromzähler durch Smart Meter ersetzen; die Frist ist vom Gesellschafterkreis (übergeordnete Ebene) als feste Projektgrenze vorgegeben. Executive ist Herr Dr. Amsel (Geschäftsführer), Senior User Frau Kowalski (Leiterin Netzbetrieb), Senior Supplier Herr Tan (Vertriebsdirektor des Zählerherstellers MeterTec GmbH). Project Manager ist Frau Ostermann, Team Manager Herr Riedel (Montagepartner). Stages: Initiierung, Pilot (2.000 Zähler), Rollout Süd, Rollout Nord, Abschluss. Stage-Toleranzen: Zeit ±3 Wochen, Kosten ±4 %. Qualitätskriterium: Kommunikationsfehlerquote der eingebauten Zähler unter 1 %. Frage: Herr Riedel erkennt, dass sein aktuelles Work Package die vereinbarte Zeittoleranz voraussichtlich überschreiten wird. Wen informiert er?
❌ Niemand, solange die Stage-Toleranz noch eingehalten wird
✅ Frau Ostermann als Project Manager, die die Work-Package-Toleranzen vorgegeben hat
❌ Die Senior User Frau Kowalski, da sie die Nutzerinteressen vertritt
❌ Direkt das Project Board, weil Toleranzüberschreitungen immer dort gemeldet werden
Toleranzen werden ebenenweise delegiert: Das Board setzt Stage-Toleranzen für den PM, der PM setzt Work-Package-Toleranzen für den Team Manager. Überschreitungen werden jeweils an die delegierende Ebene gemeldet.
Zuordnung Berichte Smart Meter [P] [Practices] 1 Unterseite →
matching FALLSTUDIE „Smart Meter Rollout“: Die Stadtwerke Rheinau müssen bis zum 31.12. 80.000 konventionelle Stromzähler durch Smart Meter ersetzen; die Frist ist vom Gesellschafterkreis (übergeordnete Ebene) als feste Projektgrenze vorgegeben. Executive ist Herr Dr. Amsel (Geschäftsführer), Senior User Frau Kowalski (Leiterin Netzbetrieb), Senior Supplier Herr Tan (Vertriebsdirektor des Zählerherstellers MeterTec GmbH). Project Manager ist Frau Ostermann, Team Manager Herr Riedel (Montagepartner). Stages: Initiierung, Pilot (2.000 Zähler), Rollout Süd, Rollout Nord, Abschluss. Stage-Toleranzen: Zeit ±3 Wochen, Kosten ±4 %. Qualitätskriterium: Kommunikationsfehlerquote der eingebauten Zähler unter 1 %. Frage: Ordnen Sie jedem Bericht seinen Zweck zu.
Die beiden Distraktoren beschreiben Lessons Report bzw. Issue Report.
Fallstudie PayLite [P] [Practices] 4 Unterseite →
☝️ Single FALLSTUDIE „PayLite“: Die FinBridge GmbH (Fintech, 60 Mitarbeitende) entwickelt die Zahlungs-App PayLite. Executive ist Frau Nguyen (CEO), Senior User Herr Baumann (Head of Customer Success), Senior Supplier Frau Dr. Lehmann (CTO). Project Manager ist Herr Weber. Die Entwicklung erfolgt durch zwei Scrum-Teams in Zwei-Wochen-Sprints; Product Owner ist Herr Jung. Das Projekt hat vier Stages von je etwa drei Monaten (Initiierung, MVP, Beta & Regulierung, Marktstart). Zeit und Kosten sind eng begrenzt, der Umfang ist priorisiert (Must/Should/Could). Für den Marktstart wird eine Erlaubnis der Aufsichtsbehörde benötigt. Frage: Herr Weber möchte Zeit und Kosten fix halten und den Umfang flexibel steuern. Wie bildet er das in PRINCE2 ab?
✅ Über Umfangstoleranzen: Must-Anforderungen bleiben fix, Should und Could dürfen innerhalb der Toleranz entfallen
❌ Über ein größeres Change-Budget, mit dem Umfangsreduzierungen finanziell ausgeglichen werden sollen
❌ Gar nicht: PRINCE2 verlangt, dass der Umfang exakt wie in der Baseline geliefert wird, ohne Ausnahme
❌ Über zusätzliche Stages, in denen fehlender Umfang ohne Board-Freigabe nachgeliefert werden darf
Toleranzen gibt es nicht nur für Zeit und Kosten, sondern auch für den Umfang. Eine priorisierte Anforderungsliste erlaubt es, den Umfang innerhalb definierter Grenzen zu variieren.
☝️ Single FALLSTUDIE „PayLite“: Die FinBridge GmbH (Fintech, 60 Mitarbeitende) entwickelt die Zahlungs-App PayLite. Executive ist Frau Nguyen (CEO), Senior User Herr Baumann (Head of Customer Success), Senior Supplier Frau Dr. Lehmann (CTO). Project Manager ist Herr Weber. Die Entwicklung erfolgt durch zwei Scrum-Teams in Zwei-Wochen-Sprints; Product Owner ist Herr Jung. Das Projekt hat vier Stages von je etwa drei Monaten (Initiierung, MVP, Beta & Regulierung, Marktstart). Zeit und Kosten sind eng begrenzt, der Umfang ist priorisiert (Must/Should/Could). Für den Marktstart wird eine Erlaubnis der Aufsichtsbehörde benötigt. Frage: Im laufenden Sprint bittet der Product Owner, eine neue Funktion aufzunehmen und dafür eine gleich große Could-Funktion zu streichen. Zeit, Kosten und Umfangstoleranz bleiben unberührt. Wer kann das entscheiden?
❌ Frau Nguyen als CEO, außerhalb der Projektorganisation und ohne Abstimmung mit dem Project Manager
❌ Nur das Project Board, da jede Änderung des Backlogs eine Änderung der Baseline darstellt
❌ Das Scrum-Team allein, da PRINCE2 für agile Vorhaben keine Änderungssteuerung vorsieht
✅ Der Project Manager bzw. die delegierte Change Authority – innerhalb der delegierten Toleranzen, ohne das Board
Manage by Exception: Innerhalb der delegierten Toleranzen und Befugnisse (Change Authority, Change-Budget) entscheidet die Projektebene selbst; das Board wird nur bei drohender Überschreitung eingebunden.
☝️ Single FALLSTUDIE „PayLite“: Die FinBridge GmbH (Fintech, 60 Mitarbeitende) entwickelt die Zahlungs-App PayLite. Executive ist Frau Nguyen (CEO), Senior User Herr Baumann (Head of Customer Success), Senior Supplier Frau Dr. Lehmann (CTO). Project Manager ist Herr Weber. Die Entwicklung erfolgt durch zwei Scrum-Teams in Zwei-Wochen-Sprints; Product Owner ist Herr Jung. Das Projekt hat vier Stages von je etwa drei Monaten (Initiierung, MVP, Beta & Regulierung, Marktstart). Zeit und Kosten sind eng begrenzt, der Umfang ist priorisiert (Must/Should/Could). Für den Marktstart wird eine Erlaubnis der Aufsichtsbehörde benötigt. Frage: Die Scrum-Teams nutzen eine Definition of Done. Wie lässt sich diese in PRINCE2 verorten?
❌ Gar nicht, da agile Teams ihre Qualitätskriterien erst während der Sprints festlegen
❌ Als Bestandteil des Highlight Reports, der die Fertigstellung meldet
✅ Als Qualitätskriterien in den Product Descriptions und im Quality Management Approach
❌ Als Risikotoleranz im Risk Management Approach, der Schwellenwerte für die Eskalation festlegt
Die Definition of Done entspricht inhaltlich den Qualitätskriterien und Abnahmekriterien, die PRINCE2 in Product Descriptions festhält; der Quality Management Approach regelt, wie sie geprüft werden.
☝️ Single FALLSTUDIE „PayLite“: Die FinBridge GmbH (Fintech, 60 Mitarbeitende) entwickelt die Zahlungs-App PayLite. Executive ist Frau Nguyen (CEO), Senior User Herr Baumann (Head of Customer Success), Senior Supplier Frau Dr. Lehmann (CTO). Project Manager ist Herr Weber. Die Entwicklung erfolgt durch zwei Scrum-Teams in Zwei-Wochen-Sprints; Product Owner ist Herr Jung. Das Projekt hat vier Stages von je etwa drei Monaten (Initiierung, MVP, Beta & Regulierung, Marktstart). Zeit und Kosten sind eng begrenzt, der Umfang ist priorisiert (Must/Should/Could). Für den Marktstart wird eine Erlaubnis der Aufsichtsbehörde benötigt. Frage: Im Risk Register steht: Die Aufsichtserlaubnis kommt nicht rechtzeitig zum Marktstart. Das Board beschließt, einen Alternativplan zu erarbeiten (Start unter der Lizenz eines Partnerinstituts), der nur bei Eintritt des Risikos aktiviert wird. Welche Risikoreaktion ist das?
❌ Übertragen (Transfer): das Risiko geht an Dritte
✅ Notfallplan vorbereiten (Contingent Plan)
❌ Vermeiden (Avoid): die Bedrohung wird beseitigt
❌ Akzeptieren (Accept): das Risiko wird hingenommen
Ein Contingent Plan wird vorab vorbereitet und nur aktiviert, wenn das Risiko (oder ein definierter Auslöser) eintritt. Es handelt sich um eine Reaktion auf Bedrohungen, die die Auswirkung begrenzen soll.
Fallstudie GreenLine [P] [Practices] 5 Unterseite →
☝️ Single FALLSTUDIE „GreenLine“: Die PackWerk AG (Verpackungshersteller, 900 Mitarbeitende) ersetzt am Hauptstandort eine Produktionslinie durch eine klimaneutrale Anlage (Investition 4,2 Mio. €, davon 30 % gefördert). Executive ist Herr Dr. Sommer (Werkleiter), Senior User Frau Idris (Leiterin Produktionsplanung), Senior Supplier Herr Rahn (Anlagenbauer ThermoTec). Project Manager ist Frau Vogt. Stages: Initiierung, Planung & Bestellung, Installation, Inbetriebnahme & Hochlauf. Ziele: CO₂-Ausstoß der Linie mindestens 35 % geringer, Energiekosten mindestens 22 % geringer, Produktionsausfall höchstens drei Tage. Der Betriebsrat begleitet das Projekt. Frage: Am Ende von Stage 2 zeigt der aktualisierte Business Case: Die Energiekosten sinken voraussichtlich nur um 18 %; die Benefit-Toleranz verlangt mindestens 22 %. Wie muss Frau Vogt reagieren?
❌ Die Benefit-Toleranz selbst auf 18 % senken, damit die Stage im Rahmen bleibt
✅ Die drohende Überschreitung dem Project Board unverzüglich melden; das Board entscheidet
❌ Nichts unternehmen, da Toleranzen nur für Zeit und Kosten gelten, nicht für Nutzen
❌ Die Prognose erst im Highlight Report der nächsten Stage erwähnen und abwarten
Toleranzen gelten für alle Performance-Ziele, auch für Nutzen. Eine drohende Überschreitung muss sofort an die delegierende Ebene (Project Board) gemeldet werden; das Board entscheidet über Korrektur, Anpassung oder Abbruch.
☝️ Single FALLSTUDIE „GreenLine“: Die PackWerk AG (Verpackungshersteller, 900 Mitarbeitende) ersetzt am Hauptstandort eine Produktionslinie durch eine klimaneutrale Anlage (Investition 4,2 Mio. €, davon 30 % gefördert). Executive ist Herr Dr. Sommer (Werkleiter), Senior User Frau Idris (Leiterin Produktionsplanung), Senior Supplier Herr Rahn (Anlagenbauer ThermoTec). Project Manager ist Frau Vogt. Stages: Initiierung, Planung & Bestellung, Installation, Inbetriebnahme & Hochlauf. Ziele: CO₂-Ausstoß der Linie mindestens 35 % geringer, Energiekosten mindestens 22 % geringer, Produktionsausfall höchstens drei Tage. Der Betriebsrat begleitet das Projekt. Frage: Für das Risiko „Lieferverzug der Wärmepumpen“ benennt Frau Vogt Herrn Rahn als Risk Owner. Was bedeutet das?
✅ Herr Rahn steuert und überwacht dieses einzelne Risiko; das Risk Register insgesamt bleibt beim Project Manager
❌ Herr Rahn trägt die Verantwortung für das gesamte Risk Register und alle Risiken des Projekts
❌ Herr Rahn entscheidet, ob das Risiko dem Board gemeldet wird, ohne den Project Manager zu informieren
❌ Herr Rahn muss alle Risikomaßnahmen persönlich durchführen; Delegation ist ausgeschlossen
Der Risk Owner steuert ein bestimmtes Risiko; einzelne Maßnahmen können an Risk Actionees delegiert werden. Der Project Manager verantwortet das Risikomanagement des Projekts insgesamt.
☝️ Single FALLSTUDIE „GreenLine“: Die PackWerk AG (Verpackungshersteller, 900 Mitarbeitende) ersetzt am Hauptstandort eine Produktionslinie durch eine klimaneutrale Anlage (Investition 4,2 Mio. €, davon 30 % gefördert). Executive ist Herr Dr. Sommer (Werkleiter), Senior User Frau Idris (Leiterin Produktionsplanung), Senior Supplier Herr Rahn (Anlagenbauer ThermoTec). Project Manager ist Frau Vogt. Stages: Initiierung, Planung & Bestellung, Installation, Inbetriebnahme & Hochlauf. Ziele: CO₂-Ausstoß der Linie mindestens 35 % geringer, Energiekosten mindestens 22 % geringer, Produktionsausfall höchstens drei Tage. Der Betriebsrat begleitet das Projekt. Frage: Am Projektende soll die Anlage einen 72-Stunden-Dauertest ohne Störung bestehen. Wo werden solche Abnahmekriterien für das Gesamtergebnis festgelegt?
❌ Im Lessons Report, der erst nach Projektende für künftige Projekte erstellt wird
❌ Im Communication Management Approach, der die Stakeholder-Kommunikation regelt
❌ Im Highlight Report der letzten Stage des Projekts, der dem Board vorgelegt wird
✅ In der Project Product Description des Gesamtergebnisses (Abnahmekriterien und -methode)
Die Project Product Description definiert, was das Projekt insgesamt liefern muss und nach welchen Kriterien es abgenommen wird. Sie wird früh erstellt und vom Board genehmigt.
☝️ Single FALLSTUDIE „GreenLine“: Die PackWerk AG (Verpackungshersteller, 900 Mitarbeitende) ersetzt am Hauptstandort eine Produktionslinie durch eine klimaneutrale Anlage (Investition 4,2 Mio. €, davon 30 % gefördert). Executive ist Herr Dr. Sommer (Werkleiter), Senior User Frau Idris (Leiterin Produktionsplanung), Senior Supplier Herr Rahn (Anlagenbauer ThermoTec). Project Manager ist Frau Vogt. Stages: Initiierung, Planung & Bestellung, Installation, Inbetriebnahme & Hochlauf. Ziele: CO₂-Ausstoß der Linie mindestens 35 % geringer, Energiekosten mindestens 22 % geringer, Produktionsausfall höchstens drei Tage. Der Betriebsrat begleitet das Projekt. Frage: Frau Vogt vergibt das Work Package „Installation Linie 1“ an ThermoTec. Was gehört NICHT in ein Work Package?
❌ Anforderungen an Berichterstattung und Rückmeldung
❌ Die Toleranzen für das Work Package
❌ Die Product Descriptions der zu erstellenden Produkte
✅ Der vollständige Business Case des Projekts
Ein Work Package enthält, was der Team Manager zur Ausführung braucht: Produkte und Product Descriptions, Termine, Toleranzen, Einschränkungen, Schnittstellen, Berichts- und Prüfanforderungen. Der Business Case gehört nicht dazu.
☝️ Single FALLSTUDIE „GreenLine“: Die PackWerk AG (Verpackungshersteller, 900 Mitarbeitende) ersetzt am Hauptstandort eine Produktionslinie durch eine klimaneutrale Anlage (Investition 4,2 Mio. €, davon 30 % gefördert). Executive ist Herr Dr. Sommer (Werkleiter), Senior User Frau Idris (Leiterin Produktionsplanung), Senior Supplier Herr Rahn (Anlagenbauer ThermoTec). Project Manager ist Frau Vogt. Stages: Initiierung, Planung & Bestellung, Installation, Inbetriebnahme & Hochlauf. Ziele: CO₂-Ausstoß der Linie mindestens 35 % geringer, Energiekosten mindestens 22 % geringer, Produktionsausfall höchstens drei Tage. Der Betriebsrat begleitet das Projekt. Frage: Frau Vogt notiert das Risiko „Netzanschlussgenehmigung könnte sich verzögern“. Am nächsten Tag teilt der Netzbetreiber mit, dass die Genehmigung sechs Wochen später kommt. Wie ändert sich die Behandlung?
✅ Aus dem Risiko ist ein Issue geworden: erfassen, bewerten, entscheiden; das Risiko wird geschlossen
❌ Es bleibt ein Risiko im Risk Register, weil Risiken erst mit dem Projektende zu Issues werden können
❌ Es wird zu einer Off-Specification und mit einem formalen Zugeständnis der Change Authority geregelt
❌ Es wird nur im Daily Log vermerkt, bis die Genehmigung tatsächlich eintrifft und alles klar ist
Ein eingetretenes Risiko ist kein Risiko mehr, sondern ein Issue. Es wird nach dem Issue-Verfahren behandelt (erfassen, bewerten, Optionen, entscheiden, umsetzen).
Fallstudie Bürgerportal [P] [Practices] 6 Unterseite →
☝️ Single FALLSTUDIE „Bürgerportal“: Der Landkreis Waldenau führt ein digitales Bürgerportal für 35 Verwaltungsleistungen ein und bindet 12 Gemeinden an. Executive ist Landrätin Frau Dr. Wiesner, Senior User Herr Hartmann (Amtsleiter Bürgerservice), Senior Supplier Herr Petrov (Kommunales Rechenzentrum). Project Manager ist Frau Ebert. Die Datenschutzbeauftragte Frau Schulz prüft im Auftrag des Boards unabhängig die Datenschutzkonformität. Vier Stages; Stage-Toleranzen: Zeit ±4 Wochen, Kosten ±5 %, Umfang mindestens 30 von 35 Leistungen. Frage: Frau Schulz möchte ihre Prüfergebnisse zunächst mit Frau Ebert abstimmen, bevor sie an das Board berichtet. Welcher Grundsatz gilt für Project Assurance?
❌ Assurance ist dem Project Manager unterstellt und liefert ihm Prüfergebnisse zu
❌ Assurance darf nur nach Freigabe durch den Project Manager an das Board berichten
✅ Assurance ist unabhängig vom Project Manager und handelt im Auftrag des Boards
❌ Assurance ersetzt die Qualitätsprüfung der Team Manager vollständig
Project Assurance ist die unabhängige Überwachung im Auftrag des Project Boards. Unabhängigkeit vom Project Manager ist ihr Kern.
☝️ Single FALLSTUDIE „Bürgerportal“: Der Landkreis Waldenau führt ein digitales Bürgerportal für 35 Verwaltungsleistungen ein und bindet 12 Gemeinden an. Executive ist Landrätin Frau Dr. Wiesner, Senior User Herr Hartmann (Amtsleiter Bürgerservice), Senior Supplier Herr Petrov (Kommunales Rechenzentrum). Project Manager ist Frau Ebert. Die Datenschutzbeauftragte Frau Schulz prüft im Auftrag des Boards unabhängig die Datenschutzkonformität. Vier Stages; Stage-Toleranzen: Zeit ±4 Wochen, Kosten ±5 %, Umfang mindestens 30 von 35 Leistungen. Frage: Die Gemeinde Ostheim verlangt eine Sonderanpassung des Portals. Frau Ebert soll der Change Authority eine Entscheidungsgrundlage mit Beschreibung, Auswirkungsanalyse, Optionen und Empfehlung liefern. Welches Management-Produkt ist das?
❌ Daily Log
✅ Issue Report
❌ Lessons Report
❌ Exception Report
Der Issue Report fasst ein einzelnes Issue mit Bewertung, Optionen und Empfehlung zusammen. Der Exception Report dient der Eskalation einer prognostizierten Toleranzüberschreitung an das Board.
☝️ Single FALLSTUDIE „Bürgerportal“: Der Landkreis Waldenau führt ein digitales Bürgerportal für 35 Verwaltungsleistungen ein und bindet 12 Gemeinden an. Executive ist Landrätin Frau Dr. Wiesner, Senior User Herr Hartmann (Amtsleiter Bürgerservice), Senior Supplier Herr Petrov (Kommunales Rechenzentrum). Project Manager ist Frau Ebert. Die Datenschutzbeauftragte Frau Schulz prüft im Auftrag des Boards unabhängig die Datenschutzkonformität. Vier Stages; Stage-Toleranzen: Zeit ±4 Wochen, Kosten ±5 %, Umfang mindestens 30 von 35 Leistungen. Frage: Ein Team Manager meldet seit drei Wochen „90 % fertig“ für das Formularmodul. Wie sollte Frau Ebert den Fortschritt belastbar bewerten?
❌ Nach der Anzahl der Abstimmungsmeetings, die das Team zum Modul bereits abgehalten hat
✅ Anhand des Produktstatus (geliefert, geprüft, freigegeben) im Vergleich zum Plan
❌ Ausschließlich nach der subjektiven Einschätzung des zuständigen Team Managers
❌ Nach dem Aufwand, der bisher auf das Formularmodul gebucht wurde, im Vergleich zum Budget
Focus on Products: Fortschritt wird an fertiggestellten und abgenommenen Produkten gemessen. Geschätzte Prozentangaben und Aufwand sagen wenig über den tatsächlichen Stand.
☝️ Single FALLSTUDIE „Bürgerportal“: Der Landkreis Waldenau führt ein digitales Bürgerportal für 35 Verwaltungsleistungen ein und bindet 12 Gemeinden an. Executive ist Landrätin Frau Dr. Wiesner, Senior User Herr Hartmann (Amtsleiter Bürgerservice), Senior Supplier Herr Petrov (Kommunales Rechenzentrum). Project Manager ist Frau Ebert. Die Datenschutzbeauftragte Frau Schulz prüft im Auftrag des Boards unabhängig die Datenschutzkonformität. Vier Stages; Stage-Toleranzen: Zeit ±4 Wochen, Kosten ±5 %, Umfang mindestens 30 von 35 Leistungen. Frage: Frau Ebert bewertet das Risiko „Klage eines unterlegenen Bieters gegen die Vergabe“: Wahrscheinlichkeit gering, Auswirkung sehr hoch, über der vom Board gesetzten Risikotoleranz. Was muss sie tun?
✅ Das Risiko an das Project Board eskalieren, da es ihre Toleranz übersteigt
❌ Es selbst akzeptieren und dokumentieren, weil die Wahrscheinlichkeit gering ist
❌ Es an den Team Manager delegieren, der die Maßnahmen steuern soll
❌ Es im Lessons Log festhalten und ansonsten zunächst nichts unternehmen
Übersteigt ein Risiko die Risikotoleranz des Project Managers, muss er es an das Project Board eskalieren (Escalate issues and risks in Controlling a Stage).
☝️ Single FALLSTUDIE „Bürgerportal“: Der Landkreis Waldenau führt ein digitales Bürgerportal für 35 Verwaltungsleistungen ein und bindet 12 Gemeinden an. Executive ist Landrätin Frau Dr. Wiesner, Senior User Herr Hartmann (Amtsleiter Bürgerservice), Senior Supplier Herr Petrov (Kommunales Rechenzentrum). Project Manager ist Frau Ebert. Die Datenschutzbeauftragte Frau Schulz prüft im Auftrag des Boards unabhängig die Datenschutzkonformität. Vier Stages; Stage-Toleranzen: Zeit ±4 Wochen, Kosten ±5 %, Umfang mindestens 30 von 35 Leistungen. Frage: Welche Angabe gehört NICHT in den Communication Management Approach?
❌ Verantwortlichkeiten für Kommunikationsaufgaben
❌ Kommunikationswege, Formate und Häufigkeit
❌ Eine Analyse der Stakeholder und ihrer Informationsbedürfnisse
✅ Qualitätskriterien und Abnahmemethoden der einzelnen Produkte
Qualitätskriterien stehen in den Product Descriptions, das Vorgehen zur Qualitätssicherung im Quality Management Approach. Der Communication Management Approach regelt Stakeholder-Analyse, Wege, Formate, Frequenz und Verantwortlichkeiten.
✌️ Multi FALLSTUDIE „Bürgerportal“: Der Landkreis Waldenau führt ein digitales Bürgerportal für 35 Verwaltungsleistungen ein und bindet 12 Gemeinden an. Executive ist Landrätin Frau Dr. Wiesner, Senior User Herr Hartmann (Amtsleiter Bürgerservice), Senior Supplier Herr Petrov (Kommunales Rechenzentrum). Project Manager ist Frau Ebert. Die Datenschutzbeauftragte Frau Schulz prüft im Auftrag des Boards unabhängig die Datenschutzkonformität. Vier Stages; Stage-Toleranzen: Zeit ±4 Wochen, Kosten ±5 %, Umfang mindestens 30 von 35 Leistungen. Frage: Welche Aussagen zum Project Board in diesem Projekt sind zutreffend? (Mehrere richtig)
❌ Frau Schulz gehört als Assurance-Verantwortliche zum Board und stimmt über die Fortführung ab
✅ Das Board delegiert das Tagesgeschäft an den Project Manager im Rahmen der Toleranzen
✅ Das Board entscheidet an den Stage-Grenzen über die Fortführung des Projekts
❌ Herr Petrov führt als Senior Supplier das Tagesgeschäft des Projekts
✅ Das Board besteht mindestens aus Executive, Senior User und Senior Supplier
Das Project Board trägt die Gesamtverantwortung, entscheidet an den Kontrollpunkten und delegiert die laufende Führung an den Project Manager. Assurance handelt im Auftrag des Boards, ist aber kein Board-Mitglied.
Zuordnung Management-Ansätze Bürgerportal [P] [Practices] 1 Unterseite →
matching FALLSTUDIE „Bürgerportal“: Der Landkreis Waldenau führt ein digitales Bürgerportal für 35 Verwaltungsleistungen ein und bindet 12 Gemeinden an. Executive ist Landrätin Frau Dr. Wiesner, Senior User Herr Hartmann (Amtsleiter Bürgerservice), Senior Supplier Herr Petrov (Kommunales Rechenzentrum). Project Manager ist Frau Ebert. Die Datenschutzbeauftragte Frau Schulz prüft im Auftrag des Boards unabhängig die Datenschutzkonformität. Vier Stages; Stage-Toleranzen: Zeit ±4 Wochen, Kosten ±5 %, Umfang mindestens 30 von 35 Leistungen. Frage: Ordnen Sie jedem Management-Ansatz seinen Inhalt zu.
Die beiden Distraktoren beschreiben den Quality Management Approach bzw. die Project Product Description.
Fallstudie CargoVolt [P] [Practices] 5 Unterseite →
☝️ Single FALLSTUDIE „CargoVolt“: Das Start-up CargoVolt (25 Mitarbeitende) bringt ein neues E-Lastenrad zur Marktreife und will es auf einer Fachmesse im September (fester Termin) präsentieren. Budget 350.000 €, Laufzeit neun Monate. Executive ist die Gründerin Frau Seidel, Senior User Herr Aydin (Vertriebsleiter), Senior Supplier Herr Kraus (Fahrradwerk Kraus & Söhne, Fertigungspartner). Project Manager ist Frau Meier (Teilzeit). Es gibt kein Project-Support-Team; das Projekt hat nur zwei Stages (Initiierung, Entwicklung & Markteinführung). Frage: Frau Meier möchte wegen des kleinen Teams Rollen kombinieren. Welche Kombination ist NICHT sinnvoll?
❌ Frau Meier als Project Manager und zugleich als Team Manager für kleine Work Packages
❌ Frau Meier übernimmt zusätzlich zur PM-Rolle die Aufgaben von Project Support
❌ Herr Aydin nimmt die Senior-User-Rolle wahr und delegiert die User Assurance an einen Kollegen aus dem Vertrieb
✅ Frau Meier als Project Manager und zugleich als Project Assurance für dasselbe Projekt
Rollen können kombiniert werden, solange keine Interessenkonflikte entstehen. Assurance muss unabhängig vom Project Manager sein; die anderen genannten Kombinationen sind üblich.
☝️ Single FALLSTUDIE „CargoVolt“: Das Start-up CargoVolt (25 Mitarbeitende) bringt ein neues E-Lastenrad zur Marktreife und will es auf einer Fachmesse im September (fester Termin) präsentieren. Budget 350.000 €, Laufzeit neun Monate. Executive ist die Gründerin Frau Seidel, Senior User Herr Aydin (Vertriebsleiter), Senior Supplier Herr Kraus (Fahrradwerk Kraus & Söhne, Fertigungspartner). Project Manager ist Frau Meier (Teilzeit). Es gibt kein Project-Support-Team; das Projekt hat nur zwei Stages (Initiierung, Entwicklung & Markteinführung). Frage: Im Reichweitentest schafft der Prototyp 82 km statt der geforderten 90 km (untere Toleranz 85 km). Herr Aydin erklärt, der Markt werde 82 km akzeptieren. Wie heißt die formale Genehmigung, ein Produkt trotz Abweichung von der Spezifikation zu akzeptieren?
❌ Highlight Report (Statusbericht)
❌ Baseline-Freigabe (Baselining)
✅ Concession (Zugeständnis)
❌ Exception Plan (Ausnahmeplan)
Eine Concession ist die formale Akzeptanz eines Produkts, das die Spezifikation nicht erfüllt (Off-Specification), durch die dafür zuständige Stelle.
☝️ Single FALLSTUDIE „CargoVolt“: Das Start-up CargoVolt (25 Mitarbeitende) bringt ein neues E-Lastenrad zur Marktreife und will es auf einer Fachmesse im September (fester Termin) präsentieren. Budget 350.000 €, Laufzeit neun Monate. Executive ist die Gründerin Frau Seidel, Senior User Herr Aydin (Vertriebsleiter), Senior Supplier Herr Kraus (Fahrradwerk Kraus & Söhne, Fertigungspartner). Project Manager ist Frau Meier (Teilzeit). Es gibt kein Project-Support-Team; das Projekt hat nur zwei Stages (Initiierung, Entwicklung & Markteinführung). Frage: Ein Fachjournalist könnte auf der Messe über das Rad berichten. Frau Meier schlägt vor, zusätzliches Budget in einen größeren Messestand zu investieren, um die Wahrscheinlichkeit einer Berichterstattung zu erhöhen. Welche Reaktion auf die Chance ist das?
❌ Ablehnen (Reject)
✅ Verstärken (Enhance)
❌ Ausschöpfen (Exploit) – die Chance wird sicher eintreten
❌ Vermeiden (Avoid)
Enhance erhöht Wahrscheinlichkeit oder Wirkung einer Chance. Exploit stellt sicher, dass sie eintritt. Reject bedeutet, die Chance bewusst nicht zu verfolgen.
✌️ Multi FALLSTUDIE „CargoVolt“: Das Start-up CargoVolt (25 Mitarbeitende) bringt ein neues E-Lastenrad zur Marktreife und will es auf einer Fachmesse im September (fester Termin) präsentieren. Budget 350.000 €, Laufzeit neun Monate. Executive ist die Gründerin Frau Seidel, Senior User Herr Aydin (Vertriebsleiter), Senior Supplier Herr Kraus (Fahrradwerk Kraus & Söhne, Fertigungspartner). Project Manager ist Frau Meier (Teilzeit). Es gibt kein Project-Support-Team; das Projekt hat nur zwei Stages (Initiierung, Entwicklung & Markteinführung). Frage: Der Messeveranstalter zieht den Termin um drei Wochen vor. Frau Meier meldet per Exception Report, dass die Zeittoleranz nicht zu halten ist. Welche Reaktionen sind für das Project Board zulässig? (Mehrere richtig)
❌ Die Abweichung ignorieren, solange die Kosten eingehalten werden
✅ Frau Meier beauftragen, einen Exception Plan zu erstellen
❌ Den Exception Report an Frau Meier zurückgeben, damit sie die Abweichung selbst genehmigt
✅ Das Projekt vorzeitig schließen
✅ Nach Rücksprache mit der übergeordneten Ebene neue Toleranzen setzen
Nach einem Exception Report entscheidet das Board: Exception Plan anfordern, Projekt beenden oder Toleranzen und Ziele neu setzen (ggf. nach Eskalation). Die Verantwortung liegt beim Board, nicht beim Project Manager.
☝️ Single FALLSTUDIE „CargoVolt“: Das Start-up CargoVolt (25 Mitarbeitende) bringt ein neues E-Lastenrad zur Marktreife und will es auf einer Fachmesse im September (fester Termin) präsentieren. Budget 350.000 €, Laufzeit neun Monate. Executive ist die Gründerin Frau Seidel, Senior User Herr Aydin (Vertriebsleiter), Senior Supplier Herr Kraus (Fahrradwerk Kraus & Söhne, Fertigungspartner). Project Manager ist Frau Meier (Teilzeit). Es gibt kein Project-Support-Team; das Projekt hat nur zwei Stages (Initiierung, Entwicklung & Markteinführung). Frage: Wie sollte das Board bei dem festen Messetermin die Toleranzen setzen?
✅ Zeittoleranz sehr gering oder null; dafür Flexibilität bei Umfang und ggf. Kosten einräumen
❌ Keine Toleranzen setzen, da der Messetermin fix ist und alles darauf abgestimmt wird
❌ Alle Toleranzen auf null setzen, damit im gesamten Projekt keine Abweichung entstehen kann
❌ Die Zeittoleranz hoch setzen und notfalls den Messetermin gegenüber dem Veranstalter verschieben
Toleranzen bilden die Prioritäten des Projekts ab. Ist der Termin fix, wird Flexibilität bei anderen Zielen (Umfang, Kosten) eingeräumt, statt überall Nulltoleranz zu setzen.
Fallstudie RZ-Umzug [P] [Practices] 5 Unterseite →
☝️ Single FALLSTUDIE „RZ-Umzug“: Die Nordstern Versicherung AG verlagert ihr Rechenzentrum zu einem externen Provider (Budget 2,4 Mio. €). Der Mietvertrag des alten Rechenzentrums endet am 31.03.; die Frist wurde von der Konzernleitung als Projekttoleranz vorgegeben. Executive ist Frau Dr. Yildiz (CIO), Senior User Herr Bergmann (Leiter Schadenbearbeitung), Senior Supplier Herr Novak (Account Manager des Providers ColoNet). Project Manager ist Herr Schäfer, Project Support Frau Peters. Stages: Initiierung, Planung & Vorbereitung, Migration Welle 1 (unkritische Systeme), Migration Welle 2 (kritische Systeme), Abschluss. Frage: Das Board möchte für Welle 2 eine engere Zeittoleranz setzen als die von der Konzernleitung vorgegebene Projekttoleranz. Ist das zulässig?
❌ Ja, und sie dürfen auch weiter sein als die Projekttoleranz, wenn das Board zustimmt
✅ Ja: Stage-Toleranzen liegen innerhalb der Projekttoleranz und dürfen enger sein, um einen Puffer zu erhalten
❌ Nein, nur die Konzernleitung darf Toleranzen für einzelne Stages des Projekts festlegen
❌ Nein, Stage-Toleranzen müssen exakt der vorgegebenen Projekttoleranz entsprechen und dürfen nicht abweichen
Toleranzen werden ebenenweise delegiert und verschachteln sich: Stage-Toleranzen liegen innerhalb der Projekttoleranz. Engere Werte schaffen Reserven für die übergeordnete Ebene.
☝️ Single FALLSTUDIE „RZ-Umzug“: Die Nordstern Versicherung AG verlagert ihr Rechenzentrum zu einem externen Provider (Budget 2,4 Mio. €). Der Mietvertrag des alten Rechenzentrums endet am 31.03.; die Frist wurde von der Konzernleitung als Projekttoleranz vorgegeben. Executive ist Frau Dr. Yildiz (CIO), Senior User Herr Bergmann (Leiter Schadenbearbeitung), Senior Supplier Herr Novak (Account Manager des Providers ColoNet). Project Manager ist Herr Schäfer, Project Support Frau Peters. Stages: Initiierung, Planung & Vorbereitung, Migration Welle 1 (unkritische Systeme), Migration Welle 2 (kritische Systeme), Abschluss. Frage: Welche Aufgaben gehören typischerweise zu Project Support (Frau Peters)?
❌ Eigenständige Entscheidung über Toleranzüberschreitungen und Exception Plans des Projekts
✅ Administrative Unterstützung, z. B. Registerpflege, Berichte, Terminverwaltung und Konfigurationsmanagement
❌ Unabhängige Prüfung im Auftrag des Boards, ob das Projekt weiter gerechtfertigt ist
❌ Freigabe des aktualisierten Business Case und der Fortführung für die nächste Management Stage
Project Support entlastet den Project Manager administrativ. Entscheidungen treffen Board und PM, unabhängige Prüfungen sind Sache der Assurance.
☝️ Single FALLSTUDIE „RZ-Umzug“: Die Nordstern Versicherung AG verlagert ihr Rechenzentrum zu einem externen Provider (Budget 2,4 Mio. €). Der Mietvertrag des alten Rechenzentrums endet am 31.03.; die Frist wurde von der Konzernleitung als Projekttoleranz vorgegeben. Executive ist Frau Dr. Yildiz (CIO), Senior User Herr Bergmann (Leiter Schadenbearbeitung), Senior Supplier Herr Novak (Account Manager des Providers ColoNet). Project Manager ist Herr Schäfer, Project Support Frau Peters. Stages: Initiierung, Planung & Vorbereitung, Migration Welle 1 (unkritische Systeme), Migration Welle 2 (kritische Systeme), Abschluss. Frage: Frau Peters hat das Issue „Anwendung X benötigt zusätzliche Netzwerkfreigaben“ im Issue Register erfasst. Welcher Schritt des Issue-Verfahrens folgt als Nächstes?
✅ Bewerten (Assess): Auswirkungen und Priorität analysieren
❌ Umsetzen (Implement): die Option wird durchgeführt
❌ Entscheiden (Decide): die zuständige Stelle wählt
❌ Erneut erfassen (Capture), nun im Lessons Log
Das Issue-Verfahren lautet: erfassen (Capture), bewerten (Assess), Optionen vorschlagen (Propose), entscheiden (Decide), umsetzen (Implement).
☝️ Single FALLSTUDIE „RZ-Umzug“: Die Nordstern Versicherung AG verlagert ihr Rechenzentrum zu einem externen Provider (Budget 2,4 Mio. €). Der Mietvertrag des alten Rechenzentrums endet am 31.03.; die Frist wurde von der Konzernleitung als Projekttoleranz vorgegeben. Executive ist Frau Dr. Yildiz (CIO), Senior User Herr Bergmann (Leiter Schadenbearbeitung), Senior Supplier Herr Novak (Account Manager des Providers ColoNet). Project Manager ist Herr Schäfer, Project Support Frau Peters. Stages: Initiierung, Planung & Vorbereitung, Migration Welle 1 (unkritische Systeme), Migration Welle 2 (kritische Systeme), Abschluss. Frage: Für die Abnahmetests möchte Herr Schäfer, dass der Provider-Techniker, der die Systeme migriert hat, auch die Abnahmeprüfung durchführt. Was sieht PRINCE2 für Qualitätsprüfungen vor?
❌ Prüfungen sind Sache des Project Boards und werden nie delegiert
❌ Der Ersteller ist am besten geeignet zu prüfen, da er das Produkt kennt
✅ Ersteller und Prüfer sollten verschiedene Personen sein (Unabhängigkeit)
❌ Bei Migrationen sind Qualitätsprüfungen nicht vorgesehen
Ein Grundprinzip der Qualitätsprüfung ist die Unabhängigkeit: Wer ein Produkt erstellt hat, sollte es nicht selbst abnehmen.
☝️ Single FALLSTUDIE „RZ-Umzug“: Die Nordstern Versicherung AG verlagert ihr Rechenzentrum zu einem externen Provider (Budget 2,4 Mio. €). Der Mietvertrag des alten Rechenzentrums endet am 31.03.; die Frist wurde von der Konzernleitung als Projekttoleranz vorgegeben. Executive ist Frau Dr. Yildiz (CIO), Senior User Herr Bergmann (Leiter Schadenbearbeitung), Senior Supplier Herr Novak (Account Manager des Providers ColoNet). Project Manager ist Herr Schäfer, Project Support Frau Peters. Stages: Initiierung, Planung & Vorbereitung, Migration Welle 1 (unkritische Systeme), Migration Welle 2 (kritische Systeme), Abschluss. Frage: Nach den bestandenen Lasttests in Welle 1 ist das Risiko „Netzwerkkapazität reicht nicht aus“ nicht mehr relevant. Was geschieht mit dem Risiko?
❌ Es bleibt bis zum Projektende offen und wird erst im End Project Report bewertet
❌ Es wird sofort aus dem Risk Register gelöscht, damit das Register übersichtlich bleibt
❌ Es wird in ein Issue umgewandelt und im Issue Register weitergeführt und bewertet
✅ Es wird im Risk Register als geschlossen vermerkt; der Eintrag bleibt für Lessons erhalten
Erledigte Risiken werden geschlossen, nicht gelöscht: Das Risk Register dokumentiert den Verlauf und liefert Erkenntnisse für künftige Projekte.
Zuordnung Toleranzebenen RZ-Umzug [P] [Practices] 1 Unterseite →
matching FALLSTUDIE „RZ-Umzug“: Die Nordstern Versicherung AG verlagert ihr Rechenzentrum zu einem externen Provider (Budget 2,4 Mio. €). Der Mietvertrag des alten Rechenzentrums endet am 31.03.; die Frist wurde von der Konzernleitung als Projekttoleranz vorgegeben. Executive ist Frau Dr. Yildiz (CIO), Senior User Herr Bergmann (Leiter Schadenbearbeitung), Senior Supplier Herr Novak (Account Manager des Providers ColoNet). Project Manager ist Herr Schäfer, Project Support Frau Peters. Stages: Initiierung, Planung & Vorbereitung, Migration Welle 1 (unkritische Systeme), Migration Welle 2 (kritische Systeme), Abschluss. Frage: Ordnen Sie jeder Toleranzebene zu, wer sie setzt.
Toleranzen werden von oben nach unten delegiert: übergeordnete Ebene → Board → Project Manager → Team Manager.
Zuordnung Planebenen [P] [Practices] 1 Unterseite →
matching Ordnen Sie jeder Planebene ihre Beschreibung zu.
Project Plan, Stage Plan und Team Plan bilden die Planungshierarchie; der Exception Plan ersetzt bei Bedarf den betroffenen Plan. Ein Notfallplan ist kein Planlevel, sondern eine Risikoreaktion.
Zuordnung Chancenreaktionen [P] [Practices] 1 Unterseite →
matching Ordnen Sie jeder Situation die passende Reaktion auf eine Chance zu.
Exploit = Eintritt sicherstellen; Enhance = Wahrscheinlichkeit oder Wirkung erhöhen; Reject = Chance bewusst nicht verfolgen. Avoid und Transfer sind Reaktionen auf Bedrohungen.
Zuordnung Issue-Arten [P] [Practices] 1 Unterseite →
matching Ordnen Sie jedem Sachverhalt die passende Issue-Art zu.
Request for Change = Änderung einer Baseline; Off-Specification = Produkt bleibt hinter der Spezifikation zurück; Problem/Concern = alles andere, was der PM lösen oder eskalieren muss.
Zuordnung Practices und Kernfragen [P] [Practices] 1 Unterseite →
matching Jede PRINCE2-Practice beantwortet eine Kernfrage. Ordnen Sie zu.
Die beiden Distraktoren gehören zu den Practices Issues bzw. Progress, die hier nicht abgefragt werden.
Zuordnung Rollen und Verantwortung [P] [Practices] 1 Unterseite →
matching Ordnen Sie jeder Rolle ihre Kernverantwortung zu.
Change Authority und Project Assurance sind eigene Rollen und passen zu keiner der vier genannten Beschreibungen.
Zuordnung Konfigurationsmanagement [P] [Practices] 1 Unterseite →
matching Ordnen Sie jedem Begriff die richtige Definition zu.
Baseline = fixierter Referenzstand; Configuration Item = verwaltetes Produkt; Configuration Item Record = Steckbrief mit Status und Version.
Zuordnung Qualitätsbegriffe [P] [Practices] 1 Unterseite →
matching Ordnen Sie jedem Beispiel den passenden Begriff aus dem Qualitätsmanagement zu.
Das Qualitätskriterium sagt, WAS erreicht werden muss, die Toleranz, wie weit man abweichen darf, die Methode, WIE geprüft wird. Abnahmekriterien bestimmen, wann das Ergebnis vom Kunden akzeptiert wird.
Zuordnung Issue-Verfahren [P] [Practices] 1 Unterseite →
matching Ordnen Sie jedem Schritt des Issue-Verfahrens seine Tätigkeit zu.
Reihenfolge: erfassen → bewerten → Optionen vorschlagen → entscheiden → umsetzen. Wer entscheidet, hängt von den delegierten Befugnissen ab; nicht jedes Issue geht an das Board.
Zuordnung Risikobegriffe [P] [Practices] 1 Unterseite →
matching Ordnen Sie jedem Begriff aus dem Risikomanagement seine Bedeutung zu.
Die beiden Distraktoren beschreiben Impact bzw. Risk Register.
Zuordnung Planungsprodukte [P] [Practices] 1 Unterseite →
matching Ordnen Sie jedem Planungs- bzw. Steuerungsprodukt seine Beschreibung zu.
PBS, PFD und Product Descriptions bilden die produktbasierte Planung; das Work Package ist die Schnittstelle zwischen Project Manager und Team Manager.
Zuordnung Berichte zu Erkenntnissen und Leistung [P] [Practices] 1 Unterseite →
matching Ordnen Sie jedem Management-Produkt seinen Zweck zu.
Die Distraktoren beschreiben einen Request for Change bzw. einen Exception Report.
Zuordnung Änderungsentscheidungen [P] [Practices] 1 Unterseite →
matching Ordnen Sie jeder Situation zu, wer über die Änderung entscheidet.
Entscheidungen werden auf der niedrigsten Ebene getroffen, deren Befugnisse (Toleranzen, Change-Budget) nicht überschritten werden.
Merksatz: „Der Chef entscheidet, wer zahlt und wer profitiert."
  • Projektvorstand (Board): Große/teure Änderungen, die Business Case, Budget oder Projektziele betreffen – „die Kasse und das Warum".

  • Projektmanager: Kleine Änderungen innerhalb der Toleranzen, die nur Zeit/Ressourcen im Alltag betreffen – „das Tagesgeschäft".

  • Teammanager: Technische Detailänderungen innerhalb seines Arbeitspakets – „die Werkbank".


Eselsbrücke: Geld → Board, Plan → PM, Detail → Team.
Zuordnung Dokumente und Inhalte [P] [Practices] 1 Unterseite →
matching Ordnen Sie jedem Dokument seinen Inhalt bzw. Zweck zu.
Die Distraktoren beschreiben Issue Register bzw. End Stage Report.
Szenario Daily Log [P] [Practices] 1 Unterseite →
☝️ Single Der Project Manager führt ein informelles Tagebuch mit Notizen, Vereinbarungen und Beobachtungen und ein separates formales Verzeichnis für alle Issues mit Status und Priorität. Wie heißen diese beiden Produkte?
✅ Daily Log und Issue Register
❌ Lessons Log und Risk Register
❌ Highlight Report und Issue Report
❌ Quality Register und Issue Report
Das Daily Log ist das informelle Arbeitsjournal des PM. Das Issue Register erfasst alle formalen Issues mit Status, Priorität und Entscheidung.
Szenario Highlight Report [P] [Practices] 1 Unterseite →
✌️ Multi Was gehört typischerweise in einen Highlight Report? (Mehrere richtig)
✅ Ausblick auf die nächste Berichtsperiode
❌ Die detaillierten Product Descriptions aller Produkte
✅ Stand der Stage im Vergleich zu Plan und Toleranzen
❌ Der vollständige Business Case
✅ Aktuelle Issues und Risiken
Der Highlight Report informiert das Board regelmäßig über Fortschritt, Toleranzen, Issues, Risiken und Ausblick. Product Descriptions und Business Case sind eigene Management-Produkte.
Szenario Lieferantenvertrag [P] [Practices] 1 Unterseite →
☝️ Single Ein Anlagenbauer liefert im Rahmen eines Festpreisvertrags. Wie passt das zur PRINCE2-Steuerung?
✅ Der Vertrag regelt die kommerzielle Beziehung; Work Packages steuern Arbeit und Schnittstelle zum Project Manager
❌ Verträge ersetzen Work Packages; der Lieferant wird ausschließlich über den Einkauf gesteuert
❌ Externe Lieferanten dürfen keine Team-Manager-Rolle übernehmen, da sie nicht zur eigenen Organisation gehören
❌ Lieferanten sind von den Toleranzen und Berichtspflichten des Projekts grundsätzlich ausgenommen
Team Manager können auch von Lieferanten kommen. Work Packages sind der Steuerungsmechanismus (Umfang, Termine, Toleranzen, Berichte), der Vertrag ergänzt ihn kommerziell.
Szenario Change-Budget [P] [Practices] 1 Unterseite →
☝️ Single Was ist das Change-Budget?
❌ Ein Budget für die Nutzenmessung nach Projektende
❌ Ein Budget für Workshops, in denen Lessons gesammelt werden
❌ Eine Reserve, mit der der Project Manager Kostenüberschreitungen einer Stage ausgleicht
✅ Ein vom Project Board bereitgestelltes Budget, aus dem die Change Authority Änderungen finanziert
Das Change-Budget begrenzt, wie viel Änderung die Change Authority ohne erneute Board-Entscheidung genehmigen darf. Es ist keine Reserve zum Ausgleich von Fehlplanung.
Szenario Produktbasierte Planung [P] [Practices] 1 Unterseite →
☝️ Single In welcher Reihenfolge entsteht ein produktbasierter Plan typischerweise?
❌ Terminplan festlegen → Budget verteilen → Produkte ableiten → Risiken bewerten und dokumentieren
❌ Aufwand schätzen → Produkte identifizieren → Aktivitäten festlegen → Abhängigkeiten klären
❌ Aktivitäten sammeln → Termine festlegen → Produkte nachträglich benennen → Aufwand schätzen
✅ Produkte definieren → Reihenfolge/Abhängigkeiten (PFD) → Aktivitäten ableiten → Aufwand schätzen → Terminplan
Focus on Products: Zuerst wird geklärt, WAS geliefert wird, dann in welcher Reihenfolge, erst danach WIE (Aktivitäten), mit welchem Aufwand und wann.
Szenario Issue-Definition [P] [Practices] 1 Unterseite →
☝️ Single Was ist ein Issue in PRINCE2?
❌ Ein Änderungsantrag, der ausschließlich vom Kunden gestellt werden darf
❌ Jede Abweichung der Work-Package-Kosten, auch wenn sie innerhalb der Toleranz liegt
✅ Jedes relevante Ereignis, das nicht geplant war und Management-Aufmerksamkeit erfordert
❌ Ausschließlich ein bereits eingetretenes Risiko
Ein Issue kann ein Änderungswunsch, eine Off-Specification oder ein Problem/Concern sein. Es wird erfasst, bewertet und über das Issue-Verfahren entschieden.
Szenario Rolle und Jobtitel [P] [Practices] 1 Unterseite →
☝️ Single In PRINCE2 werden Rollen von Jobtiteln unterschieden. Was bedeutet das für die Rolle Senior User?
❌ Sie wird automatisch vom Project Manager zusätzlich zu seinen eigenen Aufgaben mit übernommen
❌ Sie ist an den Jobtitel „Abteilungsleiter“ gebunden und kann nicht anders besetzt werden
✅ Von einer geeigneten Person mit den nötigen Befugnissen, unabhängig vom Jobtitel; ggf. auch von mehreren Personen
❌ Sie kann nur von einer einzigen Person ausgeübt werden und niemals von mehreren gemeinsam
Defined Roles and Responsibilities: Entscheidend sind Befugnis, Kompetenz und Verfügbarkeit, nicht der Jobtitel. Rollen können geteilt oder kombiniert werden, wo es sinnvoll ist.
Die 7 Prinzipien
Anwendung Tailoring im Szenario [P] [Prinzipien] 1 Unterseite →
☝️ Single SZENARIO "Kundenportal 2.0": Die Mustermann GmbH führt ein neues Kunden-Self-Service-Portal ein. Executive: Frau Dr. Keller (Vertrieb). Senior User: Herr Aydın (Kundenservice). Senior Supplier: Frau Nowak (IT, inkl. externer Dienstleister). Projektmanager: Herr Vogt. Budget 420.000 € (davon 90.000 € Reserve). 4 Stages über 9 Monate. Die Mustermann GmbH ist ein mittelständisches Unternehmen ohne eigene PMO-Struktur. Was wäre ein sinnvoller Tailoring-Ansatz?
✅ Vereinfachte, kombinierte Management-Produkte bei vollständig erhaltenen Principles
❌ Tailoring ist nur bei Konzernen zulässig
❌ PRINCE2 kann bei mittelständischen Unternehmen grundsätzlich nicht angewendet werden
❌ Einzelne Principles komplett weglassen, um Aufwand zu sparen
Vereinfachte, kombinierte Management-Produkte statt umfangreicher Einzeldokumente — die Principles bleiben dabei vollständig erhalten.
Merksatz:
Ein Maßanzug (Tailoring) wird gekürzt und vereinfacht (Dokumente kombiniert), aber die Nähte (Principles) müssen bombenfest halten, sonst fällt er auseinander.

Warum die anderen falsch sind:
B: Tailoring ist für jede Projektgröße Pflicht, nicht nur für Konzerne.
 C: PRINCE2 ist universell skalierbar und durch Anpassung gerade für den Mittelstand ideal.
  • D: Die Prinzipien sind das unverhandelbare Fundament und dürfen niemals weggelassen werden.
Szenario Tailoring bei kleinerem Standort [P] [Prinzipien] 1 Unterseite →
☝️ Single SZENARIO 'SolarDach Rollout': Die GreenTech Solar AG (Senior Supplier, Geschaeftsfuehrerin Frau Yilmaz) installiert im Auftrag der LogiKon AG (Auftraggeber-Konzern) Photovoltaik-Anlagen auf 40 Logistikzentren. Executive ist Frau Dr. Berger (COO LogiKon), Senior User ist Herr Falk (Leiter Facility Management LogiKon, spaeterer Nutzer der Anlagen), Project Manager ist Herr Nowak, Team Manager Elektroinstallation ist Frau Lindqvist. Das Projekt ist in 4 Management-Stages gegliedert: IP, Pilotphase (5 Standorte), Rollout-Welle 1 (20 Standorte), Rollout-Welle 2 (15 Standorte) inkl. Abschluss. Toleranzen: Budget +/-5%, Zeit +/-2 Wochen je Stage. Fuer einen einzelnen, sehr kleinen Zusatzstandort (nur ein kleines Nebengebaeude) moechte Herr Nowak den vollen Foermlichkeitsgrad von Stage Boundaries vereinfachen. Ist das mit PRINCE2 vereinbar?
❌ Nein, jede Stage Boundary muss unabhaengig von der Projektgroesse identisch formell ablaufen.
❌ Ja, aber nur wenn das Project Board dafuer offiziell ein anderes Rahmenwerk statt PRINCE2 einfuehrt.
❌ Nein, das Principle 'Tailor to Suit the Project' gilt nur fuer die Practices, nicht fuer Prozesse.
✅ Ja, solange die zugrunde liegenden Prinzipien (u.a. Manage by Stages) weiterhin beachtet werden.
Szenario Tailoring oeffentlicher Sektor [P] [Prinzipien] 1 Unterseite →
☝️ Single SZENARIO 'Stadtarchiv Digitalisierung': Die Stadt Muenchen digitalisiert historische Archivbestaende. Executive ist Stadtkaemmerin Frau Dr. Vogel, Senior User ist Stadtarchivar Herr Brandt (spaeterer Nutzer der digitalen Bestaende), Senior Supplier ist Herr Ilic (Projektleiter bei ScanTech GmbH, dem beauftragten Dienstleister). Project Manager ist Frau Keller. Zwei Project-Assurance-Rollen sind benannt: die interne Revisionsstelle (Business Assurance) und der behoerdliche Datenschutzbeauftragte (User Assurance). Stages: Pilot (1.000 Dokumente), Hauptphase Welle 1 (Zeitungsarchiv), Welle 2 (Urkunden), Abschluss. Qualitaetskriterium: Scan-Aufloesung mind. 600dpi, Methode: Stichprobenpruefung von 5% der gescannten Dokumente. Weil die Stadt zusaetzliche Vergabe- und Dokumentationsvorschriften des oeffentlichen Sektors einhalten muss, ergaenzt Frau Keller die Management-Produkte um zusaetzliche Freigabeschritte. Welches PRINCE2-Prinzip beschreibt dieses Vorgehen?
❌ Continued Business Justification.
❌ Focus on Products.
✅ Tailor to Suit the Project.
❌ Manage by Exception.
Mini-Szenario Manage by Stages Bauprojekt [P] [Prinzipien] 1 Unterseite →
☝️ Single Ein Bauunternehmen teilt ein Projekt in vier Management-Stages: Planung, Rohbau, Ausbau, Abnahme. Nach jeder Stage entscheidet das Project Board erneut ueber die Freigabe der naechsten. Welches Prinzip wird hier konkret angewendet?
✅ Manage by Stages.
❌ Learn from Experience.
❌ Focus on Products.
❌ Defined Roles and Responsibilities.
Mini-Szenario Toleranz Team Manager [P] [Prinzipien] 1 Unterseite →
☝️ Single Ein Team Manager darf innerhalb seines Arbeitspakets frei entscheiden, solange Zeit- und Qualitaetsvorgaben eingehalten werden. Erst bei drohender Abweichung informiert er den Project Manager. Welches Prinzip zeigt sich hier?
✅ Manage by Exception.
❌ Continued Business Justification.
❌ Focus on Products.
❌ Tailor to Suit the Project.
Mini-Szenario Business Case wird unrentabel [P] [Prinzipien] 1 Unterseite →
☝️ Single Waehrend eines IT-Migrationsprojekts stellt sich heraus, dass ein Wettbewerber eine guenstigere Loesung anbietet, wodurch der Nutzen des eigenen Projekts stark sinkt. Was verlangt PRINCE2 in diesem Fall vom Project Board?
❌ Ausschliesslich den Project Manager ueber die Marktlage informell zu unterrichten.
✅ Das Projekt formell auf fortbestehende Rechtfertigung zu pruefen und ggf. anzupassen oder zu beenden.
❌ Das Projekt unveraendert und ohne jede weitere Pruefung fortzufuehren, da ein einmal genehmigter Business Case fuer immer bindend bleibt.
❌ Sofort ein neues Projekt mit anderem Executive zu starten.
Fallstudie Campus Nord [P] [Prinzipien] 1 Unterseite →
☝️ Single FALLSTUDIE „Campus Nord“: Die Hochschule Rheinbach errichtet ein Lernzentrum mit Bibliothek (Neubau, Budget 8,5 Mio. €, davon 6 Mio. € Landesförderung; der Förderbescheid verlangt die Fertigstellung bis 31. Juli). Executive ist Kanzlerin Frau Dr. Weiß, Senior User Prof. Haas (Leiter der Bibliothek), Senior Supplier Herr Demir (Projektleiter der Demir Bau AG). Project Manager ist Herr Krüger; Frau Lenz unterstützt ihn als Project Support; das Hochschul-Controlling prüft unabhängig die Kostenentwicklung. Herr Voss (Bauleiter der Demir Bau AG) ist Team Manager. Fünf Stages: Planung & Genehmigung, Rohbau, Ausbau, Technik & Ausstattung, Abnahme & Übergabe. Stage-Toleranzen: Zeit ±4 Wochen, Kosten ±3 %. Ziel ist eine DGNB-Gold-Zertifizierung. Frage: Die Kanzlerin fragt, warum das Projekt in fünf Stages geteilt wird und nicht nur in zwei. Welche Kriterien bestimmen sinnvolle Stage-Grenzen nach PRINCE2?
❌ Der Rhythmus der Quartalsberichte des Hochschul-Controllings
✅ Planungshorizont, Risiko und Kontrollbedarf sowie natürliche Entscheidungspunkte im Projekt
❌ Die Projektlaufzeit geteilt durch eine feste Stage-Länge von drei Monaten
❌ Die Zahl der beteiligten Lieferanten, da jeder Lieferant eine eigene Stage erhält
Manage by Stages: Länge und Anzahl richten sich nach Planungshorizont, Risiko/Komplexität (Kontrollbedarf) und natürlichen Entscheidungspunkten. Jede Stage-Grenze ist ein Kontrollpunkt für das Board.
Fallstudie PayLite [P] [Prinzipien] 2 Unterseite →
☝️ Single FALLSTUDIE „PayLite“: Die FinBridge GmbH (Fintech, 60 Mitarbeitende) entwickelt die Zahlungs-App PayLite. Executive ist Frau Nguyen (CEO), Senior User Herr Baumann (Head of Customer Success), Senior Supplier Frau Dr. Lehmann (CTO). Project Manager ist Herr Weber. Die Entwicklung erfolgt durch zwei Scrum-Teams in Zwei-Wochen-Sprints; Product Owner ist Herr Jung. Das Projekt hat vier Stages von je etwa drei Monaten (Initiierung, MVP, Beta & Regulierung, Marktstart). Zeit und Kosten sind eng begrenzt, der Umfang ist priorisiert (Must/Should/Could). Für den Marktstart wird eine Erlaubnis der Aufsichtsbehörde benötigt. Frage: Frau Nguyen möchte statt umfangreicher Highlight Reports nur ein Dashboard mit Burn-up-Chart und Top-Risiken. Ist das mit PRINCE2 vereinbar?
❌ Nein, der Highlight Report ist ein verpflichtendes Dokument in fester Form und darf nicht ersetzt werden
✅ Ja: Management-Produkte müssen kein Dokument sein, solange die nötigen Informationen zweckgerecht ankommen (Tailoring)
❌ Nur, wenn alle sieben Principles für dieses Projekt gleichzeitig angepasst und neu definiert werden
❌ Nein, Dashboards sind nur auf Team-Ebene zulässig, nicht für das Project Board oder den Executive
Tailor to suit the project: Form und Umfang der Management-Produkte dürfen angepasst werden. Entscheidend ist, dass der Informationsbedarf der Empfänger erfüllt wird. Die Principles selbst sind nicht verhandelbar.
☝️ Single FALLSTUDIE „PayLite“: Die FinBridge GmbH (Fintech, 60 Mitarbeitende) entwickelt die Zahlungs-App PayLite. Executive ist Frau Nguyen (CEO), Senior User Herr Baumann (Head of Customer Success), Senior Supplier Frau Dr. Lehmann (CTO). Project Manager ist Herr Weber. Die Entwicklung erfolgt durch zwei Scrum-Teams in Zwei-Wochen-Sprints; Product Owner ist Herr Jung. Das Projekt hat vier Stages von je etwa drei Monaten (Initiierung, MVP, Beta & Regulierung, Marktstart). Zeit und Kosten sind eng begrenzt, der Umfang ist priorisiert (Must/Should/Could). Für den Marktstart wird eine Erlaubnis der Aufsichtsbehörde benötigt. Frage: Herr Jung schlägt vor, ganz auf Stage-Grenzen zu verzichten, weil die Sprints ohnehin alle zwei Wochen Feedback liefern. Wie ist das zu beurteilen?
✅ Nicht möglich: Pflicht sind Initiierungs-Stage plus mindestens eine weitere; Stage-Grenzen sind Board-Entscheidungspunkte
❌ Möglich, weil agile Projekte grundsätzlich von den PRINCE2-Principles befreit sind und selbst steuern
❌ Möglich, wenn der Product Owner die Stage-Entscheidungen an Stelle des Project Boards trifft
❌ Möglich, wenn das Project Board jeden einzelnen Sprint formal als eigene Stage autorisiert und dokumentiert
Sprint-Reviews ersetzen keine Board-Entscheidungen über Business Case und Fortführung. Stages bleiben als Kontrollpunkte erhalten; ihre Länge kann jedoch an das agile Umfeld angepasst werden.
Fallstudie Bürgerportal [P] [Prinzipien] 1 Unterseite →
☝️ Single FALLSTUDIE „Bürgerportal“: Der Landkreis Waldenau führt ein digitales Bürgerportal für 35 Verwaltungsleistungen ein und bindet 12 Gemeinden an. Executive ist Landrätin Frau Dr. Wiesner, Senior User Herr Hartmann (Amtsleiter Bürgerservice), Senior Supplier Herr Petrov (Kommunales Rechenzentrum). Project Manager ist Frau Ebert. Die Datenschutzbeauftragte Frau Schulz prüft im Auftrag des Boards unabhängig die Datenschutzkonformität. Vier Stages; Stage-Toleranzen: Zeit ±4 Wochen, Kosten ±5 %, Umfang mindestens 30 von 35 Leistungen. Frage: Nach dem Erfolg möchte die Landrätin PRINCE2 als Standard für alle Kreisprojekte verankern. Wie unterscheidet sich das von Tailoring?
❌ Tailoring gilt nur für kleine Projekte mit wenig Risiko, Embedding nur für große Programme
❌ Es gibt keinen Unterschied; beide Begriffe bezeichnen die Anpassung von Management-Produkten
❌ Embedding bedeutet, alle Principles wegzulassen; Tailoring betrifft nur die sieben Practices
✅ Tailoring passt PRINCE2 an ein Projekt an; Embedding verankert die Methode dauerhaft in der Organisation
Tailoring = projektbezogene Anpassung der Methode. Embedding = Integration der Methode in die Arbeitsweise, Standards und Governance der Organisation.
Fallstudie CargoVolt [P] [Prinzipien] 2 Unterseite →
☝️ Single FALLSTUDIE „CargoVolt“: Das Start-up CargoVolt (25 Mitarbeitende) bringt ein neues E-Lastenrad zur Marktreife und will es auf einer Fachmesse im September (fester Termin) präsentieren. Budget 350.000 €, Laufzeit neun Monate. Executive ist die Gründerin Frau Seidel, Senior User Herr Aydin (Vertriebsleiter), Senior Supplier Herr Kraus (Fahrradwerk Kraus & Söhne, Fertigungspartner). Project Manager ist Frau Meier (Teilzeit). Es gibt kein Project-Support-Team; das Projekt hat nur zwei Stages (Initiierung, Entwicklung & Markteinführung). Frage: Herr Aydin fragt, ob zwei Stages für ein so kleines Projekt zulässig sind. Wie viele Management Stages verlangt PRINCE2 mindestens?
✅ Zwei: eine Initiierungs-Stage und mindestens eine weitere Management Stage
❌ Drei – Initiierung, Durchführung und Abschluss müssen getrennte Stages sein
❌ Fünf – eine je Phase des Produktlebenszyklus
❌ Eine – bei kleinen Projekten entfällt die Initiierungs-Stage
Manage by Stages: Jedes PRINCE2-Projekt hat mindestens zwei Management Stages, die Initiierungs-Stage und mindestens eine weitere. Bei kleinen Projekten genügt oft genau das.
☝️ Single FALLSTUDIE „CargoVolt“: Das Start-up CargoVolt (25 Mitarbeitende) bringt ein neues E-Lastenrad zur Marktreife und will es auf einer Fachmesse im September (fester Termin) präsentieren. Budget 350.000 €, Laufzeit neun Monate. Executive ist die Gründerin Frau Seidel, Senior User Herr Aydin (Vertriebsleiter), Senior Supplier Herr Kraus (Fahrradwerk Kraus & Söhne, Fertigungspartner). Project Manager ist Frau Meier (Teilzeit). Es gibt kein Project-Support-Team; das Projekt hat nur zwei Stages (Initiierung, Entwicklung & Markteinführung). Frage: Frau Seidel möchte Project Brief, PID und Stage Plan der Initiierung in einem kompakten Dokument von zehn Seiten zusammenfassen. Ist das mit PRINCE2 vereinbar?
❌ Nein, PRINCE2 verbietet es, Produkte aus verschiedenen Prozessen in einem Dokument zusammenzufassen
❌ Ja, aber dann entfallen die Principles für dieses Projekt und müssen später nachgeholt werden
❌ Nein, jedes Management-Produkt muss ein eigenes, vollständiges Dokument in voller Länge sein
✅ Ja: Management-Produkte dürfen angepasst und kombiniert werden, wenn die nötigen Informationen enthalten sind
Tailoring erlaubt Kombination, Kürzung und andere Formen der Management-Produkte. Nicht verhandelbar sind die sieben Principles.
Szenario Lernen aus Erfahrung [P] [Prinzipien] 1 Unterseite →
☝️ Single Wer trägt in PRINCE2 Verantwortung dafür, dass aus Erfahrungen gelernt wird?
❌ Ausschließlich die Project Assurance, die im Auftrag des Boards das Projekt überwacht
✅ Alle Projektbeteiligten; der Project Manager stellt sicher, dass Lessons genutzt werden
❌ Ausschließlich das Project Board, und zwar erst mit dem Projektabschluss
❌ Ausschließlich das Project-Support-Team, das Logs und Registers des Projekts pflegt
Learn from Experience ist ein Principle für das gesamte Projekt. Lessons werden von allen gesammelt und vom PM in Log und Report gepflegt.
Die 7 Prozesse
Szenario Prozessreihenfolge im Beispiel [P] [Prozesse] 1 Unterseite →
☝️ Single SZENARIO 'SolarDach Rollout': Die GreenTech Solar AG (Senior Supplier, Geschaeftsfuehrerin Frau Yilmaz) installiert im Auftrag der LogiKon AG (Auftraggeber-Konzern) Photovoltaik-Anlagen auf 40 Logistikzentren. Executive ist Frau Dr. Berger (COO LogiKon), Senior User ist Herr Falk (Leiter Facility Management LogiKon, spaeterer Nutzer der Anlagen), Project Manager ist Herr Nowak, Team Manager Elektroinstallation ist Frau Lindqvist. Das Projekt ist in 4 Management-Stages gegliedert: IP, Pilotphase (5 Standorte), Rollout-Welle 1 (20 Standorte), Rollout-Welle 2 (15 Standorte) inkl. Abschluss. Toleranzen: Budget +/-5%, Zeit +/-2 Wochen je Stage. In welchem Prozess wird festgelegt, WELCHE konkreten Standorte in die Pilotphase aufgenommen werden, inkl. Erstellung von PID und Stage-Plan?
✅ Initiating a Project (IP).
❌ Starting up a Project (SU).
❌ Managing a Stage Boundary (SB).
❌ Controlling a Stage (CS).
Szenario Prozess SB am Stage-Ende Welle 1 [P] [Prozesse] 1 Unterseite →
☝️ Single SZENARIO 'Stadtarchiv Digitalisierung': Die Stadt Muenchen digitalisiert historische Archivbestaende. Executive ist Stadtkaemmerin Frau Dr. Vogel, Senior User ist Stadtarchivar Herr Brandt (spaeterer Nutzer der digitalen Bestaende), Senior Supplier ist Herr Ilic (Projektleiter bei ScanTech GmbH, dem beauftragten Dienstleister). Project Manager ist Frau Keller. Zwei Project-Assurance-Rollen sind benannt: die interne Revisionsstelle (Business Assurance) und der behoerdliche Datenschutzbeauftragte (User Assurance). Stages: Pilot (1.000 Dokumente), Hauptphase Welle 1 (Zeitungsarchiv), Welle 2 (Urkunden), Abschluss. Qualitaetskriterium: Scan-Aufloesung mind. 600dpi, Methode: Stichprobenpruefung von 5% der gescannten Dokumente. Am Ende von Welle 1 (Zeitungsarchiv) muss entschieden werden, ob Welle 2 (Urkunden) beginnt. Welcher Prozess deckt diese Vorbereitung ab?
✅ Managing a Stage Boundary (SB).
❌ Closing a Project (CP), also ganz am allerletzten Ende des gesamten Vorhabens.
❌ Controlling a Stage (CS).
❌ Managing Product Delivery (MP).
Szenario MP Arbeitspaket ScanTech [P] [Prozesse] 1 Unterseite →
☝️ Single SZENARIO 'Stadtarchiv Digitalisierung': Die Stadt Muenchen digitalisiert historische Archivbestaende. Executive ist Stadtkaemmerin Frau Dr. Vogel, Senior User ist Stadtarchivar Herr Brandt (spaeterer Nutzer der digitalen Bestaende), Senior Supplier ist Herr Ilic (Projektleiter bei ScanTech GmbH, dem beauftragten Dienstleister). Project Manager ist Frau Keller. Zwei Project-Assurance-Rollen sind benannt: die interne Revisionsstelle (Business Assurance) und der behoerdliche Datenschutzbeauftragte (User Assurance). Stages: Pilot (1.000 Dokumente), Hauptphase Welle 1 (Zeitungsarchiv), Welle 2 (Urkunden), Abschluss. Qualitaetskriterium: Scan-Aufloesung mind. 600dpi, Methode: Stichprobenpruefung von 5% der gescannten Dokumente. Frau Keller vereinbart mit Herrn Ilic (ScanTech) ein Arbeitspaket fuer das Scannen der Urkunden in Welle 2, inkl. Abnahmekriterien und Fortschrittsberichten. Welchem Prozess ist diese kontrollierte Uebergabe zuzuordnen?
❌ Directing a Project (DP).
❌ Starting up a Project (SU).
❌ Initiating a Project (IP).
✅ Managing Product Delivery (MP).
Mini-Szenario Prozesse den Zwecken zuordnen [P] [Prozesse] 1 Unterseite →
matching Ordnen Sie jedem PRINCE2-Prozess seinen zentralen Zweck zu.
Fallstudie WerftOne [P] [Prozesse] 3 Unterseite →
☝️ Single FALLSTUDIE „WerftOne“: Die Nordwerft Systems GmbH (Schiffsausrüster, 420 Mitarbeitende) löst ihr 20 Jahre altes ERP-System durch eine neue Standardsoftware ab. Executive ist Frau Brandes (Vorständin Finanzen), Senior User Herr Petersen (Leiter Produktion), Senior Supplier Herr Okafor (Vertriebsleiter des Softwareherstellers Arcon), Project Manager Frau Lindner. Team Manager für die Konfiguration ist Frau Sato von Arcon. Budget 1,8 Mio. €, Laufzeit 14 Monate, vier Stages (Initiierung, Design & Konfiguration, Test & Datenmigration, Go-live & Abschluss). Stage-Toleranzen: Zeit ±3 Wochen, Kosten ±5 %. Das Change-Budget beträgt 60.000 €, davon sind 10.000 € verbraucht; als Change Authority ist ein Gremium aus Herrn Petersen und Frau Lindner benannt. Erwarteter Nutzen: 12 % geringere Lagerbestandskosten, messbar frühestens 18 Monate nach Go-live. Frage: Das Project Board bittet Frau Lindner nach dem Exception Report, einen Exception Plan vorzulegen. In welchem Prozess erstellt sie ihn?
❌ In Controlling a Stage (CS), weil die Ausnahme innerhalb der laufenden Stage entsteht
❌ In Directing a Project (DP), weil das Board den Plan selbst erstellt und autorisiert
✅ In Managing a Stage Boundary (SB) – dort gibt es die Aktivität „Produce an Exception Plan“
❌ In Initiating a Project (IP), weil ein neuer Plan die Projektinitiierung wiederholt
Der Exception Plan wird auf Anforderung des Boards vom Project Manager im Prozess Managing a Stage Boundary erstellt. Autorisiert wird er anschließend vom Project Board in Directing a Project.
☝️ Single FALLSTUDIE „WerftOne“: Die Nordwerft Systems GmbH (Schiffsausrüster, 420 Mitarbeitende) löst ihr 20 Jahre altes ERP-System durch eine neue Standardsoftware ab. Executive ist Frau Brandes (Vorständin Finanzen), Senior User Herr Petersen (Leiter Produktion), Senior Supplier Herr Okafor (Vertriebsleiter des Softwareherstellers Arcon), Project Manager Frau Lindner. Team Manager für die Konfiguration ist Frau Sato von Arcon. Budget 1,8 Mio. €, Laufzeit 14 Monate, vier Stages (Initiierung, Design & Konfiguration, Test & Datenmigration, Go-live & Abschluss). Stage-Toleranzen: Zeit ±3 Wochen, Kosten ±5 %. Das Change-Budget beträgt 60.000 €, davon sind 10.000 € verbraucht; als Change Authority ist ein Gremium aus Herrn Petersen und Frau Lindner benannt. Erwarteter Nutzen: 12 % geringere Lagerbestandskosten, messbar frühestens 18 Monate nach Go-live. Frage: Am Ende von Stage 2 liegen dem Project Board End Stage Report, aktualisierter Business Case und der Stage Plan für Stage 3 vor. In welchem Prozess entscheidet das Board, ob Stage 3 beginnen darf?
❌ Initiating a Project (IP), da jede Stage mit einer Initiierung beginnt
❌ Managing a Stage Boundary (SB), da der Project Manager die Stage-Freigabe erteilt
❌ Controlling a Stage (CS), da die Freigabe Teil der laufenden Steuerung ist
✅ Directing a Project (DP) – Aktivität „Authorize a Stage or Exception Plan“
Der Project Manager bereitet den Stage-Übergang in SB vor; die Entscheidung über die Fortführung trifft das Project Board in DP.
☝️ Single FALLSTUDIE „WerftOne“: Die Nordwerft Systems GmbH (Schiffsausrüster, 420 Mitarbeitende) löst ihr 20 Jahre altes ERP-System durch eine neue Standardsoftware ab. Executive ist Frau Brandes (Vorständin Finanzen), Senior User Herr Petersen (Leiter Produktion), Senior Supplier Herr Okafor (Vertriebsleiter des Softwareherstellers Arcon), Project Manager Frau Lindner. Team Manager für die Konfiguration ist Frau Sato von Arcon. Budget 1,8 Mio. €, Laufzeit 14 Monate, vier Stages (Initiierung, Design & Konfiguration, Test & Datenmigration, Go-live & Abschluss). Stage-Toleranzen: Zeit ±3 Wochen, Kosten ±5 %. Das Change-Budget beträgt 60.000 €, davon sind 10.000 € verbraucht; als Change Authority ist ein Gremium aus Herrn Petersen und Frau Lindner benannt. Erwarteter Nutzen: 12 % geringere Lagerbestandskosten, messbar frühestens 18 Monate nach Go-live. Frage: Zu Projektbeginn erfährt Frau Lindner, dass ein früheres CRM-Projekt der Nordwerft an der Datenmigration gescheitert ist. Was sollte sie in der Startphase tun?
❌ Nichts unternehmen, da Lessons ausschließlich aus dem eigenen Projekt stammen können und sonst nicht belastbar sind
❌ Warten, bis in der letzten Stage der Lessons Report erstellt wird, und dort das Thema aufgreifen
✅ Frühere Lessons gezielt einholen (SU), im Lessons Log festhalten und in Planung und Risikoanalyse berücksichtigen
❌ Das Thema als Issue erfassen und der Change Authority zur Entscheidung vorlegen
Learn from Experience beginnt vor dem Projektstart: In Starting up a Project werden Lessons früherer Projekte erfasst und für Planung und Risikobewertung genutzt.
Fallstudie Campus Nord [P] [Prozesse] 1 Unterseite →
☝️ Single FALLSTUDIE „Campus Nord“: Die Hochschule Rheinbach errichtet ein Lernzentrum mit Bibliothek (Neubau, Budget 8,5 Mio. €, davon 6 Mio. € Landesförderung; der Förderbescheid verlangt die Fertigstellung bis 31. Juli). Executive ist Kanzlerin Frau Dr. Weiß, Senior User Prof. Haas (Leiter der Bibliothek), Senior Supplier Herr Demir (Projektleiter der Demir Bau AG). Project Manager ist Herr Krüger; Frau Lenz unterstützt ihn als Project Support; das Hochschul-Controlling prüft unabhängig die Kostenentwicklung. Herr Voss (Bauleiter der Demir Bau AG) ist Team Manager. Fünf Stages: Planung & Genehmigung, Rohbau, Ausbau, Technik & Ausstattung, Abnahme & Übergabe. Stage-Toleranzen: Zeit ±4 Wochen, Kosten ±3 %. Ziel ist eine DGNB-Gold-Zertifizierung. Frage: Das Land kürzt die Förderung, das Board beschließt in Stage 3 den vorzeitigen Abbruch. Welche Aktivität führt Herr Krüger jetzt im Prozess Closing a Project aus?
❌ Den Prozess Starting up a Project erneut durchlaufen, um ein verkleinertes Projekt zu starten
❌ Bis zum regulären Stage-Ende warten und erst danach den Abschluss im Stage Boundary vorbereiten
❌ Einen Exception Plan für die Fortsetzung mit reduziertem Budget erstellen und zur Genehmigung vorlegen
✅ Prepare premature closure: gelieferte Produkte sichern, offene Arbeiten und Follow-on Actions dokumentieren
Bei vorzeitigem Abbruch entscheidet das Board (DP); der Project Manager bereitet in CP den vorzeitigen Abschluss vor: Was ist fertig, was nicht, was muss übergeben werden, welche Folgemaßnahmen sind zu empfehlen.
Zuordnung Prozesse Campus Nord [P] [Prozesse] 1 Unterseite →
matching FALLSTUDIE „Campus Nord“: Die Hochschule Rheinbach errichtet ein Lernzentrum mit Bibliothek (Neubau, Budget 8,5 Mio. €, davon 6 Mio. € Landesförderung; der Förderbescheid verlangt die Fertigstellung bis 31. Juli). Executive ist Kanzlerin Frau Dr. Weiß, Senior User Prof. Haas (Leiter der Bibliothek), Senior Supplier Herr Demir (Projektleiter der Demir Bau AG). Project Manager ist Herr Krüger; Frau Lenz unterstützt ihn als Project Support; das Hochschul-Controlling prüft unabhängig die Kostenentwicklung. Herr Voss (Bauleiter der Demir Bau AG) ist Team Manager. Fünf Stages: Planung & Genehmigung, Rohbau, Ausbau, Technik & Ausstattung, Abnahme & Übergabe. Stage-Toleranzen: Zeit ±4 Wochen, Kosten ±3 %. Ziel ist eine DGNB-Gold-Zertifizierung. Frage: Ordnen Sie jedem Ereignis den PRINCE2-Prozess zu, in dem es stattfindet.
Stage Plan für die Folge-Stage: SB. Autorisierung der Initiierung: DP. Work Package autorisieren: CS. Produkte liefern und übergeben: MP.
Fallstudie Smart Meter [P] [Prozesse] 1 Unterseite →
☝️ Single FALLSTUDIE „Smart Meter Rollout“: Die Stadtwerke Rheinau müssen bis zum 31.12. 80.000 konventionelle Stromzähler durch Smart Meter ersetzen; die Frist ist vom Gesellschafterkreis (übergeordnete Ebene) als feste Projektgrenze vorgegeben. Executive ist Herr Dr. Amsel (Geschäftsführer), Senior User Frau Kowalski (Leiterin Netzbetrieb), Senior Supplier Herr Tan (Vertriebsdirektor des Zählerherstellers MeterTec GmbH). Project Manager ist Frau Ostermann, Team Manager Herr Riedel (Montagepartner). Stages: Initiierung, Pilot (2.000 Zähler), Rollout Süd, Rollout Nord, Abschluss. Stage-Toleranzen: Zeit ±3 Wochen, Kosten ±4 %. Qualitätskriterium: Kommunikationsfehlerquote der eingebauten Zähler unter 1 %. Frage: Nach dem Pilot steht fest: Der Zugang zu Kellerräumen kostet 20 % mehr Zeit als geplant. Wie sollte dieses Wissen genutzt werden?
❌ Erst im Lessons Report am Projektende festhalten, damit ausschließlich spätere Projekte profitieren können
❌ Verwerfen, da die Pilot-Stage abgeschlossen ist und ihre Daten für die weitere Planung nicht mehr relevant sind
❌ Nur dann als Issue behandeln, wenn die Zeittoleranz der Stage tatsächlich überschritten wird
✅ Im Lessons Log festhalten, im End Stage Report berichten und in die Planung der Folge-Stages einfließen lassen
Learn from Experience heißt: Lessons laufend erfassen und aktiv anwenden. Der Stage-Übergang (SB) ist der natürliche Zeitpunkt, um Erkenntnisse in die Planung der nächsten Stage zu übernehmen.
Fallstudie GreenLine [P] [Prozesse] 1 Unterseite →
☝️ Single FALLSTUDIE „GreenLine“: Die PackWerk AG (Verpackungshersteller, 900 Mitarbeitende) ersetzt am Hauptstandort eine Produktionslinie durch eine klimaneutrale Anlage (Investition 4,2 Mio. €, davon 30 % gefördert). Executive ist Herr Dr. Sommer (Werkleiter), Senior User Frau Idris (Leiterin Produktionsplanung), Senior Supplier Herr Rahn (Anlagenbauer ThermoTec). Project Manager ist Frau Vogt. Stages: Initiierung, Planung & Bestellung, Installation, Inbetriebnahme & Hochlauf. Ziele: CO₂-Ausstoß der Linie mindestens 35 % geringer, Energiekosten mindestens 22 % geringer, Produktionsausfall höchstens drei Tage. Der Betriebsrat begleitet das Projekt. Frage: Vor dem Projektende übergibt Frau Vogt die Anlage an die Instandhaltung. Was gilt dafür in Closing a Project?
❌ Die Übergabe ist Sache der Betriebsorganisation; der Project Manager dokumentiert nur die Projektkosten
❌ Die Übergabe erfolgt informell, damit das Projekt möglichst schnell geschlossen werden kann
✅ Die Produkte werden formal an die Betriebsorganisation übergeben; offene Punkte gehen als Follow-on Actions weiter
❌ Offene Punkte werden verworfen, sobald das Board den Projektabschluss formal bestätigt hat
In CP gehören Übergabe der Produkte, Bestätigung der Akzeptanz und Empfehlungen für Folgemaßnahmen (Follow-on Actions, Benefit Reviews) zu den zentralen Aktivitäten.
Fallstudie Bürgerportal [P] [Prozesse] 1 Unterseite →
☝️ Single FALLSTUDIE „Bürgerportal“: Der Landkreis Waldenau führt ein digitales Bürgerportal für 35 Verwaltungsleistungen ein und bindet 12 Gemeinden an. Executive ist Landrätin Frau Dr. Wiesner, Senior User Herr Hartmann (Amtsleiter Bürgerservice), Senior Supplier Herr Petrov (Kommunales Rechenzentrum). Project Manager ist Frau Ebert. Die Datenschutzbeauftragte Frau Schulz prüft im Auftrag des Boards unabhängig die Datenschutzkonformität. Vier Stages; Stage-Toleranzen: Zeit ±4 Wochen, Kosten ±5 %, Umfang mindestens 30 von 35 Leistungen. Frage: Das Board hat den Project Brief freigegeben. Wie hängt er mit der Projektinitiierungsdokumentation (PID) zusammen?
❌ Der Project Brief wird nach Freigabe der PID vernichtet, weil er dann rechtlich unwirksam ist
❌ Der Project Brief entsteht erst nach der PID und fasst sie für das Board kurz zusammen
✅ Der Project Brief ist die Grundlage; in der Initiierung wird daraus die PID, die das Board freigibt
❌ Beide Dokumente sind identisch und werden nur unterschiedlich benannt, je nach Prozess
SU liefert den Project Brief (Begründung, Umfang, Rahmen) als Entscheidungsgrundlage für die Initiierung. In IP wird daraus die detaillierte PID mit Business Case, Plänen und Management-Ansätzen.
Fallstudie RZ-Umzug [P] [Prozesse] 2 Unterseite →
☝️ Single FALLSTUDIE „RZ-Umzug“: Die Nordstern Versicherung AG verlagert ihr Rechenzentrum zu einem externen Provider (Budget 2,4 Mio. €). Der Mietvertrag des alten Rechenzentrums endet am 31.03.; die Frist wurde von der Konzernleitung als Projekttoleranz vorgegeben. Executive ist Frau Dr. Yildiz (CIO), Senior User Herr Bergmann (Leiter Schadenbearbeitung), Senior Supplier Herr Novak (Account Manager des Providers ColoNet). Project Manager ist Herr Schäfer, Project Support Frau Peters. Stages: Initiierung, Planung & Vorbereitung, Migration Welle 1 (unkritische Systeme), Migration Welle 2 (kritische Systeme), Abschluss. Frage: In Welle 1 meldet Herr Novak eine Verzögerung von einer Woche; die Stage-Zeittoleranz beträgt ±2 Wochen und weitere Verzögerungen sind nicht absehbar. Wie handelt Herr Schäfer?
❌ Er bittet das Board um die Genehmigung eines Exception Plans für die Stage
❌ Er erstellt sofort einen Exception Report, weil jede Verzögerung dem Board gemeldet werden muss
❌ Er unternimmt nichts, weil die Verzögerung nicht gemeldet werden muss
✅ Er ergreift im Rahmen seiner Befugnis Korrekturmaßnahmen und berichtet im Highlight Report
Innerhalb der Toleranz steuert der Project Manager selbst (Take corrective action in Controlling a Stage) und informiert im regulären Reporting. Nur prognostizierte Überschreitungen lösen einen Exception Report aus.
☝️ Single FALLSTUDIE „RZ-Umzug“: Die Nordstern Versicherung AG verlagert ihr Rechenzentrum zu einem externen Provider (Budget 2,4 Mio. €). Der Mietvertrag des alten Rechenzentrums endet am 31.03.; die Frist wurde von der Konzernleitung als Projekttoleranz vorgegeben. Executive ist Frau Dr. Yildiz (CIO), Senior User Herr Bergmann (Leiter Schadenbearbeitung), Senior Supplier Herr Novak (Account Manager des Providers ColoNet). Project Manager ist Herr Schäfer, Project Support Frau Peters. Stages: Initiierung, Planung & Vorbereitung, Migration Welle 1 (unkritische Systeme), Migration Welle 2 (kritische Systeme), Abschluss. Frage: Nach dem Umzug soll bewertet werden, wie das Projekt gegenüber dem ursprünglichen Plan (Ziele, Toleranzen, Qualität) abgeschnitten hat. Welches Management-Produkt erstellt der Project Manager dafür in Closing a Project?
❌ End Stage Report
❌ Highlight Report
✅ End Project Report
❌ Exception Report
Der End Project Report bewertet die Projektleistung gegenüber der PID (Ziele, Toleranzen, Business Case, Qualität). Der End Stage Report bezieht sich nur auf eine Stage.
Zuordnung Prozess und Hauptergebnis [P] [Prozesse] 1 Unterseite →
matching Ordnen Sie jedem PRINCE2-Prozess sein typisches Hauptergebnis zu.
SU → Project Brief; IP → PID; SB → nächster Stage Plan und End Stage Report; CP → End Project Report und Folgemaßnahmen. Die Distraktoren gehören zu MP bzw. DP.
Zuordnung Aktivität und Prozess [P] [Prozesse] 1 Unterseite →
matching Ordnen Sie jede Aktivität dem Prozess zu, in dem sie stattfindet.
Capture previous lessons → SU; Set up the project controls → IP; Review work package status → CS; Accept a work package → MP; Evaluate the project → CP.
Zuordnung Entscheidungen des Project Boards [P] [Prozesse] 1 Unterseite →
matching Ordnen Sie jedem Ausgangspunkt die passende Entscheidungsaktivität in Directing a Project zu.
Das Board entscheidet an den Kontrollpunkten: Initiierung, Projekt, jede Stage, Abschluss. Work Packages autorisiert der Project Manager in Controlling a Stage.
Szenario Stage-Planung [P] [Prozesse] 1 Unterseite →
☝️ Single In einem Projekt mit vier Stages wird der detaillierte Plan für Stage 3 erst am Ende von Stage 2 erstellt. Ein Kollege hält das für nachlässig. Warum entspricht das dem PRINCE2-Vorgehen?
❌ Weil PRINCE2 nur den Project Plan kennt und die Detailplanung dem Team überlässt und offen lässt
❌ Weil die Detailplanung einer Stage erst nach deren Ende beginnen darf und nie früher zulässig ist
❌ Weil Stage Plans nie vom Project Board genehmigt werden müssen und deshalb spät entstehen dürfen
✅ Weil Stage Plans erst gegen Ende der Vorgänger-Stage in SB detailliert werden, wenn aktuelle Informationen vorliegen
Der Project Plan bleibt grob; die Detailplanung erfolgt stagebezogen und so spät wie sinnvoll. So fließen Lessons, Issues und veränderte Rahmenbedingungen ein.
Szenario Stage-Übergang [P] [Prozesse] 1 Unterseite →
☝️ Single Wann wird der Prozess Managing a Stage Boundary (SB) erstmals durchlaufen?
❌ Erst am Ende der zweiten Delivery-Stage, wenn genügend Erfahrung vorliegt
❌ Nur dann, wenn eine Toleranz überschritten wird und das Board es fordert
✅ Am Ende der Initiierungs-Stage; danach am Ende jeder weiteren Stage außer der letzten
❌ Am Ende jeder Stage einschließlich der letzten, anstelle von Closing a Project
SB bereitet den Übergang in die nächste Stage vor. Für die Initiierungs-Stage ist das der Weg in die erste Delivery-Stage. Die letzte Stage endet mit Closing a Project.
Szenario Letzte Stage [P] [Prozesse] 1 Unterseite →
☝️ Single Warum gibt es für die letzte Management Stage keinen Stage-Übergang (SB), sondern den Prozess Closing a Project?
❌ Weil das Project Board die letzte Stage automatisch ohne inhaltliche Prüfung genehmigt und freigibt
✅ Weil mit der letzten Stage das Projekt endet; statt Folge-Stage werden Übergabe und Abschluss vorbereitet
❌ Weil die letzte Stage keine Toleranzen hat und deshalb gar nicht mehr aktiv gesteuert werden muss
❌ Weil Closing a Project immer als eigene Stage nach der letzten Delivery-Stage durchgeführt wird
In der letzten Stage werden die Aktivitäten von Closing a Project ausgeführt. Ein Stage-Übergang wäre sinnlos, da keine Folge-Stage existiert.
Szenario Folgemaßnahmen [P] [Prozesse] 1 Unterseite →
☝️ Single Kurz vor dem Projektabschluss sind drei Änderungswünsche und ein ungelöstes Problem offen. Was geschieht damit?
❌ Sie werden verworfen, da das Projekt beendet ist und keine Ressourcen mehr hat
❌ Sie werden im Lessons Report als Erfolgsfaktoren des Projekts aufgeführt und archiviert
❌ Das Projekt wird verlängert, bis alle offenen Punkte vollständig erledigt sind
✅ Sie werden als Follow-on Action Recommendations dokumentiert und an die zuständige Stelle übergeben
In Closing a Project erstellt der PM Empfehlungen für Folgemaßnahmen (unerledigte Issues, Risiken, Benefit Reviews) und übergibt sie an die zuständige Organisation.
Szenario Starting up a Project [P] [Prozesse] 1 Unterseite →
✌️ Multi Welche Aktivitäten gehören zum Prozess Starting up a Project (SU)? (Mehrere richtig)
❌ Work Packages autorisieren
✅ Erfahrungen früherer Projekte einholen
❌ Den Business Case endgültig ausarbeiten und die PID baselinen
✅ Den Project Brief zusammenstellen
✅ Executive und Project Manager ernennen
SU ist eine kurze Vorprüfung: Team ernennen, Lessons einholen, Ansatz wählen, Business Case skizzieren, Project Brief erstellen. Work Packages werden in CS autorisiert; die PID entsteht in IP.
Merksatz: SU = „Vor dem Start das Briefing": Team ernennen, Lehren ernten, Brief basteln – PID und Work Packages kommen später.

Warum die anderen falsch sind:
  • Work Packages autorisieren – das macht der Prozess Controlling a Stage (CS).

  • Business Case final + PID baselinen – das gehört zu Initiating a Project (IP), nicht SU.
Szenario Controlling a Stage [P] [Prozesse] 1 Unterseite →
✌️ Multi Welche Aktivitäten gehören zum Prozess Controlling a Stage (CS)? (Mehrere richtig)
❌ Den Projektabschluss autorisieren
✅ Den Stand der Stage prüfen (Review stage status)
❌ Produkte innerhalb eines Work Packages erstellen
✅ Highlight Reports erstellen
✅ Work Packages autorisieren
In CS steuert der Project Manager die laufende Stage. Produkte erstellt der Team Manager in MP; den Abschluss autorisiert das Board in DP.
Szenario Managing Product Delivery [P] [Prozesse] 1 Unterseite →
✌️ Multi Welche Aktivitäten gehören zum Prozess Managing Product Delivery (MP)? (Mehrere richtig)
✅ Ein Work Package ausführen
✅ Ein Work Package abliefern
❌ Den Business Case für die nächste Stage aktualisieren
❌ Den Stage Plan der nächsten Stage erstellen
✅ Ein Work Package annehmen
MP ist die Schnittstelle zwischen Project Manager und Team Manager: Work Package annehmen, ausführen und abliefern. Plan und Business Case der nächsten Stage betreffen SB.
Szenario Managing a Stage Boundary [P] [Prozesse] 1 Unterseite →
✌️ Multi Welche Aktivitäten gehören zum Prozess Managing a Stage Boundary (SB)? (Mehrere richtig)
❌ Ein Work Package autorisieren
❌ Follow-on Action Recommendations für die Übergabe vorbereiten
✅ Die nächste Stage planen
✅ Project Plan und Business Case aktualisieren
✅ Das Ende der Stage berichten (End Stage Report)
SB umfasst Planung der nächsten Stage, Aktualisierung von Project Plan und Business Case, Stage-Ende-Bericht und ggf. Exception Plan. Work Packages autorisiert CS, Folgemaßnahmen entstehen in CP.
Szenario Exception Plan Freigabe [P] [Prozesse] 1 Unterseite →
☝️ Single Frau Berger hat auf Anforderung des Boards einen Exception Plan erstellt. Wer autorisiert ihn?
✅ Das Project Board im Prozess Directing a Project
❌ Der Project Manager selbst, da er den Plan erstellt hat
❌ Der Team Manager
❌ Die Project Assurance
Pläne mit Toleranzwirkung werden vom Project Board autorisiert (Authorize a Stage or Exception Plan). Der PM erstellt, das Board entscheidet.
Szenario Ad-hoc-Anweisung [P] [Prozesse] 1 Unterseite →
☝️ Single Zwischen zwei Stage-Grenzen erfährt der Executive von einer neuen gesetzlichen Vorgabe, die das Projekt betrifft. Welche Aktivität in Directing a Project passt?
❌ Authorize project closure: Das Board beendet das Projekt sofort formal
❌ Authorize initiation: Das Board gibt die Initiierung eines neuen Projekts frei
❌ Ein neues Project Brief erstellen lassen und das Projekt vollständig neu starten
✅ Give ad hoc direction: Das Board informiert den PM und gibt bei Bedarf Anweisungen
In DP kann das Board jederzeit ad hoc Vorgaben machen, z. B. bei externen Änderungen, ohne bis zur nächsten Stage-Grenze zu warten.
People – Menschen im Projekt
Stakeholder-Kommunikation im Szenario [P] [People] 1 Unterseite →
☝️ Single Wie sollten Sorgen von Mitarbeitenden vor Stellenabbau in einem IT-Projekt adressiert werden?
✅ Durch frühzeitige, ehrliche Kommunikation und Einbindung der Betroffenen
❌ Durch ausschließliche Information der Führungsebene und Verzicht auf Einbindung der Betroffenen
❌ Durch Verzögerung der Kommunikation bis zum Ende aller Projektarbeiten und anschließender Bekanntgabe
❌ Durch formelle Ankündigung per Rundschreiben ohne Möglichkeit für Rückfragen oder Dialog
Sorgen vor Stellenabbau werden durch frühzeitige, ehrliche Kommunikation und Einbindung der Betroffenen adressiert (People-Element).
Merksatz:
"Der frühe Vogel baut die Brücke" – Ängste löst man nicht durch Schweigen, sondern indem man Betroffene von Anfang an ehrlich ins Boot holt.

Warum die anderen falsch sind:
B: Geheimhaltung schürt nur die Gerüchteküche und zerstört jegliches Vertrauen.
 C: Späte Information führt zu massivem Widerstand während der gesamten Projektlaufzeit.
  • D: Reine Anweisungen ignorieren die menschliche Ebene und verstärken die Existenzangst.
Mini-Szenario People-Element Widerstand [P] [People] 1 Unterseite →
✌️ Multi Bei der Einfuehrung einer neuen Software beobachtet der Project Manager, dass mehrere Mitarbeitende die Aenderung ablehnen und verunsichert wirken. Welche Massnahmen entsprechen dem People-Element von PRINCE2 (Mehrfachauswahl)?
❌ Die Bedenken ignorieren, da nur die termingerechte Lieferung zaehlt.
✅ Fruehzeitige, transparente Kommunikation ueber Gruende und Auswirkungen der Aenderung.
✅ Kommunikationsform und -inhalt an die jeweilige Zielgruppe anpassen.
✅ Gezieltes Stakeholder-Engagement, um Bedenken der Betroffenen zu verstehen.
Mini-Szenario Fuehrung vs. Aufgabenverteilung [P] [People] 1 Unterseite →
☝️ Single Ein Project Manager verteilt Aufgaben ausschliesslich per E-Mail ohne jede persoenliche Ruecksprache oder Motivation des Teams. Was wuerde das People-Element hierzu vermutlich kritisch anmerken?
✅ Dass Fuehrung mehr umfasst als Aufgabenverteilung, naemlich auch Motivation und Orientierung des Teams.
❌ Dass E-Mail als Kommunikationsmittel grundsaetzlich in PRINCE2 verboten ist.
❌ Nichts, da reine Aufgabenverteilung bereits ausreichende Fuehrung darstellt.
❌ Dass diese Situation ausschliesslich ein Risiko und kein People-Thema ist.
Mini-Szenario Diversitaet im Projektteam [P] [People] 1 Unterseite →
☝️ Single Ein Projektteam besteht bewusst aus Mitgliedern unterschiedlicher Fachrichtungen und Erfahrungshintergruende. Der Project Manager begruendet dies mit robusteren Entscheidungen durch verschiedene Perspektiven. Welchem Aspekt des People-Elements entspricht das?
❌ Manage by Exception auf Teamebene.
❌ Stakeholder-Engagement gegenueber externen Parteien.
✅ Diversity (Vielfalt) im Team.
❌ Change Management fuer Betroffene.
Mini-Szenario Kommunikationsplan Zielgruppen [P] [People] 1 Unterseite →
☝️ Single Ein Project Manager erstellt fuer das Project Board monatliche Kurzberichte, fuer das Team taegliche Stand-ups und fuer externe Stakeholder vierteljaehrliche Newsletter. Welches PRINCE2-Konzept wird damit konkret umgesetzt?
❌ Das Risk Register.
✅ Der Communication Management Approach mit zielgruppengerechter Kommunikation.
❌ Die Change Authority mit ihrem eigenen, vom Project Board eigens zugewiesenen Aenderungsbudget.
❌ Der Exception Plan.
Fallstudie Campus Nord [P] [People] 1 Unterseite →
☝️ Single FALLSTUDIE „Campus Nord“: Die Hochschule Rheinbach errichtet ein Lernzentrum mit Bibliothek (Neubau, Budget 8,5 Mio. €, davon 6 Mio. € Landesförderung; der Förderbescheid verlangt die Fertigstellung bis 31. Juli). Executive ist Kanzlerin Frau Dr. Weiß, Senior User Prof. Haas (Leiter der Bibliothek), Senior Supplier Herr Demir (Projektleiter der Demir Bau AG). Project Manager ist Herr Krüger; Frau Lenz unterstützt ihn als Project Support; das Hochschul-Controlling prüft unabhängig die Kostenentwicklung. Herr Voss (Bauleiter der Demir Bau AG) ist Team Manager. Fünf Stages: Planung & Genehmigung, Rohbau, Ausbau, Technik & Ausstattung, Abnahme & Übergabe. Stage-Toleranzen: Zeit ±4 Wochen, Kosten ±3 %. Ziel ist eine DGNB-Gold-Zertifizierung. Frage: Eine Bürgerinitiative protestiert gegen den Baulärm. Sie ist nicht im Project Board vertreten, kann aber durch Klagen die Baugenehmigung gefährden. Was ist nach dem People-Element angemessen?
❌ Die Initiative ignorieren, da nur Mitglieder des Project Boards für das Projekt relevante Stakeholder sind
❌ Die Kommunikation auf die Pressestelle beschränken und Beschwerden lediglich dokumentieren und ablegen
✅ Die Initiative als Stakeholder analysieren und Engagement im Communication Management Approach planen, z. B. frühen Dialog
❌ Die Initiative in das Project Board aufnehmen, damit sie gleichberechtigt über den Bau mitentscheidet
Stakeholder sind alle, die das Projekt beeinflussen oder von ihm betroffen sind – unabhängig von einer Board-Rolle. Engagement wird analysiert, geplant und im Communication Management Approach festgehalten.
Fallstudie Smart Meter [P] [People] 1 Unterseite →
☝️ Single FALLSTUDIE „Smart Meter Rollout“: Die Stadtwerke Rheinau müssen bis zum 31.12. 80.000 konventionelle Stromzähler durch Smart Meter ersetzen; die Frist ist vom Gesellschafterkreis (übergeordnete Ebene) als feste Projektgrenze vorgegeben. Executive ist Herr Dr. Amsel (Geschäftsführer), Senior User Frau Kowalski (Leiterin Netzbetrieb), Senior Supplier Herr Tan (Vertriebsdirektor des Zählerherstellers MeterTec GmbH). Project Manager ist Frau Ostermann, Team Manager Herr Riedel (Montagepartner). Stages: Initiierung, Pilot (2.000 Zähler), Rollout Süd, Rollout Nord, Abschluss. Stage-Toleranzen: Zeit ±3 Wochen, Kosten ±4 %. Qualitätskriterium: Kommunikationsfehlerquote der eingebauten Zähler unter 1 %. Frage: In der Presse kursiert, der Rollout führe zu höheren Strompreisen; der Kundenservice fürchtet eine Anrufwelle. Wie sollte Frau Ostermann vorgehen?
❌ Alle Kommunikation an die Pressestelle delegieren und den Kundenservice nicht einbinden, um Klarheit zu wahren
❌ Abwarten, bis konkrete Beschwerden vorliegen, und diese dann einzeln als Issues erfassen und bewerten
❌ Den Rollout stoppen, bis die Medienberichte abgeklungen sind und sich die Stimmung beruhigt hat
✅ Stakeholder-Analyse aktualisieren und proaktiv, abgestimmt und mit Rückkanälen kommunizieren, auch mit dem Kundenservice
Das People-Element verlangt vorausschauendes Stakeholder-Engagement: Interessen verstehen, zielgruppengerecht und in beide Richtungen kommunizieren und den Ansatz im Communication Management Approach verankern.
Fallstudie PayLite [P] [People] 1 Unterseite →
☝️ Single FALLSTUDIE „PayLite“: Die FinBridge GmbH (Fintech, 60 Mitarbeitende) entwickelt die Zahlungs-App PayLite. Executive ist Frau Nguyen (CEO), Senior User Herr Baumann (Head of Customer Success), Senior Supplier Frau Dr. Lehmann (CTO). Project Manager ist Herr Weber. Die Entwicklung erfolgt durch zwei Scrum-Teams in Zwei-Wochen-Sprints; Product Owner ist Herr Jung. Das Projekt hat vier Stages von je etwa drei Monaten (Initiierung, MVP, Beta & Regulierung, Marktstart). Zeit und Kosten sind eng begrenzt, der Umfang ist priorisiert (Must/Should/Could). Für den Marktstart wird eine Erlaubnis der Aufsichtsbehörde benötigt. Frage: Herr Weber kommt aus dem klassischen Projektmanagement; die Teams befürchten Bürokratie durch PRINCE2. Was ist der beste Ansatz?
❌ PRINCE2 vollständig und unverändert einführen, um endlose Diskussionen im Team zu vermeiden
❌ Die Kommunikation mit den Teams auf formale Berichte und Statusmeldungen beschränken
❌ Skeptische Teammitglieder aus dem Projekt herausnehmen und durch überzeugte Kollegen ersetzen
✅ Nutzen und Zweck erklären, die Methode gemeinsam mit dem Team anpassen (Tailoring) und Aufwand begrenzen
Akzeptanz entsteht durch Verständnis und Beteiligung. Tailoring erlaubt, den Aufwand an das Umfeld anzupassen; das People-Element betont Kommunikation, Zusammenarbeit und Führung.
Fallstudie GreenLine [P] [People] 1 Unterseite →
☝️ Single FALLSTUDIE „GreenLine“: Die PackWerk AG (Verpackungshersteller, 900 Mitarbeitende) ersetzt am Hauptstandort eine Produktionslinie durch eine klimaneutrale Anlage (Investition 4,2 Mio. €, davon 30 % gefördert). Executive ist Herr Dr. Sommer (Werkleiter), Senior User Frau Idris (Leiterin Produktionsplanung), Senior Supplier Herr Rahn (Anlagenbauer ThermoTec). Project Manager ist Frau Vogt. Stages: Initiierung, Planung & Bestellung, Installation, Inbetriebnahme & Hochlauf. Ziele: CO₂-Ausstoß der Linie mindestens 35 % geringer, Energiekosten mindestens 22 % geringer, Produktionsausfall höchstens drei Tage. Der Betriebsrat begleitet das Projekt. Frage: Der Betriebsrat befürchtet Arbeitsplatzveränderungen durch die Automatisierung und wirkt skeptisch. Was ist ein angemessenes Vorgehen?
❌ Den Betriebsrat in das Project Board aufnehmen und ihm die Entscheidung über den Business Case übertragen
✅ Den Betriebsrat früh als Stakeholder einbinden, Bedenken anhören, transparent informieren und Austausch planen
❌ Die Kommunikation der Personalabteilung überlassen und nur die Ergebnisse abwarten, die man erhält
❌ Erst nach Abschluss der Installation informieren, um Widerstand zu vermeiden und Diskussionen zu umgehen
Stakeholder-Engagement bedeutet frühzeitig, ehrlich und wechselseitig kommunizieren. Skepsis ist ein Signal, das ernst genommen und im Kommunikationsansatz berücksichtigt werden sollte.
Fallstudie CargoVolt [P] [People] 1 Unterseite →
☝️ Single FALLSTUDIE „CargoVolt“: Das Start-up CargoVolt (25 Mitarbeitende) bringt ein neues E-Lastenrad zur Marktreife und will es auf einer Fachmesse im September (fester Termin) präsentieren. Budget 350.000 €, Laufzeit neun Monate. Executive ist die Gründerin Frau Seidel, Senior User Herr Aydin (Vertriebsleiter), Senior Supplier Herr Kraus (Fahrradwerk Kraus & Söhne, Fertigungspartner). Project Manager ist Frau Meier (Teilzeit). Es gibt kein Project-Support-Team; das Projekt hat nur zwei Stages (Initiierung, Entwicklung & Markteinführung). Frage: Frau Seidel weist Teammitgliedern direkt Aufgaben zu und umgeht dabei Frau Meier. Wie sollte Frau Meier vorgehen?
❌ Die Anweisungen der Gründerin kommentarlos umsetzen, da sie die höchste Autorität im Unternehmen ist
❌ Ihre Rolle als Project Manager niederlegen und die Steuerung des Projekts der Gründerin überlassen
❌ Das Projekt sofort beim Board als gescheitert melden und die Fortführung infrage stellen
✅ Das Gespräch suchen, die Rollen klären und Änderungswünsche über die Änderungssteuerung leiten
Defined Roles and Responsibilities und Leadership: Klare Rollen verhindern Doppelsteuerung. Der offene Dialog über Delegation und Änderungssteuerung ist der konstruktive Weg.
Zuordnung Stakeholder CargoVolt [P] [People] 1 Unterseite →
matching FALLSTUDIE „CargoVolt“: Das Start-up CargoVolt (25 Mitarbeitende) bringt ein neues E-Lastenrad zur Marktreife und will es auf einer Fachmesse im September (fester Termin) präsentieren. Budget 350.000 €, Laufzeit neun Monate. Executive ist die Gründerin Frau Seidel, Senior User Herr Aydin (Vertriebsleiter), Senior Supplier Herr Kraus (Fahrradwerk Kraus & Söhne, Fertigungspartner). Project Manager ist Frau Meier (Teilzeit). Es gibt kein Project-Support-Team; das Projekt hat nur zwei Stages (Initiierung, Entwicklung & Markteinführung). Frage: Ordnen Sie jedem Stakeholder die passende Engagement-Strategie zu.
Eine Stakeholder-Matrix (Einfluss/Interesse) hilft, den Kommunikationsaufwand sinnvoll zu verteilen. Auch Stakeholder mit geringer Priorität werden beobachtet, nicht ignoriert.
Fallstudie RZ-Umzug [P] [People] 1 Unterseite →
☝️ Single FALLSTUDIE „RZ-Umzug“: Die Nordstern Versicherung AG verlagert ihr Rechenzentrum zu einem externen Provider (Budget 2,4 Mio. €). Der Mietvertrag des alten Rechenzentrums endet am 31.03.; die Frist wurde von der Konzernleitung als Projekttoleranz vorgegeben. Executive ist Frau Dr. Yildiz (CIO), Senior User Herr Bergmann (Leiter Schadenbearbeitung), Senior Supplier Herr Novak (Account Manager des Providers ColoNet). Project Manager ist Herr Schäfer, Project Support Frau Peters. Stages: Initiierung, Planung & Vorbereitung, Migration Welle 1 (unkritische Systeme), Migration Welle 2 (kritische Systeme), Abschluss. Frage: Die Migration von Welle 2 findet an drei Wochenenden nachts statt. Das Team ist erschöpft, Fehler häufen sich. Was verlangt das People-Element von Herrn Schäfer?
❌ Mehr Kontrolle und detailliertere Berichte einführen, um Fehler zu vermeiden
✅ Auf Belastung und Wohlbefinden achten, mit Erholungszeiten planen und Leistung wertschätzen
❌ Die Toleranzen des Work Packages erhöhen und das Team nicht mehr ansprechen
❌ Das Thema dem Team allein überlassen, da Führung nur Aufgabenverteilung bedeutet
Zum People-Element gehören Führung, Motivation und Wohlbefinden. Überlastung gefährdet Qualität und Termine und ist daher auch ein Steuerungsthema.
Szenario Stakeholder [P] [People] 1 Unterseite →
☝️ Single Ein Projektteam diskutiert, wer als Stakeholder gilt. Welche Definition trifft in PRINCE2 zu?
✅ Jede Person oder Gruppe, die das Projekt beeinflussen kann oder davon betroffen ist
❌ Ausschließlich externe Kunden und Lieferanten außerhalb der eigenen Organisation
❌ Alle Personen, die im Projektplan namentlich als Teammitglied genannt werden
❌ Nur die Mitglieder des Project Boards sowie die Verantwortlichen der Assurance
Stakeholder sind alle, die ein Interesse haben, beeinflussen oder betroffen sind. Das People-Element verlangt, sie zu identifizieren, zu analysieren und gezielt einzubinden.
Szenario Fehlerkultur [P] [People] 1 Unterseite →
☝️ Single In einem Projekt werden Fehler aus Angst vor Schuldzuweisungen verschwiegen. Was sollte der Project Manager tun?
❌ Die Berichtspflichten verschärfen und zusätzliche Kontrollen einführen, um alles nachzuvollziehen
✅ Offene Fehler- und Lernkultur fördern, Probleme früh ansprechbar machen und mit gutem Beispiel vorangehen
❌ Nur noch Ergebnisberichte verlangen und keine Problemberichte mehr, um Konflikte zu vermeiden
❌ Fehler strenger sanktionieren und Verantwortliche benennen, damit Fehler seltener vorkommen
Manage by Exception und Learn from Experience setzen voraus, dass Probleme früh gemeldet werden. Das People-Element betont Vertrauen, Offenheit und Führung durch Vorbild.
Szenario Zusammenarbeit [P] [People] 1 Unterseite →
☝️ Single Zwei Lieferanten schieben sich bei einer Schnittstelle gegenseitig die Verantwortung zu. Was ist im Sinne des People-Elements der beste erste Schritt?
✅ Beide zusammenholen, gemeinsame Ziele und Schnittstellenverantwortung klären und eine Lösung vereinbaren
❌ Das Problem im Lessons Log notieren und abwarten, ob es sich von selbst löst und beruhigt
❌ Einen der beiden Lieferanten ohne weitere Klärung sofort vom Projekt ausschließen und ersetzen
❌ Sofort Vertragsstrafen androhen und die Zahlungen an beide Lieferanten einfrieren
Zusammenarbeit entsteht durch klare gemeinsame Ziele, definierte Schnittstellen und offene Kommunikation. Eskalation und Sanktionen sind erst der nächste Schritt, wenn Klärung scheitert.
Schlüsselkonzepte
Szenario Performance-Ziel Nachhaltigkeit [P] [Konzepte] 1 Unterseite →
☝️ Single SZENARIO 'SolarDach Rollout': Die GreenTech Solar AG (Senior Supplier, Geschaeftsfuehrerin Frau Yilmaz) installiert im Auftrag der LogiKon AG (Auftraggeber-Konzern) Photovoltaik-Anlagen auf 40 Logistikzentren. Executive ist Frau Dr. Berger (COO LogiKon), Senior User ist Herr Falk (Leiter Facility Management LogiKon, spaeterer Nutzer der Anlagen), Project Manager ist Herr Nowak, Team Manager Elektroinstallation ist Frau Lindqvist. Das Projekt ist in 4 Management-Stages gegliedert: IP, Pilotphase (5 Standorte), Rollout-Welle 1 (20 Standorte), Rollout-Welle 2 (15 Standorte) inkl. Abschluss. Toleranzen: Budget +/-5%, Zeit +/-2 Wochen je Stage. LogiKon moechte im Business Case auch den CO2-Effekt der Solaranlagen ueber die Laufzeit hinweg messbar nachhalten. Welchem PRINCE2-Performance-Ziel (Performance Target) entspricht das am ehesten?
❌ Scope.
✅ Sustainability.
❌ Quality.
❌ Benefits, weil CO2-Einsparung immer automatisch ein Benefit ist.
Szenario Management-Produkt Konfiguration [P] [Konzepte] 1 Unterseite →
☝️ Single SZENARIO 'Stadtarchiv Digitalisierung': Die Stadt Muenchen digitalisiert historische Archivbestaende. Executive ist Stadtkaemmerin Frau Dr. Vogel, Senior User ist Stadtarchivar Herr Brandt (spaeterer Nutzer der digitalen Bestaende), Senior Supplier ist Herr Ilic (Projektleiter bei ScanTech GmbH, dem beauftragten Dienstleister). Project Manager ist Frau Keller. Zwei Project-Assurance-Rollen sind benannt: die interne Revisionsstelle (Business Assurance) und der behoerdliche Datenschutzbeauftragte (User Assurance). Stages: Pilot (1.000 Dokumente), Hauptphase Welle 1 (Zeitungsarchiv), Welle 2 (Urkunden), Abschluss. Qualitaetskriterium: Scan-Aufloesung mind. 600dpi, Methode: Stichprobenpruefung von 5% der gescannten Dokumente. Frau Keller moechte fuer jedes digitalisierte Dokument nachvollziehen koennen, in welcher Version und welchem Bearbeitungs- status es sich aktuell befindet. Welches Konzept/Produkt nutzt sie dafuer?
❌ Die Project Initiation Documentation.
❌ Den Business Case.
❌ Das Highlight Report.
✅ Configuration Item Records.
Merksatz: Jedes Dokument braucht seinen „Bibliothekskatalog-Eintrag“: Version + Status = Configuration Item Record. Frau Keller führt das Register wie ein Archivar den Bestandskatalog.

Warum die anderen falsch sind:
  • PID: Gesamtprojekt-Baseline, kein Einzeldokument-Tracking.

  • Business Case: Nur Nutzen/Kosten/Risiko, kein Versionsstatus.

  • Highlight Report: Zeitraumbericht an Stakeholder, kein Item-Register.
Mini-Szenario Baseline vs. Record [P] [Konzepte] 1 Unterseite →
☝️ Single Ein Team erstellt sowohl eine freigegebene Versionsstands-PID als auch ein laufend aktualisiertes Risikoregister. Wie werden diese beiden Management Products jeweils kategorisiert?
✅ Die PID ist eine Baseline, das Risikoregister ist ein Record.
❌ Die PID ist ein Report, das Risikoregister eine Baseline.
❌ Beide sind Records.
❌ Beide sind Baselines.
Mini-Szenario Output Outcome Benefit [P] [Konzepte] 1 Unterseite →
☝️ Single Ein Projekt liefert eine neue Kundenservice-Software (Ergebnis der Lieferung). Dadurch arbeiten Mitarbeitende schneller (veraenderte Arbeitsweise), was langfristig geringere Bearbeitungskosten zur Folge hat. Ordnen Sie: Was ist hier der 'Benefit'?
✅ Die geringeren Bearbeitungskosten.
❌ Die schnellere Arbeitsweise der Mitarbeitenden allein, ohne Kostenbezug.
❌ Die Projektlaufzeit.
❌ Die neue Software selbst.
Mini-Szenario Sustainability Toleranz [P] [Konzepte] 1 Unterseite →
☝️ Single Ein Projekt legt fest: 'Der CO2-Ausstoss darf ueber die Projektlaufzeit 20 Tonnen nicht ueberschreiten.' Wofuer ist dies ein Beispiel?
❌ Eine Rollenbeschreibung.
❌ Eine Qualitaetsmethode.
❌ Ein Risiko im Risk Register.
✅ Eine Toleranzgrenze fuer das Performance-Ziel Sustainability.
Fallstudie Campus Nord [P] [Konzepte] 1 Unterseite →
☝️ Single FALLSTUDIE „Campus Nord“: Die Hochschule Rheinbach errichtet ein Lernzentrum mit Bibliothek (Neubau, Budget 8,5 Mio. €, davon 6 Mio. € Landesförderung; der Förderbescheid verlangt die Fertigstellung bis 31. Juli). Executive ist Kanzlerin Frau Dr. Weiß, Senior User Prof. Haas (Leiter der Bibliothek), Senior Supplier Herr Demir (Projektleiter der Demir Bau AG). Project Manager ist Herr Krüger; Frau Lenz unterstützt ihn als Project Support; das Hochschul-Controlling prüft unabhängig die Kostenentwicklung. Herr Voss (Bauleiter der Demir Bau AG) ist Team Manager. Fünf Stages: Planung & Genehmigung, Rohbau, Ausbau, Technik & Ausstattung, Abnahme & Übergabe. Stage-Toleranzen: Zeit ±4 Wochen, Kosten ±3 %. Ziel ist eine DGNB-Gold-Zertifizierung. Frage: Herr Krüger möchte das Ziel „DGNB Gold“ im Projekt verankern. Wie berücksichtigt PRINCE2 7 Nachhaltigkeit?
✅ Nachhaltigkeit ist ein eigenes Performance-Ziel und fließt in Business Case, Product Descriptions und Toleranzen ein
❌ Nachhaltigkeit betrifft nur den späteren Betrieb des Gebäudes, nicht die Durchführung des Projekts selbst
❌ PRINCE2 7 enthält dazu keine Vorgaben; es ist allein Sache des Bauunternehmens, Standards festzulegen
❌ Nachhaltigkeit wird ausschließlich über das Risk Register als mögliches Risiko für den Projekterfolg behandelt
In PRINCE2 7 ist Sustainability das siebte Performance-Ziel neben Nutzen, Risiko, Umfang, Zeit, Kosten und Qualität. Es kann mit Toleranzen versehen und in Business Case und Produktbeschreibungen konkretisiert werden.
Fallstudie PayLite [P] [Konzepte] 1 Unterseite →
☝️ Single FALLSTUDIE „PayLite“: Die FinBridge GmbH (Fintech, 60 Mitarbeitende) entwickelt die Zahlungs-App PayLite. Executive ist Frau Nguyen (CEO), Senior User Herr Baumann (Head of Customer Success), Senior Supplier Frau Dr. Lehmann (CTO). Project Manager ist Herr Weber. Die Entwicklung erfolgt durch zwei Scrum-Teams in Zwei-Wochen-Sprints; Product Owner ist Herr Jung. Das Projekt hat vier Stages von je etwa drei Monaten (Initiierung, MVP, Beta & Regulierung, Marktstart). Zeit und Kosten sind eng begrenzt, der Umfang ist priorisiert (Must/Should/Could). Für den Marktstart wird eine Erlaubnis der Aufsichtsbehörde benötigt. Frage: Das Entwicklungsteam fragt, wie Scrum-Sprints und PRINCE2-Stages zusammenpassen. Welche Aussage trifft zu?
✅ Sprints laufen innerhalb von Stages bzw. Work Packages; PRINCE2 liefert die Steuerung, Scrum die Art der Lieferung
❌ PRINCE2 und Scrum schließen sich aus; das Projekt muss sich für eine der beiden Methoden entscheiden
❌ Jeder Sprint ersetzt eine Stage, sodass das Project Board alle zwei Wochen über die Fortführung entscheidet
❌ Der Product Owner ersetzt das Project Board, da er den Umfang verantwortet und Prioritäten setzt
PRINCE2 ist ein Steuerungs- und Governance-Rahmen, Scrum ein Lieferansatz. Beide lassen sich kombinieren: Das Team arbeitet in Sprints, das Board steuert über Stages, Toleranzen und Business Case.
Zuordnung Nutzenkette PayLite [P] [Konzepte] 1 Unterseite →
matching FALLSTUDIE „PayLite“: Die FinBridge GmbH (Fintech, 60 Mitarbeitende) entwickelt die Zahlungs-App PayLite. Executive ist Frau Nguyen (CEO), Senior User Herr Baumann (Head of Customer Success), Senior Supplier Frau Dr. Lehmann (CTO). Project Manager ist Herr Weber. Die Entwicklung erfolgt durch zwei Scrum-Teams in Zwei-Wochen-Sprints; Product Owner ist Herr Jung. Das Projekt hat vier Stages von je etwa drei Monaten (Initiierung, MVP, Beta & Regulierung, Marktstart). Zeit und Kosten sind eng begrenzt, der Umfang ist priorisiert (Must/Should/Could). Für den Marktstart wird eine Erlaubnis der Aufsichtsbehörde benötigt. Frage: Ordnen Sie jedem Beispiel die passende Ebene der Nutzenkette zu.
Output = was geliefert wird; Outcome = Veränderung durch die Nutzung; Benefit = messbarer Vorteil für Stakeholder; Dis-Benefit = messbarer Nachteil, der als Folge entsteht.
Fallstudie GreenLine [P] [Konzepte] 1 Unterseite →
✌️ Multi FALLSTUDIE „GreenLine“: Die PackWerk AG (Verpackungshersteller, 900 Mitarbeitende) ersetzt am Hauptstandort eine Produktionslinie durch eine klimaneutrale Anlage (Investition 4,2 Mio. €, davon 30 % gefördert). Executive ist Herr Dr. Sommer (Werkleiter), Senior User Frau Idris (Leiterin Produktionsplanung), Senior Supplier Herr Rahn (Anlagenbauer ThermoTec). Project Manager ist Frau Vogt. Stages: Initiierung, Planung & Bestellung, Installation, Inbetriebnahme & Hochlauf. Ziele: CO₂-Ausstoß der Linie mindestens 35 % geringer, Energiekosten mindestens 22 % geringer, Produktionsausfall höchstens drei Tage. Der Betriebsrat begleitet das Projekt. Frage: Welche Aussagen zur Nachhaltigkeit im Projekt GreenLine sind zutreffend? (Mehrere richtig)
✅ Nachhaltigkeitsaspekte sind bei Entscheidungen zum Business Case zu berücksichtigen
✅ Nachhaltigkeit ist eines der Performance-Ziele, für das Toleranzen festgelegt werden können
❌ Für Nachhaltigkeit darf keine Toleranz definiert werden, da sie nicht messbar ist
✅ Die CO₂-Einsparung kann als Qualitätskriterium in Product Descriptions konkretisiert werden
❌ Nachhaltigkeit betrifft nur das Ergebnis, nicht die Art, wie das Projekt selbst durchgeführt wird
PRINCE2 7 behandelt Sustainability als Performance-Ziel: Sie betrifft sowohl das Projektergebnis als auch die Projektdurchführung, ist messbar und toleranzfähig und gehört in Business Case und Produktbeschreibungen.
Zuordnung Performance-Ziele GreenLine [P] [Konzepte] 1 Unterseite →
matching FALLSTUDIE „GreenLine“: Die PackWerk AG (Verpackungshersteller, 900 Mitarbeitende) ersetzt am Hauptstandort eine Produktionslinie durch eine klimaneutrale Anlage (Investition 4,2 Mio. €, davon 30 % gefördert). Executive ist Herr Dr. Sommer (Werkleiter), Senior User Frau Idris (Leiterin Produktionsplanung), Senior Supplier Herr Rahn (Anlagenbauer ThermoTec). Project Manager ist Frau Vogt. Stages: Initiierung, Planung & Bestellung, Installation, Inbetriebnahme & Hochlauf. Ziele: CO₂-Ausstoß der Linie mindestens 35 % geringer, Energiekosten mindestens 22 % geringer, Produktionsausfall höchstens drei Tage. Der Betriebsrat begleitet das Projekt. Frage: Ordnen Sie jeder Zielvorgabe das passende Performance-Ziel zu.
PRINCE2 7 kennt sieben Performance-Ziele: Nutzen, Risiko, Umfang, Zeit, Kosten, Qualität und Nachhaltigkeit. Die vier Vorgaben lassen sich jeweils eindeutig zuordnen.
Szenario Nutzenprüfung [P] [Konzepte] 1 Unterseite →
☝️ Single Sechs Monate nach Projektende soll geprüft werden, ob der erwartete Nutzen eingetreten ist. Das Project Board existiert dann nicht mehr. Wer verantwortet die Nutzenprüfung typischerweise?
❌ Der Project Manager als Teil seines Projektabschlusses, auch nach Auflösung des Boards
❌ Der Team Manager, der die Produkte geliefert hat, gemeinsam mit seinem Lieferanten
✅ Die Linien- bzw. Programmorganisation, an die die Benefit Reviews in CP übergeben wurden
❌ Das Project-Support-Team, das die Projektdokumente archiviert und verwaltet
Nutzen tritt oft erst nach Projektende ein. Die Verantwortung für Messung und Realisierung wird deshalb in CP an die Linien- bzw. Programmorganisation übergeben.
Szenario Performance-Ziele [P] [Konzepte] 1 Unterseite →
✌️ Multi Welche der folgenden gehören zu den Performance-Zielen in PRINCE2 7? (Mehrere richtig)
✅ Nutzen
✅ Nachhaltigkeit
❌ Lieferantenzufriedenheit
❌ Kommunikation
✅ Qualität
Die sieben Performance-Ziele sind Nutzen, Risiko, Umfang, Zeit, Kosten, Qualität und Nachhaltigkeit.
Keine Fragen gefunden