PRINCE2 Project Management Foundation (Version 7)

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

Fortlaufende geschäftliche Rechtfertigung — Jederzeit ein tragfähiger Business Case

Lernen aus Erfahrung — Lessons suchen, festhalten, anwenden

Definierte Rollen & Verantwortlichkeiten — Business-, User- und Supplier-Interessen vertreten

Steuern über Management-Phasen — Planen und kontrollieren Phase für Phase

Steuern nach dem Ausnahmeprinzip — Toleranzen setzen, nur bei Überschreitung eskalieren

Fokus auf Produkte — Produkte mit Qualitätskriterien vor der Aktivität

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

Business Case — Rechtfertigung und Nutzen

Organizing — Rollen und Verantwortlichkeiten

Plans — Produktbasierte Planung

Quality — Qualitätskriterien und -methoden

Risk — Risiken steuern, Risk Register

Issues — Change Control, Off-Specifications

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

Starting Up a Project (SU) — Lohnend und machbar?

Directing a Project (DP) — Steuerung durch das Project Board

Initiating a Project (IP) — Fundament und PID

Controlling a Stage (CS) — Tagesgeschäft des PM

Managing Product Delivery (MP) — Work Packages liefern

Managing a Stage Boundary (SB) — Phasenübergang planen

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

Prinzipien — Die 7 unverzichtbaren Leitsätze

People — Menschen — neu als eigenes Element in V7

Practices — Die 7 durchgängigen Aspekte (früher Themes)

Prozesse — Die 7 Schritte von SU bis CP

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

Executive — Trägt den Business Case, letzte Entscheidung

Senior User — Vertritt die Nutzer und den erwarteten Nutzen

Senior Supplier — Vertritt die Lieferseite und Ressourcen

Project Manager — Führt das Projekt im Tagesgeschäft

Team Manager — Verantwortet die Produkterstellung

Project Assurance — Unabhängige Prüfung im Auftrag des Boards

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 🔺 Foundation
455 Fragen 443 Single 12 Multi 0 Offen

Allgemein

Element Menschen [F] [Menschen] [Neu] 2 Unterseite →

☝️ Single Was ist eine Definition von Management (im Unterschied zu Leadership)?

❌ Menschen durch Überzeugung, Einbeziehung und Co-Kreation motivieren

✅ Anweisen der Ausführung von Aufgaben im Einklang mit vereinbarten Arbeitsweisen

❌ Sicherstellen, dass das Projekt am angestrebten Business-Nutzen ausgerichtet bleibt

❌ Gemeinsame Einstellungen, Werte und Ziele einer Gruppe prägen

Management bezeichnet das Anweisen und Steuern der Aufgabenausführung. Motivation durch Überzeugung und Co-Kreation beschreibt Leadership.

Merksatz:
Management macht Manuale: Manager weisen an und kontrollieren die vereinbarten Regeln, während Leader Menschen inspirieren und bewegen.

Warum die anderen falsch sind:
Menschen motivieren: Das ist Leadership, da es auf Inspiration und Co-Kreation statt auf reine Anweisung setzt.
Ausrichtung am Business-Nutzen: Dies beschreibt die übergeordnete Governance und Lenkung (Steering) des Projekts, nicht das operative Management.
Gemeinsame Werte prägen:* Das Gestalten der Kultur und gemeinsamer Werte ist eine klassische Leadership-Aufgabe, um Teams emotional zu binden.

☝️ Single Welcher Begriff bezeichnet die Zusammenarbeit mit wichtigen Einflussnehmern, damit vereinbarte Arbeitsweisen von allen Bereichen des Projektökosystems mitgetragen werden?

✅ Co-Kreation

❌ Governance

❌ Delegation

❌ Eskalation

Co-Kreation meint das gemeinsame Erarbeiten von Arbeitsweisen mit Einflussnehmern, um deren Akzeptanz im gesamten Projektökosystem sicherzustellen.

Merksatz:
Co-Kreation ist wie Co-working im Kreativ-Team: Nur wenn wir gemeinsam (Co) etwas erschaffen, tragen am Ende alle im Ökosystem die Arbeitsweisen freiwillig mit.

Governance ist falsch, da dies die offiziellen Regeln, Vorgaben und Kontrollstrukturen von oben herab beschreibt, nicht die partnerschaftliche Zusammenarbeit.
Delegation ist falsch, da hierbei Aufgaben und Befugnisse einseitig nach unten übertragen werden, statt gemeinsam auf Augenhöhe zu agieren.

Eskalation ist falsch, da dies das Weiterleiten von Problemen an eine höhere Managementebene bei Konflikten oder Grenzüberschreitungen ist.

Anpassen an das Projekt [F] [Grundlagen] [Neu] 2 Unterseite →

☝️ Single Was ist ein EXTERNER Faktor, der bei der Anpassung von PRINCE2 zu berücksichtigen ist?

❌ Die Handbücher der Organisation

❌ Der Umfang des Projekts

✅ Branchenstandards und regulatorische Vorgaben

❌ Der Risikograd des Projekts

Branchenstandards und regulatorische Vorgaben sind externe Faktoren; Handbücher, Umfang und Risikograd sind interne bzw. projektspezifische Faktoren.

Merksatz:
„Das Wetter kommt von außen“ – Genauso wie das Wetter sind Branchenstandards und Gesetze externe Umweltfaktoren, die von außen auf das Projekt einwirken und an die man sich anpassen muss, während alles andere im eigenen „Haus“ (Projekt/Organisation) liegt.

Handbücher der Organisation: Sind interne Faktoren, da sie direkt aus dem Inneren des eigenen Unternehmens stammen.
Der Umfang des Projekts: Ist ein projektspezifischer (interner) Faktor, der die Komplexität, aber nicht die externe Umwelt beschreibt.
Der Risikograd des Projekts:* Ist eine projektinterne Eigenschaft, die sich aus den spezifischen Aufgaben und dem Kontext des Projekts selbst ergibt.

☝️ Single Welcher der folgenden Aspekte gehört zu den sieben Aspekten der Projektleistung in PRINCE2 7 und war in der Vorgängerversion nicht als eigener Aspekt enthalten?

❌ Kosten

❌ Qualität

✅ Nachhaltigkeit

❌ Umfang

PRINCE2 7 ergänzt die Leistungsaspekte um „Nachhaltigkeit“ (neben Nutzen, Zeit, Kosten, Qualität, Umfang und Risiko).

Element Menschen [F] [Menschen] 6 Unterseite →

☝️ Single Was beschreibt Leadership in einem Projekt am treffendsten?

✅ Sie gelingt am besten durch Zusammenarbeit im Projektökosystem

❌ Sie ist die Anweisung zur Aufgabenausführung nach Vorgaben

❌ Sie ist eine Steuerung, die bei bestimmten Ereignissen greift

❌ Sie ist die Gesamtheit der Werte und Ziele des Projekts

Leadership entfaltet sich durch Zusammenarbeit und Einbeziehung im Projektökosystem; die letzte Option beschreibt Management.

Merksatz:
Echte Leader herrschen nicht einsam, sondern säen Kooperation im gesamten Projektgarten (Ökosystem), damit alle gemeinsam wachsen.

Warum die anderen falsch sind:

Anweisung zur Aufgabenausführung: Das ist reines, direktives Management (Befehl und Kontrolle), kein modernes Leadership.

Steuerung bei bestimmten Ereignissen: Dies beschreibt reaktives Eingreifen (Management by Exception) statt aktiver, motivierender Führung.

Gesamtheit der Werte und Ziele: Dies definiert die Projektkultur und -strategie, nicht das aktive Verhalten von Führungskräften.

☝️ Single Welche Aktivität ist KEIN Bestandteil von Leadership?

❌ Menschen motivieren, um Projektziele zu erreichen

❌ Regelmäßig Feedback einholen

✅ Anweisen der Aufgabenausführung gemäß vereinbarter Arbeitsweisen

❌ Stakeholder überzeugen und einbeziehen

Das reine Anweisen der Aufgabenausführung ist Management, nicht Leadership.

Merksatz:
Ein echter Leader bewegt Menschen (Motivation, Feedback, Überzeugen), während ein klassischer Manager nur stur anweist.

Warum die anderen falsch sind:
Menschen motivieren: Ist eine Kernaufgabe von Leadership, da Führung durch Inspiration und nicht durch reinen Zwang funktioniert.
Regelmäßig Feedback einholen: Gehört zwingend zu moderner Führung, um die Zusammenarbeit und das Vertrauen im Team kontinuierlich zu verbessern.

Stakeholder überzeugen und einbeziehen: Ist essenzieller Bestandteil von Leadership, da Führung auch das Beziehungsmanagement außerhalb des direkten Teams umfasst.

☝️ Single Warum ist Change Management (Veränderungsbegleitung) im Projekt wichtig?

❌ Damit die Qualitätskriterien definiert sind

❌ Damit die Risiken den Eigentümern zugeordnet sind

❌ Damit die Reihenfolge der Arbeitspakete feststeht

✅ Damit betroffene Bereiche die neuen Produkte annehmen und der Nutzen realisiert wird

Change Management sorgt dafür, dass Menschen die Veränderung mittragen, damit die erwarteten Nutzen realisiert werden.

Merksatz:
Change Management schlägt die Brücke vom gelieferten Produkt zum echten Nutzen: Nur wenn die Menschen das neue Werkzeug auch gerne annehmen und benutzen, wird das Projekt zum Erfolg.

Warum die anderen falsch sind:
Qualitätskriterien: Diese gehören zur Produktplanung (Praxis Qualität) und werden nicht durch Change Management definiert.
Risikoeigentümer: Die Zuweisung von Verantwortlichkeiten für Risiken ist Aufgabe der Praxis Risiko, nicht der Veränderungsbegleitung.

Reihenfolge der Arbeitspakete: Dies betrifft die reine Ablaufplanung und Terminierung (Praxis Pläne) und hat keinen Bezug zum menschlichen Wandel.

☝️ Single Welche Aussage über effektive Kommunikation im Projekt trifft zu?

❌ Remote-Teams brauchen meist weniger formelle Kommunikation

✅ Informationen sollten formatgerecht und zielgruppenorientiert bereitgestellt werden

❌ Widerständler werden in der Regel von selbst zu Befürwortern

❌ Regelmäßige Berichte allein sichern effektive Kommunikation

Effektive Kommunikation ist zielgruppenorientiert, bidirektional und passt Format und Kanal an die Empfänger an.

☝️ Single Worauf sollte sich Projektkommunikation vor allem konzentrieren?

❌ Auf möglichst häufige Fortschrittsberichte

❌ Auf ausschließlich formelle Kanäle

❌ Auf generische Botschaften, um Zeit zu sparen

✅ Auf Bereiche mit Widerstand gegen das Projekt

Kommunikation sollte gezielt dort ansetzen, wo Widerstand oder geringe Akzeptanz besteht.

Merksatz:
Wo es raucht, muss gelöscht werden: Erfolgreiche Projektkommunikation ist wie eine Feuerwehr – sie richtet ihren Fokus gezielt auf die Brandherde des Widerstands, statt wahllos Wasser zu verteilen.

Warum die anderen falsch sind:
Häufige Fortschrittsberichte: Erzeugen nur Informationsüberlastung („Spam“), statt echte Akzeptanz und Verständnis bei den Stakeholdern zu schaffen.
Ausschließlich formelle Kanäle: Ignorieren den wertvollen informellen Flurfunk, der für den Beziehungsaufbau und das Vertrauen im Team entscheidend ist.

Generische Botschaften: Verfehlen die individuellen Bedürfnisse der Stakeholder, da Kommunikation immer zielgruppenorientiert und maßgeschneidert sein muss.

☝️ Single Was wird als Prozess bezeichnet, bei dem Menschen zusammenarbeiten, um die Ziele des Projekts zu erreichen?

❌ Governance

✅ Zusammenarbeit

❌ Delegation

❌ Co-Kreation

Zusammenarbeit bezeichnet das gemeinsame Hinarbeiten auf die Projektziele; Co-Kreation ist das gemeinsame Erarbeiten von Arbeitsweisen.

Merksatz:
Zusammenarbeit ist das gemeinsame „An-einem-Strang-Ziehen“, um das Projektziel zu erreichen – Menschen arbeiten aktiv zusammen, um zu arbeiten.

Governance ist falsch, da dies der Rahmen aus Richtlinien und Entscheidungsstrukturen ist, nicht der aktive Arbeitsprozess selbst.
Delegation ist falsch, da dies nur das Übertragen von Aufgaben und Verantwortung von oben nach unten beschreibt.

Co-Kreation ist falsch, da dies ein spezieller, schöpferischer Prozess zur gemeinsamen Wertschöpfung mit Stakeholdern ist, nicht die allgemeine projektbezogene Zusammenarbeit.

Managementprodukte [F] [Managementprodukte] 7 Unterseite →

☝️ Single Welches Managementprodukt legt Projektumfang und Zeithorizont fest und wird vom Lenkungsausschuss genehmigt?

❌ Projektmandat

❌ Business Case

✅ Projektleitdokumentation

❌ Nutzenmanagement-Ansatz

Die Projektleitdokumentation (PID) bündelt u. a. Umfang und Zeithorizont und wird vom Lenkungsausschuss genehmigt.

Merksatz:
Die Projektleitdokumentation (PLD) ist das feste Fundament und Gesetzbuch des Projekts: Sie zementiert den Umfang und den Zeitrahmen, damit der Lenkungsausschuss mit seiner Unterschrift offiziell grünes Licht für den Bau geben kann.

Warum die anderen falsch sind:
Projektmandat: Ist nur der allererste, vage Auslöser von außerhalb des Projekts und noch kein genehmigtes Steuerungsdokument.
Business Case: Fokussiert sich auf die wirtschaftliche Tragfähigkeit (Kosten-Nutzen-Verhältnis) und definiert nicht den detaillierten Projektumfang.
Nutzenmanagement-Ansatz: Legt nur fest, wie und wann* der Nutzen gemessen wird, enthält aber weder den Projektumfang noch den Zeitplan.

☝️ Single Wie nennt PRINCE2 im Prozess „Vorbereiten eines Projekts“ das Dokument, das einem externen Lieferanten die grundlegenden Projektinformationen liefert?

✅ Projektkurzbeschreibung

❌ Arbeitspaket

❌ Projektansatz

❌ Projektmandat

Die Projektkurzbeschreibung (Project Brief) fasst die Grundinformationen zusammen und kann als Angebotsgrundlage dienen.

Merksatz:
Die Projektkurzbeschreibung ist wie ein kurzer, knackiger Steckbrief (Briefing), den du dem externen Lieferanten über den Zaun wirfst, damit er sofort weiß, worum es im Projekt geht.

Warum die anderen falsch sind:

Arbeitspaket: Wird erst viel später in der Phase „Managen der Produktlieferung“ für konkrete Aufgaben genutzt, nicht zum Start.

Projektansatz: Ist kein eigenständiges Dokument für Lieferanten, sondern beschreibt die strategische Methode zur Projektdurchführung.

Projektmandat: Ist der allererste, oft unvollständige Auslöser von außerhalb des Projekts, kein strukturiertes Informationsdokument für Lieferanten.

☝️ Single Welches Managementprodukt bietet dem Team am besten die Grundlage für das laufende Management des Gesamtprojekts?

❌ Projektplan

❌ Business Case

✅ Projektleitdokumentation

❌ Projektstatusbericht

Die Projektleitdokumentation ist die Referenz für das laufende Management des gesamten Projekts.

Merksatz:
Die Projektleitdokumentation (PID) ist das „Grundgesetz“ und Fundament des Projekts – sie schweißt alle Regeln, Pläne und Definitionen zu einer einzigen, stabilen Grundlage für das gesamte Management zusammen.

Warum die anderen falsch sind:
Projektplan: Ist nur ein Teilprodukt der PID und fokussiert sich rein auf Zeit und Ressourcen, nicht auf das gesamte Management.
Business Case: Liefert nur die wirtschaftliche Rechtfertigung, aber nicht die operative Grundlage für das laufende Projektmanagement.

Projektstatusbericht: Ist ein reines Informationswerkzeug für den Ist-Zustand und keine steuernde Managementgrundlage.

☝️ Single Welches Managementprodukt sollte der Projektmanager prüfen, um dem Lenkungsausschuss über den Status offener Issues zu berichten?

✅ Issueregister

❌ Teamstatusbericht

❌ Projektlogbuch

❌ Projektkurzbeschreibung

Das Issueregister enthält den Status aller erfassten Issues und dient als Grundlage der Berichterstattung.

Merksatz:
Das Issueregister ist deine offizielle „Mängelliste“: Wenn der Lenkungsausschuss nach dem Status offener Probleme (Issues) fragt, schlägst du genau dieses Register auf – denn nur hier stehen alle aktuellen Issues samt Status schwarz auf weiß.

Warum die anderen falsch sind:

Teamstatusbericht: Ist ein interner Bericht des Teammanagers an den Projektmanager, kein zentrales Register für den Lenkungsausschuss.

Projektlogbuch: Dient nur als informelles, internes Notizbuch des Projektmanagers für informelle Ereignisse und erste Ideen.

Projektkurzbeschreibung: Wird nur in der Vorbereitungsphase erstellt, um das Projekt zu definieren, und enthält keine laufenden Status-Updates.

☝️ Single Welches Managementprodukt sollte der Teammanager prüfen, um zu wissen, welche Produkte sein Team liefern soll?

❌ Projektproduktbeschreibung

❌ Projektplan

❌ Phasenplan

✅ Arbeitspaketbeschreibung

Die Arbeitspaketbeschreibung legt fest, welche Produkte das Team unter welchen Bedingungen liefert.

Merksatz:
Der Teammanager packt seine Koffer für die Arbeit: Er schaut nur in sein persönliches Arbeitspaket, um zu wissen, was sein Team abliefern muss.

Projektproduktbeschreibung: Falsch, weil sie das finale Gesamtprodukt des Kunden beschreibt, nicht die konkreten Aufgaben eines einzelnen Teams.
Projektplan: Falsch, weil er die grobe Roadmap für das gesamte Projekt auf Lenkungsausschuss-Ebene ist und keine operativen Team-Details enthält.

Phasenplan: Falsch, weil er die Steuerungsebene des Projektmanagers für eine gesamte Phase betrifft, während der Teammanager nur sein spezifisches Arbeitspaket steuert.

☝️ Single Welches Managementprodukt sollte der Projektmanager prüfen, um den Fortschritt eines einzelnen Arbeitspakets zu beurteilen?

❌ Produktbeschreibung

✅ Teamstatusbericht

❌ Projektstatusbericht

❌ Arbeitspaket

Der Teamstatusbericht (Checkpoint Report) meldet dem Projektmanager den Fortschritt eines Arbeitspakets.

Merksatz:
Der Teamstatusbericht ist das direkte Feedback des Teammanagers an den Projektmanager über den aktuellen Status eines einzelnen Arbeitspakets – wie ein wöchentliches Update-Telefonat direkt von der Baustelle.

Produktbeschreibung: Definiert nur die Qualitätsanforderungen eines zu liefernden Produkts, nicht den aktuellen Arbeitsfortschritt.
Projektstatusbericht: Richtet sich an den Lenkungsausschuss und fasst den Fortschritt des gesamten Projekts (oder einer Phase) zusammen, ist also viel zu grob.
Arbeitspaket: Ist der formelle Auftrag des Projektmanagers an* das Team, enthält aber selbst keine dynamischen Rückmeldungen über den aktuellen Fortschritt.

☝️ Single Welches Managementprodukt sollte den Hauptnutzen und die Qualitätserwartungen der Benutzer identifizieren?

❌ Produktbeschreibung

❌ Qualitätsregister

❌ Projektplan

✅ Projektproduktbeschreibung

Die Projektproduktbeschreibung enthält Hauptnutzen sowie die Qualitätserwartungen der Benutzer für das Projektprodukt.

Merksatz:
Die Projektproduktbeschreibung ist das „Super-Produkt“ ganz am Anfang: Sie beschreibt das gesamte Projektziel aus Sicht des Kunden, inklusive des Hauptnutzens und der globalen Qualitätsmaßstäbe.

Warum die anderen falsch sind:
Produktbeschreibung: Definiert nur ein einzelnes, spezifisches Teilprodukt innerhalb des Projekts, nicht das Gesamtergebnis und dessen Hauptnutzen.
Qualitätsregister: Ist ein dynamisches Protokoll zur Dokumentation durchgeführter Qualitätsaktivitäten, kein definierendes Anforderungsdokument.

Projektplan: Fokussiert sich auf Zeit, Ressourcen und Kosten der Umsetzung, nicht auf die inhaltliche Definition des Kundennutzens.

Anpassen an das Projekt [F] [Grundlagen] 7 Unterseite →

☝️ Single Was ist ein INTERNER Faktor, der bei der Anpassung von PRINCE2 zu berücksichtigen ist?

❌ Die Branchenstandards

❌ Die Sicherheitsvorschriften des Gesetzgebers

❌ Die umweltpolitischen Standards

✅ Die Verfahren und Handbücher der Organisation

Verfahren und Handbücher der eigenen Organisation sind interne Faktoren; Gesetze, Branchen- und Umweltstandards sind extern.

Merksatz:
„Mein Haus, meine Regeln“ – Interne Faktoren kommen immer direkt aus dem Inneren der eigenen Organisation (wie die eigenen Hausregeln, Verfahren und Handbücher), während Gesetze und Branchenstandards von außen übergestülpt werden.

Warum die anderen falsch sind:
Branchenstandards: Diese werden von externen Marktsegmenten vorgegeben, nicht von der eigenen Organisation.
Sicherheitsvorschriften des Gesetzgebers: Gesetze sind zwingende, externe Vorgaben des Staates.

Umweltpolitische Standards: Diese stellen gesellschaftliche oder staatliche Rahmenbedingungen von außen dar.

☝️ Single Was unterscheidet ein Projekt am ehesten vom Business as Usual (BAU)?

❌ Projekte sind grundsätzlich risikoärmer als BAU

✅ Jedes Projekt unterscheidet sich von früheren Vorhaben

❌ Projekte umfassen das laufende Management des Betriebs

❌ Projekte laufen dauerhaft weiter

Projekte sind einzigartig und befristet; BAU ist dauerhaft und wiederkehrend.

Merksatz:
Ein Projekt ist wie ein Prototyp – jedes Mal einzigartig und neu, während BAU das Fließband ist, das immer dasselbe tut.

Warum die anderen falsch sind:
Risikoärmer: Projekte bringen durch ihre Neuartigkeit naturgemäß mehr Unsicherheit und Risiko mit sich als der bekannte Routinebetrieb.
Laufendes Management des Betriebs: Dies beschreibt exakt die Definition von BAU, wohingegen Projekte temporäre Strukturen sind, um Veränderung herbeizuführen.

Dauerhaft weiterlaufen: Projekte sind per Definition zeitlich begrenzt (haben einen definierten Anfang und ein Ende) und laufen niemals endlos.

☝️ Single Welcher Begriff bezeichnet den materiellen oder immateriellen Liefergegenstand einer Aktivität?

✅ Output

❌ Plan

❌ Ergebnis

❌ Nutzen

Ein Output ist der konkrete Liefergegenstand; daraus entstehen Ergebnisse (Outcomes) und Nutzen.

Merksatz:
Der Output ist das, was am Ende der "Maschine" (Aktivität) physisch ausgespuckt wird – wie ein gedrucktes Buch oder eine fertige Software.

Warum die anderen falsch sind:
Plan: Ein Plan beschreibt nur den Weg (wie und wann), ist aber nicht das gelieferte Endprodukt selbst.
Ergebnis (Outcome): Das Ergebnis ist die durch den Output bewirkte Veränderung im Verhalten der Nutzer (z. B. schnelleres Arbeiten).

Nutzen (Benefit): Der Nutzen ist der messbare Vorteil für das Unternehmen (z. B. 20% Kostenersparnis), der erst durch das Ergebnis entsteht.

☝️ Single Was ist ein Lieferansatz, bei dem der nächste Schritt erst nach Abschluss des vorherigen beginnt und das Produkt am Projektende bereitsteht?

❌ Iterativ-inkrementell

✅ Linear-sequenziell

❌ Ereignisgesteuert

❌ Hybrid

Der linear-sequenzielle Ansatz durchläuft die Schritte einmalig nacheinander; das Endprodukt steht am Schluss bereit.

Merksatz:
„Die Domino-Schlange fällt in einer geraden Linie“ – Bei Linear-sequenziell folgt eine Phase stur nach der anderen (wie eine Perlenkette), und das fertige Gesamtprodukt gibt es erst ganz am Schluss.

Iterativ-inkrementell ist falsch, da hier Produkte in wiederkehrenden Schleifen schrittweise aufgebaut und oft schon vorab in Teilen geliefert werden.
Ereignisgesteuert ist falsch, da dies ein Steuerungsmechanismus für Entscheidungen (durch Ereignisse wie Abweichungen) ist, kein Lieferansatz für die Produkterstellung.

Hybrid ist falsch, da es eine Mischung aus verschiedenen Ansätzen (z. B. agil und klassisch) beschreibt und nicht das rein nacheinander folgende Vorgehen.

☝️ Single Welcher Lieferansatz wiederholt Anforderungserhebung, Erstellung und Test mehrfach, um das Produkt schrittweise zu verbessern?

✅ Iterativ-inkrementell

❌ Hybrid

❌ Zeitbasiert

❌ Linear-sequenziell

Der iterativ-inkrementelle Ansatz wiederholt die Schritte in mehreren Iterationen und verbessert das Produkt schrittweise.

Merksatz:
Stell dir ein Karussell (Iterativ) vor, das sich im Kreis dreht (Wiederholung von Erhebung, Bau, Test), während bei jeder Runde ein neues Puzzleteil (Inkrement) hinzugefügt wird, bis das Bild perfekt ist.

Warum die anderen falsch sind:
Hybrid: Ist eine Mischform (z. B. agil + klassisch), beschreibt aber nicht den spezifischen, sich wiederholenden Verbesserungszyklus selbst.
Zeitbasiert: Fokussiert sich auf feste Zeitfenster (Timeboxen) und nicht auf den inhaltlichen Ablauf von Feedbackschleifen.

Linear-sequenziell: Folgt einer starren Einbahnstraße (wie das Wasserfallmodell), bei der Phasen nacheinander ablaufen und nicht wiederholt werden.

☝️ Single Welches Merkmal eines Projekts beschreibt die Zusammenarbeit von Teams aus verschiedenen Organisationen oder Bereichen?

❌ Befristet

❌ Änderung

❌ Einzigartig

✅ Bereichsübergreifend

„Bereichsübergreifend“ meint die Zusammenarbeit über Bereichs- oder Organisationsgrenzen hinweg.

☝️ Single Was ist die Definition eines Stakeholders?

❌ Die für die Gesamtlenkung verantwortliche Person

❌ Jemand, der eine Risikomaßnahme umsetzt

❌ Eine unabhängige Prüfperson für Produkte

✅ Eine Person, die das Projekt beeinflussen oder von ihm beeinflusst werden kann

Ein Stakeholder ist jede Person/Gruppe, die das Projekt beeinflussen kann oder von ihm betroffen ist.

Merksatz:
Ein Stakeholder ist wie ein Zuschauer im Stadion, der das Spiel durch lautes Rufen beeinflusst oder von einem herumfliegenden Ball getroffen (beeinflusst) wird.

Warum die anderen falsch sind:
Gesamtlenkung: Das beschreibt die Rolle des Projektauftraggebers (Sponsor) oder Lenkungsausschusses, nicht die Gesamtheit aller Stakeholder.
Risikomaßnahme: Dies ist die Definition des Risikoverantwortlichen (Risk Owner) oder Maßnahmeverantwortlichen (Risk Actionee).

Unabhängige Prüfperson: Das beschreibt die Rolle der Projektsicherung (Project Assurance) oder eines externen Qualitätsprüfers.

Die 7 Practices

Business Case Zweck [F] [Practices] 1 Unterseite →

☝️ Single Welche Frage beantwortet die Practice "Business Case" durchgängig?

❌ Ob das Projekt über den gesamten Lebenszyklus hinweg die erwarteten Kosten und den Zeitplan einhält

✅ Ob das Projekt weiterhin wünschenswert, machbar und erreichbar ist

❌ Ob die im Projektmanagementplan festgelegten Meilensteine und Liefertermine eingehalten werden

❌ Ob die im Projektauftrag definierten Rollen und Verantwortlichkeiten klar zugewiesen sind

Ob das Projekt weiterhin wünschenswert, machbar und erreichbar ist ("Lohnt es sich noch?").

Merksatz:
Der Business Case ist der TÜV des Projekts: Er prüft durchgängig, ob die Fahrt noch wünschenswert (Lohnt es sich?), machbar (Haben wir Sprit?) und erreichbar (Kommen wir an?) ist.

Warum die anderen falsch sind:
A: Risikodokumentation ist Aufgabe des Risikomanagements, nicht der Wirtschaftlichkeitsprüfung.
C: Qualitätskriterien werden im Qualitätsmanagement definiert, um Produktstandards zu sichern.

D: Die Teamzusammensetzung regelt die Ressourcenplanung und nicht die Sinnhaftigkeit des Projekts.

Business Case Verantwortung [F] [Practices] 1 Unterseite →

☝️ Single Wer trägt laut PRINCE2 die Gesamtverantwortung für den Business Case?

❌ Der Senior Supplier

❌ Das gesamte Team ohne klare Zuordnung

✅ Der Executive

❌ Der Projektmanager

Der Executive (Mitglied des Project Board).

Merksatz:
Der Executive ist der "Chef-Entscheider" – er sitzt auf dem Geldbeutel (Business Case) und bürgt als alleiniger Eigentümer für den wirtschaftlichen Erfolg.

Warum die anderen falsch sind:
A) Senior Supplier: Er vertritt nur die Lieferantenseite und sichert die technische Machbarkeit, nicht den geschäftlichen Nutzen.
B) Das gesamte Team: Ohne klare Zuordnung scheitert jedes Projekt; PRINCE2 fordert eindeutige, personifizierte Verantwortlichkeiten.

D) Project Manager: Er managt das Projekt nur operativ im Alltag, darf aber nicht über den finalen wirtschaftlichen Sinn entscheiden.

Organizing Kernidee [F] [Practices] 1 Unterseite →

☝️ Single Was ist der Kernzweck der Practice "Organizing" (vorher "Organization")?

❌ Eine vollständige Dokumentation aller Projektabläufe und Arbeitsprozesse zu erstellen

❌ Die Verteilung von Projektressourcen auf verschiedene Standorte zu koordinieren

✅ Eine klare Projektstruktur mit definierten Rollen zu schaffen

❌ Die Einhaltung gesetzlicher Vorschriften und externer Standards sicherzustellen

Klare Projektstruktur mit definierten Rollen und Verantwortlichkeiten zu schaffen.

Merksatz: Stell dir ein Fußballteam vor: „Organizing“ verteilt die Trikots (Rollen) und stellt die Spieler auf das Spielfeld (Projektstruktur), damit jeder weiß, was er zu tun hat.

Warum die anderen falsch sind:
A: Reduziert die Projektorganisation fälschlicherweise auf reine Büroarbeit und Verwaltung.
B: Verwechselt die personelle Teamstruktur mit der technischen IT-Systemarchitektur.

D: Gehört inhaltlich zur Practice „Finance“ und nicht zur Organisation.

Project Board Zusammensetzung [F] [Practices] 1 Unterseite →

☝️ Single Aus welchen drei Rollen besteht das Lenkungsausschuss mindestens?

❌ CEO, CFO, CTO

✅ Executive, Senior User, Senior Supplier

❌ Sponsor, Kunde, Lieferant (identisch mit ITIL-Rollen)

❌ Projektmanager, Teammanager, Project Support

Executive, Senior User, Senior Supplier.

Merksatz: Der Chef (Executive) lenkt, der Nutzer (Senior User) wünscht, der Lieferant (Senior Supplier) liefert – dieses englische Trio bildet das Board.

Warum die anderen falsch sind:
A) C-Level-Manager leiten das Gesamtunternehmen, nicht standardmäßig jedes einzelne Projekt.
C) Dies sind allgemeine Geschäftsbeziehungen und keine spezifisch definierten PM-Lenkungsausschuss-Rollen.

D) Diese Rollen steuern und unterstützen das Projekt operativ, statt es strategisch zu lenken.

Executive Rolle [F] [Practices] 1 Unterseite →

☝️ Single Was ist die Kernverantwortung des "Executive" im Lenkungsausschuss?

❌ Der Executive trägt die alleinige Verantwortung für die Auswahl und Steuerung aller Lieferanten und deren Verträge im Projekt.

❌ Der Executive ist ausschließlich dafür zuständig, die Interessen und Anforderungen der späteren Nutzer im Projekt zu vertreten.

❌ Der Executive übernimmt die vollständige Verantwortung für die technische Umsetzung und die Qualität der Projektergebnisse.

✅ Gesamtverantwortung für das Projekt und den Business Case

Gesamtverantwortung für das Projekt, insbesondere Sicherstellung des Business Case.

Merksatz:
Der Executive ist der Boss im Boot – er trägt die Gesamtverantwortung für das Projekt und hält die Geldbörse (Business Case) fest in der Hand, während andere nur rudern.

Warum die anderen falsch sind:
Ausschließlich Lieferantensteuerung: Dies ist die Rolle des Senior Supplier, der die Ressourcen und die technische Qualität sichert.
Ausschließlich Nutzerinteressen: Dafür ist der Senior User zuständig, der den Nutzen für die Anwender vertritt.
Ausschließlich technische Umsetzung: Dies liegt im Aufgabenbereich der Spezialisten und des Senior Supplier*, nicht beim Auftraggeber (Executive).

Senior User Rolle [F] [Practices] 1 Unterseite →

☝️ Single Wofür steht die Rolle "Senior User" im Lenkungsausschuss?

❌ Übernimmt die Rolle des Projektmanagers und steuert das Tagesgeschäft des Projekts

✅ Vertritt die Interessen der künftigen Nutzenden des Ergebnisses

❌ Besitzt die alleinige finanzielle Verantwortung und genehmigt sämtliche Projektbudgets

❌ Setzt sich ausschließlich für die Interessen der Lieferanten und externen Anbieter ein

Vertritt die Interessen derjenigen, die das Projektergebnis später nutzen werden.

Merksatz:
Der Senior User ist der Anwalt der Nutzer – stell dir einen erfahrenen ("Senior") Kunden vor, der lautstark die Wünsche der späteren Anwender einfordert.

Warum die anderen falsch sind:
A: Der Project Manager leitet das Projekt operativ, während der Senior User im übergeordneten Lenkungsausschuss (Project Board) sitzt.
C: Die finanzielle Verantwortung trägt der Projektauftraggeber (Executive/Sponsor), nicht der Nutzervertreter.

D: Für die Lieferanten gibt es eine eigene Rolle im Board, den "Senior Supplier".

Senior Supplier Rolle [F] [Practices] 1 Unterseite →

☝️ Single Wofür steht die Rolle "Senior Supplier" im Lenkungsausschuss?

❌ Übernimmt die vollständige Verantwortung für alle Entscheidungen des Lenkungsausschusss und ist dem Executive direkt unterstellt

❌ Vertritt ausschließlich die Interessen der späteren Anwender:innen des Projektprodukts und hat kein Mitspracherecht bei der Ressourcenbereitstellung

❌ Ist allein für die finanzielle Steuerung des Projekts zuständig und legt das Budget ohne Abstimmung mit anderen Board-Mitgliedern fest

✅ Vertritt die Interessen der Liefernden von Ressourcen/Fachwissen

Vertritt die Interessen derjenigen, die Ressourcen/Fachwissen für die Umsetzung bereitstellen.

Merksatz:
Der Supplier ist der Lieferant, der den Einkaufswagen des Projekts mit Ressourcen und Fachwissen belädt – ohne seine Waren gibt es kein Produkt.

Warum die anderen falsch sind:
A: Verwechselt den Lieferanten mit dem übergeordneten Auftraggeber (Executive).
B: Verwechselt die Lieferseite mit den tatsächlichen Anwendern (Senior User).

C: Verkennt, dass die Budgethoheit allein beim Executive liegt.

Project Manager Rolle [F] [Practices] 1 Unterseite →

☝️ Single Was ist die Kernaufgabe des "Projektmanager" bei PRINCE2?

✅ Das Tagesgeschäft im Rahmen gesetzter Toleranzen steuern

❌ Die langfristige Projektstrategie eigenverantwortlich festlegen und umsetzen

❌ Als stimmberechtigtes Mitglied des Projektausschusses alle Entscheidungen treffen

❌ Die Rolle des Projektauftraggebers vollständig übernehmen und dessen Aufgaben ausführen

Das Tagesgeschäft des Projekts im Rahmen der vom Project Board gesetzten Toleranzen steuern.

Merksatz:
Der Project Manager ist der Kapitän im Alltag: Er steuert das Schiff täglich im sicheren Fahrwasser der vorgegebenen Toleranzen – weicht er ab, entscheidet der Lenkungsausschuss.

Warum die anderen falsch sind:
B: Strategische Entscheidungen trifft allein der Lenkungsausschuss (Project Board).
C: Der Project Manager berichtet an das Board, ist aber selbst kein stimmberechtigtes Mitglied.

D: Der Executive ist der Auftraggeber und bleibt die oberste, nicht ersetzbare Instanz.

Plans Kernidee [F] [Practices] 1 Unterseite →

☝️ Single Was ist der Kerngedanke der Practice "Plans"?

❌ Die Planung erfolgt in PRINCE2 durch reine Aktivitätenplanung, bei der die Reihenfolge der Schritte im Vordergrund steht

❌ Ein einmal erstellter Plan bleibt während des gesamten Projekts unverändert und wird nicht angepasst

✅ Produktbasierte Planung ausgehend von den zu liefernden Produkten

❌ PRINCE2 sieht für jedes Projekt nur einen einzigen umfassenden Gesamtplan vor, der alle Ebenen abdeckt

Produktbasierte Planung — Pläne werden von den zu liefernden Produkten her entwickelt, nicht nur von Aktivitäten.

Merksatz: Erst das fertige Haus visualisieren, dann die Steine stapeln – PRINCE2 plant immer produktbasiert vom konkreten Ergebnis her, nicht von der Aktivität.

Warum die anderen falsch sind:
A) Aktivitäten werden erst nach der Definition der Produkte abgeleitet, nicht umgekehrt.
B) Pläne sind dynamische Steuerungsinstrumente, die bei Änderungen laufend aktualisiert werden müssen.

D) PRINCE2 nutzt eine dreistufige Planhierarchie (Projekt-, Phasen- und Teampläne) statt nur eines einzigen Plans.

Planebenen [F] [Practices] 1 Unterseite →

☝️ Single Auf welchen unterschiedlichen Ebenen kann bei PRINCE2 geplant werden?

✅ Projekt-, Stage- und Teamebene

❌ Nur auf Unternehmensebene

❌ Ausschließlich auf Tagesebene

❌ Nur auf einer einzigen Gesamtebene

Typischerweise Projekt-, Stage- und Teamebene — je nach Detailgrad und Adressat.

Merksatz: Ein Prinz (PRINCE2) plant dreistufig: die große Reise (Projekt), die nächste Etappe (Stage) und die Aufgaben für seine Gefährten (Team).

Warum die anderen falsch sind:
B) Übersieht, dass PRINCE2 ein Projekt- und kein reines Unternehmens-Framework ist.
C) Verwechselt operatives Daily-Scrum mit der strukturierten PRINCE2-Phasenplanung.

D) Ignoriert das PRINCE2-Prinzip der "Steuerung über Managementphasen" (Stages).

Quality Kernidee [F] [Practices] 1 Unterseite →

☝️ Single Was ist der Kernzweck der Practice "Quality"?

✅ Sicherstellen, dass Produkte vereinbarte Qualitätsanforderungen erfüllen

❌ Sicherstellen, dass alle Projekte unabhängig von ihrer Größe denselben festgelegten Qualitätsstandard einhalten

❌ Sicherstellen, dass Qualitätsprüfungen ausschließlich am Projektende durchgeführt werden, um Zeit zu sparen

❌ Sicherstellen, dass Qualitätsabweichungen ohne formale Dokumentation direkt im Team behoben werden

Sicherzustellen, dass die Produkte den vereinbarten Qualitätsanforderungen entsprechen und dies überprüfbar ist.

Merksatz:
Die Qualität ist der "Vertrags-Wächter": Sie sorgt dafür, dass das Produkt am Ende genau das hält, was vorher schriftlich vereinbart wurde – kein "Passt-schon", sondern exakte Vertragserfüllung.

Warum die anderen falsch sind:
Kosten niedrig halten: Dies ist primär Aufgabe der Practice "Fortschritt" (Progress) und des Business Cases, nicht der Qualität.
Ausschließlich Terminplanung: Termine werden über Pläne und die Practice "Fortschritt" gesteuert, nicht durch Qualitätsmerkmale.

Qualität zweitrangig: Qualität ist eine der sechs zentralen Projekttoleranzen in PRINCE2 und niemals zweitrangig.

Qualitätskriterien vs. Qualitätsmethoden [F] [Practices] 1 Unterseite →

☝️ Single Was unterscheidet "Qualitätskriterien" von "Qualitätsmethoden"?

❌ Qualitätskriterien legen die Prioritäten fest, während Qualitätsmethoden nur die Reihenfolge der Prüfschritte bestimmen

✅ Kriterien beschreiben WAS erfüllt sein muss, Methoden beschreiben WIE geprüft wird

❌ Qualitätskriterien werden nur für die Planungsphase verwendet, Qualitätsmethoden nur für die Umsetzungsphase

❌ Qualitätskriterien sind die Grundlage für die Messung, Qualitätsmethoden dienen ausschließlich der Dokumentation

Qualitätskriterien beschreiben WAS erfüllt sein muss, Qualitätsmethoden beschreiben WIE die Erfüllung geprüft wird.

Merksatz:
Das Kriterium bestimmt das Kompassziel (WAS erreicht sein muss), die Methode den Messweg (WIE es geprüft wird).

Warum die anderen falsch sind:
A: Eine Priorisierung ist falsch, da beide Elemente im Qualitätsmanagement gleichwertig ineinandergreifen.
C: Diese Einschränkung ist zu eng, da beide Begriffe universell für alle Projektergebnisse gelten.

D: Die Gleichsetzung ignoriert den fundamentalen Unterschied zwischen der Zieldefinition (Kriterium) und dem Prüfverfahren (Methode).

Risk Kernidee [F] [Practices] 1 Unterseite →

☝️ Single Was ist der Kernzweck der Practice "Risk"?

❌ Risiken ausschließlich nach Abschluss des Projekts zu analysieren und zu bewerten

✅ Risiken systematisch identifizieren, bewerten und steuern

❌ Sämtliche Risiken im Projektverlauf vollständig zu beseitigen und auszuschließen

❌ Nur finanzielle Risiken für das Projektbudget systematisch zu erfassen und zu überwachen

Risiken systematisch zu identifizieren, zu bewerten und angemessen zu steuern.

Merksatz:
Stell dir Risikomanagement wie das Radar eines Schiffes vor: Gefahren frühzeitig erkennen (identifizieren), ihre Größe einschätzen (bewerten) und aktiv ausweichen (steuern) – das ist der dreistufige Dauerlauf für ein sicheres Projekt.

Warum die anderen falsch sind:
A: ...ist ein fataler Spätstart, da Risiken das laufende Projekt bedrohen und nicht erst die Nachbereitung.
C: ...ist eine Illusion, da absolute Risikofreiheit im Projektgeschäft unmöglich und unbezahlbar ist.

D: ...ist ein gefährlicher Tunnelblick, der terminliche, personelle oder technische Gefahren komplett übersieht.

Risikostrategien [F] [Practices] 1 Unterseite →

☝️ Single Welche der folgenden ist KEINE klassische Strategie im Umgang mit einem negativen Risiko (Bedrohung)?

❌ Transfer (übertragen)

✅ Exploit (nutzen)

❌ Avoid (vermeiden)

❌ Reduce (reduzieren)

Exploit ist eine Strategie für positive Risiken (Chancen), nicht für Bedrohungen.

Merksatz:
Wer eine Bedrohung ausnutzt (Exploit), verwechselt Gefahr mit Chance – man „nutzt“ nur positive Risiken, während man negative Risiken wie heiße Kartoffeln meidet, überträgt oder verkleinert.

Transfer (übertragen): Ist falsch, weil man eine Bedrohung real an Dritte (z. B. Versicherungen) abgeben kann.
Avoid (vermeiden): Ist falsch, weil das komplette Umgehen der Gefahr (z. B. durch Planänderung) eine Standardreaktion auf Bedrohungen ist.

Reduce (reduzieren): Ist falsch, weil die Senkung von Wahrscheinlichkeit oder Auswirkung die typischste Maßnahme gegen negative Risiken darstellt.

Issues Kernidee [F] [Practices] 1 Unterseite →

☝️ Single Was deckt die Practice "Issues" (vorher "Change") ab?

❌ Behandlung von ausschließlich technischen Störungen und Softwarefehlern im Projekt

✅ Umgang mit unerwarteten Ereignissen, Änderungswünschen und Abweichungen

❌ Fokussierung ausschließlich auf personelle Angelegenheiten und Teamkonflikte

❌ Betrachtung von Issues nur in der Abschlussphase des Projekts

Den Umgang mit unerwarteten Ereignissen, Änderungswünschen und Abweichungen während des Projekts.

Merksatz: Stell dir ein "Issue-Taschentuch" vor, mit dem du unerwartete Flecken (Ereignisse), Falten (Abweichungen) und neue Wünsche im gesamten Projektverlauf flexibel wegwischst.

Warum die anderen falsch sind:

A: Zu eng gedacht, da IT-Bugs nur ein winziger Teilbereich von Projektproblemen sind.

C: Falscher Fokus, da Teamkonflikte und Personalressourcen in andere Practices gehören.

D: Denkfehler, weil ungeplante Ereignisse und Änderungen von Tag eins an auftreten können.

Issue-Arten [F] [Practices] 1 Unterseite →

☝️ Single Welche Arten von Issues unterscheidet PRINCE2 typischerweise?

✅ Request for Change, Off-Specification, allgemeine Problem/Concern-Issues

❌ PRINCE2 unterscheidet ausschließlich technische und finanzielle Issues, da nur diese beiden Kategorien für die Steuerung eines Projekts relevant sind.

❌ PRINCE2 kennt nur eine einzige, undifferenzierte Issue-Art, die alle Probleme unabhängig von ihrer Herkunft oder Auswirkung zusammenfasst.

❌ PRINCE2 sieht keine Kategorisierung von Issues vor, sondern behandelt sämtliche Abweichungen und Anliegen als einheitliche Meldungen ohne weitere Unterscheidung.

Request for Change, Off-Specification und allgemeine Problem/Concern-Issues.

Merksatz:
Ein Issue-Trio regelt das Chaos: Der „Request for Change“ will etwas Neues, die „Off-Specification“ weicht vom Plan ab und das „Problem/Concern“ drückt allgemein der Schuh.

Warum die anderen falsch sind:
Ausschließlich technische und finanzielle Issues: PRINCE2 denkt ganzheitlich und schränkt Issues nicht auf diese zwei spezifischen Fachbereiche ein.
Nur eine einzige, undifferenzierte Issue-Art: Ohne Unterscheidung könnte man nicht gezielt steuern, ob etwas geändert, repariert oder gelöst werden muss.

Issues werden bei PRINCE2 nicht kategorisiert: Falsch, denn die strukturierte Einteilung in die drei Standard-Kategorien ist essenziell für den kontrollierten Change-Prozess.

Progress Kernidee [F] [Practices] 1 Unterseite →

☝️ Single Was ist der Kernzweck der Practice "Progress"?

❌ Der Kernzweck der Practice Progress liegt in der kontinuierlichen Erfassung und Auswertung der Teamzufriedenheit, um daraus direkte Maßnahmen zur Verbesserung des Arbeitsklimas abzuleiten.

✅ Fortschritt mit Plan vergleichen und Entscheidungsgrundlagen liefern

❌ Die Practice Progress entfaltet ihre volle Wirkung erst in der Abschlussphase des Projekts, wenn alle Ergebnisse vorliegen und der Gesamterfolg abschließend bewertet werden kann.

❌ Die systematische Verfolgung des Fortschritts erfolgt bei PRINCE2 nur auf Wunsch des Auftraggebers und ist kein fester Bestandteil der Methodik.

Den tatsächlichen Fortschritt mit dem Plan zu vergleichen und Entscheidungsgrundlagen für das Project Board zu liefern.

Merksatz:
„Progress ist das Navi des Projekts: Es vergleicht IST mit SOLL (Plan) und zeigt dem Lenkungsausschuss, ob wir auf Kurs sind oder abbiegen müssen.“

Warum die anderen falsch sind:
Team-Stimmung messen: Das ist zu kurz gegriffen, da Progress harte Fakten (Zeit, Kosten, Toleranzen) überwacht und nicht nur weiche Faktoren.
Nur am Projektende relevant: Fortschrittskontrolle muss kontinuierlich in jeder Phase stattfinden, um rechtzeitig gegensteuern zu können.

Nicht systematisch verfolgt: PRINCE2 fordert durch Toleranzen und Berichte ein extrem strukturiertes, systematisches Fortschrittsmanagement.

Highlight Report [F] [Practices] 1 Unterseite →

☝️ Single Wofür wird ein "Projektstatusbericht" typischerweise genutzt?

❌ Detaillierte Leistungsbeschreibungen zur Steuerung der externen Zusammenarbeit mit Dienstleistern

❌ Zusammenfassende Darstellung aller Projektergebnisse zur offiziellen Beendigung des Vorhabens

❌ Umfassende technische Vorgaben zur Umsetzung der geforderten Projektfunktionalitäten

✅ Regelmäßige Fortschrittsberichte an das Lenkungsausschuss

Regelmäßige, zusammenfassende Fortschrittsberichte des Project Manager an das Project Board.

Merksatz: Der Highlight-Report wirft regelmäßig ein Scheinwerferlicht auf den aktuellen Projektfortschritt, damit das Project Board nie im Dunkeln tappt.

Warum die anderen falsch sind:
A: Verträge regeln rechtliche Beziehungen mit Externen und sind keine internen Status-Updates.
B: Für das Projektende gibt es den Abschlussbericht, während der Highlight-Report zyklisch berichtet.

C: Technische Details gehören in Spezifikationen, nicht in einen kurzen Management-Bericht.

7 Practices korrekt benennen [F] [Practices] 1 Unterseite →

✌️ Multi Welche der folgenden gehören zu den 7 Practices? (Mehrfachauswahl)

✅ Issues

✅ Organizing

❌ Continuous Delivery

✅ Business Case

Merksatz:
Ein Manager im schicken Business-Anzug organisiert seine brennenden Probleme (Issues) strukturiert im Aktenkoffer.

Warum die anderen falsch sind:

C) Continuous Delivery: Ist ein agiler Software-Auslieferungsprozess (DevOps) und keine der sieben universellen Projektmanagement-Praktiken.

Themes zu Practices Umbenennung [F] [Practices] 1 Unterseite →

✌️ Multi Welche Umbenennungen fanden zwischen 6. und 7. Edition statt? (Mehrfachauswahl)

✅ Themes → Practices

✅ Change → Issues

✅ Organization → Organizing

❌ Risk → Opportunity

Merksatz:
In der 7. Edition werden passive Themen zu aktiven Praktiken (A): Wir organisieren (C) jetzt aktiv und lösen konkrete Probleme (B/Issues), statt nur Veränderungen zu verwalten.

Warum die anderen falsch sind:

D) Risk → Opportunity: Ein typischer Denkfehler, da Chancen zwar Teil des Risikomanagements sind, die Praxis aber weiterhin schlicht „Risk“ heißt.

Business Case über Projektlaufzeit [F] [Practices] 1 Unterseite →

☝️ Single Wie sollte das Lenkungsausschuss reagieren, wenn der Business Case während der Laufzeit nicht mehr tragfähig ist?

✅ Das Projekt anpassen oder vorzeitig beenden

❌ Das Projekt unverändert bis zum Ende fortsetzen

❌ Den Business Case nur noch einmal am Projektende prüfen

❌ Die Verantwortung vollständig an den Teammanager übertragen

Bei nicht mehr tragfähigem Business Case muss das Project Board das Projekt anpassen oder vorzeitig beenden (Continued Business Justification).

Merksatz:
Ein totes Pferd reitet man nicht weiter: Ist der Business Case im Eimer, zieht das Project Board sofort die Reißleine (beenden) oder baut den Sattel um (anpassen).

Warum die anderen falsch sind:
B) Ignoriert den absehbaren Misserfolg und verbrennt sehenden Auges wertvolle Ressourcen.
C) Verschiebt die nötige Kontrolle auf einen Zeitpunkt, an dem das Geld bereits unwiderruflich verloren ist.

D) Schiebt die strategische Lenkungsverantwortung des Boards fälschlicherweise auf die rein operative Ebene ab.

Rollen im eigenen Projekt zuordnen [F] [Practices] 1 Unterseite →

✌️ Multi Welche Aussagen zur Besetzung des Lenkungsausschuss sind korrekt? (Mehrfachauswahl)

✅ Der Executive vertritt das Business-Interesse

✅ Der Senior User vertritt die Nutzerinteressen

✅ Der Senior Supplier vertritt die Lieferanten-/Ressourceninteressen

❌ Der Projektmanager ist stimmberechtigtes Mitglied des Lenkungsausschuss

Executive = Business, Senior User = Nutzer, Senior Supplier = Lieferant. Der Project Manager ist kein stimmberechtigtes Mitglied des Project Board.

Merksatz:
Das Project Board ist das "BUS"-Trio (Business-Executive, User-Senior, Supplier-Senior) – der Projektleiter fährt nur den Bus, sitzt aber selbst nicht im Vorstand.

Warum die anderen falsch sind:

D) Der Projektmanager berichtet als operativer Leiter nur an das Board, ist dort aber kein stimmberechtigtes Mitglied.

Toleranzen definieren [F] [Practices] 1 Unterseite →

☝️ Single In Bezug auf welche Dimensionen können bei PRINCE2 typischerweise Toleranzen gesetzt werden?

❌ Toleranzen können ausschließlich für die Kosten festgelegt werden, da diese die einzige messbare Größe im Projektmanagement darstellen und andere Aspekte wie Zeit oder Qualität nicht objektiv bewertbar sind.

❌ Toleranzen beziehen sich bei PRINCE2 nur auf die Größe des Projektteams, da die Anzahl der Teammitglieder den entscheidenden Faktor für den Projekterfolg darstellt und daher streng überwacht werden muss.

❌ Das Konzept der Toleranzen ist in der PRINCE2-Methodik nicht vorgesehen, da alle Projektparameter exakt eingehalten werden müssen und jede Abweichung sofort als schwerwiegender Fehler behandelt wird.

✅ Für alle Performance-Ziele wie Zeit, Kosten, Qualität, Umfang, Risiko, Nutzen

Für alle Performance-Ziele, u.a. Zeit, Kosten, Qualität, Umfang, Risiko, Nutzen.

Merksatz:
Denke an das Akronym Quali-Zit-Ko-U-Ri-Nu (Qualität, Zeit, Kosten, Umfang, Risiko, Nutzen). Wie ein Kapitän, der sechs Hebel gleichzeitig steuern muss, setzt PRINCE2 für alle sechs Leistungsdimensionen Toleranzgrenzen, damit das Projekt nicht vom Kurs abkommt.

Warum die anderen falsch sind:
Ausschließlich für die Kosten: Dieser Denkfehler reduziert Projektsteuerung fälschlicherweise auf das Budget und ignoriert andere kritische Faktoren wie Termine oder Qualität.
Nur für die Teamgröße: Ressourcen wie die Teamgröße sind organisatorische Mittel, aber keine eigenständigen Performance-Ziele des Projekts.

Toleranzen sind nicht vorgesehen: Toleranzgrenzen sind das Fundament des PRINCE2-Prinzips „Steuern nach dem Ausnahmeprinzip“ (Manage by Exception) und daher absolut essenziell.

Team Manager Rolle [F] [Practices] 1 Unterseite →

☝️ Single Was ist die Kernaufgabe des "Teammanager"?

✅ Verantwortlich für die Produktion vereinbarter Produkte durch das Team

❌ Übernimmt die vollständige Verantwortung für die Planung und Steuerung des gesamten Projekts

❌ Ist allein verantwortlich für die Erstellung und Aktualisierung des Business Case

❌ Hat als festes Mitglied des Lenkungsausschuss Stimmrecht bei allen Projektentscheidungen

Verantwortlich für die Produktion der vereinbarten Produkte durch das Team, gemäß Arbeitspaket.

Merksatz:
Der Team Manager ist der „Werkstattleiter“: Er sorgt dafür, dass sein Team die bestellten Produkte wie vereinbart produziert.

Warum die anderen falsch sind:
B) Er leitet nur sein Fach-Team und ersetzt niemals die übergeordnete Gesamt-Projektleitung.
C) Für den Business Case ist der Auftraggeber (Sponsor) verantwortlich, nicht der operative Teamleiter.

D) Im Lenkungsausschuss (Project Board) sitzen Auftraggeber und Lieferanten-Vertreter, nicht der Teamleiter.

Project Assurance [F] [Practices] 1 Unterseite →

☝️ Single Wofür ist "Project Assurance" zuständig?

✅ Unabhängige Überwachung im Sinne der Project-Board-Interessen

❌ Die kontinuierliche Überwachung der Einhaltung von Qualitätsstandards in der Projektlieferung

❌ Die direkte Steuerung und Kontrolle aller Projektaktivitäten durch den Projektmanager

❌ Die ausschließliche Prüfung der technischen Sicherheitsmaßnahmen im Projektumfeld

Unabhängige Überwachung, ob das Projekt im Sinne der jeweiligen Project-Board-Interessen (Business/User/Supplier) läuft.

Merksatz:
Denke an die „unabhängige Lupe des Project Boards“: Project Assurance ist der neutrale TÜV-Prüfer, der im Auftrag des Lenkungsausschusses die Projektqualität sichert.

Warum die anderen falsch sind:
B): Die operative Umsetzung ist Aufgabe des Projektteams, nicht der Überwachung.
C): Der Project Manager leitet das operative Geschäft und darf sich wegen Befangenheit nicht selbst prüfen.

D): IT-Sicherheit ist nur ein winziger technischer Teilaspekt und nicht der Fokus der Gesamt-Projektsicherung.

Change Authority [F] [Practices] 1 Unterseite →

☝️ Single Was ist die Aufgabe der "Änderungsinstanz"?

❌ Übernimmt die Verantwortung für die Qualitätsprüfung aller Projektergebnisse und gibt dazu die finale Freigabe

✅ Entscheidet über Änderungsanfragen, oft mit festgelegtem Budget-Rahmen

❌ Erstellt die vollständige technische Dokumentation und pflegt diese während des gesamten Projektverlaufs

❌ Übernimmt die Rolle des Teammanagers und steuert die tägliche Arbeit des Projektteams

Entscheidet über Requests for Change/Off-Specifications, oft mit einem festgelegten Budget-Rahmen.

Merksatz:
Die Change Authority ist der „Geld- und Ideen-Wächter“: Sie hat die Autorität, über Änderungen zu entscheiden, und nutzt dafür oft ein eigenes Änderungsbudget, um den Lenkungsausschuss zu entlasten.

Warum die anderen falsch sind:
Qualitätsprüfung: Das ist Aufgabe der Projektsicherung (Project Assurance) oder spezieller Prüfer, nicht der Entscheidungsinstanz für Änderungen.
Technische Dokumentation: Dies ist eine rein operative Erstellungsaufgabe der Spezialisten oder des Projektteams, keine Management-Entscheidung.

Identisch mit dem Team Manager: Der Team Manager liefert Produkte und leitet das Team, während die Change Authority eine übergeordnete Steuerungsfunktion des Lenkungsausschusses wahrnimmt.

Project Support [F] [Practices] 1 Unterseite →

☝️ Single Welche Funktion hat "Project Support" typischerweise?

❌ Übernimmt die vollständige Verantwortung für die Projektsteuerung und ersetzt den Projektmanager in allen Entscheidungen

❌ Ist in jedem PRINCE2-Projekt zwingend vorgeschrieben und darf nicht weggelassen werden

✅ Administrative Unterstützung, z.B. Dokumentenverwaltung

❌ Legt die strategischen Ziele fest und trifft alle wesentlichen Entscheidungen für das Projekt

Administrative Unterstützung, z.B. Dokumentenverwaltung, Terminkoordination — optionale Rolle.

Merksatz:
Der Project Support ist der fleißige Büro-Butler, der dem Projektleiter den Rücken freihält, indem er Akten sortiert und Termine jongliert, statt selbst zu regieren.

Warum die anderen falsch sind:
A: Ein Assistent entlastet den Projektleiter, anstatt dessen Rolle komplett zu ersetzen.
B: PRINCE2 ist hochgradig anpassbar, weshalb der Support dort keine zwingend eigenständige Rolle sein muss.

D: Strategische Entscheidungen treffen ausschließlich der Lenkungsausschuss oder der Projektleiter, nicht die administrative Unterstützung.

PID Inhalt [F] [Practices] 1 Unterseite →

☝️ Single Wofür steht "PID" und wann wird es erstellt?

❌ Project Initiation Document, erstellt in der Phase 'Starting up a Project' als technische Spezifikation für die Projektteammitglieder.

✅ Project Initiation Documentation, erstellt in "Initiating a Project"

❌ Project Incident Documentation, erstellt während der Phase 'Managing a Stage Boundary' zur Dokumentation aller aufgetretenen Abweichungen.

❌ Project Initiation Definition, erstellt in der Phase 'Directing a Project' als Kurzfassung des Business Case für das Projektboard.

Project Initiation Documentation — wird im Prozess "Initiating a Project" erstellt und bildet die "Vertragsgrundlage" mit dem Project Board.

Merksatz:
Stell dir die PID als Projekt-Initiations-Dokument vor – die "Geburtsurkunde", die beim Initiieren (Initiating a Project) ausgestellt wird.

Warum die anderen falsch sind:
A: Die PID ist das zentrale Steuerungsdokument für das Project Board, kein reines Technik-Papier.
C: "Incident" steht für ungeplante Vorfälle; die PID plant jedoch das gesamte Projekt strategisch im Voraus.

D: Der Business Case ist lediglich ein (wenn auch wichtiger) Teilbereich der umfassenden PID.

End Stage Report [F] [Practices] 1 Unterseite →

☝️ Single Wann wird ein "Phasenabschlussbericht" typischerweise erstellt?

❌ Täglich während der laufenden Stage

❌ Nur bei Projektabbruch

❌ Nur einmal am absoluten Projektende

✅ Am Ende einer Management-Stage

Am Ende einer Management-Stage, als Grundlage für die Freigabe der nächsten Stage durch das Project Board.

Merksatz:
Der End Stage Report ist das Zeugnis am Ende des Schulhalbjahres: Er wird genau am Ende jeder Management-Stage geschrieben, um dem Lenkungsausschuss die Leistung dieser Phase zu zeigen, bevor es in die nächste geht.

Warum die anderen falsch sind:

Täglich während der laufenden Stage: Dafür gibt es das Daily Log, ein täglicher Bericht wäre reiner Mikromanagement-Overkill.

Nur bei Projektabbruch: Bei einem Abbruch wird stattdessen ein spezieller "Exception Report" oder direkt der "End Project Report" genutzt.

Nur einmal am absoluten Projektende: Am eigentlichen Projektende wird der umfassende "End Project Report" erstellt, nicht der phasenbezogene End Stage Report.

Lessons Log vs. Lessons Report [F] [Practices] 1 Unterseite →

☝️ Single Wie unterscheiden sich "Erfahrungsprotokoll" und "Erfahrungsbericht"?

❌ Der Report wird kontinuierlich während des gesamten Projekts aktualisiert, während der Log ausschließlich in der Abschlussphase erstellt wird.

✅ Der Log wird laufend gepflegt, der Report fasst Erkenntnisse formal zusammen

❌ Der Erfahrungsprotokoll dokumentiert ausschließlich technische Fehler und Lösungen, nicht aber organisatorische oder prozessbezogene Erkenntnisse.

❌ Beide Dokumente sind inhaltlich und zeitlich völlig identisch und unterscheiden sich nur durch ihre jeweilige Bezeichnung im Projektmanagement.

Der Lessons Log wird laufend während des Projekts gepflegt, der Lessons Report fasst am Ende/bei Bedarf die wichtigsten Erkenntnisse formal zusammen.

Merksatz:
Das Logbuch ist dein ständiger Begleiter auf der Reise (laufend gepflegt), während der Report der feierliche Abschlussbericht am Hafen ist (formale Zusammenfassung).

Der Report wird laufend gepflegt... ist falsch, da ein Report (Bericht) ein punktuelles Dokument ist und das Log (Logbuch) das dynamische Werkzeug für den Alltag darstellt.
Lessons Log betrifft nur technische Themen ist falsch, da das Logbuch alle Arten von Erkenntnissen (organisatorisch, prozessual, menschlich) im gesamten Projekt erfasst.

Beide Begriffe sind exakt identisch ist falsch, da das Log das laufende Arbeitswerkzeug ist, während der Report ein formelles Berichts-Dokument für Stakeholder darstellt.

Daily Log [F] [Practices] 1 Unterseite →

☝️ Single Wofür wird das "Daily Log" genutzt?

✅ Informelles Protokoll für Aktionen und Beobachtungen im Tagesgeschäft

❌ Formelles Dokument, das dem Lenkungsausschuss zur Genehmigung vorgelegt wird

❌ Wird ausschließlich bei der Abschlussphase des Projekts erstellt

❌ Übernimmt die Funktion des Business Case im Projektverlauf

Informelles Protokoll des Project Manager für Aktionen, Beobachtungen, kleinere Ereignisse im Tagesgeschäft.

Merksatz: Das Daily Log ist dein persönliches Projekttagebuch: Hier notierst du informell und spontan die kleinen Ereignisse des Alltags, bevor sie in Vergessenheit geraten.

Warum die anderen falsch sind:
B) Ein Daily Log ist viel zu informell für das hochrangige Project Board.
C) Das Wort „Daily“ schließt eine einmalige Erstellung am Projektende logischerweise aus.

D) Ein simples Notizbuch kann niemals die strategische Wirtschaftlichkeitsrechnung des Business Case ersetzen.

Product Description [F] [Practices] 1 Unterseite →

☝️ Single Was enthält eine "Produktbeschreibung" typischerweise?

❌ Die genaue Auflistung aller Einzelteile und Baugruppen eines Produkts ohne Berücksichtigung von Qualitätsanforderungen

❌ Die alleinige Angabe des Verkaufspreises eines Produkts inklusive aller Nebenkosten und Rabattstaffeln

❌ Die reine Nennung des Produktnamens sowie seiner Versionsnummer und des Erstellungsdatums

✅ Zweck, Zusammensetzung, Herkunft und Qualitätskriterien eines Produkts

Zweck, Zusammensetzung, Herkunft und Qualitätskriterien eines zu liefernden Produkts.

Merksatz:
Die Produktbeschreibung ist der „Personalausweis“ des Produkts: Er verrät den Zweck (Beruf), die Zusammensetzung (DNA), die Herkunft (Heimat) und die Qualität (Charakter) – alles für eine erfolgreiche Abnahme.

Warum die anderen falsch sind:
A: Der Preis gehört in die Kalkulation oder das Angebot, nicht in die inhaltliche Beschreibung.
B: Eine reine Stückliste vernachlässigt die für die Abnahme entscheidenden Qualitätskriterien.

C: Nur der Name ist ein bloßes Etikett und liefert keinerlei steuerungsrelevante Informationen.

Work Package [F] [Practices] 1 Unterseite →

☝️ Single Was ist ein "Arbeitspaket" (Arbeitspaket)?

❌ Ein reines Budgetinstrument zur Überwachung der Projektkosten

❌ Ein anderer Begriff für den vollständigen Projektplan

✅ Eine Beauftragung eines Teams zur Lieferung eines oder mehrerer Produkte

❌ Ein Bericht, der ausschließlich für das Lenkungsausschuss erstellt wird

Eine Menge an Informationen, mit denen ein Team beauftragt wird, ein oder mehrere Produkte zu liefern.

Merksatz:
Stell dir das Arbeitspaket wie ein Postpaket vor: Du beauftragst ein Team, damit es dir konkrete Produkte liefert.

Warum die anderen falsch sind:
A) Greift als reiner Finanzposten viel zu kurz.
B) Verwechselt das einzelne Steuerungselement mit dem gesamten Projektplan.

D) Richtet sich an das ausführende Team, nicht primär an das Project Board.

Exception Report [F] [Practices] 1 Unterseite →

☝️ Single Wann wird ein "Ausnahmebericht" erstellt?

❌ Wenn im Projekt ein schwerwiegender Fehler auftritt, der den Projektabschluss gefährdet, wird dieser Bericht zur Dokumentation des Vorfalls erstellt.

✅ Wenn eine gesetzte Toleranz voraussichtlich überschritten wird

❌ Der Ausnahmebericht wird in regelmäßigen Abständen erstellt, um den aktuellen Projektstatus unabhängig von Abweichungen zu protokollieren.

❌ Bei einem Wechsel der Projektleitung wird dieser Bericht verfasst, um die Übergabe der Verantwortlichkeiten zu dokumentieren.

Wenn eine gesetzte Toleranz voraussichtlich überschritten wird — informiert das Project Board über die Abweichung.

Merksatz:
Der Exception Report ist der Notbrems-Alarm: Er schrillt sofort, wenn das Projekt die vereinbarten Toleranz-Leitplanken zu durchbrechen droht.

Warum die anderen falsch sind:
A: Ein erfolgreicher Abschluss wird im Projektabschlussbericht dokumentiert, nicht im Ausnahmebericht.
C: Wöchentliche Berichte sind routinemäßige Statusberichte und keine anlassbezogenen Eskalationswerkzeuge.

D: Personalwechsel werden über das Ressourcenmanagement gelöst und erfordern keinen Exception Report.

Exception Plan [F] [Practices] 1 Unterseite →

☝️ Single Was ist ein "Ausnahmeplan"?

❌ Ein Dokument, das den wirtschaftlichen Nutzen des Projekts zusammenfasst und als Grundlage für alle weiteren Planungen dient.

❌ Der unveränderte Basisplan, der zu Beginn des Projekts erstellt und während der gesamten Laufzeit unverändert beibehalten wird.

❌ Ein Plan, der vor Projektbeginn aufgestellt wird und alle späteren Änderungen am Projektumfang grundsätzlich ausschließt.

✅ Ein überarbeiteter Plan als Reaktion auf eine genehmigte Ausnahmesituation

Ein überarbeiteter Plan als Reaktion auf einen genehmigten Exception Report, ersetzt den bisherigen Plan ab dem aktuellen Zeitpunkt.

Merksatz:
Der Exception Plan (Ausnahmeplan) ist das rettende Navi-Update, wenn das Projekt vom Kurs abkommt: Er steuert als neuer, genehmigter Fahrplan aus der Krise heraus.

Synonym für Business Case: Falsch, weil der Business Case die wirtschaftliche Rechtfertigung liefert, nicht die operative Steuerung im Krisenfall.
Ursprünglicher, unveränderter Projektplan: Falsch, dies ist die "Baseline" (Basislinie), während der Exception Plan eine dynamische Reaktion auf Abweichungen ist.

Ausschließlich vor Projektbeginn erstellt: Falsch, da er erst während des Projekts als Reaktion auf eine konkrete Toleranzüberschreitung entsteht.

Risk Register [F] [Practices] 1 Unterseite →

☝️ Single Was wird im "Risikoregister" festgehalten?

❌ Ausschließlich die Projektkosten

✅ Identifizierte Risiken inkl. Bewertung und Gegenmaßnahmen

❌ Die Namen aller Teammitglieder

❌ Ausschließlich abgeschlossene, nicht mehr relevante Risiken

Identifizierte Risiken inkl. Bewertung, Gegenmaßnahmen und Verantwortlichkeiten.

Merksatz:
Das Risk Register ist das „Gefahren-Radar“ des Projekts: Es scannt die Bedrohungen (Risiken), misst ihre Stärke (Bewertung) und hält den Schutzschild bereit (Gegenmaßnahmen).

Warum die anderen falsch sind:
Ausschließlich die Projektkosten: Das Budget gehört in den Business Case oder Projektplan, nicht in die Risikoliste.
Die Namen aller Teammitglieder: Personalressourcen werden im Projektorganisationsplan oder Kommunikationsmanagement-Ansatz dokumentiert.
Ausschließlich abgeschlossene Risiken: Ein Register muss lebendig sein und vor allem aktive*, zukünftige Bedrohungen steuern, um das Projekt aktiv zu schützen.

Issue Register [F] [Practices] 1 Unterseite →

☝️ Single Was wird im "Issueregister" festgehalten?

❌ Alle im Projektverlauf aufgetretenen Kostenänderungen mit ihrer aktuellen Bewertung und dem genehmigten Budgetstatus

❌ Sämtliche dokumentierten technischen Störungen inklusive der jeweiligen Fehlerursache und der durchgeführten Korrekturmaßnahme

✅ Alle formal erfassten Issues inkl. Status und Entscheidung

❌ Die vollständige Auflistung aller identifizierten Risiken mit ihrer Eintrittswahrscheinlichkeit und der geplanten Gegenmaßnahme

Alle formal erfassten Issues inkl. Status und Entscheidung darüber.

Merksatz:
Das Issue Register ist das offizielle „Sorgen- und Ideenbuch“ des Projekts: Hier landet jeder formale Vorfall (Issue) von der Geburt bis zur gelösten Entscheidung – lückenlos mit Status.

Warum die anderen falsch sind:
Ausschließlich Budgetabweichungen: Dies ist zu eng gefasst, da Issues alle Arten von Problemen, Änderungen und offenen Punkten umfassen.
Ausschließlich technische Fehlerprotokolle: Dies greift viel zu kurz und verwechselt das Register mit einem IT-Bugtracker.

Eine Liste aller Projektrisiken: Risiken (unsichere zukünftige Ereignisse) gehören ins Risikoregister, während das Issue Register bereits eingetretene Ereignisse erfasst.

Quality Register [F] [Practices] 1 Unterseite →

☝️ Single Was wird im "Qualitätsregister" festgehalten?

❌ Die vollständige Dokumentation aller vertraglichen Vereinbarungen mit externen Lieferanten und Dienstleistern

✅ Geplante und durchgeführte Qualitätsprüfungen und deren Ergebnisse

❌ Die zentrale Auflistung aller identifizierten Risiken inklusive ihrer Eintrittswahrscheinlichkeit und Auswirkungen

❌ Die detaillierte Erfassung der Projektteamstruktur inklusive aller Rollen, Verantwortlichkeiten und Kompetenzen

Geplante und durchgeführte Qualitätsprüfungen sowie deren Ergebnisse.

Merksatz:
Das Quality Register ist das „TÜV-Heft“ des Projekts: Es dokumentiert, wann geprüft wird (geplant), wer prüft (durchgeführt) und ob das Produkt die Plakette erhält (Ergebnis).

Warum die anderen falsch sind:
A: Lieferantenverträge gehören in den Einkauf (Beschaffungsmanagement), nicht in die Qualitätskontrolle.
C: Risiken bedrohen das Projekt, Qualität sichert das Produkt – das sind zwei völlig verschiedene Dokumente.

D: Die Teamzusammensetzung wird im Organigramm oder Ressourcenplan erfasst, nicht im Qualitätsnachweis.

Communication Management Approach [F] [Practices] 1 Unterseite →

☝️ Single Wofür wird ein "Communication Management Approach" erstellt?

❌ Er dient dazu, den Business Case durch eine detaillierte Auflistung aller Kommunikationswege zu ersetzen und so die Projektsteuerung zu vereinfachen.

❌ Er wird genutzt, um die gleichen Risiken wie der Risk Management Approach zu erfassen und die Maßnahmen zur Risikominimierung zu dokumentieren.

✅ Um festzulegen, wer wann welche Information in welcher Form erhält

❌ Er legt fest, wie ausschließlich externe Pressemitteilungen an die Öffentlichkeit formuliert und über die Medien verbreitet werden.

Um festzulegen, wer wann welche Information in welcher Form erhält.

Merksatz:
Der Communication Management Approach ist der Postbote des Projekts: Er regelt den exakten Fahrplan – wer, wann, was und wie – damit keine Nachricht im Nirgendwo landet.

Warum die anderen falsch sind:
Ersetzt den Business Case: Der Business Case rechtfertigt das Projekt wirtschaftlich, Kommunikation regelt nur den Informationsfluss.
Identisch mit Risk Management Approach: Risiko-Management analysiert Bedrohungen und Chancen, statt Kommunikationswege zu strukturieren.

Ausschließlich für externe Pressemitteilungen: Er umfasst die gesamte interne und externe Projektkommunikation, nicht nur die Presse.

Tolerance Ebenen [F] [Practices] 1 Unterseite →

☝️ Single Auf welchen Ebenen können bei PRINCE2 Toleranzen gesetzt werden?

❌ Auf allen Ebenen des Projektmanagements, also auf Projektebene, Stage-Ebene und Teamebene, können Toleranzen gesetzt werden.

❌ Toleranzen werden ausschließlich auf der obersten Managementebene festgelegt, also nur auf Projektebene, und gelten dann für alle weiteren Ebenen.

✅ Auf Projekt-, Stage- und Arbeitspaket-Ebene

❌ Toleranzen können nur auf der Ebene der einzelnen Arbeitspakete definiert werden, nicht jedoch auf Projekt- oder Stage-Ebene.

Auf Projekt-, Stage- und Arbeitspaket-Ebene, jeweils mit entsprechender Eskalationsverantwortung.

Merksatz:
Stell dir das PRINCE-Schloss mit drei Etagen vor: Oben regiert das Projekt, in der Mitte die Stage (Phase) und unten lagert das Arbeitspaket – jede Etage braucht ihren eigenen Spielraum (Toleranz).

Warum die anderen falsch sind:
A) ...ignoriert die operative Steuerung der einzelnen Phasen und Teams.
B) ...übersieht, dass starre globale Vorgaben die nötige Flexibilität vor Ort blockieren.

D) ...vergisst, dass die strategische Führungsebene die Rahmenbedingungen vorgibt.

Eskalation bei Überschreitung [F] [Practices] 1 Unterseite →

☝️ Single Was passiert, wenn eine Toleranz auf Stage-Ebene überschritten zu werden droht?

❌ Der Projektmanager informiert das Lenkungsausschuss erst im nächsten regulären Statusbericht und ergreift bis dahin selbstständig Korrekturmaßnahmen, um die Abweichung zu beheben.

❌ Das Lenkungsausschuss wird automatisch informiert und beendet das Projekt umgehend, ohne dass eine weitere Analyse oder ein Ausnahmebericht erforderlich ist.

❌ Die Toleranzüberschreitung wird dokumentiert und im Projektausschuss behandelt, jedoch ohne dass konkrete Maßnahmen oder eine formale Eskalation ausgelöst werden.

✅ Der Projektmanager eskaliert per Ausnahmebericht an das Lenkungsausschuss

Der Project Manager eskaliert per Exception Report an das Project Board.

Merksatz: Reißt die Toleranz-Leine auf Stage-Ebene, funkt der Project Manager sofort SOS per Exception Report an das übergeordnete Project Board – er darf das Problem nicht im Alleingang aussitzen.

Warum die anderen falsch sind:
A) Der Project Manager darf seine festgesetzten Kompetenzgrenzen niemals eigenmächtig überschreiten.
B) Ein Projektabbruch ist die absolute Ausnahme und erfolgt niemals automatisch.

C) Toleranzen sind verbindliche Leitplanken und keine optionalen Richtwerte.

Themes/Practices Prüfungsfalle [F] [Practices] 1 Unterseite →

☝️ Single Ein Prüfungskandidat nutzt noch den Begriff "Change" statt "Issues". Was ist das Problem?

❌ Der Unterschied zwischen beiden Begriffen ist rein kosmetischer Natur und hat keinerlei Auswirkungen auf die Prüfungsleistung oder das Verständnis der Methode.

❌ Der Begriff 'Change' bezeichnet in der 7. Edition ein eigenständiges, achtes Practice, das sich ausschließlich mit Änderungsanträgen befasst.

✅ "Change" ist der veraltete Begriff aus der 6. Edition, jetzt heißt es "Issues"

❌ Beide Begriffe sind in der 7. Edition weiterhin identisch gültig und können im Prüfungskontext beliebig austauschbar verwendet werden.

"Change" war der Name der Practice in der 6. Edition — in der 7. Edition heißt sie "Issues". Für die aktuelle Prüfung zählt die neue Terminologie.

Merksatz:
Wer in der neuen Edition noch "Change" sagt, hat selbst ein "Issue" – das alte "Change"-Thema wurde komplett durch das neue "Issues"-Practice ersetzt.

Warum die anderen falsch sind:
A: Ignoriert die strikte begriffliche Trennung der Editionen, die für das Bestehen der Prüfung elementar ist.
B: Erfindet fälschlicherweise ein zusätzliches achtes Practice, obwohl es weiterhin nur sieben gibt.

D: Übersieht den harten, exklusiven begrifflichen Schnitt zwischen den beiden Versionen.

Organization vs. Organizing Prüfungsfalle [F] [Practices] 1 Unterseite →

☝️ Single Welcher Begriff ist in der PRINCE2 7. Edition korrekt: "Organization" oder "Organizing"?

❌ Keiner von beiden, korrekt ist "Organisation" auf Deutsch

✅ Organizing

❌ Beide sind offiziell gleichwertig

❌ Organization

"Organizing" — umbenannt in der 7. Edition, um den aktiven/fortlaufenden Charakter zu betonen.

Merksatz:
In PRINCE2 7 ist alles in Bewegung: Wir nutzen das aktive Verb "Organizing" (Organisieren) statt des starren Nomens "Organization", weil Projektmanagement ein dynamischer Prozess ist – denke an das "-ing" für "laufende Action".

Warum die anderen falsch sind:
"Organization": Dies war der statische Begriff der alten Version 6; in Version 7 wurde er durch das dynamische "Organizing" ersetzt.
Beide sind gleichwertig: PRINCE2 7 ist hier strikt und nutzt konsequent nur noch den prozessorientierten Begriff "Organizing".

"Organisation" auf Deutsch: Die offizielle deutsche Übersetzung von PRINCE2 7 nutzt zwar "Organisation", die englischen Fachbegriffe bleiben in der Prüfung jedoch die exakte Referenz, bei der "Organizing" die einzig korrekte Basis ist.

Rollen-Prüfungsfalle [F] [Practices] 1 Unterseite →

☝️ Single Ein Kandidat verwechselt in der Prüfung "Senior User" mit "Senior Supplier". Worauf sollte er sich zur Unterscheidung konzentrieren?

❌ Senior User ist in PRINCE2 immer identisch mit dem Executive und übernimmt dessen Entscheidungsbefugnisse

✅ Senior User = Nutzer-Interessen, Senior Supplier = Lieferanten-Interessen

❌ Beide Rollen sind in PRINCE2 austauschbar und haben dieselben Verantwortlichkeiten und Interessen

❌ Senior Supplier vertritt in PRINCE2 immer die Interessen der Endnutzer und deren Anforderungen

Senior User vertritt NUTZER-Interessen (wer profitiert vom Ergebnis), Senior Supplier vertritt LIEFERANTEN-Interessen (wer stellt Ressourcen/Fachwissen bereit).

Merksatz:
Der User urteilt über den Nutzen (Anwender), der Supplier schuldet die Leistung (Lieferant).

Warum die anderen falsch sind:
A) Der Executive leitet das Projekt strategisch und ist eine eigene, übergeordnete Rolle.
C) Die Rollen vertreten völlig gegensätzliche Perspektiven (Bedarf vs. Realisierung) und sind strikt getrennt.

D) Der Supplier liefert die Ressourcen, während der User die Endnutzer vertritt.

Project-Board-Rollen vollständig [F] [Practices] 1 Unterseite →

✌️ Multi Welche drei Rollen bilden zusammen das Lenkungsausschuss? (Mehrfachauswahl — wähle alle drei)

✅ Executive

✅ Senior Supplier

✅ Senior User

❌ Teammanager

Merksatz:
Das Project Board thront auf dem E-S-U-Sofa: Der Executive (Auftraggeber) sitzt in der Mitte, flankiert vom Senior Supplier (Lieferant) und Senior User (Anwender) – sie lenken gemeinsam von oben.

Warum die anderen falsch sind:

D) Team Manager: Ist eine rein operative Rolle auf der Lieferebene, die dem Project Board unterstellt ist und dort keine strategischen Entscheidungen trifft.

Toleranzen im eigenen Beispiel [F] [Practices] 1 Unterseite →

☝️ Single Auf welchem PRINCE2-Principle basiert die Festlegung von Toleranzen (z. B. ±5 % Budget)?

✅ Steuern nach dem Ausnahmeprinzip

❌ Focus on Products

❌ Learn from Experience

❌ Tailor to Suit the Project

Toleranzen sind die zentrale Umsetzung des Prinzips "Manage by Exception".

Merksatz: Toleranzen sind wie die Leitplanken auf der Autobahn: Solange du innerhalb der ±5 % fährst, läuft alles von selbst – erst beim Verlassen der Spur (der Ausnahme) greift der Chef ein (Manage by Exception).

Warum die anderen falsch sind:
Focus on Products: Konzentriert sich auf die Definition und Qualität der Lieferergebnisse, nicht auf finanzielle oder zeitliche Puffer.
Learn from Experience: Nutzt Lehren aus der Vergangenheit für die Zukunft, statt den aktuellen Handlungsspielraum im Projekt zu steuern.

Tailor to Suit the Project: Passt die PRINCE2-Methode an die Projektgröße an, legt aber keine operativen Grenzwerte fest.

Exception Report selbst formulieren [F] [Practices] 1 Unterseite →

☝️ Single Was muss ein Ausnahmebericht an das Lenkungsausschuss enthalten?

✅ Ursache, Auswirkung, Handlungsoptionen und die benötigte Entscheidung des Lenkungsausschuss

❌ Die ausschließliche Darstellung von positiven Fortschrittsmeldungen, um den aktuellen Status des Projekts als erfolgreich zu präsentieren und eine positive Entscheidung des Lenkungsausschusss zu fördern.

❌ Die reine Auflistung der Namen aller betroffenen Teammitglieder, um die Verantwortlichkeiten innerhalb des Projekts klar zu dokumentieren und die Zuständigkeiten für das Lenkungsausschuss nachvollziehbar zu machen.

❌ Die ausschließliche Bereitstellung einer detaillierten Kostenaufstellung, ohne dabei mögliche Handlungsoptionen oder alternative Vorgehensweisen für das Lenkungsausschuss zu skizzieren.

Ein Exception Report enthält Ursache, Auswirkung, Handlungsoptionen und die benötigte Entscheidung des Project Board.

Merksatz:
Der Exception Report ist wie ein Notruf beim Autounfall: Du musst dem Board sagen, was die Ursache war, welche Auswirkung droht, welche Optionen es zur Rettung gibt und welche Entscheidung du jetzt sofort von ihnen brauchst.

Ausschließlich positive Fortschrittsmeldungen: Falsch, weil ein Exception Report ein Alarmmittel bei Toleranzüberschreitungen ist und kein geschönter Statusbericht.
Nur die Namen der betroffenen Teammitglieder: Falsch, da Schuldzuweisungen dem Lenkungsausschuss keine sachliche Entscheidungsgrundlage zur Problemlösung bieten.

Ausschließlich eine Kostenaufstellung ohne Handlungsoptionen: Falsch, da das Board ohne konkrete Lösungswege und Empfehlungen handlungsunfähig bleibt.

Benefits Review Plan [F] [Practices] 1 Unterseite →

☝️ Single Wofür wird ein "Benefits Review Plan" genutzt?

❌ Um festzulegen, wie und wann die Projektkosten überwacht und gesteuert werden

❌ Um festzulegen, wie und wann der Nutzen während der Initiierungsphase bewertet wird

✅ Um festzulegen, wie und wann der erwartete Nutzen gemessen wird

❌ Um den Business Case vollständig zu ersetzen und dessen Inhalte zu übernehmen

Um festzulegen, wie und wann der erwartete Nutzen eines Projekts gemessen wird — teils auch nach Projektabschluss.

Merksatz:
Der Benefits Review Plan ist die „Nutzen-Messuhr“: Er tickt wie ein Timer, der festlegt, wann und mit welcher Waage (wie) die süßen Früchte (der Nutzen) des Projekts geerntet und gewogen werden.

Warum die anderen falsch sind:
Kostenkontrolle: Kosten sind nicht gleich Nutzen; für Finanzen ist das Budget- und Kostencontrolling zuständig.
Nur Initiierung: Nutzen entsteht meist erst nach Projektende, weshalb der Plan weit über die Initiierung hinaus aktiv bleibt.

Ersetzt Business Case: Er ersetzt ihn nicht, sondern ist nur das Werkzeug, um die Versprechen des Business Case im Nachgang zu überprüfen.

Nutzen nach Projektende [F] [Practices] 1 Unterseite →

☝️ Single Warum kann die Messung des Nutzens eines Projekts auch NACH dessen formalem Abschluss relevant sein?

✅ Weil viele Nutzeneffekte sich erst über einen längeren Zeitraum im Betrieb zeigen

❌ Weil der Nutzen eines Projekts bereits vollständig vor dem formalen Abschluss realisiert sein muss, damit eine valide Bewertung möglich ist.

❌ Weil PRINCE2 vorsieht, dass das Projektmanagementteam auch nach dem Abschluss weiterhin für die Nutzenrealisierung verantwortlich bleibt.

❌ Weil die Nutzenmessung nach dem Abschluss nur dann relevant ist, wenn das Projekt im Rahmen eines Programms mit festen Meilensteinen durchgeführt wird.

Weil viele Nutzeneffekte (z.B. Effizienzsteigerung) sich erst über einen längeren Zeitraum im laufenden Betrieb zeigen.

Merksatz:
Die Ernte wird nicht am Tag der Aussaat eingefahren – echter Projektnutzen entfaltet sich erst im laufenden Betrieb, lange nachdem das Projektteam Feierabend hat.

Warum die anderen falsch sind:

Nur vor Projektbeginn sinnvoll: Vorab schätzt man den Nutzen nur, gemessen werden kann er logischerweise erst nach der Einführung.

Projekte schließen nie ab: PRINCE2 hat mit dem Prozess „Abschließen eines Projekts“ ein ganz klares, definiertes Ende.

Nicht vorgesehen: PRINCE2 sieht im „Nutzen-Managementansatz“ explizit Aktivitäten nach dem Projektende vor, um den tatsächlichen Erfolg zu überprüfen.

Qualitätsplanung vs. Qualitätskontrolle [F] [Practices] 1 Unterseite →

☝️ Single Wie unterscheiden sich Qualitätsplanung und Qualitätskontrolle bei PRINCE2?

❌ Qualitätsplanung legt die Prüfverfahren erst nach Abschluss der Qualitätskontrolle fest, da die Kontrollergebnisse die Planung bestimmen.

❌ Qualitätsplanung ist in PRINCE2 ein optionaler Prozess, der nur bei Projekten mit hohem Risiko angewendet werden muss.

✅ Planung legt vorab fest was/wie geprüft wird, Kontrolle führt die Prüfung durch

❌ Qualitätsplanung und Qualitätskontrolle bezeichnen in PRINCE2 denselben Vorgang, der lediglich zu unterschiedlichen Zeitpunkten durchgeführt wird.

Qualitätsplanung legt vorab fest, was/wie geprüft wird — Qualitätskontrolle führt die eigentliche Prüfung durch.

Merksatz:
Der Planer zeichnet die Zielscheibe (Kriterien & Methoden), der Kontrolleur schießt darauf (Prüfung & Nachweis). Erst die Schablone erstellen, dann die Passform messen!

Warum die anderen falsch sind:
Kontrolle vor Planung: Logisch unmöglich, da man ohne vorherige Kriterien gar nicht weiß, was man kontrollieren soll.
Planung optional: Qualität ist ein PRINCE2-Grundprinzip und niemals optional, um den Projekterfolg zu sichern.

Begriffe identisch: Planung (Soll-Definition) und Kontrolle (Ist-Prüfung) sind zwei völlig verschiedene Prozessschritte.

Risikobewertung Wahrscheinlichkeit/Auswirkung [F] [Practices] 1 Unterseite →

☝️ Single Wonach werden Risiken bei PRINCE2 typischerweise bewertet?

❌ Ausschließlich nach dem Alter des Risikos

❌ Risiken werden bei PRINCE2 nicht bewertet, nur gelistet

❌ Ausschließlich nach den Kosten der Gegenmaßnahme

✅ Nach Eintrittswahrscheinlichkeit und Auswirkung

Nach Eintrittswahrscheinlichkeit und Auswirkung (Impact), oft kombiniert zu einem Risikowert.

Merksatz:
Stell dir ein Risiko wie ein drohendes Gewitter vor: Du bewertest immer, wie wahrscheinlich es dich trifft und wie heftig die Auswirkungen (der Schaden) sind.

Warum die anderen falsch sind:
A) Das Alter eines Risikos sagt nichts über seine aktuelle Bedrohungskraft aus.
B) Reine Listen ohne Bewertung machen Risikomanagement völlig blind und nutzlos.

C) Die Kosten von Gegenmaßnahmen bestimmen die Reaktion, nicht die eigentliche Bedrohung.

Risikostrategie Chancen [F] [Practices] 1 Unterseite →

☝️ Single Welche Strategie passt zu einem positiven Risiko (einer Chance)?

❌ Transfer ausschließlich für Bedrohungen

✅ Exploit

❌ Reduce ausschließlich für Bedrohungen

❌ Avoid

"Exploit" (aktiv nutzen) ist eine typische Strategie für Chancen, im Gegensatz zu "Avoid" für Bedrohungen.

Merksatz:
Bei Chancen gilt: „Nutze sie voll aus!“ – Das englische Wort Exploit bedeutet „ausbeuten“ oder „maximieren“. Wir wollen die Chance also zu 100 % Realität werden lassen, indem wir die Unsicherheit komplett beseitigen.

Warum die anderen falsch sind:
Transfer (Übertragen): Dies verschiebt nur finanzielle Auswirkungen von Bedrohungen auf Dritte (z. B. Versicherungen), statt Chancen aktiv zu realisieren.
Reduce (Reduzieren): Dies mindert die Wahrscheinlichkeit oder Auswirkung von negativen Bedrohungen, während wir Chancen vergrößern wollen.

Avoid (Vermeiden): Dies ist eine reine Abwehrstrategie, um Bedrohungen komplett zu umgehen – für Chancen völlig ungeeignet.

Risk Owner [F] [Practices] 1 Unterseite →

☝️ Single Was ist die Aufgabe eines "Risk Owner"?

❌ Verantwortlich für die Identifikation und Bewertung sämtlicher Risiken innerhalb des Projektportfolios

✅ Verantwortlich für Überwachung und Steuerung eines zugeordneten Risikos

❌ Übernimmt die Rolle des Executive und entscheidet über alle risikobezogenen Maßnahmen

❌ Dokumentiert Risiken ausschließlich im Risikoregister ohne weitere Einflussnahme

Verantwortlich für die Überwachung und Steuerung eines konkreten, ihm zugeordneten Risikos.

Merksatz:
Der Risk Owner ist der persönliche „Bodyguard“ für ein bestimmtes Risiko – er behält es fest im Blick und greift aktiv ein, wenn es zuschlägt.

Warum die anderen falsch sind:
A: ... weil niemand die utopische Gesamtverantwortung für alle Risiken aller Projekte tragen kann.
C: ... weil der Executive das Projekt strategisch lenkt, die Detailsteuerung einzelner Risiken aber delegiert.

D: ... weil ein „Owner“ aktiv handeln und steuern muss, statt nur passiv zu dokumentieren.

Issue vs. Risiko Abgrenzung [F] [Practices] 1 Unterseite →

☝️ Single Wie unterscheidet sich ein "Issue" grundsätzlich von einem "Risiko"?

❌ Ein Issue stellt die übergeordnete Kategorie dar, unter die alle Risiken als spezielle Form von Problemen eingeordnet werden.

✅ Risiko = mögliches zukünftiges Ereignis, Issue = bereits eingetreten/aktuell

❌ Issues beziehen sich ausschließlich auf schwerwiegende Abweichungen vom Projektplan, während Risiken nur geringfügige Unsicherheiten beschreiben.

❌ Beide Begriffe bezeichnen denselben Sachverhalt und können im Projektmanagement jederzeit synonym verwendet werden.

Ein Risiko ist ein mögliches, zukünftiges Ereignis — ein Issue ist bereits eingetreten oder ein aktuelles Anliegen.

Merksatz:
Das Risiko ist die Regenwolke am Horizont (Zukunft/Vielleicht), das Issue ist der Innenraum-Wasserschaden (Gegenwart/Fakt).

Warum die anderen falsch sind:
A: PRINCE2-Methoden spielen für die IPMA-Definitionen keine Rolle.
C: Auch kleine, triviale Probleme sind Issues, während Risiken existenzbedrohend sein können.

D: Die zeitliche Komponente (Zukunft vs. Gegenwart) trennt beide Begriffe messerscharf.

Off-Specification [F] [Practices] 1 Unterseite →

☝️ Single Was ist eine "Off-Specification"?

❌ Ein Hinweis, dass ein Produkt die vereinbarten Spezifikationen übertrifft

❌ Ein Dokument, das ausschließlich im Projektabschlussbericht verwendet wird

❌ Ein anderer Begriff für eine genehmigte Änderungsanforderung

✅ Ein Hinweis, dass ein Produkt vereinbarte Spezifikationen nicht erfüllt

Ein Hinweis darauf, dass ein Produkt die vereinbarten Spezifikationen nicht erfüllt (oder nicht erfüllen wird).

Merksatz:
Stell dir ein Auto vor, das offroad im Graben landet, weil es die Straße (Spezifikation) verlassen hat: Eine "Off-Spec" bedeutet, dass das Produkt "off" (daneben) ist und die vereinbarten Kriterien nicht erfüllt.

Warum die anderen falsch sind:
A: Ein Fehler ("off") ist das Gegenteil von positiver Qualität.
B: Abweichungen müssen sofort bei Entstehung gemeldet werden, nicht erst am Projektende.

C: Die Off-Spec stellt nur den IST-Mangel fest, während ein RFC (Request for Change) die SOLL-Änderung aktiv beantragt.

Request for Change [F] [Practices] 1 Unterseite →

☝️ Single Was ist ein "Request for Change"?

❌ Ein formeller Antrag auf Freigabe zusätzlicher finanzieller Mittel aus der Projektreserve

❌ Ein Dokument, das Abweichungen von der Projektfreigabe zusammenfasst und bewertet

✅ Ein Vorschlag zur Änderung einer bereits genehmigten Spezifikation

❌ Ein schriftlicher Antrag zur sofortigen Beendigung des gesamten Projekts

Ein Vorschlag zur Änderung einer bereits genehmigten (baselined) Spezifikation.

Merksatz: Der "Request for Change" (RfC) ist wie ein nachträglicher Änderungswunsch am bereits unterschriebenen Bauplan – erst wenn die Spezifikation offiziell genehmigt ist, bittet man formell um Anpassung.

Warum die anderen falsch sind:
A: Verwechselt die bloße Abweichung vom Soll-Zustand (Off-Specification) mit dem formellen Antrag auf eine bewusste Änderung.
B: Verengt den Fokus fälschlicherweise nur aufs Geld, obwohl ein RfC auch Termine, Qualität oder den Leistungsumfang betrifft.

D: Setzt eine kontrollierte Kurskorrektur fälschlicherweise mit dem kompletten, vorzeitigen Ende des Projekts gleich.

Toleranz-Dimensionen [F] [Practices] 1 Unterseite →

✌️ Multi Für welche der folgenden können bei PRINCE2 typischerweise Toleranzen gesetzt werden? (Mehrfachauswahl)

✅ Zeit

❌ Bürostandort

✅ Risiko

✅ Kosten

Merksatz:
Wer im Projekt Zeit und Kosten überschreitet, geht ein hohes Risiko ein – für diese drei Dimensionen (Zeit, Kosten, Risiko) brauchst du immer Toleranz-Puffer!

Warum die anderen falsch sind:

B) Bürostandort: Dies ist eine feste infrastrukturelle Vorgabe und keine steuerbare Leistungsdimension des Projektmanagements.

Baseline und Change zusammen erklären [F] [Practices] 1 Unterseite →

☝️ Single Was gilt, wenn ein baselined Produkt geändert werden soll?

✅ Die Änderung muss formal über einen Request for Change beantragt und genehmigt werden

❌ Eine Änderung an einem baselined Produkt kann nach Rücksprache mit dem Team direkt umgesetzt werden, ohne dass ein formaler Genehmigungsprozess durchlaufen werden muss.

❌ Das Baselining eines Produkts stellt sicher, dass nach der Freigabe keinerlei Anpassungen mehr vorgenommen werden dürfen, auch wenn neue Anforderungen auftreten.

❌ Bei jeder gewünschten Änderung wird die bestehende Baseline automatisch entfernt, sodass das Produkt ohne weitere Prüfung neu freigegeben werden kann.

Ein baselined Produkt darf nur über einen formalen Request for Change geändert werden.

Merksatz:
Die Baseline ist wie ein Tresor: Wer den Inhalt ändern will, braucht den offiziellen Schlüssel – den formellen "Request for Change" (RfC) mit Genehmigung.

Warum die anderen falsch sind:
B: Informelles Ändern führt zu Kontrollverlust und zerstört den Sinn einer gesicherten Baseline.
C: Baselining friert den Zustand zwar ein, erlaubt aber kontrollierte Anpassungen im Projektverlauf.

D: Die Baseline wird nicht gelöscht, sondern durch die genehmigte Änderung sauber auf eine neue Version aktualisiert.

Eigenes Risiko bewerten [F] [Practices] 1 Unterseite →

☝️ Single Welche Schritte umfasst das PRINCE2-Risikomanagement-Verfahren?

✅ Identifizieren, Bewerten, Planen, Implementieren, Kommunizieren

❌ Identifizieren, Bewerten, Planen, Implementieren, Überwachen

❌ Identifizieren, Analysieren, Steuern, Dokumentieren, Abschließen

❌ Erkennen, Priorisieren, Behandeln, Kontrollieren, Berichten

Das Risikomanagement-Verfahren umfasst Identifizieren, Bewerten, Planen, Implementieren und Kommunizieren.

Merksatz:
Stell dir einen Prinzen im Nebel vor: Er muss Gefahren erst Identifizieren, deren Schwere Bewerten, einen Ausweg Planen, diesen Implementieren und per Funk Kommunizieren – merk dir I-B-P-I-K für PRINCE2.

Warum die anderen falsch sind:
B) Ignoriert die aktiven Steuerungs- und Kommunikationsschritte.
C) Verkürzt das Verfahren fälschlicherweise auf reine Passivität ohne Planung.

D) Verkennt, dass PRINCE2 eine hochgradig strukturierte Methode mit festem Risikoprozess ist.

Project Brief [F] [Practices] 1 Unterseite →

☝️ Single Wann wird der "Projektkurzbeschreibung" erstellt und welchen Zweck erfüllt er?

✅ Er wird in "Starting up a Project" als grobe Grundlage für die Initiierung erstellt

❌ Er wird in "Closing a Project" als abschließende Zusammenfassung der Projektergebnisse für das Projektboard erstellt

❌ Er wird in "Controlling a Stage" als Steuerungsinstrument für die tägliche Überwachung der Arbeitspakete erstellt

❌ Er ist inhaltlich identisch mit der Project Initiation Documentation und wird nur zu Beginn aktualisiert

Der Project Brief wird im Prozess "Starting up a Project" erstellt. Er ist eine grobe Projektskizze, die dem Project Board als Entscheidungsgrundlage dient, ob sich die Initiierung (Initiating a Project) lohnt.

Merksatz:
Der Brief ist wie ein kurzer Brief vor der Reise: Er wird ganz am Anfang beim Starten (Starting up a Project) geschrieben, um grob zu klären, wohin die Reise geht, bevor man die detaillierte Route plant.

Closing a Project: Am Projektende ist es zu spät für eine Startgrundlage.
Controlling a Stage: In dieser Phase wird das Projekt bereits gesteuert, statt grob initiiert.

Identisch mit der PID: Der Brief ist nur das kurze Fundament; die PID ist das spätere, detaillierte Gesamtpaket der Initiierung.

Project Product Description [F] [Practices] 1 Unterseite →

☝️ Single Was beschreibt die "Projektproduktbeschreibung"?

✅ Das Gesamtprodukt des Projekts inklusive Abnahmekriterien

❌ Das Gesamtprodukt des Projekts inklusive der wichtigsten Meilensteintermine

❌ Das Gesamtprodukt des Projekts inklusive der geplanten Ressourcenzuteilung

❌ Das Gesamtprodukt des Projekts inklusive der Kommunikationswege im Team

Die Project Product Description beschreibt das Gesamtprodukt des Projekts inklusive Abnahmekriterien und ist die Grundlage für Umfang und Abnahme.

Merksatz:
Stell dir das Projekt-Produkt wie ein neues Auto vor: Die Beschreibung ist der Kaufvertrag, der das fertige Auto definiert und festlegt, welche TÜV-Kriterien (Abnahme) es für die Übergabe erfüllen muss.

Warum die anderen falsch sind:
B: Verwechselt das finale Lieferobjekt mit dem operativen Tagesgeschäft des Managers.
C: Reduziert das gesamte Produktergebnis fälschlicherweise auf reine Finanzdaten.

D: Verwechselt den sachlichen Projektgegenstand mit der personellen Teamstruktur.

Checkpoint Report [F] [Practices] 1 Unterseite →

☝️ Single Wer erstellt den "Teamstatusbericht" und an wen richtet er sich?

✅ Vom Teammanager an den Projektmanager

❌ Vom Projektmanager an das Lenkungsausschuss

❌ Vom Lenkungsausschuss an den Projektmanager

❌ Vom Teammanager an das Lenkungsausschuss

Der Checkpoint Report wird vom Team Manager erstellt und informiert den Project Manager über den Fortschritt eines Arbeitspakets.

Merksatz:
Der Teamleiter steht am Checkpoint und funkt den Statusbericht hoch zum Projektleiter (Team Manager an Project Manager).

Warum die anderen falsch sind:
B: Der Projektleiter berichtet an das Board mittels Highlight Report, nicht per Checkpoint Report.
C: Das Board lenkt strategisch von oben und schreibt keine operativen Statusberichte nach unten.

D: Der Teamleiter darf die Hierarchie nicht überspringen und berichtet niemals direkt an das Board.

End Project Report [F] [Practices] 1 Unterseite →

☝️ Single Was bewertet der "Projektabschlussbericht"?

✅ Die Projektleistung gegen die ursprüngliche PID

❌ Die Bewertung der Teammoral und der allgemeinen Zufriedenheit der Projektbeteiligten während der gesamten Projektlaufzeit

❌ Die Ermittlung des noch verfügbaren Budgets und dessen ausreichende Deckung für alle offenen Projektaktivitäten

❌ Die Erfassung der Gesamtzahl der abgeschlossenen Arbeitspakete im Vergleich zur ursprünglichen Projektplanung

Der End Project Report bewertet zum Projektabschluss die Projektleistung gegen die ursprüngliche PID und übergibt offene Punkte und Lessons.

Merksatz: Der Endbericht ist das Abschlusszeugnis: Er vergleicht das fertige Werk (Projektleistung) direkt mit dem ursprünglichen Lehrplan (der PID).

Warum die anderen falsch sind:
B: Ein reines „Gutfühl-Barometer“ der Teamstimmung greift für eine formelle Projektabnahme viel zu kurz.
C: Das Restbudget ist nur ein kleiner Finanz-Teilaspekt und ignoriert die erbrachten Leistungen völlig.

D: Reines To-Do-Listen-Abhaken sagt nichts über den tatsächlichen Projekterfolg und den gelieferten Wert aus.

Business Case Inhalte [F] [Practices] 1 Unterseite →

✌️ Multi Welche Elemente gehören typischerweise in einen Business Case? (Mehrfachauswahl)

✅ Erwarteter Nutzen (Benefits)

✅ Gründe für das Projekt

✅ Kosten und Risiken

❌ Die private Telefonliste des Executive

Ein Business Case enthält typischerweise die Gründe, die Optionen, den erwarteten Nutzen, die erwarteten Nachteile (Dis-benefits), Kosten, Zeiten und Risiken.

Merksatz:
Ein Business Case ist die Waagschale des Projekts: Auf der einen Seite liegen die Gründe und der erwartete Nutzen, auf der anderen die Kosten und Risiken. Nur wenn diese Bilanz stimmt, startet das Projekt.

Warum die anderen falsch sind:

D) Private Kontaktdaten verstoßen gegen den Datenschutz und haben im offiziellen, wirtschaftlichen Rechtfertigungsdokument nichts verloren.

Project Plan [F] [Practices] 1 Unterseite →

☝️ Single Welcher Plan dient dem Lenkungsausschuss als Kontrollinstrument für das Gesamtprojekt?

✅ Projektplan

❌ Phasenplan

❌ Team Plan

❌ Ausnahmeplan

Der Project Plan bietet eine Gesamtübersicht über das Projekt und dient dem Project Board als Kontrollinstrument.

Merksatz: Das Board steht an Bord und lenkt das ganze Schiff – dafür braucht es den großen Project Plan als Gesamtkarte.

Warum die anderen falsch sind:
Stage Plan: Zeigt nur eine einzelne Phase und ist zu kurzsichtig fürs Board.
Team Plan: Ist viel zu detailliert und nur für die operative Arbeitsebene gedacht.

Exception Plan: Wird nur im Notfall bei Toleranzüberschreitungen als Sonderplan aktiv.

Benefits Realisierung [F] [Practices] 1 Unterseite →

☝️ Single Wer ist primär für die Realisierung des Nutzens (Benefits) nach Projektende verantwortlich?

✅ Der Senior User

❌ Der Senior Supplier

❌ Der Teammanager

❌ Project Support

Der Senior User ist dafür verantwortlich, die Benefits zu spezifizieren und deren Realisierung nach Projektende im laufenden Betrieb sicherzustellen.

Merksatz:
Nur wer das Produkt am Ende täglich nutzt (der Senior User), kann auch den Nutzen (Benefit) ernten – der Anwender zieht den Gewinn, nicht der Ersteller.

Warum die anderen falsch sind:
Senior Supplier: Liefert nur die Ressourcen und das Produkt, nutzt es aber nach Projektende nicht selbst.
Team Manager: Führt nur die operative Erstellung während des Projekts und hat danach keine Rolle mehr.

Project Support: Bietet nur administrative Hilfe und trägt keinerlei Verantwortung für Geschäftsziele.

Business Case [Practices] 6 Unterseite →

☝️ Single Was ist der Zweck der Practice 'Business Case'?

❌ Sicherstellen, dass die Projektteammitglieder ihre Aufgaben gemäß den vereinbarten Zeitplänen ausführen

❌ Sicherstellen, dass die Projektprodukte gemäß den spezifizierten technischen Anforderungen hergestellt werden

✅ Sicherstellen, dass das Projekt eine begründete, lohnende Investition bleibt

❌ Sicherstellen, dass die Projektorganisation die richtigen Fähigkeiten für die Durchführung der Arbeiten bereitstellt

Die Business-Case-Practice entwickelt und prüft fortlaufend die Rechtfertigung.

Merksatz:
Der Business Case ist die Brille des Investors: Sie zeigt dir im Projektverlauf permanent, ob das Vorhaben eine lohnende und begründete Investition bleibt oder zum Geldgrab wird.

Warum die anderen falsch sind:
A: Die technische Erstellung steuert die Produktentwicklung, nicht die Wirtschaftlichkeit.
B: Qualitätskriterien prüft das Qualitätsmanagement, was eine eigenständige Practice ist.

D: Die Teamzusammensetzung regelt das Ressourcen- und Personalmanagement.

☝️ Single Welche drei Eigenschaften prüft ein tragfähiger Business Case?

❌ Rentabel, ressourcenschonend und langfristig stabil

❌ Umsetzbar, innerhalb von Zeit- und Kostenrahmen

❌ Sinnvoll, nachvollziehbar und prüfbar

✅ Wünschenswert, machbar und erreichbar (desirable, viable, achievable)

Ein Projekt muss wünschenswert, machbar und erreichbar sein, um gerechtfertigt zu sein.

Merksatz: Ein tragfähiger Business Case ist wie deine Traumreise: Du musst sie wünschen (desirable), finanzieren können (machbar/viable) und das Ziel auch tatsächlich erreichen (achievable).

Warum die anderen falsch sind:
A: Reine Statussymbole, die weder Nutzen noch wirtschaftliche Tragfähigkeit garantieren.
B: Naives Wunschdenken, das die strategische und finanzielle Realität im Projektalltag ignoriert.

C: Reine Trend-Buzzwords, die keine Aussagekraft über den tatsächlichen Geschäftswert haben.

☝️ Single Wer ist für den Business Case hauptverantwortlich?

❌ Project Support

✅ Der Executive

❌ Der Senior Supplier

❌ Der Teammanager

Der Executive verantwortet den Business Case über den gesamten Projektverlauf.

Merksatz: Der Executive (Chef) hütet den Business Case wie sein eigenes Sparbuch – nur er trägt die finanzielle Gesamtverantwortung für den Projekterfolg.

Warum die anderen falsch sind:
Project Support: Erledigt nur administrative Zuarbeit ohne jede Entscheidungsmacht.
Senior Supplier: Vertritt nur die Lieferantenseite und sichert die technische Machbarkeit.

Team Manager: Fokussiert sich rein auf die operative Umsetzung der Arbeitspakete.

☝️ Single Was ist ein Dis-benefit?

❌ Ein besonders großer, über den Erwartungen liegender positiver Effekt eines Projektergebnisses

✅ Eine als negativ empfundene, messbare Folge eines Projektergebnisses

❌ Ein potenzielles Ereignis, das den Projekterfolg gefährden könnte und daher aktiv gesteuert werden muss

❌ Ein Arbeitspaket, das ohne formale Genehmigung durchgeführt wurde und daher als negativ bewertet wird

Dis-benefits sind im Business Case gegen die Benefits abzuwägen.

Merksatz:
Ein Dis-benefit ist die Dis-harmonie nach dem Projekt: Eine messbare, negative Folge, die sicher eintritt (wie der höhere Spritverbrauch nach dem Kauf eines größeren Dienstwagens).

Warum die anderen falsch sind:
A: "Dis" signalisiert das Gegenteil von Nutzen, nicht dessen Steigerung.
C: Ein Risiko ist unsicher, während ein Dis-benefit eine sichere Folge ist.

D: Arbeitspakete betreffen die operative Umsetzung, nicht die strategische Wirkung des Ergebnisses.

☝️ Single Wann wird der Business Case im Projektverlauf typischerweise aktualisiert?

✅ An den Phasenübergängen (in 'Managen eines Phasenübergangs')

❌ Der Business Case wird ausschließlich im Rahmen der Initiierungsphase erstellt und danach nicht mehr verändert, da alle weiteren Entscheidungen auf dieser ursprünglichen Version basieren.

❌ Eine Aktualisierung erfolgt nur bei der abschließenden Projektbewertung, wenn der Business Case rückblickend für das Projektende dokumentiert und archiviert wird.

❌ Der Teammanager überprüft den Business Case bei jedem Arbeitsschritt und passt ihn kontinuierlich an, um den aktuellen Ist-Zustand der Lieferobjekte widerzuspiegeln.

An jedem Phasenübergang wird der Business Case auf Aktualität geprüft.

Merksatz: Der Business Case ist das Bahnticket für dein Projekt: An jedem Phasenübergang (Schranke) wird er abgestempelt (aktualisiert), um zu prüfen, ob sich die Weiterfahrt noch lohnt.

Warum die anderen falsch sind:
B) Ein starres Dokument ignoriert Marktveränderungen und führt unkontrolliert zu Fehlinvestitionen.
C) Am Projektende ist eine Aktualisierung nutzlos, da Fehlentwicklungen dann nicht mehr korrigiert werden können.

D) Tägliche Updates erzeugen nur bürokratischen Overkill, zudem verantwortet der Team Manager nur Arbeitspakete, nicht den Projektnutzen.

☝️ Single Was beschreibt der Benefits-Management-Ansatz?

❌ Wie und wann die identifizierten Risiken im Projektverlauf bewertet und überprüft werden

❌ Wie und wann die benötigten Projektteammitglieder ausgewählt und zusammengestellt werden

❌ Wie und wann die definierten Arbeitspakete an die ausführenden Teams vergeben und freigegeben werden

✅ Wie und wann die erwarteten Benefits gemessen und überprüft werden

Benefits werden oft erst nach Projektende realisiert und gemessen; der Ansatz regelt das.

Merksatz:
Stell dir eine Waage vor, auf der du regelmäßig prüfst, ob deine geernteten Früchte (Benefits) das versprochene Gewicht haben – es geht um das Wie und Wann des Messens.

Warum die anderen falsch sind:
A) Risikobewertung gehört zum Risikomanagement, nicht zur Nutzenrealisierung.
B) Teamzusammenstellung betrifft die Ressourcenplanung und soziale Kompetenzen.

C) Die Vergabe von Arbeitspaketen ist Teil der Ablauf- und Terminplanung.

Organizing [Practices] 5 Unterseite →

☝️ Single Was ist der Zweck der Practice 'Organizing'?

❌ Die Projektorganisation mit klaren Rollen und Verantwortlichkeiten festlegen

✅ Die Projektorganisation mit klaren Rollen und Verantwortlichkeiten definieren

❌ Die Projektstruktur mit detaillierten Aufgaben und Befugnissen beschreiben

❌ Die Projektmitarbeiter mit definierten Kompetenzen und Zuständigkeiten ausstatten

Organizing (früher Organization) regelt, wer wofür verantwortlich und rechenschaftspflichtig ist.

Merksatz: Stell dir ein Fußballteam vor: „Organizing“ verteilt die Trikots und bestimmt, wer im Sturm steht und wer im Tor bleibt – es klärt also, wer welche Rolle und Verantwortung im Team hat.

Warum die anderen falsch sind:
A) Technische Erstellung ist Sache der Fachspezialisten (z. B. „Scope“), nicht der Teamstruktur.
C) Die Zeitberechnung gehört zur Practice „Time“ (Terminmanagement).

D) Die Risikobewertung ist Aufgabe von „Risk and Opportunity“.

☝️ Single Aus welchen Rollen besteht das Lenkungsausschuss?

❌ Executive, Projektmanager und Teammanager

❌ Projektmanager, Teammanager und Support

✅ Executive, Senior User und Senior Supplier

❌ Senior User, Teammanager und Assurance

Das Board vertritt die drei Interessen Business, User und Supplier.

Merksatz:
Das Board fliegt First Class (C): Der Chef (Executive) reist nur mit dem Nutzer (Senior User) und dem Lieferanten (Senior Supplier).

Warum die anderen falsch sind:
A: Der Project Manager leitet operativ und sitzt nicht selbst im übergeordneten Board.
B: Manager und Support bilden die operative Umsetzungsebene, nicht die strategische Lenkung.

D: Team Manager steuern Arbeitspakete und Assurance ist eine reine Überwachungsfunktion.

☝️ Single Welche Board-Rolle ist immer mit genau einer Person besetzt?

❌ Project Assurance

❌ Der Senior User

✅ Der Executive

❌ Der Senior Supplier

Senior User und Senior Supplier können mehrfach besetzt sein, der Executive ist immer eine Einzelperson.

Merksatz:
Der Executive ist der König im Projekt-Schach: Es kann nur einen geben, der die Letztverantwortung trägt und den Hut aufhat.

Warum die anderen falsch sind:
Project Assurance: Kann auf mehrere Personen für Business, User und Supplier aufgeteilt werden.
Der Senior User: Vertritt oft verschiedene Nutzergruppen und wird daher häufig von mehreren Personen besetzt.

Der Senior Supplier: Kann mehrere interne und externe Lieferanten gleichzeitig im Board repräsentieren.

☝️ Single Was ist die Aufgabe von Project Assurance?

❌ Unabhängig vom Projektmanager die tägliche Steuerung der Teammitglieder übernehmen und deren Arbeitsergebnisse kontrollieren

✅ Unabhängig im Auftrag des Boards prüfen, ob die Interessen gewahrt werden

❌ Die fachliche Verantwortung für die Erstellung der Projektergebnisse übernehmen und diese direkt selbst herstellen

❌ Die endgültige Entscheidung über den Business Case treffen und dessen Wirtschaftlichkeit eigenständig festlegen

Assurance ist eine unabhängige Board-Funktion, getrennt vom Project Manager.

Merksatz: Project Assurance ist der neutrale Wachhund des Project Boards: Er schnüffelt unabhängig herum, um die Interessen der Auftraggeber abzusichern (Assurance), ohne selbst mitzuspielen.

Warum die anderen falsch sind:
A: Das tägliche Führen der Teams ist die operative Aufgabe des Projektleiters.
C: Die Erstellung der Produkte liegt allein beim Projektteam.

D: Die Entscheidung über den Business Case trifft exklusiv das Project Board selbst.

☝️ Single Welche drei Projektinteressen bildet die Projektorganisation ab?

❌ Risiko, Issue und Change

❌ Vorstand, PMO und Kunde

✅ Business, User und Supplier

❌ Zeit, Kosten und Qualität

Business-, User- und Supplier-Interessen müssen in der Organisation vertreten sein.

Merksatz: Stell dir die Projektorganisation wie einen BUS vor: Business (zahlt), User (nutzt) und Supplier (liefert) müssen alle an Bord sein, um das Ziel sicher zu erreichen.

Warum die anderen falsch sind:
A: Sind dynamische Steuerungsereignisse im Projektverlauf, keine strukturellen Interessen.
B: Bezeichnet konkrete Rollen und Abteilungen statt der drei fundamentalen Interessengruppen.

D: Beschreibt die Dimensionen des Magischen Dreiecks der Projektziele, nicht die Organisation.

Plans [Practices] 6 Unterseite →

☝️ Single Was ist der Zweck der Practice 'Plans'?

❌ Festlegen, wie und wann Risiken im Projektverlauf bewertet und behandelt werden

❌ Festlegen, wie und wann die Mitglieder des Lenkungsausschusses ihre Aufgaben wahrnehmen

❌ Festlegen, wie und wann die einzelnen Projektergebnisse formal freigegeben und übernommen werden

✅ Festlegen, wie und wann Produkte, Kosten und Termine erreicht werden

Die Plans-Practice beschreibt, wer, was, wann, wie und zu welchen Kosten liefert.

Merksatz:
Wer plant, baut die Brücke: Er legt fest, wie und wann die Produkte im Kosten- und Zeitrahmen geliefert werden.

Warum die anderen falsch sind:
A: Gehört zur Practice "Risk and Opportunity" und nicht zur Ablaufplanung.
B: Ist Teil der Aufbauorganisation ("Organisation") und keine Planungsaufgabe.

C: Ist Aufgabe der Qualitätssicherung ("Quality") oder des Kunden, nicht der reinen Planung.

☝️ Single Welche Planebenen kennt PRINCE2?

✅ Projektplan, Phasenplan, Teamplan und Ausnahmeplan

❌ Gesamtplan, Phasenplan und Teamplan, wobei der Gesamtplan alle weiteren Ebenen ersetzt

❌ Grobplan, Detailplan und ein separater Risikoplan, die unabhängig voneinander erstellt werden

❌ Ein einziger umfassender Plan, der alle Projektaktivitäten auf einer Ebene zusammenfasst

PRINCE2 unterscheidet Projekt-, Phasen-, Team- und (bei Bedarf) Ausnahmeplan.

Merksatz:
Der Prinz (PRINCE2) plant das Projekt, teilt es in Phasen, delegiert ans Team und rettet die Ausnahme!

Warum die anderen falsch sind:
B: Grob- und Feinplanung sind rein informelle Begriffe und keine definierten PRINCE2-Ebenen.
C: Tages- und Wochenpläne sind zu kleinteilig für das strategische PRINCE2-Framework.

D: Ein einziger Gesamtplan widerspricht dem PRINCE2-Prinzip der „Steuerung über Managementphasen“.

☝️ Single Was ist das Grundprinzip der produktbasierten Planung?

❌ Zuerst die Aktivitäten und deren Reihenfolge festlegen, die benötigten Produkte ergeben sich daraus automatisch

❌ Die Planung ausschließlich auf der Grundlage der verfügbaren Kosten durchführen, ohne Berücksichtigung der zu erstellenden Ergebnisse

✅ Zuerst die zu liefernden Produkte definieren, dann die Aktivitäten ableiten

❌ Nur die zeitlichen Abhängigkeiten der Meilensteine betrachten, ohne einen Bezug zu den konkreten Liefergegenständen herzustellen

Produktbasierte Planung leitet Aktivitäten aus den definierten Produkten ab.

Merksatz:
Erst das fertige Backwerk (Produkt) vor Augen haben, dann die Zutaten rühren (Aktivität) – ohne klares Lieferobjekt läuft jede Arbeit ins Leere.

Warum die anderen falsch sind:
A) verwechselt Ursache und Wirkung, da Aktivitäten ohne definiertes Zielprodukt planlos sind.
B) fokussiert blind nur auf Finanzen und ignoriert den eigentlichen Projektgegenstand.

D) plant Termine im luftleeren Raum ohne konkreten Bezug zu den Ergebnissen.

☝️ Single Was zeigt der Produktstrukturplan (PBS)?

❌ Die zeitliche Abfolge der einzelnen Arbeitsschritte innerhalb des Projektablaufs

❌ Die Aufteilung der geplanten Gesamtkosten auf die einzelnen Projektphasen

❌ Die Zuordnung der Projektrollen zu den Mitgliedern des Lenkungsausschusss

✅ Die hierarchische Zerlegung des Gesamtprodukts in Teilprodukte

Der PBS ist ein Kernschritt der produktbasierten Planung.

Merksatz:
Stell dir den PBS wie einen Lego-Bausatz vor: Er zerlegt das fertige Modell (Gesamtprodukt) hierarchisch in seine einzelnen Steine (Teilprodukte) – ganz ohne Zeitdruck oder Kosten.

Warum die anderen falsch sind:
A ist falsch: Die zeitliche Abfolge zeigt der Terminplan (z. B. Gantt-Chart), nicht die Produktstruktur.
B ist falsch: Die Kostenverteilung gehört in den Kosten- und Budgetplan.

C ist falsch: Rollen und Zuständigkeiten regelt das Projektorganigramm oder die RAM (Rollenmatrix).

☝️ Single Was zeigt das Produktflussdiagramm?

❌ Die zeitliche Abfolge der geplanten Risikoreaktionsmaßnahmen im Projektverlauf

✅ Die Erstellungsreihenfolge und Abhängigkeiten der Produkte

❌ Die vollständige Auflistung aller am Projekt beteiligten Personen und Gruppen

❌ Die hierarchische Darstellung der Verantwortlichkeiten und Berichtswege im Projektteam

Aus dem Produktflussdiagramm wird die Aktivitätenplanung abgeleitet.

Merksatz:
Der Produkt-Fluss ist wie ein Flusslauf: Er zeigt, welches Produkt zuerst (Reihenfolge) entsteht und wie sie logisch zusammenhängen (Abhängigkeiten).

Warum die anderen falsch sind:
A) Das Risikobudget wird im Risikomanagement berechnet, nicht im Produktplan.
C) Personen (Stakeholder) stehen in der Stakeholderliste, nicht im Produktfluss.

D) Die Teamstruktur zeigt das Organigramm (OBS), nicht der Ablauf der Produkte.

☝️ Single Wann wird ein Ausnahmeplan (Ausnahmeplan) erstellt?

❌ Wenn ein Arbeitspaket von einem Teammanager eine Abweichung von der geplanten Toleranz meldet, muss für dieses Paket ein Ausnahmeplan erstellt werden, um die Abweichung zu dokumentieren.

❌ Wenn der Projektabschlussbericht erstellt wird, muss ein Ausnahmeplan die endgültigen Ergebnisse und Abweichungen des gesamten Projekts zusammenfassen.

✅ Wenn eine genehmigte Baseline nach einer Exception ersetzt werden muss

❌ Zu Beginn jeder Managementstufe wird routinemäßig ein Ausnahmeplan erstellt, um die nächste Phase detailliert zu planen und abzusichern.

Der Ausnahmeplan ersetzt nach Genehmigung den überschrittenen Plan.

Merksatz:
Der Ausnahmeplan (Exception Plan) ist der „Rettungsschirm“: Er wird erst aufgespannt, wenn das Projekt aus den Fugen gerät (Toleranzüberschreitung) und die alte, genehmigte Baseline durch eine neue ersetzt werden muss.

Warum die anderen falsch sind:
Arbeitspaket: Hierfür nutzt man Teampläne, ein Ausnahmeplan wäre viel zu bürokratisch.
Projektabschluss: Am Ende wird das Projekt geschlossen und kein neuer Plan mehr erstellt.

Routine zu Phasenbeginn: Zu jedem Phasenübergang wird routinemäßig ein normaler Phasenplan (Stage Plan) erstellt, kein Ausnahmeplan.

Quality [Practices] 6 Unterseite →

☝️ Single Was ist der Zweck der Practice 'Quality'?

❌ Sicherstellen, dass die Projektteams effektiv zusammenarbeiten und ihre Aufgaben eigenverantwortlich umsetzen

✅ Sicherstellen, dass die Produkte die Anforderungen und Abnahmekriterien erfüllen

❌ Sicherstellen, dass alle projektbezogenen Risiken auf externe Parteien übertragen werden, um Verluste zu vermeiden

❌ Sicherstellen, dass die Projektkosten durch effiziente Ressourcennutzung und Prozessoptimierung minimiert werden

Quality regelt Qualitätskriterien, -methoden und -kontrollen.

Merksatz:
Qualität ist der strenge Türsteher: Er lässt das Produkt nur durch, wenn es exakt dem Bauplan (Anforderungen) entspricht und den Stempel (Abnahmekriterien) erhält.

Warum die anderen falsch sind:
A) Verwechselt Qualität mit Teamführung (Leadership).
C) Verwechselt Qualität mit Risikotransfer (Risikomanagement).

D) Verwechselt Qualität mit Budgetkontrolle (Kostenmanagement).

☝️ Single Worin unterscheiden sich Qualitätssicherung und Qualitätskontrolle?

✅ Sicherung prüft unabhängig das Qualitätsmanagement, Kontrolle prüft die Produkte selbst

❌ Die Sicherung überwacht ausschließlich die Einhaltung des Projektbudgets, während die Kontrolle sich auf die termingerechte Lieferung der Projektergebnisse konzentriert.

❌ Qualitätssicherung und Qualitätskontrolle sind in PRINCE2 zwei Begriffe für denselben Prozess, der die Einhaltung der Qualitätsstandards im gesamten Projektverlauf überwacht.

❌ Die Qualitätskontrolle ist eine reine Aufgabe des Projektausschusses, der die Produkte nach Fertigstellung prüft und über deren Freigabe entscheidet.

Quality Assurance ist unabhängig; Quality Control prüft Produkte gegen ihre Kriterien.

Merksatz:
Die Sicherung baut die sichere Straße (das QM-System), die Kontrolle stoppt das einzelne Auto (das Produkt).

Warum die anderen falsch sind:
B: Qualitätssicherung ist kein Finanz-Controlling und fokussiert Prozesse, nicht primär Kosten.
C: Sicherung (präventiv/systemisch) und Kontrolle (reaktiv/produktspezifisch) sind prozessual klar getrennt.

D: Produktkontrollen finden operativ im Projekt oder der Produktion statt, nicht auf Vorstandsebene.

☝️ Single Wo sind die Qualitätskriterien eines Produkts festgehalten?

❌ Im Projektstatusbericht

❌ Im Daily Log

✅ In der Produktbeschreibung

❌ Im Risikoregister

Die Product Description enthält Zweck, Zusammensetzung sowie Qualitäts- und Abnahmekriterien.

Merksatz:
Die Product Description ist der „Steckbrief“ des Produkts – nur wer die Beschreibung liest, kennt die geforderten Eigenschaften und Qualitätskriterien.

Warum die anderen falsch sind:
A) Highlight Report: Ist ein reiner Statusbericht für den Lenkungsausschuss, kein Produktdokument.
B) Daily Log: Dient als informelles Tagebuch des Projektleiters für tägliche Ereignisse.

D) Risikoregister: Erfasst potenzielle Bedrohungen und Chancen, keine konkreten Produktanforderungen.

☝️ Single Was beschreibt die Projektproduktbeschreibung?

✅ Das Gesamtprodukt des Projekts inklusive der Abnahmekriterien

❌ Die vollständige Beschreibung aller Arbeitspakete, die an die Projektmitarbeiter übergeben werden

❌ Die detaillierte Darstellung der Entscheidungsbefugnisse und Verantwortlichkeiten des Projektausschusses

❌ Die umfassende Auflistung aller Berichtswege und Informationsflüsse innerhalb des Projekts

Sie ist Grundlage für Umfang und die finale Abnahme des Projekts.

Merksatz:
Stell dir das Project Product als das fertige Paket vor, das der Kunde am Ende auspackt – inklusive des Prüfzettels (Abnahmekriterien), ob alles perfekt ist.

Warum die anderen falsch sind:
B) ist falsch, weil ein Arbeitspaket nur ein winziges Puzzleteil beschreibt, nicht das große Ganze.
C) ist falsch, weil Projektrollen die Organisation regeln und nichts über das Produkt aussagen.

D) ist falsch, weil der Kommunikationsplan den Informationsfluss steuert, nicht die Produktqualität.

☝️ Single Was dokumentiert das Qualitätsregister?

❌ Die vollständige Auflistung aller identifizierten Stakeholder und ihrer Kommunikationsbedürfnisse

✅ Geplante und durchgeführte Qualitätsprüfungen und deren Ergebnisse

❌ Die Dokumentation aller eingereichten Änderungsanträge inklusive ihres aktuellen Bearbeitungsstatus

❌ Die Erfassung sämtlicher Projektrisiken mit ihrer Eintrittswahrscheinlichkeit und Auswirkung

Das Qualitätsregister ist ein Record und belegt die Qualitätsaktivitäten.

Merksatz:
Das Qualitätsregister ist das TÜV-Prüfbuch des Projekts: Es plant die nächste Inspektion, dokumentiert die Prüfung und hält das Ergebnis (Plakette oder Mängel) fest.

Warum die anderen falsch sind:
A) Stakeholder werden im Stakeholderregister erfasst, da sie Personen und keine Qualitätsmerkmale sind.
C) Änderungen werden im Änderungsregister (Change Log) gesteuert, um den Projektumfang zu kontrollieren.

D) Risiken gehören ins Risikoregister, um Bedrohungen und Chancen strukturiert zu managen.

☝️ Single Was ist die Qualitätsprüfungstechnik (Quality Review)?

❌ Ein standardisiertes Vorgehen, um die Risiken eines Projekts systematisch zu bewerten

❌ Ein formaler Prozess zur Auswahl der geeigneten Projektteammitglieder

❌ Eine detaillierte Methode zur Berechnung der voraussichtlichen Projektkosten

✅ Ein strukturiertes Verfahren, um Produkte gegen ihre Qualitätskriterien zu prüfen

Die Quality-Review-Technik prüft Produkte mit definierten Rollen strukturiert.

Merksatz: Stell dir den Quality Review wie den TÜV fürs Produkt vor: Jedes Teil wird streng nach Checkliste (Qualitätskriterien) auf Herz und Nieren geprüft.

Warum die anderen falsch sind:
A) Risikobewertung analysiert zukünftige Bedrohungen, keine fertigen Produkte.
B) Teamauswahl regelt die Personalbesetzung, nicht die Produktgüte.

C) Kostenschätzung kalkuliert Finanzen und prüft keine Qualitätsstandards.

Risk [Practices] 6 Unterseite →

☝️ Single Was ist der Zweck der Practice 'Risk'?

❌ Die geplanten Projektergebnisse formal abnehmen und freigeben

❌ Die vorgesehenen Projektrollen eindeutig besetzen und zuweisen

❌ Die angefallenen Projektkosten vollständig erfassen und verbuchen

✅ Unsicherheiten identifizieren, bewerten und steuern

Die Risk-Practice steuert Bedrohungen und Chancen über den Projektverlauf.

Merksatz:
Stell dir das Risiko-Radar vor: Wie ein Kapitän im Nebel musst du unsichtbare Klippen Identifizieren, ihre Gefahr Bewerten und das Schiff sicher vorbeiSteuern (I-B-S).

Warum die anderen falsch sind:
A) Produkte abnehmen ist Aufgabe der Qualitätssicherung oder des Projektabschlusses.
B) Rollen besetzen betrifft die Teamorganisation und das Ressourcenmanagement.

C) Kosten buchen ist reine Buchhaltung und nachträgliches Controlling.

☝️ Single Welche zwei Arten von Risiken unterscheidet PRINCE2?

❌ Große und kleine Issues

✅ Bedrohungen und Chancen

❌ Geplante und ungeplante Phasen

❌ Interne und externe Kosten

Risiken können sich negativ (Bedrohung) oder positiv (Chance) auswirken.

Merksatz:
Der Prinz (PRINCE2) trägt eine zweifarbige Brille: Ein Glas warnt vor Bedrohungen (negativ), das andere sucht nach Chancen (positiv).

Warum die anderen falsch sind:
A) Issues sind bereits eingetretene Probleme und keine zukünftigen Risiken.
C) Phasen strukturieren den Projektverlauf zeitlich, sind aber keine Risikoarten.

D) Kosten sind finanzielle Auswirkungen und keine Risikokategorien.

☝️ Single Welche Reaktion auf eine Bedrohung ist in PRINCE2 vorgesehen?

❌ Die Bedrohung wird durch eine sofortige Erhöhung des Projektbudgets neutralisiert, ohne dass weitere Maßnahmen zur Risikominimierung ergriffen werden.

❌ Das Projekt wird umgehend abgebrochen, um die Bedrohung vollständig zu eliminieren, unabhängig von möglichen Alternativen zur Risikobewältigung.

❌ Die Bedrohung wird bewusst ignoriert, da davon ausgegangen wird, dass sie sich im Projektverlauf von selbst auflöst und keine aktive Steuerung erforderlich ist.

✅ Vermeiden, Reduzieren, Übertragen, Teilen, Akzeptieren oder Notfallplan vorbereiten

PRINCE2 kennt mehrere Bedrohungsreaktionen, je nach Art und Schwere des Risikos.

Merksatz:
Gegen Bedrohungen hilft das V-R-Ü-T-A-N-Schutzschild: Vermeiden, Reduzieren, Ubertragen, Teilen, Akzeptieren oder Notfallplan vorbereiten – ein ganzer Werkzeugkoffer statt nur einer einzigen Notbremse!

Warum die anderen falsch sind:
Nur die Kosten erhöhen: Dies ist eine reine Budgetmaßnahme und löst weder die Ursache noch das Risiko selbst aktiv.
Nur das Projekt sofort beenden: Das ist die absolute Eskalationsstufe und ignoriert alle wirtschaftlichen Steuerungsmöglichkeiten eines aktiven Risikomanagements.

Ausschließlich Ignorieren: Ignorieren ist fahrlässig und keine strukturierte PRINCE2-Reaktion (nicht zu verwechseln mit dem bewussten, dokumentierten „Akzeptieren“).

☝️ Single Welche Reaktion auf eine Chance ist in PRINCE2 vorgesehen?

❌ Chancen werden grundsätzlich nur durch das Erstellen von Notfallplänen behandelt, um im Eintrittsfall sofort reagieren zu können.

❌ Die einzige vorgesehene Reaktion auf eine Chance besteht darin, sie vollständig zu vermeiden, um Risiken im Projekt zu minimieren.

❌ Chancen sollten ausschließlich an eine externe Stelle übertragen werden, damit das Projektteam sich auf die Kernaufgaben konzentrieren kann.

✅ Nutzen, Verstärken, Teilen, Ablehnen oder Akzeptieren

Für Chancen gibt es eigene Reaktionen wie Nutzen (exploit) oder Verstärken (enhance).

Merksatz:
Wenn dir das Schicksal ein Geschenk (eine Chance) anbietet, kannst du es nutzen, seine Wirkung verstärken, es mit anderen teilen, es dankend ablehnen oder einfach gelassen akzeptieren – das ist die fünfgliedrige Chancen-Klaviatur von PRINCE2.

Warum die anderen falsch sind:
A) „Vermeiden“ bekämpft negative Bedrohungen, statt positive Chancen zu realisieren.
B) Ein „Notfallplan“ dient der Schadensbegrenzung bei Risiken, nicht dem proaktiven Nutzen von Chancen.

C) „Übertragen“ ist nur eine von mehreren Optionen und schränkt das aktive Gestalten zu stark ein.

☝️ Single Worin unterscheiden sich Risk Owner und Risk Actionee?

❌ Der Owner ist für die Überwachung zuständig, während der Actionee ausschließlich strategische Entscheidungen trifft und nie operativ tätig wird.

❌ Nur der Owner darf Maßnahmen ergreifen, der Actionee hat lediglich eine beratende Funktion und darf keine konkreten Schritte einleiten.

✅ Der Owner verantwortet ein Risiko, der Actionee führt eine konkrete Maßnahme aus

❌ In PRINCE2 sind Risk Owner und Risk Actionee immer dieselbe Person, da beide Rollen untrennbar miteinander verbunden sind.

Die Verantwortung (Owner) und die Ausführung einzelner Maßnahmen (Actionee) können getrennt sein.

Merksatz:
Der Owner (Besitzer) hat den Hut auf und verantwortet das Risiko, während der Actionee die Action (Maßnahme) ausführt. (Denke an den Hausbesitzer, der für das kaputte Dach haftet, und den Dachdecker, der es repariert).

Warum die anderen falsch sind:
A: Falsch, da der Actionee aktiv handelt und der Owner keineswegs zur Untätigkeit verdammt ist.
B: Falsch, weil der Actionee explizit dafür da ist, die zugewiesene Maßnahme umzusetzen.

D: Falsch, da die Trennung in zwei Personen im Projektalltag zur Arbeitsentlastung absolut üblich ist.

☝️ Single Wo werden identifizierte Risiken erfasst?

❌ Im Qualitätsregister

❌ Im Issue-Register

❌ Im Daily Log

✅ Im Risikoregister

Das Risikoregister führt Bedrohungen und Chancen mit Bewertung und Maßnahmen.

Merksatz:
Ein Risiko parkt immer im Risikoregister – gleicher Name, gleicher Parkplatz!

Warum die anderen falsch sind:
Qualitätsregister: ...fokussiert die Produktqualität, nicht potenzielle Bedrohungen.
Issue-Register: ...dokumentiert bereits eingetretene Probleme, keine zukünftigen Unsicherheiten.

Daily Log: ...ist nur ein informelles Projekttagebuch für den Alltag.

Issues [Practices] 6 Unterseite →

☝️ Single Was ist der Zweck der Practice 'Issues'?

❌ Die geplanten Lieferobjekte in einem Projekt strukturiert und terminlich festzulegen

❌ Die Projektteams hinsichtlich ihrer Aufgaben und Verantwortlichkeiten zu koordinieren

❌ Die erwarteten und realisierten Vorteile des Projekts systematisch zu erfassen und auszuwerten

✅ Issues behandeln und Änderungen an den Baselines kontrolliert steuern

Issues (früher Change) regelt den kontrollierten Umgang mit Issues und Änderungen.

Merksatz: Ein Issue (Problem) bringt das Projekt ins Wanken – du musst es sofort behandeln und den Kurs (Baseline) kontrolliert anpassen, damit das Schiff nicht sinkt.

Warum die anderen falsch sind:
A) Produktplanung gehört zur Practice "Leistungsumfang", nicht zur aktuellen Problembewältigung.
B) Teamführung ist eine soziale Kompetenz (People), kein technischer Prozess für Sachprobleme.

C) Nutzenmessung betrifft die langfristige Wirkung (Benefits), nicht akute Störungen im Projektablauf.

☝️ Single Welche drei Arten von Issues unterscheidet PRINCE2?

❌ Änderungsantrag, Vorfall und Ausnahmesituation

✅ Änderungsantrag, Off-Specification und Problem/Anliegen

❌ Projektauftrag, Phasenplan und Arbeitspaket

❌ Basislinie, Fortschrittsbericht und Abweichungsbericht

Diese drei Issue-Arten werden unterschiedlich behandelt.

Merksatz:
Das Problem-Schiff weicht vom Kurs ab (Off-Specification), weshalb die Crew eilig einen Änderungsantrag einreicht.

Warum die anderen falsch sind:
A) Verwechselt zukünftige Risiken (Bedrohung/Chance) mit bereits eingetretenen Issues.
C) Beschreibt die hierarchischen Managementebenen von PRINCE2, keine Vorfälle.

D) Bezeichnet Dokumenten- und Berichtstypen der Konfigurationsverwaltung.

☝️ Single Was ist eine Off-Specification?

✅ Ein Produkt, das eine Anforderung nicht (oder voraussichtlich nicht) erfüllt

❌ Ein Produkt, das eine zusätzliche Leistung enthält, die im Projektauftrag nicht vorgesehen war

❌ Ein Vorschlag, eine genehmigte Baseline nachträglich zu ändern oder anzupassen

❌ Ein Produkt, das einen besonders großen Nutzen für das Projekt oder die Organisation darstellt

Die Off-Specification ist eine der drei Issue-Arten: ein Mangel gegenüber der Baseline.

Merksatz:
Denk an das englische Wort „OFF“: Ein Produkt liegt völlig daneben und erfüllt die Spezifikation (Anforderung) nicht.

Warum die anderen falsch sind:
B) Verwechselt eine Mängel-Abweichung mit einer offiziell erlaubten Leistungserweiterung.
C) Beschreibt den formellen Änderungsantrag (Change Request) und nicht den physischen Mangel.

D) Setzt fälschlicherweise ein qualitatives Problem mit einem positiven Projektergebnis gleich.

☝️ Single Was ist ein Änderungsantrag (Request for Change)?

✅ Der Vorschlag, eine genehmigte Baseline zu ändern

❌ Die formale Dokumentation eines abgeschlossenen Arbeitspakets zur Archivierung

❌ Ein Bericht über ein Kommunikationsproblem innerhalb des Projektteams

❌ Ein Produkt, das eine definierte Anforderung nicht erfüllt

Der Änderungsantrag ist eine Issue-Art und unterliegt der Change Control.

Merksatz:
Der Änderungsantrag (Request for Change) ist der schriftliche Wunsch, eine bereits fest zementierte Basislinie (Baseline) wieder aufzubrechen und zu verändern – wie ein Bauantrag für ein bereits genehmigtes Haus.

Warum die anderen falsch sind:

Ein abgeschlossenes Arbeitspaket: Dies ist ein fertiges Projektergebnis (Deliverable) und kein Antrag auf Veränderung.

Ein reines Kommunikationsproblem: Dies beschreibt ein menschliches oder organisatorisches Missverständnis, kein formelles Änderungsbegehren.

Ein Produkt, das eine Anforderung verfehlt: Das ist eine Abweichung (Off-Specification) und kein gezielter Vorschlag zur Anpassung einer Baseline.

☝️ Single Wozu dient eine Änderungsinstanz?

❌ Um innerhalb eines Projektteams die täglichen Arbeitsabläufe zu koordinieren und die Teammitglieder zu motivieren

✅ Um innerhalb eines Änderungsbudgets über Änderungsanträge zu entscheiden

❌ Um die finanzielle Begründung des Projekts zu erstellen und den erwarteten Nutzen zu dokumentieren

❌ Um die geplanten Projektergebnisse zu entwickeln und die Qualität der Lieferobjekte sicherzustellen

Das Board kann Änderungsentscheidungen an eine Change Authority delegieren.

Merksatz:
Die Change Authority ist der Türsteher mit der Geldbörse: Sie entscheidet, welche Änderungswünsche (Änderungsanträge) mit dem vorhandenen Geld (Änderungsbudget) reingelassen werden.

Warum die anderen falsch sind:
A) Teamführung ist die Kernaufgabe der Projektleitung, nicht eines Änderungs-Gremiums.
C) Der Business Case wird strategisch vom Auftraggeber oder Initiator vorab erstellt.

D) Die Produkterstellung liegt operativ in den Händen der Projektmitarbeiter und Fachexperten.

☝️ Single Wo werden formal zu behandelnde Issues erfasst?

❌ Im Qualitätsregister

❌ Im Risikoregister

✅ Im Issue-Register

❌ Im Erfahrungsprotokoll

Formale Issues werden im Issue-Register geführt; informelle im Daily Log.

Merksatz:
Ein akutes Issue (Problem) gehört direkt ins Issue-Register – so wie ein Brief in den Briefkasten mit exakt demselben Namen gehört.

Warum die anderen falsch sind:
Qualitätsregister: Prüft die Qualität von Lieferobjekten, nicht aktuelle Probleme.
Risikoregister: Erfasst nur zukünftige, unsichere Ereignisse (Risiken), keine bereits eingetretenen Issues.

Lessons Log: Sammelt Lerneffekte für zukünftige Projekte, löst aber keine akuten Probleme.

Progress [Practices] 6 Unterseite →

☝️ Single Was ist der Zweck der Practice 'Progress'?

❌ Den Fortschritt der Projektdokumentation sicherstellen und die Qualität der erstellten Berichte überwachen

✅ Den Fortschritt gegen die Pläne überwachen und die Steuerung ermöglichen

❌ Die Einhaltung der vereinbarten Terminpläne kontrollieren und bei Abweichungen Korrekturmaßnahmen einleiten

❌ Die Leistung der Projektmitarbeiter bewerten und die Ergebnisse an das Projektteam kommunizieren

Progress überwacht den Fortschritt, prüft die Rechtfertigung und steuert über Toleranzen.

Merksatz: Stell dir „Progress“ wie ein GPS im Auto vor: Es vergleicht ständig deinen aktuellen Standort (Fortschritt) mit der Route (Plan), damit du richtig lenken (steuern) kannst.

Warum die anderen falsch sind:
A) Verwechselt die personelle Strukturierung (Organisation) mit der laufenden Projektkontrolle.
C) Verwechselt die rein technische Erstellung der Projektergebnisse mit deren übergeordneter Steuerung.

D) Verwechselt das gezielte Vorbeugen von Gefahren (Risikomanagement) mit dem allgemeinen Soll-Ist-Vergleich.

☝️ Single Auf welchen Ebenen werden in PRINCE2 Toleranzen gesetzt?

❌ Auf Projekt-, Phasen- und Teamebene, wobei die Teamebene die wichtigste Rolle spielt.

✅ Auf Projekt-, Phasen- und Arbeitspaketebene

❌ Auf Projekt- und Programmeebene, da Toleranzen nur auf strategischer Ebene festgelegt werden.

❌ Auf Projekt- und Unternehmensebene, um die Übereinstimmung mit der Geschäftsstrategie sicherzustellen.

Projekttoleranzen setzt das Board, Phasentoleranzen gelten in CS, Arbeitspakettoleranzen für den Team Manager.

Merksatz: Stell dir eine dreistufige Pyramide vor: Die Spitze ist das Projekt, die Mitte die Phase und die Basis das Arbeitspaket – auf allen drei Ebenen braucht es Spielraum (Toleranz) zum Atmen.

Warum die anderen falsch sind:
A) ...übersieht die notwendige Steuerung und Delegation von oben nach unten.
C) ...ignoriert das fundamentale PRINCE2-Prinzip „Steuern nach dem Ausnahmeprinzip“.

D) ...vernachlässigt den Handlungsspielraum für Phasen- und Teamleiter im Projektalltag.

☝️ Single Welche Berichte dienen der Fortschrittssteuerung?

✅ Projektstatusbericht, Teamstatusbericht und Phasenabschlussbericht

❌ Der Business Case, der Projektplan und der Nutzenbewertungsplan

❌ Die Produktbeschreibung, die Projektproduktbeschreibung und der Qualitätsmanagementansatz

❌ Der Projektauftrag, die Risikoliste und der Lessons-Log

Diese Reports informieren die jeweiligen Ebenen über den Fortschritt.

Merksatz: Stell dir eine Rallye vor: Die Highlights zeigen den Zwischenstand, die Checkpoints kontrollieren die Route und der End-Stage-Bericht feiert das Etappenziel – diese drei steuern deinen Fortschritt.

Warum die anderen falsch sind:
B) Der Business Case prüft nur die wirtschaftliche Tragfähigkeit, steuert aber nicht den operativen Fortschritt.
C) Die Product Description beschreibt lediglich die Produkteigenschaften, liefert aber keine Statusdaten.

D) Der Projektauftrag autorisiert das Projekt einmalig zu Beginn, statt es laufend zu überwachen.

☝️ Single Welche zwei Arten von Kontrollen unterscheidet PRINCE2 bei Progress?

❌ Manuelle und automatische Kontrollen

❌ Interne und externe Kontrollen

❌ Positive und negative Kontrollen

✅ Ereignisgesteuerte und zeitgesteuerte Kontrollen

Ereignisgesteuerte Kontrollen knüpfen an Ereignisse, zeitgesteuerte an feste Intervalle.

Merksatz:
Stell dir einen Wecker (zeitgesteuert) und einen Rauchmelder (ereignisgesteuert) vor, die den Projektfortschritt überwachen: Der Wecker klingelt regelmäßig, der Rauchmelder schlägt nur an, wenn etwas Bestimmtes passiert.

Warum die anderen falsch sind:
A) Manuelle/automatische: Unterscheidet nur die technische Ausführung, nicht aber den Steuerungsrhythmus von PRINCE2.
B) Interne/externe: Beschreibt die organisatorische Herkunft von Prüfern, nicht die Auslöser von Kontrollberichten.

C) Positive/negative: Ist ein psychologisches Feedback-Konzept und kein Steuerungsmechanismus im Projektmanagement.

☝️ Single Was prüft die Progress-Practice fortlaufend mit?

❌ Ob die im Projektplan festgelegten Meilensteine und Aktivitäten ausreichend detailliert beschrieben sind

✅ Ob die geschäftliche Rechtfertigung des Projekts weiterhin gilt

❌ Ob die im Projekt definierten Qualitätsstandards und Prüfverfahren den aktuellen Anforderungen entsprechen

❌ Ob die im Projekt vorgesehenen Ressourcen und Budgets für alle Arbeitspakete vollständig zugewiesen sind

Progress verknüpft Fortschritt mit der fortdauernden Rechtfertigung.

Merksatz:
Der Fortschritts-Zug fährt nur, solange am Ziel noch Gold (die geschäftliche Rechtfertigung) liegt – ohne Sinn kein Fortschritt!

Warum die anderen falsch sind:
A) Teamgröße: ...ist reine Ressourcenplanung, kein Maß für den inhaltlichen Projektfortschritt.
C) Dokumentenanzahl: ...erzeugt nur Bürokratie, sichert aber weder Qualität noch echten Projektwert.

D) Meetinganzahl: ...ist reine Aktivitätstherapie statt ergebnisorientierter und wertstiftender Steuerung.

☝️ Single Was ist eine Exception im Kontext der Progress-Practice?

❌ Ein geplanter Abschluss eines Management-Stages, der im Rahmen der regulären Steuerung durchgeführt wird

❌ Die formale Bestätigung, dass ein geliefertes Produkt alle vereinbarten Anforderungen erfüllt hat

✅ Eine voraussichtliche Überschreitung einer vereinbarten Toleranz

❌ Die Benennung einer zusätzlichen Person, die das Projektteam bei der Umsetzung unterstützt

Exceptions werden an die nächsthöhere Ebene eskaliert.

Merksatz:
Eine Exception (Ausnahme) ist wie ein Blitzerfoto: Es blitzt erst, wenn du die erlaubte Toleranzgrenze überschreitest.

Warum die anderen falsch sind:
A) Ein Phasenabschluss ist der planmäßige Regelfall und kein Abweichungsalarm.
B) Die Produktabnahme ist ein positives, geplantes Lieferergebnis und kein Steuerungsproblem.

D) Ein neues Teammitglied ist eine reine Personalressource ohne direkten Bezug zu Projekt-Toleranzgrenzen.

Die 7 Practices [Practices] 23 Unterseite →

☝️ Single Warum ist produktbasierte Planung (Product-Based Planning) in PRINCE2 wichtig?

✅ Sie beginnt mit der Definition der finalen Liefergegenstände

❌ Sie beginnt mit der Erstellung eines detaillierten Zeitplans für alle Projektaktivitäten

❌ Sie konzentriert sich auf die Minimierung der Projektdokumentation und -berichte

Richtig – dies schafft Klarheit über die Ergebnisse, bevor Aktivitäten geplant werden.

Merksatz:
Erst das fertige Haus zeichnen, dann die Steine stapeln: Produktbasierte Planung startet immer mit dem fertigen Endprodukt (Liefergegenstand), nicht mit den Aktivitäten.

Warum die anderen falsch sind:
B übersieht, dass Zeitpläne erst nach der Definition der Produkte entstehen können.
C verkennt, dass gerade Produktbeschreibungen eine präzise Dokumentation erfordern.

☝️ Single Welche der folgenden Optionen gehört NICHT zu den vier Planungsebenen in PRINCE2?

❌ Phasenplan (Phasenplan)

✅ Risikoplan

❌ Projektplan (Projektplan)

Richtig – es gibt keinen eigenständigen „Risikoplan“; Risiken werden innerhalb der Pläne gemanagt.

Merksatz:
PRINCE2 plant in Stufen, nicht in Gefahren: Projekt, Phase, Team und die Ausnahme haben einen Plan – das Risiko hat nur ein Register, aber keine eigene Planungsebene!

Warum die anderen falsch sind:
Phasenplan: Ist eine offizielle Ebene, da PRINCE2-Projekte zwingend in kontrollierbare Abschnitte unterteilt werden.
Projektplan: Ist die obligatorische Hauptebene, die dem Lenkungsausschuss die Gesamtübersicht über das Projekt liefert.

☝️ Single Was ist der Zweck einer Product Breakdown Structure (PBS)?

❌ Produkte in ihre wesentlichen Bestandteile zu gliedern

✅ Produkte in kleinere Bestandteile zu zerlegen

❌ Den zeitlichen Ablauf der Produkterstellung zu planen

Richtig – die PBS zeigt alle Liefergegenstände strukturiert auf.

Merksatz:
Denke bei PBS an ein Lego-Schloss: Du zerlegst das fertige Gesamtprodukt in seine einzelnen Bausteine (Bestandteile), um zu sehen, woraus es genau besteht.

Warum die anderen falsch sind:
A (Teamverantwortlichkeiten): Dies regelt die RAM (Responsibility Assignment Matrix) oder OBS, nicht die produktfokussierte PBS.
C (Projektrisiken): Risiken werden im Risikoregister erfasst und haben keinen Bezug zur physischen Produktstruktur.

☝️ Single Was ist das Ziel der Schätzung (Estimation) in der PRINCE2-Planung?

✅ Realistische Zeit- und Kostenprognosen zu liefern

❌ Die Projektdauer schnell zu schätzen (raten)

❌ Unsicherheit vollständig zu beseitigen

Richtig – präzise Schätzungen unterstützen eine wirksame Planung.

Merksatz:
Schätzen ist wie ein professioneller Wetterbericht: Er liefert eine realistische Prognose für Zeit und Geld, damit man weder im Regen steht noch unnötig viel Ballast mitschleppt.

Warum die anderen falsch sind:
B: Schnelles Raten ist keine methodische Schätzung und führt im Projekt zu gefährlichen Blindflügen.
C: Vollständige Sicherheit gibt es im Projektmanagement nicht, da zukünftige Risiken niemals komplett eliminiert werden können.

☝️ Single Warum ist es wichtig, Abhängigkeiten und Einschränkungen (Constraints) in einem Projekt zu identifizieren?

✅ Um Faktoren zu verstehen, die Terminplanung und Lieferung beeinflussen

❌ Um sicherzustellen, dass alle Projektunterlagen vollständig und aktuell sind

❌ Um die Notwendigkeit einer detaillierten Projektplanung zu umgehen

Richtig – Abhängigkeiten und Einschränkungen wirken sich direkt auf Zeitpläne und die Umsetzung aus.

Merksatz:
Leitplanken und Weichen bestimmen den Fahrplan: Nur wer Einschränkungen und Abhängigkeiten kennt, bringt den Projekt-Zug sicher und pünktlich ins Ziel.

Warum die anderen falsch sind:
B ist falsch, da das Identifizieren von Projektfaktoren die Dokumentation meist erhöht statt senkt.
C ist falsch, weil Einschränkungen eine präzise Zeitplanung erst recht erzwingen, statt sie überflüssig zu machen.

☝️ Single Was bedeutet „Qualität“ in PRINCE2 in erster Linie?

❌ Die Einhaltung des vorgegebenen Projektzeitplans und aller Meilensteine sicherzustellen

✅ Kundenerwartungen und Produktanforderungen zu erfüllen

❌ Die Gesamtkosten des Projekts auf ein absolutes Minimum zu reduzieren

Richtig – Qualität bedeutet Eignung für den Zweck (Fitness for Purpose) und die Erfüllung vereinbarter Kriterien.

Merksatz: Qualität ist wie ein maßgeschneiderter Smoking: Er glänzt nur, wenn er dem Kunden perfekt passt (Erwartungen) und alle Nähte halten (Produktanforderungen).

Warum die anderen falsch sind:
A) Schnelligkeit betrifft nur die Dimension Zeit, vernachlässigt aber die tatsächliche Tauglichkeit des gelieferten Produkts.
C) Reine Kostenminimierung ist Budgetdisziplin, führt ohne Qualitätsfokus jedoch meist zu unbrauchbarem Ausschuss.

☝️ Single Was ist der Zweck des Quality Management Approach?

❌ Festzulegen, wie sämtliche Projektrisiken erfasst und bewertet werden

❌ Festzulegen, wie Aufgaben an einzelne Teammitglieder zugewiesen werden

✅ Festzulegen, wie Qualität geplant, gesteuert und sichergestellt wird

Richtig – dieses Dokument beschreibt, wie die Qualitätsprozesse angewendet werden.

Merksatz:
Qualität ist ein Dreisprung: Erst planen, dann steuern, am Ende sichern – das ist der rote Faden für fehlerfreie Ergebnisse.

Warum die anderen falsch sind:
A: Das Auflisten von Risiken ist die Kernaufgabe des Risikomanagements, nicht der Qualitätssicherung.
B: Die Aufgabenverteilung erfolgt über den Projektstrukturplan und die Ressourcenplanung.

☝️ Single Was ist der Zweck des Risikomanagementverfahrens in PRINCE2?

✅ Risiken zu identifizieren, zu bewerten und zu steuern

❌ Risiken vollständig zu eliminieren und damit jede Unsicherheit im Projekt auszuschließen

❌ Risiken mit geringer Eintrittswahrscheinlichkeit grundsätzlich zu ignorieren und nicht weiter zu verfolgen

Richtig – das ist der Kernzweck des Risikoverfahrens.

Merksatz: Stell dir Risikomanagement wie ein Schiffsradar vor: Du musst Gefahren erst aufspüren (Identifizieren), ihre Bedrohung einschätzen (Bewerten) und das Schiff aktiv vorbeilenken (Steuern) – das I-B-S-Prinzip.

Warum die anderen falsch sind:
B: ...weil die vollständige Beseitigung aller Risiken in Projekten utopisch und wirtschaftlich unmöglich ist.
C: ...weil auch kleine Risiken überwacht werden müssen, um nicht unbemerkt zu einer Katastrophe anzuwachsen.

☝️ Single Welche der folgenden Optionen ist eine gültige Risikoreaktion (Risk Response) in PRINCE2?

❌ Ignorieren

✅ Vermeiden (Avoid)

❌ Unbegrenzt aufschieben

Richtig – Vermeidung ist eine anerkannte Risikostrategie.

Merksatz:
Wer die Klippe aktiv vermeidet, steuert das Schiff sicher um den Felsen herum – echtes Handeln statt Augen verschließen.

Warum die anderen falsch sind:
A) Ignorieren: Ein Risiko darf man im Projektmanagement niemals einfach totschweigen, da dies fahrlässige Untätigkeit statt aktiver Steuerung ist.
C) Unbegrenzt aufschieben: Risiken aufzuschieben löst sie nicht, sondern vergrößert die Gefahr durch unkontrollierten Zeitverzug.

☝️ Single Warum ist die Balance zwischen Qualität und Risiko in PRINCE2 wichtig?

❌ Um sicherzustellen, dass sämtliche Projektunterlagen vollständig und präzise dokumentiert werden, ohne unnötige Informationen zu erfassen

✅ Um sicherzustellen, dass Produkte die Erwartungen erfüllen, ohne übermäßiges Risiko einzugehen

❌ Um die Erstellung von Projektplänen vollständig zu automatisieren, sodass keine manuellen Planungsschritte mehr erforderlich sind

Richtig – Projekte müssen Qualität liefern und gleichzeitig Unsicherheiten managen.

Merksatz:
Stell dir eine Waage vor: Auf der einen Schale liegt die perfekte Qualität (Erwartung), auf der anderen das Risiko – nur im Gleichgewicht kommt das Produkt sicher ans Ziel.

Warum die anderen falsch sind:
A: Risikomanagement dient der Projektsteuerung, nicht der bloßen Reduzierung von Dokumenten.
C: Ohne Planung ist eine systematische Qualitäts- und Risikosteuerung unmöglich.

☝️ Single Was ist der entscheidende Unterschied zwischen einem Issue (Problem) und einem Risiko in PRINCE2?

❌ Ein Risiko ist bereits eingetreten, während ein Issue eintreten könnte

❌ Es gibt keinen Unterschied

✅ Ein Issue ist bereits eingetreten, während ein Risiko ungewiss ist

Richtig – Issues sind aktuelle Probleme oder Änderungen; Risiken sind mögliche zukünftige Ereignisse.

Merksatz:
Das Risiko lauert als Rätsel in der Zukunft (ungewiss), das Issue ist Immer schon da und tut weh (eingetreten).

Warum die anderen falsch sind:
A): Vertauscht die Definitionen von Gegenwart (Issue) und Zukunft (Risiko) komplett.
B): Ignoriert den fundamentalen Unterschied zwischen Gewissheit und Ungewissheit im Projektmanagement.

☝️ Single Was ist der Zweck des Änderungssteuerungsverfahrens (Change Control Procedure) in PRINCE2?

❌ Die vollständige und dauerhafte Umsetzung sämtlicher eingereichter Änderungsanträge ohne weitere Prüfung sicherzustellen

✅ Die Auswirkungen von Änderungen zu bewerten und zu steuern

❌ Jegliche Abweichungen vom ursprünglichen Projektplan durch strikte Ablehnung aller Änderungsvorschläge zu verhindern

Richtig – dies stellt sicher, dass Änderungen vor der Genehmigung bewertet werden.

Merksatz: Stell dir das Änderungsverfahren wie einen Club-Türsteher vor: Er winkt nicht jeden blind durch (A) und schließt auch nicht den Laden (C), sondern prüft jeden Gast (Auswirkung) und entscheidet dann kontrolliert (B).

Warum die anderen falsch sind:
A ist falsch: Ein automatischer "Freibrief" für jede Änderung würde das Projektbudget und den Zeitplan sofort sprengen.
C ist falsch: Ein starres Verbot blockiert notwendigen Fortschritt, da sich Projekte dynamisch anpassen müssen.

☝️ Single Was beschreibt Toleranzen (Tolerances) in PRINCE2 am besten?

✅ Akzeptable Abweichungsgrenzen bei den Projektzielen

❌ Feste Regeln, die nicht geändert werden können

❌ Nur auf die Projektkosten bezogen

Richtig – diese gelten für Zeit, Kosten, Umfang, Risiko, Qualität und Nutzen.

Merksatz: Toleranzen sind die elastischen Leitplanken auf dem Weg zu den Projektzielen: Sie erlauben ein Abweichen nach links und rechts, solange man nicht von der Straße abkommt.

Warum die anderen falsch sind:
B: Starre, unveränderliche Regeln widersprechen dem Grundgedanken flexibler Abweichungskorridore.
C: Die reine Fokussierung auf Finanzen vernachlässigt die übrigen fünf PRINCE2-Toleranzdimensionen wie Zeit, Qualität und Umfang.

☝️ Single Was ist der Hauptzweck des Issueregister?

✅ Issues während des gesamten Projekts zu verfolgen und zu managen

❌ Risiken während des gesamten Projekts zu identifizieren und zu bewerten

❌ Pläne während des gesamten Projekts zu aktualisieren und zu archivieren

Richtig – das Issue Register hält alle Issues organisiert und unter Kontrolle.

Merksatz:
Das Issue-Register ist das Tagebuch der akuten Probleme: Es hält fest, was jetzt brennt, und verfolgt den Fall, bis das Feuer gelöscht (gemanagt) ist.

Warum die anderen falsch sind:
B) Risiken sind ungelegte Eier (Zukunft) und gehören ins Risikoregister, während Issues bereits eingetretene Probleme (Gegenwart) sind.
C) Pläne gehören in das Dokumentenmanagement oder den Projektleitfaden, nicht in eine dynamische Problemliste.

☝️ Single Wie sollte ein Projektmanager mit Scope Creep (schleichender Umfangsausweitung) während einer Phase umgehen?

❌ Kleinere Umfangsänderungen sollten direkt im Team besprochen und ohne formale Dokumentation umgesetzt werden, um den Projektfortschritt nicht zu verzögern.

✅ Die Auswirkungen bewerten und dem Änderungssteuerungsverfahren folgen

❌ Alle neuen Anforderungen, die während der Phase auftreten, sollten sofort in den Projektplan aufgenommen werden, um die Kundenzufriedenheit sicherzustellen.

Auch kleine Änderungen können sich auf Zeit, Kosten oder Qualität auswirken.

Merksatz:
Scope Creep ist wie ein blinder Passagier: Erst stoppst du ihn, prüfst sein Ticket (Auswirkungen bewerten) und schickst ihn durch die Zollkontrolle (Änderungsverfahren).

Warum die anderen falsch sind:
A: Kleinvieh macht auch Mist und summiert sich unbemerkt zu einem massiven Budget- und Zeitproblem.
C: Blinde Zustimmung hebelt das magische Dreieck aus und führt direkt in den Kontrollverlust.

☝️ Single Was ist bei einer 60-minütigen PRINCE2-Prüfung mit 60 Fragen die empfohlene Vorgehensweise?

✅ Etwa 1 Minute pro Frage einplanen

❌ Zuerst extra Zeit für schwierige Fragen aufwenden

❌ Nur Fragen beantworten, bei denen man sich zu 100 % sicher ist

Dies stellt sicher, dass alle Fragen innerhalb der verfügbaren Zeit bearbeitet werden.

Merksatz:
Der Sekundenzeiger im Kopf: Bei 60 Fragen in 60 Minuten tickt die Uhr im Gleichschritt – plane eisern eine Minute pro Frage ein, um im perfekten Rhythmus sicher ins Ziel zu kommen.

Warum die anderen falsch sind:
B: Wer sich an schweren Fragen festbeißt, verliert wertvolle Zeit für die leichten Punkte am Ende.
C: Unbeantwortete Fragen bringen garantiert null Punkte, während Raten ohne Punktabzug immer eine Chance bietet.

☝️ Single Was ist der Zweck der Festlegung von Toleranzen in PRINCE2?

❌ Die Häufigkeit der Berichterstattung an das Projektmanagement zu erhöhen und damit die Transparenz zu verbessern

✅ Akzeptable Abweichungen zu definieren und unnötige Eskalationen zu reduzieren

❌ Alle Projektrisiken vollständig zu beseitigen und so die Unsicherheit im Projektverlauf zu minimieren

Toleranzen ermöglichen das Führen nach dem Ausnahmeprinzip und erlauben Eigenständigkeit innerhalb festgelegter Grenzen.

Merksatz:
Toleranz ist die Leitplanke auf der Projekt-Autobahn: Solange du dazwischen bleibst, steuerst du selbstständig und musst nicht den ADAC (Lenkungsausschuss) rufen.

Warum die anderen falsch sind:
A: Toleranzen dienen der Steuerung nach dem Ausnahmeprinzip und reduzieren Berichte, statt sie zu erhöhen.
C: Risiken können durch Toleranzen niemals komplett beseitigt, sondern nur in Grenzen gehalten werden.

☝️ Single Was ist der HAUPTVORTEIL eines produktorientierten Ansatzes (Product-Focused Approach) in PRINCE2?

❌ Er stellt sicher, dass alle Aktivitäten im Projekt auf eine möglichst effiziente Durchführung ausgerichtet werden

❌ Er ermöglicht eine vollständige Umsetzung der Projektziele ohne vorherige Festlegung von Meilensteinen

✅ Er schafft Klarheit darüber, was geliefert werden muss und in welcher Qualität

Eine produktorientierte Denkweise sorgt für klare Liefergegenstände und Qualitätserwartungen und reduziert Unklarheiten.

Merksatz: Erst das fertige Gemälde im Kopf haben (Was & Qualität), statt blind den Pinsel zu schwingen.

Warum die anderen falsch sind:
A: Verwechselt hektischen Aktionismus (Aktivitäten) mit dem eigentlichen, wertvollen Ergebnis.
B: Ein fataler Irrglaube, da ein klar definiertes Produkt die Planung erst präzise ermöglicht, statt sie zu ersetzen.

☝️ Single Wie sollte der Business Case in PRINCE2 während des gesamten Projekts behandelt werden?

✅ An zentralen Entscheidungspunkten aktualisiert und überprüft

❌ Ausschließlich bei der Erstellung des Projektauftrags festgelegt und danach nicht mehr angepasst

❌ Nur im Rahmen der Abschlussphase des Projekts einer abschließenden Bewertung unterzogen

Der Business Case ist ein lebendiges Dokument, das regelmäßig (besonders an Phasengrenzen) überprüft und aktualisiert wird, um die fortlaufende Rechtfertigung sicherzustellen.

Merksatz:
Der Business Case ist das GPS des Projekts: An jeder wichtigen Kreuzung (Entscheidungspunkt) musst du die Route prüfen und aktualisieren, um nicht blind ins Verderben zu steuern.

Warum die anderen falsch sind:
B ignoriert die Steuerung während des Projekts, da ein Blick auf das Navi erst am Zielort Totalschäden nicht mehr verhindern kann.
C verkennt die Dynamik von Projekten, da starres Festhalten an alten Plänen veränderte Marktbedingungen völlig ignoriert.

☝️ Single Was sind Dis-Benefits in einem PRINCE2-Business-Case?

❌ Mögliche Ereignisse, die den Projekterfolg gefährden könnten

❌ Aufwendungen, die für die Durchführung des Projekts anfallen

✅ Negative Auswirkungen, die aus dem Projekt resultieren

Dis-Benefits sind erwartete negative Auswirkungen, wie z. B. vorübergehende Störungen oder verringerte Leistung.

Merksatz:
Dis-Benefits sind die „Dis-aster-Effekte“ nach dem Projekt – wie der neue Stau durch eine neue Ampel: Sie sind reale, negative Nebenwirkungen des fertigen Produkts.

Warum die anderen falsch sind:
A: Risiken sind nur unsichere Eventualitäten während des Projekts, während Dis-Benefits als sichere, negative Konsequenzen des fertigen Produkts fest eingeplant sind.
B: Kosten sind der rein finanzielle Aufwand für die Erstellung, nicht die inhaltlich negativen Folgeschäden des Ergebnisses.

☝️ Single Wann sollte ein PRINCE2-Projekt vorzeitig beendet werden?

✅ Wenn der Business Case nicht mehr tragfähig ist

❌ Wenn das Projekt die letzte Phase erreicht

❌ Wenn alle Liefergegenstände fertiggestellt sind

PRINCE2 verlangt eine fortlaufende geschäftliche Rechtfertigung – scheitert der Business Case, sollte das Projekt gestoppt werden.

Merksatz:
Keine Kohle, kein Projekt: Der Business Case ist der Motor – stottert er, zieht PRINCE2 sofort die Handbremse!

Warum die anderen falsch sind:
B): Das Erreichen der letzten Phase ist der reguläre Endspurt und kein Grund für einen vorzeitigen Abbruch.
C): Die Fertigstellung aller Liefergegenstände führt zum geplanten, regulären Projektabschluss und nicht zu einem vorzeitigen Ende.

☝️ Single Was ist der ERSTE Schritt im PRINCE2-Änderungssteuerungsverfahren (Change Control Procedure)?

❌ Die genehmigte Änderung umsetzen

✅ Das Issue erfassen und untersuchen

❌ Die Auswirkungen des Issues bewerten

Der erste Schritt ist, das Issue zu erfassen und zu untersuchen, damit es formal dokumentiert und verstanden wird, bevor Maßnahmen ergriffen werden.

Merksatz:
Erst den Fisch ins Netz erfassen und untersuchen, bevor man ihn kocht. Ohne das Issue registriert zu haben, kann kein Prozess starten.

Warum die anderen falsch sind:
A) Umsetzen: Ist der finale Schritt am Ende des Prozesses, nicht der Anfang.
C) Bewerten: Ist erst der zweite Schritt; ohne Erfassung gibt es noch nichts zu bewerten.

☝️ Single Was ist die BESTE Methode, um Scope Creep in einem PRINCE2-Projekt zu managen?

❌ Alle Änderungen akzeptieren, um Stakeholder zufriedenzustellen

✅ Änderungen über das Änderungssteuerungsverfahren bewerten

❌ Kleine Änderungen ignorieren, um Zeit zu sparen

Alle Änderungen sollten formal über das Änderungssteuerungsverfahren bewertet werden, um die Kontrolle über Umfang, Kosten und Zeit zu behalten.

Merksatz:
Das Änderungsverfahren ist der strenge Türsteher deines Projekts: Jede Änderung braucht ein Ticket (Bewertung), sonst entsteht wildes Chaos (Scope Creep).

Warum die anderen falsch sind:
A) Führt direkt in den Ruin, da unkontrollierte Zugeständnisse Budget und Zeitplan sofort sprengen.
C) Unterschätzt den "Kleinvieh-Effekt", da sich auch kleine, ignorierte Änderungen unbemerkt zu massivem Verzug summieren.

Practice Business Case [F] [Practices] [Neu] 4 Unterseite →

☝️ Single In welchem Schritt der Technik „Business-Case-Management“ wird der Business Case am Ende jeder Managementphase mit den neuesten Nutzenprognosen aktualisiert?

❌ Entwickeln

❌ Prüfen

✅ Pflegen

❌ Bestätigen

Der Schritt „Pflegen“ hält den Business Case während des Projekts aktuell und aktualisiert ihn am Ende jeder Phase, damit die fortlaufende Rechtfertigung beurteilt werden kann.

Merksatz:
Wer ein Auto besitzt, muss es regelmäßig pflegen, damit es fahrbereit bleibt – genauso muss der Business Case über das gesamte Projekt hinweg durch Aktualisierungen gepflegt werden, um aktuell zu bleiben.

Warum die anderen falsch sind:
Entwickeln: Dies geschieht nur ganz am Anfang beim Erstellen des ersten Entwurfs, nicht am Ende der Phasen.
Prüfen: Hier wird der Business Case nur auf seine Tragfähigkeit kontrolliert (z. B. durch den Lenkungsausschuss), aber nicht aktiv fortgeschrieben.

Bestätigen: Dies findet erst nach dem Projekt statt, um zu prüfen, ob die erwarteten Nutzenvorteile tatsächlich realisiert wurden.

☝️ Single Nach Projektabschluss soll gemessen werden, ob die versprochenen Effizienzgewinne tatsächlich eingetreten sind. In welchem Schritt der Technik „Business-Case-Management“ geschieht das?

❌ Entwickeln

❌ Prüfen

❌ Pflegen

✅ Bestätigen

Im Schritt „Bestätigen“ wird – häufig erst nach Projektende – überprüft, ob der erwartete Nutzen realisiert wurde.

Merksatz:
Wer am Ende den Erfolg bestätigen will, muss den Champagner kaltstellen und die echten Zahlen mit den Versprechen abgleichen.

Warum die anderen falsch sind:
Entwickeln: Hier wird der Business Case im Initiierungsprozess überhaupt erst erstellt und kalkuliert.
Prüfen: Dies ist die laufende Bewertung der Wirtschaftlichkeit während des Projekts vor jeder nächsten Phase.

Pflegen: Das bezeichnet die kontinuierliche Aktualisierung des Business Case bei Änderungen oder Fortschritten im Projektverlauf.

☝️ Single Welches Managementprodukt beschreibt, wie und wann der erwartete Nutzen nach Projektabschluss gemessen wird?

❌ Business Case

✅ Nutzenmanagement-Ansatz

❌ Projektabschlussbericht

❌ Projektplan

Der Nutzenmanagement-Ansatz legt Maßnahmen, Verantwortlichkeiten und Zeitpunkte für die Messung und Überprüfung des Nutzens fest.

Merksatz:
Der Nutzenmanagement-Ansatz ist dein „Mess-Fahrplan“: Er zeigt dir den Weg (Ansatz), wie und wann du die Früchte (Nutzen) nach der Ernte (Projektabschluss) wiegst.

Business Case: Begründet zwar das Projekt und listet den Nutzen auf, beschreibt aber nicht den konkreten Messprozess und Zeitplan nach Abschluss.
Projektabschlussbericht: Zieht nur Bilanz über das Projektende, plant aber keine zukünftigen Messungen.

Projektplan: Steuert die Erstellung der Liefergegenstände während des Projekts, nicht die Nutzenrealisierung danach.

☝️ Single Ein Projekt liefert eine neue Software, deren laufende Wartungskosten den Betrieb nach Projektende dauerhaft belasten. Welche Practice stellt sicher, dass diese Kosten in der Rechtfertigung berücksichtigt werden?

❌ Pläne

❌ Fortschritt

✅ Business Case

❌ Issues

Die Practice „Business Case“ betrachtet die Kosten über den gesamten Lebenszyklus, einschließlich der nach Projektende anfallenden Betriebskosten.

Merksatz:
Der Business Case ist die Waagschale des Projekts: Er wiegt alle Kosten (auch zukünftige Wartung) gegen den Nutzen auf, um die dauerhafte Wirtschaftlichkeit zu sichern.

Warum die anderen falsch sind:

Pläne: Fokussiert sich auf die zeitliche und logistische Durchführung der Lieferobjekte, nicht auf die langfristige finanzielle Rechtfertigung.

Fortschritt: Überwacht nur den aktuellen Ist-Zustand und Abweichungen im laufenden Projekt, regelt aber keine Lebenszykluskosten.

Issues: Behandelt aktuelle Probleme und Änderungsanträge, ist aber kein Werkzeug für die grundlegende Investitionsrechnung.

Practice Organisieren [F] [Practices] [Neu] 4 Unterseite →

☝️ Single Welche zwei Managementprodukte beschreiben gemeinsam am vollständigsten, wer am Projekt beteiligt ist und welche Verantwortlichkeiten die Beteiligten tragen?

❌ Projektlogbuch und Rollenbeschreibungen

❌ Business Case und Rollenbeschreibungen

✅ Rollenbeschreibungen und Struktur des Projektmanagement-Teams

❌ Projektplan und Struktur des Projektmanagement-Teams

Rollenbeschreibungen legen Verantwortlichkeiten und Befugnisse fest, die Struktur des Projektmanagement-Teams zeigt die Beteiligten und ihre Beziehungen – gemeinsam beschreiben sie die Projektorganisation.

Merksatz:
Wer im Projekt was tut, zeigt das Organigramm (Struktur des Projektmanagement-Teams) zusammen mit den Stellenbeschreibungen (Rollenbeschreibungen) – wie im echten Unternehmen zeigt das eine die Hierarchie und das andere die konkreten Aufgaben.

Warum die anderen falsch sind:
Projektlogbuch ist nur ein informelles Register für tägliche Notizen, kein strukturelles Dokument für feste Zuständigkeiten.
Business Case begründet nur den wirtschaftlichen Nutzen des Projekts, definiert aber keine Teamstrukturen oder Aufgaben.

Projektplan beschreibt den zeitlichen und inhaltlichen Ablauf (Wann und Was), nicht die personellen Zuständigkeiten (Wer).

☝️ Single Gemäß der Practice „Organisieren“ – wie sollten Rollen und Verantwortlichkeiten in einem Projekt zugeteilt werden?

❌ Jeder definierten PRINCE2-Rolle wird genau eine Person zugewiesen

✅ Verantwortlichkeiten sind stets eindeutig zugeteilt, auch wenn Rollen geteilt oder kombiniert werden

❌ Rollen werden ausschließlich aus internen Stakeholdern besetzt

❌ Zuständigkeiten werden erst bei Bedarf während der Lieferphasen vergeben

Entscheidend ist die eindeutige Verantwortlichkeit. Rollen dürfen kombiniert oder geteilt werden, solange die Zuständigkeit klar bleibt.

☝️ Single Bei einem kleinen, wenig komplexen Projekt sollen laut Leitlinie zwei Rollen typischerweise kombiniert werden. Welche?

❌ Benutzervertreter und Lieferantenvertreter

❌ Projektauftraggeber und Projektmanager

✅ Projektmanager und Teammanager

❌ Projektsicherung und Projektunterstützung

Bei kleinen Projekten übernimmt der Projektmanager häufig zusätzlich die Teammanager-Rolle. Auftraggeber/Projektmanager und Benutzer/Lieferant bleiben aus Governance-Gründen getrennt.

☝️ Single Wer ist definiert als mit der Befugnis ausgestattet, das Projekt innerhalb des von der Business-Ebene gesetzten Rahmens zu lenken?

❌ Projektmanager

✅ Lenkungsausschuss

❌ Projektauftraggeber allein

❌ Projektunterstützung

Der Lenkungsausschuss lenkt das Projekt innerhalb der von der Business-Ebene gesetzten Grenzen; der Auftraggeber leitet ihn, trägt die Befugnis jedoch nicht allein.

Merksatz:
Der Lenkungsausschuss lenkt das Schiff (Projekt) im Auftrag des Reeders (Business-Ebene), während der Projektmanager nur der Steuermann ist.

Warum die anderen falsch sind:

Projektmanager: Er managt das Tagesgeschäft, hat aber keine übergeordnete Lenkungsbefugnis.

Projektauftraggeber allein: Er vertritt zwar die Business-Interessen, lenkt das Projekt aber im Lenkungsausschuss gemeinsam mit Benutzern und Lieferanten (Dreifaltigkeit).

Projektunterstützung: Sie übernimmt nur administrative Aufgaben und hat keinerlei Entscheidungs- oder Lenkungsbefugnis.

Practice Pläne [F] [Practices] [Neu] 4 Unterseite →

☝️ Single In welchem Schritt der Planungstechnik werden Abhängigkeiten zwischen den zu liefernden Produkten ERSTMALS identifiziert?

✅ Produkte definieren und analysieren

❌ Arbeitspakete organisieren

❌ Schätzungen durchführen

❌ Einen Zeitplan aufstellen

Die produktbasierte Planung im Schritt „Produkte definieren und analysieren“ ermittelt Produkte und ihre Beziehungen – damit werden Abhängigkeiten zuerst sichtbar.

Merksatz:
Erst die Bausteine (Produkte) genau betrachten, dann sieht man, wie sie zusammenpassen: Die Produktanalyse (PBS und PFD) deckt die logische Reihenfolge und somit alle Abhängigkeiten auf, noch bevor überhaupt an Zeit oder Arbeit gedacht wird.

Warum die anderen falsch sind:
Arbeitspakete organisieren: Arbeitspakete bündeln bereits definierte Produkte, anstatt deren grundlegende Abhängigkeiten neu zu entdecken.
Schätzungen durchführen: Hier geht es rein um Aufwand und Ressourcen, was die logischen Produktbeziehungen bereits voraussetzt.

Einen Zeitplan aufstellen: Hier werden die zuvor ermittelten Abhängigkeiten nur noch in eine zeitliche Reihenfolge gebracht (visualisiert), nicht erstmals identifiziert.

☝️ Single Welcher Plan liefert dem Projektmanager ausreichend Detail für die tägliche Steuerung der aktuellen Managementphase?

❌ Projektplan

✅ Phasenplan

❌ Teamplan

❌ Ausnahmeplan

Der Phasenplan enthält die für die tägliche Steuerung nötige Detailtiefe. Der Projektplan bleibt übergeordnet, der Teamplan dient dem Teammanager.

Merksatz:
Der Phasenplan ist das tägliche Navigationsgerät des Projektmanagers: Er zoomt nah genug heran, um die aktuelle Phase Schritt für Schritt zu steuern.

Warum die anderen falsch sind:
Projektplan: Ist die grobe Weltkarte für das gesamte Projekt, viel zu ungenau für die tägliche Steuerung.
Teamplan: Gehört dem Teammanager zur Zuweisung von Arbeitspaketen, nicht dem Projektmanager.

Ausnahmeplan: Wird nur als Notfallplan bei Toleranzüberschreitungen erstellt, nicht für den Normalbetrieb.

☝️ Single Ergänzen Sie: Ein Zeitplan ist lediglich ein Bestandteil eines [?].

❌ Arbeitspakets

✅ Plans

❌ Risikoregisters

❌ Phasenübergangs

Ein Plan umfasst neben dem Zeitplan weitere Elemente wie Produktbeschreibungen, Ressourcen, Schätzungen und Abhängigkeiten.

Merksatz:
Ein Plan ist das große Ganze (wie ein Haus), während der Zeitplan nur ein einzelnes Zimmer darin ist – er zeigt nur die zeitliche Dimension des Gesamtplans.

Warum die anderen falsch sind:
Arbeitspakets: Ein Arbeitspaket ist ein konkretes Aufgabenbündel und kein übergeordnetes Dokument, das einen Zeitplan enthält.
Risikoregisters: Hier werden Bedrohungen und Chancen gelistet, keine zeitlichen Projektabläufe.

Phasenübergangs: Dies ist ein Entscheidungspunkt (Ereignis) und kein Dokument, das einen Zeitplan als physischen Bestandteil in sich trägt.

☝️ Single Welches Element effektiver Planung senkt am stärksten das Risiko, dass wesentliche Umfangsbestandteile im Plan übersehen werden?

❌ Die Festlegung von Planungstoleranzen

✅ Die produktbasierte Planung

❌ Der Planungshorizont

❌ Die Aufteilung in Managementphasen

Die produktbasierte Planung beginnt mit der Identifikation aller Produkte und ihrer Beziehungen und stellt so eine vollständige Umfangserfassung sicher.

Merksatz:
Erst das Produkt, dann der Plan – wer physische Produkte wie Puzzleteile auf den Tisch legt, vergisst kein einziges Teil des Gesamtbildes.

Warum die anderen falsch sind:
Planungstoleranzen steuern nur Abweichungen von Zeit und Budget, verhindern aber nicht das Vergessen von Inhalten.
Der Planungshorizont bestimmt nur, wie weit man in die Zukunft blickt, schützt aber nicht vor Lücken im aktuellen Bereich.

Managementphasen strukturieren das Projekt zeitlich in Abschnitte, listen aber nicht die konkreten Liefergegenstände auf.

Practice Qualität [F] [Practices] [Neu] 4 Unterseite →

☝️ Single In welchem Schritt der Qualitätsmanagement-Technik werden die Qualitätserwartungen der Benutzer erfasst?

✅ Sammeln von Benutzer-Inputs

❌ Beschreibung des Qualitätsmanagement-Ansatzes

❌ Steuerung der Qualität

❌ Abnehmen von Produkten

Die Qualitätserwartungen der Benutzer werden im Schritt „Sammeln von Benutzer-Inputs“ erfasst und bilden die Grundlage der Qualitätsplanung.

Merksatz:
Bevor man kocht, fragt man die Gäste nach ihren Wünschen – die Erwartungen der Benutzer werden im allerersten Schritt beim „Sammeln von Benutzer-Inputs“ eingeholt.

Warum die anderen falsch sind:
Beschreibung des Qualitätsmanagement-Ansatzes: Dies legt nur die Regeln und Methoden fest, erfasst aber keine konkreten Benutzererwartungen.
Steuerung der Qualität: Dies ist die spätere Überwachung während der Umsetzung, nicht die initiale Erfassung der Anforderungen.

Abnehmen von Produkten: Dies ist der finale Schritt der Überprüfung, ob die zuvor erfassten Erwartungen am Ende auch erfüllt wurden.

☝️ Single Welches Managementprodukt liefert Audit- und Sicherungsnachweise darüber, was an Qualitätsaktivitäten geplant war und was tatsächlich durchgeführt wurde?

❌ Produktbeschreibung

❌ Qualitätsmanagement-Ansatz

✅ Qualitätsregister

❌ Projektproduktbeschreibung

Das Qualitätsregister dokumentiert geplante und durchgeführte Qualitätsaktivitäten samt Ergebnissen und dient damit als Audit-/Sicherungsnachweis.

Merksatz:
Das Qualitätsregister ist das „Kassentagebuch“ der Qualität: Hier wird jede geplante und tatsächlich durchgeführte Qualitätsprüfung lückenlos als Nachweis protokolliert.

Warum die anderen falsch sind:
Produktbeschreibung: Definiert nur die Qualitätskriterien eines einzelnen Produkts vorab, liefert aber keine Nachweise über durchgeführte Aktivitäten.
Qualitätsmanagement-Ansatz: Beschreibt nur die Strategie und Techniken (das „Wie“), ist aber kein Protokoll über tatsächliche Ergebnisse.

Projektproduktbeschreibung: Definiert lediglich die Erwartungen des Kunden an das Gesamtprojekt, nicht die Details einzelner Qualitätsprüfungen.

☝️ Single Welche Aussage beschreibt die Projektsicherung, aber NICHT die Qualitätssicherung?

❌ Sie prüft, ob Produkte bei der Inspektion ihre Qualitätsspezifikationen erfüllen

✅ Sie ist eine Verantwortung des Lenkungsausschusses, unabhängig vom Projektmanager

❌ Sie ist Teil des Qualitätsmanagementsystems der liefernden Organisation

❌ Sie erfasst die Qualitätsspezifikationen in Form von Produktbeschreibungen

Projektsicherung ist eine unabhängige Verantwortung des Lenkungsausschusses. Die übrigen Aussagen beschreiben Qualitätssicherung oder die Practice Qualität.

Merksatz: Der Lenkungsausschuss sichert das Projekt, der Projektmanager sichert die Produkte.

Warum die anderen falsch sind:
Sie prüft, ob Produkte bei der Inspektion ihre Qualitätsspezifikationen erfüllen – Das ist operative Qualitätskontrolle.
Sie ist Teil des Qualitätsmanagementsystems der liefernden Organisation – Das ist übergeordnetes Organisations-QM, nicht Projektsicherung.

Sie erfasst die Qualitätsspezifikationen in Form von Produktbeschreibungen – Das ist Teil der Qualitätsplanung.

☝️ Single Welches Managementprodukt ist der wichtigste Input für die Qualitätsplanung eines einzelnen Produkts?

❌ Projektproduktbeschreibung

✅ Produktbeschreibung

❌ Qualitätsmanagement-Ansatz

❌ Qualitätsregister

Die Produktbeschreibung definiert Qualitätskriterien, -methoden und -verantwortlichkeiten für das einzelne Produkt und ist damit zentraler Input der Qualitätsplanung.

Merksatz:
Für das perfekte Rezept eines einzelnen Gerichts brauchst du die konkrete Produktbeschreibung – die Projektproduktbeschreibung ist nur das Menü für das gesamte Festmahl.

Warum die anderen falsch sind:
Projektproduktbeschreibung: Bezieht sich auf das gesamte Projekt und die Erwartungen des Kunden, nicht auf ein einzelnes, spezifisches Produkt.
Qualitätsmanagement-Ansatz: Definiert nur die allgemeine Strategie und die Techniken für das gesamte Projekt, enthält aber keine Details für ein bestimmtes Produkt.

Qualitätsregister: Ist ein dynamisches Protokoll zur Aufzeichnung von Qualitätsaktivitäten und kein planender Input für die Erstellung eines Produkts.

Practice Risiko [F] [Practices] [Neu] 4 Unterseite →

☝️ Single In welchem Schritt der Risikomanagement-Technik wird die Eintrittswahrscheinlichkeit eines identifizierten Risikos analysiert?

❌ Identifizieren: Kontext und Ziele definieren

❌ Identifizieren: Bedrohungen und Chancen identifizieren

✅ Bewerten: Risiken priorisieren

❌ Planen

Im Schritt „Bewerten: Risiken priorisieren“ werden u. a. Eintrittswahrscheinlichkeit, Auswirkung und Eintrittsnähe bewertet.

Merksatz:
Wer priorisieren will, muss zuerst den Wert bestimmen – im Schritt „Bewerten: Risiken priorisieren“ wiegst du die Wahrscheinlichkeit und Auswirkung ab, um die wichtigste Waagschale (Priorität) zu füllen.

Identifizieren (Kontext): Setzt nur den Rahmen und sucht noch keine konkreten Risiken.
Identifizieren (Bedrohungen/Chancen): Sammelt und benennt die Risiken lediglich, statt sie mathematisch oder qualitativ zu analysieren.

Planen: Reagiert erst auf die bereits analysierten Risiken und bereitet die Gegenmaßnahmen vor.

☝️ Single Ein während einer Phase identifizierter positiver Effekt (Chance) wird weiterverfolgt. Wo wird sein aktueller Bearbeitungsstand dokumentiert?

❌ Phasenplan

✅ Risikoregister

❌ Risikomanagement-Ansatz

❌ Projektlogbuch

Chancen werden als positive Risiken behandelt; ihr Status wird – wie bei Bedrohungen – im Risikoregister festgehalten.

Merksatz:
Chancen und Risiken sind zwei Seiten derselben Medaille – sie wohnen zusammen im Risikoregister, wo ihr aktueller Status wie in einem Steckbrief laufend aktualisiert wird.

Warum die anderen falsch sind:
Phasenplan: Plant Termine und Ressourcen für die Phase, ist aber kein dynamisches Tracking-Tool für Einzelrisiken.
Risikomanagement-Ansatz: Beschreibt nur die strategischen Spielregeln (das „Wie“), enthält aber keine konkreten, aktuellen Fälle.

Projektlogbuch: Dient als informelles Notizbuch für kleinere Probleme und Erkenntnisse, nicht für das formelle Management von Risiken und Chancen.

☝️ Single Der Projektmanager will die Projektumgebung verstehen und festlegen, wie das Risikomanagement im Projekt durchgeführt wird. In welchem Schritt der Technik geschieht das?

✅ Identifizieren: Kontext und Ziele definieren

❌ Bewerten: Risiken priorisieren

❌ Planen

❌ Implementieren

Der Rahmen für das Risikomanagement wird im Schritt „Identifizieren: Kontext und Ziele definieren“ festgelegt.

Merksatz:
Bevor du Gefahren suchst, musst du die Landkarte zeichnen: Das Identifizieren startet immer mit dem Abstecken des Spielfelds (Kontext & Ziele definieren), denn nur wer die Umgebung kennt, sieht auch die Risiken.

Warum die anderen falsch sind:
Bewerten (falsch): Hier geht es um die Schätzung von Wahrscheinlichkeit und Auswirkung bereits gefundener Risiken, nicht um das Aufsetzen des Prozesses.
Planen (falsch): In diesem Schritt werden spezifische Gegenmaßnahmen (Reaktionen) für konkrete Risiken vorbereitet, anstatt die Rahmenbedingungen festzulegen.

Implementieren (falsch): Hier werden die beschlossenen Risikoreaktionen aktiv ausgeführt und überwacht, was eine bereits stehende Projektumgebung voraussetzt.

☝️ Single Welcher Begriff ist definiert als ein unsicheres Ereignis, das beim Eintreten Auswirkungen auf die Erreichung der Ziele hätte?

❌ Issue

✅ Risiko

❌ Ausnahme

❌ Spezifikationsabweichung

Ein Risiko ist ein unsicheres Ereignis mit möglicher Auswirkung auf die Ziele; ein Issue ist bereits eingetreten, eine Ausnahme eine prognostizierte Toleranzüberschreitung.

Merksatz:
Ein Risiko ist wie ein „unsichtbares Fragezeichen in der Zukunft“ – es ist unsicher, ob es passiert, aber wenn es einschlägt, trifft es deine Projektziele direkt.

Warum die anderen falsch sind:
Issue: Ein Issue ist ein bereits eingetretenes, also absolut sicheres Ereignis oder Problem in der Gegenwart.
Ausnahme: Dies ist eine Toleranzüberschreitung, kein unsicheres zukünftiges Ereignis.

Spezifikationsabweichung: Dies beschreibt einen konkreten, bereits existierenden Fehler im Produkt und kein unsicheres Zukunftsrisiko.

Practice Issues [F] [Practices] [Neu] 4 Unterseite →

☝️ Single In welchem Schritt der Issuemanagement-Technik sollte gegebenenfalls ein Ausnahmeplan angefordert werden?

❌ Erfassen von Issues

❌ Bewerten von Issues

✅ Entscheidung über Änderungen

❌ Implementieren von Änderungen

Ergibt die Bewertung, dass Toleranzen überschritten werden, wird im Schritt „Entscheidung über Änderungen“ ein Ausnahmeplan angefordert.

Merksatz:
Erst wenn der Chef am runden Tisch über das Schicksal der Änderung entscheidet, wird der rote Knopf für den Ausnahmeplan gedrückt – denn nur wer entscheidet, fordert auch Pläne an!

Erfassen von Issues: Hier wird das Problem nur im Register aufgeschrieben, noch nichts analysiert oder geplant.
Bewerten von Issues: In diesem Schritt werden nur die Auswirkungen untersucht, aber noch keine formelle Steuerungsmaßnahme (wie ein Ausnahmeplan) angefordert.

Implementieren von Änderungen: Hier wird die beschlossene Lösung bereits umgesetzt, für die Anforderung eines Ausnahmeplans ist es viel zu spät.

☝️ Single Wo sollte die Leitlinie beschrieben sein, wie Änderungen an der Projekt-Baseline berichtet und eskaliert werden?

✅ Issuemanagement-Ansatz

❌ Risikomanagement-Ansatz

❌ Nutzenmanagement-Ansatz

❌ Qualitätsmanagement-Ansatz

Der Issuemanagement-Ansatz regelt Behandlung, Bewertung, Genehmigung und Berichterstattung von Issues, einschließlich Änderungen an Baselines.

Merksatz:
Ein Issue (Problem/Änderungsantrag) stört die Baseline – darum regelt der Issuemanagement-Ansatz, wie wir Änderungen berichten und eskalieren!

Warum die anderen falsch sind:
Risikomanagement-Ansatz: Bezieht sich nur auf potenzielle Bedrohungen und Chancen (Zukunft), nicht auf bereits konkrete Änderungsanträge (Issues).
Nutzenmanagement-Ansatz: Definiert, wie und wann der messbare Geschäftsnutzen realisiert wird, nicht den operativen Umgang mit Baseline-Änderungen.

Qualitätsmanagement-Ansatz: Legt Qualitätsstandards und Prüfverfahren für Produkte fest, regelt aber nicht den Eskalationsweg für formelle Projektänderungen.

☝️ Single Was ist die Definition eines Änderungsantrags?

✅ Ein Vorschlag zur Änderung einer Baseline

❌ Ein Produkt, das seine Spezifikation nicht erfüllt

❌ Ein unsicheres Ereignis mit möglicher Zielauswirkung

❌ Eine prognostizierte Überschreitung vereinbarter Toleranzen

Ein Änderungsantrag ist ein Vorschlag zur Änderung einer genehmigten Baseline. Die übrigen Optionen definieren Spezifikationsabweichung, Risiko bzw. Ausnahme.

Merksatz:
Ein Änderungsantrag will die feste Basislinie verschieben – stell dir vor, du beantragst, die Baseline (die Ziellinie) im Sand neu zu ziehen.

Warum die anderen falsch sind:
Ein Produkt, das seine Spezifikation nicht erfüllt: Das beschreibt eine Spezifikationsabweichung (Off-Specification), da der Fehler bereits im Produkt existiert.
Ein unsicheres Ereignis mit möglicher Zielauswirkung: Dies ist die klassische Definition eines Risikos, da es sich um die Zukunft und Unsicherheit dreht.
Eine prognostizierte Überschreitung vereinbarter Toleranzen: Dies definiert eine Ausnahme* (Exception), die eine Eskalation an die nächsthöhere Managementebene erfordert.

☝️ Single Welches Managementprodukt sollte aktualisiert werden, um informelle Maßnahmen oder Ereignisse festzuhalten, die kein formales Register erfordern?

❌ Projektstatusbericht

❌ Issuebericht

✅ Projektlogbuch

❌ Ausnahmebericht

Das Projektlogbuch dient als Arbeitsprotokoll des Projektmanagers für informelle Notizen, Ereignisse und Maßnahmen.

Merksatz:
Das Projektlogbuch ist das „Notizbuch“ des Projektleiters – hier wird alles Informelle, Schnelle und Alltägliche sofort eingetragen, ohne dass man erst ein formelles Register öffnen muss.

Warum die anderen falsch sind:
Projektstatusbericht: Dient der regelmäßigen, formellen Berichterstattung an den Lenkungsausschuss, nicht dem Festhalten informeller Alltagsereignisse.
Issuebericht: Wird nur für formale Offene Punkte (Issues) erstellt, die eine strukturierte Bewertung und Entscheidung erfordern.

Ausnahmebericht: Wird erst erstellt, wenn Toleranzen nachweislich überschritten werden, und ist ein hochgradig formelles Dokument.

Practice Fortschritt [F] [Practices] [Neu] 3 Unterseite →

☝️ Single Was beschreibt AM BESTEN, wie der Fortschritt überwacht werden sollte?

❌ Durch Messen, ob Produkte ihre geplanten Qualitätsspezifikationen erreicht haben

✅ Durch Messen der erreichten Ergebnisse an den Plänen der Projekt-Baseline

❌ Durch Messen des Nutzens an den Business-Zielen

❌ Durch Messen der Ergebnisse am ursprünglichen Projektmandat

Fortschritt wird überwacht, indem die tatsächlich erreichten Ergebnisse mit den Baselines – insbesondere den Plänen – verglichen werden.

Merksatz:
Fortschritt ist wie eine Wanderung mit GPS: Du misst deine aktuelle Position (erreichte Ergebnisse) immer an der Route, die du vorab im Gerät gespeichert hast (Projekt-Baseline).

Warum die anderen falsch sind:
Qualitätsspezifikationen: Dies prüft die Qualität (Qualitäts-Practice), nicht den zeitlichen oder finanziellen Gesamtfortschritt.
Nutzen an Business-Zielen: Das misst den langfristigen Projekterfolg (Nutzenrealisierung) nach dem Projekt, nicht den aktuellen Projektfortschritt.

Ursprüngliches Projektmandat: Das Mandat ist nur der allererste, grobe Startimpuls und viel zu ungenau für die laufende Steuerung; dafür gibt es die detaillierte Baseline.

☝️ Single Welches Managementprodukt sollte der Lenkungsausschuss prüfen, wenn er am Phasenende über das weitere Vorgehen entscheidet?

❌ Teamstatusbericht

❌ Projektstatusbericht

✅ Phasenabschlussbericht

❌ Ausnahmebericht

Der Phasenabschlussbericht fasst die Ergebnisse der Phase zusammen und dient dem Lenkungsausschuss als Entscheidungsgrundlage am Phasenübergang.

Merksatz:
Der Lenkungsausschuss zieht am Phasenende einen Schlussstrich: Er prüft den Phasenabschlussbericht, um das bisherige Ergebnis abzusegnen und die nächste Phase freizugeben.

Warum die anderen falsch sind:
Teamstatusbericht: Ist ein internes Dokument des Teammanagers für den Projektmanager, nicht für den Lenkungsausschuss.
Projektstatusbericht: Liefert regelmäßige Updates während einer laufenden Phase, dient aber nicht der formalen Entscheidung am Phasenende.

Ausnahmebericht: Wird nur bei drohenden Toleranzüberschreitungen erstellt, nicht als Standardprodukt am regulären Phasenende.

☝️ Single Ergänzen Sie: [?]-Steuerungen kommen in vordefinierten, regelmäßigen Intervallen zum Einsatz.

❌ Ereignisbasierte

✅ Zeitbasierte

❌ Toleranzbasierte

❌ Prognostizierte

Zeitbasierte Steuerungen (z. B. regelmäßige Statusberichte) erfolgen in festen Intervallen; ereignisbasierte werden durch bestimmte Ereignisse ausgelöst.

Merksatz:
Zeit läuft im Takt der Uhr: Zeitbasierte Steuerungen ticken in regelmäßigen Intervallen wie ein Wecker (z. B. wöchentliche Statusberichte).

Warum die anderen falsch sind:
Ereignisbasierte: Diese reagieren nur spontan auf bestimmte Vorfälle (wie ein Meilenstein oder Projektende), nicht nach dem Kalender.
Toleranzbasierte: Diese greifen erst ein, wenn Grenzwerte (z. B. Budgetüberschreitungen) verletzt werden, unabhängig von der Zeit.

Prognostizierte: Dies ist kein PRINCE2-Steuerungstyp, sondern ein Blick in die Zukunft zur Planungsunterstützung.

Practice Business Case [F] [Practices] 7 Unterseite →

☝️ Single In welchem Schritt der Business-Case-Management-Technik wird der Business Case erstmals erstellt?

❌ Pflegen

❌ Bestätigen

✅ Entwickeln

❌ Prüfen

Der Schritt „Entwickeln“ umfasst die erstmalige Erstellung des Business Case.

Merksatz:
Wer etwas Neues erschaffen will, muss es entwickeln – wie ein Softwareentwickler, der Code schreibt, oder ein Bauherr, der den ersten Entwurf zeichnet. Erst nach dem Entwickeln kann man prüfen, pflegen oder bestätigen.

Warum die anderen falsch sind:
Pflegen: Das ist die kontinuierliche Aktualisierung während des Projekts, wofür der Case bereits existieren muss.
Bestätigen: Hier wird der Nutzen nachgelagert überprüft (oft nach Projektende), nicht erst erstellt.

Prüfen: Dies ist die Qualitätskontrolle eines bereits fertig entwickelten Entwurfs vor der Freigabe.

☝️ Single Der Lenkungsausschuss will bei einer Entscheidung prüfen, ob das Projekt weiterhin wünschenswert, machbar und erreichbar ist. In welchem Schritt der Technik geschieht diese Bewertung?

❌ Bestätigen

❌ Entwickeln

✅ Prüfen

❌ Pflegen

Im Schritt „Prüfen“ wird die fortlaufende Gültigkeit der geschäftlichen Rechtfertigung bewertet.

Merksatz:
Der Lenkungsausschuss will die Fakten prüfen, um die Fortführung des Projekts abzusegnen – genau wie ein TÜV-Prüfer, der die Fahrtüchtigkeit kontrolliert, bevor es weitergeht.

Warum die anderen falsch sind:
Bestätigen: Hier formuliert der Projektmanager die endgültige Empfehlung für den Lenkungsausschuss, statt selbst die übergeordnete Bewertung vorzunehmen.
Entwickeln: In diesem Schritt werden die Daten und Optionen für den Business Case erst gesammelt und ausgearbeitet.

Pflegen: Dies ist die fortlaufende Aktualisierung des Business Cases bei Änderungen, keine punktuelle Bewertungsentscheidung.

☝️ Single Was ist ein Zweck der Practice „Business Case“?

✅ Den Auftraggeber in die Lage versetzen, über die Fortführung des Projekts zu entscheiden

❌ Die Risiken auf Risikoeigentümer zu verteilen

❌ Die Reihenfolge der Arbeitspakete zu bestimmen

❌ Die Qualitätskriterien einzelner Produkte festzulegen

Die Practice liefert die Informationen, damit über Start und Fortführung des Projekts rational entschieden werden kann.

☝️ Single Welcher Begriff bezeichnet ein messbares Ergebnis, das von der investierenden Organisation als vorteilhaft empfunden wird?

✅ Nutzen

❌ Output

❌ Ergebnis

❌ Nebeneffekt

Ein Nutzen ist eine messbare Verbesserung, die als vorteilhaft wahrgenommen wird; ein Output ist der reine Liefergegenstand.

Merksatz:
Nutzen bringt Nutzen (Profit) – Nur ein messbarer Vorteil für den Investor ist echter Nutzen (Benefit), während Produkte nur Staubfänger sind, bis sie diesen Wert entfalten.

Output ist falsch, weil dies nur das physische oder immaterielle Lieferergebnis (Spezialprodukt) des Projekts ist.
Ergebnis ist falsch, weil es die Veränderung beschreibt, die durch die Nutzung des Outputs entsteht (z. B. neue Arbeitsweise), aber noch nicht den finanziellen/messbaren Vorteil selbst.

Nebeneffekt ist falsch, weil dies ungeplante (positive oder negative) Konsequenzen sind und nicht das primär angestrebte, vorteilhafte Ziel der Investition.

☝️ Single Welcher Begriff bezeichnet einen messbaren Rückgang, der von der investierenden Organisation als nachteilig empfunden wird?

✅ Negativer Nebeneffekt

❌ Änderungsantrag

❌ Ergebnis

❌ Risiko

Ein negativer Nebeneffekt ist ein messbarer nachteiliger Effekt und wird zusammen mit dem Nutzen im Business Case betrachtet.

Merksatz:
Der negative Nebeneffekt ist das „saure Bonbon“ der Investition – ein realer, messbarer Nachteil, den man zähneknirschend schlucken muss, um das Hauptziel zu erreichen.

Warum die anderen falsch sind:
Änderungsantrag: Dies ist ein formeller Vorschlag zur Modifikation eines Produkts oder Plans, kein messbarer Nachteil.
Ergebnis: Ein Ergebnis (Outcome) beschreibt die durch die Projektausgaben erzielte Veränderung, die idealerweise positiv ist.

Risiko: Ein Risiko ist ein unsicheres Ereignis in der Zukunft, während der negative Nebeneffekt eine sichere, messbare Folge der Investition ist.

☝️ Single Wozu führen wünschenswerte Ergebnisse (Outcomes) unmittelbar?

❌ Zu Outputs des Projekts

✅ Zu messbaren Verbesserungen (Nutzen)

❌ Zur Genehmigung des Projektplans

❌ Zur Reduktion der Projektrisiken

Aus den Outcomes ergeben sich die messbaren Verbesserungen (Nutzen), die im Business Case definiert sind.

Merksatz:
„Outcomes bringen Nutzen!“ Stell dir vor, du baust eine Küche (Output). Kochen zu können, ist das Ergebnis (Outcome). Das spart Geld und schmeckt besser – das ist der messbare Nutzen (Benefit). Outcomes führen direkt zum Nutzen!

Warum die anderen falsch sind:
Zu Outputs des Projekts: Outputs (die Küche) müssen vor dem Outcome (dem Kochen) existieren, nicht danach.
Zur Genehmigung des Projektplans: Dies ist ein formaler Management-Schritt und keine logische Folge von Outcomes.

Zur Reduktion der Projektrisiken: Risikominderung wird durch aktives Risikomanagement erreicht, nicht automatisch durch das Erzielen von Outcomes.

☝️ Single Welches Managementprodukt soll die Sicherheit geben, dass eine solide Rechtfertigung für das Projekt besteht?

❌ Nutzenmanagement-Ansatz

✅ Business Case

❌ Projektplan

❌ Projektkurzbeschreibung

Der Business Case dokumentiert die geschäftliche Rechtfertigung und deren fortlaufende Gültigkeit.

Merksatz:
Der Business Case ist der „wirtschaftliche Personalausweis“ des Projekts – ohne dieses Dokument gibt es keine Rechtfertigung für den Start oder die Fortführung.

Warum die anderen falsch sind:
Nutzenmanagement-Ansatz: Er beschreibt nur die Methode, wie Nutzen gemessen und realisiert werden, liefert aber selbst keine Projektberechtigung.
Projektplan: Er zeigt das Wie und Wann der Umsetzung (Zeit und Ressourcen), rechtfertigt aber nicht das Warum.

Projektkurzbeschreibung: Sie ist nur ein vorläufiges Dokument zur Initiierung, das später im Business Case und der Projektleitlinie aufgeht.

Practice Organisieren [F] [Practices] 7 Unterseite →

☝️ Single Ein neues Teammitglied soll eingearbeitet werden und persönliche Ziele erhalten. In welchem Schritt der Technik „Organisationsdesign und -entwicklung“ geschieht das?

❌ Managen laufender Änderungen am Projektökosystem

❌ Das organisatorische Ökosystem verstehen

✅ Das Projektökosystem entwickeln

❌ Das Projektökosystem designen

Das Einbinden und Entwickeln der Beteiligten – inkl. persönlicher Ziele – erfolgt beim „Entwickeln des Projektökosystems“.

Merksatz:
Menschen wachsen und gedeihen: Das Einarbeiten neuer Mitglieder und das Setzen persönlicher Ziele ist wie das Gießen von Pflanzen – wir entwickeln das Projektökosystem aktiv weiter, damit das Team wachsen kann.

Warum die anderen falsch sind:
Verstehen: Hier wird nur die Ist-Situation analysiert, bevor überhaupt gehandelt wird.
Designen: Dies ist die reine Planungsphase am Reißbrett (Strukturen und Rollen festlegen), noch ohne konkrete Personen.

Managen laufender Änderungen: Dies betrifft spätere Anpassungen bei Störungen oder Abweichungen, nicht die initiale Einarbeitung.

☝️ Single Welches Managementprodukt legt individuelle Rechenschaftspflichten, z. B. für Nachhaltigkeitsziele, fest?

❌ Produktbeschreibung

❌ Business Case

❌ Struktur des Projektmanagement-Teams

✅ Rollenbeschreibungen

Rollenbeschreibungen legen Verantwortlichkeiten und Rechenschaftspflichten einzelner Rollen fest.

Merksatz:
Wer im Projekt den Hut aufhat (Rechenschaftspflicht), steht in seiner Rolle – die Rollenbeschreibung verteilt die konkreten Aufgaben und Verantwortungen (wie Nachhaltigkeit) an einzelne Personen.

Warum die anderen falsch sind:
Produktbeschreibung: Definiert die Qualitätsmerkmale eines konkreten Liefergegenstands, nicht die Pflichten von Personen.
Business Case: Begründet nur den wirtschaftlichen Wert und die Tragfähigkeit des Projekts.

Struktur des Projektmanagement-Teams: Zeigt nur das hierarchische Organigramm (wer an wen berichtet), enthält aber keine detaillierten, individuellen Pflichten.

☝️ Single Welche Rolle fokussiert sich vor allem auf Sicherheit und Wohlergehen des Projektteams?

❌ Teammanager

❌ Projektmanager

❌ Projektunterstützung

✅ Lenkungsausschuss

Die Sorge um Sicherheit und Wohlergehen des Teams liegt in der übergeordneten Verantwortung des Lenkungsausschusses.

Merksatz:
Der Lenkungsausschuss lenkt das Projekt wie ein fürsorglicher Kapitän – er trägt die ultimative Verantwortung für das Schiff und sorgt als oberste Instanz dafür, dass die Crew (das Projektteam) sicher und wohlbehalten ans Ziel kommt.

Warum die anderen falsch sind:
Teammanager: Fokussiert sich rein auf die fachliche Lieferung der Arbeitspakete, nicht auf die übergeordnete Fürsorgepflicht.
Projektmanager: Leitet zwar das Tagesgeschäft, hat aber nicht die letztendliche, strategische Verantwortung für das Wohlergehen des gesamten Teams.

Projektunterstützung: Übernimmt nur administrative Aufgaben und hat keinerlei Führungs- oder Fürsorgefunktion.

☝️ Single Ein Abteilungsleiter möchte wissen, welche Personen am Projekt beteiligt sind und wie sie zueinander stehen. Welches Managementprodukt sollte er prüfen?

✅ Struktur des Projektmanagement-Teams

❌ Business Case

❌ Rollenbeschreibungen

❌ Projektlogbuch

Die Struktur des Projektmanagement-Teams zeigt die Beteiligten und ihre organisatorischen Beziehungen.

Merksatz:
Das Projektmanagement-Team ist wie ein Organigramm: Wer mit wem arbeitet und wie alle zueinander stehen, zeigt dir auf einen Blick die Struktur.

Warum die anderen falsch sind:
Business Case: Begründet nur den wirtschaftlichen Nutzen des Projekts, zeigt aber keine Hierarchien oder Personen.
Rollenbeschreibungen: Definieren zwar Aufgaben einzelner Rollen, zeigen aber nicht das Beziehungsnetz des gesamten Teams.

Projektlogbuch: Ist ein informelles Register für tägliche Notizen und Probleme, kein Strukturdiagramm der Organisation.

☝️ Single Welche Aussage über Fähigkeiten und Kompetenzen in einem Projekt ist korrekt?

❌ Teams sollten aus Mitgliedern mit möglichst ähnlichen Kompetenzen bestehen

❌ Standardrollen sollten unabhängig vom Projektbedarf verwendet werden

❌ Die berufliche Weiterentwicklung liegt stets beim Projektmanager

✅ Menschen mit scheinbar gleichen Kompetenzen gehen Aufgaben oft unterschiedlich an

Selbst bei ähnlichen Kompetenzen unterscheiden sich Herangehensweisen; effektive Teams brauchen ein Spektrum an Fähigkeiten.

☝️ Single Welcher allgemeine Projektkontext bezieht sich darauf, dass externe Lieferanten Teile des Projekts liefern?

❌ Liefermethode

❌ Organisatorisch

✅ Kommerziell

❌ Umfang

Der kommerzielle Kontext betrifft die Einbeziehung externer Lieferanten über vertragliche Beziehungen.

Merksatz:
Kommerziell = Kaufen! Wenn externe Lieferanten gegen Geld (Kommerz) Teile des Projekts liefern, befinden wir uns im kommerziellen Kontext.

Warum die anderen falsch sind:

Liefermethode: Bezieht sich auf das „Wie“ der Erstellung (z. B. agil oder sequenziell), nicht auf die vertragliche Herkunft.

Organisatorisch: Betrifft die internen Strukturen, Rollen und Berichtswege des Projektteams, nicht externe Kunden-Lieferanten-Beziehungen.

Umfang: Definiert die zu erbringenden Produkte und Arbeiten, nicht wer diese vertraglich liefert.

☝️ Single Was ist ein Zweck der Practice „Organisieren“?

❌ Festlegen, wie Produkte getestet und abgenommen werden

❌ Bewerten, ob der Nutzen die Kosten übersteigt

❌ Steuern von Änderungen an den Baselines

✅ Festlegen, wie Arbeit und Menschen organisiert werden, um die Projektziele zu erreichen

Die Practice „Organisieren“ definiert, wie Arbeit und Menschen zur Zielerreichung organisiert werden.

Merksatz:
„Organisieren“ ist das Getriebe des Projekts: Es bringt Menschen und Arbeit so zusammen, dass alle Zahnräder perfekt ineinandergreifen, um das gemeinsame Ziel zu erreichen.

Warum die anderen falsch sind:
Testen und Abnehmen: Dies betrifft die Practice Qualität, die sicherstellt, dass Produkte den Anforderungen entsprechen.
Nutzen vs. Kosten: Das ist Kern der Practice Wirtschaftlichkeit, um die fortlaufende geschäftliche Rechtfertigung zu prüfen.
Änderungen an Baselines: Dies gehört zur Practice Veränderung*, die den Umgang mit Änderungsanträgen und Konfigurationen regelt.

Practice Pläne [F] [Practices] 7 Unterseite →

☝️ Single In welchem Schritt der Planungstechnik werden die Aktivitäten zur Erstellung und Lieferung der Produkte identifiziert?

✅ Arbeitspakete organisieren

❌ Schätzungen durchführen

❌ Einen Zeitplan aufstellen

❌ Produkte definieren und analysieren

Nach Definition der Produkte werden im Schritt „Arbeitspakete organisieren“ die nötigen Aktivitäten und Abhängigkeiten festgelegt.

Merksatz:
„Erst packen wir die Arbeit an, bevor der Zeitplan starten kann.“
Stelle dir ein Umzugsteam vor, das die Kisten (Arbeitspakete) stapelt und organisiert, um die Möbel (Produkte) tatsächlich zu liefern.

Warum die anderen falsch sind:
Schätzungen durchführen: Hier geht es um die Berechnung von Aufwand, Zeit und Kosten, nicht um das Identifizieren der konkreten Aktivitäten.
Einen Zeitplan aufstellen: Dies ordnet die Aktivitäten erst zeitlich ein und weist Ressourcen zu, nachdem die Arbeitspakete bereits organisiert wurden.

Produkte definieren und analysieren: In diesem früheren Schritt werden die Produkte selbst (z. B. via Produktstrukturplan) beschrieben, noch nicht die Aktivitäten zu deren Erstellung.

☝️ Single In welchem Schritt der Planungstechnik wird die für die Lieferung erforderliche Ausrüstung bzw. werden Ressourcen ermittelt?

❌ Produkte definieren und analysieren

✅ Schätzungen durchführen

❌ Arbeitspakete organisieren

❌ Einen Zeitplan aufstellen

Ressourcen- und Aufwandsermittlung erfolgt im Schritt „Schätzungen durchführen“.

Merksatz:
Erst wenn du die Größe des Berges schätzt, weißt du, wie viele Seile und Bergführer (Ressourcen/Ausrüstung) du wirklich brauchst. Schätzen bestimmt das „Wie viel“ an Mensch und Material.

Warum die anderen falsch sind:
Produkte definieren und analysieren: Hier geht es nur darum, was geliefert wird (Anforderungen), noch nicht um die benötigten Ressourcen.
Arbeitspakete organisieren: Dies strukturiert die Zuständigkeiten und die Verteilung der Arbeit, ermittelt aber nicht die Ressourcenmenge.

Einen Zeitplan aufstellen: Hier werden die Aktivitäten in eine logische Reihenfolge und auf einer Zeitachse platziert, nachdem Ressourcen und Aufwände bereits geschätzt wurden.

☝️ Single Was ist als übergeordneter Plan definiert, der die wichtigsten Produkte des Projekts zeigt?

❌ Phasenplan

❌ Teamplan

❌ Ausnahmeplan

✅ Projektplan

Der Projektplan ist der übergeordnete Plan mit den wichtigsten Produkten und Meilensteinen des Gesamtprojekts.

Merksatz:
Der Projektplan ist die „Satellitenkarte“ des gesamten Projekts: Er zeigt das große Ganze und alle wichtigen Liefergegenstände (Produkte) aus der Vogelperspektive.

Warum die anderen falsch sind:
Phasenplan: Fokussiert sich als „Lupe“ nur auf die Details einer einzelnen Managementphase, nicht auf das gesamte Projekt.
Teamplan: Ist die „Werkzeugkiste“ für die Arbeitspakete eines bestimmten Teams und viel zu kleinteilig.

Ausnahmeplan: Wird als „Feuerlöscher“ nur bei Toleranzüberschreitungen erstellt, um den aktuellen Plan zu ersetzen, ist aber kein standardmäßiger Gesamtplan.

☝️ Single Wie sollte der Projektmanager den Planungshorizont berücksichtigen?

✅ Durch einen detaillierteren Phasenplan für die jeweils nächste Phase

❌ Durch Verzicht auf Detailplanung zugunsten von Toleranzen

❌ Durch einen vollständigen, detaillierten Projektplan zu Beginn

❌ Durch identische Detailtiefe für alle Phasen

Wegen des begrenzten Planungshorizonts wird die jeweils nächste Phase detaillierter geplant als das Gesamtprojekt.

Merksatz:
„Der Nebel lichtet sich Schritt für Schritt“ – Je weiter die Zukunft entfernt ist, desto ungenauer ist der Blick. Deshalb planen wir das große Ganze grob, aber die jeweils nächste Phase messerscharf und detailliert im Phasenplan.

Verzicht auf Detailplanung: Toleranzen sind kein Ersatz für konkrete Pläne, sondern definieren nur den Handlungsspielraum bei Abweichungen.
Vollständiger Detailplan zu Beginn: Zu Projektbeginn fehlen noch die nötigen Informationen für verlässliche Details der fernen Zukunft (Planungshorizont überschritten).

Identische Detailtiefe für alle Phasen: Ignoriert die Realität, dass nahe Ereignisse präziser planbar sind als weit entfernte Phasen.

☝️ Single Welcher Plan sollte erstellt werden, wenn eine Phase voraussichtlich ihre Toleranzen überschreiten wird?

✅ Ausnahmeplan

❌ Phasenplan

❌ Teamplan

❌ Projektplan

Bei drohender Toleranzüberschreitung wird ein Ausnahmeplan erstellt, der den bestehenden Plan ersetzt.

Merksatz:
Wenn das Schiff vom Kurs abweicht (Toleranzüberschreitung), herrscht der Ausnahmezustand – du brauchst sofort den Ausnahmeplan, um das Steuer wieder herumzureißen!

Phasenplan: Falsch, weil er den regulären Ablauf einer Phase beschreibt und nicht die Rettung bei einer Toleranzüberschreitung.
Teamplan: Falsch, weil er nur die Arbeitspakete einzelner Teams steuert, nicht aber die Phasenabweichung auf Management-Ebene.

Projektplan: Falsch, weil er die grobe Gesamtübersicht des Projekts darstellt und nicht operativ auf eine akute Phasenkrise reagiert.

☝️ Single Ergänzen Sie: Bei der Planung gibt es mindestens zwei Arten von [?], die für ein Projekt relevant sind: interne und externe.

❌ Toleranzen

✅ Abhängigkeiten

❌ Ausnahmen

❌ Umfänge

Es werden interne und externe Abhängigkeiten unterschieden; interne liegen in der Kontrolle des Projektteams.

Merksatz: Interne und externe Abhängigkeiten sind wie Nabelschnüre: Das Projekt ist davon nicht autark, sondern braucht Inputs von innen (z.B. Team) und außen (z.B. Lieferanten).

Warum die anderen falsch sind:
Toleranzen: Beschreiben erlaubte Abweichungen, nicht die Art der Planungselemente.
Ausnahmen: Sind Abweichungen von Toleranzen, keine grundlegenden Planungsarten.

Umfänge: Definieren das Was des Projekts, nicht die Beziehungen zu anderen Elementen.

☝️ Single Ergänzen Sie: Eine [?] Abhängigkeit besteht zwischen zwei Produkten des Projekts, über die das Projektteam die Kontrolle hat.

❌ ressourcengesteuerte

❌ zeitgesteuerte

✅ interne

❌ externe

Interne Abhängigkeiten liegen innerhalb der Kontrolle des Projektteams, externe außerhalb.

Merksatz:
Alles, was das Team selbst in der Hand hat, ist intern – wie die Organe im eigenen Körper, die man selbst kontrolliert.

ressourcengesteuerte: Beschreibt die Limitierung durch Arbeitskräfte/Material, nicht den internen Kontrollbereich der Produktbeziehung.
zeitgesteuerte: Bezieht sich auf den reinen Ablaufplan (Früher/Später), nicht auf die organisatorische Zuständigkeit.

externe: Hier liegt die Kontrolle außerhalb des Projekts (z. B. bei Lieferanten oder Behörden), nicht beim eigenen Team.

Practice Qualität [F] [Practices] 7 Unterseite →

☝️ Single In welchem Schritt der Qualitätsmanagement-Technik übernimmt der Benutzer nach erfolgreichem Test die Verantwortung für ein Produkt?

❌ Sammeln von Benutzer-Inputs

✅ Abnehmen von Produkten

❌ Beschreibung des Qualitätsmanagement-Ansatzes

❌ Steuerung der Qualität

Die Übernahme der Verantwortung durch den Benutzer nach dem Test erfolgt im Schritt „Abnehmen von Produkten“.

Merksatz:
Der Benutzer nimmt das fertige Geschenk (Produkt) ab und trägt ab jetzt die Verantwortung dafür – wie bei der Paketabnahme an der Haustür.

Warum die anderen falsch sind:

Sammeln von Benutzer-Inputs ist nur der allererste Schritt zur Anforderungsdefinition, noch weit vor jedem Test oder einer Übergabe.

Beschreibung des Qualitätsmanagement-Ansatzes plant lediglich die Strategie und Methoden für das gesamte Projekt, statt konkrete Produkte zu übergeben.

Steuerung der Qualität ist der laufende Prozess der Qualitätsprüfung und -überwachung, nicht der finale formelle Akt der Verantwortungsübernahme.

☝️ Single Wo sollte festgehalten werden, dass ein Produkt getestet, aber noch nicht genehmigt wurde?

❌ Produktregister

❌ Qualitätsspezifikationen

❌ Projektproduktbeschreibung

✅ Qualitätsregister

Das Qualitätsregister verfolgt geplante und durchgeführte Qualitätsaktivitäten samt ihrem Status.

Merksatz:
Das Qualitätsregister ist das „Tagebuch der Tests“: Hier wird jeder Schritt (geplant, getestet, genehmigt) laufend protokolliert – wie ein dynamisches Klassenbuch für Produktprüfungen.

Warum die anderen falsch sind:
Produktregister: Ein solches Register existiert in PRINCE2 nicht (Verwechslung mit der Produktstruktur).
Qualitätsspezifikationen: Diese definieren vorab die Kriterien und Anforderungen, dokumentieren aber keinen aktuellen Teststatus.

Projektproduktbeschreibung: Sie ist das übergeordnete Dokument für die Kundenerwartungen zu Projektbeginn, kein laufendes Kontrollwerkzeug für Einzelprodukte.

☝️ Single Was ist ein Zweck der Practice „Qualität“?

❌ Die Rechtfertigung des Projekts fortlaufend zu prüfen

✅ Sicherzustellen, dass die Produkte die dokumentierten Erwartungen der Benutzer erfüllen

❌ Die Reihenfolge der Managementphasen festzulegen

❌ Änderungen an der Baseline zu genehmigen

Die Practice „Qualität“ stellt sicher, dass Produkte die dokumentierten Qualitätserwartungen der Benutzer erfüllen.

Merksatz: Qualität sichert, dass der Kunde am Ende jubelt, weil das Produkt genau seinen dokumentierten Erwartungen entspricht. Es ist wie beim maßgeschneiderten Anzug – er muss perfekt sitzen, nicht nur „irgendwie gut“.

Warum die anderen falsch sind:
Die Rechtfertigung des Projekts fortlaufend zu prüfen – Das ist die Aufgabe der Practice "Business Case".
Die Reihenfolge der Managementphasen festzulegen – Das ist Teil der Practice "Pläne".

Änderungen an der Baseline zu genehmigen – Das gehört zur Practice "Risiko" oder "Change".

☝️ Single Wo sollte eine Leitlinie stehen, wie und wann Prototyping im Projekt eingesetzt werden soll?

❌ Qualitätsregister

❌ Projektproduktbeschreibung

❌ Produktbeschreibung

✅ Qualitätsmanagement-Ansatz

Der Qualitätsmanagement-Ansatz beschreibt die im Projekt eingesetzten Qualitätsmethoden, einschließlich Prototyping.

Merksatz:
Der Qualitätsmanagement-Ansatz ist das „Kochbuch“ für Qualität: Hier steht die allgemeine Anleitung (wie und wann Prototyping genutzt wird), während die Produkte selbst nur das fertige Gericht sind.

Warum die anderen falsch sind:
Qualitätsregister: Ist nur das Protokoll-Tagebuch, das die tatsächlichen Testergebnisse dokumentiert, keine methodische Anleitung.
Projektproduktbeschreibung: Definiert nur die Erwartungen des Kunden an das finale Gesamtprodukt, nicht die detaillierte Entwicklungsmethode.

Produktbeschreibung: Beschreibt die Spezifikationen eines einzelnen Bauteils, nicht den projektweiten Prozess für Prototypen.

☝️ Single Was beschreibt Qualitätsspezifikationen am treffendsten?

✅ Sie werden bei der Inspektion eines fertigen Produkts angewendet

❌ Sie definieren die Reihenfolge der Phasen

❌ Sie ersetzen die Produktbeschreibung

❌ Sie beschreiben die Projektorganisation

Qualitätsspezifikationen (Kriterien/Methoden) werden bei der Prüfung eines fertigen Produkts angewendet.

Merksatz:
Die Qualitätsspezifikation ist das Lineal bei der Endkontrolle: Erst wenn das Produkt fertig ist, legt man die Spezifikation an, um zu prüfen, ob es passt.

Warum die anderen falsch sind:
Reihenfolge der Phasen: Dies regelt der Projektplan (Pläne-Practice), nicht die Qualitätsprüfung einzelner Produkte.
Ersetzen die Produktbeschreibung: Sie sind ein integraler Bestandteil der Produktbeschreibung, kein Ersatz dafür.

Projektorganisation: Dafür ist das Organisations-Thema (Organisations-Practice) zuständig, das Rollen und Verantwortlichkeiten definiert.

☝️ Single Welche Aussage beschreibt Qualitätssicherung – NICHT Projektsicherung?

❌ Sie ist unabhängig vom Projektmanager, aber nicht vom Projekt

✅ Sie ist unabhängig vom Projekt und oft Teil des Qualitätsmanagementsystems der Organisation

❌ Sie bestätigt dem Auftraggeber die korrekte Projektführung

❌ Sie ist eine Verantwortung des Lenkungsausschusses

Qualitätssicherung ist unabhängig vom Projekt und typischerweise Teil des organisationsweiten Qualitätsmanagementsystems.

Merksatz:
Die QualitätsSicherung ist System- und Struktur-Sache der gesamten Organisation (extern zum Projekt), während die ProjektSicherung den Steuerungsausschuss im Projekt unterstützt.

Warum die anderen falsch sind:

Unabhängig vom PM, aber nicht vom Projekt: Dies beschreibt die Projektsicherung, die direkt im Projekt verankert ist.

Bestätigt dem Auftraggeber korrekte Projektführung: Das ist die Kernaufgabe der Projektsicherung zur Beruhigung des Lenkungsausschusses.

Verantwortung des Lenkungsausschusses: Der Lenkungsausschuss ist für die Projekt- und nicht für die organisationsweite Qualitätssicherung zuständig.

☝️ Single Welches Managementprodukt liefert die Leitlinie zu den Techniken, mit denen die Abnahmekriterien nachgewiesen werden?

❌ Qualitätsmanagement-Ansatz

❌ Qualitätsregister

❌ Produktbeschreibung

✅ Projektproduktbeschreibung

Die Projektproduktbeschreibung definiert Abnahmekriterien und -methode für das Projektprodukt.

Merksatz:
Die Projektproduktbeschreibung ist der „Masterplan“ für das gesamte Projektziel: Hier stehen die finalen Abnahmekriterien des Kunden und wie deren Erfüllung am Ende nachgewiesen wird.

Qualitätsmanagement-Ansatz: Definiert nur die allgemeinen Spielregeln, Werkzeuge und Zuständigkeiten für das Qualitätsmanagement im Projekt, nicht die konkreten Kriterien des Endprodukts.
Qualitätsregister: Ist nur das Protokoll (Tagebuch), das geplante und durchgeführte Qualitätsaktivitäten dokumentiert.

Produktbeschreibung: Bezieht sich nur auf einzelne, kleinere Teilprodukte (Komponenten) des Projekts, nicht auf das übergeordnete Gesamtprodukt und dessen finale Abnahme.

Practice Risiko [F] [Practices] 7 Unterseite →

☝️ Single Wer ist dafür verantwortlich, zufriedenstellend auf ein bestimmtes Risiko zu reagieren (die Maßnahme umzusetzen)?

❌ Projektunterstützung

✅ Risikobearbeiter

❌ Projektsicherung

❌ Risikoeigentümer

Der Risikobearbeiter setzt die vereinbarte Maßnahme um; der Risikoeigentümer verantwortet das Risiko insgesamt.

Merksatz:
Der Eigentümer besitzt das Haus (Risiko), aber der Handwerker (Risikobearbeiter) führt die Arbeit (Maßnahme) tatsächlich aus.

Warum die anderen falsch sind:
Risikoeigentümer: Er steuert und überwacht das Risiko strategisch, führt die Maßnahme aber nicht selbst operativ durch.
Projektsicherung: Sie prüft nur unabhängig, ob das Risikomanagement korrekt durchgeführt wird, greift aber nicht aktiv ein.

Projektunterstützung: Sie übernimmt nur administrative Aufgaben (wie das Pflegen des Risikoreregisters), setzt aber keine Risikomaßnahmen um.

☝️ Single Welcher Begriff bezeichnet die Person, die für die Überwachung eines bestimmten Risikos gesamtverantwortlich ist?

✅ Risikoeigentümer

❌ Projektsicherung

❌ Risikobearbeiter

❌ Teammanager

Der Risikoeigentümer trägt die Gesamtverantwortung für Überwachung und Steuerung eines Risikos.

Merksatz:
Der Risikoeigentümer (Risk Owner) besitzt das Risiko – wer etwas „besitzt“, trägt die Gesamtverantwortung für dessen Überwachung, so wie ein Hausbesitzer für sein Gebäude.

Warum die anderen falsch sind:
Projektsicherung: Prüft unabhängig, ob das Risikomanagement korrekt durchgeführt wird, trägt aber keine direkte operative Verantwortung für einzelne Risiken.
Risikobearbeiter: Führt nur die konkreten Maßnahmen aus, während die Gesamtverantwortung beim Eigentümer bleibt.

Teammanager: Ist für die Lieferung der Arbeitspakete zuständig, nicht für die übergreifende Gesamtverantwortung eines spezifischen Projektrisikos.

☝️ Single Wo erhält das Projektmanagement-Team die Leitlinie, wie Bedrohungen aufgezeichnet werden sollen?

❌ Risikoregister

❌ Issueregister

✅ Risikomanagement-Ansatz

❌ Arbeitspaketbeschreibung

Der Risikomanagement-Ansatz beschreibt Vorgehen, Rollen und Vorgaben, u. a. wie Risiken erfasst werden.

Merksatz:
Der Ansatz zeigt dir das Wie, das Register nur das Was. Wie du Risiken (Bedrohungen) anpackst und aufzeichnest, steht im Risikomanagement-Ansatz – er ist das Rezeptbuch, das Register nur die Zutatenliste.

Risikoregister: Falsch, weil es die konkreten, bereits erfassten Risiken auflistet, aber nicht die allgemeine Anleitung (die Methode) zur Aufzeichnung enthält.
Issueregister: Falsch, weil es für bereits eingetretene Probleme (Issues) zuständig ist, nicht für zukünftige Bedrohungen (Risiken).

Arbeitspaketbeschreibung: Falsch, weil sie nur die konkrete Arbeit und die Toleranzen für ein bestimmtes Paket definiert, nicht aber die projektweite Risikostrategie.

☝️ Single Was wird bei der qualitativen Analyse eines Risikos mindestens bewertet?

❌ Die Kosten der Gegenmaßnahme

❌ Der Notfallplan für das Risiko

✅ Wahrscheinlichkeit und Auswirkung des Risikos

❌ Wie schnell das Risiko eintreten könnte

Die qualitative Analyse bewertet mindestens Eintrittswahrscheinlichkeit und Auswirkung je Risiko.

Merksatz: "WIE wahrscheinlich ist es, dass ein Risiko WIE stark AUSWIRKUNG hat?" – Stell dir einen Wetterbericht vor, der die Wahrscheinlichkeit von Regen und dessen Stärke (Auswirkung) bewertet.

Warum die anderen falsch sind:
Die Kosten der Gegenmaßnahme: Gehört zur Risikoreaktion, nicht zur qualitativen Analyse.
Der Notfallplan für das Risiko: Ist eine mögliche Risikoreaktion, keine qualitative Bewertung.

Wie schnell das Risiko eintreten könnte: Ist ein Element der zeitlichen Nähe, aber nicht das Kernstück der qualitativen Bewertung.

☝️ Single Ein Projektmanager möchte prüfen, ob eine Maßnahme gegen eine Bedrohung bereits umgesetzt wurde. Wo prüft er das?

❌ Teamstatusbericht

❌ Produktregister

❌ Risikomanagement-Ansatz

✅ Risikoregister

Der aktuelle Status von Risikomaßnahmen wird im Risikoregister festgehalten.

Merksatz:
Das Risikoregister ist das dynamische „Tagebuch“ aller Gefahren – hier steht nicht nur, was droht, sondern im aktuellen Status auch haarklein, ob die Abwehrmaßnahme schon aktiv ist.

Warum die anderen falsch sind:
Teamstatusbericht: Zeigt nur den Arbeitsfortschritt von Arbeitspaketen, ist aber kein zentrales Tool für die Verfolgung einzelner Risikomaßnahmen.
Produktregister: Listet den Zustand der Projektergebnisse (Produkte) auf, nicht den Status von Risikobewältigungen.

Risikomanagement-Ansatz: Beschreibt nur die strategischen Spielregeln und Methoden („wie“ man vorgeht), enthält aber keine konkreten, aktuellen Risikodaten.

☝️ Single Wie unterstützt die Identifikation der Ursache eines Risikos die Risikoplanung?

❌ Sie bestimmt automatisch die Eintrittsnähe

✅ Sie ermöglicht die Zuordnung geeigneter Maßnahmen und Verantwortlichkeiten

❌ Sie ersetzt die Bewertung der Auswirkung

❌ Sie legt das Risikobudget fest

Das Verständnis der Ursache hilft, passende Präventiv-/Gegenmaßnahmen und Verantwortlichkeiten festzulegen.

☝️ Single Was ist ein Zweck der Practice „Risiko“?

✅ Die Erfolgschancen durch Steuerung von Unsicherheiten zu erhöhen

❌ Die Reihenfolge der Phasen zu bestimmen

❌ Änderungen an der Baseline zu genehmigen

❌ Die Qualitätskriterien der Produkte festzulegen

Die Practice „Risiko“ erhöht die Erfolgschancen, indem sie Bedrohungen und Chancen erkennt, bewertet und steuert.

Practice Issues [F] [Practices] 7 Unterseite →

☝️ Single In welchem Schritt der Issuemanagement-Technik wird die Auswirkung eines Issues auf Umfang, Kosten und Nutzen analysiert?

❌ Implementieren von Änderungen

✅ Bewerten von Issues

❌ Entscheidung über Änderungen

❌ Erfassen von Issues

Die Analyse der Auswirkungen erfolgt im Schritt „Bewerten von Issues“.

Merksatz:
Erst bewerten, dann agieren – wer die Waagschale (Auswirkung) für Kosten, Nutzen und Umfang hält, muss den Issue genau bewerten.

Warum die anderen falsch sind:
Implementieren von Änderungen: Hier wird die beschlossene Lösung bereits umgesetzt, nicht mehr analysiert.
Entscheidung über Änderungen: Dies ist der Folgeschritt, der auf den Ergebnissen der Bewertung basiert.

Erfassen von Issues: Hier wird das Problem nur formell registriert und beschrieben, noch nicht auf Auswirkungen untersucht.

☝️ Single Was ist die Definition eines Issues?

✅ Ein Ereignis, das für das Projekt relevant ist und Managementaufmerksamkeit erfordert

❌ Eine prognostizierte Toleranzüberschreitung

❌ Ein unsicheres Ereignis mit möglicher Zielauswirkung

❌ Ein Vorschlag zur Änderung einer Baseline

Ein Issue ist ein bereits relevantes Ereignis, das vom Projektmanagement berücksichtigt werden muss.

Merksatz:
Ein Issue ist wie eine rote Sirene im Projekt: Es ist JETZT real passiert, betrifft das Projekt direkt und zwingt das Management zum sofortigen Hinschauen und Handeln (Aufmerksamkeit).

Warum die anderen falsch sind:
Eine prognostizierte Toleranzüberschreitung ist eine drohende Abweichung (Exception), kein allgemeines Issue.
Ein unsicheres Ereignis mit möglicher Auswirkung beschreibt ein Risiko (Zukunft), während ein Issue bereits Realität ist (Gegenwart).
Ein Vorschlag zur Änderung einer Baseline ist ein spezifischer Änderungsantrag* (Request for Change), was nur eine Unterart von Issues sein kann.

☝️ Single Was ist die Definition einer Spezifikationsabweichung?

❌ Eine genehmigte Version eines Produkts

❌ Ein Vorschlag zur Änderung einer Baseline

✅ Etwas, das geliefert werden sollte, aber voraussichtlich nicht (vollständig) geliefert wird

❌ Ein unsicheres zukünftiges Ereignis

Eine Spezifikationsabweichung liegt vor, wenn ein Produkt seine vereinbarte Spezifikation voraussichtlich nicht erfüllt.

Merksatz:
Eine Spezifikationsabweichung ist wie eine Lücke im Lieferkarton: Du erwartest das fertige Produkt, aber es wird nicht oder nur unvollständig geliefert.

Warum die anderen falsch sind:
Genehmigte Version: Das beschreibt eine freigegebene Baseline (Bezugslinie) und keinen Fehler oder Mangel.
Vorschlag zur Änderung: Dies ist ein Änderungsantrag (Request for Change), der eine formelle Anpassung anstrebt.

Unsicheres zukünftiges Ereignis: Das ist die klassische Definition eines Risikos, nicht einer bereits absehbaren Abweichung.

☝️ Single Welches Managementprodukt sollte die Projektunterstützung prüfen, um zu verstehen, wie Änderungen an genehmigten Produkten vorgenommen werden?

❌ Nutzenmanagement-Ansatz

❌ Risikomanagement-Ansatz

✅ Issuemanagement-Ansatz

❌ Qualitätsmanagement-Ansatz

Der Issuemanagement-Ansatz beschreibt Verfahren und Verantwortlichkeiten für Änderungen an genehmigten Produkten.

Merksatz:
Ein Issue (Problem/Änderungswunsch) bringt das Projekt zum Wackeln – der Issuemanagement-Ansatz regelt, wie wir Änderungen an Produkten kontrolliert abwickeln.

Warum die anderen falsch sind:
Nutzenmanagement-Ansatz: Misst nur den geschäftlichen Erfolg und die Realisierung der Projektvorteile, nicht den Umgang mit Produktänderungen.
Risikomanagement-Ansatz: Befasst sich ausschließlich mit unsicheren zukünftigen Ereignissen (Bedrohungen/Chancen), nicht mit bereits konkreten Änderungsanträgen.

Qualitätsmanagement-Ansatz: Definiert Qualitätsstandards und Prüfverfahren, regelt aber nicht den formalen Prozess zur Steuerung von Produktänderungen.

☝️ Single Wie trägt die Practice „Issues“ zu einem erfolgreichen Projekt bei?

✅ Durch Steuerung von Modifikationen an genehmigten Versionen der Managementprodukte

❌ Durch Identifikation positiver Zielauswirkungen

❌ Durch Planung der Nutzenmessung

❌ Durch Festlegen der Qualitätskriterien

Die Practice steuert Änderungen an genehmigten (baseline-gesetzten) Produkten kontrolliert.

Merksatz:
„Issues kontrollieren die Versionen.“ Stell dir ein rotes Stoppschild („Issue“) vor einer Druckerpresse vor: Bevor eine bereits genehmigte Version (Managementprodukt) modifiziert und neu gedruckt werden darf, muss das Issue-Management erst grünes Licht geben.

Identifikation positiver Zielauswirkungen: Dies ist Aufgabe des Risikomanagements (Chancen/Opportunities), nicht von Issues.
Planung der Nutzenmessung: Dafür ist die Practice „Nutzen“ (Benefits) zuständig, die den Wertbeitrag des Projekts nachverfolgt.

Festlegen der Qualitätskriterien: Dies gehört zur Practice „Qualität“, um die Produkteigenschaften und Erwartungen des Kunden zu definieren.

☝️ Single Wann sollte die Projekt-Baseline im Sinne der Practice „Issues“ aktualisiert werden?

❌ Sobald eine Chance erkannt wird

❌ Sobald ein Issue identifiziert wird

❌ Sobald ein Änderungsantrag im Issueregister erfasst wird

✅ Sobald die Änderungsinstanz eine Änderung genehmigt hat

Die Baseline wird erst aktualisiert, nachdem die zuständige Änderungsinstanz die Änderung genehmigt hat.

Merksatz:
Erst wenn der Richter den Hammer schwingt, wird das Gesetz gültig – erst wenn die Änderungsinstanz die Änderung genehmigt, wird die Baseline aktualisiert. Kein Stift wird angesetzt, bevor die offizielle Freigabe vorliegt.

Warum die anderen falsch sind:
Chance erkannt: Das Erkennen einer Option ist reine Theorie und verändert noch keine festgeschriebenen Pläne.
Issue identifiziert: Ein Problem zu finden bedeutet nur, dass Klärungsbedarf besteht, nicht dass sich der Plan bereits ändert.

Änderungsantrag erfasst: Die bloße Registrierung im Register ist nur ein bürokratischer Zwischenschritt vor der eigentlichen Entscheidung.

☝️ Single Welcher Teil effektiven Issuemanagements ermöglicht es, eine genehmigte Änderung tatsächlich umzusetzen?

✅ Delegierte Entscheidungsbefugnis der zuständigen Ebene

❌ Die Eskalation an die Business-Ebene

❌ Das Audit des Produktregisters

❌ Die Definition der Baseline-Detailtiefe

Die delegierte Befugnis, auf der passenden Ebene über Änderungen zu entscheiden, ermöglicht deren Umsetzung.

Merksatz:
Erst die Unterschrift auf dem Scheck (delegierte Entscheidungsbefugnis) macht den Einkauf möglich – ohne die offizielle Erlaubnis der zuständigen Ebene bleibt jede genehmigte Änderung nur ein zahnloser Papiertiger auf dem Schreibtisch.

Warum die anderen falsch sind:
Eskalation an die Business-Ebene: Verzögert die Umsetzung unnötig, statt sie direkt vor Ort durch die bereits zuständige Ebene freizugeben.
Audit des Produktregisters: Ist nur eine nachträgliche Qualitätskontrolle der Dokumente, kein aktiver Motor für die praktische Durchführung.

Definition der Baseline-Detailtiefe: Bestimmt nur den Startpunkt und den Detailgrad der Planung, liefert aber keine Handlungsvollmacht für die konkrete Umsetzung.

Practice Fortschritt [F] [Practices] 7 Unterseite →

☝️ Single Was ist der Zweck der Practice „Fortschritt“?

✅ Vorherzusagen, ob die Phase rechtzeitig und im Budget liefert

❌ Die Rollen im Team zu definieren

❌ Änderungen an der Baseline zu genehmigen

❌ Die Qualitätskriterien der Produkte festzulegen

Die Practice „Fortschritt“ überwacht und prognostiziert, ob Ziele innerhalb der Toleranzen erreicht werden.

Merksatz:
Der Fortschritt ist dein Blick in die Kristallkugel: Er prognostiziert wie ein Wetterbericht, ob du das Ziel (Phase) noch pünktlich (Zeit) und ohne Pleite (Budget) erreichst.

Warum die anderen falsch sind:
Rollen definieren: Das ist Aufgabe der Practice „Organisation“, nicht der Fortschrittskontrolle.
Änderungen genehmigen: Dafür ist das Änderungsmanagement (Practice „Veränderung“) zuständig.

Qualitätskriterien festlegen: Dies gehört logischerweise zur Practice „Qualität“, um die Produktanforderungen zu definieren.

☝️ Single Auf welchen Ebenen sollte der Fortschritt am ehesten überwacht werden?

❌ Nur bei Projektabschluss

❌ Nur auf Produktlieferungsebene

✅ Auf Projekt-, Phasen- und Arbeitspaketebene

❌ Nur an den Phasenübergängen

Fortschritt wird auf Projekt-, Phasen- und Arbeitspaketebene überwacht.

☝️ Single Welches Managementprodukt nutzt der Projektmanager, um dem Lenkungsausschuss regelmäßig über den Phasenfortschritt zu berichten?

❌ Ausnahmebericht

✅ Projektstatusbericht

❌ Teamstatusbericht

❌ Phasenabschlussbericht

Der Projektstatusbericht (Highlight Report) dient der regelmäßigen Fortschrittsberichterstattung an den Lenkungsausschuss.

Merksatz:
Der Projektstatusbericht ist das regelmäßige „Status-Update“ (Highlight Report) direkt vom Projektmanager an die Chefetage (Lenkungsausschuss), um den aktuellen Phasenfortschritt transparent zu zeigen.

Ausnahmebericht: Wird nur bei drohenden Toleranzüberschreitungen (Ausnahmen) erstellt, nicht regelmäßig.
Teamstatusbericht: Geht vom Teammanager an den Projektmanager, nicht an den Lenkungsausschuss.

Phasenabschlussbericht: Wird erst am Ende einer Phase erstellt, nicht für die regelmäßige Berichterstattung zwischendurch.

☝️ Single Was ist die Definition einer Ausnahme?

❌ Ein Bericht über den Status eines Arbeitspakets

❌ Ein Produkt, das seine Spezifikation nicht erfüllt

✅ Eine prognostizierte Abweichung über die vereinbarten Toleranzen hinaus

❌ Ein unsicheres Ereignis mit möglicher Zielauswirkung

Eine Ausnahme ist die prognostizierte (oder eingetretene) Überschreitung vereinbarter Toleranzen.

Merksatz: Eine Ausnahme ist wie ein Prognose-Alarm, der anzeigt: "Wir werden die Toleranz-Grenze überschreiten!" – Ein klares Signal, dass das Projekt vom Pfad abweicht.

Warum die anderen falsch sind:
Ein Bericht über den Status eines Arbeitspakets: Beschreibt den Ist-Zustand, nicht eine Abweichungsprognose.
Ein Produkt, das seine Spezifikation nicht erfüllt: Ist ein Qualitätsproblem, keine Management-Ausnahme im PRINCE2-Sinne.

Ein unsicheres Ereignis mit möglicher Zielauswirkung: Dies ist die Definition eines Risikos, nicht einer Ausnahme.

☝️ Single Wie sollte die Nutzung von Daten und Systemen effektives Fortschrittsmanagement unterstützen?

❌ Durch Festlegen der Phasenreihenfolge

✅ Durch Bereitstellung genauer Daten zur Prognose zukünftiger Leistung

❌ Durch alleiniges Sammeln vergangener Daten

❌ Durch Konzentration auf manuelle Datenerfassung

Verlässliche Daten helfen, die zukünftige Projektleistung vorherzusagen und rechtzeitig zu steuern.

☝️ Single Welcher Steuerungstyp wird durch ein bestimmtes Ereignis ausgelöst und nicht in festen Intervallen?

❌ Zeitbasierte Steuerung

❌ Prognosebasierte Steuerung

❌ Toleranzbasierte Planung

✅ Ereignisbasierte Steuerung

Ereignisbasierte Steuerungen (z. B. Phasenende, Ausnahmebericht) werden durch bestimmte Ereignisse ausgelöst.

Merksatz:
Ein Ereignis (wie ein Unfall oder ein Meilenstein) löst sofort eine ereignisbasierte Steuerung aus – genau wie ein Rauchmelder, der nur bei Rauch (Ereignis) schrillt und nicht alle zwei Stunden.

Zeitbasierte Steuerung: Reagiert stur nach Kalender (z. B. wöchentlich), völlig unabhängig von aktuellen Vorfällen.
Prognosebasierte Steuerung: Schaut hypothetisch in die Zukunft, statt auf ein konkret eingetretenes Ereignis zu reagieren.

Toleranzbasierte Planung: Ist ein Konzept zur Festlegung von Handlungsspielräumen (Budgets/Zeit), aber kein Steuerungstyp, der durch Ereignisse gestartet wird.

☝️ Single Welches Managementprodukt eskaliert eine prognostizierte Toleranzüberschreitung an den Lenkungsausschuss?

❌ Teamstatusbericht

❌ Phasenabschlussbericht

✅ Ausnahmebericht

❌ Projektstatusbericht

Der Ausnahmebericht meldet dem Lenkungsausschuss eine prognostizierte Überschreitung der Phasen- oder Projekttoleranzen.

Die 7 Prinzipien

Principles Übersicht [F] [Prinzipien] 1 Unterseite →

☝️ Single Wie viele Principles hat PRINCE2 (7. Edition)?

❌ Neun

❌ Vier

✅ Sieben

❌ Fünf

Sieben Principles bilden das Fundament jedes PRINCE2-Projekts.

Merksatz:
Denk an die 7 Weltwunder des Projektmanagements: PRINCE7 hat genau 7 Prinzipien (Principles) – sie sind das unerschütterliche Fundament, auf dem jede Edition steht.

Warum die anderen falsch sind:

Neun: Zu hoch angesetzt – verwechselt die Prinzipien mit den (nicht existierenden) Management-Phasen.

Vier: Zu wenig – das entspricht eher den vier integrierten Elementen von PRINCE2 (People, Practice, Process, Project Context).

Fünf: Falsche Zahl – verwechselt die Prinzipien mit den fünf Leistungsfaktoren (Performance Targets), von denen es in Version 7 übrigens sechs gibt.

Alle 7 Principles Pflicht [F] [Prinzipien] 1 Unterseite →

☝️ Single Was gilt laut PRINCE2, wenn ein Projekt nur 6 von 7 Principles anwendet?

❌ Nur die Practices sind dann betroffen, nicht die Principles

❌ Es zählt trotzdem als vollständiges PRINCE2-Projekt

❌ Das ist völlig unproblematisch und weiterhin PRINCE2

✅ Es ist kein PRINCE2-Projekt im eigentlichen Sinne

Es handelt sich dann nicht um ein "echtes" PRINCE2-Projekt — alle 7 müssen angewendet werden.

Merksatz:
PRINCE2 ist wie ein Tisch mit 7 Beinen: Fehlt auch nur ein einziges Bein (Prinzip), bricht das PRINCE2-Projekt zusammen – es ist dann schlicht kein PRINCE2-Projekt mehr.

Warum die anderen falsch sind:
A: ...weil die Prinzipien das Fundament bilden und ihr Fehlen das gesamte Projekt (nicht nur Practices) betrifft.
B: ...weil PRINCE2 keine "Pick-and-Choose"-Methode ist, sondern alle 7 Prinzipien zwingend vorschreibt.

C: ...weil das Weglassen eines Prinzips die methodische Integrität zerstört und somit hochproblematisch ist.

Continued Business Justification [F] [Prinzipien] 1 Unterseite →

☝️ Single Was fordert das Principle "Continued Business Justification"?

❌ Der Business Case muss nur zu Beginn des Projekts erstellt und genehmigt werden, danach ist keine weitere Überprüfung erforderlich.

✅ Der Nutzen muss während der gesamten Projektlaufzeit gerechtfertigt bleiben

❌ Die fortlaufende Rechtfertigung des Nutzens ist ausschließlich bei Projekten mit einem hohen Budget oder einer langen Laufzeit verpflichtend.

❌ Die Business Justification bezieht sich allein auf die anfängliche Investitionsentscheidung und ist nach dem Projektstart nicht mehr relevant.

Der geschäftliche Nutzen muss über die GESAMTE Projektlaufzeit gerechtfertigt bleiben, nicht nur zu Beginn.

Merksatz:
Ein Projekt ist wie eine Taxifahrt: Du musst während der gesamten Fahrt prüfen, ob sich der Weg zum Ziel finanziell noch lohnt, nicht nur beim Einsteigen.

Warum die anderen falsch sind:
A: Einmalige Anfangskosten greifen zu kurz, da sich Nutzen und Kosten im Verlauf laufend verändern.
C: Auch kleine Projekte dürfen kein Geld verschwenden und benötigen eine Rechtfertigung.

D: Ein Business Case ist kein statisches Startdokument, sondern muss bis zum Projektende aktuell bleiben.

Learn from Experience [F] [Prinzipien] 1 Unterseite →

☝️ Single Wie sollte "Learn from Experience" laut PRINCE2 gelebt werden?

❌ Erst bei einer kritischen Abweichung vom Projektplan werden die Erfahrungen ausgewertet und dokumentiert.

✅ Aktiv während des gesamten Projekts, nicht nur am Ende dokumentiert

❌ Die Erkenntnisse werden ausschließlich im Projektabschlussbericht festgehalten und am Projektende zusammengefasst.

❌ Die Anwendung von Lessons Learned ist im PRINCE2-Prozessmodell als freiwillige Maßnahme vorgesehen.

Aktiv über den gesamten Projektverlauf — Lessons werden gesucht, festgehalten und angewendet, nicht nur am Ende dokumentiert.

Merksatz:
Erfahrung ist kein Grabstein am Ende, sondern ein ständiger Beifahrer: Wir lernen auf der gesamten Fahrt, nicht erst beim Totalschaden oder beim Einparken im Ziel.

Warum die anderen falsch sind:
Nur bei Scheitern: Lernen schützt vor Fehlern, bevor sie passieren, und optimiert auch erfolgreiche Phasen.
Nur im Abschlussbericht: Ein reines "Friedhofsregister" am Ende nützt dem laufenden Projekt nichts mehr.

Lessons Learned sind optional: Das Prinzip "Lernen aus Erfahrung" ist eine zwingende PRINCE2-Vorgabe, kein freiwilliges Extra.

Defined Roles and Responsibilities [F] [Prinzipien] 1 Unterseite →

☝️ Single Warum legt PRINCE2 großen Wert auf klar definierte Rollen?

❌ Damit das Projektmanagement-Team unnötige Aufgaben vermeiden kann

✅ Damit jederzeit klar ist, wer wofür verantwortlich ist

❌ Damit die Projektleitung möglichst viele Entscheidungen selbst treffen kann

❌ Damit die Kommunikation mit externen Lieferanten vereinfacht wird

Damit jederzeit klar ist, wer wofür verantwortlich ist — Unklarheiten sind eine Hauptursache für Projektprobleme.

Merksatz: Stell dir PRINCE2 wie ein Fußballteam vor: Ohne feste Positionen rennen alle kopflos dem Ball hinterher – klare Rollen sichern das Zusammenspiel und die Verantwortung für den Sieg.

Warum die anderen falsch sind:
A) PRINCE2-Prinzipien gelten für jedes Projekt, unabhängig von der Größe.
C) PRINCE2 fordert maßgeschneiderte Rollen, keine künstliche Bürokratie.

D) Rollen sind kein Nebenschauplatz, sondern ein tragendes Grundprinzip der Methode.

Manage by Stages [F] [Prinzipien] 1 Unterseite →

☝️ Single Was ist der Kerngedanke von "Steuern über Managementphasen"?

❌ Das Projekt wird in einem einzigen, durchgehenden Arbeitsabschnitt ohne Zwischenkontrollen geplant und umgesetzt

✅ Das Projekt wird in überschaubare Etappen mit erneuter Freigabe unterteilt

❌ Die Unterteilung in Etappen dient ausschließlich der technischen Detailplanung und nicht der Steuerung des Projekts

❌ Die einzelnen Etappen werden erst nach Abschluss des gesamten Projekts rückwirkend definiert und dokumentiert

Ein Projekt wird in überschaubare Etappen (Management Stages) unterteilt, mit erneuter Prüfung/Freigabe an jedem Übergang.

Merksatz:
Ein Marathon läuft sich leichter in Etappen: Bei „Manage by Stages“ teilst du die Strecke in überschaubare Abschnitte und holst dir an jedem Kontrollpunkt (Stage) das grüne Licht für den nächsten Sprint.

Warum die anderen falsch sind:
Stages erst nach Projektende festlegen: Das ist wie ein Navigationsgerät, das dir erst am Ziel sagt, wo du hättest abbiegen müssen – völlig nutzlos für die Steuerung.
Nur technische Umsetzung betreffen: Stages sind Management-Entscheidungspunkte für das gesamte Projekt (Business Case, Risiken etc.), keine reinen Technik-Meilensteine.

Genau eine einzige Stufe haben: Ein Projekt benötigt laut PRINCE2 mindestens zwei Phasen (Initiierungsphase und mindestens eine Managementphase), um steuerbar zu sein.

Manage by Exception [F] [Prinzipien] 1 Unterseite →

☝️ Single Was bedeutet "Steuern nach dem Ausnahmeprinzip" konkret?

❌ Toleranzen werden nur für den Projektmanager festgelegt, Abweichungen im Team sind davon ausgenommen

❌ Jede Abweichung vom Plan muss unverzüglich an die Projektleitung gemeldet und genehmigt werden

✅ Toleranzen werden festgelegt, nur bei Überschreitung wird eskaliert

❌ Ausnahmen betreffen ausschließlich die Zusammensetzung des Projektteams und werden nicht toleriert

Toleranzen (z.B. Zeit, Kosten) werden vorab festgelegt; nur bei drohender Überschreitung wird eskaliert.

Merksatz: Stell dir einen Weidezaun vor: Solange die Schafe innerhalb des Zauns (der Toleranzgrenze) grasen, schläft der Schäfer – erst wenn ein Schaf den Zaun durchbricht (Toleranzüberschreitung), greift er ein.

Warum die anderen falsch sind:
A: Ausnahmen sind nicht verboten, sondern das definierte Werkzeug zur Projektsteuerung.
B: Mikromanagement bei Kleinstabweichungen würde die Führungsebene völlig überlasten.

D: Das Prinzip bezieht sich auf Steuerungsgrößen wie Zeit und Budget, nicht auf Personalentscheidungen.

Manage by Exception Vorteil [F] [Prinzipien] 1 Unterseite →

☝️ Single Welchen praktischen Vorteil hat "Steuern nach dem Ausnahmeprinzip" für das Top-Management?

❌ Dadurch übernimmt das Top-Management sämtliche operativen Aufgaben und steuert das Projekt vollständig selbst

✅ Es wird nur bei relevanten Abweichungen eingebunden, nicht bei jeder Kleinigkeit

❌ Die festgelegten Toleranzen werden für das Projekt vollständig aufgehoben und durch Einzelfallentscheidungen ersetzt

❌ Das Top-Management muss über den Projektfortschritt grundsätzlich nicht mehr informiert werden und bleibt vollständig außen vor

Es muss nicht bei jeder Kleinigkeit eingebunden werden, sondern nur bei relevanten Abweichungen — spart Zeit und ermöglicht Delegation.

Merksatz:
Der Chef schläft tief und fest im „Ausnahme-Bett“ – er wird erst geweckt, wenn das Haus brennt, und muss im Normalbetrieb überhaupt nicht informiert werden.

Warum die anderen falsch sind:
„Nur bei relevanten Abweichungen eingebunden“: Falsch, da dies die Definition von Toleranzgrenzen ist, das Top-Management bei normalem Projektverlauf jedoch komplett ohne Berichte auskommt.
„Komplette Tagesarbeit übernehmen“: Falsch, da das Prinzip das Management gerade von der operativen Tagesarbeit entlasten soll.

„Toleranzen entfallen“: Falsch, da Toleranzen das Fundament von "Manage by Exception" sind und ohne sie das Prinzip gar nicht funktionieren kann.

Focus on Products [F] [Prinzipien] 1 Unterseite →

☝️ Single Was steht beim Principle "Focus on Products" im Mittelpunkt?

✅ Klare Definition der zu liefernden Produkte inkl. Qualitätsanforderungen

❌ Die Definition der Produkte erfolgt erst am Projektende und hat keinen Einfluss auf die Planung

❌ Im Mittelpunkt stehen die verwendeten Methoden und Techniken zur Steuerung des Projektteams

❌ Der Produktfokus beschränkt sich auf materielle Ergebnisse und schließt sämtliche Dokumentation aus

Die klare Definition, was genau geliefert werden soll (Qualität, Umfang) — statt sich nur auf Aktivitäten zu konzentrieren.

Merksatz:
Erst das Backrezept samt Geschmack (Produkt & Qualität) definieren, bevor man blind den Teig rührt – denn ohne klares Zielprodukt schmeckt das Ergebnis nicht.

Warum die anderen falsch sind:
B: PRINCE2 fokussiert primär auf Produkte (Ergebnisse), nicht auf reine Aktivitäten (Aktivismus-Falle).
C: Werkzeuge sind nur unterstützende Hilfsmittel, niemals der eigentliche Fokus des Projekts.

D: "Produkte" umfasst im Projektmanagement auch Dokumente, Pläne und Software, nicht nur Physisches.

Tailor to Suit the Project [F] [Prinzipien] 1 Unterseite →

☝️ Single Was bedeutet "Tailor to Suit the Project"?

❌ PRINCE2 wird bei der Anpassung so weit vereinfacht, dass die Prinzipien nicht mehr in vollem Umfang berücksichtigt werden müssen

❌ Die Anpassung von PRINCE2 ist ausschließlich für Projekte mit geringem Umfang und niedrigem Risiko vorgesehen

✅ PRINCE2 wird an das jeweilige Projekt angepasst, nicht starr übernommen

❌ Die Anwendung von PRINCE2 erfolgt in jedem Projekt nach demselben festen Schema, ohne Abweichungen zuzulassen

PRINCE2 wird an Größe, Komplexität, Umfeld des jeweiligen Projekts angepasst, statt starr angewendet zu werden.

Merksatz:
PRINCE2 ist kein starrer Schutzanzug von der Stange, sondern ein flexibler Maßanzug (Tailor), der perfekt auf die Größe und Umgebung deines Projekts zugeschnitten wird.

Warum die anderen falsch sind:
A: Prinzipien sind das unumstößliche Fundament und dürfen niemals weggelassen werden.
B: Anpassung ist für jedes Projekt Pflicht, egal ob winzig oder gigantisch.

D: Ein starrer Einheitsbrei ignoriert die Einzigartigkeit und erzeugt nur unnötige Bürokratie.

Principles und Weglassen [F] [Prinzipien] 1 Unterseite →

☝️ Single Können einzelne Principles je nach Projekt weggelassen werden?

❌ Nur "Steuern nach dem Ausnahmeprinzip" ist verpflichtend, der Rest optional

❌ Ja, bei kleinen Projekten dürfen bis zu 2 entfallen

✅ Nein, alle 7 Principles sind verpflichtend

❌ Ja, Principles sind komplett optional

Nein — im Gegensatz zu Practices/Prozessen (die angepasst werden können) sind alle 7 Principles verpflichtend.

Merksatz:
Stell dir die 7 Prinzipien wie die 7 tragenden Säulen eines Tempels vor – ziehst du auch nur eine einzige heraus, stürzt das gesamte Projektdach ein! Alle sieben müssen immer stehen.

Warum die anderen falsch sind:
A: "Manage by Exception" ist kein Solokünstler, sondern nur ein gleichwertiges Mitglied des unzertrennlichen 7er-Teams.
B: Auch kleine Tempel benötigen alle Säulen, die Projektgröße erlaubt kein Rosinenpicken bei den Grundregeln.

D: Ohne diese Fundamente ist es kein methodisches Projektmanagement mehr, sondern reines Chaos auf eigene Gefahr.

Principles korrekt benennen [F] [Prinzipien] 1 Unterseite →

✌️ Multi Welche der folgenden sind tatsächlich PRINCE2-Principles? (Mehrfachauswahl)

❌ Continuous Integration

✅ Steuern nach dem Ausnahmeprinzip

✅ Focus on Products

✅ Continued Business Justification

Merksatz:
Ein erfolgreicher PRINCE-Herrscher regiert hocheffizient: Er fordert stets eine wirtschaftliche Rechtfertigung (Business Justification), fokussiert sich voll auf das fertige Produkt (Products) und greift selbst nur im Ausnahmefall (Exception) steuernd ein.

Warum die anderen falsch sind:

A) Continuous Integration: Dies ist ein technischer Begriff aus der agilen Softwareentwicklung (DevOps) und kein Management-Prinzip von PRINCE2.

Tailoring selbst anwenden [F] [Prinzipien] 1 Unterseite →

☝️ Single Wie kann ein sehr kleines Projekt PRINCE2 sinnvoll tailoren, ohne ein Principle zu verletzen?

✅ Vereinfachte, kombinierte Management-Produkte nutzen, während alle Principles erhalten bleiben

❌ Management-Produkte können vereinfacht werden, aber einzelne Principles dürfen bei sehr kleinen Projekten ausgelassen werden, um den Aufwand zu reduzieren.

❌ Für ein sehr kleines Projekt sollten sämtliche Management-Produkte in maximaler Detaillierung erstellt werden, um die vollständige Kontrolle zu gewährleisten.

❌ Ein Tailoring der Methoden ist nur bei Großprojekten zulässig, während kleine Projekte strikt nach dem vollen PRINCE2-Rahmenwerk arbeiten müssen.

Durch Tailoring werden Management-Produkte vereinfacht oder kombiniert — die sieben Principles bleiben dabei vollständig erhalten.

Merksatz: Auch im Handgepäck (kleines Projekt) nutzt du All-in-One-Duschgel (kombinierte Produkte), aber du lässt niemals deinen Pass (die unantastbaren Principles) zu Hause.

Warum die anderen falsch sind:
B) – Principles sind das unverhandelbare Fundament und dürfen niemals ignoriert werden.
C) – Maximale Detaillierung erzeugt nur unnötigen bürokratischen Ballast.

D) – Tailoring ist für jede Projektgröße Pflicht, um PRINCE2 überhaupt sinnvoll anzuwenden.

Tailoring vs. Embedding [F] [Prinzipien] 1 Unterseite →

☝️ Single Was ist der Unterschied zwischen "Tailoring" (projektspezifische Anpassung) und "Embedding" (organisationsweite Verankerung) von PRINCE2?

❌ Tailoring beschreibt die dauerhafte Integration von PRINCE2 in die Aufbau- und Ablauforganisation eines Unternehmens, während Embedding die einmalige Anpassung der Methode an die spezifischen Anforderungen eines einzelnen Projekts darstellt.

❌ Embedding zielt darauf ab, die PRINCE2-Methodik innerhalb eines Projekts flexibel zu gestalten, wobei Tailoring die standardisierte Einführung der Methode über alle Projekte einer Organisation hinweg sicherstellt.

❌ Tailoring und Embedding bezeichnen denselben Vorgang der Anpassung von PRINCE2, wobei der Unterschied lediglich in der zeitlichen Reihenfolge liegt: Zuerst wird getailort, danach geembeddet.

✅ Tailoring = Anpassung an ein Projekt, Embedding = organisationsweite Verankerung

Tailoring passt PRINCE2 an EIN konkretes Projekt an, Embedding verankert PRINCE2 als Standard in der GESAMTEN Organisation.

Merksatz:
Der Tailor (Schneider) passt den Anzug maßgeschneidert für ein einzelnes Projekt an, während das Bett (Embedding) das tiefe, feste Fundament für das ganze Haus (die Organisation) bildet.

Warum die anderen falsch sind:
A: Übersieht, dass der „Schneider“ (Tailoring) nur das konkrete Projekt und nicht die Organisationsebene anpasst.
B: Verkennt, dass das „Bett“ (Embedding) die gesamte Organisation durchdringen und tragen muss.

C: Ignoriert den fundamentalen Unterschied zwischen der temporären Projekt- und der dauerhaften Organisationsebene.

Fortlaufende geschäftliche Rechtfertigung [Prinzipien] 2 Unterseite →

☝️ Single Was besagt das Prinzip 'Fortlaufende geschäftliche Rechtfertigung'?

❌ Ein Projekt muss seine geschäftliche Rechtfertigung ausschließlich am Projektende nachweisen, um den Projekterfolg zu bewerten.

❌ Die geschäftliche Rechtfertigung ist nur dann erforderlich, wenn ein detaillierter Projektplan vorliegt, andernfalls kann darauf verzichtet werden.

✅ Ein Projekt braucht über seine gesamte Laufzeit eine gültige geschäftliche Rechtfertigung

❌ Ein Projekt benötigt lediglich zu Beginn eine einmalige geschäftliche Rechtfertigung, die während der Laufzeit nicht aktualisiert werden muss.

Die Rechtfertigung muss durchgehend gültig sein – entfällt sie, sollte das Projekt beendet werden.

Merksatz:
Ein PRINCE2-Projekt ist wie ein Taxi mit laufendem Taxameter: Du fährst nur weiter, solange sich das Ziel für dich dauerhaft lohnt – verliert die Fahrt ihren Sinn, steigst du sofort aus.

Warum die anderen falsch sind:

Erst am Projektende: Zu spät – ohne laufende Prüfung verbrennt man bis zum Ende sinnlos Geld.

Optional bei existierendem Plan: Ein Plan ohne wirtschaftlichen Nutzen ist wertlos und rechtfertigt kein Projekt.

Nur zu Beginn: Märkte und Prioritäten ändern sich; ein anfangs gutes Projekt kann später unrentabel werden.

☝️ Single Was sollte geschehen, wenn die geschäftliche Rechtfertigung eines Projekts entfällt?

❌ Nur der Projektmanager wird ausgetauscht

✅ Das Projekt sollte (vorzeitig) beendet werden

❌ Das Projekt läuft unverändert weiter

❌ Der Business Case wird gelöscht, das Projekt bleibt

Ohne gültige Rechtfertigung ist das Projekt nicht mehr sinnvoll und sollte gestoppt werden.

Merksatz: Reite kein totes Pferd – ohne geschäftlichen Nutzen zieht man sofort den Stecker und beendet das Projekt vorzeitig.

Warum die anderen falsch sind:
A) Ein neuer Projektleiter kann ein grundlegend sinnloses Projekt auch nicht profitabel machen.
C) Unverändert weiterzuarbeiten verschwendet nur wertvolle Ressourcen ohne jeden Gegenwert.

D) Den Business Case einfach zu ignorieren ist wie Fliegen im Blindflug ohne Ziel.

Lernen aus Erfahrung [Prinzipien] 2 Unterseite →

☝️ Single Was verlangt das Prinzip 'Lernen aus Erfahrung'?

❌ Erkenntnisse ausschließlich am Projektende sammeln und dokumentieren, ohne sie während der Laufzeit anzuwenden

❌ Bewusst auf die Dokumentation von Fehlern verzichten, um das Team nicht zu belasten und den Projektverlauf nicht zu gefährden

❌ Die Verantwortung für das Sammeln und Bewerten von Erfahrungen vollständig an externe Berater delegieren

✅ Erkenntnisse aktiv suchen, festhalten und im Projekt anwenden

Lessons werden zu Beginn gesucht, während des Projekts festgehalten und am Ende weitergegeben.

Merksatz:
Das Prinzip ist wie ein Erfahrungs-Tagebuch: Du suchst aktiv nach wertvollen Schätzen (Erkenntnissen), schreibst sie sofort auf und nutzt sie direkt für das laufende Projekt.

Warum die anderen falsch sind:
A: Nur am Ende zu reflektieren ist viel zu spät, da Chancen im laufenden Projekt verpuffen.
B: Fehler zu verschweigen blockiert die Weiterentwicklung und führt zu teuren Wiederholungsfehlern.

C: Externe Berater entscheiden zu lassen ignoriert das eigene Team und dessen Lernkurve.

☝️ Single Wo werden Erkenntnisse während des laufenden Projekts festgehalten?

❌ Im Teamstatusbericht

✅ Im Erfahrungsprotokoll

❌ Im Arbeitspaket

❌ Im Risikoregister

Das Lessons Log sammelt laufend Erkenntnisse; der Lessons Report gibt sie weiter.

Merksatz:
Das Lessons Log ist dein „Erfahrungs-Tagebuch“: Jede Erkenntnis wird laufend wie in ein Logbuch eingetragen, damit sie sofort gesichert ist.

Warum die anderen falsch sind:
A) Checkpoint Report: Ein reiner Statusbericht des Teams an den Projektleiter, kein Sammelbecken für Lerneffekte.
C) Arbeitspaket: Beschreibt nur konkrete Aufgaben und Lieferobjekte, keine übergreifenden Erkenntnisse.

D) Risikoregister: Steuert zukünftige Unsicherheiten, statt bereits gemachte Erfahrungen zu dokumentieren.

Definierte Rollen und Verantwortlichkeiten [Prinzipien] 2 Unterseite →

☝️ Single Welche drei Interessen müssen laut Prinzip 'Definierte Rollen und Verantwortlichkeiten' vertreten sein?

❌ Management, Personalvertretung und Auftraggeber

✅ Business, Nutzer (User) und Lieferant (Supplier)

❌ Fachbereiche, Entwicklung und Betrieb

❌ Aufwand, Termine und Ergebnisse

PRINCE2 verlangt, dass Business-, User- und Supplier-Interessen im Projekt vertreten sind.

Merksatz:
Fahre im BUS zum Projekterfolg: Business (zahlt), User (nutzt) und Supplier (liefert) lenken das Projekt gemeinsam.

Warum die anderen falsch sind:
A: Vorstand und Betriebsrat sind interne Organisationsorgane, keine universellen Projektrollen.
C: Marketing, Vertrieb und IT beschreiben bloße Abteilungen statt der drei fundamentalen Projektinteressen.

D: Kosten, Zeit und Qualität bilden das magische Dreieck der Projektziele, keine personellen Rollen.

☝️ Single Warum sind klar definierte Rollen ein PRINCE2-Prinzip?

✅ Damit alle wissen, wer wofür zuständig ist und wer entscheidet

❌ Damit der Projektablauf ohne Rückfragen und Abstimmungen zügig voranschreiten kann

❌ Damit auf eine ausführliche Projektdokumentation vollständig verzichtet werden kann

❌ Damit der Projektmanager alle Entscheidungen eigenständig und ohne Einbindung anderer treffen kann

Klare Rollen sind Voraussetzung dafür, dass ein Projekt steuerbar ist.

Merksatz:
Ein Schiff braucht eine klare Crew: Nur wenn jeder weiß, wer das Steuer hält (Entscheidung) und wer die Segel hisst (Zuständigkeit), erreicht das Projekt sicher den Hafen.

Warum die anderen falsch sind:
Möglichst wenig Kommunikation: Rollen fördern den gezielten Austausch, statt Kommunikation zu verhindern.
Keine Dokumentation nötig: Klare Rollen ersetzen keine Dokumentation, sondern müssen selbst schriftlich fixiert werden.
Project Manager entscheidet allein: Der Projektmanager entscheidet eben nicht* alles allein, sondern teilt sich die Lenkung mit dem Lenkungsausschuss.

Steuern über Managementphasen [Prinzipien] 2 Unterseite →

☝️ Single Was besagt das Prinzip 'Steuern über Managementphasen'?

❌ Das Projekt wird ausschließlich in der letzten Phase detailliert geplant und überwacht

✅ Das Projekt wird phasenweise geplant, überwacht und gesteuert

❌ Die Freigabe der einzelnen Phasen erfolgt durch den Teammanager

❌ Das Projekt wird als ein kontinuierlicher Ablauf ohne Unterteilung in Phasen gesteuert

Am Ende jeder Managementphase entscheidet das Board über die Fortführung.

Merksatz:
Ein Bergsteiger plant, überwacht und sichert jede Etappe einzeln, statt den Gipfel blind in einem Rutsch zu stürmen.

Warum die anderen falsch sind:
A) ...weil eine Planung erst am Ende des Projekts völlig nutzlos für die Steuerung ist.
C) ...weil die Phasenfreigabe durch den Lenkungsausschuss erfolgt, nicht durch den Team Manager.

D) ...weil ein Projekt ohne strukturierte Abschnitte unsteuerbar im Chaos versinkt.

☝️ Single Wer entscheidet am Ende einer Managementphase über die Fortführung?

❌ Der Teammanager

✅ Das Lenkungsausschuss

❌ Die Änderungsinstanz

❌ Project Support

Die phasenweise Steuerung gibt dem Board regelmäßige Entscheidungspunkte.

Merksatz: Das Project Board steht am Bord des Schiffes und entscheidet als Kapitän-Riege exklusiv, ob die Reise in die nächste Phase geht.

Warum die anderen falsch sind:
A) Team Manager: Liefert nur Arbeitspakete ab und hat keine strategische Freigabekompetenz.
C) Change Authority: Ist nur für die Genehmigung von inhaltlichen Änderungen (Changes) zuständig.

D) Project Support: Übernimmt rein administrative Aufgaben und besitzt keinerlei Entscheidungsmacht.

Steuern nach dem Ausnahmeprinzip [Prinzipien] 2 Unterseite →

☝️ Single Was besagt das Prinzip 'Steuern nach dem Ausnahmeprinzip' (Steuern nach dem Ausnahmeprinzip)?

❌ Es werden keine Toleranzen definiert, sodass jede Abweichung direkt an das Projektboard gemeldet werden muss.

❌ Das Projektboard übernimmt die tägliche Steuerung aller Arbeitspakete und greift aktiv in das Tagesgeschäft ein.

✅ Es werden Toleranzen gesetzt; erst deren drohende Überschreitung wird eskaliert

❌ Jede noch so kleine Abweichung vom Plan wird unverzüglich an das Projektboard eskaliert, um sofortige Korrekturen zu veranlassen.

Innerhalb der Toleranzen arbeitet die jeweilige Ebene eigenständig.

Merksatz:
Das Lenkungsausschuss-Board schläft friedlich im „Toleranz-Bett“ – erst wenn das Projekt droht, über die Bettkante (Toleranzgrenze) zu fallen, wacht es durch den Wecker (Ausnahmebericht) auf.

Warum die anderen falsch sind:
Keine Toleranzen: Ohne Toleranzen müsste jede winzige Abweichung gemeldet werden, was das Prinzip der Effizienz völlig zerstört.
Board steuert Tagesgeschäft: Das Board lenkt strategisch; das operative Tagesgeschäft liegt allein beim Projektmanager.

Jede Abweichung sofort eskalieren: Das würde das Board mit Mikromanagement überlasten; erst das Überschreiten der vereinbarten Toleranzgrenze erfordert eine Eskalation.

☝️ Single Welchen Vorteil bietet 'Steuern nach dem Ausnahmeprinzip'?

❌ Das Management erhält dadurch keine Informationen und kann keine Entscheidungen treffen

❌ Der Projektmanager muss alle Abweichungen sofort selbstständig und ohne Rücksprache lösen

✅ Das Management wird nur bei Bedarf einbezogen und arbeitet effizient

❌ Das Projektteam muss jede einzelne Aktivität dem Vorstand zur Freigabe vorlegen

Manage by Exception spart Managementaufwand, ohne die Kontrolle zu verlieren.

Merksatz: Stell dir das Management wie die Feuerwehr vor: Sie rückt nur aus, wenn der Alarm schrillt (Toleranz überschritten) – das spart Zeit und schont Ressourcen.

Warum die anderen falsch sind:
A: ...weil Toleranzen die zwingende Grundlage sind, um eine Ausnahme überhaupt zu definieren.
B: ...da der Projektleiter innerhalb der Toleranzgrenzen weiterhin eigenständig entscheidet.

D: ...weil tägliche Detailprüfungen das Gegenteil von Entlastung und Effizienz bedeuten.

Fokus auf Produkte [Prinzipien] 2 Unterseite →

☝️ Single Was besagt das Prinzip 'Fokus auf Produkte'?

❌ Produkte werden erst nach Abschluss aller Aktivitäten vollständig definiert

✅ Produkte werden mit Qualitätskriterien definiert, bevor Aktivitäten geplant werden

❌ Qualitätskriterien werden erst nach der Lieferung des Produkts festgelegt

❌ Die Planung von Aktivitäten hat Vorrang vor der Definition von Produkten

PRINCE2 richtet Planung und Steuerung an klar definierten Produkten aus.

Merksatz:
Erst das Backrezept samt Zutaten (Qualität) festlegen, dann den Rührbesen schwingen (Aktivitäten) – erst das Produkt definieren, dann die Arbeit planen!

Warum die anderen falsch sind:
A: Verwechselt blinden Aktionismus mit zielgerichtetem Arbeiten.
C: Ignoriert, dass ohne Qualitätsmaßstab kein messbarer Erfolg existiert.

D: Führt zu spätem Erwachen und teuren Fehlern am Projektende.

☝️ Single Worauf richtet das Prinzip 'Fokus auf Produkte' die Planung primär aus?

❌ Auf die zeitliche Abfolge der Projektrollen und ihre jeweiligen Einsatzzeitpunkte

❌ Auf die Auswahl und Konfiguration der unterstützenden Projektmanagement-Werkzeuge

❌ Auf die Festlegung der Häufigkeit und Dauer aller geplanten Projektbesprechungen

✅ Auf die zu liefernden Produkte und ihre Qualitätskriterien

Erst wird definiert, was geliefert wird, dann wie.

Merksatz:
Erst das fertige Backergebnis (Produkt) und sein Geschmack (Qualität) bestimmen das Rezept, nicht der Ofen oder die Bäcker-Reihenfolge.

Warum die anderen falsch sind:
A) Rollen regeln nur Zuständigkeiten, sind aber nicht das eigentliche Projektziel.
B) Werkzeuge sind bloße Hilfsmittel, die ohne Produktfokus wirkungslos bleiben.

C) Meetings verwalten nur die Zeit und schaffen selbst keinen messbaren Kundennutzen.

Anpassung an das Projektumfeld [Prinzipien] 2 Unterseite →

☝️ Single Was besagt das Prinzip 'Anpassung an das Projektumfeld' (Tailoring)?

❌ PRINCE2 wird ausschließlich für Projekte mit einem Budget über einer Million Euro eingesetzt

❌ PRINCE2 schreibt für jedes Projekt exakt denselben Satz an Prozessen und Managementprodukten vor

✅ PRINCE2 wird an Größe, Umfeld, Komplexität und Risiko des Projekts angepasst

❌ Bei Projekten mit geringem Risiko dürfen einzelne PRINCE2-Prinzipien komplett ignoriert werden

Tailoring passt die Methode an den Kontext an, ohne ihre Substanz aufzugeben.

Merksatz:
PRINCE2 ist kein starrer Panzer, sondern ein flexibler Maßanzug, der perfekt auf die Größe, das Umfeld, die Komplexität und das Risiko (G-U-K-R) des Projekts zugeschnitten wird.

"Nur große Projekte..." ist falsch: PRINCE2 ist skalierbar und funktioniert auch bei kleinsten Projekten.
"Immer identisch angewendet" ist falsch: Ein starres "Copy-Paste" führt zu bürokratischem Overhead und ignoriert die Realität.

"Prinzipien dürfen weggelassen werden" ist falsch: Die 7 Prinzipien sind nicht verhandelbar; wer sie weglässt, managt kein PRINCE2-Projekt mehr.

☝️ Single Was darf beim Tailoring von PRINCE2 NICHT wegfallen?

✅ Die sieben Prinzipien

❌ Die Management-Ansätze

❌ Einzelne Berichte

❌ Die Team-Pläne

Getailort werden dürfen Prozesse, Rollen und Produkte – die Prinzipien gelten immer.

Merksatz:
Die sieben Prinzipien sind das unantastbare Fundament (die „DNA“) von PRINCE2 – nimmst du sie weg, ist es kein PRINCE2 mehr.

Warum die anderen falsch sind:
B) Die Management-Ansätze: Diese können flexibel angepasst, zusammengefasst oder für kleine Projekte stark vereinfacht werden.
C) Einzelne Berichte: Dokumente und Berichte dürfen beim Tailoring zusammengelegt oder durch mündliche Absprachen ersetzt werden.

D) Die Team-Pläne: Diese optionalen Pläne der Lieferebene sind bei kleinen Projekten oft überflüssig und dürfen entfallen.

Die 7 Prinzipien [Prinzipien] 9 Unterseite →

☝️ Single Warum gilt PRINCE2 als „Goldstandard“ im Projektmanagement?

❌ Es bietet eine vollständige und verbindliche Vorgehensweise, die sämtliche Projektarten ohne weitere Anpassungen abdeckt

✅ Es bietet ein strukturiertes, skalierbares und anpassungsfähiges Framework

❌ Es stellt ein offizielles Regelwerk dar, das ausschließlich für öffentliche Verwaltungen in Großbritannien entwickelt wurde

PRINCE2 wird geschätzt, weil es eine klare Struktur bietet und gleichzeitig flexibel genug ist, um sich an unterschiedliche Projektgrößen, Branchen und Vorgehensweisen anzupassen.

Merksatz: PRINCE2 ist wie ein Lego-Baukasten: Er liefert feste Steine (Struktur), passt für kleine Hütten wie große Burgen (Skalierbarkeit) und lässt sich völlig flexibel umbauen (Anpassung).

Warum die anderen falsch sind:
A ist falsch, weil PRINCE2 andere Methoden (wie agile Praktiken) sinnvoll ergänzt, statt sie arrogant zu ersetzen.
C ist falsch, weil der globale „Goldstandard“ längst weltweit in allen Branchen genutzt wird und nicht auf britische Behörden beschränkt ist.

☝️ Single Was ist der Hauptzweck der „Business Justification“ (geschäftlichen Rechtfertigung) in einem Projekt?

✅ Zu bestätigen, dass das Projekt tragfähig, wünschenswert und erreichbar ist

❌ Um sicherzustellen, dass das Projektteam täglich klare Arbeitsanweisungen und priorisierte Aufgaben erhält, um die Projektziele termingerecht zu erreichen

❌ Zu gewährleisten, dass dem Projekt ausreichend qualifizierte und verfügbare Teammitglieder zugewiesen werden, um alle geplanten Aktivitäten durchführen zu können

Die geschäftliche Rechtfertigung stellt sicher, dass das Projekt während seines gesamten Lebenszyklus finanziell und strategisch sinnvoll bleibt.

Merksatz:
Die Business Justification ist das dreibeinige Fundament des Projekts: Es steht nur stabil, wenn es tragfähig (lohnt es sich?), wünschenswert (wollen wir es?) und erreichbar (schaffen wir es?) ist.

Warum die anderen falsch sind:
B): Tägliche Aufgaben regelt die operative Steuerung (z. B. Arbeitspakete), nicht die übergeordnete geschäftliche Sinnhaftigkeit.
C): Die Teamgröße betrifft das Ressourcenmanagement und sichert noch keinen wirtschaftlichen Nutzen für das Unternehmen.

☝️ Single Was betont das Prinzip „Lernen aus Erfahrung“ in PRINCE2?

❌ Die ausschließliche Dokumentation von Erfahrungen erst nach Abschluss des Projekts

❌ Die bewusste Nichtberücksichtigung früherer Projekte zur Förderung neuer Ideen

✅ Die kontinuierliche Anwendung von Lehren aus vergangenen und laufenden Projekten

Kontinuierliches Lernen verbessert die Entscheidungsfindung und die Projektergebnisse.

Merksatz: Ein kluger Kapitän nutzt seine Seekarte kontinuierlich während der gesamten Fahrt – er schaut nicht erst im Zielhafen hinein und ignoriert bekannte Gefahrenstellen nicht.

Warum die anderen falsch sind:
A) ... weil „nur am Ende“ viel zu spät ist, um Fehler im aktuellen Projekt noch aktiv zu verhindern.
B) ... weil das Ignorieren alter Fehler nicht innovativ ist, sondern das Rad nur schmerzhaft neu erfindet.

☝️ Single Was ist die zentrale Idee hinter „Managen nach Phasen“ (Managing by Stages)?

✅ Das Projekt in überschaubare Phasen zu unterteilen

❌ Das gesamte Projekt in einem Zug abzuschließen

❌ Die gesamte Verantwortung einer einzigen Person zu übertragen

Projekte werden in Phasen unterteilt, um bessere Steuerung, Überwachung und Entscheidungsfindung zu ermöglichen.

Merksatz: Wer einen Berg besteigt, plant Etappen (Phasen) mit Rastplätzen, statt ohne Pause zum Gipfel zu rennen – das sichert den Überblick und die Kontrolle.

Warum die anderen falsch sind:
B) – Alles in einem Rutsch zu planen ignoriert die Unvorhersehbarkeit von Projekten.
C) – Projektverantwortung zu bündeln löst keine zeitlichen Strukturierungsprobleme.

☝️ Single Was ermöglicht „Führen nach dem Ausnahmeprinzip“ (Management by Exception)?

❌ Mikromanagement jeder einzelnen Aufgabe

❌ Die Notwendigkeit von Berichten zu beseitigen

✅ Teams innerhalb festgelegter Toleranzen zu befähigen

Die Notwendigkeit von Berichten zu beseitigen

Merksatz:
Der Chef zieht die Leitplanken (Toleranzen) – das Team lenkt selbstständig, solange es nicht anstößt.

Warum die anderen falsch sind:
A) Führt zum exakten Gegenteil von Autonomie und blockiert die Führungskraft durch Kontrollwahn.
B) Berichte sind weiterhin zwingend nötig, um das Einhalten der Toleranzgrenzen überhaupt zu belegen.

☝️ Single Was versteht man in PRINCE2 unter „Tailoring“ (Anpassung)?

❌ PRINCE2 bei jedem Projekt exakt gleich anzuwenden

❌ PRINCE2-Richtlinien unter Druck zu ignorieren

✅ PRINCE2 an das jeweilige Projektumfeld anzupassen

PRINCE2 sollte je nach Projektgröße, Komplexität und Kontext skaliert und angepasst werden.

Merksatz:
Ein guter Schneider (Tailor) zwängt keinen Riesen in einen Baby-Strampler – er passt die PRINCE2-Methode wie einen Maßanzug individuell an das Projektumfeld an.

Warum die anderen falsch sind:
A ist falsch, weil starre Schablonen ohne Flexibilität dem Grundgedanken von PRINCE2 widersprechen.
B ist falsch, weil Stress kein Freibrief für Chaos ist, sondern strukturierte Anpassung erfordert.

☝️ Single Was bedeutet „Führen nach dem Ausnahmeprinzip“ (management by exception) in PRINCE2?

✅ Der Projektmanager eskaliert nur, wenn Toleranzen überschritten werden

❌ Das Lenkungsausschuss übernimmt die operative Steuerung aller täglichen Arbeitspakete und entscheidet direkt über jede Detailfrage im Projektverlauf.

❌ Sämtliche Issues und Abweichungen werden unverzüglich an das Lenkungsausschuss gemeldet, unabhängig von ihrer Auswirkung auf die Projektziele.

Richtig – dies ermöglicht effiziente Delegation und Steuerung.

Merksatz: Der Projektmanager läuft wie ein autonomer Saugroboter: Solange er innerhalb der Zimmerwände (Toleranzen) bleibt, arbeitet er geräuschlos – erst beim harten Anstoßen (Toleranzüberschreitung) piept er um Hilfe (Eskalation).

Warum die anderen falsch sind:
B) Der Lenkungsausschuss steuert nur strategisch, das tägliche Management ist Aufgabe des Projektmanagers.
C) Dies würde zu Mikromanagement führen, da kleine Abweichungen innerhalb der Toleranzgrenzen eigenständig gelöst werden.

☝️ Single Was bedeutet Tailoring von PRINCE2 in der Praxis?

✅ PRINCE2-Prinzipien und -Praktiken passend zum jeweiligen Projektkontext anzuwenden

❌ PRINCE2-Regeln und -Vorgaben in jedem Projekt unverändert und vollständig umzusetzen, ohne Anpassungen an den Projektkontext vorzunehmen

❌ PRINCE2-Prozesse und -Dokumente bewusst auszulassen, um den Verwaltungsaufwand zu reduzieren und schneller zu Ergebnissen zu gelangen

Tailoring stellt sicher, dass PRINCE2 zweckmäßig ist und an Projektgröße, Komplexität und Umfeld angepasst wird.

Merksatz:
PRINCE2 ist kein starrer Panzer, sondern ein flexibler Maßanzug: Beim „Tailoring“ (Anpassen) schneiderst du die Methoden passgenau auf die Größe und den Kontext deines Projekts zu.

Warum die anderen falsch sind:
B: Ein stures, unverändertes Befolgen ignoriert die Projektrealität und führt zu bürokratischem Overhead.
C: Wildes Ignorieren von Prozessen ist kein professionelles Anpassen, sondern pures Chaos unter dem Deckmantel der Zeitersparnis.

☝️ Single Was ist der HAUPTZWECK von Management by Exception (Führen nach dem Ausnahmeprinzip) in PRINCE2?

❌ Sicherzustellen, dass das Lenkungsausschuss jede Entscheidung des Projektmanagers vorab genehmigt, um Risiken zu minimieren

❌ Die Erstellung sämtlicher Statusberichte überflüssig zu machen, da das Lenkungsausschuss den Fortschritt direkt überwacht

✅ Dem Projektmanager zu ermöglichen, innerhalb vereinbarter Toleranzen zu arbeiten, ohne ständig zu eskalieren

Management by Exception befähigt den Project Manager, innerhalb festgelegter Toleranzen eigenständig zu handeln, was die Effizienz erhöht.

Merksatz:
Der Projektmanager fährt frei in seiner Spur (Toleranz) – erst beim Verlassen der Fahrbahn (Ausnahme) schlägt das Navi (Lenkungsausschuss) Alarm.

Warum die anderen falsch sind:
A: Das Project Board soll entlastet und eben nicht durch Mikromanagement in jede Entscheidung einbezogen werden.
B: Berichte werden nicht abgeschafft, sondern durch definierte Toleranzen erst effizient und zielgerichtet steuerbar.

Prinzipien-Anwendung [F] [Prinzipien] [Neu] 5 Unterseite →

☝️ Single Ein Energieversorger stoppt ein Digitalisierungsprojekt vorzeitig, nachdem eine Gesetzesänderung den erwarteten Nutzen vollständig entwertet hat. Welches Grundprinzip liegt dieser Entscheidung zugrunde?

❌ Steuern nach dem Ausnahmeprinzip

✅ Fortlaufende geschäftliche Rechtfertigung sicherstellen

❌ Anpassen an das Projekt

❌ Steuern über Managementphasen

Ist die geschäftliche Rechtfertigung nicht mehr gegeben, verlangt das Prinzip „Fortlaufende geschäftliche Rechtfertigung sicherstellen“, das Projekt anzupassen oder zu beenden – unabhängig vom Projektfortschritt.

Merksatz:
„Kein Nutzen, kein Projekt!“ – So wie ein Auto ohne Treibstoff sofort stehen bleibt, muss ein PRINCE2-Projekt sofort gestoppt werden, sobald die geschäftliche Rechtfertigung (der Nutzen) durch äußere Umstände verpufft.

Warum die anderen falsch sind:
Steuern nach dem Ausnahmeprinzip: Befasst sich nur mit Toleranzüberschreitungen bei Zeit oder Budget, nicht mit der Existenzberechtigung des Projekts.
Anpassen an das Projekt: Regelt die Skalierung der Methode auf das Projektumfeld, nicht den Projektabbruch wegen Sinnlosigkeit.

Steuern über Managementphasen: Strukturiert das Projekt in zeitliche Abschnitte, erzwingt aber keinen inhaltlichen Abbruch bei Gesetzesänderungen.

☝️ Single Der Projektmanager vereinbart mit einem Teammanager, dass dieser ein Arbeitspaket eigenverantwortlich liefern darf, solange Zeit- und Kostengrenzen eingehalten werden. Welches Prinzip wird angewendet?

❌ Lernen aus Erfahrung

❌ Definierte Rollen, Verantwortlichkeiten und Beziehungen

✅ Steuern nach dem Ausnahmeprinzip

❌ Produktorientierung

Das Festlegen von Toleranzen, innerhalb derer eine Ebene ohne Eskalation arbeiten darf, ist die Kernidee von „Steuern nach dem Ausnahmeprinzip“.

Merksatz:
Der Teammanager steuert sein Paket frei auf der Schiene, solange er die Toleranzgrenzen (Zeit/Kosten) nicht reißt – erst bei einer drohenden Grenzüberschreitung zieht er die Notbremse (Ausnahme).

Warum die anderen falsch sind:
Lernen aus Erfahrung: Beschäftigt sich mit der Nutzung von historischem Wissen, nicht mit der operativen Einhaltung von Toleranzgrenzen.
Definierte Rollen, Verantwortlichkeiten und Beziehungen: Regelt zwar die Struktur der Beteiligten, aber nicht das spezifische Steuerungswerkzeug der Toleranzgrenzen.

Produktorientierung: Fokussiert sich rein auf die Definition und Qualität der zu liefernden Produkte, nicht auf das Delegationsprinzip für deren Erstellung.

☝️ Single Welches der folgenden Elemente ist KEIN Grundprinzip von PRINCE2 7?

❌ Lernen aus Erfahrung

✅ Kontinuierliche Verbesserung der Prozesse

❌ Produktorientierung

❌ Steuern über Managementphasen

PRINCE2 7 kennt sieben Prinzipien; „Kontinuierliche Verbesserung der Prozesse“ gehört nicht dazu. Die anderen drei sind echte Prinzipien.

Merksatz:
PRINCE2-Prinzipien sind wie ein stabiles Haus: Es braucht feste Phasen, klare Produkte und das Fundament aus Erfahrung – aber die „kontinuierliche Verbesserung der Prozesse“ gehört zu ITIL, nicht zu den PRINCE2-Prinzipien.

Lernen aus Erfahrung: Ist falsch, weil dieses Prinzip zwingend vorschreibt, aus Fehlern der Vergangenheit zu lernen.
Produktorientierung: Ist falsch, weil PRINCE2 immer ergebnis- und produktfokussiert arbeitet, um den Nutzen zu sichern.

Steuern über Managementphasen: Ist falsch, weil die Aufteilung des Projekts in kontrollierbare Abschnitte ein Kernprinzip ist.

☝️ Single Beim Aufbau des Projektteams passt der Projektmanager Arbeitsweisen und Kommunikation an die beteiligten Personen an, statt die Menschen in ein starres Vorgehen zu zwingen. Welches Prinzip wendet das Element „Menschen“ hier an?

✅ Anpassen an das Projekt

❌ Definierte Rollen, Verantwortlichkeiten und Beziehungen

❌ Fortlaufende geschäftliche Rechtfertigung sicherstellen

❌ Lernen aus Erfahrung

„Anpassen an das Projekt“ bedeutet, die Methode an Projekt und Menschen anzupassen – nicht umgekehrt. Das Element „Menschen“ betont dies ausdrücklich.

Merksatz:
Der Maßanzug für Menschen: Wer Arbeitsweisen flexibel zuschneidet, statt das Team in eine Schablone zu pressen, der passt die Methode an das Projekt (und seine Menschen) an.

Warum die anderen falsch sind:
Rollen, Verantwortlichkeiten und Beziehungen: Fokussiert sich auf die formale Struktur und Zuständigkeiten, nicht auf die flexible Gestaltung der Zusammenarbeit.
Geschäftliche Rechtfertigung: Betrifft den wirtschaftlichen Nutzen (Business Case) und nicht die zwischenmenschliche Arbeitsweise.

Lernen aus Erfahrung: Zielt auf das Erfassen und Nutzen von Lehren (Lessons Learned) aus der Vergangenheit ab, nicht auf die aktuelle Anpassung an Teammitglieder.

☝️ Single Warum sollte ein PRINCE2-Projekt aus mindestens zwei Managementphasen bestehen?

❌ Damit für jede Phase ein eigener Teammanager benannt werden kann

✅ Damit der Lenkungsausschuss am Phasenende einen Steuerungspunkt zur Freigabe hat

❌ Damit jede Phase einen eigenen Business Case erhält

❌ Damit Risiken auf mehrere Teams verteilt werden können

„Steuern über Managementphasen“ schafft am Ende jeder Phase einen Entscheidungspunkt, an dem der Lenkungsausschuss die Fortführung freigibt; mindestens eine Initiierungs- und eine Lieferphase sind nötig.

Prinzipien-Anwendung [F] [Prinzipien] 7 Unterseite →

☝️ Single Zu Beginn eines Projekts sammelt das Team gezielt Erkenntnisse aus einem vergleichbaren, früher gescheiterten Vorhaben. Welches Grundprinzip wird hier gelebt?

❌ Anpassen an das Projekt

❌ Produktorientierung

✅ Lernen aus Erfahrung

❌ Steuern über Managementphasen

„Lernen aus Erfahrung“ verlangt, schon zu Projektbeginn aktiv nach relevanten Erfahrungen zu suchen und sie zu nutzen.

☝️ Single Ein Team definiert für jedes Ergebnis zuerst die geforderten Merkmale und Abnahmekriterien, bevor die Arbeit geplant wird. Welches Prinzip steht im Vordergrund?

❌ Steuern nach dem Ausnahmeprinzip

✅ Produktorientierung

❌ Fortlaufende geschäftliche Rechtfertigung sicherstellen

❌ Lernen aus Erfahrung

„Produktorientierung“ stellt die zu liefernden Produkte und ihre Qualitätsanforderungen in den Mittelpunkt der Planung.

Merksatz:
Erst das Produkt (Merkmale & Abnahmekriterien) definieren, dann den Weg planen – wer das Ziel nicht kennt, baut am Kunden vorbei.

Warum die anderen falsch sind:
Manage by Exception: Hier geht es um Toleranzen und Delegation von Befugnissen, nicht um die Definition von Liefergegenständen.
Fortlaufende geschäftliche Rechtfertigung: Dies prüft den wirtschaftlichen Nutzen (Business Case) über die gesamte Projektlaufzeit, nicht die konkreten Produkteigenschaften.

Lernen aus Erfahrung: Dieses Prinzip befasst sich mit dem Erfassen und Anwenden von Lektionen aus der Vergangenheit, nicht mit der aktuellen Produktdefinition.

☝️ Single Welche Aussage zum Prinzip „Steuern über Managementphasen“ ist korrekt?

❌ Projekte mit hohem Risiko sollten wenige, lange Phasen haben

❌ Der Lenkungsausschuss gibt möglichst alle Phasen gemeinsam frei

✅ Das Ende jeder Phase ist ein Kontrollpunkt für den Lenkungsausschuss

❌ Jede Phase muss inkrementell einen Teil des Nutzens liefern

Jedes Phasenende bildet einen Steuerungspunkt, an dem der Lenkungsausschuss über die Fortführung entscheidet.

Merksatz:
Phasenenden sind wie Mautstationen auf der Projekt-Autobahn: Der Lenkungsausschuss steht an der Schranke, kontrolliert die Tickets (Ergebnisse) und gibt die Fahrt für den nächsten Abschnitt frei.

Warum die anderen falsch sind:
Wenige, lange Phasen bei hohem Risiko: Falsch, denn hohes Risiko erfordert mehr und kürzere Phasen für eine engmaschige Kontrolle.
Gemeinsame Freigabe aller Phasen: Falsch, da der Lenkungsausschuss das Projekt phasenweise autorisiert, um das finanzielle Risiko zu minimieren.

Inkrementelle Nutzenlieferung pro Phase: Falsch, da Nutzen oft erst nach Projektende entsteht und Phasen primär der Steuerung, nicht zwingend der direkten Nutzenbereitstellung dienen.

☝️ Single Ein Projektmanagement-Team bindet einen externen Lieferanten vertraglich ein und klärt dessen Rolle im Lenkungsausschuss. Welches Prinzip wird angewendet?

❌ Lernen aus Erfahrung

❌ Steuern nach dem Ausnahmeprinzip

✅ Definierte Rollen, Verantwortlichkeiten und Beziehungen

❌ Produktorientierung

Die klare Festlegung von Rollen, Verantwortlichkeiten und Beziehungen – auch für externe Beteiligte – ist Kern dieses Prinzips.

☝️ Single Welche Aussage über die Grundprinzipien von PRINCE2 7 trifft zu?

✅ Sie gelten für jedes PRINCE2-Projekt und sind nicht optional

❌ Sie ersetzen die Practices

❌ Sie werden nur in großen Projekten angewendet

❌ Sie können je nach Projekt weggelassen werden

Die sieben Prinzipien sind universell und verbindlich; erfüllt ein Vorhaben sie nicht, ist es kein PRINCE2-Projekt.

Merksatz: Die PRINCE2-Prinzipien sind wie die Fundamente eines Hauses: Immer vorhanden, unumstößlich und für jedes Bauwerk (Projekt) zwingend notwendig, egal wie groß oder klein. Ohne Fundament stürzt das Haus ein.

Warum die anderen falsch sind:
Sie ersetzen die Practices: Prinzipien sind die "Was", Practices das "Wie"; sie ergänzen sich, ersetzen sich nicht.
Sie werden nur in großen Projekten angewendet: Prinzipien sind universell, ihre Anwendung wird skaliert, nicht weggelassen.

Sie können je nach Projekt weggelassen werden: Die Prinzipien sind der Kern von PRINCE2; ohne sie ist es kein PRINCE2-Projekt.

☝️ Single Der Lenkungsausschuss delegiert das Tagesgeschäft an den Projektmanager und greift nur ein, wenn Toleranzen voraussichtlich überschritten werden. Welches Prinzip beschreibt das?

❌ Produktorientierung

❌ Definierte Rollen und Verantwortlichkeiten

❌ Steuern über Managementphasen

✅ Steuern nach dem Ausnahmeprinzip

„Steuern nach dem Ausnahmeprinzip“ erlaubt eigenverantwortliches Arbeiten innerhalb von Toleranzen und Eskalation nur bei drohender Überschreitung.

Merksatz: Der Lenkungsausschuss ist wie ein König, der nur eingreift, wenn sein Hofstaat (Projektmanager) die königlichen Toleranzen überschreitet. Sonst regiert er im Hintergrund – das ist "Steuern nach dem Ausnahmeprinzip".

Warum die anderen falsch sind:
Produktorientierung: Fokussiert auf die Lieferobjekte, nicht auf die Delegationsweise.
Definierte Rollen und Verantwortlichkeiten: Beschreibt die Zuweisung, nicht den Interventionsmechanismus.

Steuern über Managementphasen: Bezieht sich auf die Projektstrukturierung, nicht auf das Eingreifen bei Abweichungen.

☝️ Single Ein Projektmanager reduziert die Anzahl der Managementprodukte, weil das Projekt klein und risikoarm ist. Welches Prinzip rechtfertigt dies?

❌ Lernen aus Erfahrung

❌ Fortlaufende geschäftliche Rechtfertigung sicherstellen

✅ Anpassen an das Projekt

❌ Steuern nach dem Ausnahmeprinzip

„Anpassen an das Projekt“ erlaubt, Umfang und Formalität der Methode an Größe, Komplexität und Risiko anzupassen.

Merksatz:
Ein maßgeschneiderter Anzug passt sich dem Körper an – genauso passt sich PRINCE2 durch das Prinzip „Anpassen an das Projekt“ in Größe, Komplexität und Risiko flexibel an jedes Projekt an, um unnötigen Ballast zu vermeiden.

Warum die anderen falsch sind:
Lernen aus Erfahrung: Zielt auf das Vermeiden von Fehlern durch Lektionen ab, nicht auf die Skalierung der Dokumentation.
Fortlaufende geschäftliche Rechtfertigung: Prüft nur, ob sich das Projekt finanziell und strategisch noch lohnt.
Manage by Exception:* Regelt Toleranzen und Eskalationswege bei Abweichungen, nicht die strukturelle Projektgröße.

Die 7 Prozesse

Prozessreihenfolge [F] [Prozesse] 1 Unterseite →

☝️ Single In welcher grundsätzlichen Reihenfolge laufen die PRINCE2-Prozesse typischerweise ab?

❌ Directing (begleitend) → Starting up → Initiating → Controlling/Managing pro Stage → Closing, wobei das Directing erst nach dem Initiating beginnt und die Stages in beliebiger Reihenfolge durchlaufen werden.

❌ Initiating → Starting up → Directing (begleitend) → Controlling/Managing pro Stage → Closing, wobei das Initiating bereits vor dem Projektstart abgeschlossen sein muss und das Directing nur bei Abweichungen eingreift.

❌ Closing → Directing (begleitend) → Starting up → Initiating → Controlling/Managing pro Stage, wobei das Closing als erstes durchgeführt wird, um die Ressourcen für die nachfolgenden Prozesse freizugeben.

✅ Starting up → Directing (begleitend) → Initiating → Controlling/Managing pro Stage → Closing

SU → DP → IP → (CS/MP/SB wiederholt pro Stage) → CP, mit DP begleitend über die gesamte Laufzeit.

Merksatz:
Denk an den Bau eines Hauses: Erst der Startschuss (Starting up), dann die Direktion der Chefs (Directing) im Hintergrund, gefolgt von der Detailplanung (Initiating). Danach wird Etage für Etage kontrolliert und gemanagt (Controlling/Managing per Stage), bis am Ende der Schlüssel übergeben und das Haus geschlossen wird (Closing).

Warum die anderen falsch sind:
Keine Reihenfolge: Falsch, da PRINCE2 ein logischer, chronologischer Leitfaden für den Projektlebenszyklus ist.
Gleichzeitig/unabhängig: Falsch, da Prozesse aufeinander aufbauen (z. B. braucht die Planung die Freigabe aus der Startphase).

Closing vor Initiating: Falsch, da man ein Projekt nicht beenden kann, bevor es überhaupt detailliert geplant und gestartet wurde.

SU - Starting up a Project [F] [Prozesse] 1 Unterseite →

☝️ Single Was ist der Kernzweck von "Starting up a Project" (SU)?

❌ Die vollständige Erstellung aller geplanten Projektergebnisse und Lieferobjekte sicherstellen

❌ Die kontinuierliche Überwachung und Steuerung der täglichen Arbeiten innerhalb einer laufenden Stage übernehmen

❌ Den formellen Abschluss des Projekts inklusive aller Übergabe- und Abschlussaktivitäten durchführen

✅ Vorab prüfen, ob sich ein Projekt überhaupt lohnt

Vorab zu prüfen, ob sich ein Projekt überhaupt lohnt, bevor größere Ressourcen investiert werden.

Merksatz: Bevor du den Motor startest, prüfst du den Tank: SU ist der schnelle Vorab-TÜV, um Schrottprojekte sofort auszusortieren, bevor echtes Geld fließt.

Warum die anderen falsch sind:
A: Verwechselt die kurze Vorbereitungsphase mit der eigentlichen, langen Realisierung.
B: Verwechselt den Projektstart mit der späteren, täglichen Steuerungsarbeit im Projekt.

C: Verwechselt den allerersten Schritt (Start) mit dem allerletzten Schritt (Abschluss).

DP - Directing a Project [F] [Prozesse] 1 Unterseite →

☝️ Single Wer ist hauptsächlich für den Prozess "Directing a Project" (DP) verantwortlich?

❌ Ausschließlich der Projektmanager

✅ Das Lenkungsausschuss

❌ Ausschließlich externe Prüfer

❌ Ausschließlich die Teammanager

Das Project Board — trifft die übergeordneten Entscheidungen über die gesamte Projektlaufzeit hinweg.

Merksatz:
Das Project Board steht am Steuerrad (Directing): Nur die Lenkungsausschuss-Mitglieder haben die Macht, das Projekt zu steuern und freizugeben – sie sind die „Direktoren“ an Bord.

Warum die anderen falsch sind:
Project Manager: Führt das Projekt im Alltag operativ (Managing), statt es strategisch zu lenken.
Externe Prüfer: Sichern die Qualität unabhängig ab, treffen aber keine Steuerungsentscheidungen.

Team Manager: Liefern nur die Arbeitspakete ab (Delivering) und haben keine Gesamtverantwortung.

IP - Initiating a Project [F] [Prozesse] 1 Unterseite →

☝️ Single Was wird im Prozess "Initiating a Project" (IP) typischerweise erstellt?

❌ Der Abschlussbericht

❌ Ein einzelnes Arbeitspaket

✅ Das Project Initiation Documentation (PID)

❌ Ausschließlich das Budget ohne weitere Planung

Das Project Initiation Documentation (PID) mit detaillierter Planung.

Merksatz:
IP macht das Projekt IP-fit: Im Prozess Initiating a Project schnüren wir das PID (Project Initiation Documentation) als stabiles Fundament, bevor die Reise richtig losgeht.

Warum die anderen falsch sind:
Abschlussbericht: Dieser entsteht erst ganz am Ende im Prozess Closing a Project (CP).
Einzelnes Arbeitspaket: Arbeitspakete werden dynamisch im Prozess Managing a Product Delivery (MP) erstellt, nicht in der initialen Gesamtplanung.

Ausschließlich das Budget: Das PID umfasst die integrierte Gesamtplanung (Qualität, Risiko, Nutzen etc.), ein reines Budget greift viel zu kurz.

CS - Controlling a Stage [F] [Prozesse] 1 Unterseite →

☝️ Single Was ist der Kernzweck von "Controlling a Stage" (CS)?

❌ Die abschließende formale Abnahme aller Projektergebnisse und die offizielle Auflösung des Projektteams

❌ Die reine Weitergabe der Verantwortung an das nächste Team ohne weitere Überwachungstätigkeiten

❌ Die einmalige Bestätigung des Projektauftrags und die Freigabe der ersten Management-Stage

✅ Tägliche Steuerung und Überwachung einer laufenden Stage

Die tägliche Steuerung und Überwachung einer laufenden Management-Stage.

Merksatz:
Stell dir einen Regisseur vor, der täglich am Bühnenrand steht, um das laufende Theaterstück (die Stage) aktiv zu steuern und zu überwachen – er greift laufend ein und wartet nicht erst auf das Finale.

Warum die anderen falsch sind:
A: Der formale Projektabschluss ist Aufgabe des separaten Prozesses „Closing a Project“.
B: Übergaben betreffen die Produktlieferung und das Phasenende, nicht die alltägliche Steuerung.

C: Die einmalige Freigabe erfolgt vorab auf strategischer Ebene durch das Projektlenkungsausschuss-Gremium.

MP - Managing Product Delivery [F] [Prozesse] 1 Unterseite →

☝️ Single Was ist der Kernzweck von "Managing Product Delivery" (MP)?

❌ Die formale Durchführung der Projektabschlussaktivitäten

✅ Kontrollierte Übergabe von Arbeitspaketen an das Team

❌ Die strategische Freigabeentscheidung für den Projektstart

❌ Die ausschließliche Festlegung des Projektbudgets

Kontrollierte Übergabe von Arbeitspaketen zwischen Project Manager und Team Manager/Team.

Merksatz:
Denke an den Postboten (Projektleiter), der ein Paket (Arbeitspaket) kontrolliert an den Empfänger (Team) übergibt, damit dieser es bearbeiten kann – MP regelt genau diese Schnittstelle zur Umsetzung.

Warum die anderen falsch sind:
A) ... beschreibt den Prozess "Abschließen eines Projekts" (CP) ganz am Ende.
C) ... ist die strategische Aufgabe des Lenkungsausschusses (DP) vor dem eigentlichen Start.

D) ... reduziert das gesamte Schnittstellenmanagement fälschlicherweise auf einen reinen Finanzaspekt.

SB - Managing a Stage Boundary [F] [Prozesse] 1 Unterseite →

☝️ Single Wann kommt der Prozess "Managing a Stage Boundary" (SB) typischerweise zum Einsatz?

❌ Ausschließlich zu Projektbeginn

❌ Ausschließlich am absoluten Projektende

❌ Während der täglichen Arbeit innerhalb einer Stage

✅ Am Übergang zwischen zwei Management-Stages

Am Übergang von einer Management-Stage zur nächsten — Planung der Folgestufe, Bericht an das Project Board.

Merksatz: Stell dir die „Stage Boundary“ wie eine Zollstation an der Grenze zweier Länder vor: Du musst anhalten, Bilanz ziehen und das Visum für das nächste Land (die nächste Phase) beantragen, um die Grenze überqueren zu dürfen.

Warum die anderen falsch sind:
A) Zu Projektbeginn greift die Initiierung, da noch keine Phasen-Grenze existiert.
B) Am Projektende wird das Projekt final geschlossen, es folgt keine neue Phase mehr.

C) Die tägliche Arbeit innerhalb einer Phase wird durch „Controlling a Stage“ gesteuert.

CP - Closing a Project [F] [Prozesse] 1 Unterseite →

☝️ Single Was ist der Kernzweck von "Closing a Project" (CP)?

❌ Ein formaler Projektabschluss, bei dem ausschließlich die Auflösung des Projektteams im Mittelpunkt steht und keine weitere Bewertung der Ergebnisse erfolgt.

✅ Kontrollierter, formaler Projektabschluss inkl. Zielbewertung

❌ Der kontrollierte Start der eigentlichen Umsetzungsphase, in der die geplanten Lieferobjekte erstmals erstellt und dem Kunden übergeben werden.

❌ Die detaillierte Ausarbeitung der Projektpläne und Ressourcenverteilung, die unmittelbar nach der Initiierung des Projekts durchgeführt wird.

Kontrollierter, formaler Abschluss des Projekts — inkl. Bewertung, ob Ziele erreicht wurden.

Merksatz:
Der CP-Prozess ist der „Notar des Projekts“: Er macht offiziell das Licht aus, zieht einen sauberen Schlussstrich unter die Ergebnisse und übergibt das fertige Produkt kontrolliert an den Kunden.

Warum die anderen falsch sind:
Nur Team-Auflösung: CP ist viel umfassender und bewertet auch den Projekterfolg sowie die Zielerreichung.
Beginn der Umsetzung: Die Umsetzung startet viel früher im Prozess „Directing a Controlling a Stage“ (CS).

Detailplanung zu Beginn: Die Detailplanung gehört in die Initiierungsphase (IP) und nicht an das Projektende.

DP begleitend [F] [Prozesse] 1 Unterseite →

☝️ Single Warum läuft "Directing a Project" (DP) begleitend über die gesamte Projektlaufzeit statt nur einmalig?

❌ Weil das Lenkungsausschuss nur bei der Initiierungsphase eine formale Freigabe erteilen muss

❌ Weil das Lenkungsausschuss die gleichen Aufgaben wie der Projektmanager während der gesamten Laufzeit übernimmt

❌ Weil das Lenkungsausschuss ausschließlich bei der Abschlussphase die Endabnahme und Projektbewertung vornimmt

✅ Weil das Lenkungsausschuss fortlaufend Entscheidungen treffen muss

Weil das Project Board fortlaufend Entscheidungen treffen muss (z.B. Freigaben an Stage-Übergängen, Reaktion auf Exceptions).

Merksatz:
Der Lenkungsausschuss ist kein Einmal-Schnitt, sondern der Dauer-Steuermann: Das Project Board muss das Schiff über die gesamte Fahrt hinweg aktiv steuern und an jeder Kreuzung fortlaufend Entscheidungen treffen.

Warum die anderen falsch sind:
Nur beim Projektabschluss relevant: Übersieht, dass Lenkungsentscheidungen (wie Freigaben) von der Initiierung bis zum Ende permanent nötig sind.
Identisch mit CS: Verwechselt die strategische Lenkungsebene des Projektausschusses (DP) mit der operativen Steuerungsebene des Projektmanagers (CS).

Nur zu Projektbeginn einmalig: Ignoriert, dass ein Projekt dynamisch ist und nicht nach dem Start sich selbst überlassen werden kann.

7 Prozesse korrekt benennen [F] [Prozesse] 1 Unterseite →

✌️ Multi Welche der folgenden gehören zu den 7 PRINCE2-Prozessen? (Mehrfachauswahl)

❌ Continuous Deployment

✅ Starting up a Project

✅ Closing a Project

✅ Managing a Stage Boundary

Merksatz:
Ein Projekt läuft wie ein Theaterstück: Vor dem Vorhang wird das Projekt gestartet (Starting up), am Ende wird es sauber geschlossen (Closing), und in den Pausen zwischen den Akten ziehen wir an der Bühnengrenze Bilanz (Stage Boundary).

Warum die anderen falsch sind:

Continuous Deployment: Dies ist ein Begriff aus der agilen Softwareentwicklung (DevOps) und kein PRINCE2-Prozess.

Prozessablauf eigenständig erklären [F] [Prozesse] 1 Unterseite →

☝️ Single Welcher Prozess läuft begleitend über die gesamte Projektlaufzeit?

✅ Directing a Project (DP)

❌ Starting up a Project (SU)

❌ Initiating a Project (IP)

❌ Closing a Project (CP)

Directing a Project (DP) läuft als einziger Prozess begleitend über die gesamte Projektlaufzeit.

Merksatz:
Der Direktor (DP - Directing) sitzt vom ersten Casting bis zum Abspann im Regiestuhl und lenkt den gesamten Film.

Warum die anderen falsch sind:
SU: ...ist nur die kurze Aufwärmphase vor dem eigentlichen Projektstart.
IP: ...legt einmalig das Fundament fest und endet mit der Projektfreigabe.

CP: ...räumt erst ganz am Ende die Baustelle auf.

SB vs. CS Abgrenzung [F] [Prozesse] 1 Unterseite →

☝️ Single Wodurch unterscheiden sich "Controlling a Stage" (CS) und "Managing a Stage Boundary" (SB)?

✅ CS steuert die laufende Arbeit innerhalb einer Stage, SB bereitet den Übergang zur nächsten Stage vor

❌ CS und SB sind beide für die Überwachung der Projektkosten zuständig, unterscheiden sich aber in der Häufigkeit der Berichterstattung

❌ CS behandelt ausschließlich die technische Qualität der Lieferobjekte, während SB sich nur mit der Terminplanung beschäftigt

❌ SB überwacht die täglichen Aktivitäten des Projektteams, während CS die Freigabe der nächsten Stage genehmigt

Controlling a Stage (CS) ist die laufende Tagesarbeit innerhalb einer Stage; Managing a Stage Boundary (SB) findet am Übergang zwischen zwei Stages statt.

Merksatz: Mit CS (Controlling a Stage) steuerst du das Auto auf der Straße (laufende Phase), bei SB (Stage Boundary) stehst du an der Grenzstation zur nächsten Etappe.

Warum die anderen falsch sind:
B: CS läuft permanent während der gesamten Phase, nicht erst am Ende.
C: Hier wurden die Definitionen der beiden Prozesse komplett vertauscht.

D: Die Prozesse sind grundverschieden und laufen zu unterschiedlichen Zeiten ab.

Vorbereiten eines Projekts (SU) [Prozesse] 5 Unterseite →

☝️ Single Was ist der Hauptzweck des Prozesses 'Vorbereiten eines Projekts' (Starting up a Project)?

❌ Sicherstellen, dass alle Projektaktivitäten abgeschlossen und die Ergebnisse formal dokumentiert sind

❌ Die vollständige Projektinitiierungsdokumentation mit allen Details und Plänen ausarbeiten

✅ Prüfen, ob das Projekt lohnend und machbar ist, bevor größerer Aufwand investiert wird

❌ Die geplanten Projektergebnisse erstellen und deren Abnahme durch den Auftraggeber bestätigen

SU stellt sicher, dass die Voraussetzungen für die Initiierung vorliegen. Die detaillierte PID entsteht erst in 'Initiieren eines Projekts'.

Merksatz:
Der Prozess "Vorbereiten" ist der Türsteher des Projekts: Er prüft erst den Ausweis (Sinn und Machbarkeit), bevor die teure Party (Investition) überhaupt losgehen darf.

Warum die anderen falsch sind:
A: Abschluss und Lessons Learned gehören ganz ans Ende des Projekts, nicht an den Start.
B: Die vollständige PID wird erst in der darauffolgenden Initiierungsphase detailliert ausgearbeitet.

D: Die Produkterstellung geschieht erst viel später in der Umsetzungsphase durch die Spezialisten-Teams.

☝️ Single Welches Dokument löst den Prozess 'Vorbereiten eines Projekts' aus?

❌ Die Projektinitiierungsdokumentation (PID)

❌ Der Phasenabschlussbericht der vorherigen Phase

❌ Das Arbeitspaket des Teammanagers

✅ Der Projektauftrag (Projektmandat)

Der Projektauftrag ist der externe Auslöser, mit dem die beauftragende Ebene das Projekt anstößt.

Merksatz:
Der Projektauftrag (Project Mandate) ist der Zündschlüssel, der den Motor der Vorbereitung überhaupt erst anlässt – ohne Mandat kein Start!

Warum die anderen falsch sind:
A (PID): Ist das finale Ergebnis der Initiierung, entsteht also viel zu spät.
B (End Stage Report): Schließt eine spätere Phase ab, statt das Projekt ganz am Anfang zu starten.

C (Arbeitspaket): Regelt die operative Ausführung im laufenden Projekt und ist kein Auslöser.

☝️ Single Welches Ergebnis entsteht typischerweise in 'Vorbereiten eines Projekts'?

❌ Der detaillierte Business Case in endgültiger Form

✅ Der Projektkurzbeschreibung mit einem groben (initialen) Business Case

❌ Das vollständige Qualitätsregister mit allen Prüfungen

❌ Die genehmigten Phasenabschlussberichts aller Phasen

In SU entstehen u. a. Project Brief und grober Business Case; der detaillierte Business Case folgt in der Initiierung.

Merksatz:
Beim Vorbereiten (SU) schreiben wir nur einen kurzen Brief (Project Brief) mit grobem Budget (initialer Business Case), bevor wir überhaupt losreisen.

Warum die anderen falsch sind:
A: ...weil Details erst beim Initiieren (IP) ausgearbeitet werden.
C: ...weil das Qualitätsregister erst im Projektverlauf wächst.

D: ...weil Phasenberichte logischerweise erst am Ende von Phasen entstehen.

☝️ Single Welche Tätigkeit gehört NICHT zu 'Vorbereiten eines Projekts'?

❌ Festlegen des Projektansatzes und Zusammenstellen des Projektkurzbeschreibung

❌ Erstellen eines groben Business Case

✅ Erstellen der vollständigen Projektinitiierungsdokumentation

❌ Ernennen von Executive und Projektmanager

Die vollständige PID wird in 'Initiieren eines Projekts' erstellt, nicht in SU.

Merksatz:
Beim Aufwärmen (Vorbereiten) schnürt man nur die Schuhe (grober Plan, Rollen) – die vollständige Rüstung (PID) legt man erst beim eigentlichen Start (Initiieren) an.

Warum die anderen falsch sind:
A (Projektansatz/Brief): Gehört zur Vorbereitung, da man vorab klären muss, wie das Projekt grundsätzlich angegangen wird.
B (grober Business Case): Ist zwingend Teil der Vorbereitung, um die Sinnhaftigkeit vor dem echten Projektstart grob zu prüfen.

D (Executive/PM ernennen): Muss ganz am Anfang der Vorbereitung passieren, da ohne diese Rollen niemand die Arbeit steuern kann.

☝️ Single Wer wird im Prozess 'Vorbereiten eines Projekts' zuerst ernannt?

❌ Die Änderungsinstanz und Project Support

✅ Der Executive und der Projektmanager

❌ Alle Teammanager des Projekts

❌ Die Senior User aller Nutzergruppen

Zu Beginn werden Executive und Project Manager ernannt, damit die weitere Vorbereitung erfolgen kann.

Merksatz: Erst der Chef (Executive) und sein Fahrer (Project Manager), bevor die Reise (das Projekt) überhaupt losgehen kann.

Warum die anderen falsch sind:
A): Change Authority und Support sind rein operative Rollen, die erst im laufenden Projekt zur Entlastung ernannt werden.
C): Team Manager werden erst viel später für die konkrete Umsetzung einzelner Arbeitspakete benötigt.

D): Senior User werden erst bei der späteren, detaillierten Zusammensetzung des Lenkungsausschusses definiert.

Lenken eines Projekts (DP) [Prozesse] 5 Unterseite →

☝️ Single Wer führt den Prozess 'Lenken eines Projekts' (Directing a Project) aus?

❌ Der Teammanager

❌ Project Support

✅ Das Lenkungsausschuss

❌ Der Projektmanager

DP ist der Prozess des Project Boards: Es trifft die Schlüsselentscheidungen des Projekts.

Merksatz: Das Board hält das Lenkrad in der Hand – nur der Lenkungsausschuss (Project Board) steuert das Projekt aus der Vogelperspektive.

Warum die anderen falsch sind:
A) Der Team Manager führt nur einzelne Arbeitspakete aus, lenkt aber nicht strategisch.
B) Project Support leistet rein administrative Zuarbeit ohne jegliche Entscheidungskompetenz.

D) Der Project Manager managt zwar das operative Tagesgeschäft, lenkt (directs) aber nicht das Gesamtprojekt.

☝️ Single Über welchen Zeitraum läuft der Prozess 'Lenken eines Projekts'?

❌ Nur während der Initiierungsphase

❌ Nur beim Abschluss des Projekts

❌ Nur am Ende jeder Managementphase

✅ Über die gesamte Projektlaufzeit

DP begleitet das ganze Projekt – von der Freigabe der Initiierung bis zum Abschluss.

Merksatz:
Der Kapitän lässt das Steuer niemals los: Gelenkt wird das Projektschiff vom Ablegen bis zum Anlegen – also über die gesamte Projektlaufzeit!

Warum die anderen falsch sind:
A): Nur am Anfang zu lenken, führt danach zum sofortigen Blindflug.
B): Erst beim Abschluss zu lenken ist nutzlos, da das Schiff dann bereits angekommen oder gesunken ist.

C): Nur am Phasenende zu lenken vernachlässigt die kontinuierliche Steuerung und Entscheidungsfindung während der Phasen.

☝️ Single Welche Entscheidung trifft das Board im Prozess 'Lenken eines Projekts' NICHT?

❌ Die Entscheidung über die tägliche Zuweisung von Arbeitspaketen an einzelne Teams treffen

✅ Die tägliche Vergabe einzelner Arbeitspakete an die Teams

❌ Die Freigabe des Projektabschlusses auf Basis des Endberichts erteilen

❌ Die Genehmigung eines Phasenplans oder Ausnahmeplans zur Steuerung des Projektfortschritts vornehmen

Arbeitspakete vergibt der Project Manager in 'Steuern einer Phase' – nicht das Board.

Merksatz:
Der Lenkungsausschuss lenkt das große Schiff aus der Ferne – er schrubbt nicht täglich das Deck (Mikromanagement ist Sache des Projektleiters).

Warum die anderen falsch sind:
A: Das Board muss das offizielle Projektende absegnen, da es die Gesamtverantwortung trägt.
C: Phasen- und Ausnahmepläne erfordern zwingend die strategische Freigabe der Lenkungsebene bei Toleranzüberschreitungen.

D: Ohne das initiale „Go“ des Boards für die Initiierung darf das Projekt gar nicht erst starten.

☝️ Single Nach welchem Prinzip arbeitet das Board vorrangig im Prozess 'Lenken eines Projekts'?

❌ Steuern durch detaillierte Kontrolle sämtlicher Arbeitspakete auf täglicher Basis

❌ Steuern ohne vorab definierte Toleranzgrenzen für Zeit, Kosten und Qualität

✅ Steuern nach dem Ausnahmeprinzip (Steuern nach dem Ausnahmeprinzip)

❌ Steuern ausschließlich durch eine einzige Bewertung am Ende des gesamten Projekts

Das Board delegiert innerhalb vereinbarter Toleranzen und greift erst bei drohender Überschreitung ein.

Merksatz:
Das Lenkungs-Board schläft friedlich im Liegestuhl und wacht erst auf, wenn der Alarm (die Toleranzgrenze) schrillt – es steuert nur bei der Ausnahme (Management by Exception).

Warum die anderen falsch sind:
A: Tägliche Detailkontrolle ist Mikromanagement durch den Projektleiter, nicht Aufgabe des Boards.
B: Ohne Toleranzen müsste das Board bei jeder kleinsten Abweichung zeitaufwendig eingreifen.

D: Eine Steuerung nur am Projektende macht eine rechtzeitige Kurskorrektur unmöglich.

☝️ Single Womit reagiert das Board bei Bedarf zwischen den Phasen mit konkreter Hilfestellung?

❌ Mit einer informellen Rücksprache mit dem Projektmanager (informal consultation)

❌ Mit einer formlosen Stellungnahme zum Projektstatus (informal statement)

❌ Mit einer ungeplanten Mitteilung an das Projektteam (unscheduled communication)

✅ Mit Ad-hoc-Anweisungen (ad hoc direction)

Neben formalen Freigaben kann das Board über Ad-hoc-Anweisungen reagieren.

Merksatz: Das Board ist wie die Feuerwehr: Brennt es unerwartet zwischen den Phasen, greift es spontan zum Löschschlauch der Ad-hoc-Anweisungen (ad hoc direction).

Warum die anderen falsch sind:
Checkpoint Report: Ist ein Statusbericht des Teams an den Projektleiter, keine Lenkungsmaßnahme des Boards.
Produktflussdiagramm: Ist ein reines Planungswerkzeug zur logischen Reihenfolge von Produkten.

Arbeitspaket: Wird vom Projektleiter an die Teamleiter vergeben, nicht vom Board.

Initiieren eines Projekts (IP) [Prozesse] 5 Unterseite →

☝️ Single Was ist der Hauptzweck des Prozesses 'Initiieren eines Projekts' (Initiating a Project)?

❌ Eine belastbare Grundlage für die Projektsteuerung etablieren und die notwendigen Managementverfahren festlegen

✅ Ein solides Fundament schaffen, damit das Projekt gesteuert werden kann

❌ Die wirtschaftliche Tragfähigkeit des Vorhabens bewerten und eine fundierte Entscheidungsgrundlage bereitstellen

❌ Die geplanten Projektergebnisse termingerecht herstellen und an die beauftragende Stelle übergeben

IP schafft die Grundlage: PID, Management-Ansätze, Register und detaillierter Business Case.

Merksatz:
Wer ein stabiles Haus bauen will, gießt zuerst ein solides Fundament – genau das tut die Initiierung, damit das Projekt beim Steuern später nicht ins Wanken gerät.

Warum die anderen falsch sind:
A: Bewerten und Abschließen erfolgt erst ganz am Ende des Projektlebenszyklus.
C: Ob das Projekt lohnend ist, wird bereits im Vorfeld (beim Vorbereiten) grob geprüft.

D: Die Produkterstellung ist die eigentliche Umsetzungsarbeit, nicht die Initiierung.

☝️ Single Welches zentrale Dokument entsteht im Prozess 'Initiieren eines Projekts'?

❌ Die Projektmanagement-Team-Kommunikationsstrategie (PMKS)

❌ Die Projektmanagement-Risikobewertung (PMRB)

❌ Die Projektmanagement-Qualitätsprüfungsdokumentation (PMQD)

✅ Die Projektinitiierungsdokumentation (PID)

Die PID bündelt Business Case, Ansätze, Organisation, Pläne und Controls und ist die Baseline des Projekts.

Merksatz:
Wer ein Projekt Initiiert, gießt das Fundament mit der PID (ProjektInitiierungsDokumentation) – das prägnante I verbindet den Prozess direkt mit dem Dokumentenname.

Warum die anderen falsch sind:
A) Der Checkpoint Report ist ein regelmäßiger Statusbericht der Teamebene während der laufenden Phase.
B) Das Project Mandate (Projektauftrag) ist der externe Auslöser vor dem eigentlichen Projektstart.

C) Der End Project Report wird erst ganz am Ende beim Projektabschluss erstellt.

☝️ Single Welche Management-Ansätze werden typischerweise in 'Initiieren eines Projekts' festgelegt?

❌ Risiko-, Qualitäts-, Change-Control- und Kommunikationsmanagement-Ansatz werden erst im Projektabschluss festgelegt und dokumentiert

❌ Der Benefits-Management-Ansatz wird als einziger Ansatz im Initiieren eines Projekts definiert und alle anderen folgen später

✅ Risiko-, Qualitäts-, Change-Control- und Kommunikationsmanagement-Ansatz

❌ Der Kommunikationsmanagement-Ansatz ist der einzige, der während der Initiierungsphase festgelegt wird

In der Initiierung werden die Management-Ansätze definiert und in der PID zusammengeführt.

Merksatz:
Stell dir vor, du packst für deine Projekt-Reise: Einen Rettungsring (Risiko), ein Qualitätssiegel (Qualität), ein Chameleon (Change-Control) und ein Kabeltelefon (Kommunikation) – dieses R-Q-C-K-Sicherheitspaket schnürst du direkt beim Start (Initiieren)!

Warum die anderen falsch sind:
A: Wer Management-Ansätze erst beim Abschluss festlegt, plant den Schiffbruch im Voraus.
B: Der Fokus auf reinen Nutzen (Benefits) ignoriert die operativen Risiken und Qualitätsstandards.

D: Nur zu kommunizieren reicht nicht aus, um Änderungen und Risiken aktiv zu steuern.

☝️ Single Wer genehmigt die in 'Initiieren eines Projekts' erstellte PID?

❌ Das Lenkungsausschuss im Prozess 'Steuern eines Projekts'

❌ Der Projektmanager im Prozess 'Initiieren eines Projekts'

✅ Das Lenkungsausschuss (im Prozess 'Lenken eines Projekts')

❌ Die Unternehmensleitung im Prozess 'Direktes Management von Projekten'

Der Project Manager erstellt die PID; genehmigt wird sie vom Board über DP.

Merksatz:
Der Manager plant das Schiff (PID), aber nur die Admirale im Board geben im Prozess Lenken das Signal zum Auslaufen.

Warum die anderen falsch sind:
Der Project Manager selbst: Er ist nur der Architekt und darf sein eigenes Werk nicht final freigeben (Gewaltenteilung).
Die beauftragende Ebene direkt: Sie delegiert die operative Führung an das Project Board, welches die direkte Entscheidungsinstanz ist.

Der Team Manager: Er liefert nur Arbeitspakete zu und hat keinerlei projektweite Autorisierungsbefugnis.

☝️ Single Worin unterscheidet sich der Business Case in IP von dem in SU?

❌ In IP wird der Business Case nur auf strategischer Ebene betrachtet, während er in SU bereits vollständig ausgearbeitet und genehmigt wird.

❌ Der Business Case wird in beiden Prozessen mit dem gleichen Detaillierungsgrad erstellt und unterscheidet sich lediglich in der verwendeten Dokumentationsvorlage.

❌ In SU wird der Business Case nur als grobe Skizze angelegt, während er in IP bereits final abgeschlossen und keiner weiteren Überarbeitung mehr unterzogen wird.

✅ In IP wird er detailliert ausgearbeitet, in SU ist er nur grob

Der grobe Business Case aus SU wird in IP zum detaillierten Business Case ausgearbeitet.

Merksatz:
In SU machst du die Skizze (grob), in IP die Intensiv-Planung (detailliert).

Warum die anderen falsch sind:
A: Ein Business Case ist das wirtschaftliche Fundament und entfällt in IP niemals.
B: Der Business Case entwickelt sich im Projektverlauf weiter und bleibt nicht identisch.

C: Verwechselt die logische Reihenfolge, da das zeitlich vorgelagerte SU nur die grobe Vorstufe liefern kann.

Steuern einer Phase (CS) [Prozesse] 5 Unterseite →

☝️ Single Wer führt den Prozess 'Steuern einer Phase' (Controlling a Stage) aus?

✅ Der Projektmanager

❌ Das Lenkungsausschuss

❌ Der Teammanager

❌ Die Änderungsinstanz

CS ist der Alltagsprozess des Project Managers innerhalb einer Managementphase.

Merksatz: Der Projektmanager (PM) steht täglich auf der Phasen-Bühne und managt die Show – er hält das Steuer der Phase fest in der Hand.

Warum die anderen falsch sind:
B) Das Project Board lenkt das Projekt nur strategisch aus der Vogelperspektive, statt operativ die Phase zu steuern.
C) Der Team Manager verantwortet nur die Erstellung einzelner Arbeitspakete, nicht die übergeordnete Phase.

D) Die Change Authority bewertet und genehmigt lediglich Änderungen, statt den laufenden Phasenprozess zu managen.

☝️ Single Welchen Bericht liefert der Projektmanager in 'Steuern einer Phase' an das Board?

✅ Den Projektstatusbericht

❌ Den Ausnahmeplan

❌ Den Teamstatusbericht

❌ Den Projektabschlussbericht

Über Highlight Reports informiert der Project Manager das Board regelmäßig über den Phasenfortschritt.

Merksatz:
Der Projektmanager wirft im laufenden Betrieb ein Spotlight (Highlight Report) nach oben zum Lenkungsausschuss (Board), um die Phase im richtigen Licht zu steuern.

Warum die anderen falsch sind:
Exception Plan: Wird vom Projektmanager erst nach einer Toleranzüberschreitung (Ausnahme) erstellt, nicht als regelmäßiger Bericht zur Phasensteuerung.
Checkpoint Report: Geht vom Teammanager nach oben an den Projektmanager (Fortschritt der Arbeitspakete), nicht direkt an das Board.

End Project Report: Wird erst ganz am Ende im Prozess „Abschließen eines Projekts“ erstellt, nicht während der laufenden Phasensteuerung.

☝️ Single Was tut der Projektmanager in 'Steuern einer Phase', wenn eine Toleranz voraussichtlich überschritten wird?

❌ Er dokumentiert die Abweichung und wartet ab, ob sich die Lage bis zum nächsten Phasenende von selbst korrigiert, bevor er eine Entscheidung trifft.

✅ Er eskaliert die Ausnahme an das Lenkungsausschuss (Exception)

❌ Er passt die Projekttoleranzen eigenständig an die neue Situation an, um die Abweichung ohne weitere Abstimmung mit dem Lenkungsausschuss zu kompensieren.

❌ Er beendet das Projekt vorzeitig, um weitere Kosten zu vermeiden, und informiert das Lenkungsausschuss erst nach Abschluss über die Gründe.

Drohende Toleranzüberschreitungen werden als Exception an die nächsthöhere Ebene eskaliert.

Merksatz: Reißt die Toleranz-Leine, schlag sofort Alarm beim Lenkungsausschuss (Project Board) – der Manager meldet die Ausnahme (Exception), statt den Kopf in den Sand zu stecken.

Warum die anderen falsch sind:
A) Ignorieren verschlimmert die Abweichung und verletzt die projektliche Berichtspflicht.
C) Toleranzgrenzen darf nur der Lenkungsausschuss ändern, nicht der Projektmanager eigenmächtig.

D) Ein sofortiger Projektabbruch ist eine extreme Überreaktion und liegt nicht in der Befugnis des Projektmanagers.

☝️ Single Welche Tätigkeit gehört zu 'Steuern einer Phase'?

❌ Das Projekt formal abschließen

✅ Arbeitspakete vergeben, überwachen und abnehmen

❌ Die Initiierung des Projekts freigeben

❌ Die nächste Phase planen und den Business Case aktualisieren

In CS vergibt und überwacht der Project Manager Arbeitspakete; die nächste Phase plant SB.

Merksatz:
Der Phasen-Steuermann steht am Fließband: Er verteilt die Arbeitspakete, schaut genau hin (überwachen) und klebt am Ende das Prüfsiegel drauf (abnehmen).

Warum die anderen falsch sind:
A) ...gehört zum finalen Projektabschluss, nicht zur laufenden Phase.
C) ...ist eine strategische Freigabe des Lenkungsausschusses, kein operatives Steuern.

D) ...beschreibt den Phasenübergang an der Grenze zur nächsten Phase.

☝️ Single Für welchen Zeitraum wird der Prozess 'Steuern einer Phase' durchlaufen?

❌ Für jede einzelne Managementphase (Lieferphase) des Projekts gesondert

❌ Für den gesamten Projektlebenszyklus in einem durchgehenden Durchlauf

❌ Ausschließlich während der Initiierungsphase des Projekts

✅ Für jede Managementphase (Lieferphase) einzeln

CS wird je Lieferphase durchlaufen; am Phasenende schließt SB an.

Merksatz:
Denke an eine Treppe: Du nimmst nicht die gesamte Treppe auf einmal, sondern steuerst jede Stufe (Phase) einzeln an, um sicher oben anzukommen.

Warum die anderen falsch sind:
A) Verwechselt die laufende Steuerung mit dem finalen Projektabschluss.
B) Ignoriert, dass ein Projekt in überschaubare Abschnitte unterteilt werden muss.

C) Setzt die Steuerung fälschlicherweise mit der reinen Vorbereitungsphase gleich.

Managen der Produktlieferung (MP) [Prozesse] 5 Unterseite →

☝️ Single Wer führt den Prozess 'Managen der Produktlieferung' (Managing Product Delivery) aus?

✅ Der Teammanager

❌ Das Lenkungsausschuss

❌ Der Projektmanager

❌ Project Assurance

MP ist der Prozess des Team Managers bzw. Teams, das die Produkte erstellt.

Merksatz: Der Team Manager steht direkt an der Werkbank und packt die Produkte für die Lieferung persönlich ab.

Warum die anderen falsch sind:
Project Board (B): Lenkt das Projekt nur strategisch aus der Chefetage, statt operativ Produkte zu erstellen.
Project Manager (C): Steuert das Gesamtprojekt und delegiert die eigentliche Erstellung an den Team Manager.

Project Assurance (D): Überwacht und prüft die Qualität unabhängig, statt selbst zu liefern.

☝️ Single Welcher Bericht wird in 'Managen der Produktlieferung' an den Projektmanager gegeben?

❌ Der Projektstatusbericht

✅ Der Teamstatusbericht

❌ Der Ausnahmebericht

❌ Der Phasenabschlussbericht

Der Team Manager berichtet dem Project Manager über Checkpoint Reports.

Merksatz:
Der Teammanager meldet sich am Checkpoint beim Projektmanager zurück, um die Arbeit zu checken – wie ein Soldat, der am Kontrollpunkt (Checkpoint) Statusbericht erstattet.

Warum die anderen falsch sind:
Highlight Report: Wird vom Projektmanager an den Lenkungsausschuss geschickt, nicht vom Teammanager.
Exception Report: Wird bei drohenden Toleranzüberschreitungen vom Projektmanager an den Lenkungsausschuss eskaliert.

End Stage Report: Erstellt der Projektmanager am Ende einer Phase für den Lenkungsausschuss, um die Phase abzuschließen.

☝️ Single Was bildet die Schnittstelle zwischen 'Steuern einer Phase' und 'Managen der Produktlieferung'?

❌ Das Arbeitspaket (Arbeitspaket) bildet die Schnittstelle zwischen 'Steuern einer Phase' und 'Managen der Produktlieferung' und wird vom Projektmanager an das Team erteilt.

❌ Das Erfahrungsprotokoll dokumentiert Erfahrungen und wird während des gesamten Projekts gepflegt, um Verbesserungen für zukünftige Phasen zu ermöglichen.

❌ Die Projektinitiierungsdokumentation (PID) legt die Grundlagen für das Projekt fest und wird zu Beginn des Projekts erstellt und genehmigt.

✅ Das Arbeitspaket (Arbeitspaket)

Das Arbeitspaket ist die Vereinbarung zwischen Project Manager (CS) und Team Manager (MP).

Merksatz:
Das Arbeitspaket ist das Postpaket, das der Projektleiter (Phase steuern) dem Teamleiter (Produktlieferung managen) über die Schnittstelle reicht – ohne Paket gibt es keinen Auftrag.

Warum die anderen falsch sind:
A) Lessons Log: Ist ein reines Lern-Register für Erfahrungen, kein operatives Übergabe-Werkzeug.
B) PID: Dokumentiert die Projektdefinition beim Start, nicht die laufende Phasen-Schnittstelle.

C) Business Case: Prüft die wirtschaftliche Tragfähigkeit des Gesamtprojekts, steuert aber keine konkreten Lieferungen.

☝️ Single Welche Tätigkeit gehört zu 'Managen der Produktlieferung'?

❌ Die Initiierung des Projekts formell freigeben und den Projektauftrag bestätigen

✅ Ein Arbeitspaket annehmen, ausführen und die Produkte liefern

❌ Den Business Case prüfen und die wirtschaftliche Rechtfertigung des Projekts genehmigen

❌ Die Managementphasen des Projekts im Projektplan detailliert ausarbeiten und festlegen

In MP nimmt der Team Manager Arbeitspakete an, erstellt die Produkte und liefert sie.

Merksatz:
Stell dir den Paketboten vor: Er muss das Arbeitspaket annehmen, die Treppen hochrennen (ausführen) und es dir an der Haustür liefern.

Warum die anderen falsch sind:
A) Freigaben sind strategische Chefsache des Lenkungsausschusses, nicht der operativen Lieferebene.
C) Die Genehmigung des Business Case obliegt ebenfalls dem übergeordneten Lenkungsausschuss.

D) Die Phasenplanung ist Aufgabe des Projektmanagers beim Phasenübergang, nicht des Lieferteams.

☝️ Single Was prüft der Teammanager, bevor er ein Arbeitspaket annimmt?

❌ Ob die Freigabe der nächsten Managementphase durch das Projektboard bereits erfolgt ist

✅ Ob er die Vereinbarung (Aufwand, Termine, Qualität, Toleranzen) erfüllen kann

❌ Ob der im Business Case dokumentierte Nutzen des Gesamtprojekts weiterhin als erreichbar gilt

❌ Ob die für den Projektabschluss definierten Kriterien und Lieferobjekte vollständig umsetzbar sind

Der Team Manager stellt sicher, dass er das Arbeitspaket wie vereinbart liefern kann.

Merksatz: Der Team-Manager ist wie ein Handwerker: Bevor er den Auftrag (das Arbeitspaket) annimmt, prüft er seine Werkzeugkiste und den Kalender, ob er das Werk in der vereinbarten Zeit und Qualität wirklich liefern kann.

Warum die anderen falsch sind:
A) Phasenfreigaben entscheidet der Lenkungsausschuss, das liegt weit über der operativen Ebene des Team-Managers.
C) Die Wirtschaftlichkeit (Business Case) überwacht die Projektleitung, nicht der ausführende Team-Manager.

D) Der Projektabschluss ist eine strategische Phase am Ende, kein Kriterium für ein einzelnes Arbeitspaket.

Managen eines Phasenübergangs (SB) [Prozesse] 5 Unterseite →

☝️ Single Was ist der Hauptzweck des Prozesses 'Managen eines Phasenübergangs' (Managing a Stage Boundary)?

❌ Dem Projektausschuss die laufenden Arbeitsfortschritte der Teams im Detail berichten

❌ Die im Phasenplan definierten Lieferobjekte eigenständig und vollständig herstellen

❌ Den formalen Projektabschluss inklusive aller Abschlussberichte und Lessons Learned durchführen

✅ Dem Board die Grundlage für die Entscheidung über die nächste Phase liefern

SB plant die nächste Phase, aktualisiert Business Case/Pläne und liefert den End Stage Report.

Merksatz:
Am Grenzübergang (Boundary) zeigst du dem Zoll (Board) die Papiere, damit sie die Schranke zur nächsten Phase öffnen.

Warum die anderen falsch sind:
A: Tägliche Teamarbeit steuern ist Aufgabe von „Steuern einer Phase“ (CS), nicht des Übergangs.
B: Die Produkterstellung erfolgt im Prozess „Managen der Produktlieferung“ (MP).

C: Der endgültige Projektabschluss ist ein eigener, separater Prozess am Projektende (CP).

☝️ Single Welcher Bericht entsteht am Ende einer Phase in 'Managen eines Phasenübergangs'?

✅ Der Phasenabschlussbericht

❌ Der Projektabschlussbericht

❌ Der Projektauftrag

❌ Der Teamstatusbericht

Der End Stage Report zieht Bilanz der Phase und geht an das Board.

Merksatz:
Am Ende der Phase stehst du auf der Stage (Bühne) und präsentierst den End Stage Report – Vorhang zu für diesen Abschnitt!

Warum die anderen falsch sind:
B) End Project Report: Beendet das gesamte Projekt und nicht nur eine einzelne Phase.
C) Projektauftrag: Entsteht ganz am Anfang des Projekts als Autorisierungsbasis.
D) Checkpoint Report: Ist ein rein operativer Statusbericht des Teamleiters während* einer laufenden Phase.

☝️ Single Wann wird der Prozess 'Managen eines Phasenübergangs' zusätzlich ausgelöst?

✅ Wenn eine Ausnahme (Exception) einen Ausnahmeplan erfordert

❌ Wenn ein Teammitglied eine Abweichung von der Toleranz meldet, die aber noch innerhalb der vereinbarten Toleranzgrenzen liegt

❌ Wenn der Projektauftrag geändert wird und dadurch eine neue Version der Projektdokumentation erforderlich ist

❌ Wenn der Projektmanager eine regelmäßige Überprüfung der Projektfortschritte durchführt und dabei eine Aktualisierung der Pläne vornimmt

Neben dem regulären Phasenende wird SB genutzt, um nach einer Exception einen Ausnahmeplan zu erstellen.

Merksatz:
Der Phasenübergang ist wie eine Grenzkontrolle: Sie wird nicht nur regulär passiert, sondern auch dann erzwungen, wenn ein Unfall (Ausnahme) eine völlig neue Route (Ausnahmeplan) erfordert.

Warum die anderen falsch sind:
B: ...da tägliche Statusmeldungen reines operatives Tagesgeschäft sind und keinen Phasenwechsel rechtfertigen.
C: ...da Phasenübergänge zwischen allen Phasen stattfinden und nicht erst beim Projektabschluss.

D: ...da am Ende der Initiierung nur die erste Phase freigegeben wird, der Prozess aber an jedem Phasenende greift.

☝️ Single Was wird im Prozess 'Managen eines Phasenübergangs' aktualisiert?

❌ Der Business Case, die Projektpläne und die Register werden im Phasenübergang nicht angepasst, sondern nur die Arbeitspakete für die nächste Phase neu definiert.

❌ Im Prozess 'Managen eines Phasenübergangs' werden ausschließlich die Einträge im Daily Log aktualisiert, um den Fortschritt der laufenden Phase festzuhalten.

❌ Der Prozess 'Managen eines Phasenübergangs' erzeugt lediglich neue Dokumente, ohne bestehende Projektinformationen wie Pläne oder Register zu verändern.

✅ Der Business Case, die Projektpläne und die Register

SB aktualisiert Business Case, Pläne und Register und plant die Folgephase.

Merksatz:
Am Grenzübergang (Phasenübergang) kontrolliert der Zoll deinen aktualisierten Pass (Projektplan), dein Geld (Business Case) und deine Gepäckliste (Register), bevor du weiterreisen darfst.

Warum die anderen falsch sind:
A: ... weil Arbeitspakete zu kleinteilig sind und im laufenden Betrieb gesteuert werden.
B: ... da das Daily Log nur ein informelles Alltagswerkzeug des Projektleiters ist.

C: ... weil ohne die Aktualisierung von Plänen und Business Case die Entscheidungsgrundlage für die nächste Phase fehlt.

☝️ Single Für welche Phase wird KEIN regulärer Phasenübergang durchgeführt?

❌ Für die Initiierungsphase (dort folgt die Projekteinrichtung)

✅ Für die letzte Phase (dort folgt der Abschluss)

❌ Für die erste Lieferphase (dort folgt der Projektstart)

❌ Für jede mittlere Phase (dort folgt die nächste Phase)

Am Ende der letzten Phase folgt kein weiterer Übergang, sondern 'Abschließen eines Projekts'.

Merksatz: Am Ende der Reise gibt es keine Brücke mehr, sondern das Ziel – die letzte Phase wird nicht übergeleitet, sondern direkt abgeschlossen.

Warum die anderen falsch sind:
A) Erste Lieferphase: – Sie geht regulär in die nächste Phase über, um den Fortschritt zu sichern.
C) Mittlere Phase: – Jede Zwischenphase benötigt zwingend einen gesteuerten Übergang zur nächsten Etappe.

D) Initiierungsphase: – Nach dem Startschuss erfolgt der reguläre Übergang in die erste Lieferphase.

Abschließen eines Projekts (CP) [Prozesse] 5 Unterseite →

☝️ Single Was ist der Hauptzweck des Prozesses 'Abschließen eines Projekts' (Closing a Project)?

❌ Die Erstellung des Projektauftrags als formale Grundlage für die Projektfreigabe sicherstellen

❌ Die Detailplanung der ersten Managementphase inklusive Zeit- und Ressourcenplanung durchführen

❌ Die Entwicklung der projektspezifischen Produkte gemäß den Anforderungen im Projektauftrag vornehmen

✅ Einen kontrollierten Abschluss mit Produktabnahme und Bewertung sicherstellen

CP bestätigt die Abnahme, übergibt die Produkte, bewertet das Projekt und empfiehlt den Abschluss.

Merksatz: Der Projektabschluss ist wie die Schlüsselübergabe beim Hausbau: Erst wenn der Kunde den Schlüssel abnimmt (Produktabnahme) und die Arbeit bewertet, ist kontrolliert Feierabend.

Warum die anderen falsch sind:
A) Ist der allererste Schritt beim Projektstart und nicht das Ende.
B) Plant den Anfang des Projekts, was zeitlich genau entgegengesetzt ist.

C) Beschreibt die eigentliche Umsetzung während der Projektlaufzeit, nicht das Finale.

☝️ Single Welche Berichte entstehen typischerweise in 'Abschließen eines Projekts'?

✅ Projektabschlussbericht und Erfahrungsbericht

❌ Projektauftrag und Projektkurzbeschreibung

❌ Projektstatusbericht und Teamstatusbericht

❌ Nur der Ausnahmebericht

Zum Abschluss werden End Project Report und Lessons Report erstellt.

Merksatz:
Am Ende (End Project Report) zieht man die Lehren (Lessons Report) – der finale Vorhang fällt erst, wenn abgerechnet und gelernt wurde.

Warum die anderen falsch sind:
B): Projektauftrag und Project Brief entstehen ganz am Anfang bei der Initiierung.
C): Highlight und Checkpoint Reports dienen der regelmäßigen Statuskontrolle während der laufenden Phasen.

D): Der Exception Report ist ein reiner Krisenbericht bei Toleranzüberschreitungen während des Projekts.

☝️ Single Wer autorisiert letztlich den Abschluss des Projekts?

❌ Die Änderungsinstanz, die im Prozess 'Steuern eines Projekts' die Freigabe des Projektabschlusses erteilt, nachdem alle Änderungsanforderungen abschließend bewertet wurden.

❌ Der Teammanager, der im Prozess 'Steuern eines Projekts' den Projektabschluss bestätigt, sobald alle Arbeitspakete formal abgenommen und die Lieferobjekte übergeben wurden.

✅ Das Lenkungsausschuss (im Prozess 'Lenken eines Projekts')

❌ Project Support, das im Prozess 'Lenken eines Projekts' den Projektabschluss autorisiert, nachdem die Projektdokumentation vollständig archiviert und die Lessons Learned erfasst wurden.

Der Project Manager bereitet den Abschluss vor; das Board autorisiert ihn über DP.

Merksatz:
Nur die Kapitäne auf der Brücke (Board) dürfen das Schiff offiziell im Hafen abmelden und die Reise beenden.

Warum die anderen falsch sind:
A) Change Authority: Ist nur für inhaltliche Änderungen während der Laufzeit zuständig, nicht für das Projektende.
B) Team Manager: Führt lediglich einzelne Arbeitspakete operativ aus und hat keine strategische Entscheidungsmacht.

D) Project Support: Leistet nur administrative Hilfsdienste und besitzt keinerlei Führungs- oder Freigabekompetenz.

☝️ Single Welche zwei Abschlussarten unterscheidet PRINCE2?

❌ Den vertraglichen und den internen Abschluss

❌ Den Phasenabschluss und den Projektabschluss

✅ Den geplanten und den vorzeitigen (premature) Abschluss

❌ Den formellen und den informellen Abschluss

Ein Projekt kann planmäßig oder vorzeitig abgeschlossen werden.

Merksatz: Ein Projekt endet wie eine Reise: Entweder kommen wir geplant am Ziel an, oder wir müssen wegen einer Panne vorzeitig aussteigen.

Warum die anderen falsch sind:
A) Intern/extern betrifft nur die Vertragspartner, nicht die PRINCE2-Prozesslogik.
B) Phasen und Arbeitspakete enden im laufenden Projekt, nicht beim finalen Projektabschluss.

D) Agil und klassisch sind Entwicklungsansätze, keine formellen Abschlussarten.

☝️ Single Was geschieht in 'Abschließen eines Projekts' mit den Produkten?

❌ Sie werden erstmals im Projektmanagementplan festgelegt und für die weitere Nutzung dokumentiert

❌ Sie werden ohne formale Abnahme direkt entsorgt und aus dem Projektarchiv entfernt

✅ Sie werden abgenommen und an Betrieb/Nutzer übergeben

❌ Sie werden an den Projektauftrag zurückgegeben und dort für Folgeprojekte archiviert

CP bestätigt die Abnahme und regelt die Übergabe der Produkte.

Merksatz:
Beim Projektabschluss ist „Schlüsselübergabe“: Das fertige Haus wird feierlich abgenommen und an die neuen Bewohner (Betrieb/Nutzer) übergeben.

Warum die anderen falsch sind:
A) Planung gehört an den Projektstart, nicht ans Ende.
B) Produkte unbesehen wegzuwerfen, widerspricht dem wirtschaftlichen Projektsinn.

D) Der Projektauftrag ist ein statisches Dokument und kann keine Produkte aufnehmen.

Die 7 Prozesse [Prozesse] 18 Unterseite →

☝️ Single Worauf bezieht sich der Begriff „organisatorisches Ökosystem“?

✅ Das Netzwerk aus Menschen, Kultur, Beziehungen und Prozessen

❌ Die Gesamtheit aller externen Dienstleister und Lieferanten, die an einem Projekt beteiligt sind

❌ Die Summe aller technischen Systeme und Anwendungen, die für die Projektarbeit genutzt werden

Richtig. Es erfasst, wie alles und jeder innerhalb der Organisation zusammenwirkt.

Merksatz:
Ein biologisches Ökosystem lebt vom Zusammenspiel aller Organismen – im Projekt sind das Menschen, Kultur, Beziehungen und Prozesse, die wie ein lebendiger Wald zusammenwirken.

Warum die anderen falsch sind:
B) Hierarchien bilden nur das starre, formale Gerüst ab und vernachlässigen das lebendige, informelle Miteinander.
C) Die IT-Infrastruktur stellt lediglich die technischen Werkzeuge bereit, nicht aber das soziale und kulturelle Gefüge.

☝️ Single Wofür steht das PRINCE2-„Prozessrad“?

❌ Eine ausschließlich für die Projektplanung vorgesehene Sammlung von Aktivitäten ohne Bezug zur Steuerung

❌ Eine strikt aufeinanderfolgende Kette von Arbeitsschritten, die keinerlei Überlappungen oder Rückkopplungen zulässt

✅ Eine strukturierte Menge von Prozessen, die während des gesamten Projekts zusammenwirken

Richtig – das „Rad“ zeigt, wie die Prozesse über den gesamten Lebenszyklus miteinander verbunden sind.

Merksatz:
Das PRINCE2-Prozessrad ist wie ein Zahnradgetriebe: Alle Zahnräder (Prozesse) greifen während der gesamten Fahrt (Projekt) ständig ineinander, um das Projekt dynamisch am Laufen zu halten.

Warum die anderen falsch sind:
A): Ein Rad dreht sich während der gesamten Reise und stoppt nicht direkt nach der Planung.
B): Prozesse greifen flexibel und parallel ineinander, statt starr und nacheinander abzulaufen.

☝️ Single Was ist der Hauptzweck des Prozesses Starting Up a Project (SU) – Vorbereiten eines Projekts?

✅ Sicherzustellen, dass das Projekt tragfähig ist, bevor Ressourcen gebunden werden

❌ Sicherzustellen, dass alle Projektprodukte termingerecht und gemäß den Anforderungen geliefert werden

❌ Sicherzustellen, dass der vollständige Projektplan inklusive aller Aktivitäten und Ressourcen erstellt wird

Richtig – SU prüft, ob es sich lohnt, mit dem Projekt fortzufahren.

Merksatz:
SU ist der „Türsteher“ des Projekts: Er prüft die Tragfähigkeit an der Schwelle, damit keine teuren Ressourcen für eine schlechte Idee verschwendet werden.

Warum die anderen falsch sind:
B) Das Liefern von Produkten ist Aufgabe der viel späteren Umsetzungsphase, nicht des ersten Starts.
C) Die vollständige Detailplanung erfolgt erst im darauffolgenden Prozess der Initiierung (IP).

☝️ Single Was ist der Zweck des Projektkurzbeschreibung in PRINCE2?

❌ Alle Projektpläne endgültig festzulegen

✅ Einen ersten Überblick über das Projekt zu geben

❌ Die Project Initiation Documentation (PID) zu ersetzen

Richtig – der Project Brief umreißt frühzeitig die wichtigsten Aspekte des Projekts.

Merksatz: Das Project Brief ist wie ein kurzer Brief (Postkarte) vor dem Urlaub: Er gibt einen schnellen Überblick, bevor die Reise überhaupt richtig losgeht.

Warum die anderen falsch sind:
A: Endgültige Pläne entstehen erst viel später in der Initiierungsphase, nicht beim ersten groben Entwurf.
C: Das Briefing ist die Vorstufe und das Fundament der PID, kein Ersatz dafür.

☝️ Single Welche Rolle hat das Lenkungsausschuss im Prozess Directing a Project (DP) – Lenken eines Projekts?

❌ Die detaillierte Steuerung der einzelnen Projektphasen und die Überwachung der Tagesabläufe zu übernehmen

❌ Die konkreten Arbeitspakete für die Teams zu definieren und deren Ergebnisse abzunehmen

✅ Die übergeordnete Richtung vorzugeben und zentrale Entscheidungen zu treffen

Richtig – das Project Board lenkt das Projekt und trifft übergeordnete Entscheidungen.

Merksatz: Das Project Board ist der Kapitän auf der Brücke: Es bestimmt den Kurs (Richtung) und trifft die großen Entscheidungen, statt selbst im Maschinenraum zu schuften.

Warum die anderen falsch sind:
A ist falsch, weil das tägliche Management die rein operative Aufgabe des Projektmanagers ist.
B ist falsch, weil Arbeitspakete auf der Lieferebene von den Teamleitern erstellt und koordiniert werden.

☝️ Single Was ist der Hauptfokus des Prozesses Controlling a Stage (CS) – Steuern einer Phase?

✅ Die täglichen Projektaktivitäten zu überwachen und zu steuern

❌ Die vollständige Projektplanung über den gesamten Lebenszyklus hinweg zu erstellen und zu pflegen

❌ Die abschließenden Aktivitäten des Projekts zu koordinieren und den Abschluss zu verwalten

Richtig – in CS managt der Project Manager den täglichen Fortschritt, Issues und Risiken.

Merksatz:
Stell dir den Projektmanager wie einen Kapitän vor, der im Prozess Controlling a Stage täglich fest das Steuerrad greift, um die Mannschaft auf der aktuellen Etappe auf Kurs zu halten.

Warum die anderen falsch sind:
B: Die Gesamtplanung erfolgt vorab im Prozess Initiating a Project (IP) und nicht während der laufenden Phasensteuerung.
C: Für das geordnete Beenden des Projekts ist exklusiv der Prozess Closing a Project (CP) zuständig.

☝️ Single Was ist der Zweck eines Arbeitspaket in PRINCE2?

❌ Die im Projektverlauf gesammelten Erfahrungen und Erkenntnisse systematisch zu dokumentieren und für zukünftige Projekte aufzubereiten

❌ Den vollständigen Umfang des Projekts inklusive aller Lieferobjekte, Aktivitäten und Ressourcen verbindlich festzulegen

✅ Die einem Team zugewiesene Arbeit zu autorisieren und zu detaillieren

Richtig – Work Packages definieren klar, was das Team liefern muss.

Merksatz:
Das Work Package ist der offizielle Marschbefehl: Es autorisiert das Team und liefert alle Details für dessen konkreten Auftrag.

Warum die anderen falsch sind:
A: Verwechselt die Arbeitsdelegation mit dem Erfahrungslernen (Lessons Log).
B: Verwechselt ein einzelnes, kleines Paket mit dem gesamten Projektumfang.

☝️ Single Was ist der Hauptzweck eines Teamstatusbericht?

❌ Dem Lenkungsausschuss eine Zusammenfassung des aktuellen Projektstatus zur Entscheidungsfindung zu übermitteln

✅ Fortschrittsupdates vom Teammanager an den Projektmanager zu liefern

❌ Die formale Genehmigung für den Beginn der nächsten Projektphase einzuholen

Fortschrittsupdates vom Team Manager an den Project Manager zu liefern

Merksatz:
Am Checkpoint funkt der Team Manager direkt an den Project Manager: „Arbeitspaket läuft!“ – ein kurzes, operatives Update von unten nach oben.

Warum die anderen falsch sind:
A) Das Project Board erhält den übergeordneten Highlight Report, keinen detaillierten Bericht aus der Teamebene.
C) Die Phasenfreigabe ist eine strategische Entscheidung des Project Boards am Phasenübergang, kein einfaches Status-Update.

☝️ Single Was ist der Hauptzweck des Prozesses Managing a Stage Boundary (SB) – Managen eines Phasenübergangs in PRINCE2?

❌ Die aktuellen Arbeitspakete zu genehmigen und die Projektfreigabe zu erteilen

✅ Die aktuelle Phase zu überprüfen und die nächste Phase zu planen

❌ Die Projektrisiken zu bewerten und den Projektauftrag zu aktualisieren

Das ist der Hauptzweck – die Leistung zu bewerten und den nächsten Phasenplan vorzubereiten.

Merksatz: Am Grenzübergang (Boundary) hältst du kurz an, ziehst Bilanz der letzten Etappe und planst die Route für die nächste Teilstrecke.

Warum die anderen falsch sind:
A) Aufgabenverteilung gehört in die laufende Steuerung (CS) und Teamführung (MPD), nicht an die Phasengrenze.
C) Die Erstellung und Lieferung von Produkten erfolgt operativ im Prozess MPD.

☝️ Single Wann sollte in PRINCE2 ein Ausnahmeplan erstellt werden?

❌ Wenn im Projektverlauf eine Phase erfolgreich abgeschlossen wurde und die nächste Phase geplant werden muss

❌ Wenn die Projektleitung regelmäßige Fortschrittsberichte erstellt und den Business Case aktualisiert

✅ Wenn erwartet wird, dass Toleranzen überschritten werden

Wenn erwartet wird, dass Toleranzen überschritten werden

Merksatz: Der Exception Plan ist der Notfall-Airbag: Er zündet erst, wenn das Projekt die schützenden Leitplanken (Toleranzen) zu durchbrechen droht.

Warum die anderen falsch sind:
A) Zu Beginn jeder Phase wird standardmäßig ein regulärer Phasenplan (Stage Plan) erstellt, kein Ausnahmeplan.
B) Bei normalem Projektverlauf steuert man über bestehende Pläne, ein Sonderplan wäre hier reine Zeitverschwendung.

☝️ Single Was ist ein zentrales Ziel des Prozesses Closing a Project (CP) – Abschließen eines Projekts?

❌ Sicherzustellen, dass alle Projektziele erreicht und die Ergebnisse im Tagesgeschäft nachhaltig verankert werden

✅ Sicherzustellen, dass alle Produkte abgenommen und ordnungsgemäß übergeben werden

❌ Sicherzustellen, dass alle offenen Punkte und Risiken vollständig gelöst und dokumentiert werden

Der Abschluss stellt die formale Abnahme und ordnungsgemäße Übergabe sicher.

Merksatz:
Beim Projektabschluss (CP) übergibst du die Schlüssel: Nur wenn der Kunde alle Produkte abnimmt und unterschreibt, ist das Projekt sauber übergeben.

Warum die anderen falsch sind:
A: Der Business Case wird ganz am Anfang in der Startphase erstellt, nicht erst beim Aufräumen am Ende.
C: Ein neues Projekt startet man in der Vorbereitungsphase, während CP das Licht ausknipst.

☝️ Single Was unterscheidet eine vorzeitige Beendigung (Premature Closure) von einer geplanten Beendigung in PRINCE2?

❌ Eine vorzeitige Beendigung erfolgt, wenn alle Ziele erreicht wurden

❌ Eine vorzeitige Beendigung erfolgt, bevor alle geplanten Produkte geliefert wurden

✅ Eine geplante Beendigung erfolgt, wenn das Projekt nicht mehr tragfähig ist

Dies beschreibt eine vorzeitige Beendigung aufgrund von Scheitern oder Veränderung.

Merksatz:
Stell dir einen unfertigen Rohbau vor: Bei der vorzeitigen Beendigung wird die Baustelle fluchtartig verlassen, bevor das schützende Dach (das fertige Produkt) geliefert wurde.

Warum die anderen falsch sind:
A: Verwechselt vorzeitig mit geplant, da das Erreichen aller Ziele das reguläre Projektende markiert.
C: Verdreht die Logik, da mangelnde Tragfähigkeit der Hauptgrund für einen vorzeitigen Abbruch ist.

☝️ Single Wann sollte ein Ausnahmebericht erstellt werden?

✅ Wenn erwartet wird, dass eine Toleranz überschritten wird

❌ In regelmäßigen Abständen, um das Lenkungsausschuss zu informieren

❌ Wenn eine Phase planmäßig verläuft

Ein Exception Report wird erstellt, wenn erwartet wird, dass die Leistung die vereinbarten Toleranzen überschreitet, was eine Eskalation erfordert.

Merksatz:
Der Exception Report ist wie ein Notbrems-Signal: Er wird sofort gezogen, wenn der Projektzug droht, die Schienen der vereinbarten Toleranz zu verlassen.

Warum die anderen falsch sind:
B) Regelmäßige Status-Updates erfolgen über den Highlight Report, nicht über Ausnahmeberichte.
C) Bei planmäßigem Verlauf gilt „Management by Exception“ – hier ist kein Bericht nötig.

☝️ Single Was ist der PRIMÄRE Zweck des Prozesses Starting Up a Project (SU) – Vorbereiten eines Projekts?

❌ Sicherzustellen, dass die vollständige Projektdefinition und alle Managementstrategien endgültig genehmigt und dokumentiert werden

✅ Sicherzustellen, dass das Projekt tragfähig und sinnvoll ist, bevor erhebliche Ressourcen gebunden werden

❌ Die kontinuierliche Steuerung und Überwachung der Projektarbeit während der gesamten Laufzeit zu gewährleisten

SU stellt sicher, dass das Projekt auf einem soliden Fundament steht, indem die Tragfähigkeit vor größeren Investitionen geprüft wird. Es beantwortet die Frage: „Sollten wir überhaupt starten?“

Merksatz: Der Prozess Starting Up (SU) ist der Türsteher des Projekts: Er prüft den Ausweis auf Sinnhaftigkeit, bevor die teure Party (Ressourcenbindung) überhaupt losgeht.

Warum die anderen falsch sind:
A: Die detaillierte PID wird erst im darauffolgenden Prozess Initiating a Project (IP) erstellt, nicht beim ersten Vorab-Check.
C: Die Lieferung der Produkte wird im Prozess Managing Product Delivery (MP) gesteuert, also mitten in der Umsetzungsphase.

☝️ Single Was ist der ENTSCHEIDENDE Unterschied zwischen dem Projektkurzbeschreibung und der PID (Project Initiation Documentation)?

❌ Die PID ersetzt den Projektkurzbeschreibung vollständig und enthält ausschließlich die während der Initiierungsphase erarbeiteten Pläne, während der Projektkurzbeschreibung nur die Projektmandatsanforderungen zusammenfasst.

✅ Die PID löst den Projektkurzbeschreibung ab und liefert einen detaillierten Bauplan für das Projekt

❌ Der Projektkurzbeschreibung ist die ausführlichere und umfassendere Version der PID, da er bereits alle Detailpläne und Kontrollvorgaben für die spätere Steuerung des Projekts enthält.

Die PID baut auf dem Project Brief auf und wird zum maßgeblichen Dokument, das das Projekt leitet.

Merksatz:
Der Brief ist der grobe Steckbrief (die Skizze), während die PID als detaillierter Bauplan das Projekt endgültig einleitet und den Brief ablöst.

Warum die anderen falsch sind:
A: Ignoriert, dass der Brief nur die Initiierungsphase startet, während die PID das gesamte Projekt steuert.
C: Verwechselt die Detailtiefe, da ein kurzer Steckbrief niemals detaillierter sein kann als eine umfassende Dokumentation.

☝️ Single Wer ist im Prozess Directing a Project (DP) – Lenken eines Projekts primär für die Entscheidungsfindung verantwortlich?

❌ Teammanager

❌ Projektmanager

✅ Lenkungsausschuss

Das Project Board gibt die übergeordnete Richtung vor, trifft zentrale Entscheidungen und autorisiert die wichtigsten Phasen.

Merksatz:
Wer lenkt (Directing), sitzt im Board – nur der Lenkungsausschuss (Project Board) hat das Steuer für die finalen Entscheidungen in der Hand.

Warum die anderen falsch sind:
A) Team Manager: ...steuert nur die Erstellung der Produkte im eigenen Team, nicht das Gesamtprojekt.
B) Project Manager: ...managt nur das tägliche Geschäft und muss für Richtungsentscheidungen das Board fragen.

☝️ Single Was ist das HAUPTZIEL des Prozesses Managing a Stage Boundary (SB) – Managen eines Phasenübergangs?

✅ Die aktuelle Phase zu überprüfen und die nächste Phase zu planen

❌ Die Gesamtsteuerung des Projekts zu übernehmen und den Auftraggeber über den aktuellen Status zu informieren

❌ Die geplanten Projektergebnisse fertigzustellen und an den Kunden zu übergeben

SB stellt sicher, dass das Projekt tragfähig bleibt, indem die Leistung überprüft und der nächste Phasenplan zur Genehmigung vorbereitet wird.

Merksatz: Am Grenzübergang (Boundary) blickst du zurück auf die geschaffte Etappe und planst die Route für das nächste Land.

Warum die anderen falsch sind:
B: ... weil der Projektabschluss erst ganz am Ende im separaten Prozess „Closing a Project“ erfolgt.
C: ... weil Produkte operativ im Prozess „Managing Product Delivery“ erstellt und geliefert werden.

☝️ Single Welches Szenario beschreibt eine vorzeitige Projektbeendigung (Premature Closure) AM BESTEN?

❌ Das Projekt wird nach Abschluss aller geplanten Phasen regulär beendet, ohne dass ein vorzeitiger Abbruch erfolgt

❌ Das Projekt endet, sobald die definierten Lieferobjekte vollständig erstellt und an den Auftraggeber übergeben wurden

✅ Das Projekt wird wegen fehlender geschäftlicher Rechtfertigung frühzeitig gestoppt

Eine vorzeitige Beendigung tritt ein, wenn das Projekt frühzeitig gestoppt wird, oft weil es nicht mehr tragfähig oder gerechtfertigt ist.

Merksatz:
„Premature Closure“ ist die Notbremse im Projekt: Wenn der Business Case stirbt (fehlende Rechtfertigung), zieht man den Stecker vor dem eigentlichen Ziel.

Warum die anderen falsch sind:
A): Das Erreichen der letzten Phase beschreibt den ganz normalen, planmäßigen Projektverlauf ohne Abbruch.
B): Die erfolgreiche Lieferung aller Produkte ist das Paradebeispiel für einen regulären, erfolgreichen Projektabschluss.

Prozesse [F] [Prozesse] [Neu] 5 Unterseite →

☝️ Single Was ist der Auslöser (Trigger) für den Prozess „Vorbereiten eines Projekts“?

❌ Business-Case-Entwurf

✅ Projektmandat

❌ Projektproduktbeschreibung

❌ Ernennung des Projektauftraggebers

Das Projektmandat löst den Prozess „Vorbereiten eines Projekts“ aus; die übrigen Elemente entstehen erst innerhalb dieses Prozesses.

Merksatz:
Das Mandat ist der Startschuss: Ohne ein offizielles „Projektmandat“ von der Unternehmensleitung darf im PRINCE2-Motor kein einziger Kolben anspringen – es ist der physische Schlüssel, der den Prozess „Vorbereiten eines Projekts“ (SU) überhaupt erst startet.

Warum die anderen falsch sind:
Business-Case-Entwurf: Ist kein Auslöser, sondern ein wichtiges Ergebnis, das erst während dieses Prozesses erstellt wird.
Projektproduktbeschreibung: Wird ebenfalls erst im Prozess selbst erarbeitet, um die Erwartungen des Kunden zu definieren.
Ernennung des Projektauftraggebers: Ist eine Aktivität* innerhalb des Prozesses (basierend auf dem Mandat) und nicht der Auslöser selbst.

☝️ Single Welche Aktivität wird ausschließlich im Prozess „Managen eines Phasenübergangs“ durchgeführt?

❌ Regelmäßige Fortschrittsberichterstattung an den Lenkungsausschuss

✅ Vorbereiten eines Ersatzplans zur Genehmigung durch den Lenkungsausschuss

❌ Fortlaufende Überprüfung der Rechtfertigung anhand des Business Case

❌ Vorbereiten des Projekts auf einen vorzeitigen Abschluss

Das Erstellen des nächsten Phasenplans (bzw. eines Ausnahmeplans) zur Genehmigung erfolgt nur im Prozess „Managen eines Phasenübergangs“.

Merksatz:
Der Ersatzplan (Exception Plan) ist die „Rettungsinsel“ am Phasenübergang: Er wird nur dann gebaut und zur Genehmigung vorgelegt, wenn die Phase aus dem Ruder läuft und neu geplant werden muss.

Warum die anderen falsch sind:
Regelmäßige Berichte: Dies geschieht laufend im Prozess Steuern einer Phase (mittels Statusberichten), nicht erst am Phasenübergang.
Fortlaufende Business-Case-Prüfung: Das ist eine permanente Führungsaufgabe im Prozess Lenken eines Projekts und keine exklusive Aktivität am Phasenübergang.
Vorzeitiger Abschluss: Die Vorbereitung für ein vorzeitiges Ende wird im Prozess Abschließen eines Projekts* durchgeführt.

☝️ Single Welcher Prozess stellt sicher, dass keine soliden Grundlagen für ein ungeeignetes Projekt geschaffen werden, bevor überhaupt Aufwand in die Initiierung fließt?

✅ Vorbereiten eines Projekts

❌ Lenken eines Projekts

❌ Initiieren eines Projekts

❌ Steuern einer Phase

„Vorbereiten eines Projekts“ prüft auf hoher Ebene die Sinnhaftigkeit, damit keine Grundlagen für ungeeignete Projekte gelegt werden.

Merksatz:
Erst VORBEREITEN, bevor wir starten: Der Türsteher-Prozess fängt den Müll ab, damit wir keine Zeit mit der teuren Initiierung verschwenden.

Lenken eines Projekts: Falsch, da der Lenkungsausschuss hier nur Entscheidungen trifft (z. B. Freigaben), statt die operativen Vorarbeiten zu leisten.
Initiieren eines Projekts: Falsch, da dieser Prozess bereits die detaillierte Planung (die soliden Grundlagen) ist, die wir für ein ungeeignetes Projekt ja gerade verhindern wollen.

Steuern einer Phase: Falsch, da dieser Prozess erst während der Projektdurchführung für die alltägliche Arbeit des Projektmanagers genutzt wird.

☝️ Single In welchem Prozess wird bewertet, ob alle in der aktuellen Projektleitdokumentation genannten Ziele erreicht wurden?

❌ Steuern einer Phase

❌ Managen eines Phasenübergangs

✅ Abschließen eines Projekts

❌ Managen der Produktlieferung

Im Prozess „Abschließen eines Projekts“ wird geprüft, ob die Ziele der Projektleitdokumentation erreicht wurden und das Projektprodukt abgenommen ist.

Merksatz:
Beim Abschließen eines Projekts zieht man den finalen Schlussstrich: Hier wird die Projektleitdokumentation (PID) wie ein Testament geöffnet, um zu prüfen, ob am Ende wirklich alle gesteckten Ziele erreicht wurden.

Warum die anderen falsch sind:
Steuern einer Phase: Konzentriert sich nur auf die alltägliche Überwachung der laufenden, einzelnen Phase, nicht auf das Gesamtprojekt.
Managen eines Phasenübergangs: Bereitet den Übergang zur nächsten Phase vor und plant diese, statt das finale Gesamtergebnis zu bewerten.

Managen der Produktlieferung: Ist die reine Arbeitsebene des Teams zur Erstellung der Produkte ohne Blick auf die übergeordneten Projektziele.

☝️ Single In welchem Prozess werden die im Arbeitspaket vereinbarten Produkte erstellt, geprüft und gemäß Produktbeschreibung abgenommen?

❌ Steuern einer Phase

✅ Managen der Produktlieferung

❌ Managen eines Phasenübergangs

❌ Abschließen eines Projekts

Die eigentliche Erstellung, Prüfung und Abnahme der Produkte erfolgt im Prozess „Managen der Produktlieferung“ durch die liefernden Teams.

Merksatz:
Der Produkt-Manager liefert ab: Nur im Prozess „Managen der Produktlieferung“ (MP) stellen die Spezialisten-Teams die Produkte her, testen sie und übergeben sie fertig abgenommen.

Warum die anderen falsch sind:
Steuern einer Phase: Dieser Prozess liegt beim Projektmanager, der Arbeitspakete nur vergibt und überwacht, aber nicht selbst Produkte erstellt.
Managen eines Phasenübergangs: Hier wird die nächste Phase geplant und die aktuelle für den Lenkungsausschuss bewertet, statt Produkte zu bauen.
Abschließen eines Projekts: Dies dient dem geordneten Projektende*, nicht der operativen Erstellung und Abnahme einzelner Arbeitspakete.

Prozesse [F] [Prozesse] 10 Unterseite →

☝️ Single Was ist ein Zweck des Prozesses „Vorbereiten eines Projekts“?

❌ Die detaillierte Steuerung an Teammanager zu delegieren

✅ Zu bewerten, ob ein Projekt für die Organisation lohnend sein kann

❌ Den Nutzen nach Projektende zu messen

❌ Die Produkte einer Phase abzunehmen

„Vorbereiten eines Projekts“ prüft auf hoher Ebene, ob das Projekt lohnend und machbar erscheint.

☝️ Single Was ist ein Zweck des Prozesses „Lenken eines Projekts“?

❌ Die Produkte zu erstellen und zu testen

❌ Die Arbeitspakete täglich zu steuern

❌ Die nächste Phase im Detail zu planen

✅ Die Rechenschaft des Lenkungsausschusses zu wahren und das Detailmanagement zu delegieren

„Lenken eines Projekts“ bewahrt die Gesamtverantwortung des Lenkungsausschusses und delegiert das Detailmanagement.

Merksatz:
Der Lenkungsausschuss ist der „Kapitän auf der Brücke“: Er trägt die Rechenschaft für das Schiff, überlässt das Rudern im Maschinenraum (Detailmanagement) aber der Crew (Delegation).

Warum die anderen falsch sind:
Produkte erstellen/testen: Das ist die Aufgabe der Spezialisten im Prozess Managen der Produktlieferung.
Arbeitspakete täglich steuern: Dies ist die operative Rolle des Projektmanagers im Prozess Steuern einer Phase.
Nächste Phase im Detail planen: Diese Detailplanung erfolgt im Prozess Managen eines Phasenübergangs* durch den Projektmanager, nicht durch das Lenkungsgremium.

☝️ Single Wann beginnt der Prozess „Lenken eines Projekts“?

❌ Nach Abschluss der Initiierungsphase

✅ Wenn der Projektmanager die Projektkurzbeschreibung zur Genehmigung vorlegt

❌ Bei der ersten Toleranzüberschreitung

❌ Nach Erhalt des Projektmandats

„Lenken eines Projekts“ beginnt mit dem Antrag auf Projektinitiierung, gestützt auf die vorgelegte Projektkurzbeschreibung.

Merksatz:
Der Lenkungsausschuss greift erst zum Steuer (Lenken beginnt), sobald ihm die Projektkurzbeschreibung (Project Brief) auf dem Silbertablett zur Genehmigung vorgelegt wird – vorher gibt es noch nichts zu lenken.

Warum die anderen falsch sind:

Nach Abschluss der Initiierungsphase: Zu diesem Zeitpunkt läuft das Lenken bereits in seiner zweiten Phase, da die Initiierung selbst erst freigegeben werden musste.

Bei der ersten Toleranzüberschreitung: Dies triggert nur eine Ausnahmeentscheidung (Exception), nicht den gesamten Lenkungsprozess.

Nach Erhalt des Projektmandats: Das Mandat startet erst den Prozess „Vorbereiten eines Projekts“ (Voraussetzung für die Kurzbeschreibung), noch nicht das Lenken.

☝️ Single Welcher Prozess definiert die Arbeit zur Lieferung der wichtigsten Produkte und stellt einen effektiven Ressourceneinsatz sicher?

❌ Steuern einer Phase

❌ Managen der Produktlieferung

✅ Initiieren eines Projekts

❌ Vorbereiten eines Projekts

„Initiieren eines Projekts“ schafft die Grundlagen, u. a. Pläne und Ansätze für einen effektiven Ressourceneinsatz.

Merksatz:
Der Initiierungs-Prozess legt das feste Fundament: Hier wird die eigentliche Arbeit für die wichtigsten Produkte (im Projektleitplan) verbindlich definiert und die Ressourcen dafür weise verplant.

Warum die anderen falsch sind:
Steuern einer Phase: Konzentriert sich nur auf die Überwachung und alltägliche Steuerung einer bereits laufenden Phase, nicht auf die Gesamtdefinition der Arbeit.
Managen der Produktlieferung: Regelt nur die konkrete Erstellung und Rückmeldung von Arbeitspaketen durch die Spezialistenteams.

Vorbereiten eines Projekts: Ist nur die erste, grobe Machbarkeitsprüfung („Sollte man überhaupt starten?“) vor der detaillierten Planung.

☝️ Single Was wird benötigt, um den Prozess „Managen eines Phasenübergangs“ durchzuführen?

❌ Jede Phase muss sich in einer Ausnahme befinden

❌ Das Projekt muss ein festes Enddatum haben

❌ Jede Phase muss inkrementell Nutzen liefern

✅ Die Projektarbeit muss in Abschnitte (Phasen) unterteilt sein

Der Prozess setzt voraus, dass das Projekt in mehrere Managementphasen unterteilt ist.

Merksatz:
Wo kein Übergang gebraucht wird, gibt es keine Phasen – nur wer seinen Weg in Abschnitte unterteilt, kann auch von einem zum nächsten übergehen.

Ausnahme-Zustand: Ein Phasenübergang ist der geplante Regelfall am Ende jeder Phase, keine Notfallreaktion auf Toleranzüberschreitungen.
Festes Enddatum: PRINCE2 steuert über Phasen, unabhängig davon, ob das Projektende flexibel oder starr definiert ist.

Inkrementeller Nutzen: Nutzen kann auch erst komplett am Projektende entstehen; Phasen dienen der Managementsteuerung, nicht zwingend der kontinuierlichen Produktlieferung.

☝️ Single Welche Maßnahme ist bei einem vorzeitigen Projektabschluss zu ergreifen?

✅ Der Projektmanager nutzt weiterhin den Prozess „Abschließen eines Projekts“, um die Situation zu handhaben

❌ Der Lenkungsausschuss finanziert den laufenden Betrieb aus dem Restbudget

❌ Es wird sofort ein neues Projekt gestartet

❌ Die offenen Arbeitspakete werden ohne Abnahme gelöscht

Auch bei vorzeitigem Abschluss wird der Prozess „Abschließen eines Projekts“ verwendet, um geordnet vorzugehen.

☝️ Single Was beschreibt einen Zweck des Prozesses „Managen der Produktlieferung“?

❌ Berichterstattung an den Lenkungsausschuss über den Phasenfortschritt

❌ Bewertung, ob das Projekt weiterhin lohnend ist

✅ Vereinbarung zwischen Projektmanager und Teammanager über zu liefernde Produkte

❌ Planung der nächsten Managementphase

Der Prozess regelt die kontrollierte Vereinbarung und Lieferung von Produkten zwischen Projekt- und Teammanager.

Merksatz:
Beim „Managen der Produktlieferung“ schütteln sich Projektmanager und Teammanager die Hände: Sie besiegeln den „Deal“ (das Arbeitspaket), damit die Produkte wie vereinbart erstellt werden.

Warum die anderen falsch sind:
Berichterstattung an den Lenkungsausschuss: Dies ist Aufgabe des Prozesses „Steuern einer Phase“, nicht der Teamebene.
Bewertung, ob das Projekt lohnend ist: Das geschieht fortlaufend in „Steuern einer Phase“ und beim Phasenübergang, nicht bei der reinen Produktlieferung.

Planung der nächsten Managementphase: Dies ist der Kern des Prozesses „Managen eines Phasenübergangs“.

☝️ Single Welcher Prozess stellt eine Schnittstelle zwischen dem Lenkungsausschuss und dem Projektmanager während der laufenden Phase bereit?

❌ Vorbereiten eines Projekts

✅ Steuern einer Phase

❌ Abschließen eines Projekts

❌ Managen der Produktlieferung

„Steuern einer Phase“ überwacht die laufende Phase und bildet die Schnittstelle zum Lenkungsausschuss.

Merksatz:
Der Projektmanager steuert die Phase am Steuerpult und funkt dabei direkt an den Lenkungsausschuss (Schnittstelle), um den Kurs zu halten.

Warum die anderen falsch sind:
Vorbereiten eines Projekts: Findet vor dem eigentlichen Projektstart statt, nicht während der laufenden Phase.
Abschließen eines Projekts: Wird erst am ganz am Ende des Projekts aktiv, um es geordnet zu beenden.

Managen der Produktlieferung: Ist die Schnittstelle zwischen Projektmanager und Teammanager, nicht zum Lenkungsausschuss.

☝️ Single Was beschreibt ein Projektmerkmal, das die Notwendigkeit des Prozesses „Abschließen eines Projekts“ begründet?

✅ Ein Projekt ist befristet und übergibt die Änderung an den laufenden Betrieb

❌ Ein Projekt hat ein hohes Maß an Unsicherheit

❌ Ein Projekt nutzt Ressourcen aus mehreren Abteilungen

❌ Ein Projekt wird mit einem neuen Team geliefert

Weil Projekte befristet sind, braucht es einen geordneten Abschluss und die Übergabe an den Betrieb (BAU).

Merksatz:
Ein Projekt ist wie ein befristeter Staffellauf: Am Ende muss der Stab (die Änderung) sauber an den laufenden Betrieb übergeben werden – sonst läuft niemand weiter.

Warum die anderen falsch sind:
Hohe Unsicherheit: Dies erfordert kontinuierliches Risikomanagement und Steuerung (z.B. „Lenken eines Projekts“), begründet aber nicht das gezielte, geordnete Projektende.
Ressourcen aus mehreren Abteilungen: Dies betrifft die organisationsübergreifende Koordination und Ressourcenplanung während der Durchführung, nicht den Abschluss.

Neues Team: Die Teamzusammenstellung erfordert Teambuilding und Führung, erzwingt aber keinen formalen Übergabeprozess am Projektende.

☝️ Single In welchem Prozess wird das Arbeitspaket zwischen Projektmanager und Teammanager vereinbart?

❌ Initiieren eines Projekts

✅ Managen der Produktlieferung

❌ Steuern einer Phase

❌ Managen eines Phasenübergangs

Die Annahme und Durchführung des Arbeitspakets erfolgt im Prozess „Managen der Produktlieferung“.

Merksatz:
Der Teammanager liefert die Arbeit ab – die Übergabe und Vereinbarung des Arbeitspakets erfolgt daher direkt an der Grenze zum Prozess „Managen der Produktlieferung“ (MP).

Warum die anderen falsch sind:
Initiieren eines Projekts: Hier wird das Projekt geplant und gestartet, noch keine konkreten Arbeitspakete an Teams vergeben.
Steuern einer Phase: Dies ist der Prozess des Projektmanagers; die eigentliche Vereinbarung und Annahme des Pakets findet jedoch auf der Teamebene in Managen der Produktlieferung statt.

Managen eines Phasenübergangs: Dieser Prozess dient dem Rückblick und der Planung der nächsten Phase, nicht der operativen Paketvereinbarung.

People – Menschen im Projekt

People-Element Einordnung [F] [People] 1 Unterseite →

☝️ Single Seit welcher Edition ist "People" ein eigenständiges Element von PRINCE2?

❌ Seit der ersten Version (1996)

❌ Seit der 6. Edition (2017)

❌ People war schon immer Teil von PRINCE2

✅ Seit der 7. Edition (2023)

Seit der 7. Edition (2023) — davor gab es nur Principles, Themes/Practices und Processes.

Merksatz:
PRINCE 7 krönt die People: Erst in der 7. Edition (2023) wird der Mensch (People) als eigenständiges, fünftes Element auf den PRINCE2-Thron gehoben.

Warum die anderen falsch sind:
A (1996): Damals herrschte rein starrer Prozess-Fokus ohne weiche Faktoren.
B (2017): Die 6. Edition betonte die Anpassbarkeit, noch ohne das separate "People"-Element.

C (immer Teil): Der Faktor Mensch war früher nur implizit in Rollen versteckt, nie ein eigenständiges Kernelement.

Warum People als eigenes Element [F] [People] 1 Unterseite →

☝️ Single Warum hat PeopleCert "People" als eigenständiges Element in Edition 7 eingeführt?

❌ Um sicherzustellen, dass die Methode auch weiterhin den Anforderungen internationaler Zertifizierungsstandards entspricht und dadurch die globale Anerkennung von PRINCE2 gestärkt wird.

❌ Um den wachsenden Einfluss agiler Arbeitsweisen aufzugreifen und die Integration von flexiblen Teamstrukturen in die klassische Projektmanagement-Methodik zu ermöglichen.

✅ Um anzuerkennen, dass Projekterfolg wesentlich von Menschen abhängt, nicht nur von Prozessen

❌ Um die Dokumentationspflichten zu vereinheitlichen und dadurch die Nachvollziehbarkeit von Entscheidungen in Projekten für externe Prüfinstanzen zu verbessern.

Um explizit anzuerkennen, dass Projekterfolg maßgeblich von Führung, Teamdynamik und Stakeholder-Engagement abhängt, nicht nur von Prozessen.

Merksatz: Ohne den Lokführer (Mensch) nützt die beste Schiene (Prozess) nichts – Erfolg braucht Köpfe, nicht nur Papier.

Warum die anderen falsch sind:
A: PRINCE2 definierte schon immer klare Rollen wie den Lenkungsausschuss.
B: Rechtliche Aspekte sind im Projektmanagement nur Randnotizen, kein Haupttreiber.

D: Prozesse wurden keineswegs abgeschafft, sondern bleiben das methodische Rückgrat.

Führung im Projekt [F] [People] 1 Unterseite →

☝️ Single Welche Aussage zur Führungsrolle im Projekt passt zum People-Element?

✅ Führung bedeutet, Motivation und Orientierung zu geben, nicht nur Aufgaben zu verteilen

❌ Führung bedeutet im People-Element, dass der Projektmanager alle Entscheidungen allein trifft und das Team nur ausführende Anweisungen erhält

❌ Führung im People-Element konzentriert sich darauf, dass der Executive die fachliche Arbeit des Teams vollständig übernimmt und steuert

❌ Führung ist im People-Element nicht erforderlich, da die Prozesse und Methoden die Zusammenarbeit automatisch regeln

Führung bedeutet, das Team zu motivieren und Orientierung zu geben — nicht nur Aufgaben zu verteilen.

Merksatz:
Ein wahrer Leader treibt Menschen mit Herz und Kompass an (Motivation und Orientierung), statt sie nur als leblose Zahnräder (Aufgabenverteiler) zu betrachten.

Führung ist irrelevant: Ignoriert völlig, dass Menschen („People“) ohne Führung ziellos sind und das Element genau darauf abzielt.
Strikte Kontrolle ohne Delegation: Widerspricht dem PRINCE2-Prinzip der „Steuerung nach Ausnahmeregelung“ und dem modernen Führungsverständnis.

Ausschließlich auf den Executive bezogen: Schließt fälschlicherweise den Projektmanager und die Teammanager aus, die ebenfalls aktiv führen müssen.

Stakeholder-Engagement [F] [People] 1 Unterseite →

☝️ Single Warum ist gezieltes Stakeholder-Engagement wichtig für ein Projekt?

❌ Weil PRINCE2 vorschreibt, dass Stakeholder-Engagement nur in der Initiierungsphase des Projekts durchgeführt werden muss, um die Anforderungen zu sammeln.

❌ Weil das gezielte Engagement von Stakeholdern laut PRINCE2 ausschließlich dem Senior Supplier obliegt, der alle Interessensgruppen vertritt.

❌ Weil Stakeholder-Engagement in PRINCE2 als optionale Aktivität definiert ist, die nur bei komplexen Projekten mit externen Partnern empfohlen wird.

✅ Weil übersehene Stakeholder ein Projekt gefährden können, selbst bei guter technischer Umsetzung

Weil unzufriedene oder übersehene Stakeholder ein Projekt gefährden können, selbst wenn die technische Umsetzung gut läuft.

Merksatz:
Der unsichtbare Stolperstein: Ein Projekt kann technisch perfekt fliegen, aber wenn ein übersehener Stakeholder die Landebahn blockiert, stürzt es trotzdem ab.

Warum die anderen falsch sind:
Optional: Stakeholder-Engagement ist in PRINCE2 über die Kernpraktik „Mensch“ fest vorgeschrieben und niemals freiwillig.
Einmalig zu Projektbeginn: Stakeholder-Interessen ändern sich ständig, weshalb die Einbindung ein kontinuierlicher Prozess über den gesamten Lebenszyklus ist.

Ausschließlich Senior Supplier: Das Engagement umfasst alle drei Stakeholder-Interessen (Business, User, Supplier) und nicht nur eine einzige Rolle.

Kommunikation im Projekt [F] [People] 1 Unterseite →

☝️ Single Was fordert das People-Element bezüglich Kommunikation?

❌ Kommunikation ist Aufgabe des Project Support allein

✅ Zielgruppengerechte Information statt Einheitskommunikation

❌ Kommunikation ist ausschließlich schriftlich zu führen

❌ Alle Beteiligten erhalten immer exakt dieselbe Information

Zielgruppengerechte Information — unterschiedliche Stakeholder brauchen unterschiedliche Informationen in unterschiedlicher Form.

Merksatz:
Menschen sind verschieden – serviere ihnen ein maßgeschneidertes Informations-Menü statt eines faden Einheitsbreis! (Zielgruppengerecht statt Gießkanne).

Project Support allein: Kommunikation ist Führungsaufgabe aller Rollen, nicht nur der Assistenz.
Ausschließlich schriftlich: Blockiert den agilen, persönlichen Austausch und wichtige informelle Kanäle.

Exakt dieselbe Information: Erzeugt Informationsüberlastung bei Stakeholdern, die nur spezifische Details benötigen.

Veränderung und Menschen [F] [People] 1 Unterseite →

☝️ Single Warum berücksichtigt PRINCE2 im People-Element auch, wie Menschen Veränderung erleben?

❌ Weil PRINCE2 davon ausgeht, dass Menschen Veränderungen immer rational und ohne Emotionen bewerten, weshalb nur technische Aspekte berücksichtigt werden müssen.

✅ Weil Projektveränderungen Widerstand/Unsicherheit auslösen können, was den Erfolg beeinflusst

❌ Weil das People-Element ausschließlich dazu dient, die Kommunikation mit externen Stakeholdern zu regeln, nicht aber die interne Betroffenheit der Mitarbeiter.

❌ Weil PRINCE2 Veränderungen nur dann berücksichtigt, wenn sie direkt die Projektkosten betreffen, und menschliche Reaktionen dabei keine Rolle spielen.

Weil Projekte oft Veränderungen mit sich bringen, die bei Betroffenen Widerstand oder Unsicherheit auslösen können — das beeinflusst den Projekterfolg.

Merksatz: Wer die Wellen der Angst ignoriert, bringt das Projektschiff zum Kentern – Menschen tragen den Wandel, also nimm ihre Unsicherheit mit an Bord!

Warum die anderen falsch sind:
A: Weil IT-Projekte kein Monopol auf menschliche Emotionen haben.
C: Weil Change-Management direkt im Projekt und nicht isoliert in der HR stattfindet.

D: Weil PRINCE2 Wandel aktiv gestaltet, statt ihn starr zu blockieren.

People-Element Inhalte [F] [People] 1 Unterseite →

✌️ Multi Welche Aspekte gehören inhaltlich zum People-Element? (Mehrfachauswahl)

❌ Ausschließlich Gehaltsabrechnung

✅ Zielgruppengerechte Kommunikation

✅ Stakeholder-Engagement

✅ Teamdynamik

Merksatz:
Menschen im Projekt führen bedeutet: Reden, Einbinden, Teamgeist finden! (Kommunikation, Stakeholder, Teamdynamik).

Warum die anderen falsch sind:

Ausschließlich Gehaltsabrechnung: Das ist eine reine HR-Verwaltungsaufgabe und klammert die zwischenmenschliche Führung komplett aus.

People-Element im eigenen Projekt [F] [People] 1 Unterseite →

☝️ Single Was kann im People-Element den Unterschied zwischen Projekterfolg und -misserfolg ausmachen?

✅ Frühzeitige, ehrliche Kommunikation und aktive Einbindung betroffener Stakeholder

❌ Eine vollständige und lückenlose Befolgung aller dokumentierten Prozessschritte und Verfahrensvorgaben

❌ Eine umfassende Information der betroffenen Personen erst nach Abschluss des gesamten Projekts

❌ Eine ausschließliche Fokussierung auf die technische Umsetzung ohne Berücksichtigung der Stakeholder

Gutes People-Management zeigt sich in frühzeitiger, ehrlicher Kommunikation und der aktiven Einbindung betroffener Stakeholder.

Merksatz:
"Wer Menschen mitnimmt und ehrlich spricht, führt das Projekt ins Rampenlicht – Stakeholder sind der Motor, nicht das Gepäck."

Warum die anderen falsch sind:
B: ... ignoriert den menschlichen Faktor durch starre Bürokratie.
C: ... erzeugt Widerstand durch vollendete Tatsachen statt Akzeptanz.

D: ... vergisst, dass Technik ohne Menschen wertlos ist.

People vs. Practices Abgrenzung [F] [People] 1 Unterseite →

☝️ Single Wie unterscheidet sich das People-Element grundsätzlich von den 7 Practices?

✅ Practices strukturieren WAS gemanagt wird, People betrifft WIE mit Menschen umgegangen wird

❌ People und Practices beschreiben beide denselben Steuerungsansatz, nur mit unterschiedlichen Begriffen für die gleichen Prozesse

❌ Das People-Element übernimmt sämtliche Aufgaben der Practices und macht diese dadurch überflüssig

❌ People ist als zusätzliche Practice in das bestehende Framework integriert und ergänzt die sieben bestehenden

Practices strukturieren WAS gemanagt wird (Business Case, Risk usw.), People betrifft WIE mit Menschen im Projekt umgegangen wird.

Merksatz: Die Practices sind die Werkzeuge im Kasten (WAS getan wird), während People die soziale Kompetenz zeigt, WIE wir die Werkzeuge gemeinsam nutzen.

Warum die anderen falsch sind:
B: Verkennt, dass die IPMA strikt zwischen Methoden (Practices) und Verhalten (People) unterscheidet.
C: Ignoriert, dass Verhalten (People) die Fachmethoden (Practices) sinnvoll ergänzt, statt sie zu löschen.

D: Übersieht, dass People ein eigenständiger, gleichwertiger Kompetenzbereich und keine Unter-Practice ist.

Diversität im Team [F] [People] 1 Unterseite →

☝️ Single Warum kann Vielfalt (Diversity) im Projektteam laut modernem Verständnis von Vorteil sein?

✅ Unterschiedliche Perspektiven können zu besseren, robusteren Entscheidungen führen

❌ Vielfalt im Team führt laut PRINCE2 zu einer unnötigen Komplexität, die die klaren Rollen und Verantwortlichkeiten verwässert und dadurch die Effizienz der Projektarbeit beeinträchtigt.

❌ Nach dem PRINCE2-Ansatz ist Vielfalt im Projektteam nicht relevant, da der Fokus ausschließlich auf standardisierten Prozessen und Methoden liegt, die unabhängig von Teammitgliedern funktionieren.

❌ Vielfalt im Projektteam wird von PRINCE2 als Risikofaktor betrachtet, weil unterschiedliche Meinungen und Arbeitsweisen die Einhaltung der vorgegebenen Projektpläne und Qualitätsstandards grundsätzlich erschweren.

Unterschiedliche Perspektiven können zu besseren Lösungen und robusteren Entscheidungen führen.

Merksatz: PRINCE2 ist ein Fundament, das sich auf Prozesse und Governance konzentriert. Es bewertet Vielfalt nicht als direkten Vorteil oder Nachteil für die Projektleistung, sondern überlässt dies der Projektmanagement-Organisation.

Warum die anderen falsch sind:
Unterschiedliche Perspektiven können zu besseren, robusteren Entscheidungen führen: Dies ist eine allgemeine Aussage zum Nutzen von Vielfalt, aber keine spezifische PRINCE2-Aussage über deren praktischen Nutzen im Kontext der Methode.
Vielfalt verlangsamt Projekte laut PRINCE2 grundsätzlich: PRINCE2 macht keine solche pauschale Aussage.

Das Thema ist für PRINCE2 irrelevant: PRINCE2 ist eine generische Methode, die sich nicht explizit zu jedem Aspekt der Teamdynamik äußert, was aber nicht bedeutet, dass es irrelevant ist, sondern dass es nicht im Fokus der Methode liegt.

Change Management für Menschen [F] [People] 1 Unterseite →

☝️ Single Was ist ein sinnvoller erster Schritt, um Mitarbeitende durch eine projektbedingte Veränderung zu begleiten?

✅ Frühzeitige, transparente Kommunikation über Gründe und Auswirkungen

❌ Eine frühzeitige und umfassende Information der Betroffenen sollte erst nach der endgültigen Entscheidung über den Projektumfang erfolgen, um Verunsicherung zu vermeiden.

❌ Die Kommunikation der Veränderung erfolgt am besten über ein formelles Rundschreiben, das die neuen Arbeitsabläufe verbindlich festlegt und keine Rückfragen zulässt.

❌ Die Details der Veränderung sollten bis zum offiziellen Projektabschluss vertraulich behandelt werden, um Spekulationen und Widerstände im Team zu unterbinden.

Frühzeitige, transparente Kommunikation über Gründe und Auswirkungen der Veränderung.

Merksatz:
Stell dir ein Schiff im Nebel vor: Nur wer frühzeitig die Scheinwerfer einschaltet (Transparenz), verhindert, dass die Crew aus Angst vor dem Unbekannten von Bord springt.

Warum die anderen falsch sind:
B): Erzeugt durch vollendete Tatsachen maximalen Widerstand und blockiert jede Akzeptanz.
C): Ignoriert die menschliche Komponente völlig und wirkt wie ein kaltes, motivierendes Diktat.

D): Schürt Existenzängste durch eine brodelnde Gerüchteküche und zerstört jegliches Vertrauen im Keim.

Projektinteressen [People] 1 Unterseite →

☝️ Single Welche drei primären Interessen müssen im Lenkungsausschuss vertreten sein?

❌ Finanzen, Personal und strategische Ausrichtung

❌ Qualität, Risiko und Fortschrittskontrolle

✅ Business, Nutzer (User) und Lieferant (Supplier)

❌ Auftraggeber, Anwender und Projektteam

PRINCE2 verlangt die Vertretung von Business-, User- und Supplier-Interessen im Board.

Merksatz:
Denke an den BUS, der das Projekt sicher ans Ziel steuert: Im Project Board sitzen Business (Geldgeber), User (Nutzer) und Supplier (Lieferant) gemeinsam in der ersten Reihe.

Warum die anderen falsch sind:
A) Fokussiert sich fälschlicherweise auf rein operative Abteilungen statt auf die universellen Projektrollen.
B) Verwechselt methodische Projektthemen und Prozesse mit den personellen Interessenvertretern.

D) Nennt formelle Unternehmens- und Mitbestimmungsorgane, die nicht die primären Projektperspektiven abbilden.

Rolle Executive [People] 1 Unterseite →

☝️ Single Wofür ist der Executive hauptverantwortlich?

✅ Für den Business Case und den Gesamterfolg des Projekts

❌ Für die Vertretung der reinen Nutzerinteressen

❌ Für die tägliche Erstellung der Produkte

❌ Für die administrative Unterstützung des Teams

Der Executive verantwortet den Business Case und hat den Vorsitz im Board.

Merksatz: Der Executive ist der „CEO des Projekts“: Er sitzt auf dem Geldbeutel (Business Case) und trägt die Krone für den Gesamterfolg.

Warum die anderen falsch sind:
B) Reine Nutzerinteressen vertritt der Senior User (Benutzervertreter).
C) Die tägliche Produkterstellung ist Aufgabe der Spezialisten und des Teammanagers.
D) Administrative Hilfe leistet die Projektunterstützung* (PMO), nicht der Lenkungsausschuss.

Rolle Senior User [People] 1 Unterseite →

☝️ Single Was verantwortet der Senior User?

❌ Die Leitung der Projektlenkungsausschusssitzungen und die Sicherstellung der Entscheidungsfähigkeit des Gremiums

❌ Die Steuerung der internen und externen Lieferantenressourcen sowie die Überwachung der Vertragserfüllung

❌ Die Einrichtung und Pflege der Projektadministration inklusive der Dokumentenlenkung und Berichtswesen

✅ Die Nutzeranforderungen und die Realisierung der Benefits

Der Senior User vertritt die Nutzer, spezifiziert Anforderungen und ist für die Benefits mitverantwortlich.

Merksatz:
Der Senior User ist der hungrige Nutzer am Tisch: Er bestellt das Essen (Anforderungen) und will, dass es ihm schmeckt (Benefits).

Warum die anderen falsch sind:
A: Den Vorsitz im Project Board führt der Auftraggeber (Executive).
B: Lieferantenressourcen stellt der Senior Supplier (Lieferantenvertreter) bereit.

C: Administrative Unterstützung ist die Aufgabe des Project Office (PMO).

Rolle Senior Supplier [People] 1 Unterseite →

☝️ Single Was verantwortet der Senior Supplier?

✅ Ressourcen und die fachliche Machbarkeit/Qualität der Lieferung

❌ Die Freigabe des Business Case und die damit verbundene Sicherstellung der Wirtschaftlichkeit des Projekts

❌ Die Vertretung der Nutzerinteressen sowie die Definition und Priorisierung der Anforderungen

❌ Die Genehmigung der Projekttoleranzen und die Festlegung der zulässigen Abweichungen

Der Senior Supplier vertritt die Ersteller der Produkte und sichert Ressourcen und Machbarkeit.

Merksatz:
Der Supplier ist der Super-Lieferant: Er liefert die Ressourcen und bürgt mit seinem Fach-Wissen für die Qualität der Lieferung.

Warum die anderen falsch sind:
B: Den Business Case gibt der Auftraggeber (Executive) frei, da er das Budget verantwortet.
C: Nutzerinteressen vertritt logischerweise der Senior User (Anwendervertreter).

D: Projekttoleranzen genehmigt das übergeordnete Lenkungsorgan (Lenkungsausschuss), nicht der Lieferant allein.

Project Board [People] 1 Unterseite →

☝️ Single Wer trifft im Lenkungsausschuss die letztlich bindende Entscheidung?

✅ Der Executive

❌ Der Senior Supplier

❌ Der Projektmanager

❌ Der Senior User

Das Board entscheidet gemeinsam, die letztlich bindende Entscheidung liegt beim Executive.

Merksatz:
Der Executive ist der „König“ des Project Boards: Er trägt die alleinige Gesamtverantwortung für den Projekterfolg und hat als Einziger das Zepter für das letzte, bindende Wort in der Hand.

Warum die anderen falsch sind:
B) Senior Supplier: Vertritt nur die Lieferantenseite bezüglich Ressourcen und Machbarkeit, besitzt aber keine finale Richtlinienkompetenz.
C) Project Manager: Leitet lediglich das operative Tagesgeschäft und ist dem Board unterstellt, darf also keine strategischen Letztentscheidungen treffen.

D) Senior User: Vertritt nur die Interessen der späteren Anwender und den Nutzen, hat jedoch nicht die finale Budget- und Entscheidungsgewalt.

Rolle Project Manager [People] 1 Unterseite →

☝️ Single Welche Aufgabe hat der Projektmanager?

✅ Das Projekt im Auftrag des Boards im Tagesgeschäft planen und steuern

❌ Die fachliche Erstellung der Projektergebnisse eigenverantwortlich übernehmen

❌ Die grundlegende Entscheidung über die Projektfinanzierung und den Investitionsumfang treffen

❌ Die Arbeit des Projektausschusses durch unabhängige Prüfungen und Berichte überwachen

Der Project Manager führt das Projekt im Rahmen der vom Board gesetzten Toleranzen.

Merksatz:
Der Project Manager ist der „Kapitän im Alltag“: Er steuert das Schiff (Projekt) täglich im Auftrag der Reeder (Project Board), packt aber nicht selbst im Maschinenraum an.

Warum die anderen falsch sind:

Produkte selbst erstellen: Das ist die Aufgabe der Spezialisten (Team Manager), nicht des koordinierenden Project Managers.

Strategische Investitionsentscheidung: Diese Macht liegt allein beim Project Board (Lenkungsausschuss) als Auftraggeber.

Board unabhängig kontrollieren: Die Kontrolle erfolgt umgekehrt (Board kontrolliert den Manager) oder durch die unabhängige Projektsicherung (Project Assurance).

Rolle Team Manager [People] 1 Unterseite →

☝️ Single Was ist zur Rolle des Teammanagers korrekt?

❌ Sie ist verpflichtend und übernimmt die vollständige Leitung des gesamten Projektteams

❌ Sie ist zwingend erforderlich und vertritt den Projektmanager bei allen Entscheidungen

✅ Sie ist optional und verantwortet die Erstellung zugewiesener Produkte

❌ Sie ist obligatorisch und berichtet direkt an das Lenkungsausschuss über alle Details

Der Team Manager ist optional; fehlt er, übernimmt der Project Manager dessen Aufgaben.

Merksatz: Der Team Manager ist wie ein optionaler Werkstattleiter: Er wird nur bei Bedarf geholt, um die bestellten Produkte in seiner Werkstatt fehlerfrei zusammenzubauen.

Warum die anderen falsch sind:
A: Ein Werkstattleiter ersetzt niemals den Gesamt-Projektleiter, der das große Ganze steuert.
B: Das Project Board (Lenkungsausschuss) wird vom Auftraggeber geleitet, nicht von der operativen Fachebene.

D: In kleinen Projekten kann der Projektmanager die Teamleitung einfach selbst übernehmen, weshalb sie nicht zwingend ist.

Project Assurance [People] 1 Unterseite →

☝️ Single Was kennzeichnet Project Assurance?

❌ Die kontinuierliche Bewertung der Wirtschaftlichkeit des Projekts durch den Projektmanager

❌ Die organisatorische und logistische Unterstützung des Projektmanagers bei der Projektsteuerung

✅ Unabhängige Überprüfung im Auftrag des Boards, getrennt vom Projektmanager

❌ Die direkte und eigenverantwortliche Führung der einzelnen Projektteams durch den Projektmanager

Project Assurance sichert unabhängig die Board-Interessen und darf nicht an den Project Manager delegiert werden.

Merksatz: Project Assurance ist der unabhängige „Projekt-TÜV“ im Auftrag des Vorstands (Boards) – er schaut dem Projektleiter neutral auf die Finger, ohne selbst mitzuarbeiten.

Warum die anderen falsch sind:
A) Business-Case-Entscheidungen trifft allein der Projektauftraggeber (Sponsor), nicht die Qualitätssicherung.
B) Administrative Unterstützung ist die klassische Aufgabe des PMO, nicht der unabhängigen Prüfung.

D) Die tägliche Teamleitung liegt in der operativen Verantwortung des Projektmanagers.

Change Authority [People] 1 Unterseite →

☝️ Single Welche Aufgabe hat eine Änderungsinstanz?

❌ Den Projektabschlussbericht erstellen und dem Projektvorstand zur Genehmigung vorlegen

❌ Die Projekttoleranzen für Zeit und Kosten eigenständig festlegen und anpassen

✅ Über Änderungsanträge innerhalb eines Änderungsbudgets entscheiden

❌ Die geplanten Projektergebnisse selbst erstellen und deren Qualität sicherstellen

Das Board kann Entscheidungen über Änderungen an eine Change Authority delegieren.

Merksatz:
Stell dir die Change Authority als „Schrankenwärter mit der Geldbörse“ vor: Sie sitzt direkt auf dem Änderungsbudget und entscheidet, welche Änderungsanträge passieren dürfen.

Warum die anderen falsch sind:
A: ... den Endbericht schreibt der Projektleiter am Projektende.
B: ... globale Projekttoleranzen legt der Lenkungsausschuss (Board) oder der Auftraggeber fest.

D: ... die Produkte werden von den Fachexperten im Team erstellt.

Project Support [People] 1 Unterseite →

☝️ Single Wofür ist Project Support zuständig?

✅ Administrative Unterstützung, z. B. Register, Konfiguration und Termine

❌ Die formale Genehmigung der Pläne für sämtliche Projektphasen

❌ Die Vertretung der Interessen aller externen Lieferanten im Projekt

❌ Die unabhängige Qualitätsprüfung im Auftrag des Projektausschusses

Project Support entlastet Project Manager und Teams administrativ.

Merksatz: Der Project Support ist die fleißige „Büro-Biene“ des Projekts: Sie ordnet die Akten (Register), pflegt den Kalender (Termine) und sortiert die Ablage (Konfiguration) – sie managt den Papierkram, entscheidet aber nichts.

Warum die anderen falsch sind:
B: Genehmigungen sind reine Lenkungsausschuss-Sache.
C: Lieferanteninteressen vertritt exklusiv der Senior Supplier.

D: Unabhängige Absicherung ist die Aufgabe der Project Assurance.

Trennung Assurance/Delivery [People] 1 Unterseite →

☝️ Single Warum darf Project Assurance nicht vom Projektmanager wahrgenommen werden?

❌ Weil Assurance eine reine Team-Manager-Aufgabe ist

❌ Weil der Projektmanager dafür keine Zeit hat

❌ Weil das Board Assurance grundsätzlich verbietet

✅ Weil Assurance unabhängig vom Tagesgeschäft prüfen muss

Assurance ist eine unabhängige Board-Funktion und muss von der Projektleitung getrennt sein.

Merksatz: Der Schiedsrichter spielt nicht selbst mit – nur ein unabhängiger Prüfer sieht das Spielfeld objektiv und ohne Betriebsblindheit.

Warum die anderen falsch sind:
A: Team-Manager liefern Arbeitspakete, statt die übergeordnete Qualität unabhängig zu sichern.
B: Zeitmangel ist ein reines Ressourcenproblem und kein strukturelles Rollenprinzip.

C: Das Board verbietet Assurance nicht, sondern benötigt sie zur eigenen Absicherung.

People-Element [People] 1 Unterseite →

☝️ Single Worauf legt das People-Element der 7. Edition besonderen Wert?

✅ Auf Führung, Kultur, Kommunikation und Change-Management

❌ Auf die strikte Einhaltung von Dokumentationsstandards und die Pflege zentraler Projektakten

❌ Auf die vollständige Eliminierung aller definierten Projektrollen zugunsten flexibler Teams

❌ Auf die Optimierung der technischen Umsetzung und die Qualität der gelieferten Produkte

PRINCE2 7 betont, dass Projekte durch Menschen und Verhalten gelingen, nicht durch Methode allein.

Merksatz:
Menschen (People) arbeiten nicht mit Papier, sondern miteinander: Sie brauchen einen Führer mit Kultur, der klar kommuniziert, um den Wandel (Change) zu meistern.

Warum die anderen falsch sind:
Reine Dokumentenverwaltung: PRINCE2 7 rückt den Menschen in den Fokus, nicht starre Bürokratie.
Abschaffung von Rollen: Rollen werden nicht abgeschafft, sondern durch die menschliche Dimension gestärkt und klarer definiert.
Technische Produktentwicklung:* Dies ist Aufgabe der Spezialistenteams und nicht der Kern des People-Elements, das auf Zusammenarbeit abzielt.

Ernennung Executive [People] 1 Unterseite →

☝️ Single Wer ernennt den Executive?

❌ Die Änderungsinstanz, die vom Projektvorstand eingesetzt wird und Änderungsanträge genehmigt, übernimmt die Ernennung des Executive als Teil ihrer Steuerungsaufgaben.

✅ Die beauftragende Ebene (Unternehmen, Programm oder Kunde)

❌ Der Senior Supplier, der die Lieferanteninteressen im Projektvorstand vertritt und für die Qualität der Lieferungen verantwortlich ist, ernennt den Executive aus seinem eigenen Bereich.

❌ Der Projektmanager, der für die tägliche Steuerung des Projekts zuständig ist und die Projektpläne überwacht, bestimmt den Executive als Teil seiner Personalverantwortung.

Die beauftragende Ebene steht über dem Projekt und ernennt den Executive.

Merksatz:
Der König (die übergeordnete Organisation) krönt den Kanzler (Executive), damit dieser das Reich (Projekt) regiert. Nur wer das Projekt beauftragt, hat die Macht, den Hauptverantwortlichen zu ernennen.

Change Authority: Ändert nur Projektdetails im laufenden Betrieb, besitzt aber keine Personalhoheit über die Projektleitung.
Senior Supplier: Vertritt nur die Lieferantenseite und ist dem Executive unterstellt, kann ihn also nicht ernennen.

Project Manager: Wird selbst erst vom Executive ernannt – der Angestellte kann nicht seinen eigenen Chef einstellen.

Stakeholder [People] 1 Unterseite →

☝️ Single Was ist ein Stakeholder im PRINCE2-Sinn?

✅ Jede Person/Gruppe, die das Projekt beeinflusst oder von ihm betroffen ist

❌ Nur die Mitglieder des Lenkungsausschusss, die alle Entscheidungen treffen

❌ Ausschließlich die Kunden, die das Projekt finanziell unterstützen

❌ Lediglich die Personen, die direkt an der Projektdurchführung beteiligt sind

Stakeholder sind alle, die ein Interesse am Projekt haben oder betroffen sind.

Merksatz:
Stell dir ein riesiges Lasso vor, das jeden einfängt, der aktiv am Projektseil zieht (beeinflusst) oder einfach nur im Weg steht und nass wird (betroffen ist).

Warum die anderen falsch sind:
B (Ausschließlich Project Board): Zu eng gedacht, da das Board nur die oberste Lenkungsebene darstellt.
C (Nur zahlende Kunden): Ignoriert alle internen Nutzer, Kritiker und Gesetzgeber, die ebenfalls betroffen sind.

D (Nur Lieferteam): Fokussiert sich fälschlicherweise nur auf die Macher, nicht auf die Empfänger des Projekts.

Rollen und Verantwortlichkeiten [People] 1 Unterseite →

☝️ Single Warum verlangt PRINCE2 klar definierte Rollen und Verantwortlichkeiten?

✅ Damit alle wissen, wer wofür zuständig ist und wer entscheidet

❌ Damit die Projektunterlagen ohne zusätzlichen Aufwand erstellt und gepflegt werden können

❌ Damit alle Projektbeteiligten in sämtliche Entscheidungsprozesse eingebunden werden

❌ Damit der Projektmanager die volle Kontrolle über alle fachlichen Inhalte behält

Klare Rollen sind ein PRINCE2-Prinzip und Voraussetzung für Steuerbarkeit.

Merksatz: Ein Orchester ohne Dirigenten und Notenblatt erzeugt nur Lärm – PRINCE2 verteilt die Instrumente und den Taktstock klar, damit jeder seinen Einsatz und seine Entscheidungsgewalt kennt.

Warum die anderen falsch sind:
B) Dokumentation wird durch klare Rollen nicht vermieden, sondern erst sauber strukturiert.
C) Mehr Personen bedeuten nur mehr Chaos, nicht mehr Effizienz.

D) Der Projektmanager entscheidet eben nicht alles allein, sondern arbeitet eng mit dem Lenkungsausschuss zusammen.

Führung und Management [People] 1 Unterseite →

☝️ Single Wie unterscheidet PRINCE2 7 Führung (Leadership) und Management?

❌ Management legt den Fokus auf Vision und Inspiration, während Führung operative Details überwacht

✅ Führung gibt Richtung und motiviert, Management plant und steuert konkret

❌ Führung und Management bezeichnen in PRINCE2 denselben Prozess der Entscheidungsfindung

❌ Management übernimmt die Rolle der Motivation, während Führung sich auf Kontrolle beschränkt

Das People-Element betont beide Aspekte als notwendig für Projekterfolg.

Merksatz:
Der Leader zeigt mit dem Kompass die Richtung und feuert das Team an, während der Manager die Route konkret plant und das Steuer lenkt.

Warum die anderen falsch sind:
A: Verwaltung ist das Gegenteil von visionärer, motivierender Führung.
C: Führung bewegt Menschen, Management strukturiert Prozesse – sie sind also keineswegs identisch.

D: Ohne Planung ist Management unmöglich, da Steuerung immer ein klares Ziel voraussetzt.

Kommunikation [People] 1 Unterseite →

☝️ Single Was regelt der Kommunikationsmanagement-Ansatz?

❌ Wie und wann die Projektprodukte erstellt und abgenommen werden

❌ Wie und wann finanzielle Mittel freigegeben und gebucht werden

✅ Wie und wann mit Stakeholdern kommuniziert wird

❌ Wie und wann Risiken identifiziert und bewertet werden

Er legt Methoden, Häufigkeit, Verantwortlichkeiten und Kanäle fest.

Merksatz:
Der Kommunikationsansatz ist der Sendeplan deines Projekt-Radios: Er bestimmt, wie und wann die Stakeholder auf Empfang gehen.

Warum die anderen falsch sind:
A: Die Produktherstellung regelt das Scope- und Qualitätsmanagement, nicht der Informationsfluss.
B: Budgetbuchungen gehören ins Kosten- und Finanzmanagement, wo Zahlen statt Worte zählen.

D: Die Risikobewertung ist Aufgabe des Risikomanagements zur reinen Gefahrenabwehr.

Organisationskultur [People] 1 Unterseite →

☝️ Single Warum betrachtet PRINCE2 7 das Organisationsökosystem und die Kultur?

✅ Weil Umfeld und Kultur den Projekterfolg maßgeblich beeinflussen

❌ Weil PRINCE2 7 sich primär auf technische Werkzeuge und Methoden konzentriert, die den Projekterfolg unabhängig vom Umfeld sicherstellen

❌ Weil die Unternehmenskultur für die Umsetzung von PRINCE2 7 keine Rolle spielt, da alle Projekte standardisiert ablaufen

❌ Weil die Prinzipien von PRINCE2 7 die kulturellen Aspekte vollständig abdecken und eine separate Betrachtung überflüssig machen

Das People-Element bezieht Kultur und Umfeld bewusst ein.

Merksatz:
Kultur ist der Nährboden, auf dem das Projekt wächst – ohne das richtige Ökosystem verdorrt selbst der beste Plan.

Warum die anderen falsch sind:
B) Reine Technik scheitert im Projektalltag ohne den Faktor Mensch.
C) Kultur prägt jede Zusammenarbeit und ist daher absolut erfolgskritisch.

D) Kultur ergänzt und unterstützt die PRINCE2-Prinzipien, statt sie zu ersetzen.

Veränderung und Betroffene [People] 1 Unterseite →

☝️ Single Worauf zielt das Change-Management im People-Element?

✅ Menschen durch Veränderung begleiten und Widerstände adressieren

❌ Verantwortliche Personen dazu zu bewegen, ihre Zustimmung für geplante Änderungen an Projektzielen zu erteilen

❌ Die Übertragung von Entscheidungsbefugnissen an das Projektteam für alle Änderungsanträge sicherzustellen

❌ Technische Anpassungen an bestehenden Projektplänen ohne formale Freigabe durchzuführen

People-Change meint das Begleiten der von der Veränderung betroffenen Menschen.

Merksatz:
Stell dir das "People"-Element wie einen Bergführer vor, der verängstigte Wanderer (Menschen) sicher durch einen Sturm (Veränderung) führt und ihre Ängste (Widerstände) aktiv abbaut – es geht um Empathie, nicht um Bürokratie.

Warum die anderen falsch sind:
B) Arbeitspakete zu vergeben ist reine Projektorganisation (Struktur) und vernachlässigt die menschliche Ebene.
C) Risiken zu übertragen ist ein rein vertragliches oder strategisches Werkzeug des Risikomanagements.

D) Baselines technisch zu ändern betrifft das formale Änderungsmanagement (Scope) und nicht die Betroffenen.

Teams [People] 1 Unterseite →

☝️ Single Was betont das People-Element zum Thema Teams?

❌ Die konsequente Vermeidung von Teamarbeit zugunsten individueller Einzelleistungen

❌ Die Bildung möglichst großer Teams zur Steigerung der Gesamtproduktivität

❌ Die bewusste Gestaltung von Teams ohne festgelegte Rollen und Verantwortlichkeiten

✅ Wirksame Zusammenarbeit, klare Rollen und Verantwortung im Team

Gut zusammenarbeitende Teams sind ein Schwerpunkt des People-Elements.

Merksatz:
Ein erfolgreiches Team ist wie ein eingespieltes Orchester: Jeder Musiker kennt seine Noten (klare Rollen), übernimmt die Verantwortung für sein Instrument und spielt harmonisch mit den anderen zusammen (wirksame Zusammenarbeit).

Warum die anderen falsch sind:
A: Ohne Zusammenarbeit existiert überhaupt kein echtes Team, sondern nur eine lose Gruppe von Einzelgängern.
B: Zu große Teams erzeugen nur Kommunikationschaos und verlangsamen Entscheidungen, statt die Effizienz zu steigern.

C: Ohne definierte Rollen weiß niemand, wer was tun soll, was unweigerlich zu Konflikten und Doppelarbeit führt.

People als integriertes Element [People] 1 Unterseite →

☝️ Single Warum wurde People in PRINCE2 7 zu einem eigenen Element?

❌ Weil die reine Einhaltung von Prozessen und Dokumenten als ausreichend für den Projekterfolg betrachtet wird

❌ Weil die Methode als vollständig selbsttragend angesehen wird und keine Anpassung an menschliche Bedürfnisse benötigt

❌ Weil die bisherigen Rollen als überflüssig erachtet wurden und durch standardisierte Abläufe ersetzt werden sollten

✅ Weil der menschliche Faktor als eigenständig erfolgskritisch anerkannt wird

In der 7. Edition ist People ein eigenes integriertes Element neben Prinzipien, Practices und Prozessen.

Merksatz: Ohne Menschen (People) bleibt jede Methode nur totes Papier – der „Faktor Mensch“ ist der lebendige Motor, der Projekte eigenständig zum Erfolg steuert.

Warum die anderen falsch sind:
A: Ignoriert, dass Menschen Dokumente erst mit Leben füllen und nicht umgekehrt.
B: Übersieht, dass die beste Methode ohne menschliche Akzeptanz und Zusammenarbeit scheitert.

C: Ist sachlich falsch, da Rollen weiterhin ein Kernbestandteil von PRINCE2 bleiben.

People – Menschen im Projekt [People] 18 Unterseite →

☝️ Single Was ist ein zentrales Merkmal der PRINCE2 7. Auflage?

❌ Abschaffung aller klassischen PRINCE2-Prinzipien

❌ Ausschließlicher Fokus auf Dokumentation und Prozesse

✅ Einführung eines „People-First“-Ansatzes

Eine wesentliche Neuerung in PRINCE2 7 ist der stärkere Fokus auf Menschen, Führung, Zusammenarbeit und Organisationskultur.

Merksatz:
Der Prinz (PRINCE2) trägt in der 7. Generation ein Herz auf der Krone: Der Mensch steht an erster Stelle („People-First“).

Warum die anderen falsch sind:
A: Weil bewährte Prinzipien das Fundament von PRINCE2 bleiben und nicht abgeschafft, sondern modernisiert werden.
B: Weil starre Bürokratie veraltet ist und die neue Auflage genau diesen einseitigen Fokus auf reine Dokumentation aufbricht.

☝️ Single Was ist laut diesem Abschnitt der Hauptgrund für das Scheitern von Projekten?

❌ Unzureichende technische Expertise und mangelndes Fachwissen im Projektteam

✅ Schlechtes Personalmanagement und schwache Teamdynamik

❌ Fehlen moderner Projektmanagement-Werkzeuge und unzureichende Tool-Unterstützung

Richtig. Missverständnisse, Konflikte und mangelnde Abstimmung zwischen Menschen sind die größten Ursachen für Scheitern.

Merksatz:
Projekte scheitern an Menschen, nicht an Maschinen – ohne Teamgeist und Führung blockiert das beste System.

Warum die anderen falsch sind:
A: Technisches Wissen lässt sich einkaufen, wohingegen zerrüttete Teams das Projekt von innen heraus blockieren.
C: Die besten Tools sind nutzlos, wenn die Menschen, die sie bedienen, nicht miteinander kommunizieren.

☝️ Single Was ist das „Geheimnis“ effektiver Zusammenarbeit?

❌ Eine klare Hierarchie und eindeutige Weisungsbefugnis der Projektleitung

✅ Gemeinsame Verantwortung und Vertrauen unter den Teammitgliedern

❌ Eine Minimierung des Informationsaustauschs zur Vermeidung von Störungen

Richtig. Zusammenarbeit gedeiht, wenn Menschen sich vertraut und für Ergebnisse verantwortlich fühlen.

Merksatz:
Ein starkes Team ist wie ein Trapez-Duo im Zirkus: Sie fliegen nur sicher durch blindes Vertrauen und die gemeinsame Verantwortung für den Fang.

Warum die anderen falsch sind:
A) Weniger Kommunikation verhindert keine Verwirrung, sondern erzeugt gefährliche Informationslücken.
C) Strikte Kontrolle erstickt die nötige Eigeninitiative und zerstört das Vertrauen im Team.

☝️ Single Was unterscheidet Führung (Leadership) von Management in Projekten?

❌ Führung ist ausschließlich für die strategische Ebene vorgesehen, während Management sich auf operative Tätigkeiten beschränkt

❌ Management stellt die übergeordnete Disziplin dar, die Führung als Teilbereich für die Personalführung integriert

✅ Führung konzentriert sich auf Vision und Menschen, Management auf die Umsetzung

Richtig. Führung inspiriert und gibt Orientierung, während Management organisiert und steuert.

Merksatz:
Der Leader zeigt den Weg zum Horizont (Vision & Menschen), während der Manager die Straße dorthin asphaltiert (Umsetzung).

Warum die anderen falsch sind:
A: Ignoriert, dass beide Disziplinen gleichwertig sind und sich je nach Situation ergänzen müssen.
B: Übersieht, dass Führung (z. B. laterale Führung) auf allen Projektebenen stattfinden kann.

☝️ Single Was beschreibt eine gesunde Projektkultur am besten?

✅ Offene Kommunikation, psychologische Sicherheit und kontinuierliche Verbesserung

❌ Ein Umfeld, das Fehler sanktioniert und eine lückenlose Dokumentation von Verantwortlichkeiten fordert

❌ Eine Arbeitsweise, die Konflikte frühzeitig unterbindet und Harmonie über fachliche Diskussionen stellt

Richtig. Diese Elemente schaffen Vertrauen, Lernen und hohe Leistungsfähigkeit.

Merksatz:
Eine gesunde Projektkultur ist wie ein stabiles Sicherheitsnetz: Man spricht offen über Fehler, um gemeinsam besser zu werden.

Warum die anderen falsch sind:
B) Schuldzuweisungen erzeugen Angst und blockieren die Weiterentwicklung.
C) Konfliktvermeidung führt zu Scheinharmonie und staut Probleme nur auf.

☝️ Single Was sind die drei primären Projektinteressen (Stakeholder-Perspektiven) in PRINCE2?

❌ Zeit, Kosten und Qualität als die drei zentralen Steuerungsgrößen eines Projekts, die in PRINCE2 als gleichwertige Erfolgskriterien für die Projektsteuerung definiert sind.

✅ Business, Anwender (User), Lieferant (Supplier)

❌ Risiko, Umfang und Nutzen als die drei wesentlichen Perspektiven, die in PRINCE2 zur Bewertung des Projekterfolgs aus Sicht der Auftraggeber herangezogen werden.

Richtig – PRINCE2 stellt sicher, dass alle drei Perspektiven vertreten sind.

Merksatz:
Stell dir den PRINCE auf seinem Thron vor, der drei Berater braucht: Den Business-Mann (der zahlt), den Anwender (der die Krone trägt) und den Lieferanten (der sie schmiedet) – das magische PRINCE2-Trio!

Warum die anderen falsch sind:
A) Verwechselt die Steuerungsgrößen des klassischen „Magischen Dreiecks“ mit den beteiligten Personengruppen.
C) Beschreibt abstrakte Projektvariablen und Nutzenaspekte anstelle von konkreten Stakeholder-Rollen.

☝️ Single Was ist die Hauptverantwortung des Lenkungsausschuss (Lenkungsausschuss)?

❌ Die täglichen Arbeitspakete zu koordinieren und operative Einzelheiten zu überwachen

✅ Die übergeordnete Richtung vorzugeben und wichtige Entscheidungen zu treffen

❌ Die konkreten Projektergebnisse eigenständig zu erstellen und abzunehmen

Richtig – das Project Board ist für die Governance und zentrale Entscheidungen verantwortlich.

Merksatz: Der Lenkungsausschuss ist das Lenkrad des Projekts: Er bestimmt die übergeordnete Richtung und trifft die großen Weichenentscheidungen, während andere im Maschinenraum arbeiten.

Warum die anderen falsch sind:
A) Tägliches Management ist die operative Aufgabe des Projektleiters, nicht des strategischen Gremiums.
C) Technische Ergebnisse liefern die Fachexperten im Projektteam, nicht die Lenker im Ausschuss.

☝️ Single Was ist die Hauptverantwortung des Executive in PRINCE2?

✅ Eigentümer des Business Case zu sein und dessen Gültigkeit sicherzustellen

❌ Die fachliche Leitung der Projektteams zu übernehmen und die Einhaltung der Projektmethodik sicherzustellen

❌ Die Erstellung und Zuweisung von Arbeitspaketen an die Projektmitarbeiter zu verantworten

Richtig – der Executive stellt sicher, dass das Projekt tragfähig bleibt.

Merksatz: Der Executive ist der „Eigentümer“ mit dem Euro-Koffer: Er wacht als oberster Entscheider über den Business Case, damit das Projekt stets rentabel bleibt.

Warum die anderen falsch sind:
B) Verwechselt die strategische Lenkung des Executives mit der operativen Teamführung durch den Projektmanager.
C) Verwechselt die wirtschaftliche Gesamtverantwortung des Executives mit der detaillierten Paket-Erstellung durch den Projekt- oder Teammanager.

☝️ Single Welche Rolle hat die Project Assurance?

✅ Unabhängig zu prüfen, ob das Projekt ordnungsgemäß gemanagt wird

❌ Die Projekt Assurance übernimmt die operative Steuerung aller Projektaktivitäten und trifft eigenständig Entscheidungen zur Zielerreichung.

❌ Die Projekt Assurance ist verantwortlich für die tägliche Koordination und Zuweisung aller Arbeitspakete an die einzelnen Teammitglieder.

Richtig – Project Assurance liefert eine unabhängige, unvoreingenommene Sichtweise.

Merksatz:
Die Project Assurance ist der neutrale „Projekt-TÜV“: Sie schraubt nicht selbst am Auto, sondern prüft unabhängig von außen, ob alles vorschriftsmäßig läuft.

Warum die anderen falsch sind:
B) ...weil man die unabhängige Überwachung fälschlicherweise mit dem aktiven, operativen Risikomanagement der Projektleitung verwechselt.
C) ...weil die Aufgabenverteilung eine direkte Führungsaufgabe des Projektleiters ist und nicht zur Qualitätssicherung gehört.

☝️ Single Was ist die beste Vorgehensweise bei einem Rollenkonflikt in einem PRINCE2-Projektteam?

✅ Rollen und Verantwortlichkeiten klar definieren

❌ Den Konflikt ignorieren

❌ Beide Rollen sich ohne Klärung überschneiden lassen

Richtig – Klarheit verhindert Doppelarbeit und Konflikte.

Merksatz:
Ein Prinz (PRINCE2) braucht klare Grenzen: Nur ein scharf gezogener Zaun (Rollendefinition) verhindert den Revierkampf im Schlossgarten.

Warum die anderen falsch sind:
B): Ignorieren vergrößert den Konflikt nur, statt ihn an der Wurzel zu lösen.
C): Ungeklärte Überschneidungen erzeugen nur Chaos und ineffiziente Doppelarbeit.

☝️ Single Was ist bei Anwendung der Ausschlusstechnik in einer PeopleCert-Prüfung der BESTE erste Schritt?

❌ Die längste Antwort auswählen

❌ Bei Unsicherheit sofort raten

✅ Eindeutig falsche Optionen entfernen

Das Ausschließen offensichtlich falscher Antworten erhöht die Wahrscheinlichkeit, die richtige Antwort zu wählen.

Merksatz:
Wer den Müll zuerst rausbringt, sieht den Schatz sofort – feg bei der Ausschlusstechnik zuerst die faulen Eier (eindeutig falsche Optionen) vom Tisch, um freie Sicht auf die richtige Antwort zu haben.

Warum die anderen falsch sind:
A (Längste Antwort): Ein bloßer Längenvergleich verleitet zu Scheinsicherheit, da auch lange Antworten inhaltlich komplett falsch sein können.
B (Sofort raten): Überstürztes Raten senkt deine Erfolgschance, während systematisches Eliminieren die Trefferwahrscheinlichkeit mathematisch massiv erhöht.

☝️ Single Was sollte ein Projektmanager tun, wenn der Business Case während einer Krise ungültig wird?

❌ Das Projekt fortsetzen, um bereits eingesetzte Ressourcen nicht zu verschwenden

❌ Das Problem bis zur nächsten Phasengrenze ignorieren

✅ Das Problem an das Lenkungsausschuss zur Entscheidung eskalieren

Der Project Manager muss an das Project Board eskalieren, das entscheidet, ob das Projekt fortgesetzt, geändert oder gestoppt wird.

Merksatz: Wenn das Fundament (Business Case) brennt, rettet der Projektleiter nicht blind die Steine, sondern ruft sofort die Eigentümer (Project Board) zur Lösch- oder Abbruchentscheidung.

Warum die anderen falsch sind:
A ist falsch: Ein klassischer Denkfehler („Sunk Cost Fallacy“), bei dem man aus falschem Stolz weiteres Geld in ein bereits sinnloses Projekt steckt.
B ist falsch: Diese Vogel-Strauß-Taktik verschwendet wertvolle Zeit und vergrößert den finanziellen Schaden bis zur nächsten Phase massiv.

☝️ Single Was ist der PRIMÄRE Fokus der Praxis People (Menschen) in PRINCE2 7?

❌ Die präzise Überwachung und Steuerung von Projektzeitplänen und Meilensteinen sicherzustellen

❌ Die detaillierte Kontrolle und Überwachung der Projektkosten und des Budgets zu gewährleisten

✅ Effektive Zusammenarbeit, Führung und Stakeholder-Engagement zu ermöglichen

Die Praxis „People“ betont Führung, Kommunikation, Teamdynamik und Stakeholder-Engagement.

Merksatz:
Bei „People“ denkst du an ein starkes Team, das sich die Hände reicht (Zusammenarbeit), geführt von einem Kapitän (Führung), während die Zuschauer (Stakeholder) klatschen – Menschen bewegen Menschen, keine Tabellen.

Warum die anderen falsch sind:
A ist falsch, weil Termine und Zeitpläne in die Praxis „Pläne“ gehören.
B ist falsch, weil die Budget- und Kostensteuerung eine reine Finanzaufgabe (Business Case/Fortschritt) ist.

☝️ Single Wann sollte ein Projektmanager einen direktiven (befehlenden) Führungsstil anwenden?

❌ Wenn in einer Krisensituation schnelle Entscheidungen erforderlich sind, weil das Team keine klaren Vorgaben hat

✅ Wenn in einer Krisensituation schnelle Entscheidungen erforderlich sind

❌ Wenn in einer Krisensituation schnelle Entscheidungen erforderlich sind, um die Projektziele zu sichern

Ein direktiver Stil ist in dringenden oder stark belasteten Situationen angebracht, in denen schnelle Entscheidungen nötig sind.

Merksatz:
Wenn die Hütte brennt (Krise), diskutiert die Feuerwehr nicht, sondern der Kommandant befiehlt – Direktiver Stil rettet das Projekt in der Not.

Warum die anderen falsch sind:
A ist falsch: Erfahrene Teams benötigen Vertrauen und Delegation statt starrer Befehle, da Direktive sie demotiviert.
C ist falsch: Stakeholder-Kommunikation ist ein organisatorischer Prozess und hat nichts mit dem Führungsstil gegenüber dem Projektteam zu tun.

☝️ Single Was ist der Zweck einer Stakeholder-Engagement-Strategie (Kommunikationsraster)?

❌ Die Priorisierung und zeitliche Planung aller Projektaktivitäten zur Sicherstellung der termingerechten Lieferung der Projektergebnisse festzulegen.

✅ Festzulegen, wie und wann Stakeholder eingebunden und mit ihnen kommuniziert wird

❌ Die Verantwortlichkeiten und Befugnisse der Projektleitung zur Entscheidungsfindung innerhalb des Projekts zu definieren.

Das Kommunikationsraster stellt effektives Stakeholder-Engagement sicher, indem es Kommunikationsmethoden, Häufigkeit und Verantwortlichkeiten festlegt.

Merksatz:
Stell dir die Stakeholder-Strategie wie einen Sendeplan vor: Er regelt, wie und wann die Zuschauer (Stakeholder) eingeschaltet werden, damit das Projekt ein Einschaltquoten-Hit wird.

Warum die anderen falsch sind:
A: Risiken werden im Risikomanagement analysiert, nicht im Kommunikationsraster.
C: Die Verteilung technischer Aufgaben ist Teil der Projektstrukturierung und Arbeitspakete, nicht der Stakeholder-Einbindung.

☝️ Single Was ist die WIRKSAMSTE Methode, um Widerstand gegen Veränderungen in einem Projekt zu begegnen?

❌ Stakeholder erst nach Abschluss der Planungsphase informieren und ihnen die endgültigen Entscheidungen präsentieren

✅ Stakeholder frühzeitig einbinden und auf ihre Bedenken eingehen

❌ Widerstände durch strikte Einhaltung der Projektvorgaben und klare Anweisungen von oben minimieren

Frühzeitige Einbindung und das Eingehen auf Bedenken schaffen Vertrauen und Zustimmung und verringern Widerstand.

Merksatz:
Wer im selben Boot mitrudert, bohrt keine Löcher in den Rumpf – binde Betroffene frühzeitig ein, um sie zu Mitstreitern der Veränderung zu machen.

Warum die anderen falsch sind:
A: Ignorieren lässt den Widerstand im Verborgenen gefährlich anwachsen.
C: Zwang erzeugt nur Schein-Compliance und führt zu passivem Boykott.

☝️ Single Was ist ein ZENTRALER Faktor beim Aufbau leistungsstarker Teams (High-Performance Teams) in PRINCE2?

❌ Feedback vermeiden, um Konflikte zu verhindern

❌ Strikte Kontrolle mit minimaler Eigenständigkeit

✅ Klare Rollen, Vertrauen und effektive Kommunikation

Leistungsstarke Teams gedeihen durch Klarheit, Vertrauen, Zusammenarbeit und offene Kommunikation.

Merksatz:
Ein High-Performance-Team ist wie ein eingespieltes Orchester: Jeder kennt seine Rolle, vertraut den Mitspielern und kommuniziert harmonisch im Takt.

Warum die anderen falsch sind:
A: Ohne Feedback gibt es keine Weiterentwicklung, sondern nur ungelöste, schwelende Konflikte.
B: Mikromanagement erstickt jegliche Motivation und blockiert die nötige Eigenverantwortung eines Spitzenteams.

☝️ Single Was ist die PRIMÄRE Rolle eines Benefit Owner in PRINCE2?

✅ Sicherzustellen, dass der Nutzen nach der Projektlieferung realisiert wird

❌ Sicherzustellen, dass die Projektlieferung termingerecht und im geplanten Umfang erfolgt

❌ Sicherzustellen, dass alle Projektrisiken während der Laufzeit aktiv überwacht und gesteuert werden

Ein Benefit Owner ist dafür verantwortlich, die Nutzenrealisierung zu verfolgen und sicherzustellen, oft nach Projektende.

Merksatz: Der Benefit Owner ist wie ein „Erntehelfer“: Er sät nicht das Feld (Projekt), sondern sorgt dafür, dass nach der Ernte (Lieferung) die Früchte (Nutzen) tatsächlich im Korb landen.

Warum die anderen falsch sind:
B) ...weil die Zeitplanung die operative Aufgabe des Projektmanagers ist.
C) ...da das Risikomanagement in der Gesamtverantwortung der Projektleitung liegt.

Schlüsselkonzepte

7 Performance-Ziele [F] [Konzepte] 1 Unterseite →

☝️ Single Welches Performance-Ziel ist NEU in der 7. Edition (zusätzlich zu den bisherigen 6)?

✅ Sustainability

❌ Risk

❌ Quality

❌ Costs

Sustainability wurde als 7. Performance-Ziel neu eingeführt.

Merksatz:
Die 7te Generation denkt grün: Das neue siebte Ziel ist Sustainability (Nachhaltigkeit), damit dem Projekt auch in Zukunft nicht die Puste ausgeht.

Warum die anderen falsch sind:
Risk: ...ist als Risikomanagement schon seit Jahrzehnten ein Standard-Fokus.
Quality: ...gehört als Qualitätsanspruch zum uralten Fundament des Projektmanagements.

Costs: ...ist als Budgetfaktor der klassischste aller Parameter und keineswegs neu.

Performance-Ziele Zweck [F] [Konzepte] 1 Unterseite →

☝️ Single Wofür dienen die Performance-Ziele (Costs, Timescales, Quality, Scope, Risk, Benefits, Sustainability)?

✅ Sie geben Bewertungsdimensionen für den Projekterfolg vor

❌ Sie dienen als verbindliche Vorgaben für die Projektbuchhaltung und ersetzen die Notwendigkeit einer separaten Kostenkontrolle im Projektmanagement.

❌ Sie sind ausschließlich auf IT-Projekte ausgerichtet und haben für andere Projekttypen wie Bau- oder Organisationsprojekte keinerlei Relevanz.

❌ Sie machen die Erstellung eines Business Case überflüssig, da die Performance-Ziele bereits alle wirtschaftlichen Aspekte des Projekts abdecken.

Sie geben Bewertungsdimensionen vor, anhand derer der Projekterfolg gemessen wird.

Merksatz: Stell dir die sieben Performance-Ziele wie die sieben Säulen eines Tempels vor, die gemeinsam das Dach des „Projekterfolgs“ tragen und messbar machen.

Warum die anderen falsch sind:
B: ...da diese universellen Steuerungsgrößen für jede Art von Projekt gelten, nicht nur für IT.
C: ...weil Dimensionen wie Qualität, Risiko und Nachhaltigkeit weit über reine Finanzdaten hinausgehen.

D: ...da sie den Business Case mit konkreten Messgrößen füllen, statt ihn überflüssig zu machen.

Sustainability als Performance-Ziel [F] [Konzepte] 1 Unterseite →

☝️ Single Wie lässt sich Sustainability als Performance-Ziel in einem Projekt operationalisieren?

✅ Durch messbare Toleranzgrenzen, z. B. für den CO2-Fußabdruck des Projekts

❌ Durch die reine Einhaltung gesetzlicher Mindestanforderungen zum Umweltschutz ohne weitere interne Vorgaben

❌ Durch die einmalige Erstellung eines Nachhaltigkeitsberichts am Projektende ohne laufende Überwachung

❌ Durch die alleinige Festlegung von qualitativen Zielen wie einer verbesserten Umweltbilanz ohne quantitative Messgrößen

Sustainability wird operationalisiert, indem messbare Toleranzgrenzen (z. B. CO2-Fußabdruck) definiert und überwacht werden.

Merksatz: Nachhaltigkeit braucht ein grünes Maßband: Nur wer feste CO2-Toleranzgrenzen zieht, steuert das Projekt sauber ins Ziel.

Warum die anderen falsch sind:
B) ... da reiner Profit die ökologische und soziale Dimension von Nachhaltigkeit ignoriert.
C) ... weil PRINCE2 Nachhaltigkeit explizit als siebte Leistungsdimension mit messbaren Toleranzen definiert.

D) ... da unverbindliche Absichten ohne konkrete Kennzahlen kein steuerbares Projektziel darstellen.

Management Products Übersicht [F] [Konzepte] 1 Unterseite →

☝️ Single Was sind "Management Products" bei PRINCE2?

❌ Die an den Kunden übergebenen Endprodukte, die den Projektnutzen sicherstellen

❌ Ein anderer Begriff für die fachlichen Ergebnisse der Projektarbeit

❌ Nur die Dokumente, die die finanziellen Mittel des Projekts darstellen

✅ Dokumente zur Steuerung des Projekts, nicht die eigentlichen Ergebnisse

Dokumente, die zur Steuerung des Projekts erstellt werden (z.B. PID, Highlight Report) — nicht die eigentlichen Projektergebnisse.

Merksatz:
Management Products sind das Steuerrad und die Navi-Karten des Projektleiters – sie lenken und verwalten die Reise, sind aber nicht das eigentliche Urlaubsziel (Spezialistenprodukt).

Warum die anderen falsch sind:
Kunden-Endprodukte: Dies sind Specialist Products (die eigentlichen Lieferergebnisse wie eine Software oder ein Gebäude), nicht die Verwaltungsdokumente.
Synonym für Specialist Products: Falsch, da PRINCE2 strikt zwischen steuernden Managementprodukten (z. B. Business Case) und den zu erstellenden Spezialistenprodukten trennt.

Ausschließlich Finanzdokumente: Zu stark eingeschränkt; sie umfassen sämtliche Steuerungs- und Kommunikationsmittel wie Pläne, Berichte und Register, nicht nur Finanzen.

Configuration Item Records [F] [Konzepte] 1 Unterseite →

☝️ Single Wofür werden "Configuration Item Records" genutzt?

✅ Um Status und Historie einzelner Produkte nachvollziehbar zu dokumentieren

❌ Um eine vollständige und aktuelle Übersicht aller offenen Risiken im Projekt zu gewährleisten

❌ Um die Einhaltung gesetzlicher Vorschriften zur Datenspeicherung in IT-Systemen sicherzustellen

❌ Um die Kosten für die Nutzung von Projektressourcen zentral zu erfassen und zu kontrollieren

Um den Status und die Historie einzelner Produkte/Konfigurationselemente nachvollziehbar zu dokumentieren.

Merksatz:
Die Configuration Item Records sind der „Lebenslauf“ eines Produkts – sie dokumentieren lückenlos seine Geburt (Erstellung), seine Entwicklung (Status) und seine Vergangenheit (Historie).

Warum die anderen falsch sind:
Ersatz für das Risk Register: Risiken bedrohen das Projekt und werden im Risk Register gemanagt, während Records rein produktbezogene Daten erfassen.
Nur bei Softwareprojekten relevant: PRINCE2 ist universell; jedes physische oder immaterielle Produkt benötigt diese Nachverfolgbarkeit.

Ausschließlich zur Gehaltsabrechnung: Die Personalverwaltung hat nichts mit dem Status von Projektprodukten zu tun.

Management Products Beispiele [F] [Konzepte] 1 Unterseite →

✌️ Multi Welche der folgenden sind typische PRINCE2 Management Products? (Mehrfachauswahl)

✅ Projektstatusbericht

❌ Jahresabschluss des Unternehmens

✅ Project Initiation Documentation (PID)

✅ Risikoregister

Merksatz:
Der PRINCE startet sein Projekt mit der PID (Initiierung), steuert Gefahren im Risk Register und glänzt regelmäßig im Highlight Report (Fortschrittsbericht).

Warum die anderen falsch sind:

B) Jahresabschluss des Unternehmens: Ist ein Instrument der permanenten Linienorganisation (Finanzwesen) und kein temporäres Steuerungsprodukt eines einzelnen Projekts.

Baseline Management Products [F] [Konzepte] 1 Unterseite →

☝️ Single Was bedeutet es, wenn ein Management Product "baselined" (freigegeben/fixiert) wurde?

✅ Es wurde formal genehmigt und dient als Referenzpunkt für weitere Änderungen

❌ Nach der Freigabe kann das Management Product ohne weitere formale Schritte jederzeit direkt angepasst werden, um aktuelle Anforderungen zu berücksichtigen.

❌ Die Fixierung eines Management Products ist ausschließlich für technische Dokumente wie Spezifikationen oder Pläne relevant, nicht für andere Projektunterlagen.

❌ Ein baselined Management Product wird nach der Freigabe nicht mehr benötigt und kann daher aus dem Projektarchiv endgültig entfernt werden.

Es wurde formal genehmigt und dient ab dann als Referenzpunkt — Änderungen müssen über einen formalen Prozess laufen.

Merksatz:
Die „Baseline“ ist wie ein Betonfundament: Einmal gegossen (formal genehmigt), steht es felsenfest als stabiler Referenzpunkt. Wer daran rütteln oder etwas ändern will, braucht einen offiziellen Änderungsantrag (Change Control).

Warum die anderen falsch sind:
Beliebig ändern: Widerspricht dem Kontrollgedanken, da jede Änderung nach der Freigabe einen formellen Prozess durchlaufen muss.
Nur technische Dokumente: Ein fataler Irrtum, da auch Business Cases, Pläne und andere nicht-technische Management-Produkte baselined werden.

Endgültig gelöscht: Das Gegenteil ist der Fall – es wird für die zukünftige Steuerung und als historischer Bezugspunkt sicher aufbewahrt.

Corporate/Programme Management [F] [Konzepte] 1 Unterseite →

☝️ Single In welchem Verhältnis steht ein PRINCE2-Projekt typischerweise zu "Corporate/Programme Management"?

❌ Das Projekt ist vollständig unabhängig und folgt ausschließlich den eigenen Zielen ohne Abstimmung mit übergeordneten Ebenen

❌ Die Verbindung zu Corporate Management wird in PRINCE2 als optional betrachtet und hat keinen Einfluss auf die Projektsteuerung

❌ Corporate Management übernimmt die Rolle des Projektausschusses und trifft alle Entscheidungen im Projekt allein

✅ Das Projekt ist in einen übergeordneten Rahmen mit Vorgaben eingebettet

Das Projekt ist eingebettet in einen übergeordneten Rahmen, der Vorgaben (z.B. Standards, Berichtspflichten) setzt.

Merksatz:
Ein PRINCE2-Projekt ist kein einsamer Wolf, sondern ein Bild im Rahmen: Das „Corporate/Programme Management“ liefert den äußeren Rahmen (Vorgaben und Toleranzen), in dem sich das Projekt sicher bewegt.

Warum die anderen falsch sind:
Keinerlei Verbindung: Ein Projekt existiert nie im luftleeren Raum, sondern benötigt strategische Ausrichtung und Autorisierung von oben.
Nicht relevant: Der Begriff ist essenziell, da von dort der Lenkungsausschuss (Project Board) seine Mandate und die Projektbegründung erhält.

Ersetzt das Project Board vollständig: Das Corporate Management delegiert die direkte Projektsteuerung an das Project Board, statt es zu ersetzen.

Projektdefinition PRINCE2 [F] [Konzepte] 1 Unterseite →

☝️ Single Wie definiert PRINCE2 grundsätzlich ein "Projekt"?

❌ Eine dauerhafte Organisationseinheit, die wiederkehrende Aufgaben zur Aufrechterhaltung des Geschäftsbetriebs übernimmt

❌ Eine fest etablierte Abteilung, die kontinuierlich standardisierte Produkte und Dienstleistungen für interne Kunden bereitstellt

❌ Eine rein technische Initiative, die sich ausschließlich auf die Implementierung neuer Software oder Systeme konzentriert

✅ Eine temporäre Organisation zur Lieferung von Business-Produkten gemäß Business Case

Eine temporäre Organisation, geschaffen, um ein oder mehrere Business-Produkte gemäß vereinbartem Business Case zu liefern.

Merksatz:
Ein PRINCE2-Projekt ist wie ein Pop-up-Store: Eine temporäre Organisation, die nur für kurze Zeit existiert, um ein bestimmtes Produkt zu verkaufen (Business-Produkt) und Gewinn zu machen (Business Case), bevor sie wieder schließt.

Warum die anderen falsch sind:
Laufender Betrieb: Projekte sind zeitlich begrenzt (temporär) und kein dauerhaftes, sich wiederholendes Tagesgeschäft (Business as usual).
Dauerhafte Abteilung: Eine Abteilung ist eine permanente Linienstruktur, während ein Projekt nach dem Erreichen seiner Ziele wieder aufgelöst wird.

Technische Entwicklungsaufgabe: Dies greift viel zu kurz, da PRINCE2-Projekte immer auch geschäftliche, organisatorische und wirtschaftliche Aspekte (den Business Case) umfassen.

Spezialistische vs. Management-Produkte [F] [Konzepte] 1 Unterseite →

☝️ Single Was unterscheidet "Specialist Products" von "Management Products"?

✅ Specialist Products sind die fachlichen Ergebnisse, Management Products steuern das Projekt

❌ Specialist Products sind ausschließlich mündlich überliefert, während Management Products immer schriftlich festgehalten werden.

❌ Specialist Products und Management Products bezeichnen in PRINCE2 denselben Satz an Dokumenten, nur mit unterschiedlichen Namen.

❌ Management Products haben grundsätzlich einen höheren Stellenwert als Specialist Products, da sie direkt die Projektziele definieren.

Specialist Products sind die eigentlichen, fachlichen Projektergebnisse — Management Products steuern das Projekt selbst.

Merksatz:
Der Spezialist baut das Schiff (Fachliches Ergebnis), der Manager nutzt die Mappe zur Steuerung.

"nie dokumentiert": Auch Fachprodukte (wie Baupläne oder Software-Code) werden intensiv dokumentiert.
"Begriffe identisch": Sie trennen strikt das Was (Projektergebnis) vom Wie (Projektsteuerung).

"Management wertvoller": Ohne das spezialistische Produkt hat das Projekt keinen Wert; beide Produkttypen sind gleichermaßen unverzichtbar.

Product Status Account [F] [Konzepte] 1 Unterseite →

☝️ Single Wofür wird ein "Product Status Account" genutzt?

✅ Um den Status und die Versionen von Produkten zu einem Zeitpunkt zu berichten

❌ Um den aktuellen Bearbeitungsstand einzelner Risiken inklusive ihrer Eintrittswahrscheinlichkeit und Auswirkung darzustellen

❌ Um die geplanten Kommunikationswege und Berichtsintervalle für alle Projektbeteiligten festzulegen

❌ Um die aufgelaufenen Personalkosten und Vergütungszahlungen für das Projektteam zu erfassen

Ein Product Status Account ist ein Bericht über den Status und die Versionen von Produkten zu einem bestimmten Zeitpunkt.

Merksatz:
Der Product Status Account ist das Klassenfoto deiner Produkte: Er zeigt auf einen Blick, welche Version zu einem bestimmten Zeitpunkt welchen Status hat.

Warum die anderen falsch sind:
B): Risiken werden im Risikoregister dokumentiert, nicht im Produktstatus.
C): Die Stakeholder-Kommunikation wird über den Kommunikationsplan gesteuert.

D): "Account" verleitet fälschlicherweise zur Annahme von Finanzbuchhaltung, hat aber nichts mit Gehältern zu tun.

Projektmerkmale [F] [Konzepte] 1 Unterseite →

✌️ Multi Welche Merkmale kennzeichnen ein Projekt nach PRINCE2? (Mehrfachauswahl)

✅ Veränderung (Change)

✅ Zeitlich befristet (Temporary)

✅ Unsicherheit (Uncertainty)

❌ Dauerhaft und repetitiv

PRINCE2 beschreibt Projekte über fünf Merkmale: Veränderung (Change), zeitlich befristet (Temporary), bereichsübergreifend (Cross-functional), einzigartig (Unique) und unsicher (Uncertainty).

Merksatz:
Ein Prinz (PRINCE2) bringt Veränderung (Change) für kurze Zeit (Temporary) und sorgt für Unsicherheit (Uncertainty) am Hof.

Warum die anderen falsch sind:

D: Verwechselt das einmalige Projekt mit dem dauerhaften, alltäglichen Linienbetrieb (Operations).

Delivery Approaches [F] [Konzepte] 1 Unterseite →

✌️ Multi Welche Vorgehensansätze unterstützt PRINCE2 7? (Mehrfachauswahl)

✅ Linear-sequenziell

✅ Iterativ-inkrementell

✅ Hybrid

❌ Chaotisch ohne Steuerung

PRINCE2 7 unterstützt drei Vorgehensansätze: linear-sequenziell, iterativ-inkrementell und hybrid.

Merksatz:
PRINCE2 7 ist wie ein moderner Allrad-SUV: Er fährt sicher auf der geraden Schiene (linear), meistert kurvige Etappen (iterativ) und kombiniert beides flexibel im Gelände (hybrid).

Warum die anderen falsch sind:

D) Chaotisch ohne Steuerung: Widerspricht dem Kern von PRINCE2, das als Methode fundamental auf strukturierter Lenkung und kontrollierten Phasen basiert.

Output Outcome Benefit [F] [Konzepte] 1 Unterseite →

☝️ Single Wie hängen Output, Outcome und Benefit zusammen?

✅ Output = geliefertes Produkt, Outcome = Veränderung, Benefit = messbarer Nutzen

❌ Output beschreibt den erzielten Nutzen, Outcome das gelieferte Produkt und Benefit die daraus resultierende Veränderung im Projektumfeld.

❌ Outcome ist das konkrete Ergebnis, das geliefert wird, während Output den langfristigen wirtschaftlichen Vorteil darstellt und Benefit die unmittelbare Zustandsänderung beschreibt.

❌ Output und Outcome bezeichnen denselben Sachverhalt, lediglich der Benefit ist als zusätzlicher, aber nicht verpflichtender Bestandteil des Projektergebnisses zu verstehen.

Ein Output ist das gelieferte Produkt, ein Outcome die daraus entstehende Veränderung, und ein Benefit der messbare Nutzen, der sich aus dem Outcome ergibt.

Merksatz:
Das Produkt (Output) bewirkt eine Veränderung (Outcome) und bringt messbaren Nutzen (Benefit) – wie ein neues Fahrrad (Output), mit dem man täglich fährt (Outcome), was die eigene Fitness steigert (Benefit).

Warum die anderen falsch sind:
B: Ignoriert die klare logische und zeitliche Kette von der Erstellung bis zur Wirkung.
C: Vertauscht Ursache (Produkt) und Wirkung (Nutzen) fälschlicherweise komplett.

D: Setzt das nackte Produkt und dessen tatsächliche Anwendung fälschlich gleich und erklärt den essenziellen Nutzen als optional.

Dis-benefit [F] [Konzepte] 1 Unterseite →

☝️ Single Was ist ein "Dis-benefit"?

✅ Eine messbare negative Auswirkung, die als Konsequenz des Projekts akzeptiert wird

❌ Eine messbare positive Wirkung, die als direkte Folge des Projekts erwartet wird

❌ Ein geplanter finanzieller Aufwand, der für die Vermarktung des Projektergebnisses vorgesehen ist

❌ Eine unvorhergesehene Möglichkeit, die sich während des Projekts als vorteilhaft erweist

Ein Dis-benefit ist eine messbare negative Auswirkung, die als Konsequenz des Projekts akzeptiert wird (z. B. Produktivitätsabfall während der Einführung).

Merksatz:
Ein „Dis-benefit“ ist die bittere Pille, die man für den Projekterfolg schlucken muss – wie der Muskelkater (negative Auswirkung) nach einem guten Training, den man bewusst in Kauf nimmt.

Warum die anderen falsch sind:
B: Das Präfix „Dis-“ bedeutet das Gegenteil von Benefit.
C: Es beschreibt eine Auswirkung und keinen Budgetposten.

D: Es ist eine negative Auswirkung und keine positive Chance.

Performance-Ziele [Konzepte] 2 Unterseite →

☝️ Single Welches ist das in PRINCE2 7 neu hinzugekommene, siebte Performance-Ziel?

❌ Motivation

❌ Dokumentation

❌ Kommunikation

✅ Nachhaltigkeit

PRINCE2 7 ergänzt die sechs bisherigen Ziele (Nutzen, Kosten, Qualität, Umfang, Zeit, Risiko) um Nachhaltigkeit.

Merksatz:
Die 7 Zwerge pflanzen einen grünen Baum: PRINCE2 7 steuert Projekte jetzt zukunftssicher mit dem siebten Ziel Nachhaltigkeit!

Warum die anderen falsch sind:
Motivation: Ist ein weicher Führungsaspekt (People), kein hartes Performance-Ziel.
Dokumentation: Ist ein administratives Werkzeug zur Absicherung, kein Steuerungsziel.

Kommunikation: Ist eine kontinuierliche Management-Aktivität, kein messbares Projektziel.

☝️ Single Welche sieben Performance-Ziele steuert PRINCE2 7?

❌ Nutzen, Kosten, Qualität, Umfang, Zeit und Kommunikation

✅ Nutzen, Kosten, Qualität, Umfang, Nachhaltigkeit, Zeit und Risiko

❌ Nutzen, Kosten, Qualität, Umfang, Zeit und Motivation

❌ Nutzen, Kosten, Qualität, Umfang, Zeit und Nachhaltigkeit

PRINCE2 7 ergänzt die sechs klassischen Ziele um Nachhaltigkeit.

Merksatz:
Der nachhaltige Riese bringt uns Nutzen durch Zeit, Kosten, Qualität und Umfang. (Riese = Risiko; Nachhaltigkeit ist das neue, siebte Ziel in PRINCE2 7).

Warum die anderen falsch sind:
A: Reduziert PRINCE2 fälschlicherweise auf das klassische magische Dreieck und ignoriert die übrigen vier Dimensionen.
C: Kommunikation ist ein wichtiges Management-Thema, aber kein messbares Performance-Ziel.

D: Motivation ist ein weicher Führungsfaktor und gehört nicht zu den harten, steuerbaren Projekt-Leistungskennzahlen.

Management Products [Konzepte] 5 Unterseite →

☝️ Single In welche drei Arten unterteilt PRINCE2 die Management Products?

❌ Inputs, Outputs und Outcomes

❌ Prinzipien, Practices und Prozesse

❌ Pläne, Risiken und Issues

✅ Baselines, Records und Reports

Management Products sind Baselines (festgeschrieben), Records (fortgeschrieben) oder Reports (Momentaufnahmen).

Merksatz: Denk bei PRINCE2-Management-Produkten an das Frösteln: BRR – Baselines (die feste Basis), Records (die Register-Einträge) und Reports (die Berichte).

Warum die anderen falsch sind:
A: Beschreibt den Wertschöpfungsprozess, nicht die Dokumentenklassen.
B: Sind die allgemeinen Säulen der PRINCE2-Methodik.

C: Sind konkrete Einzelthemen, keine übergeordneten Produktkategorien.

☝️ Single Welches Management Product ist eine Baseline?

❌ Der Projektstatusbericht stellt den aktuellen Projektstatus gegenüber der Baseline dar und dokumentiert Abweichungen von den geplanten Terminen und Kosten, weshalb er selbst als Referenzpunkt für die Steuerung dient.

✅ Die Projektinitiierungsdokumentation (PID)

❌ Das Daily Log erfasst alle informellen Ereignisse und Beobachtungen während des Projekts und wird regelmäßig aktualisiert, wodurch es eine fortlaufende und verbindliche Grundlage für die Entscheidungsfindung bildet.

❌ Das Risikoregister enthält alle identifizierten Risiken mit ihrer Bewertung und wird kontinuierlich gepflegt, sodass es als verbindlicher Ausgangspunkt für alle weiteren Risikomanagement-Aktivitäten im Projektverlauf gilt.

Baselines wie die PID werden festgeschrieben; Register sind Records, Highlight Reports sind Reports.

Merksatz: Die PID ist das in Beton gegossene Fundament (Baseline) deines Hauses – einmal freigegeben, steht es felsenfest als unveränderlicher Maßstab für den gesamten Bau.

Warum die anderen falsch sind:
A) Highlight Report: ...nur ein temporärer Statusbericht zur schnellen Information des Lenkungsausschusses.
C) Daily Log: ...ein informelles, täglich wechselndes Notizbuch des Projektleiters ohne Verbindlichkeit.

D) Risikoregister: ...ein hochdynamisches, sich ständig veränderndes Arbeitswerkzeug zur Risikoüberwachung.

☝️ Single Welches Management Product ist ein Record?

❌ Der Phasenabschlussbericht

❌ Der Business Case

❌ Die PID

✅ Das Risikoregister

Records werden laufend fortgeschrieben – etwa Risiko-, Issue- und Qualitätsregister sowie die Logs.

Merksatz:
Ein Register läuft wie ein Rekorder (Record) ständig im Projekt mit und zeichnet jedes Risiko live auf.

Warum die anderen falsch sind:
A) End Stage Report: Ist ein Report (Bericht), der nur zu einem bestimmten Zeitpunkt den Status rückblickend zusammenfasst.
B) Business Case: Ist ein Steuerungsdokument (Baseline), das die wirtschaftliche Rechtfertigung definiert.
C) PID: Ist das fundamentale Definitionsdokument (Baseline*), das den gesamten Projektrahmen festlegt.

☝️ Single Was ist ein Management Product?

✅ Ein Dokument/Artefakt zur Steuerung des Projekts, nicht das Fachprodukt selbst

❌ Ein Dokument, das die Freigabe der Projektfinanzierung durch die Unternehmensleitung bestätigt und als Nachweis für externe Prüfer dient.

❌ Ein Bericht, der die technische Spezifikation des zu liefernden Produkts beschreibt und als Grundlage für die Qualitätskontrolle verwendet wird.

❌ Eine Vereinbarung, die die Rechte und Pflichten aller am Projekt beteiligten Parteien festlegt und rechtliche Verbindlichkeit besitzt.

Management Products dienen der Projektsteuerung (Baselines, Records, Reports).

Merksatz:
Das Management Product ist das Navi (Steuerungsdokumente wie Pläne und Berichte), das dich ans Ziel führt – nicht das Auto (das eigentliche Fachprodukt) selbst.

Warum die anderen falsch sind:
B: Eine Softwarelizenz ist nur ein einzelnes Betriebsmittel, kein Werkzeug zur Projektsteuerung.
C: Das eigentliche Endprodukt ist das „Fachprodukt“ (Specialist Product), das durch das Projekt entsteht.

D: Ein Lieferantenvertrag ist ein spezifisches Rechtsdokument, kein allgemeines Artefakt der Projektlenkung.

☝️ Single Welche Zuordnung ist korrekt?

❌ Business Case = Report, Risikoregister = Record, Projektstatusbericht = Baseline

❌ Business Case = Baseline, PID = Record, Daily Log = Report

❌ Business Case = Record, Risikoregister = Baseline, Projektstatusbericht = Report

✅ Business Case = Baseline, Risikoregister = Record, Projektstatusbericht = Report

Baselines werden festgeschrieben, Records fortgeschrieben, Reports sind Momentaufnahmen.

Merksatz:
Stell dir den Business Case als festes Fundament (Baseline) vor, auf dem das Projekt steht. Das Risikoregister ist das Logbuch (Record), das ständig Gefahren aufzeichnet, und der Highlight Report ist die Postkarte (Report), die den aktuellen Status an den Lenkungsausschuss funkt.

Warum die anderen falsch sind:
Business Case = Report, PID = Record ist falsch, da der Business Case eine Baseline (Soll-Vorgabe) und das PID ebenfalls eine Baseline (kein Record) ist.
Risikoregister = Baseline, PID = Report ist falsch, da das Risikoregister ein dynamischer Record (Eintragung) und das PID eine Baseline ist.

Highlight Report = Baseline, Daily Log = Report ist falsch, da der Highlight Report ein Report (Statusbericht) und das Daily Log ein Record (Tagebuch) ist.

Ergebnisse [Konzepte] 1 Unterseite →

☝️ Single Wie unterscheiden sich Output, Outcome und Benefit?

❌ Output, Outcome und Benefit sind in PRINCE2 synonyme Begriffe für denselben Projekterfolg.

❌ Output beschreibt den messbaren Nutzen für die Organisation, während Benefit das konkrete gelieferte Produkt darstellt.

❌ Outcome ist das physische Ergebnis des Projekts, während Output die daraus resultierende Veränderung im Unternehmen bezeichnet.

✅ Output = geliefertes Produkt, Outcome = Wirkung, Benefit = messbarer Nutzen

Aus dem Output entsteht ein Outcome (Veränderung), aus dem sich der Benefit (Nutzen) ergibt.

Merksatz:
Output ist das Werkzeug (z. B. ein neues Auto), Outcome ist das Fahrgefühl (du bist schneller am Ziel), Benefit ist das gesparte Geld (messbarer Vorteil).

Warum die anderen falsch sind:
"Alle drei bezeichnen dasselbe" übersieht die klare, hierarchische Kette von der Lieferung über die Verhaltensänderung bis zum finanziellen/strategischen Wert.
"Output ist der Nutzen, Benefit das Produkt" vertauscht die Begriffe komplett, da der Output immer am Anfang der Kette (das Produkt) steht.

"Outcome ist das Produkt, Output die Wirkung" verdreht Ursache und Wirkung, da erst das Produkt (Output) existieren muss, bevor es eine Wirkung (Outcome) erzielen kann.

Managementphasen [Konzepte] 1 Unterseite →

☝️ Single Aus wie vielen Managementphasen besteht ein PRINCE2-Projekt mindestens?

❌ Mindestens sieben (eine Initiierungsphase und sechs weitere Lieferphasen)

❌ Es gibt keine feste Vorgabe, da die Anzahl je nach Projektgröße frei wählbar ist

❌ Genau einer (die Initiierungsphase, da alle weiteren Phasen optional sind)

✅ Zwei (Initiierung und mindestens eine Lieferphase)

Jedes Projekt hat mindestens die Initiierungsphase und eine Lieferphase.

Merksatz:
Der PRINCE geht stabil auf zwei Beinen: Das erste Bein plant (Initiierung), das zweite setzt um (Lieferphase). Ohne diese zwei Schritte läuft kein PRINCE2-Projekt.

Warum die anderen falsch sind:
A: Verwechselt die Phasenanzahl mit den sieben Grundprinzipien, Themen oder Prozessen von PRINCE2.
B: Ignoriert das fundamentale PRINCE2-Prinzip der „Steuerung über Managementphasen“.

C: Übersieht, dass nach der reinen Planung (Initiierung) zwingend eine Umsetzungsphase folgen muss.

Tailoring [Konzepte] 1 Unterseite →

☝️ Single Was bedeutet Tailoring in PRINCE2?

❌ Das Übernehmen eines standardisierten Projektplans aus einem früheren Projekt ohne Anpassung an die aktuellen Gegebenheiten

❌ Das vollständige Entfernen aller vier integrierten Elemente der Methode, um den Projektablauf zu vereinfachen

❌ Das strikte Einhalten aller vorgegebenen Dokumentvorlagen und Berichtsformate ohne jegliche Kürzung oder Anpassung

✅ Das Anpassen der Methode an Umgebung, Größe und Risiko des Projekts

Tailoring passt PRINCE2 an den Kontext an, ohne die sieben Prinzipien aufzugeben.

Merksatz:
Der PRINCE2-Maßschneider (Tailor) näht keinen Standard-Anzug, sondern passt die Methode perfekt an die Größe, Umgebung und das Risiko des Projekts an.

Warum die anderen falsch sind:
A: Kopieren ignoriert die Einzigartigkeit des eigenen Projekts.
B: Die PRINCE2-Prinzipien sind fundamental und dürfen niemals weggelassen werden.

C: Das Einkürzen und Zusammenfassen von Dokumenten ist beim Tailoring ausdrücklich erlaubt.

Integrierte Elemente [Konzepte] 1 Unterseite →

☝️ Single Aus welchen vier integrierten Elementen besteht PRINCE2 7?

✅ Prinzipien, People, Practices und Prozesse

❌ Business Case, Risiko, Qualität und Plan

❌ Themen, Rollen, Pläne und Register

❌ Inputs, Prozesse, Outputs und Reviews

PRINCE2 7 integriert die 7 Prinzipien, das People-Element, die 7 Practices und die 7 Prozesse.

Merksatz:
PRINCE2 7 ist die 4P-Party: Prinzipien, People, Practices und Prozesse tanzen zusammen im Projekt. (Merke: Das neue "People" bringt Leben in die PRINCE-Struktur!)

Warum die anderen falsch sind:
B) ...beschreibt nur einzelne Managementthemen (Praktiken), nicht das übergeordnete Rahmenwerk.
C) ...nutzt veraltete Begriffe und ignoriert das zentrale, neue "People"-Element der Version 7.

D) ...stellt ein allgemeines System-Input-Output-Modell dar, keine PRINCE2-Struktur.

Projekt vs. Tagesgeschäft [Konzepte] 1 Unterseite →

☝️ Single Wodurch unterscheidet sich ein Projekt vom Tagesgeschäft (Business as usual)?

✅ Es ist temporär, bringt Veränderung und liefert definierte Produkte

❌ Es ist dauerhaft angelegt, strebt keine Veränderung an und liefert wiederkehrende Ergebnisse

❌ Es besitzt einen festen Business Case, der über den gesamten Lebenszyklus unverändert bleibt

❌ Es verzichtet auf definierte Rollen und Verantwortlichkeiten innerhalb der Organisation

Ein Projekt ist eine temporäre Organisation zur Lieferung von Produkten – anders als das laufende Tagesgeschäft.

Merksatz:
Ein Projekt ist wie ein Pop-up-Store: Er öffnet nur kurz (temporär), bringt frischen Wind (Veränderung) und liefert ganz bestimmte Dinge (definierte Produkte).

Warum die anderen falsch sind:
B: Dauerhaftes Laufen ohne Ende beschreibt das klassische Tagesgeschäft (Linienarbeit).
C: Ohne wirtschaftliche Rechtfertigung (Business Case) darf kein Projekt gestartet werden.

D: Gerade Projekte erfordern klare, temporäre Rollen (wie Projektleiter) zur Steuerung.

Toleranz und Exception [Konzepte] 1 Unterseite →

☝️ Single Was löst eine Exception aus?

❌ Die unmittelbare Abweichung von einem beliebigen Detail des Projektplans ohne Berücksichtigung der vereinbarten Toleranzgrenzen

❌ Der reguläre Abschluss einer Projektphase, der ohne weitere Eskalation an den Lenkungsausschuss automatisch den nächsten Phasenplan freigibt

✅ Die voraussichtliche Überschreitung einer vereinbarten Toleranz

❌ Die Erstellung eines Teamstatusberichts, der den aktuellen Fortschritt dokumentiert und bei Abweichungen direkt eine Exception auslöst

Innerhalb der Toleranz wird eigenständig gesteuert; erst die drohende Überschreitung wird eskaliert.

Merksatz:
Die Exception-Sirene schrillt erst, wenn der Projekt-Zug die vereinbarte Toleranz-Grenze zu durchbrechen droht – Vorbeugen statt Nachsehen!

Warum die anderen falsch sind:
A: Weil ständige Fehlalarme bei kleinsten Abweichungen zu lähmendem Mikromanagement führen würden.
B: Weil ein geplanter Phasenabschluss ein normaler Routineprozess und kein unvorhergesehener Ausnahmezustand ist.

D: Weil ein Checkpoint Report ein regelmäßiges Berichtswerkzeug und kein Krisensignal darstellt.

Management-Ansätze [Konzepte] 1 Unterseite →

☝️ Single Wo werden die Management-Ansätze eines Projekts festgehalten?

✅ In der Projektinitiierungsdokumentation (PID)

❌ In der Projektmanagementstrategie, die alle relevanten Steuerungs- und Überwachungsverfahren für das Projekt zusammenfasst.

❌ Im Projektplan, der die wesentlichen Entscheidungs- und Kontrollmechanismen für die Projektsteuerung definiert.

❌ Im Kommunikationsmanagement-Ansatz, der die Vorgehensweise für die Berichterstattung und das Reporting festlegt.

Die Management-Ansätze (Risiko, Qualität, Change Control, Kommunikation u. a.) sind Bestandteil der PID.

Merksatz:
Die PID ist das Projekt-Informations-Dach, unter dem alle strategischen Management-Ansätze von Anfang an sicher geschützt zusammenwohnen.

Warum die anderen falsch sind:
B) Arbeitspaket: Enthält nur konkrete operative Aufgaben für einzelne Teams, keine globalen Strategien.
C) Checkpoint Report: Ist ein reiner Statusbericht zur Fortschrittskontrolle, kein Aufbewahrungsort für Konzepte.

D) Daily Log: Dient als informelles Tagebuch für tägliche Vorkommnisse und spontane Probleme.

Managementphase vs. Lieferung [Konzepte] 1 Unterseite →

☝️ Single Worin unterscheiden sich Managementphasen und technische Lieferschritte?

❌ Managementphasen werden direkt vom Projektboard zur Produkterstellung freigegeben

✅ Managementphasen dienen der Steuerung/Freigabe, Lieferschritte der Produkterstellung

❌ Technische Lieferschritte und Managementphasen sind in PRINCE2 immer identisch strukturiert

❌ Technische Lieferschritte dienen der Steuerung und Freigabe der erstellten Produkte

Managementphasen sind Steuerungsabschnitte des Boards; technische Schritte können sich damit überlappen, sind aber nicht dasselbe.

Merksatz:
Der Manager lenkt das Schiff (Steuerung/Freigabe), während die Techniker im Maschinenraum die Kohle schaufeln (Produkterstellung).

Warum die anderen falsch sind:
A: Das Board gibt nur Managementphasen frei, nicht die einzelnen technischen Lieferschritte.
C: Management und Technik haben völlig unterschiedliche Zyklen und sind daher fast nie identisch.

D: Phasen sind nur zeitliche Kontrollrahmen, keine Werkzeuge zur physischen Produkterstellung.

Arbeitspaket [Konzepte] 1 Unterseite →

☝️ Single Was ist ein Arbeitspaket (Arbeitspaket)?

❌ Die umfassende Darstellung aller Projektziele, des Geschäftsnutzens und der wesentlichen Managementebenen, die dem Projektausschuss zur Genehmigung vorgelegt wird.

❌ Ein formelles Schreiben des Projektausschusses an die Teammanager, das die Erwartungen an die Projektkommunikation und die Berichtswege für den Projektzeitraum festlegt.

❌ Die vollständige Auflistung aller identifizierten Risiken mit ihrer Eintrittswahrscheinlichkeit und Auswirkung, die als Grundlage für die Risikobewertung im Projekt dient.

✅ Die Vereinbarung zwischen Projektmanager und Teammanager über zu liefernde Produkte

Das Arbeitspaket enthält Produkte, Toleranzen, Termine und Berichtspflichten.

Merksatz:
Das Arbeitspaket ist der verbindliche Pakt zwischen Project Manager und Team Manager: Ein klarer Liefervertrag für definierte Produkte.

Warum die anderen falsch sind:
A: Verwechselt das operative Paket mit der umfassenden Projektleitdokumentation (PID).
B: Dreht den Informationsfluss um, da das Board lenkt und nicht an Teams berichtet.

C: Verwechselt die konkrete Arbeitsvereinbarung mit dem Risikoregister.

PID [Konzepte] 1 Unterseite →

☝️ Single Was ist die Projektinitiierungsdokumentation (PID)?

❌ Die fortlaufende Sammlung aller Entscheidungen und Begründungen des Projektmanagers während der gesamten Projektdurchführung

❌ Die Zusammenstellung aller identifizierten Risiken mit ihren Eintrittswahrscheinlichkeiten und Auswirkungen auf die Projektziele

✅ Die Baseline, die Business Case, Ansätze, Organisation, Pläne und Controls bündelt

❌ Die regelmäßige Zusammenfassung des aktuellen Projektfortschritts gegenüber dem Lenkungsausschuss für einen festgelegten Zeitraum

Gegen die PID wird der Projekterfolg gemessen.

Merksatz: Die PID ist das „Fundament-Paket“ des Projekts: Sie schnürt wie ein stabiler Container den Business Case, Pläne, Organisation und Controls zu einer unerschütterlichen Baseline zusammen.

Warum die anderen falsch sind:
A) Ein Notizbuch ist nur ein informelles, persönliches Werkzeug des Projektleiters.
B) Die Risikoliste ist nur ein dynamisches Teildokument, kein Gesamtkonzept.

D) Ein Statusbericht liefert nur eine temporäre Momentaufnahme während der Laufzeit.

Vorgehensansätze [Konzepte] 1 Unterseite →

☝️ Single Welche drei Vorgehensansätze zur Lieferung nennt PRINCE2 7?

❌ Phasenweise, ereignisgesteuert und kontinuierlich

❌ Strukturiert, flexibel und ad-hoc

✅ Linear-sequenziell, iterativ-inkrementell und hybrid

❌ Prozessbasiert, rollenbasiert und produktbasiert

PRINCE2 7 unterstützt verschiedene Lieferansätze, klassisch bis agil und hybrid.

Merksatz:
Der Prinz baut seine Burg entweder Linie für Linie (linear-sequenziell), Etage für Etage (iterativ-inkrementell) oder wirft beides zusammen (hybrid).

Warum die anderen falsch sind:
A) Chaotisch und zufällig sind das Gegenteil von strukturiertem Projektmanagement.
B) Klein, mittel und groß beschreiben die Projektgröße (Skalierung), nicht den Lieferansatz.
D) Intern und extern* beziehen sich auf die Herkunft von Ressourcen, nicht auf das Vorgehen.

Schlüsselkonzepte [Konzepte] 13 Unterseite →

☝️ Single Was definiert ein „Projekt“ in PRINCE2 am besten?

✅ Ein zeitlich befristetes Vorhaben, das ein einzigartiges Produkt oder Ergebnis liefert

❌ Ein dauerhaft angelegtes Vorhaben, das wiederkehrende Standardleistungen zur Aufrechterhaltung des Geschäftsbetriebs erbringt

❌ Eine unbefristete Tätigkeit, die kontinuierlich ähnliche Ergebnisse liefert und ohne klaren Abschlusszeitpunkt ausgeführt wird

PRINCE2 definiert ein Projekt als zeitlich befristet, mit klarem Anfang und Ende, das etwas Einzigartiges liefert.

Merksatz: Stell dir einen Prinzen (PRINCE2) vor, der nur einmalig gekrönt wird: Ein Projekt ist wie diese Krönung – zeitlich befristet und liefert ein einzigartiges Ergebnis.

Warum die anderen falsch sind:
B) Beschreibt tägliche Routineaufgaben (Linienarbeit), denen die nötige Einzigartigkeit und Befristung fehlt.
C) Definiert das laufende Tagesgeschäft („Business as Usual“) ohne Enddatum, was das exakte Gegenteil eines Projekts ist.

☝️ Single Wofür werden die „sechs Leistungsvariablen“ (Performance Variables) in PRINCE2 verwendet?

✅ Um zentrale Aspekte der Projektleistung zu steuern und auszubalancieren

❌ Um ausschließlich die Zufriedenheit der Projektmitarbeiter zu erfassen und daraus direkte Maßnahmen zur Teambindung abzuleiten

❌ Um die regulären Planungsprozesse des Projekts vollständig zu ersetzen und eine eigenständige Steuerungsebene zu schaffen

Diese Variablen (Zeit, Kosten, Qualität, Umfang, Risiko und Nutzen) helfen sicherzustellen, dass das Projekt auf Kurs bleibt und Nutzen liefert.

Merksatz:
Stell dir einen Jongleur vor, der sechs Bälle (Zeit, Kosten, Qualität, Umfang, Risiken, Nutzen) geschickt in der Luft hält, um das Projekt perfekt auszubalancieren und zu steuern.

Warum die anderen falsch sind:
B) Die Mitarbeiterzufriedenheit ist ein weicher Faktor und nicht der Fokus dieser sechs harten Steuerungsgrößen.
C) Leistungsvariablen sind Messgrößen zur Steuerung und kein Ersatz für die eigentlichen Planungsprozesse.

☝️ Single Welcher Liefer-/Vorgehensansatz sollte in PRINCE2 gewählt werden?

❌ Immer linear (Wasserfall), unabhängig vom Projekttyp

❌ In PRINCE2 7 sind ausschließlich agile Methoden zulässig

✅ Abhängig vom Projektkontext: linear, iterativ oder hybrid

PRINCE2 fördert Flexibilität – die Wahl des Vorgehensmodells sollte am besten zum Projektumfeld und den Anforderungen passen.

Merksatz:
Der PRINCE ist ein Chamäleon: Er passt sich jedem Projektkontext flexibel an und trägt mal das lineare, mal das iterative oder das hybride Gewand.

Warum die anderen falsch sind:
A) Ein starres „Immer linear“ ignoriert die moderne Projektvielfalt und widerspricht der PRINCE2-Flexibilität.
B) „Ausschließlich agil“ ist ein Extremfehler, da PRINCE2 bewährte klassische Ansätze weiterhin voll unterstützt.

☝️ Single Was ist der Hauptzweck der Project Initiation Documentation (PID)?

❌ Ausschließlich gewonnene Erkenntnisse (Lessons Learned) festzuhalten

✅ Zu beschreiben, wie das Projekt gemanagt und gesteuert wird

❌ Tägliche Aufgaben an Teammitglieder zu verteilen

Richtig – die PID ist das zentrale Referenzdokument für das Management des Projekts

Merksatz:
Die PID ist das Pilot-Instrumenten-Dashboard: Sie definiert das Fundament und die Spielregeln, wie das Projekt sicher gesteuert und gemanagt wird – wie ein Navigationssystem vor dem Abflug.

Warum die anderen falsch sind:
A) Lessons Learned dokumentieren rückblickend Erkenntnisse am Projektende, während die PID vorausschauend den Rahmen für den Start setzt.
C) Die tägliche Aufgabenverteilung ist operative Detailarbeit im Team und gehört nicht in ein strategisches Leitdokument.

☝️ Single Wie sollte technische Komplexität in PRINCE2 während der Umsetzung gemanagt werden?

❌ Sich ausschließlich auf technische Lösungen konzentrieren

✅ Technische Arbeit mit strukturierter Projektsteuerung ausbalancieren

❌ Die Methodik ignorieren, um die Lieferung zu beschleunigen

Richtig – PRINCE2 sorgt für ein diszipliniertes Management neben der technischen Lieferung.

Merksatz:
Stell dir eine Waage vor: Auf der einen Seite die komplexe Technik, auf der anderen das stabile PRINCE2-Steuerungsrad – nur in perfekter Balance bleibt das Projekt auf Kurs.

Warum die anderen falsch sind:
A): ...führt zu einem gefährlichen "blinden Fleck" für Termine, Budget und Risiken durch einen rein technologischen Tunnelblick.
C): ...opfert die nötige Kontrolle und Governance für eine scheinbare, aber hochriskante Abkürzung im Chaos.

☝️ Single Wer ist dafür verantwortlich zu prüfen, dass der Nutzen (Benefits) nach Abschluss des Projekts realisiert wird?

❌ Das Lenkungsausschuss, das die Projektleitung während der Durchführung überwacht und die Freigabe der Phasen erteilt, trägt die Verantwortung für die Sicherstellung der Nutzenrealisierung nach Projektabschluss.

✅ Das Corporate- oder Programme-Management

❌ Der Projektmanager, der die tägliche Steuerung und Koordination der Projektaktivitäten übernimmt, ist dafür zuständig, dass die geplanten Nutzen nach Projektende tatsächlich eintreten.

Sie sind für die Nutzenüberprüfung nach Projektabschluss verantwortlich.

Merksatz:
Wenn das Projekt-Schiff längst abgetakelt ist, erntet nur noch das übergeordnete Dach (Corporate- oder Programme-Management) die reifen Früchte (Nutzen).

Warum die anderen falsch sind:
A) Das Project Board: Löst sich mit dem Projektende auf und existiert für spätere Nutzenprüfungen gar nicht mehr.
C) Der Project Manager: Ist nur für die Übergabe der Projektergebnisse verantwortlich und arbeitet nach Projektende bereits im nächsten Projekt.

☝️ Single Was bewertet die Bloomsche Taxonomie in PRINCE2-Prüfungen in erster Linie?

❌ Ausschließlich Auswendiglernen

✅ Verständnis- und Anwendungsebenen

❌ Schreibfähigkeiten

Die Ebenen nach Bloom umfassen Verstehen, Anwenden und Analysieren von Konzepten.

Merksatz: Stell dir eine aufblühende Blume vor: Sie wächst nur, wenn du sie verstehst und die Pflege richtig anwendest – bloßes Anschauen reicht nicht. (Bloom = Verstehen + Anwenden).

Warum die anderen falsch sind:
A: Reine Gedächtnisleistung greift bei Bloom viel zu kurz, da höhere kognitive Stufen geprüft werden.
C: Es geht um logische Denkprozesse und Wissenstransfer, nicht um Grammatik oder Formulierungskunst.

☝️ Single Wie sollte man mit „Trickfragen“ in der PRINCE2-Prüfung umgehen?

❌ Immer die technisch anspruchsvollste Antwort wählen

✅ Die Frage sorgfältig lesen und Schlüsselwörter identifizieren

❌ Schlüsselwörter wie „NICHT“ oder „AM BESTEN“ ignorieren

Dies hilft, häufige Fallen zu vermeiden, und sichert eine korrekte Interpretation.

Merksatz:
Behandle Prüfungsfragen wie ein Minenfeld: Scanne den Text langsam mit der Lupe und markiere die "Signal-Wörter" als Warnschilder, bevor du dein Kreuz setzt.

Warum die anderen falsch sind:
A: Komplexität blendet, da PRINCE2 pragmatische Management-Logik statt technischer Kompliziertheit fordert.
C: Das Ignorieren von Signalwörtern blendet die entscheidende Richtungsweisung der Frage völlig aus.

☝️ Single Was ist ein wesentlicher Vorteil einer PRINCE2-Zertifizierung?

✅ Sie verbessert strukturierte Projektmanagement-Fähigkeiten

❌ Sie ersetzt vollständig die Notwendigkeit praktischer Projekterfahrung im Berufsalltag.

❌ Sie garantiert eine sofortige Anstellung in einer Führungsposition im Projektmanagement.

PRINCE2 bietet ein Framework, um Projekte effektiv zu managen.

Merksatz:
Ein PRINCE baut sein Königreich mit Struktur – das Zertifikat schenkt dir das stabile Fundament für geordnetes Projektmanagement, nicht die Krone ohne Arbeit.

Warum die anderen falsch sind:
B) Ersetzt Erfahrung: Ein Denkfehler, da graue Theorie (Zertifikat) niemals die echte Praxis (Erfahrung) im Projektalltag ersetzen kann.
C) Garantiert Job: Ein Trugschluss, da ein Zertifikat zwar Türen öffnet, aber niemals einen Arbeitsvertrag garantiert.

☝️ Single Wie sollte das Erfahrungsprotokoll in einem PRINCE2-Projekt genutzt werden?

❌ Ausschließlich durch das Lenkungsausschuss am Projektende gepflegt und für die Folgeprojekte bereitgestellt

❌ Nach jedem Projektabschluss einmalig aktualisiert und anschließend im Projektarchiv abgelegt

✅ Aktiv gepflegt und während des gesamten Projektverlaufs herangezogen

Das Lessons Log ist ein lebendiges Dokument, das genutzt wird, um die Entscheidungsfindung während des gesamten Projekts zu verbessern.

Merksatz:
Das Lessons Log ist das „Navi des Projekts“: Du schaust während der gesamten Fahrt ständig hinein und trägst neue Gefahren sofort ein, statt erst am Ziel den Routenplaner zu öffnen.

Warum die anderen falsch sind:
A ist falsch: Das Project Board lenkt nur strategisch, aber das gesamte Team muss laufend aus Erfahrungen lernen.
B ist falsch: Am Ende ist es für das aktuelle Projekt zu spät – das verwechselt das dynamische Log mit dem finalen Lessons Report.

☝️ Single Was ist der Unterschied zwischen Outcomes (Ergebnissen) und Benefits (Nutzen) in PRINCE2?

❌ Outcomes sind die messbaren Verbesserungen, die direkt aus der Nutzung der Produkte entstehen, während Benefits die konkreten Liefergegenstände des Projekts darstellen.

❌ Outcomes und Benefits sind in PRINCE2 austauschbare Begriffe, die beide die positiven Veränderungen beschreiben, die durch die Projektarbeit erreicht werden.

✅ Outcomes sind Veränderungen, die aus Produkten resultieren; Benefits sind messbare Verbesserungen

Outcomes sind die durch Outputs bewirkten Veränderungen, während Benefits die messbaren Verbesserungen sind, die aus diesen Outcomes resultieren.

Merksatz:
Das Produkt (Output) ist die Schaufel, das Outcome ist das gegrabene Loch (Veränderung) und der Benefit ist der gefundene Schatz (messbarer Nutzen).

Warum die anderen falsch sind:
A: Ignoriert die logische PRINCE2-Wirkungskette, die eine klare Trennung zwischen Verhaltensänderung und messbarem Wert vorschreibt.
B: Vertauscht die Definitionen komplett, da Liefergegenstände "Outputs" sind und Outcomes die Veränderung beschreiben.

☝️ Single Welche der folgenden Optionen ist eine der sechs PRINCE2-Leistungsvariablen?

❌ Kommunikation

❌ Motivation

✅ Kosten

Kosten sind eine der sechs zentralen Leistungsvariablen (Zeit, Kosten, Qualität, Umfang, Risiko, Nutzen).

Merksatz:
Stell dir einen PRINCE vor, der weinend seine leere Schatztruhe anstarrt: Ohne die Variable Kosten im Griff zu haben, scheitert jedes königliche Projekt! (Die sechs Variablen sind: Zeit, Kosten, Qualität, Umfang, Nutzen, Risiko).

Warum die anderen falsch sind:
Kommunikation: Ist ein wichtiges Führungsthema, aber keine der sechs steuerbaren Leistungsvariablen im PRINCE2-Toleranzrahmen.
Motivation: Gehört zu den weichen Verhaltenskompetenzen (Soft Skills) und ist keine hart messbare Projektdimension.

☝️ Single Was ist in PRINCE2-Prüfungsfragen ein „Distraktor“ (Distractor)?

❌ Ein verpflichtender Schritt in der PRINCE2-Methodik

✅ Eine irrelevante, aber plausibel wirkende falsche Antwortoption

❌ Ein Hinweis, der hilft, die richtige Antwort zu erkennen

Distraktoren sind Optionen, die richtig erscheinen, aber subtile Fehler enthalten oder nicht vollständig mit PRINCE2 übereinstimmen. Sie zu erkennen ist entscheidend für den Erfolg.

Merksatz: Ein Distraktor ist wie eine glitzernde Nebelkerze (Ablenkung): Sieht verlockend plausibel aus, führt dich in der Prüfung aber absichtlich auf den falschen Pfad.

Warum die anderen falsch sind:
A) Verwechselt das Vokabular des Prüfungsdesigns mit den tatsächlichen PM-Prozessen von PRINCE2.
C) Dreht die Funktion komplett um, da ein Distraktor verwirren soll und kein hilfreicher Tipp ist.

Fachbegriff-Glossar

Lern-Podcasts & Videos

Wichtige Modelle & Merkhilfen

🧭 7 Prinzipien

🛠️ 7 Practices

🔄 7 Prozesse

🧩 Die 5 integrierten Elemente

👥 Project Board & Rollen

Syllabus-Landkarte

Alle Prüfungsfragen 🔺 Foundation 455 Fragen 443 Single 12 Multi 0 Offen

Alle Prüfungsfragen 🔺 Foundation
455 Fragen 443 Single 12 Multi 0 Offen