

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
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:
Der Projektablauf bei PRINCE2 wird in mehre Phasen eingeteilt:
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:
| 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. |
Wenn Sie den Blog-Beitrag abonnieren, senden wir Ihnen eine E-Mail, sobald es Updates auf dieser Website gibt.

Kommentare 26
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.
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.
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.
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.
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.