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.
{tmamazon asin="B0HNGRQ94Z" layout="mini" align="left" label="PRINCE2 Agile – Alles was man wissen muss" text="Eine fachliche Auseinandersetzung mit der Verbindung von verbindlicher Projektsteuerung und agilen Arbeitsweisen. Die Themen reichen von klaren Verantwortlichkeiten über Entscheidungsprozesse bis zur verlässlichen Lieferung." shorttext="Eine fachliche Auseinandersetzung mit der Verbindung von verbindlicher Projektsteuerung und agilen Arbeitsweisen." image="images/mg-publikationen/cover/buch-prince2-agile-alles-was-man-wissen-muss-steuerung-agilitaet-liefe.jpg" book="1" note="Von Dr. Markus Groß" price="0" rating="0" count="0" features="0" disclosure="1"}
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.