Ein Problementscheidungsplan (Process Decision Program Chart, PDPC) ist ein Planungswerkzeug, das einen fertigen Plan Schritt für Schritt zerlegt und an jeder Stelle fragt, was schiefgehen kann und was man dann täte. Ergebnis ist ein Baum: das Ziel oben, darunter die Hauptschritte, darunter die Teilaufgaben, dann die plausiblen Fehlerfälle und ganz unten je eine Gegenmaßnahme.
Das Werkzeug existiert, weil die meisten Pläne so geschrieben sind, als würden sie funktionieren. Ein PDPC zwingt einem bereits ausgearbeiteten Plan die gegenteilige Annahme auf, und das ist eine andere und unbequemere Übung als eine Risikosammlung auf leerem Blatt.
Aufbau
- Ziel festlegen. Ein Ziel an der Spitze, formuliert als Ergebnis, nicht als Tätigkeit.
- In Schritte zerlegen. Zwei Ebenen reichen meist: Hauptschritte, darunter die Teilaufgaben.
- Fehlerfälle sammeln. Zu jeder Teilaufgabe die plausiblen Fehlschläge notieren. Plausibel ist das entscheidende Wort, ein Plan mit jedem theoretisch denkbaren Fehler ist unbrauchbar.
- Gegenmaßnahmen anhängen. Zu jedem Fehlerfall aufschreiben, was man tatsächlich tun würde. Gegenmaßnahmen stehen auf der untersten Ebene, üblicherweise in einer anderen Form gezeichnet als die Aufgaben.
- Gegenmaßnahmen bewerten. Üblich ist ein Kreis für praktikabel und ein X für zu langsam, zu teuer oder nicht machbar. Die X-Markierungen sind das eigentliche Ergebnis: ein ungedeckter Fehlerfall braucht entweder einen anderen Plan oder einen Eintrag mit Verantwortlichem im Risikoregister.
Wann es sich lohnt
Ein PDPC rechnet sich bei Plänen, die neu, folgenschwer und schwer umkehrbar sind: eine erste Migration, ein regulierter Rollout, eine Inbetriebnahme, ein Umstellungswochenende. Bei Routinearbeit entsteht ein großer Plan mit wenig Erkenntnis, und genau deshalb geben die meisten Teams nach dem ersten Versuch wieder auf.
Ein nützlicher Nebeneffekt bleibt: weil die Gegenmaßnahmen an konkreten Schritten hängen und nicht am Projekt insgesamt, werden daraus belastbare Rückfallpläne und Go-/No-go-Kriterien statt der Absichtserklärung, man werde vorsichtig sein.
Einordnung im PMBOK Guide 8
Der Begriff kommt in der achten Ausgabe nicht vor, und in der siebten und sechsten ebenfalls nicht. PDPC kam als eines der sieben Qualitätsmanagement- und Steuerungswerkzeuge in den PMBOK Guide, einer aus dem japanischen Qualitätsmanagement übernommenen Gruppe, die in der fünften Ausgabe neben Affinitätsdiagramm, Relationendiagramm, Baumdiagramm, Priorisierungsmatrix, Netzplan und Matrixdiagramm geführt wurde. Die sechste Ausgabe löste die Gruppe auf und beschrieb die Diagramme einzeln unter Datendarstellung. Die achte Ausgabe geht weiter und verzichtet ganz auf Werkzeuglisten; sie beschreibt nur noch Techniken, die für sich stehen, etwa das Affinitätsdiagramm und das Flussdiagramm.
Erhalten bleibt der Denkansatz, verteilt auf Techniken, die die achte Ausgabe benennt. Fehlerfälle sammeln und Antworten planen ist Risikoregister und Risikobewältigung. Eine Entscheidung mit ihren Zweigen abbilden ist Entscheidungsbaumanalyse. Einen Fehler auf seine Ursache zurückführen ist Ursachenanalyse, etwa über das Ursache-Wirkungs-Diagramm. Eine Alternative für den Fall vorbereiten, dass die Antwort nicht greift, ist der Rückfallplan. Wer diese vier Dinge ohnehin sauber tut, gewinnt mit einem PDPC Struktur, aber selten neue Information.
Häufige Fragen
Ist PDPC prüfungsrelevant?
Nicht für die achte Ausgabe. Behandeln Sie es als altes Qualitätswerkzeug, das Ihnen in Organisationen mit starker TQM- oder Six-Sigma-Tradition noch begegnet, nicht als aktuellen PMBOK-Inhalt.
Was unterscheidet es vom Risikoregister?
Das Risikoregister ist eine Liste, geordnet nach Risiko. Ein PDPC ist ein Baum, geordnet nach Planschritt, und bringt deshalb nur Risiken hoch, die an etwas hängen, das man tatsächlich vorhat. Beides ergänzt sich: der Plan erzeugt Einträge, das Register verfolgt sie.
Was unterscheidet es von einer FMEA?
Die Fehlermöglichkeits- und Einflussanalyse arbeitet von unten nach oben aus Bauteilen heraus und bewertet jeden Fehler nach Bedeutung, Auftreten und Entdeckung. Ein PDPC arbeitet von oben nach unten aus einem Plan heraus und bewertet nichts numerisch. FMEA passt zu Produkten, PDPC zu Abläufen.
Gibt es ein agiles Gegenstück?
Am nächsten kommt das Pre-mortem: Das Team nimmt an, die Iteration oder das Release sei bereits gescheitert, und arbeitet rückwärts zu den Ursachen. Gleicher Reflex, deutlich weniger Zeichnerei.
Autor: Tom, seit 2004 PMP-zertifiziert. Zuletzt aktualisiert: August 2026