Projektmanagement-Leitfaden · Planung und Umfang
Project Initiation Document (PID): Inhalte und Beispiel
Ein Projektinitiierungsdokument (PID) ist die Gesamtheit der Informationen, die ein Projekt definieren, erklären, wie es gesteuert wird, und die Basis bilden, die der Lenkungsausschuss vor Beginn der Lieferung genehmigt. Es stammt aus PRINCE2, wo der Projektmanager es während der Initiierung zusammenstellt, doch viele Organisationen nutzen PIDs unabhängig von ihrer Methode. Dieser Leitfaden erklärt, was ein PID enthält, wie Sie es erstellen, zeigt ein ausführliches Beispiel und wie es sich von einem Projektauftrag unterscheidet.
Das Wichtigste in Kürze
- Ein PID legt fest, was das Projekt liefern wird, warum, wie es gesteuert wird und innerhalb welcher Grenzen.
- In PRINCE2 stellt der Projektmanager es im Prozess Initiieren eines Projekts zusammen, und der Lenkungsausschuss genehmigt es.
- Nach der Genehmigung wird das PID als Basis festgeschrieben, und Änderungen laufen über die Änderungssteuerung, oft mit Überprüfung an den Phasenübergängen.
- Toleranzen im PID erlauben dem Projektmanager, zu handeln, ohne jede kleine Abweichung zu eskalieren (Steuern nach dem Ausnahmeprinzip).
- Passen Sie den Umfang an das Projekt an: Ein kleines oder agiles Projekt braucht ein kurzes PID, ein großes Programm deutlich mehr.
Was ist ein Projektinitiierungsdokument?
A Projektinitiierungsdokument (PID) ist eine Sammlung von Informationen, die ein Projekt definieren und festlegen, wie es gesteuert wird. Es vereint Projektdefinition, Business Case, Teamstruktur, Projektplan, Managementansätze, Steuerungsmittel und Tailoring. Sobald der Lenkungsausschuss es genehmigt, wird das PID zur Basis für die Durchführung und Bewertung des Projekts.
PRINCE2 spricht formal von Projektleitdokumentation, weil es sich nicht um eine einzelne Datei handeln muss. Es kann ein einzelnes Dokument, eine Reihe verknüpfter Dokumente oder eine Seite in einem Projektmanagement-Tool sein, solange alles gemeinsam genehmigt und gesteuert wird.
Das PID beantwortet die Fragen, die ein Entscheider klären muss, bevor er Geld und Personal bindet:
- Was genau tun wir, und was tun wir nicht?
- Warum lohnt es sich, und welchen Nutzen erwarten wir?
- Wer ist wofür verantwortlich, und wer entscheidet?
- Wie lange wird es dauern und wie viel wird es kosten?
- Wie steuern wir Qualität, Risiken, Issues, Änderungen und Kommunikation?
- Wie weit dürfen Dinge abweichen, bevor der Projektmanager eskalieren muss?
Obwohl der Begriff aus PRINCE2 stammt, werden PIDs häufig in britischen Behörden, Gesundheitsdiensten und Unternehmen genutzt, die PRINCE2 nicht streng folgen.
Warum das PID wichtig ist
PRINCE2 beschreibt das PID als Vertrag zwischen Projektmanager und Lenkungsausschuss: Es hält fest, was der Lenkungsausschuss vereinbart hat und wozu sich der Projektmanager verpflichtet hat. In der Praxis bietet Ihnen ein gutes PID:
- Eine klare Go/No-go-Entscheidung: Der Lenkungsausschuss genehmigt das Projekt auf Grundlage eines vollständigen Bildes, nicht einer vagen Idee.
- Eine Basis: Fortschritt, Kosten, Umfang und Nutzen werden an dem gemessen, was genehmigt wurde.
- Steuern nach dem Ausnahmeprinzip: Vereinbarte Toleranzen erlauben dem Projektmanager, das Projekt im Tagesgeschäft zu steuern und nur zu eskalieren, wenn eine Überschreitung der Grenzen prognostiziert wird.
- Klare Governance: Rollen, Entscheidungsrechte und Berichtswege werden vereinbart, bevor Probleme auftreten; siehe Projekt-Governance.
- Kontinuität: Neue Teammitglieder, Lieferanten und Mitglieder des Lenkungsausschusses können das Projekt an einer Stelle nachvollziehen.
- Eine Referenz beim Abschluss: Am Ende vergleicht der Lenkungsausschuss, was geliefert wurde, mit dem, was das PID versprochen hat.
Wo das PID in PRINCE2 verankert ist
Das PID entsteht in der zweiten Phase eines PRINCE2-Projekts, der Initiierungsphase, und wird danach durchgehend genutzt. Die Tabelle verfolgt es durch die PRINCE2-Prozesse.
| PRINCE2-Prozess | Was mit dem PID geschieht |
|---|---|
| Vorbereiten eines Projekts | Bevor das PID existiert, werden eine kurze Projektbeschreibung und ein Grob-Business-Case erstellt, damit der Lenkungsausschuss entscheiden kann, ob sich die Initiierung lohnt. |
| Lenken eines Projekts (Initiierung genehmigen) | Der Lenkungsausschuss stimmt zu, in die Initiierungsphase zu investieren. |
| Initiieren eines Projekts | Der Projektmanager entwickelt die Managementansätze, den Projektplan, die Steuerungsmittel und den detaillierten Business Case und fasst sie im PID zusammen. |
| Lenken eines Projekts (Projekt genehmigen) | Der Lenkungsausschuss prüft und genehmigt das PID. Danach wird es als Basis festgeschrieben. |
| Managen eines Phasenübergangs | Der Projektmanager aktualisiert das PID bei Bedarf (zum Beispiel Business Case und Projektplan), damit der Lenkungsausschuss es vor der nächsten Phase prüfen kann. |
| Abschließen eines Projekts | Mit dem PID wird das Endergebnis mit der ursprünglichen Basis und den genehmigten Änderungen verglichen. |
PRINCE2 7, 2023 von PeopleCert veröffentlicht, benannte die sieben Themen in Praktiken um: Business Case, Organisation, Pläne, Qualität, Risiko, Issues und Fortschritt. Außerdem kamen Managementansätze für Kommerzielles, Nachhaltigkeit sowie Digitales und Daten hinzu, und ein neues Kapitel zum Thema Menschen wurde eingeführt. Das PID steht weiterhin im Zentrum der Initiierung.
Wenn Sie Frameworks vergleichen, siehe PMBOK vs. PRINCE2.
Was ein Projektinitiierungsdokument enthält
Laut PRINCE2-Leitlinien vereint das PID die folgenden Bestandteile. Außerhalb von PRINCE2 folgen die meisten PID-Vorlagen einer ähnlichen Struktur mit anderen Überschriften.
| PID-Abschnitt | Was es enthält |
|---|---|
| Projektdefinition | Hintergrund, Ziele, gewünschte Ergebnisse, Umfang und Ausschlüsse, Lieferobjekte, Restriktionen, Annahmen, Nutzer und Schnittstellen |
| Business Case | Gründe, geprüfte Optionen, erwarteter Nutzen und Nachteile, Kosten, Zeitrahmen, Investitionsbewertung und wesentliche Risiken |
| Struktur des Projektmanagementteams | Lenkungsausschuss, Projektmanager, Rollen für Projektsicherung und -unterstützung, oft als Organigramm |
| Rollenbeschreibungen | Verantwortlichkeiten und Befugnisse jeder Rolle |
| Managementansätze | Wie Qualität, Risiken, Issues und Änderungen, Kommunikation und weitere Bereiche gesteuert werden |
| Projektplan | Phasen, wichtige Produkte, Meilensteine, Ressourcen, Kosten und Zeitrahmen |
| Projektsteuerungsmittel | Phasenübergänge, Toleranzen, Reporting (zum Beispiel Statusberichte) und Eskalation |
| Tailoring | Wie die Methode an das Projekt angepasst wurde und warum |
Projektdefinition
Das ist das Herzstück des PID. Formulieren Sie messbare Projektziele, eine Inhaltsbeschreibung mit ausdrücklichen Ausschlüssen, eine Liste der Lieferobjekte mit Abnahmekriterien sowie die Restriktionen und Annahmen, innerhalb derer Sie arbeiten. Viele spätere Streitigkeiten in einem Projekt gehen auf eine vage Definition an dieser Stelle zurück.
Managementansätze in PRINCE2 7
Managementansätze (in älteren Ausgaben Strategien genannt) erklären, wie ein bestimmter Bereich in diesem Projekt gehandhabt wird. PRINCE2 7 beschreibt Ansätze für Bereiche wie:
- Qualität: Standards, Qualitätsmethoden, Verantwortlichkeiten und Aufzeichnungen.
- Risiko: wie Risiken identifiziert, bewertet und gesteuert werden, mit Skalen, Verantwortlichen und Überprüfungshäufigkeit. Siehe Projektrisikomanagement.
- Issues und Änderungssteuerung: wie Issues und Änderungsanträge erfasst, bewertet und entschieden werden.
- Kommunikation: welche Informationen wann und wie an wen gehen. Siehe Kommunikationsplan.
- Kommerzielles: wie Lieferanten und Verträge gesteuert werden (neu in PRINCE2 7).
- Nachhaltigkeit: wie das Projekt seine Nachhaltigkeitsziele erreicht (neu in PRINCE2 7).
- Digitales und Daten: wie mit Daten und digitaler Technologie umgegangen wird (neu in PRINCE2 7).
PRINCE2 nutzt außerdem einen Nutzenmanagement-Ansatz, der beschreibt, wie und wann der Nutzen gemessen wird, oft erst nach Projektabschluss.
Projektsteuerungsmittel und Toleranzen
Die Steuerungsmittel erklären, wie der Lenkungsausschuss die Kontrolle behält, ohne sich um Details zu kümmern: wie das Projekt in Managementphasen gegliedert wird, welche Toleranzen gelten, welche Berichte der Projektmanager wie oft erstellt und wann eine Ausnahme gemeldet werden muss. Toleranzen werden weiter unten ausführlicher behandelt.
PID vs. Projektauftrag, Business Case und Plan
Mehrere Dokumente zum Projektstart überschneiden sich. Die Tabelle zeigt, wo jedes davon hingehört.
| Dokument | Zweck | Wann | Genehmigt von |
|---|---|---|---|
| Projektbeschreibung (PRINCE2) | Kurzer Entwurf, auf dessen Grundlage über den Start der Initiierung entschieden wird | Vorbereitung | Lenkungsausschuss |
| Business Case | Rechtfertigt die Investition; wird durchgehend aktuell gehalten | Grobfassung bei der Vorbereitung, Detailfassung in der Initiierung | Auftraggeber oder Sponsor |
| Projektauftrag | Genehmigt formell das Projekt und den Projektmanager (im Stil des PMBOK) | Initiierung | Sponsor |
| Projektinitiierungsdokument | Vollständige Basis für die Genehmigung und Steuerung des Projekts (PRINCE2) | Initiierung | Lenkungsausschuss |
| Projektmanagementplan | Wie das Projekt durchgeführt, überwacht, gesteuert und abgeschlossen wird (im Stil des PMBOK) | Planung | Sponsor |
| Statement of Work | Vertragliche Beschreibung der Arbeit, die ein Lieferant erbringt | Einkauf | Käufer und Lieferant |
Am einfachsten merken Sie sich den Unterschied so: Ein Projektauftrag ist kurz und besagt, dass das Projekt genehmigt ist; ein PID ist länger und legt genau fest, was genehmigt wurde und wie es durchgeführt wird. Das PID enthält den Projektplan, umfasst aber auch Business Case, Teamstruktur und Managementansätze, die ein Plan allein nicht enthält.
A Leistungsbeschreibung ist wiederum etwas anderes: Sie regelt einen Vertrag mit einem externen Lieferanten, während das PID das Projekt intern regelt.
So erstellen Sie ein Projektinitiierungsdokument in 9 Schritten
Die folgende Reihenfolge passt für die meisten Projekte. In PRINCE2 finden diese Schritte im Prozess Initiieren eines Projekts statt; außerhalb von PRINCE2 bilden sie Ihre Initiierungsphase.
- Die Projektbeschreibung oder das Projektmandat prüfen. Bestätigen Sie Hintergrund, Ziele, Grob-Business-Case und alle Entscheidungen, die der Sponsor bereits getroffen hat. Prüfen Sie, ob die Ergebnisse einer etwaigen Machbarkeitsstudie berücksichtigt sind.
- Das Tailoring vereinbaren. Entscheiden Sie, wie formal das Projekt angesichts seiner Größe, seines Risikos und seiner Komplexität sein muss, und halten Sie diese Entscheidungen fest.
- Die Projektdefinition schreiben. Legen Sie Ziele, Umfang, Ausschlüsse, Lieferobjekte, Abnahmekriterien, Restriktionen, Annahmen und Schnittstellen zu anderen Projekten oder Systemen fest.
- Die Managementansätze definieren. Vereinbaren Sie, wie Qualität, Risiken, Issues und Änderungen, Kommunikation und weitere relevante Bereiche gesteuert werden. Legen Sie an dieser Stelle das Risikoregister an.
- Das Projektmanagementteam aufstellen. Benennen Sie Auftraggeber oder Sponsor, Benutzervertreter, Lieferantenvertreter und Projektmanager, jeweils mit Rollenbeschreibung. Eine RACI-Matrix macht die Verantwortlichkeiten klar.
- Den Projektplan erstellen. Gliedern Sie die Arbeit in Produkte oder Lieferobjekte, definieren Sie Phasen, schätzen Sie Aufwand, Kosten und Dauer und ermitteln Sie Meilensteine und Abhängigkeiten.
- Den Business Case verfeinern. Aktualisieren Sie Kosten, Zeitrahmen, Nutzen und Risiken anhand des detaillierten Plans. Nutzen Sie eine Kosten-Nutzen-Analyse dort, wo sie hilft.
- Steuerungsmittel und Toleranzen festlegen. Vereinbaren Sie Phasenübergänge, Berichtshäufigkeit, Toleranzen für Zeit, Kosten, Umfang und weitere Bereiche und wie Ausnahmen eskaliert werden.
- Zusammenstellen, prüfen und zur Genehmigung einreichen. Prüfen Sie, ob die Teile zueinander passen, lassen Sie die Projektsicherung eine Prüfung vornehmen und reichen Sie das PID dann zusammen mit einem Plan für die nächste Phase beim Lenkungsausschuss ein.
Beispiel für ein Projektinitiierungsdokument
Das folgende Beispiel dient der Veranschaulichung und ist vereinfacht. Es zeigt, wie die einzelnen Teile eines PID für eine mittelgroße Organisation aussehen könnten, die ihr CRM-System (Customer Relationship Management) ersetzt.
| PID-Abschnitt | Beispieleintrag |
|---|---|
| Hintergrund | Das aktuelle CRM wird vom Hersteller nicht mehr unterstützt und lässt sich nicht in das neue Finanzsystem integrieren. |
| Ziele | Das CRM bis zum 30. Juni ersetzen; alle aktiven Kundendatensätze migrieren; alle 85 Mitarbeitenden in Vertrieb und Service vor dem Go-live schulen. |
| Umfang | Umfasst Unterstützung bei der Auswahl, Konfiguration, Datenmigration, Integration ins Finanzsystem und Schulung. Ausgenommen sind Website und Marketing-Automatisierung. |
| Liefergegenstände | Konfiguriertes CRM; migrierte und validierte Daten; Integration ins Finanzsystem; Schulungsunterlagen; Übergabe an den Support. |
| Restriktionen und Annahmen | Budget fest bei £250.000; der Go-live darf nicht in den Jahresabschluss fallen. Annahme: Die API des Finanzsystems ist bis März verfügbar. |
| Zusammenfassung des Business Case | Vermeidet das Risiko, nicht mehr unterstützte Software zu betreiben; erwarteter Nutzen sind weniger manuelle Doppelerfassung und besseres Reporting für Vertriebsleiter. |
| Projektmanagementteam | Auftraggeber: Vertriebsleiter. Benutzervertreter: Leiterin Kundenservice. Lieferantenvertreter: Account Lead des CRM-Herstellers. Projektmanager: intern. |
| Managementansätze | Qualität: Abnahmetest durch die Nutzer, freigegeben vom Benutzervertreter. Risiko: monatliche Risikoüberprüfung. Änderungen: Änderungen über £5.000 gehen an den Lenkungsausschuss. |
| Projektplan | Vier Phasen: Initiierung; Konfiguration und Integration; Migration und Test; Schulung und Go-live. |
| Toleranzen | Zeit: plus/minus zwei Wochen. Kosten: plus/minus 5 %. Umfang: Must-have-Anforderungen dürfen nicht ohne Genehmigung des Lenkungsausschusses gestrichen werden. |
| Reporting | Statusbericht alle zwei Wochen an den Lenkungsausschuss; Phasenabschlussbericht an jedem Phasenübergang. |
| Tailoring | Der Lenkungsausschuss tagt monatlich statt bei jeder Entscheidung; es wird ein gemeinsames Risiko- und Issue-Log geführt. |
Jeder Eintrag ist so konkret, dass der Lenkungsausschuss ihn genehmigen oder hinterfragen kann. Vage Einträge wie „Kundendaten verbessern“ geben dem Lenkungsausschuss nichts an die Hand, woran er das Projekt messen kann.
Toleranzen und Steuern nach dem Ausnahmeprinzip
Toleranzen gehören zu den nützlichsten Teilen eines PID und werden zugleich am häufigsten weggelassen. Sie sind die vereinbarten Grenzen, innerhalb derer der Projektmanager Entscheidungen treffen kann, ohne den Lenkungsausschuss einzuschalten.
PRINCE2 legt Toleranzen für Bereiche wie Zeit, Kosten, Umfang, Qualität, Risiko und Nutzen fest. Typische Beispiele:
| Bereich | Beispieltoleranz |
|---|---|
| Zeit | Plus/minus zwei Wochen beim Go-live-Termin |
| Kosten | Plus/minus 5 % des genehmigten Budgets |
| Umfang | Could-have-Funktionen dürfen gestrichen werden, Must-haves nicht |
| Qualität | Festgelegte zulässige Fehlerquoten beim Go-live |
| Risiko | Kein einzelnes Risiko über einem vereinbarten Auswirkungswert ohne Prüfung durch den Lenkungsausschuss |
| Vorteile | Der erwartete Nutzen darf um einen vereinbarten Prozentsatz abweichen |
Wenn der Projektmanager prognostiziert, dass eine Toleranz überschritten wird, meldet er dem Lenkungsausschuss eine Ausnahme, statt abzuwarten, bis es so weit ist. So bleiben die Sitzungen des Lenkungsausschusses auf die Entscheidungen fokussiert, die ihn tatsächlich brauchen, und der Projektmanager hat für alles andere klare Befugnisse. Unser Leitfaden zum Projektstatusbericht zeigt, wie Sie über diese Grenzen berichten.
Das PID für kleine und agile Projekte anpassen
PRINCE2 erwartet, dass die Methode angepasst wird, und das gilt auch für das PID. Ein kurzes internes Projekt braucht kein 40-seitiges Dokument.
- Kleine Projekte: Fassen Sie Abschnitte zusammen, nutzen Sie eine einzige Seite für Definition und Plan und verweisen Sie bei Qualität, Risiko und Kommunikation auf die Standardansätze der Organisation, statt sie neu zu schreiben.
- Agile Projekte: PRINCE2 Agile nutzt weiterhin ein PID, das sich aber auf Ziele, Ergebnisse, Toleranzen und Arbeitsweisen konzentriert. Der detaillierte Umfang steht in einem priorisierten Backlog, und die Toleranzen erlauben meist Flexibilität beim Umfang, während Zeit und Kosten fest bleiben.
- Große oder risikoreiche Projekte: Behalten Sie das PID als steuernde Zusammenfassung und verlinken Sie separate Dokumente für den detaillierten Plan, die Register und die Ansätze.
Mehr dazu, wie Sie die PRINCE2-Governance mit agiler Lieferung verbinden, lesen Sie in PRINCE2 vs. Agile.
Häufige Fehler beim PID und wie Sie sie vermeiden
| Fehler | Was Sie stattdessen tun sollten |
|---|---|
| Eine lange Vorlage kopieren und jeden Abschnitt ausfüllen | Passen Sie die Struktur an und halten Sie fest, warum Abschnitte gekürzt oder entfernt wurden |
| Vage Ziele und vager Umfang | Formulieren Sie messbare Ziele und nennen Sie Ausschlüsse ausdrücklich |
| Keine Toleranzen oder Toleranzen von null | Vereinbaren Sie realistische Grenzen, damit das Steuern nach dem Ausnahmeprinzip funktioniert |
| Business Case einmal geschrieben und dann vergessen | Aktualisieren Sie ihn an jedem Phasenübergang und prüfen Sie, ob sich das Projekt noch lohnt |
| Rollen benannt, aber nicht erklärt | Schreiben Sie kurze Rollenbeschreibungen mit Entscheidungsrechten |
| Das PID nur als Papierkram für die Genehmigung betrachten | Nutzen Sie es in Sitzungen des Lenkungsausschusses, in Statusberichten und Phasenreviews |
| Es informell ändern | Ändern Sie das festgeschriebene PID nur über die Änderungssteuerung |
| Inhalte aus anderen Dokumenten duplizieren | Verweisen Sie auf Risikoregister, Plan oder Verträge, statt sie zu kopieren |
Vorlagen für Ihr PID
Wir bieten keine einzelne PID-Vorlage an, weil die meisten Inhalte ohnehin in Dokumenten stehen, die Sie sowieso erstellen. Diese kostenlosen Vorlagen decken die Hauptabschnitte ab, und Sie können sie zu Ihrem PID zusammenfügen oder verlinken:
- Vorlage für Projekt-Briefings für die Zusammenfassung bei der Vorbereitung.
- Business-Case-Vorlage für Gründe, Optionen, Kosten und Nutzen.
- Projektauftrag-Vorlage für Ziele, Umfang, Meilensteine und Rollen an einem Ort.
- Projektplan-Vorlage für Phasen, Aufgaben und Meilensteine.
- RACI-Matrix-Vorlage für das Projektmanagementteam und die Verantwortlichkeiten.
- Risikoregister-Vorlage und Vorlage für den Kommunikationsplan für zwei der zentralen Managementansätze.
Sobald Ihr PID genehmigt ist, besteht der nächste Schritt darin, die erste Lieferphase auf dieser Basis durchzuführen.
Kostenlose Vorlagen zu diesem Thema
Häufig gestellte Fragen
Was ist ein Projektinitiierungsdokument?
Ein Projektinitiierungsdokument (PID) ist die Sammlung von Informationen, die ein Projekt und seine Steuerung definieren: Projektdefinition, Business Case, Teamstruktur, Plan, Managementansätze, Steuerungsmittel und Tailoring. In PRINCE2 wird es vom Lenkungsausschuss genehmigt und bildet die Basis für das Projekt.
Wofür steht PID im Projektmanagement?
PID steht für Project Initiation Document (Projektinitiierungsdokument). PRINCE2 spricht von Project Initiation Documentation (Projektleitdokumentation), weil es ein einzelnes Dokument oder eine Reihe verknüpfter Dokumente sein kann.
Wer erstellt das PID?
Der Projektmanager stellt es zusammen, mit Beiträgen von Team, Nutzern, Lieferanten und Fachleuten. Der Auftraggeber oder Sponsor ist für den Business Case verantwortlich, und die Projektsicherung prüft das PID oft, bevor es an den Lenkungsausschuss geht.
Wer genehmigt das PID?
In PRINCE2 genehmigt der Lenkungsausschuss das PID, wenn er das Projekt im Prozess Lenken eines Projekts freigibt. Außerhalb von PRINCE2 erfolgt die Genehmigung meist durch den Sponsor oder einen Lenkungskreis.
Wann wird ein PID erstellt?
In der Initiierungsphase, nachdem der Lenkungsausschuss der Investition in die Initiierung zugestimmt hat und bevor die eigentliche Lieferarbeit beginnt.
Wird ein PID nur in PRINCE2 verwendet?
Nein. Der Begriff stammt aus PRINCE2, doch viele Organisationen, besonders im öffentlichen Sektor des Vereinigten Königreichs, nutzen PIDs unabhängig von ihrer Methode.
Was ist der Unterschied zwischen einem PID und einem Projektauftrag?
A Projektauftrag ist ein kurzes, übergeordnetes Dokument, das ein Projekt und seinen Projektmanager genehmigt. Ein PID ist detaillierter: Es ergänzt Business Case, Managementansätze, Steuerungsmittel, Toleranzen und den Projektplan und dient als vollständige Basis des Projekts.
Was ist der Unterschied zwischen einem PID und einem Projektplan?
Der Projektplan umfasst Phasen, Produkte, Meilensteine, Ressourcen, Kosten und Zeitrahmen. Das PID enthält den Projektplan sowie Projektdefinition, Business Case, Teamstruktur, Managementansätze und Steuerungsmittel.
Wie lang sollte ein PID sein?
Es gibt keine feste Länge. Ein kleines Projekt mit geringem Risiko braucht vielleicht nur wenige Seiten, ein großes Programm dagegen ein umfangreiches Dokument mit Verweisen auf separate Pläne und Register. Passen Sie es an Größe und Risiko des Projekts an.
Kann das PID nach der Genehmigung geändert werden?
Ja, aber nur über die Änderungssteuerung. In PRINCE2 aktualisiert der Projektmanager das PID üblicherweise an den Phasenübergängen zur Prüfung durch den Lenkungsausschuss, und jede Änderung der Basis muss vom Lenkungsausschuss genehmigt werden.
Brauchen agile Projekte ein PID?
PRINCE2 Agile nutzt weiterhin ein PID, meist kürzer und mit Fokus auf Ziele, Toleranzen und Arbeitsweisen. Der detaillierte Umfang steht in einem priorisierten Backlog statt im PID selbst.
Was sind Toleranzen in einem PID?
Toleranzen sind vereinbarte Grenzen für Bereiche wie Zeit, Kosten, Umfang, Qualität, Risiko und Nutzen. Innerhalb dieser Grenzen kann der Projektmanager handeln, ohne zu eskalieren; wird eine Überschreitung prognostiziert, meldet er dem Lenkungsausschuss eine Ausnahme.
Wie unterscheidet sich ein PID von einer Leistungsbeschreibung?
Ein PID regelt ein Projekt intern und wird vom Lenkungsausschuss oder Sponsor genehmigt. Eine Leistungsbeschreibung beschreibt Arbeit, die ein externer Lieferant auf Grundlage eines Vertrags erbringt.