PMI PMP: Projektplanung & Integration — Lernleitfaden

By Laurynas Brazys · 21 July 2026 · #pmi #pmp #certification #exam-prep #study-guide

Teil des PMP — Lernleitfaden. Üben Sie mit verifizierten Antworten im PMI-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Projektauftrag, Initiierung & Abstimmung mit den Stakeholdern

Der Projektauftrag ist das Instrument, das die Existenz eines Projekts formell genehmigt und dem Projektmanager die Befugnis erteilt, organisatorische Ressourcen einzusetzen. Seine Wirksamkeit ergibt sich nicht aus seiner Länge, sondern aus dem, was er festschreibt: übergeordnete Ziele, messbare Erfolgskriterien, ein zusammenfassender Meilensteinplan, ein vorläufiges Budget, Annahmen und Randbedingungen, der benannte Projektmanager und dessen Befugnisstufe sowie die Unterschrift des Auftraggebers. Ohne einen unterzeichneten Projektauftrag agiert ein Projektmanager auf Basis informeller Genehmigungen – jeder Ressourcenkonflikt, jeder Streit über den Projektumfang, jede Eskalation wird zu einer Verhandlung aus einer Position der Schwäche.

Während der Initiierung muss der Projektmanager die Vision des Auftraggebers in ein gemeinsames Verständnis umwandeln. Das bedeutet, strukturierte Gespräche mit dem Auftraggeber und den wichtigsten Stakeholdern zu führen, um zu klären, warum das Projekt existiert (der Business Case), wie „fertig“ aussieht (Abnahmekriterien) und wer die Entscheidungsbefugnisse hat. Ein Projekt zur Gestaltung einer multimedialen Ausstellung kann beispielsweise nicht mit der Planentwicklung fortfahren, bis der Projektmanager weiß, ob der Auftraggeber die Fertigstellung zur Eröffnung (fester Termin), die kuratorische Genauigkeit (fester Umfang) oder die Budgetdisziplin (feste Kosten) priorisiert. Diese Abwägungen prägen jede nachfolgende Planungsentscheidung.

Die Abstimmung mit den Stakeholdern in der Initiierungsphase ist keine Formalität. Die Identifizierung von Stakeholdern, die Analyse ihrer Interessen, ihres Einflusses und ihrer Erwartungen sowie die Überprüfung ihres Verständnisses für den Projektzweck deckt Konflikte auf, solange sie noch kostengünstig zu lösen sind. Ein frühzeitig erstelltes – und kontinuierlich verfeinertes – Stakeholder-Register verhindert das klassische Fehlermuster, mitten in der Ausführung einen mächtigen Stakeholder zu entdecken, der die Ziele nie akzeptiert hat.

PSP-Dekomposition und das PSP-Wörterbuch

Der Projektstrukturplan (PSP, Work Breakdown Structure) gliedert den gesamten Projektumfang in Lieferobjekte und weiter in Arbeitspakete. Die richtige Gliederungstiefe ist die Ebene, auf der ein Arbeitspaket zuverlässig hinsichtlich Kosten und Dauer geschätzt, einem einzigen Verantwortlichen zugewiesen und dessen Fortschritt überwacht werden kann. Dies wird oft als 8/80-Heuristik bezeichnet (Arbeitspakete mit einem Aufwand zwischen etwa 8 und 80 Stunden), aber der wahre Test ist die Steuerbarkeit, nicht die Stundenanzahl.

Eine übermäßige Detaillierung schafft administrativen Mehraufwand: Hunderte von Mikro-Aufgaben, deren Verfolgung mehr Zeit in Anspruch nimmt als ihre Ausführung und die die Verantwortlichkeit fragmentieren. Eine ungenügende Detaillierung verbirgt Risiken: Ein Arbeitspaket mit der Bezeichnung „Überbau errichten“ bei einem Brückenprojekt ist zu grob, um sinnvoll geschätzt zu werden, sodass Rückstellungen für Kosten und Termine ausufern und eine Abweichungsanalyse unmöglich wird. Für das Brückenbeispiel sollte die Gliederung so lange fortgesetzt werden, bis jedes Paket (z.B. „Bewehrungskorb für südliches Widerlager herstellen“) diskret schätzbar und einem Polier zuweisbar ist.

Das PSP-Wörterbuch ergänzt den PSP, indem es für jedes Arbeitspaket den Arbeitsumfang, die verantwortliche Organisation, terminliche Meilensteine, Ressourcenanforderungen, Qualitätskriterien, Abnahmekriterien und technische Referenzen definiert. Es ist die Brücke zwischen dem visuellen PSP und den Prozessen der Schätzung, Terminplanung und Qualitätssicherung. Das Auslassen des Wörterbuchs ist eine häufige Ursache für Streitigkeiten über den Projektumfang, da die alleinige Bezeichnung im PSP mehrdeutig ist.

Integration von Teilplänen

Der Projektmanagementplan ist kein Dokument; er ist ein integrierter Satz von Teilplänen und Basisplänen. Die Managementpläne für Umfang, Termine, Kosten, Qualität, Ressourcen, Kommunikation, Risiken, Beschaffung und Stakeholder-Engagement müssen in sich konsistent sein. Wenn der Qualitätsplan zwei unabhängige Testzyklen vorschreibt, der Zeitplan aber nur einen zulässt, ist der Plan nicht integriert – er ist eine Sammlung von Dokumenten.

• Umfang — Der PSP ist auf die Vorgänge im Zeitplan und die Kostenschätzungen abgestimmt
• Zeitplan — Ressourcenkalender sind mit dem Ressourcenmanagementplan abgeglichen
• Kosten — Rückstellungen für Unvorhergesehenes spiegeln das Risikoregister wider
• Qualität — Metriken fließen in die Überwachungs- und Steuerungsprozesse ein
• Ressourcen — Benötigte Fähigkeiten stimmen mit dem Beschaffungsplan zur Schließung von Lücken überein
• Risiko — Maßnahmenstrategien sind im Kostenplan budgetiert und im Zeitplan terminiert

Die drei Basispläne – Umfang, Zeitplan und Kosten – bilden zusammen den Leistungsmessungs-Basisplan. Einmal genehmigt, werden diese nur durch die integrierte Änderungssteuerung geändert. Die Behandlung von Basisplänen als Vorschläge statt als kontrollierte Referenzen zerstört die Earned-Value-Analyse und untergräbt die Abweichungsberichterstattung.

Auswahl des Lebenszyklus und Tailoring

Die Auswahl von prädiktiven, adaptiven oder hybriden Ansätzen ist eine bewusste Entscheidung, die von der Unsicherheit der Anforderungen, der Änderungsrate, den Erwartungen an die Einbindung der Stakeholder, regulatorischen Beschränkungen und den Anforderungen an die Lieferkadenz abhängt.

• Prädiktiv eignet sich für Projekte mit stabilen, gut verstandenen Anforderungen, festem regulatorischem Umfang und geringer Änderungstoleranz (Brückenbau, behördliche Einreichungen).
• Adaptiv (agil) eignet sich für Arbeiten mit hoher Unsicherheit, bei denen sich die Anforderungen durch Nutzung und Feedback herausbilden (neuartige Software-Features, F&E-Prototypen).
• Hybrid wird angewendet, wenn verschiedene Komponenten desselben Projekts unterschiedliche Eigenschaften aufweisen.

Ein Programm mit langer Laufzeit, das sowohl eine stabile mehrjährige Architektur als auch kurzfristig lieferbare Features benötigt, ist ein klassischer Hybridfall: Der Projektmanager setzt ein prädiktives Rahmenwerk der rollierenden Planung für die Gesamt-Roadmap, Meilensteine und Infrastruktur auf, während adaptive Iterationen inkrementell Features liefern. Die Governance-Ebenen berücksichtigen beides – Stage-Gate-Reviews für den prädiktiven Rahmen, Sprint-Reviews und Retrospektiven innerhalb der adaptiven Ebene.

Das Tailoring geht über die Wahl des Lebenszyklus hinaus und erstreckt sich auf Zeremonien, Artefakte, Werkzeuge und Rollen. Ein kleines internes Projekt benötigt möglicherweise nur einen schlanken Projektauftrag und ein Kanban-Board; ein reguliertes pharmazeutisches Projekt erfordert unabhängig von der Iterationsmethode formale Design-History-Files.

← Beschaffung · Alle Domänen · Governance →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →