Was ich an PRINCE2 liebe

Was macht Projekte erfolgreich? Ein Projekt wird durch drei Dinge erfolgreich:

  • Eine klare Vision und einen Business Case, um Feedback von Sponsoren und Stakeholdern zu bekommen,
  • Tests, die als ausführbare Spezifikation dienen, um Feedback über ein System zu bekommen, während es wächst, und
  • Menschen, die bereit sind, auf dieses Feedback zu reagieren.

Wie sehr ich eine Methode schätze oder nicht, hängt davon ab, ob sie

  • diesen Prinzipien nicht im Wege steht,
  • diese Prinzipien fördert oder
  • sicherstellt, dass dieses Feedback tatsächlich stattfindet.

Ich bewerte PRINCE2 nach diesen Kriterien, um zu erklären, durch welche Eigenschaften ich diese Methode “lieb gewonnen” habe.

Klarer Fokus auf Business und Investition

Der Business Case ist der Dreh- und Angelpunkt von PRINCE2, auf dem und um den es aufgebaut ist. Er fasst eine Produktvision in Zahlen, sodass Kosten und Nutzen, Chancen und Risiken klar zu erkennen sind und als Orientierungspunkt für alle Entscheidungen dienen können.

Ein Business Case ist gut, wenn er zwei Ziele erfüllt:

  • Er lindert Angst. Der wesentliche Grund, warum Projekte scheitern, sind Menschen. Und der wesentliche Grund, warum Menschen scheitern, ist Angst. Angst, einen Fehler zu machen, eine Entscheidung zu treffen, die getroffen werden muss, das Falsche zu tun, obwohl man davon überzeugt ist, dass es das Beste wäre. Ein guter Business Case benennt Kosten, Risiken und Fehlertoleranzen. Innerhalb dieser Toleranzen werden Menschen ermutigt, Entscheidungen zu treffen.
  • Er überlässt die Details den Menschen, die die Arbeit machen. Ein guter Business Case ist einfach und kurz genug, sodass sich jeder im Projekt tatsächlich die Zeit nimmt, ihn zu lesen. Da der Business Case Richtung und Grenzen für ein Projekt vorgibt, sollte ihn jeder kennen, um die bestmöglichen Entscheidungen treffen zu können. Jeder im Projekt sollte wissen, welchen Zweck eine Aufgabe hat und welche Wertschöpfung als Ergebnis der Aufgabe erwartet wird.

Feedback

Milliarden werden jedes Jahr leider immer noch für Produkte oder Produkt-Features ausgegeben, die kaum jemand benutzt. Projekte werden auf der Basis von Verträgen fortgeführt, die auf Annahmen beruhen, die längst nicht mehr gelten. Viel zu oft ist „mehr Geld” die Reaktion auf „schlechten Gegenwert fürs Geld”.

Vollständiges Feedback vom Sponsor bis zum Anwender kann die Kosten in Grenzen halten, falls ein Projekt in die falsche Richtung läuft.

Feedback muss auf mehreren Ebenen passieren:

  • Der Sponsor benötigt Feedback zu den angefallenen Kosten und der erbrachten Wertschöpfung.
  • Der Projektleiter benötigt Feedback über lieferbare Produkte oder Produktinkremente.
  • Die Teammitglieder benötigen Feedback zur Qualität ihrer Produkte und ihrer Zusammenarbeit.

PRINCE2 sieht entsprechende Feedbackzyklen vor: Der Sponsor bekommt Feedback am Ende jeder Management-Phase. Der Lenkungsausschuss (Repräsentanten der Anwender und Lieferanten sowie andere Stakeholder) setzt Vorgaben und berät bei der Weiterentwicklung des Produkts. Der Projektleiter bekommt Feedback, während er mit dem Team Arbeitspakete definiert und die fertig gestellten Produktinkremente entgegennimmt. Das Team bekommt Feedback von der Qualitätssicherung, geführt durch die Akzeptanzkriterien der Produktbeschreibungen. Beachten Sie, dass an keinem Punkt vorgegeben wird; „Baut zuerst, testet anschließend”. Es ist in PRINCE2 akzeptabel, die Qualität in die Arbeitsprozesse so zu integrieren, wie es Ihnen passend erscheint. Meine bevorzugte Arbeitsweise (bei Software) wäre ein Test-First-Ansatz.

Das gesamte Team gibt und bekommt Feedback über die Zusammenarbeit im Projekt durch Lessons Learned. Ich wünsche mir hier eine explizitere Integration des Feedbacks in die periodischen Prozesse. Ich sehe einen geringen Wert im Aufzeichnen von Lessons Learned am Ende eines Projekts. Aber es ist ja nie verboten, mehr zu tun, als der Prozess vorschreibt!

Ein anderer Feedback-Prozess, den ich an PRINCE2 schätze, weil er so sehr pragmatisch ist, ist das Erheben von Issues (Themen). Issues können vieles sein: Ideen, Bedenken, Änderungen, Hindernisse, Fehler… Sie werden in einheitlicher Weise behandelt. Der Projektleiter behält sie im Blick, löst oder eskaliert sie. Eskalationen sind immer dann erforderlich, wenn ein Issue nicht innerhalb der vereinbarten Toleranzen behandelt werden kann.

Respekt für Spezialisten

PRINCE2 definiert keine technischen Rollen. Sie können Ihr Team frei organisieren. Es ist auch völlig okay, wenn sich ein Team selbst organisiert. PRINCE2 definiert, wie beschrieben wird, was geliefert werden muss: Dies geschieht in Form einer wachsenden, zunehmend detaillierter werdenden Produktstruktur. Auf diese Weise kann man leicht mit der Situation umgehen, dass zu Projektbeginn oft nicht bis ins Detail klar ist, was am Ende geliefert werden muss. Projektleiter und Team einigen sich regelmäßig darauf, wie viel an einem bestimmten Datum geliefert wird. Wie Sie die Arbeit kontrollieren und wie Sie genau arbeiten, ist Ihnen überlassen.

Eine Bemerkung zum Formalismus

PRINCE2 kann in einem Projekt angewandt werden, ohne ein einziges Dokument zu erstellen. Überrascht? Das PRINCE2-Handbuch schlägt eine solch riesige Menge an Vorlagen vor, dass diese Tatsache leicht zu übersehen ist. Ein Projekt (oder eine Organisation) definiert den erforderlichen Grad an Formalismus und die benötigte Menge an Dokumentation. Das kann zu einem sehr pragmatischen Prozess führen. Ich schätze direkte Face-To-Face-Kommunikation höher als geschriebene (und schnell veraltete) Dokumentation. Nichtsdestotrotz können einige Aspekte wie die Größe des Projekts, die Kritikalität des erstellten Systems oder die Kultur der Organisation zu bestimmten Erwartungen an die Dokumentation führen. Hier ist Erfahrung gefragt.

Perfection Game

Das Perfection Game ist ein schlanker Prozess, um Feedback und Verbesserungsvorschläge zu sammeln, ein Teil der Core Protocols. Sie werden die Regeln anhand des Ergebnisses leicht verstehen:

Ich gebe PRINCE2 als Projektmanagement-Methode 7 von 10 Punkten.

Ich mag an PRINCE2:

  • Dass es Feedback für Sponsoren und Stakeholder durch den Business Case sicherstellt,
  • Wie der Business Case detaillierte Unterstützung für Entscheidungen gibt, die im Projekt getroffen werden müssen,
  • Dass es inkrementelles Erstellen des Produkts durch den Produktstrukturplan ermöglicht,
  • Die Art, wie es Spezialisten die Verantwortung dafür überlässt, wie die Arbeit getan wird,
  • Wie es eine gemeinsame Einigung zwischen Projektleiter und Team auf den Teil des Produkts, der in einer Management-Phase gebaut wird, durch das Arbeitspaket motiviert,
  • Dass es Anwender, Sponsor und Lieferanten an einen Tisch bringt, um gemeinsame Entscheidungen zu treffen,
  • Dass es durch die Definition von Toleranzen für alle wichtigen Aspekte der Planung Änderungen erleichtert,
  • Wie Akzeptanzkriterien in jeder Produktbeschreibung festgehalten werden, es aber flexibel ist hinsichtlich der Details der Qualitätssicherung.

Um 10 von 10 Punkten zu vergeben, würde ich folgendes hinzufügen:

  • Timeboxing, sodass Management-Phasen in gleich lange Iterationen unterteilt werden oder dass Management-Phasen eine gleichbleibend feste Länge haben,
  • Eine explizite Regel, dass das Ergebnis jeder Management-Phase ein potenziell lieferfähiges Produktinkrement sein muss,
  • Die Verstärkung des Lessons-Learned-Konzeptes durch regelmäßige Retrospektiven,
  • Im PRINCE2-Handbuch noch stärker betonen, dass alle vorgeschlagenen Dokumentvorlagen nur Beispiele sind und dass PRINCE2 auch ohne ein einziges schriftliches Dokument erfolgreich genutzt werden kann.

Meine persönliche Meinung von PRINCE2

Sie werden diese Argumente nicht in einem PRINCE2-Buch finden. Wenn doch, erzählen Sie mir davon! Wenn ich davon ausgehe, was ich im Laufe der Jahre von Menschen gehört habe, die einen Foundation- oder Practicioner-Kurs absolviert haben, haben sie von diesen Dingen auch in ihrem Kurs nichts gehört. Anderenfalls stellen Sie bitte einen Kontakt zu Ihrem Trainer her, ich wäre an einem Erfahrungsaustausch sehr interessiert.

Meine Sicht auf PRINCE2 hat sich im Laufe von etwa 10 Jahren der praktischen Anwendung der Methode geformt, in einer Vielfalt von Organisationen und Unternehmen. Ich hatte viele Diskussionen mit Praktikern darüber, wie sie korrekt benutzt wird, was die zentralen Vorteile sind und worauf man bei einer Implementierung achten muss. Zusätzlich habe ich PRINCE2 mit einer Reihe anderer Modelle verglichen, die ich im Laufe der Jahre praktisch angewandt habe, vor allem dem V-Modell und Scrum. Ich habe für mich selbst die Hauptunterschiede und -Ähnlichkeiten ermittelt, welche die praktische und erfolgreiche Anwendung dieser Modelle sicherstellen.

Dies ist eine Bewertung der Methode, keine Präsentation von PRINCE2. Wenn Sie möchten, dass ich Ihnen die Art, wie PRINCE2 funktioniert, detaillierter näher bringe, fragen Sie bitte nach einem weiteren Beitrag.

0 Antworten

Hinterlassen Sie einen Kommentar

Wollen Sie an der Diskussion teilnehmen?
Wir freuen uns über ihren Beitrag!

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Olaf Lewitz is a Trust Artist. His offer: trust. Agile coaching. Mentoring. For companies. For people. A former microTOOL employee, Olaf has extensive knowledge of processes, e.g. V-Modell XT, Scrum, PRINCE2 and HERMES. He is also an expert for all things in-STEP BLUE.