PRINCE2 Agile – Alles was man wissen muss
Eine fachliche Auseinandersetzung mit der Verbindung von verbindlicher Projektsteuerung und agilen Arbeitsweisen.
Von Dr. Markus Groß
GEDANKEN & FACHLICHE EINORDNUNG
Blog
Impulse zu Governance, Informationssicherheit und KI.
8 Minuten Lesezeit
(1521 Worte)
FACHARTIKEL / IT
Ein Überblick zu PRINCE2
Effektives und effizientes Projektmanagement ist in der heutigen Zeit nicht mehr wegzudenken . Ein Projekt zeichnet sich durch Einmaligkeit und einen definierten und begrenzten „Lebenszyklus“ aus. Daneben besitzt ein Projekt die Merkmale, dass ein definiertes Ziel mit definierte und messbare Anforderungen gibt. Zumeist müssen diese Ziele mit begrenzte Ressourcen und vor allem begrenzter Zeit erreicht werden. Um diese Anforderungen zu steuern bedarf es einer strukturierten Methode.
PRINCE 2 ist eine Methode, die ein skalierbares Vorgehensmodell definiert, welches aus erfolgreichen und gescheiterten Projekten abgeleitet wird. Es werden hierbei Prozesse, Komponenten, Techniken definiert, wobei jedoch das was nicht benötigt wird, weggelassen werden kann um unnötige Bürokratie zu vermeiden. Der Vorteil dieser Methode liegt darin, dass das Vorgehensmodell generisch ist und sich nicht nur – wie oft bei modernen Vorgehensmodellen – auf den Bereich der IT, sondern auch z.B. bei Bau oder Organisationsprojekten angewendet werden kann. Die Rechte an dem begriff und den Grundlagen der PRINCE2 Methodik liegen bei der OGC (Office of Government Commerce). Wobei der inhaltliche Input und die Fortschreibung des Konzeptes offen vorliegt und weltweite Best-Practices enthält. Dass OGC trägt auch die Verantwortung für Zertifizierungen von Projektleitern und Organisationen
Nach PRINCE2 ist daher ein Projekt folgendermaßen beschrieben:
a management environment that is created for the purpose of delivering one or more business products according to a specified business case
oder
a temporary organisation that is needed to produce a unique and predefined outcome or result at a prespecified time using predetermined resources
Ein Projekt wird immer durch einen geschäftliche Rechtfertigung also einen "Business Case" getrieben, das heißt, es muss einen (in der Regel) wirtschaftlichen Nutzen bringen. Entfällt die Grundlage für den Business Case, ist die Grundlage des Projektes entfallen und das Projekt muss – nach PRINCE2 - abgebrochen werden. Wichtig: Kein Projekt darf fortgeführt werden, nur weil niemand daran denkt, es zu stoppen.
Nach PRINCE2 und aus der praktischen Erfahrung sind die Gründe für das Scheitern eines Projekts der fehlender Business Case, unklare Aufgabenstellung und messbare Abnahmekriterien sowie unklare Rollenzuweisung und Verantwortung. Außerdem führt fehlerhaftes (fehlendes) Risikomanagement, fehlender Überblick über den Projektfortschritt und schlechte Planung zumeist zum Abbruch von zunächst erfolgversprechenden Projekten. Daneben sind oft schlechte bzw. fehlende Kosten und Zeitschätzung (mangelnde Ressourcen) Gründe für den vorzeitigen Abbruch. Nutzen einer Projektmanagement Methode. Eine Projektmanagement Methode kann: nicht den Erfolg eines Projektes garantieren aber durch systematische Planung/Vorbereitung verhindern, dass ein Projekt an simplen Planungs- und Organisationsfehlern scheitert eine verständliche Vorgehensweise bereitstellen, in der jeder Beteiligte seine Rolle und Verantwortung kennt. sicherstellen, dass die zu liefernden Produkte und Dokumente bekannt sind.
Eine Methode stellt den Rahmen und die organisatorischen Mittel, bis hin zu Dokumentvorlagen für Zie Abwicklung eines Projektes bereit Prozess und Produktbeschreibungen sind wie Checklisten und helfen dabei, nichts Wesentliches zu vergessen. Verfahren, Organisation und Begriff innerhalb einer Organisation, die eine Methode anwendet, werden vereinheitlicht. Diese Methode kannwiederholt und gelehrt werdenund erlaubt das Lernen aus Erfahrungen und gemachten Fehlern.
Der Name PRINCE2 steht für PRojects In Controlled Environment, wobei das 2 für die zweite Version der Prozßmethode steht. Im Jahr 2009 wurde PRINCE2 noch einmal von Grund auf renoviert, wobei redundante Teile entfernt wurden um die Methodik noch flexibler nutzbar zu machen. Seither ist die offizielle Bezeichnung PRINCE2:2009. Die international anerkannte Methode
- ist wiederholbar und kann gelehrt werden
- ist flexibel und kann an die Anforderungen des Projekts angepasst werde
- stellt sicher, dass der Bezug zum Geschäft nicht verloren geh
- geht durch "management by exception" sparsam mit der Zeit der Beteiligten um. Unnötige Routine entfällt
Die Prozesse definieren die Rollen und die damit verbundene Verantwortung für die Projektbeteiligten.Ein Projekt nach PRINCE2 benötigt und liefert in seinen Prozessen folgende Produkte:
- Spezialisten-Produkte (business products), die zu liefern das eigentliche Ziel des Projektes ist. Sie werden durch die Produkt-Spezialisten geliefert
- Management-Produkte wie Produktstrukturpläne, Projektpläne, Qualitätspläne etc. Sie dienen der Abwicklung und Dokumentation
- des Projektes und werden durch das Projektmanagementteam erstellt
Der Projektablauf bei PRINCE2 wird in mehre Phasen eingeteilt:
- Bei jedem Phasenübergang werden Business Case, Risikonalyse, Projektplan etc. überprüft und dem Lenkungsausschuss Bericht erstattet.
- Der Lenkungsausschuss genehmigt den Start in die nächste Phase auf Grundlage des vom Projektleiter vorgelegten Plans oder bricht das Projekt bei einem fehlenden Business Case ab.
- Während der Phase wird der Lenkungsausschuss (LA) nur bei Bedarf involviert (ad hoc Berichte/Anfrage). Der Projektmanager agiert selbstständig im Rahmen der vom Lenkungsausschuss gesetzten Toleranzen (management by exception).
- Jedes Projekt wird mit dem Prozess su vorbereitet, das Team zusammengestellt, der Projektlösungsansatz festgelegt, der Aufwand für die Projektinitialisierung abgeschätzt etc. Der Lenkungsausschuss (LA) verwendet den Prozess dp.
- ip initialisiert. Das Projektteam wird zusammengestellt, der Projektplan, die Risikoanalyse, Qualitätsanforderungen etc werden verfeinert. Der LA entscheidet (dp), die Realisierung des Projektes zu genehmigen.
Managemententscheidungen und Lieferarbeit ausdrücklich verbinden. Legen Sie für einen Projektabschnitt fest, welches Ergebnis benötigt wird und wann eine Abweichung eskaliert werden muss. So lassen sich Projektsteuerung und anpassungsfähige Umsetzung an einem konkreten Fall beurteilen.
Die Projektphasen werden mit cs (controlling a stage), durch den Projektmanager gesteuert und durch sb (managing stage boundaries) abgeschlossen. Der Projektmanager aktualisiert Pläne und Analysen und erstattet dem Lenkungsausschuss Bericht. Dieser entscheidet über die Fortsetzung des Projektes, oder den Abbruch. Bis zum Projektabschluss werden die beiden genannten Phasen cs und sb wiederholt. Mit dem Prozess cp (closing a project) wird das Projekt abgeschlossen
Unter dem Management by exception bei PRINCE2 versteht man, dass Routineberichte und regelmäßige geplante Meetings bei PRINCE2 nicht vorgesehen sind, weil die Mitglieder des Lenkungsasuschusses nicht mit Routine belastet werden sollten. Nur in Ausnahmesituationen (und bei Phasenübergängen) wird der Lenkungsausschuss involviert. Werden die vom Lenkungsausschuss und dem Projektlieter gesetzten Toleranzen absehbar überschritten, erstellt der Projektleiter einen sogenannten Ausnahmeplan (exception plan), mit dessen Hilfe das Projektziel erreicht werden soll. Der Lenkungsausschuss entscheidet, das Projekt ab zu brechen oder auf Basis des Ausnahmeplans mit neuem Terminplan, Ressourcen und ggf. Qualitätsanforderungen weiter zu führen.
Zusammengefasst sind die Besonderheiten von PRINCE2:
- Management by exception: Es gibt keine Routine, Meetings oder Reports. Der Lenkungsausschuss wird nur bei Phasenübergängen und (absehbarer) Toleranzüberschreitung (siehe unten) involviert.
- Der Projektmanager bekommt vom Lenkungsausschuss Toleranzen gegenüber den Planwerten, bis zu denen er eigenständig entscheiden darf (und muss). Sobald die Überschreitung der Toleranz absehbar ist, wird der Lenkungsausschuss involviert.
- Die Abläufe und Dokumente können bei PRINCE2 den Bedürfnissen des Projektes angepasst werden.
Vertiefung: Ein Überblick zu PRINCE2
Die damalige Beobachtung zu „Ein Überblick zu PRINCE2“ wird hier nicht ersetzt, sondern praktisch weitergedacht. Im Fokus stehen bei Wirkungsprüfung überprüfbare Voraussetzungen, erkennbare Grenzen und ein im Alltag belastbarer Umgang.
Ein Überblick zu PRINCE2 – Integration praktisch fassen
Der Ausgangspunkt dieses Beitrags führt beim Aspekt „Ein Überblick zu PRINCE2“ zu einer klaren Prüffrage: Es ist zu klären, welcher bestehende Prozess den neuen Prüfschritt sinnvoll aufnehmen kann. Beim Schwerpunkt „Ein Überblick zu PRINCE2“ geht es um ein Management- oder Governance-Framework und seine praktische Nutzung sowie um den Bezug zu „Methodenumfang“; zu entscheiden ist, welcher Baustein ein konkretes Organisationsproblem löst (hier bezogen auf „Verbesserungsschritt“), ohne das Framework zum Selbstzweck zu machen. Als fachliche Leitplanke gilt: Ein Framework liefert Orientierung (hier bezogen auf „Integration“); Verantwortung für Auswahl, Anpassung und Wirkung bleibt bei der Organisation. Für die belastbare Umsetzung gilt als Auftrag: Beschaffung, Berechtigung, Änderung oder Offboarding gezielt erweitern; als Bezugspunkt dient „Rollenklarheit“. Der Prüfpfad endet nicht beim Dokument; „Verbesserungsschritt“ liefert dafür den praktischen Anwendungsfall. Als Verbindung zwischen Nachweis und Messung dienen: ein eingebetteter Kontrollpunkt ohne parallelen Sonderprozess; Entscheidungsdauer, Ergebnisqualität, Nacharbeit, Rollenklarheit und nachweisbare Verbesserung. Die Leserperspektive auf „klare Zuständigkeiten und Entscheidungsrechte“ schärft den Blick dafür, ob „Methodenumfang“ nur beschrieben oder tatsächlich gesteuert wird.
Gegenposition im Blick: Rollenklarheit
Der Beitrag gewinnt beim Aspekt „Methodenumfang“ an Aktualität, sobald sein Kerngedanke in eine heutige Entscheidung übersetzt wird: Es ist zu klären, welches stärkste sachliche Argument gegen die bevorzugte Lösung spricht. Beteiligt sind hier vor allem Management, Prozess- und Serviceverantwortliche, Projektteams, Governance-Funktionen und Revision; ihre Perspektiven treffen beim Aspekt „Rollenklarheit“ unmittelbar aufeinander. Kritisch wird die Lage insbesondere dann, wenn Terminologie und Prozessbilder wachsen (hier bezogen auf „Reifeentwicklung“), während Entscheidungen, Leistungen oder Kontrollen unverändert schwach bleiben. Im Regelbetrieb wird folgender Punkt verankert: Gegenargumente nicht abwehren, sondern als Belastungstest verwenden; im vorliegenden Abschnitt wird dies an „Anpassungstiefe“ konkretisiert. Die Dokumentation hält zwei Dinge fest – eine dokumentierte Abwägung mit verbleibender Unsicherheit; zusätzlich sichtbar wird: der Zusammenhang zwischen „Methodenumfang“ und „Rollenklarheit“. Eine brauchbare Gegenprobe ist die Frage, ob dieselbe Entscheidung bei einer Störung rund um „Methodenumfang“ noch nachvollziehbar wäre.
Messgröße ohne blinden Fleck bei „Anpassungstiefe“
Der konkrete Nutzen von „Managementbedarf“ zeigt sich erst, wenn eine offene Annahme überprüft wird: Es ist zu klären, welcher Wert eine konkrete Reaktion auslösen kann. Als belastbare Grundlage dienen Zielproblem, ausgewählte Praktiken, Rollenentscheidung, Arbeitsergebnisse, Abweichungen und Verbesserungsnachweise; für den Aspekt „Managementbedarf“ muss ihre Herkunft nachvollziehbar bleiben. Die Entscheidung über „Anpassungstiefe“ sollte deshalb ausdrücklich festhalten, welcher Baustein ein konkretes Organisationsproblem löst (hier bezogen auf „Anpassungstiefe“), ohne das Framework zum Selbstzweck zu machen. Operativ folgt daraus: Definition, Quelle, Schwelle, Eigentümer und Konsequenz gemeinsam festlegen; im vorliegenden Abschnitt wird dies an „Prozessnutzen“ konkretisiert. Die Dokumentation hält zwei Dinge fest – eine Kennzahl mit erklärbarer Datenherkunft und Entscheidung; zusätzlich sichtbar wird: die beobachtbare Veränderung beim Aspekt „Tests und Lernen aus erkannten Abweichungen“. Für den Dialog unter dem Beitrag ist „Tests und Lernen aus erkannten Abweichungen“ der passende Belastungstest: Gerade beim Aspekt „Anpassungstiefe“ muss die Regel im Alltag tragen.
Als Abschluss für Ein Überblick zu PRINCE2 genügen drei verbindliche Antworten zu Methodenumfang: Wer entscheidet über Managementbedarf, woran wird Wirkung bei Wirkungsprüfung erkannt und welcher Auslöser führt zur erneuten Prüfung? Sind diese Punkte geklärt, wird aus dem historischen Impuls zu Rollenklarheit eine belastbare Arbeitsgrundlage.
| Hinweis: Teile dieses Beitrags könnten unter Einsatz von KI-gestützten Tools erstellt oder überarbeitet worden sein. Weitere Informationen finden Sie im Impressum/Disclaimer. | Marken- und Bildrechte: Dargestellte Logos und genannten Marken liegen ausschließlich bei den jeweiligen Rechteinhabern. Nutzung erfolgt ausschließlich zu illustrativen Zwecken. |
PERSPEKTIVE & DIALOG
Beitrag bewerten
Deine Bewertung hilft bei der Einordnung der Inhalte.
Wissen weitergeben
Interessant für dein Netzwerk? Teile den Beitrag direkt.
Blog-Beitrag abonnieren
Wenn Sie den Blog-Beitrag abonnieren, senden wir Ihnen eine E-Mail, sobald es Updates auf dieser Website gibt.
Über den Autor
FACHMAGAZIN
Perspektiven. Governance. Einordnung.
Kommentare 29
Ein hilfreicher Einstieg in das Thema. Wie lassen sich kurze Arbeitszyklen und klare Verantwortlichkeiten gut miteinander verbinden?
Die Entscheidungsrechte sollten klar bleiben, auch wenn sich die Arbeit flexibel organisiert. Regelmäßige Rückmeldungen machen offene Punkte früh sichtbar.
Ein begrenzter Start ist sinnvoll. Entscheidend wäre für mich, in kurzen Arbeitszyklen vorab die Bedingungen für eine Ausweitung zu benennen. So wäre auch bei veränderten Voraussetzungen klar, was zu tun ist.
Wie wird aus der Methode mehr als eine neue Bezeichnung für die bisherigen Besprechungen?
Für mich liegt der Schwerpunkt hier: Für mich müsste sich zeigen, dass Rückmeldungen wirklich Entscheidungen verändern. Neue Termine allein schaffen noch keine bessere Zusammenarbeit.
Könnte diese Lösung nicht gerade bei kleinen Teams zu viel Aufwand verursachen? Ich würde die Mindestanforderung deutlicher abgrenzen. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Ich würde die Ausnahme nicht verstecken, sondern mit Begründung, zuständiger Person und Prüfanlass festhalten. Dann kann man auch später erkennen, ob die Grundlage noch gilt. Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Der Beitrag trifft einen wichtigen Punkt. Mich würde interessieren, woran sich der praktische Nutzen des beschriebenen Vorgehens zuerst erkennen lässt. Welche Mindestinformation sollte dafür immer vorliegen?
Ich würde zunächst einen konkreten Ablauf auswählen und dort Ausgangslage, Entscheidung und Ergebnis gegenüberstellen. Sonst bleibt die Bewertung leicht abstrakt.
Für mich gehört noch ein fester Zeitpunkt zur Nachprüfung dazu. Erst dann lässt sich beurteilen, ob die Maßnahme nur erledigt wurde oder tatsächlich etwas verbessert hat.
Das ist die wesentliche Abgrenzung. Eine Dokumentation zeigt zunächst nur, was vorgesehen oder getan wurde; erst die überprüfte Wirkung macht daraus einen Steuerungsimpuls.
Damit wird es für mich deutlich greifbarer. Vor allem die vorher festgelegte Entscheidungsfolge verhindert, dass der Pilot nur als zusätzlicher Bericht endet.
Spannend ist für mich, wie schlanke Governance für agile Arbeit in bestehende Abläufe passt. Eine zusätzliche Parallelstruktur wäre vermutlich schwer dauerhaft zu betreiben.
Welche minimale Lösung wäre für Verbindlichkeit von Qualitätskriterien vertretbar, wenn ein kleines Team mehrere Rollen gleichzeitig übernimmt?
Ich würde die Rollen dennoch getrennt dokumentieren und für die kritische Entscheidung einen zweiten Blick vorsehen. Entscheidend wäre für mich, ob das Ergebnis für den konkreten Fall nachprüfbar bleibt. Bei Verbindlichkeit von Qualitätskriterien sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Aus der Praxis würde ich besonders auf schlanke Governance für agile Arbeit achten. Ohne klare Verantwortung bleibt selbst ein guter Ansatz unverbindlich.
Wie aussagekräftig ist eine Zertifizierung für die praktische Arbeit im Team?
Mein Vorschlag wäre: Als Nachweis von Grundlagenwissen kann sie hilfreich sein. Die Anwendung und der Umgang mit Konflikten müssten zusätzlich betrachtet werden.
Hier würde ich widersprechen: Ein zusätzlicher Prozess kann auch neue Reibung schaffen. Welche vorhandene Aufgabe könnte man damit zusammenführen? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Für mich müsste sich zunächst erklären lassen, welche Entscheidung verbessert werden soll. Daraus würde ich den notwendigen Umfang ableiten, statt mit der maximalen Dokumentation anzufangen. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Damit kann ich mehr anfangen. Die Grenze zwischen einem hilfreichen Nachweis und zusätzlichem Papier bleibt für mich der entscheidende Punkt. Die Ausgangsfrage „Wie aussagekräftig ist eine Zertifizierung für die praktische Arbeit im Team?“ ist damit für mich noch nicht vollständig beantwortet.
Das ist mir als Maßstab noch etwas zu weich. Welches Ergebnis müsste sich nach der Änderung nachweisbar verbessern? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Interessant finde ich hier vor allem schlanke Governance für agile Arbeit. Ein kleiner, sauber ausgewerteter Pilot wäre aussagekräftiger als eine breite Papierlösung.
Für schlanke Governance für agile Arbeit sollte feststehen, welche Annahmen der Bewertung zugrunde liegen. Sonst wird ein Status zu lange fortgeschrieben.
Ein weiterer Punkt: Wie geht man mit Vorgaben um, die den Handlungsspielraum des Teams tatsächlich begrenzen?
Für mich liegt der Schwerpunkt hier: Die Grenzen würde ich transparent machen. Innerhalb dieser Grenzen sollte das Team aber echte Entscheidungsmöglichkeiten behalten.
Ich würde das nicht allein anhand einer Beschreibung beurteilen. Was wäre ein überzeugender praktischer Nachweis?
Wie lässt sich bei Umgang mit Risiken im kurzen Lieferzyklus vermeiden, dass offene Punkte zwischen mehreren Zuständigkeiten liegen bleiben?
Ich würde den offenen Punkt mit einem Verantwortlichen, einem Termin und einem überprüfbaren Ergebnis verbinden. Bei mehreren Beteiligten sollte außerdem klar sein, wer eine Entscheidung herbeiführt. Für Umgang mit Risiken im kurzen Lieferzyklus würde ich den ersten Prüfschritt bewusst klein halten.