Ist Agiles Projektmanagement mit den PMI^® Projektmanagementprozessen machbar? Klar!

PMI^® Projektmanagementprozesse beziehen sich auf eine einzige Rolle, die vom Projektmanager. Im PMBOK Guide von PMI^® werden die Projektmanagementprozesse beschrieben. Der Projektmanager managt die operative Leistungserbringung des Projektteams. Er lötet nicht, codiert nicht, baut keine Prototypen auf, führt keine qualitätsbezogenen Versuche durch. Die Leistungserbringung ist die Sache des Projektteams. Dabei kann das Projektteam zur Vernetzung der operativen Aktivitäten zur Leistungserbringung z.B. nach dem Wasserfall vorgehen.

PMI^® versus Scrum ist falsch:

Im PMBOK Guide wird zwischen dem

• Projektlebenszyklus und
• Projektmanagementlebenszyklus

unterschieden. 

Der Projektlebenszyklus bezieht sich auf die gesamte Projektorganisation mit allen projektinternen und projektexternen Stakeholder. Er besteht aus der Sammlung sequentiell ablaufender und/oder sich mitunter überschneidender operativer Projektphasen:

• Projekt beginnen (starten) - Ausgangswert Projektauftrag
• Projekt strukturieren und vorbereiten (Leistungserbringung organisieren und vorbereiten) - Ausgangswert Projektmanagementplan
• Projektarbeit durchführen (Leistungen erbringen)  - Ausgangswert Abgenommene Liefergegenstände
• Projekt abschließen - Ausgangswert Archivierte Projektdokumente   

Der Projektmanager führt und steuert das Projektteam durch den Projektlebenszyklus. 

Scrum definiert drei Rollen

• Scrum Product Owner,
• Scrum Master und
• Scrum Entwicklungs-Team,

indem die Aufgaben, Kompetenzen und Verantwortlichkeiten vom Projektmanager nach PMI^® unter diesen drei Rolleninhabern verteilt werden. Im Scrum-Gestaltungsrahmen werden die Projektmanagementprozesse und die operative Leistungserbringung verwoben definiert. Die Selbstorganisation bezieht sich auf sowohl die Projektmanagementaufgaben, die das Scrum Team selbst verantwortet, als auch die operative Leistungserbringung in den Sprints.

In Scrum-Projekten wird die Rolle Projektmanager PMP^® zwar nicht besetzt, die Projektmanagement-Aufgaben lösen sich aber nicht in Luft auf. Unter Berücksichtigung von agilen Aspekten werden die Projektmanagement-Aufgaben auf drei Rollen verteilt.   

1986 berichteten Hirotaka Takeuchi und Ikujiro Nonaka im Harvard Business Review im Kapitel Moving the Scrum Downfield ihres Beitrages The New Product Development Game von sechs Merkmalen, auf die Produktentwicklung der führenden Unternehmen verweisen:

1. Built-in instability

2. Self-organizing project teams

3. Overlapping development phases

4. Multilearning

5. Subtle control

6. Organizational transfer of learning  

Im Rahmen eines Projektes zur Einführung von Simultaneous Engineering diente der Ansatz von Takeuchi und Nonaka uns als eine der theoretischen Grundlagen.

Warum brauchte eine so gute Idee wie Scrum erst gut 20 Jahre, um so populär zu werden?

Ken Schwaber positioniert Scrum wie folgt:

»Scrum wird für komplexe Arbeit eingesetzt, bei der es unmöglich ist, alles vorauszusagen, was eintreten kann.« (Einleitung in seinem Buch - Agiles Projektmanagement mit Scrum)

Hatten wir vor 20 Jahren keine komplexe Arbeit? Doch. Die Dynamik in den Umwelten der Unternehmen bzw. der Projekte hatte allerdings nicht das heutige Maß.   

Ein Projekt kann nur erfolgreich sein, wenn es über so viel Eigendynamik wie die Dynamik ihrer Umwelten verfügt.

Projekte reagieren permanent auf Veränderungen in ihren Umwelten, indem sie sich von ihnen irritieren lassen. Wenn die projektinternen Abläufe und das Auftreten den Umwelten gegenüber viabel, d.h. brauchbar, sind, befindet sich das Projekt auf dem Weg zum Erfolg. 

Die steigende Dynamik der globalen Märkte fordert die Projekte heraus, dass sie zum Überleben ihre Eigendynamik permanent abgleichen und anpassen.  

PMI^® , Scrum oder weitere agile Ansätze haben der Projektorganisation auf diesem Weg als Gestaltungsrahmen zu dienen:

• Sind die Umwelten des Projektes träge (→ Träge Märkte ), kann es seine Eigendynamik einem dieser Trägheit angemessenen Maß anpassen. Die herkömmlichen Ansätze für Projektmanagement eignen sich für Projekte in trägen Umwelten. PMI^® kann für Projekte in trägen Umwelten angewendet werden. Viele Projektmanager, mit denen wir zusammenarbeiten, ordnen PMI^®  zuerst zu dieser Kategorie. Auch für PMI^® ist die Zeit jedoch nicht stehengeblieben.
• Sind die Umwelten des Projektes dynamisch (→ Dynamische Märkte ), muß seine Eigendynamik mit der steigenden Dynamik seiner Umwelten wachsen. Agile Ansätze entfalten sich erst in dynamischen Umwelten richtig. Scrum ist für IT-Projekte in dynamischen Umwelten geeignet. Hat der Projektmanager die Autodynamik seines Projektes verstanden, kann er die Projektprozesse von PMI^® für ein agiles Projekt gestalten und führen ( D´Angelo bezeichnet diese Art der Gestaltung Tailoring von agilen PMI^® Prozessnetzwerken ). Er wird sich automatisch als ein Project Master wie Scrum Master verhalten und das Projektteam bei der laufenden Selbstorganisation begleiten. Er wüßte nämlich, dass die ausschließliche Projektsteuerung bei zunehmender Dynamik kollabieren würde. 

Theorie für agiles Projektmanagement? Absolut. 

Wer über keine in sich stimmige Denkhaltung mit einem starken Theorie-Rückgrat verfügt, kann in Social Network Foren lange Beiträge absetzen, in Yellow Blogs den großen Vordenker oder Querdenker-Zampano spielen oder mit seinen 500 Seiten dicken, aber kunterbunt zusammenkopierten Trainingsdokumenten den Top-Trainer mimen. Agiles Projektmanagement kann er nicht erklären, höchstens Versus Charmanterie zelebrieren.  

Nicht selten wundern wir uns in unseren Gesprächen mit Scrum Experten über die kindliche Naivität erwachsener Menschen, da sie den Eindruck erwecken, als ob bestimmte Begriffe für agiles Projektmanagement erst durch Scrum in die Welt gesetzt worden wären.     

Am Anfang beschreiben wir daher theoretisch und nach dem Motto "Exzellenter Wein in alten Schläuchen" altbekannte Begriffe, u.a. aus der PMI Welt, zum Gebrauch für agiles Projektmanagement.