Die 7 PRINCE2 Practices im Überblick: Zweck, Produkte und Prüfungsfallen

Die sieben PRINCE2 Grundprinzipien hast du an einem Abend verstanden. Sieben Leitsätze, jeder klingt vernünftig. Dann kommen die sieben PRINCE2 Practices, und der Stoff fühlt sich doppelt so groß an: Risikobereitschaft und Risikotoleranz, Änderungsantrag und Spezifikationsabweichung, Ausnahmebericht und Ausnahmeplan. Alles klingt ähnlich, alles klingt plausibel. Und in der Prüfung stehen genau diese Paare als Antwortoptionen untereinander.

Die kurze Antwort: Die sieben PRINCE2 Practices heißen Business Case, Organisation, Pläne, Qualität, Risiko, Issues und Fortschritt. Jede beantwortet eine Grundfrage, die sich in jedem PRINCE2-Projekt stellt. Und sie sind der größte Block der Foundation-Prüfung: Die offizielle Prüfungsspezifikation von PeopleCert gewichtet sie mit 60 Prozent.

Das Wichtigste in Kürze

• Eine Practice ist ein Aspekt des Projektmanagements, den du über die gesamte Projektlaufzeit im Blick behältst.
• Die sieben PRINCE2 Practices heißen Business Case, Organisation, Pläne, Qualität, Risiko, Issues und Fortschritt.
• Sie machen 60 Prozent der Foundation-Prüfung aus. Die Grundprinzipien kommen auf 8 Prozent.
• Ob ein Managementprodukt in die Projektleitdokumentation oder ins Projektlogbuch gehört, ist eine beliebte Prüfungsfrage.
• Die Fragen greifen vor allem Begriffspaare an, die sich ähnlich anhören.

Was PRINCE2 Practices sind und warum sie 60 Prozent der Prüfung ausmachen

Eine Practice ist ein Aspekt des Projektmanagements, der über den gesamten Projektlebenszyklus laufend behandelt wird. Darin liegt der Unterschied zum Prozess: Ein Prozess hat Anfang und Ende, eine Practice läuft durchgehend mit. Der Business Case wird in jeder Phase erneut geprüft, das Risikoregister bis zum Projektabschluss gepflegt.

Damit hast du drei Ebenen, die in Prüfungsfragen gern gegeneinander gestellt werden. Die Grundprinzipien sind die Haltung: sieben Leitsätze, von denen keiner wegfallen darf. Wenn du dort unsicher bist, lies zuerst, warum PRINCE2 mit Grundprinzipien arbeitet. Die Practices sind die laufende Arbeit, die Prozesse der Ablauf von der Vorbereitung bis zum Abschluss.

Ein Hinweis für alle, die mit älteren Materialien lernen: In der 6. Edition hießen die Practices noch Themen, englisch Themes, und aus dem Thema Änderungen wurde mit PRINCE2 7 die Practice Issues. Die sieben Themen im Netz sind dieselbe Gruppe vor der Umbenennung.

Die Prüfungsspezifikation im offiziellen PeopleCert-Syllabus verteilt die 60 Fragen so:

60 Prozent von 60 Fragen sind 36 Fragen. Die Bestehensgrenze der Foundation-Prüfung liegt bei 36 von 60 richtigen Antworten. Der Practices-Block allein hat also genau so viele Fragen, wie du zum Bestehen brauchst. Die Grundprinzipien, über die in jedem Kursraum am längsten geredet wird, bringen fünf. Das passt zu den Inhalten mit den größten Schwierigkeiten: Der Stoff mit dem größten Gewicht erschließt sich am schlechtesten durch reines Lesen.

Die sieben Practices und ihre Kernfragen

Jede Practice beantwortet eine Frage, die in jedem Projekt gestellt wird. Wenn du diese sieben Fragen im Kopf hast, leitest du dir die Practices her, statt sie als Liste zu behalten.

Zwei Kernfragen liegen dicht beieinander und werden entsprechend häufig vertauscht. Qualität fragt „Was?“ im Sinne der Beschaffenheit, Pläne fragen „Was?“ im Sinne der Produkte und ihrer Reihenfolge. Merke dir Qualität über die Beschaffenheit und Pläne über die Reihenfolge, dann trennst du beide sicher.

Auch die Reihenfolge hat einen Grund: Business Case und Organisation stehen vorn, weil alles Weitere auf ihnen aufsetzt. Ohne Rechtfertigung kein Projekt, ohne Rollen keine Entscheidung. Fortschritt steht am Ende, weil diese Practice die übrigen sechs zusammenbindet.

Ordne die sieben Practices selbst zu

Die Tabelle oben liest sich in zwei Minuten. Ob du sie behalten hast, merkst du erst ohne Vorlage.

Der Baustein läuft in zwei Schritten. Zuerst ordnest du jeder Practice ihre Kernfrage zu. Danach erscheint die Kernfrage auf der Practice-Karte, und du ordnest den Zweck zu, formuliert in der Sprache der Prüfung. Der zweite Schritt ist der schwierigere, weil mehrere Zweckbeschreibungen ähnlich klingen.

Business Case: Warum machen wir das Projekt?

PRINCE2 misst die geschäftliche Rechtfertigung an drei Aspekten. Das Projekt muss wünschenswert sein, der Nutzen also Kosten und Risiken überwiegen. Es muss machbar sein, die Produkte also lieferbar. Und es muss erreichbar sein, aus den Produkten also der erwartete Nutzen entstehen. Fällt einer der drei weg, entscheidet der Lenkungsausschuss über Anpassen oder Stoppen.

Für die Prüfung zählt vor allem die Kette vom Output zum Nutzen. Ein Output ist das, was das Projekt liefert. Aus dem vollständigen Satz an Outputs entsteht eine Fähigkeit, aus deren Nutzung ein Ergebnis, und erst daraus ein messbarer Nutzen. Wer Output und Nutzen gleichsetzt, stolpert über eine der häufigsten Fragen zu dieser Practice.

Der Business Case stellt außerdem Optionen gegeneinander. PRINCE2 verlangt mindestens drei: nichts tun, das Minimum tun und mehr als das Minimum tun. Nichts tun wirkt wie ein Platzhalter, ist aber die Messlatte, denn die Differenz zu dieser Option ist genau der Nutzen, den die Investition kauft.

Nutzenmanagement-Ansatz und Nachhaltigkeitsmanagement-Ansatz sind dabei eigene Managementprodukte und keine Anhänge des Business Case.

Organisation: Wer entscheidet, wer liefert?

Ein Projekt läuft parallel zum Tagesgeschäft und braucht deshalb eine eigene, zeitlich befristete Struktur mit eigener Berichtslinie.

Drei Interessen müssen darin vertreten sein. Das Business achtet darauf, dass Kosten und Nutzen weiter zusammenpassen. Die Benutzerseite darauf, dass die Produkte die Anforderungen treffen und der Nutzen eintritt. Die Lieferantenseite darauf, dass die Lösung mit den vorhandenen Fähigkeiten machbar ist. Eine Person darf mehrere Interessen abdecken, fehlen darf keines.

Darauf setzen die Rollen auf. Projektauftraggeber, Benutzervertreter und Lieferantenvertreter bilden den Lenkungsausschuss. Der Projektmanager führt das tägliche Management innerhalb gesetzter Toleranzen. Teammanager verantworten einzelne Arbeitspakete, diese Rolle ist optional. Die Projektunterstützung übernimmt die Administration, und wo sie nicht besetzt wird, übernimmt der Projektmanager sie mit.

Drei Regeln fragt die Prüfung immer wieder ab. Der Projektauftraggeber ist eine rechenschaftspflichtige Person und kein Gremium. Der Projektmanager berichtet an den Lenkungsausschuss und sitzt nicht darin. Und die Projektsicherung, die unabhängige Sicht des Lenkungsausschusses auf die drei Interessen, darf niemals beim Projektmanager liegen. Rollen darfst du kombinieren, aber keine von ihnen wegfallen lassen.

Pläne: Wie, wie viel und wann?

Ein genehmigter Plan wird zur Baseline: dem festgehaltenen Bezugspunkt, gegen den Umfang, Qualität, Risiken und Fortschritt später gemessen werden. Ändert sich etwas am Plan, wird die Baseline kontrolliert neu gesetzt und nicht stillschweigend nachgezogen.

PRINCE2 kennt genau vier Plantypen. Der Projektplan gibt den groben Überblick über Hauptprodukte, Termine und Kosten. Der Phasenplan ist die detaillierte Grundlage für eine einzelne Phase. Der Teamplan organisiert die Arbeit an einem Arbeitspaket und ist optional, kleine Teams arbeiten direkt mit der Arbeitspaketbeschreibung. Der Ausnahmeplan folgt auf einen Ausnahmebericht und ersetzt ab Genehmigung den Phasen- oder Projektplan. Für Teampläne gibt es keine Ausnahmepläne, und genau danach fragt die Prüfung.

Den Detailgrad steuert der Planungshorizont: Je weiter ein Plan reicht, desto grober bleibt er. Deshalb ist der Projektplan grob und der Phasenplan taggenau.

PRINCE2 plant produktbasiert, also zuerst das Was und dann das Wie. Und Toleranzen gelten auf jeder Planebene für sieben Leistungsziele: Nutzen, Zeit, Kosten, Qualität, Umfang, Risiken und Nachhaltigkeit.

Qualität: Liefern wir das Richtige?

Hier stecken zwei Fragen in einer. Liefert das Projekt das Richtige, und liefert es das Richtige in der vereinbarten Beschaffenheit? Ein technisch einwandfreies Produkt, das an den Bedürfnissen vorbeigeht, erfüllt keine der beiden Bedingungen.

Die Prüfung stellt vier Begriffe gegeneinander, und der Unterschied liegt oft darin, wo sie dokumentiert sind. Die Qualitätserwartungen der Benutzer und die Abnahmekriterien stehen in der Projektproduktbeschreibung, also einmal pro Projekt. Die Qualitätsspezifikationen stehen in der jeweiligen Produktbeschreibung, also einmal pro Produkt. Anforderungen sind dokumentierte Bedarfe, und nur was dokumentiert ist, gehört zum Projektumfang.

Qualitätsmanagement besteht aus drei Elementen. Die Qualitätsplanung legt fest, was in welcher Beschaffenheit entsteht. Die Qualitätssteuerung führt die geplanten Prüfungen durch und hält die Ergebnisse im Qualitätsregister fest. Die Qualitätssicherung prüft unabhängig vom Projektmanagement-Team, ob das systematisch wirkt, und kommt in der Regel aus dem Business.

Eine Regel gilt ohne Ausnahme: Der Prüfer eines Produkts muss unabhängig vom Ersteller sein. Die dritte produktbezogene Verantwortung ist der Abnahmeberechtigte.

Risiko: Was wäre, wenn?

Ein Risiko ist ein unsicheres Ereignis, das die Projektziele beeinflussen würde, falls es eintritt. In PRINCE2 ist es nicht automatisch negativ: Bedrohungen wirken sich schlecht aus, Chancen gut, beide laufen durch dasselbe Verfahren.

Für die Prüfung musst du zwei Begriffe sicher trennen. Die Risikobereitschaft ist die qualitative Haltung des Business, wie viel Risiko es grundsätzlich eingehen will, festgelegt auf der Business-Ebene. Die Risikotoleranz ist der messbare Schwellenwert je Ziel, in derselben Einheit wie das Ziel, festgelegt vom Lenkungsausschuss für das Projekt und für jede Phase. Qualitativ gegen messbar, Business-Ebene gegen Lenkungsausschuss: An diesem Paar entscheiden sich mehrere Fragen.

Ein Risiko beschreibst du in drei Teilen: Ursache, Ereignis und Auswirkung. Die Ursache liegt bereits vor, das Ereignis ist unsicher, die Auswirkung trifft ein Projektziel.

Die Maßnahmen kommen paarweise, je eine Variante für Bedrohungen und eine für Chancen: vermeiden und ergreifen, reduzieren und steigern, dazu übertragen, teilen, akzeptieren und Eventualpläne vorbereiten. Das Verfahren hat vier aufeinanderfolgende Schritte, nämlich identifizieren, bewerten, planen, implementieren. Der fünfte, kommunizieren, läuft durchgehend mit.

Einen Risikobericht oder Risikoplan als eigenes Managementprodukt kennt PRINCE2 übrigens nicht.

Sitzen die Begriffspaare auch unter Zeitdruck?

Risikobereitschaft und Risikotoleranz auseinanderzuhalten, ist beim Lesen leicht. Zwischen vier ähnlich klingenden Antwortoptionen und mit einer Minute pro Frage wird daraus eine andere Aufgabe. Genau die kannst du üben.

• Prüfungsnahe Fragen, aufgebaut entlang der offiziellen Lernziele
• Zu jeder Antwort eine Erklärung
• Exam Readiness Score als Einschätzung, wie weit du noch bist

Kostenlose Übungssession starten

Issues: Was nun?

Von der Practice Risiko trennt diese hier eine einzige Grenze: Ein Risiko ist ungewiss, ein Issue ist eingetreten. Sobald ein Risiko eintritt, wird es zum Issue.

PRINCE2 sortiert Issues in drei Gruppen. Die erste ist ein Hindernis: ein Problem mit unmittelbar negativer Wirkung oder ein Anliegen, dessen Auswirkung erst bewertet werden muss. Die zweite ist eine unerwartete positive Folge, die Business-Chance. Die dritte ist eine Änderung an der Projekt-Baseline mit genau zwei Auslösern.

Ein Änderungsantrag entsteht vor der Lieferung: Jemand möchte, dass ein Produkt anders wird. Der Lenkungsausschuss kann ihn genehmigen, ablehnen, einen Ausnahmeplan anfordern oder zusätzliche Informationen verlangen. Eine Spezifikationsabweichung entsteht durch die Lieferung: Ein geliefertes Produkt erfüllt seine Qualitätsspezifikation nicht. Der Lenkungsausschuss kann sie akzeptieren oder ablehnen. Eine akzeptierte Abweichung heißt Konzession, die Baseline wird dabei an die geänderte Produktbeschreibung angepasst.

Das Verfahren läuft in fünf Schritten: erfassen, bewerten, empfehlen, entscheiden, implementieren. Der Lenkungsausschuss kann seine Befugnis an eine Änderungsinstanz, den Projektmanager oder einen Teammanager delegieren.

Zwei Töpfe für zwei Zwecke, und auch das wird gefragt: Das Änderungsbudget finanziert genehmigte Änderungen, das Risikobudget finanziert Risikomaßnahmen.

Fortschritt: Wo stehen wir, wo landen wir?

Diese Practice beobachtet die Leistung gegen den Plan, leitet daraus Prognosen ab und löst Eskalationen aus, bevor eine Abweichung eingetreten ist. Die Prognose umfasst alle sieben Leistungsziele, nicht allein Zeit und Kosten.

PRINCE2 unterscheidet zwei Arten von Steuerungsmitteln. Ereignisbasierte greifen bei einem bestimmten Ereignis, etwa am Phasenende oder bei einem Ausnahmebericht. Zeitbasierte greifen in festen Intervallen, etwa der Teamstatusbericht alle zwei Wochen. Der Phasenabschlussbericht ist ereignisbasiert, weil das Phasenende ein Ereignis bleibt, auch wenn es geplant war.

Die Eskalation läuft über drei Ebenen, und die Prüfung fragt die Unterschiede ab. Droht ein Arbeitspaket aus der Toleranz zu laufen, meldet der Teammanager ein Issue an den Projektmanager, der eine Korrekturmaßnahme anordnet; ein Ausnahmebericht entsteht dabei nicht. Droht die Phase aus der Toleranz zu laufen, schreibt der Projektmanager einen Ausnahmebericht an den Lenkungsausschuss. Droht das Projekt aus der Projekttoleranz zu laufen, ist der Lenkungsausschuss nicht mehr befugt und eskaliert an die Business-Ebene.

Noch ein Paar, das sich ähnlich anhört: Der Ausnahmebericht meldet die drohende Überschreitung samt Optionen. Der Ausnahmeplan ist die Antwort darauf und ersetzt den laufenden Phasenplan.

Wohin die Managementprodukte gehören: PID oder Projektlogbuch

Jede Practice bringt eigene Managementprodukte mit, in Summe mehr, als man sich einzeln merken möchte. Die Prüfung fragt sie meist über ihre Zugehörigkeit ab: Gehört dieses Produkt in die Projektleitdokumentation oder ins Projektlogbuch? Die Tabelle unten sammelt alle Produkte der sieben Practices an einer Stelle.

Die Projektleitdokumentation, kurz PID, ist der Vertrag des Projekts. Sie entsteht in der Initiierungsphase, wird vom Lenkungsausschuss genehmigt und als Baseline eingefroren. Hier wohnen die Management-Ansätze, also die Beschreibungen, wie im Projekt gearbeitet wird. Das Projektlogbuch ist das laufende Notizbuch mit den Registern und Listen, die sich täglich ändern.

Daraus ergibt sich eine Merkregel, die dir eine ganze Fragengruppe abnimmt: Alle Management-Ansätze wohnen in der Projektleitdokumentation, alle Register und Listen im Projektlogbuch. Was einzeln freigegeben oder berichtet wird, steht für sich.

Typische Prüfungsfallen bei den sieben Practices

Die Foundation-Prüfung testet Wiedererkennen und Verständnis, keine Urteilsfähigkeit. Praktisch heißt das: Die falschen Antwortoptionen sind meist Begriffe aus derselben Practice, die sich ähnlich anhören. Denselben Mechanismus beschreiben wir im Beitrag zu den häufigsten Fehlern unter ähnlich klingende Begriffe verwechseln, hier mit den konkreten Paaren.

Zwei Muster tauchen quer durch alle sieben Practices auf. Wenn du sie kennst, sortierst du falsche Antworten aus, ohne die richtige zu wissen.

Erstens gelten Toleranzen für sieben Leistungsziele: Nutzen, Zeit, Kosten, Qualität, Umfang, Risiken und Nachhaltigkeit. Wo eine Antwortoption nur Zeit und Kosten aufzählt, ist sie falsch, auch wenn sie vertraut klingt.

Zweitens ist Eskalation ein vorgesehenes Verfahren und kein Scheitern. Deutet eine Antwortoption an, der Projektmanager habe durch Eskalieren versagt, kannst du sie streichen. Ausprobieren lässt sich das an den typischen Themen in Foundation-Fragen.

Wie du die sieben Practices sinnvoll lernst

Die sieben PRINCE2 Practices in einem Rutsch durchzulesen bringt wenig, weil sie ständig aufeinander verweisen. Eine Reihenfolge, die sich bewährt hat:

Fang mit Business Case und Organisation an. Beide beantworten das Warum und das Wer, die anderen fünf hängen daran. Wer nicht weiß, wer im Lenkungsausschuss sitzt, kann keine Frage zur Eskalation beantworten.

Nimm Pläne und Qualität als Paar. Beide arbeiten mit Produkten, und die produktbasierte Planung erklärt, warum Qualität mit der Projektproduktbeschreibung beginnt.

Nimm Risiko und Issues ebenfalls als Paar. Die einzige Grenze zwischen ihnen ist, ob etwas eingetreten ist. Wer sie zusammen lernt, vertauscht sie nicht.

Lass Fortschritt zum Schluss. Diese Practice bindet die anderen sechs zusammen: Toleranzen aus den Plänen, Ausnahmen aus Risiken und Issues, die Stop-oder-weiter-Entscheidung aus dem Business Case.

Und dann prüfe, ob du zuordnen kannst statt aufsagen. Zuordnung ist der Standardtyp in dieser Prüfung, und der Baustein weiter oben trainiert genau das. Wie du den Stoff über zwei Wochen verteilst, steht in unserem Beitrag zu dem, was du bis zur Prüfung wirklich beherrschen musst. Für die andere Siebenergruppe hilft dir Die 7 PRINCE2 Grundprinzipien einfach erklärt.

Zu diesem Artikel: Die Gewichtung von 60 Prozent stammt aus der Prüfungsspezifikation im offiziellen PeopleCert-Syllabus für PRINCE2 7 Foundation. Die Zahl von 36 Fragen haben wir daraus gerechnet, PeopleCert weist sie nicht so aus. Die Verwechslungspaare im Abschnitt zu den Prüfungsfallen sind eine redaktionelle Sammlung aus unserer Arbeit an den Foundation-Lernzielen und den Antworterklärungen im xamate-Fragenpool, keine Auswertung von Prüfungsergebnissen.

Fazit

Die sieben PRINCE2 Practices sind Business Case, Organisation, Pläne, Qualität, Risiko, Issues und Fortschritt. Jede beantwortet eine Frage, die in jedem Projekt gestellt wird, und jede läuft über die gesamte Projektlaufzeit mit.

Für die Prüfung sind sie der Block, der über das Bestehen entscheidet: 60 Prozent der Fragen, also 36 von 60, bei einer Bestehensgrenze von ebenfalls 36. Wer die Practices sicher beherrscht und den Rest solide kennt, steht besser da als umgekehrt.

Der Weg dahin führt über Zuordnen. Die Definitionen sind schnell gelesen. Die Paare zu trennen, Risikobereitschaft gegen Risikotoleranz, Änderungsantrag gegen Spezifikationsabweichung, Ausnahmebericht gegen Ausnahmeplan, dauert länger und entscheidet am Prüfungstag über die Punkte.