COMPUTERWOCHE-Serie „PRINCE2“

Dieser Artikel von Fachautor Martin Rother stellt den ersten Teil einer dreiteiligen COMPUTERWOCHE-Serie dar, die sich mit dem Projekt-Management-Standard „PRINCE2“ beschäftigt. Rother setzt sich kritisch mit der Best Practice Management Methode auseinander und gibt einen Rundum-Blick über Inhalte, Strukturen, Nutzen, Ziele und Zielgruppen::

Kürzlich wurde die Version 2009 von „PRINCE2“ vorgestellt. Die Projekt-Management-Methode setzt sich allmählich auch bei den Anwendern durch. Aber was ist daran eigentlich so besonders?

Die Abkürzung bedeutet "Projects in Controlled Environments", auf deutsch: "Projekte unter Kontrolle". PRINCE21 ist also eine Methode für das Management von Projekten. 1996 erschien sie in der Version 2. Sie ist Eigentum der britischen Regierung, namentlich des Office of Government Commerce2 (OGC). Eine überarbeitete Ausführung wurde kürzlich – genauer gesagt: am 16. Juni 2009 – veröffentlicht.

Mit der Ausbildung und Zertifizierung ist ein britisches Unternehmen, die APMG3 Ltd., beauftragt. Sie betreibt weltweit das Ausbildungs- und Zertifizierungsgeschäft aller OGC-Methoden; dazu zählen PRINCE2, ITIL4, MSP für das Programm-Mangement und MoR für das Risiko-Management sowie diverse Ergänzungen. Jede Ausbildungsorganisation muss sich bei der APMG akkreditieren lassen und ist dann als akkreditierte Trainingsorganisation (ATO) berechtigt, Schulungen und Zertifizierungen vorzunehmen. Die PRINCE2-Ausbildung ist zweigeteilt; sie besteht aus einem „Foundation“-Teil, der den Überblick über die Methode vermitteln soll, und dem „Practitioner“, der sich der Anwendung widmet.

  • Fehlerhafte Hartz-IV-Software (2004): Zum Start der Arbeitsmarktreform Hartz IV streikte die Software, die das Arbeitslosengeld für Langzeitarbeitslose berechnete. Die von T-Systems entwickelte Anwendung „A2LL“ lief nicht stabil und löste Rechnerabstürze aus. Zudem wurden Zuschläge falsch berechnet, Datenfelder fehlten oder waren für die Erfassung gesperrt. Außerdem kam es bei der Berechnung der Krankenversicherungsbeiträge zu Rundungsfehlern. Später wurde bekannt, dass eine nachgelagerte Software kurze Kontennummern falsch auffüllte. Statt Nullen voranzustellen, wurden sie hinten angehängt. Dadurch waren Konten nicht zuzuordnen.
  • Hartz-IV-Softwarepanne, die Zweite (2006): Im Dezember 2006 streikte die Software erneut, eine Bearbeitung von Erst- und Fortzahlungsanträgen für das Arbeitslosengeld 2 (ALG2) war nicht mehr möglich. Die Probleme tauchten auf, nachdem ein Update eingespielt wurde, hieß es zunächst. T-Systems wehrte sich allerdings gegen den Vorwurf, eine fehlerhaft implementierte Dialog-Software sei der Grund für die Pannenserie. Vielmehr sei das Problem durch ein Datenbank-Update hervorgerufen worden, betonte die Telekom-Tochter.
  • EDS und die britische Kindergeld-Behörde (2004): Der US-amerikanische IT-Dienstleister scheiterte 2004 spektakulär in Großbritannien und bescherte dem Steuerzahler einen Verlust von etwa einer Milliarde Pfund. EDS war beauftragt worden, für die britische Behörde Child Support Agency (CSA), die das Kindergeld auszahlt, ein neues IT-System zu entwickeln, das das Verfahren beschleunigt. Die implementierte Lösung CS2 überwies etwa 1,9 Millionen Berechtigten zu viel Geld, rund 700 000 bekamen allerdings zu wenig. Grund dafür war nicht allein die Software, denn zeitgleich hatte die britische Regierung die CSA reformiert.
  • Die Explosion der Ariane 5 (1996): Innerhalb von Sekunden zerbarst im 1996 Europas ehrgeizige Ariane 5-Mission. Die unbemannte Rakete explodierte 30 Sekunden nach dem Start vom Weltraumbahnhof Kourou in Französisch-Guayana, nachdem sie zuvor von ihrem Kurs abgekommen war. An Bord waren vier Satelliten im Wert von 500 Millionen Dollar. Später veröffentlichte die New York Times den Grund für die Panne. Die Ariane 5 nutzte die gleiche und bewährte Software wie ihr Vorgängermodell, die Ariane 4. Die neue Trägerrakete war jedoch schneller und konnte eine größere Nutzlast transportieren, dadurch fielen deutlich mehr und höhere Flugdaten an, die verarbeitet werden mussten. Letzten Endes löste die Umwandlung von Gleitkommazahlen in ganzzahlige Werte einen Overflow aus und setzte damit eine Fehlerkette in Gang. Das redundante System der Ariane 5 konnte die Katastrophe nicht verhindern. Es nutzte die gleiche Software.
  • Panne in der Entwicklung des Airbus A380 (2006): Die verteilte Fertigung bei Airbus brachte es mit sich, dass in verschiedenen Werken unterschiedliche Software verwendet wurde. Peinlich wurde dies, als die Werke unterschiedliche Versionen der CAD-Software Catia verwendeten. In Hamburg arbeiteten die Ingenieure mit einer älteren Version, im französischen Toulouse kam die aktuellste Ausführung zum Einsatz, die allerdings nicht abwärtskompatibel war. Als die an den jeweiligen Standorten entwickelten und gefertigten Teile zusammengeführt werden sollten, passten die Verkabelungsbäume nicht zueinander. Die Auslieferung des Airbus verzögerte sich um acht Monate.
  • Das Jahr-2000-Problem (1999/2000): Für die IT-Industrie wurde der Jahrtausendwechsel zum großen Fest. Sie verdiente prächtig an einem Fehler (beziehungsweise einer Unzulänglichkeit), den sie selbst mitverursacht hatte. Weil in den frühen Jahren der IT Speicherplatz teuer war, wurden Jahreszahlen nur zweistellig dargestellt. Die Zahlenkombination „00“ bezeichnete also sowohl das Jahr 1900 als auch das Jahr 2000. Zum Teil wurden auch ungültige Datensätze mit der Doppelnull gefüllt. Viele Anwenderunternehmen fürchteten finanziellen Schaden aufgrund falscher Berechnungen. Zudem drohten Computerabstürze und Sicherheitslecks in Anwendungen von Banken, Industrieanlagen und Kernkraftwerken.
  • Millionengrab Fiscus (1993 bis 2005): Zum Fass ohne Boden entwickelte sich das Föderale Integrierte Standardisierte Computer-Unterstützte Steuersystem (Fiscus). Mehr als zwölf Jahre strebten die deutschen Bundesländer an, eine einheitliche Steuersoftware für rund 650 Finanzämter einzuführen. Dafür verbrauchten sie geschätzte 900 Millionen Euro. Ein brauchbares Ergebnis kam nicht dabei heraus. Die Anfänge nahm Fiscus im Jahr 1993. Die Bundesländer wollten die parallele Entwicklung mehrerer Lösungen zentralisieren, um Kosten zu sparen. Zudem sollten die ausufernden Altsysteme durch eine neue, moderne Applikation ersetzt werden. Während der Entwicklungsarbeiten wurden mehrfach die technischen Zielrichtungen verändert (etwa von der strukturierten zur objektorientierten Entwicklung). Schwierigkeiten bereitete zudem das Kompetenzgerangel zwischen den Bundesländern. 2005 wurde die eigens für das Projekt gegründete Fiscus GmbH liquidiert und das neue Projekt „Konsens“ gestartet.
  • Fiasko mit Personalausweisen in Großbritannien (1999): Im Juli 1999, ausgerechnet während der Ferienzeit, konnte die britische Passport Agency keine Reisepässe ausstellen. Statt der üblichen 50.000 warten damals 500.000 Ausweisanträge auf ihre Bearbeitung. Mehrere hundert Urlauber mussten ihre Reise stornieren, der finanzielle Schaden für die Behöre belief sich auf mehr als zwölf Millionen Pfund. Grund war die von Siemens entwickelte Software „Pass“. Siemens pochte darauf, man habe eine Anwendung nach den vereinbarten Vorgabe geliefert. Später räumte die Behörde Mängel im Test und in den Schulungen ein. Parallel zur Softwareeinführung führte die britische Regierung die Ausweispflicht für Kinder bei Auslandsreisen ein. Keine Pässe für britische Bürger.
  • Hessens Desaster mit der Schulsoftware (2007): Das Bundesland Hessen erlebte mit der Einführung der neuen Schulverwaltungssoftware LUSD (Lehrer- und Schülerdatenbank) ein Desaster. Ziel der Software war eine zentrale Verwaltung aller Schüler und Lehrerdaten. Mit der Implementierung in den Schulen startete der beauftragte IT-Dienstleister CSC im Oktober 2006. Zur Eskalation kam es im Herbst 2007, als die betroffenen Schulsekretariate sich über anhalte Performance-Probleme beschwerten und sich die Mängel zum Politikum entwickelten. Ursache der Leistungsprobleme war offenbar eine nicht sauber implementierte 3-Tier-Architektur aus Web-Client, Application- und Datenbank-Server. Im Laufe des Entwicklungsprojekts wurde Prozess- beziehungsweise Business-Logik auf dem Datenbank-Server statt auf dem Application-Server abgebildet.
  • Bremen ringt mit der SAP-Einführung (2003): Am 6. Januar 2003 teilte die Hansestadt Bremen offiziell mit, dass man als erstes Bundesland flächendeckend Geschäftsprozesse mit SAP R/3 abbilden will. Mit einem Etat von 13 Millionen Euro hatte die Stadt SAP-Module etwa für das Controlling, Finanzwesen, die Buchhaltung und die Materialwirtschaft eingeführt. Die Rechnungsprüfer warnten mehrfach vor einer vorschnellen Implementierung und wurden offenbar nicht erhört. Im Betrieb gab es dann Probleme mit den Schnittstellen, mit denen die Fachverfahren der Ressorts an das SAP-System angebunden wurden. Noch im März berichteten betroffene Mitarbeiter, dass kaum ein Fachverfahren reibungslos funktioniere.
  • Die Münchner Stadtwerke scheitern am SAP-Umstieg (2002): Von August 2001 bis März 2002 konnten die Münchner Stadtwerke keine Rechnungen verschicken. Das Unternehmen hatte im Herbst 2001 zwei neue Applikationen eingeführt, unter anderem eine Lösung für Energieversorger von der SAP, die offenbar noch nicht ausgereift war. Zudem habe die schlechte Qualität der Altdaten enorme Probleme bereitet, hieß es damals. Unterm Strich kam die Einführung zu früh. Die Verantwortlichen hatten auf eine schnelle Implementierung gedrängt, weil sie das seit 1979 genutzte R/2-System von SAP nicht mehr von D-Mark auf Euro umstellen wollten.

PRINCE2 ist kein „Body of Knowledge“ wie PMBOK5, also eine Sammlung von „Good Practices“ (was man alles tun könnte), sondern eine Methode, die vom Start bis zum Ende eines Projekts festlegt, was zu tun ist. Dabei stützt sich PRINCE2® nicht auf akademische Modelle, sondern auf in der Praxis bereits bewährte Verfahren. Die Methode trennt scharf das Management von Projekten und die Herstellung von „Produkten“. Sie sagt nicht, wie etwas hergestellt wird, sondern was, von wem und wann. Deshalb arbeitet sie harmonisch mit jeder Produktherstellungs-Methode zusammen. So schließt PRINCE2® eine Lücke im Projektmanagement.6 Die Methode gibt Antwort auf die Frage, wie Projekte gemanagt, gesichert und gelenkt werden.

Was ist eigentlich ein Projekt?

Ein Projekt ist eine Aufgabe, deren Ausführung gesteuert werden muss. Dabei handelt es sich immer auch um eine Veränderung (Change7) der Ausgangssituation. Projekte sind temporär und benötigen Ressourcen, die, wenn sie nicht extern zugekauft werden, eigentlich dem normalen Geschäftsbetrieb zugeordnet sind. Im Vergleich zum Alltagsbetrieb ist ein Projekt immer mit höheren Unsicherheiten und Risiken verbunden.

Projekte sind innerhalb des Unternehmens oft funktionsübergreifend. Sie erfordern damit die zeitweilige Zusammenarbeit von unterschiedlichen Abteilungen und Organisationen. Ohne einen adäquaten Steuerungsapparat sind sie zum Scheitern verurteilt.

Die ergänzende Definition eines Projekts nach PRINCE8 lautet daher folgerichtig: „Ein Projekt ist eine temporäre Organisation, die aufgesetzt wird zum Zwecke der Bereitstellung eines oder mehrerer Business-Produkte, gemäß einem vereinbarten Business Case.“

Abenteuer Wertvernichtung

Manfred Gröger9, Professor an der Universität Würzburg, hat 2004 eine Studie zum Projektmanagement in Deutschland veröffentlicht. Die Ergebnisse waren so erschreckend, dass die Studie den Titel „Projektmanagement: Abenteuer Wertvernichtung“ bekam. Dort wurde nachgerechnet, dass in Deutschland pro Jahr in einem durchschnittlichen Gesamtwert der Projektarbeit von 244,5 Milliarden Euro ein nicht wertschöpfender Anteil von 150 Milliarden Euro enthalten ist. Die Ursachen ließen sich fast immer auf mangelnde Projektkompetenz zurückführen.

Der hohe wirtschaftliche Druck zwingt die Unternehmen, Optimierungspotenziale zu identifizieren und auszuschöpfen. Die Fähigkeit eines Unternehmens, Änderungen effektiv und effizient umzusetzen, entscheidet über seinen künftigen Erfolg. Der Weg von der Strategie bis zur Operation führt fast immer über Projekte. Zukunftsentscheidend ist damit auch die Fähigkeit, Projekte erfolgreich abzuschließen10.

Was P2M2 leistet

Eigentlich wissen wir, warum Projekte scheitern. Wir wissen auch, wie wir diese Probleme im Einzelfall verhindern können. Was lange fehlte, ist eine durchgehende Systematik, die Regeln und Anweisungen vorgibt beziehungsweise -schreibt, nach denen ein Projekt duchgezogen werden sollte. Genau das leistet PRINCE2. Das zweite große Problemfeld betrifft die Organisation. Für den Projekterfolg11 müssen dort bestimmte Rahmenbedingungen gegeben sein. Das betrifft die Auswahl von Projekten, die Abbildung von Projekten im Rechnungswesen, die Qualifizierung von Projektmitarbeitern etc. Hierfür ist PRINCE2 nicht zuständig. Um die Prozessreife eines Unternehmens im Projekt-Management sicherzustellen, hat die OGC das PRINCE2 Maturity Model (P2M212) geschaffen, an dem sich eine Organisation ausrichten und von der APMG zertifizieren lassen kann.

Wie adressiert PRINCE2®  die Probleme?

Um zu verstehen, was PRINCE213 leisten kann, muss man einen Blick auf dessen Struktur werfen. Die PRINCE2 -Prozesse umfassen das komplette Projekt von der Vorbereitung über Initiierung und Durchführung bis zum Abschluss. Bei den Prozessen handelt es sich um konkrete Handlungsanweisungen, die Inhalte werden in Management-Produkten, beispielsweise Checklisten oder Dokumentvorlagen, festgehalten. Unterstützt werden die Prozesse von einzelnen Wissensgebieten, „Themen“ genannt. Grundsätzlich eignet sich PRINCE214 für jede Art von Projekten und kann unabhängig von der Größe, des Typs, der Organisationsform, der geografischen Lage oder der Kultur eingesetzt werden. Das ist möglich, weil PRINCE2 auf sieben Prinzipien basiert, denen ihrerseits „lessons learned“ zugrunde liegen, also aus Projekten – guten wie schlechten – gewonnene Erfahrungen.

Prinzip 1: Fortlaufende Ausrichtung an den geschäftlichen Anforderungen

PRINCE2 unterscheidet zwischen den Zielen eines Projekts und seinem Nutzen. Die Ziele sind das, was ein Projekt herstellen beziehungsweise erreichen muss. Sie sind am Ende eines Projekts messbar, aber nur Mittel zum Zweck. Der Nutzen hingegen lässt sich oft nicht direkt messen, sondern wird erst nach einer gewissen Anwendungszeit sichtbar. Er macht den eigentlichen Projekterfolg aus. Die Gründe für ein Projekt und der angestrebte Nutzen werden bei PRINCE2 in einem Business Case15 festgehalten. Er hilft dem Auftraggeber, zu Beginn jeder neuen Management-Phase zu beurteilen, ob in das Projekt (weiter) investiert werden soll. Der Business Case wird sich über die Laufzeit eines Projekts verändern, deshalb muss er gepflegt werden. Wann das der Fall ist, legen die PRINCE2-Prozesse fest.

Prinzip 2: Lernen aus der Erfahrung

Um zu verhindern, dass derselbe Fehler zweimal gemacht wird, besteht PRINCE2 darauf, dass während eines Projekts ein Erfahrungsprotokoll gepflegt wird. So werden während des Projekts Chancen zur Verbesserung16 deutlich. Am Ende lässt sich daraus ein Erfahrungsbericht generieren, der anderen Projekten zur Verfügung gestellt wird. Diese Dokumente sind standardisiert und fragen systematisch ab, was gut lief, was schlecht lief, was fehlte, welche Risiken aufgetreten sind etc. Jedes Projekt muss die Erfahrungsberichte früherer Projekte berücksichtigen.

Prinzip 3: Definierte Rollen und Verantwortlichkeiten

Der Erfolg eines Projekts hängt von der Interessenwahrung der Beteiligten ab. Es gibt in jedem Projekt drei primäre Interessen:

  • Unternehmensinteresse: Die Sponsoren des Projekts wollen investieren, um einen bestimmten Nutzen von dem Projekt zu haben.
  • Benutzerinteresse: Die Anwender müssen später mit den Projektergebnissen arbeiten. Von ihrer Akzeptanz hängt der Erfolg ab.
  • Lieferanteninteresse: Die Leute stellen die Projektergebnisse her und sind für deren Qualität verantwortlich.

Die Interessen der verschiedenen Parteien („Stakeholder“) müssen im Projekt adäquat repräsentiert sein. PRINCE217 arbeitet mit Rollen. So kann man die drei Interessen unabhängig von der tatsächlichen Personenanzahl in drei Rollen unterbringen. Jede Rolle in einem Projektmanagement-Team wird zu Beginn eines Projekts definiert und abgestimmt.

Die Steuerung der Ressourcen muss vom Projekt aus möglich sein. Wenn in einer Organisation ausschließlich die Linienorganisation über die Ressourcen entscheidet, besteht immer die Gefahr, dass die Ziele des Projekts und die Ziele einer Linie nicht deckungsgleich sind. Die Lösungsansätze „Matrixorganisation18“ oder „Projektorganisation“ sind oft nicht praktikabel, da die Arbeitsverträge in den meisten Fällen keine temporäre Übergabe der disziplinarischen Verantwortung an einen Projektmanager erlauben oder ein Umbau der Organisation unerwünscht ist. Deshalb besteht PRINCE2 darauf, dass im Lenkungsausschuss eines Projekts diejenigen sitzen, die auch in der Linie über die Ressourcen entscheiden. Dieser Ansatz definiert also nicht den Projektmanager als zentrale Rolle eines Projekts, sondern das Projektmanagement-Team, in dem der Lenkungsausschuss alle wichtigen Entscheidungen trifft.

Prinzip 4: Steuern über Phasen

PRINCE2 verwendet einen „Stage Gate-Ansatz“19. Die Methode definiert neben den technischen Phasen „Management-Phasen“. Dabei handelt es sich um sequenzielle budgetierte Zeitabschnitte, für die es jeweils einen eigenen Phasenplan gibt. Der Projektplan bietet den Gesamtüberblick. Beim Übergang von einer zur anderen Management-Phase muss der Lenkungsausschuss ausdrücklich entscheiden, ob weiter in das Projekt investiert werden soll. PRINCE2 definiert ein Minimum von zwei Management-Phasen: Projektinitiierung und mindestens eine weitere. Zumindest nach der Planung und vor der eigentlichen Projektumsetzung besteht die Methode also auf einer Entscheidung des Lenkungsausschusses.

Prinzip 5: Managen nach dem Ausnahmeprinzip

Als Mitglied des leitenden Managements steht man immer vor dem Problem, wie man bei delegierten Aufgaben die Kontrolle behalten kann, ohne dass die administrativen Aufwände zu groß werden. Am bequemsten ist sicher „Management by Delegation“. Peter Drucker20 hat 1954 das „Management by Objectives“ empfohlen, also das Steuern über Ziele. Im Prinzip ist das richtig, allerdings erfolgt die Zielprüfung immer erst am Ende einer Arbeit. Das kann manchmal zu spät sein. Man könnte Teilziele und Teil-Teilziele vereinbaren, aber das vergrößert die administrativen Aufwände stark.

Die optimale Variante bei Projekten ist das „Management by Exception“21 (Managen nach dem Ausnahmeprinzip). Über Toleranzen wird ein "grüner" Bereich bestimmt, innerhalb dessen sich die Ebene, an die delegiert wird, frei bewegen kann. Sobald sich abzeichnet, dass Toleranzen über- oder unterschritten werden, muss an die nächsthöhere Management-Ebene berichtet werden – in Form einer Entscheidungsvorlage. Das gilt übrigens auch für Verbesserungsvorschläge. Dadurch wird der Lenkungsausschuss entlastet, seine Kontrollaufgaben beschränken sich nun darauf, sicherzustellen, dass sich die delegierte Ebene innerhalb der Toleranzen bewegt. PRINCE2 steckt den Handlungsspielraum einer bestimmten Delegationsebene mit sechs Toleranzarten ab:

  • Zeit,
  • Kosten,
  • Produktqualität,
  • Umfang,
  • Risiken und
  • Nutzen.

Selbst wenn alle Toleranzen auf null stehen, wird das Werkzeug dadurch nicht unwirksam. Dann wird nur häufiger eskaliert.

Prinzip 6: Fokus auf Produkten

Um erfolgreich zu sein, muss sich ein Projekt auf Ergebnisse (Produkte) konzentrieren. PRINCE2® hält sich aus der eigentlichen Herstellung von Ergebnissen heraus und fokussiert auf das Management eines Projekts. Deshalb muss die Schnittstelle zwischen dem Projektmanagement und den Spezialisten sauber definiert sein. Dazu verwendet PRINCE222 Produktbeschreibungen, in denen die Qualitätskriterien für ein Produkt vor der eigentlichen Herstellung festgelegt werden. Damit lässt sich auch der Fortschritt durch Abnahmen oder Teilabnahmen prüfen. Er liegt also nicht mehr im Ermessen der Beteiligten, sondern ist objektiv feststellbar.

Prinzip 7: Anpassung an die jeweilige Projektsituation

Die Methode ist nicht an eine bestimmte Projektsituation angelehnt. Die Anpassung wird vom Projektmanager in Verbindung mit dem Lenkungsausschuss vorgenommen und in der Projektdokumentation festgehalten. Die Anleitung zur Anpassung ist Teil von PRINCE2.

 

Die Methode im Überblick

  • PRINCE2 bietet „Best Practice“ im Projektmanagement.
  • Zudem hilft die Methode bei der Projekt-Governance23: Die Projektsicherung ist Pflicht.
  • Sie eignet sich für jede Art von Projekt.
  • Außerdem wurde sie für die harmonische Kooperation mit beliebigen Herstellungsmethoden entwickelt.
  • Es handelt sich um einen weit verbreiteten De-facto-Standard in der Projektdurchführung.
  • Darin sind klare Verantwortlichkeiten definiert.
  • PRINCE2 bedient präzise den jeweiligen Informations- und Steuerungsbedarf der verschiedenen Management-Ebenen.
  • Die Methode ist produktorientiert: Alle Beteiligten wissen, was am Ende herauskommen muss.
  • Sie beschreibt ein Management nach dem Ausnahmeprinzip24; das bedeutet geringe administrative Aufwände bei optimaler Kontrolle.
  • Vorgesehen ist die fortlaufende Ausrichtung an den geschäftlichen Anforderungen.
  • Darüber hinaus fordert PRINCE2, genaue, aber schlanke Berichte zu verfassen, die auf den jeweiligen Informationsbedarf zugeschnitten sind.
  • Vorgesehen ist eine objektive Fortschrittsmessung über Abnahmen und Teilabnahmen.
  • Ein Stakeholder-Management über definierte Rollen ist ebenfalls eingebaut.
  • Es gibt einen kontinuierlichen Verbesserungsprozess für das Projektmanagement.25
  • Nicht vergessen wurden auch Schnittstellen zum Programmmanagement.26
  • Nützlich ist zudem ein effektives und effizientes Frühwarnsystem bei Abweichungen.
  • Daneben bietet PRINCE2 eine Anleitung zur Anpassung an unterschiedliche Projektgrößen.
  • Somit stellt die Methode ein Diagnosewerkzeug für die Bewertung beliebiger Projekte oder Methoden bereit.
  • Nach PRINCE2 zertifizierbar sind Personen (für die Ausbildungsgänge Foundation und Practitioner27), aber auch Unternehmen (P2M2).