Das Beste aus beiden Welten – PRINCE2 und Agile

Mein Name ist Oliver Buhr und ich bin seit über 15 Jahren PRINCE2-Trainer. Gleichzeitig kenne ich mich bestens aus in Lean-Startup, Kanban, Design-Thinking und bin auch gleichzeitig zertifizierter Scrum-Master.

Jetzt fragst Du Dich vielleicht, wie das zusammenpasst und denkst vermutlich, dass PRINCE2 das alte Eisen ist und die anderen Sachen die Neuen Methoden sind, die ich jetzt vermittle.

Weit gefehlt. Es gibt einen großen Bedarf in der Verbindung zwischen PRINCE2 und agilen Entwicklungsmethoden. Aber es gibt einen Knackpunkt, wo es nur entweder oder geht, wo Du Dich dann entscheiden darfst: PRINCE2 oder agile Ansätze.

Was hat mich dazu bewogen, diese Episode aufzuzeichnen?

Ich war in der letzten Woche bei einem potentiellen Kunden zu einem Akquisegespräch. Dieser Kunde, ein Unternehmen in der Software-Entwicklung, setzt seit einiger Zeit PRINCE2 erfolgreich ein, aber gleichzeitig auch agile Instrumente.

Ich habe mit ihm in einem 2-Stunden-Gespräch darüber gesprochen, was man davon zu halten hat, wenn agile Ansätze im Unternehmen immer populärer werden und wir gleichzeitig auch PRINCE2 einsetzen. Wir hatten eine spannende Diskussion mit sehr wertvollen Erkenntnissen, die ich Dir jetzt im Folgenden zusammenfasse:

Dieser Kunde steht stellvertretend für so viele andere Unternehmen, die keine Startups sind und keine neu gegründeten Softwareentwicklungsschmieden, sondern ein Unternehmen, das fünf bis zehn Jahre oder vielleicht noch länger am Markt ist. Das seine Strukturen aufgebaut hat, das eine Hierarchie hat, das funktionierende Prozesse und Steuerungsinstrumente etabliert hat. Davon gibt es in Deutschland unheimlich viele. Und es gibt natürlich auch tausende von Unternehmen dieser Art, die in Deutschland PRINCE2 eingeführt haben und erfolgreich einsetzen.
Mit dieser aktuellen, populären Bewegung des modernen Agilen habe ich mich sehr intensiv beschäftigt. Es hat einen Reiz und es gibt ganz viel, was ich darin toll finde und was vielen Unternehmen unheimlich gut tun würde.

Kein „Aber“, nur Realität.

Die Realität ist, dass solche Unternehmen ab einer gewissen Größe nun einmal nicht in kürzester Zeit vom klassischen Ansatz zu einer agilen Kultur wechseln können. Das nennt man sehr oft auch agile Transformation. Je größer das Unternehmen ist, umso schwieriger ist diese Transformation und umso länger dauert sie. Jetzt wollen wir als Projektmanager natürlich performant sein und wir wollen die Vorteile von agilen Entwicklungsinstrumenten ausnutzen und bewegen uns natürlich immer noch in dem klassischen Rahmen unseres Unternehmens, an dem wir nicht vorbei arbeiten können.

Was ist denn die Perspektive von PRINCE2 und von agilen Instrumenten?

Die Perspektive von PRINCE2 ist es, eine Managementumgebung zu schaffen. Es ist dafür da, um Projekte in einem strukturierten und gesteuerten Umfeld laufen zu lassen. Die agilen Instrumente wie Scrum, Lean-Startup, Kanban oder Design-Thinking beschäftigen sich mit der Entwicklung von Produkten bzw. Ergebnissen.
Das, was diese agilen Ansätze anstreben, ist das sie Produkte schneller zu einer höheren Kundenzufriedenheit und auch mit einer höheren Akzeptanz für alle Beteiligten inklusive der Projektmitarbeiter schaffen. Das heißt also, Management-Rahmen hier, Entwicklung da. Was wir hier schon mal erkennen können ist, dass es von der Perspektive keine Konflikte oder keine Überschneidung gibt. Beide Ansätze sind auf unterschiedlichen Flughöhen. Das ist ein Vorteil, um das Ganze auch miteinander kombinieren zu können.

Wenn wir uns PRINCE2 näher anschauen, dann sehen wir, dass hier auch schon vor 20 Jahren Agilität mit eingebaut wurde, indem es in Managementphasen dachte. Es schafft die Möglichkeit, dass wir in Projekten zu ganz bestimmten Zeitpunkten, nämlich zu Phasenübergängen, das Projekt immer auf dem Prüfstand stellen: „Was haben wir erreicht und was können wir gegebenenfalls justieren?“

Das heißt also, dass PRINCE2 schon von der Steuerung her so ein bisschen Iteration und inkrementelle Vorgehensweise eingebaut hat.

Was hat PRINCE2 zusätzlich eingebaut?

PRINCE2 beschäftigt sich mit unterschiedlichen Dingen, die so einen Managementrahmen wirksam machen. Zum Beispiel mit einem Business-Case, also Projekten eine wirtschaftliche Grundlage zu geben, damit nur lohnende Projekte durchgeführt werden. PRINCE2 bettet sich in das Controlling eines Unternehmens ein, indem es Statusberichte für unterschiedliche Interessensparteien abgibt.

PRINCE2 bettet sich ein in das Qualitätsmanagementsystem eines Unternehmens. ISO 1901 zum Beispiel. PRINCE2 kümmert sich sehr intensiv um die Stakeholder. Man sagt, wir machen es in einer Kunden-Lieferanten-Umgebung. Wir haben unterschiedliche Stakeholder, die wir auf unterschiedliche Art und Weise einbetten. Insbesondere auch die Schlüsselpersonen, die wir in einen Lenkungsausschuss holen und sie mitentscheiden lassen. Die anderen binden wir ein, indem sie mitarbeiten beziehungsweise indem wir denen Informationen geben.

All das, was Du jetzt hier so in Schlagworten mal zu PRINCE2 gehört hast, kann man mal so grundsätzlich zusammenfassen unter einer bestimmten Governance, die man etabliert.

Diese Worte, die ich jetzt hier nenne, findest Du in Scrum, Lean-Startup und Design-Thinking einfach nicht. Wenn wir uns in so einem gewachsenen Unternehmen mit bestehenden Strukturen befinden, gibt den Anspruch der Organisation, dass sie das auch weiterhin geliefert bekommt: Aufsetzen eines Projektes, eingebunden in das Portfolio, Aufrechterhaltung der Kommunikation, der Einbindung der Stakeholder, Integration in das Controlling und letzten Endes ein Projekt an den Betrieb wieder übergeben.

Wenn wir uns jetzt mal anschauen, was auf der agilen Ebene so an Fokus da ist, dann sehen wir, dass es überall darum geht, Produkte zu entwickeln. Ergebnisse in einem projektartigem Umfeld herzustellen, über ganz unterschiedliche Schwerpunkte und Mechanismen.

Design-Thinking dreht sich eher um Innovation, da geht es eher darum, neue Sachen auszuprobieren. Bei Kanban konzentrieren wir uns eher auf den Flow und versuchen einen möglichst effizienten Durchlauf hinzukriegen. Bei Lean-Startup probieren wir immer neue Hypothesen aus.

Es gibt also unterschiedliche Ansätze, aber dieses Inkrementelle ist allen Ansätzen gemeinsam. Das Durchlaufen in Zyklen. Da können wir uns wunderbar an PRINCE2 andocken, weil wir agile Entwicklungen einbetten können in Managementphasen von PRINCE2.

Es gibt noch eine zweite Alternative, indem wir Arbeitspakete in PRINCE2 agil zu entwickeln, also gerade dann, wenn wir komplexere, größere Projekte haben, wo sich nicht jedes Arbeitspaket eignet. Man schneidet Arbeitspakete heraus, packt sie in einen vierwöchigen Sprint und dann in dieser eigenen Umgebung führt man dann das Ganze in einer agilen Umgebung durch, die PRINCE2 ja auch ermöglicht, denn Prince2 selbst beschäftigt sich überhaupt nicht mit der Umsetzung der Arbeitspakete.

Da können wir uns einfach austoben und uns die Instrumente aussuchen, die uns in Projekten auch wirklich diesen Vorteil schaffen, den wir alle an agilen Ansätzen so schätzen. Dass ein Team selbstorganisiert zusammenarbeitet, dass die Kommunikation sehr intensiv erfolgt, dass wir sehr visuell und transparent arbeiten, z.B. mit Scrum-Boards, dass wir permanent Feedback-Schleifen haben, sei es jetzt über die Produktentwicklung oder auch über den Prozess, wenn wir an Retrospektiven denken.

All diese Instrumente, die Du in diesen vier beispielhaften Ansätzen findest, die können wir problemlos auch in PRINCE2-Projekten einsetzen.

Zusammengefasst bedeutet das, dass es überhaupt kein Problem ist, in Organisationen, die weiterhin PRINCE2 schätzen, die agilen Instrumenten einzubauen, quasi anzuflanschen. Worüber wir nachdenken dürfen ist natürlich, wie wir diese Schnittstelle gestalten.

Hier gibt es drei Ebenen:

1. Die zeitliche Schnittstelle.

Zu welchen Zeitpunkten springe ich aus einem Prince2-Projekt in eine agile Umsetzung? Man könnte es an einem Phasenübergang machen oder auch dann, wenn ein Arbeitspaket zur Umsetzung ansteht.

2. Das Organisatorische.

Hier stellt sich die Frage, wie der Projektmanager auf der Prince2-Ebene, mit einem Product-Owner oder einem Scrum-Master kommuniziert und interagiert. Gibt es da möglicherweise Überschneidungen in diesen Rollen? Kann ein Projektmanager auch ein Product-Owner sein? Hier darf man sich in jeder Projektumgebung genauer überlegen, wie man hier die Rollen neu schneidet, die aus den unterschiedlichen Umgebungen zusammenarbeiten.

3. Die Dokumente.

Gemeint sind die Templates, die Informationsobjekte. Bei Prince2 heißen sie Managementprodukte, wo anders heißen sie Artefakte. Wenn man das einfach mal so überschlägig durchgeht, sehe ich da jetzt nicht viele Konflikte oder viele Überschneidungen, weil man hier auf der operativen Ebene ist, wo es dann darum geht, Backlocks und Impediment-Listen zu haben oder wo man dann Lessons Learned aus Retrospektiven aufschreibt.

Das einzige, wo es vielleicht eine Nahtstelle gibt ist: Wie setzen wir den Anspruch des Projektmanagers um, dass er immer Transparenz haben möchte über das, was in einem Arbeitspaket passiert. Also wollen wir von einem Scrumteam zum Beispiel einen Statusbericht haben.
Das ist natürlich eine legitime Frage. Ansonsten sind die Objekte, mit denen man arbeitet, schon von ihrer Perspektive her auch unterschiedlich. Hier spricht man dann eben von Business-Cases oder von Ausnahmeberichten, die dann Eskalationen an den Lenkungsausschuss darstellen. Man spricht vielleicht von Managementansätzen für Qualität und Risiko und so weiter.
Das ist losgelöst von den Objekten, die wir in der agilen Umgebung kennen. Also man darf sich einfach so ein bisschen inhaltlich damit auseinandersetzen und findet da relativ schnell eine Lösung und Übereinstimmung.

Was ist der Knackpunkt?

Es gibt eine Sache, wo wir ganz klar für ein Projekt definieren dürfen, ob wir es agil oder klassisch machen. Wir können immer auf der operativen Ebene im Team agile Instrumente einsetzen. In jedem Projekt. Aber wenn wir auf die Projektebene gehen und uns grundsätzlich den Aufsatz eines Projektes anschauen, dann dürfen wir uns an dieser einen Stelle, bei dem initiieren eines Projektes, wenn wir in der Planung sind für ein entweder, oder, entscheiden.

Prince2 geht davon aus, dass man das Endergebnis eines Projektes zu Beginn möglichst präzise und eindeutig formuliert. Das muss nicht detailliert sein, aber es sollte eindeutig sein. Dafür schlägt Prince2 eine produktbasierte Planung vor.
Man würde also hier in eine produktbasierte Planung gehen mit dem Ziel, das Projekt zu durchdringen. Und das ist ein Widerspruch.

Das ist ein Widerspruch zu agilen Ansätzen, die ja ein Ergebnis von einer groben nutzenorientierten Vision im Laufe des Projektes über die Erfahrungen, die wir sammeln, konkretisieren. Das nennt man inkrementelles Voranschreiten.

Genau an dieser Stelle dürfen wir uns entscheiden…

Ist die Projektaufgabenstellung so geeignet, dass wir nur eine Lösung suchen und noch gar nicht wissen, wie sie aussieht? Dann könnte man agil vorgehen.

Oder ist das Ergebnis, das gewünscht ist, schon sehr präzise formulierbar?
Zum Beispiel eine Migration von einer Plattform auf die nächste. Da gibt es für mich in meinen Augen überhaupt kein Vertun, da geht man klassisch vor und man sollte das Projekt durchplanen und durchdringen.

Also an dieser Stelle gibt es dann den Knackpunkt: Gehe ich den klassischen Ansatz oder gehe ich den agilen Ansatz?

Zusammengefasst …

…gerade für Unternehmen, die schon längere Zeit existieren, die ihre eigene Management- und Governance-Struktur etabliert haben und mit Prince2 arbeiten, ist es eine wundervolle Anreicherung, agile Instrumente in die Projekte mit einzubinden. Das funktioniert immer und Du darfst Dir einfach nur mit ein bisschen Nachdenken diese Schnittstellen sauber formulieren für die Zeit, die Rollen und für die Informationen. Und schon kann man ziemlich reibungslos unter Nutzung von beiden Vorteilen, agil und Prince2 miteinander verknüpfen. Der einzige Knackpunkt ist, dass Du Dich bei der Planungsphase eines Projektes entscheiden musst: Willst Du das Endergebnis vordefinieren oder den inkrementellen Ansatz wählen.

Ich habe ein Angebot für Dich:

So wie ich diesen potentiellen Kunden hoffentlich bald gewinnen kann und mit ihm einen Workshop machen kann, so kann ich und mein Team auch Dir Hilfestellungen leisten.

Vielleicht ist solch ein Workshop auch interessant für Dich. Die Kompetenz in beiden Welten ist da. Wir schauen, wie wir für Dein Unternehmen und Deine Projekte die bestmögliche Synergie aus dem Einsatz von beiden Welten, von der klassischen und der agilen Welt finden können.

Schreib mir gerne eine E-Mail an o.buhr@copargo.de

Ich freue mich auf Dein Feedback.

Bis bald und happy projects : )

[widgets_on_pages id=“action-oliver“]

Merken

Merken

Merken