Projektmanager werden, salopp formuliert, häufig als „Eier legende Wollmilchsau“ bezeichnet. Auch der PmBok Guide 5. Version von PMI, das zentrale Dokument zur Zertifizierung zum PMP, beschreibt auf den Seiten 16 – 18, den hochgradig interdisziplinären Hintergrund eines Projektmanagers. Von daher sollte es nicht verwundern, wenn auch die Inhalte der PMP Prüfung zum Project Management Professional, extrem interdisziplinär daher kommen.
Und jetzt sogar im PmBok 7th, mit erheblichen agilen Anteilen. So besteht der PmBok Guide 6th aus 3 Kapiteln Grundlagen sowie 10 Wissensgebieten, die eben nicht nur Projektmanagement in seinem Kern beschreiben, sondern auch Themen wie Personal-, Kommunikations-, Qualitäts-, Beschaffungs- und Stakeholder Management.
Ohne Kollaboration geht es nicht.
Projektmanagement stellt einen kollaborativen Ansatz dar, der Teamwork Fähigkeiten erfordert. Damit ist nicht nur gemeint, im Team optimal auf der Beziehungsebene miteinander zu arbeiten, soziale Kompetenz und Empathie zu leben, nein, auch die Sachebene ist involviert. Und auch hier meine ich nicht ausschließlich die Kommunikation auf der Sachebene. Neben der sachlichen Kommunikation, gilt es auch, gemeinsam Werkzeuge und Methoden zu nutzen, die nur auf Basis der gemeinsamen Kenntnisse der Werkzeuge und Methoden genutzt werden können.
Stellen Sie sich vor, Sie wollen zusammen mit einigen Teilprojektleitern den Scope (Inhalt und Umfang eines Projekts) eines Projekts anhand eines Projektstrukturplans (PSP) auf Risiken abklopfen. Jetzt hat aber keiner Ihrer Teilprojektleiter jemals einen PSP gesehen, geschweige denn erstellt. Oder Sie vergeben an Ihr PM Team den Auftrag, eine Prozessbeschreibung für die Übergabe und Entgegennahme von Arbeitspaketen, auf Basis von SIPOC zu erstellen.
Das Ganze würde sich ähnlich gestalten, wie die Exkursion einer Gruppe Großstädter, die zum ersten Mal gemeinsam, ohne Anleitung, ein Zelt aufbauen und ein Feuer anzünden soll. Wenn die Gruppe Glück hat, wird sich ein informeller Führer herauskristallisieren (Team Uhr nach Bruce Tuckmann), der mit gesundem Menschenverstand, aber ohne Fachwissen, zumindest die Koordination der Arbeiten übernimmt.
Gesunder Menschenverstand ist extrem wichtig – auch in Projekten! Reicht aber gesunder Menschenverstand und ein informeller Führer im Projektmanagement aus? Ich behaupte mal, dass ein formal eigesetzter Projektmanager mit gesundem Menschenverstand und in Kenntnis signifikanter Werkzeuge und Methoden des Projektmanagements, effizienter seine Projektziele erreicht, als ein PM, mit nur gesundem Menschenverstand und in Kenntnis der Rahmenbedingungen.
Nun, der PmBok Guide 7th, versucht gesunden Menschenverstand durch Prinzipien zu triggern. Die Realität zeigt wohl, dass da einige Lücken existieren.
Agiles Projektmanagement nur mit gesundem Menschenverstand?
IN SCRUM wird das eben erwähnte Exkursion Team im Prinzip unterstellt. Der Scrum Master befindet sich in der Rolle eines „Primus inter pares“ eines Ersten unter Gleichen. Ob er über gesunden Menschenverstand verfügt, sei dahingestellt. Er soll jedenfalls die gesamte soziale Interaktion abdecken, da wäre gesunder Menschenverstand brauchbar. Er kennt sicherlich das Rahmenwerk von SCRUM, ihm fehlen aber das grundlegende Handwerkszeug eines Projektmanagers, die Werkzeuge und Methoden.
Stellen Sie sich eine Gruppe von Schlossern vor, die über einen „Schlosser Master“ und „Product Owner“ verfügt. Fachlich sind die Jungs gut drauf, also wie man z.B. eine Feile oder Eisensäge einsetzt. Sie können auch mit einem Kanban Board umgehen, ein Backlog erstellen, einen Sprint definieren oder Story Points schätzen. Ob das immer wieder stark fokussierte Mindset beherrscht wird, sei auch dahingestellt. Alles Rahmenkriterien, die über SCRUM definiert werden. Im Vorfeld eines Schlosser Projekts oder auch sonstiger Projekte, müssen aber bspw. die Ziele und Anforderungen des Projekts ermittelt werden. In agilen Projekten, formuliert man primär user story getriebene Anforderungen, was nicht heißt, das nicht auch use case getriebene Anforderungen partiell benötigt werden oder durch einen Auftraggeber vorgegeben werden (Requirement Engineering).
Kennen der Schlosser-Master und primär der Product Owner alle Methoden zur Generierung von Scope, auf Basis eines Use case oder einer User story? Sind sie in der Lage, einen Projektstrukturplan (Story Breakdown Structure (SBS)) aus einem Produktstrukturplan zu generieren, also alle Produktelemente mit Projektmanagement Elementen zu matchen? Ist den beiden bekannt, wie der PSP (SBS) als Ausgangswerkzeug genutzt werden kann, ein optimales Controlling der Sprints zu gewährleisen? Sind die beiden „Führungskräfte“ sowie das Team in der Lage, einen Sprint in bspw. MS Project abzubilden und die Werkzeuge der Überwachung zu nutzen? Ich denke, ich könnte jetzt noch mindestens 500 weitere Fragen stellen, die alle nicht durch das Rahmenwerk SCRUM abgedeckt werden.
Verstehen Sie mich bitte nicht falsch! Agile Methoden haben ihre Berechtigung, aber ihnen fehlt i.d.R. das Fundament. Um bspw. den PMI Agile Certified Practitioner zu belegen, benötigen Sie entweder 2000 Stunden PM Erfahrung in klassischen Projekten oder die schon absolvierte PMP Zertifizierung. Wobei meiner Meinung nach, 2000 Stunden PM Erfahrung, die Inhalte einer PMP Zertifizierung bei weitem nicht ersetzen, wenn innerhalb dieser 2000 Stunden, die Werkzeuge und Methoden de PmBok Guides nicht genutzt wurden. Fast allen 800 Projektmanagern, die ich auf die PMP Zertifizierung vorbereitet habe, waren etwa 80% der Werkzeuge und Methoden des PmBok Guides nicht bekannt! Wobei Sie für die PMP Zertifizierung weit mehr Erfahrung nachweisen müssen.
Sie merken schon worauf ich hinaus will. Ob nun in agilen oder klassischen Projekten, wenn Sie Ihre Mitarbeiter jedes Mal erst auf bestimmte Werkzeuge oder Methoden trainieren wollen, dann beschreibt die Deadline Ihres Projekts eine reine Luftnummer.
Ich habe die Werkzeuge und Methoden des PmBok Guides nie gezählt, aber es handelt etwa um 120 – 150 Werkzeuge und Methoden. Ganz logisch – Sie werden nicht alle Werkzeuge und Methoden in Ihren Projekten nutzen. Allein für Identifikation von Scope, bietet Ihnen der Prozess des Scope Managements, 11 übergeordnete Werkzeuge und Methoden sowie 9 untergeordnete Elemente an. Aber um sich für opportune Werkzeuge oder Methoden entscheiden zu können, dazu muss man diese Palette zumindest erst mal kennengelernt haben. Und die, die man nutzen will, sollte man beherrschen.
Prozessorientierung
Der PmBok Guide 6th beschreibt insgesamt 49 Prozesse und 5 übergeordnete Prozessgruppen. Zu jedem Prozess werden Werkzeuge und Methoden beschrieben. Die Prozesse des PmBok Guides stehen SCRUM nicht unvereinbar gegenüber. Im Gegenteil, alle Prozesse sind von je her iterativ orientiert und von daher agil anwendbar. Agiles PM ist aus Sicht des PmBok Guides eigentlich ein alter Hut, wenn man das „Rolling Wave Planning“ berücksichtigt, seit mindesten Version 3, Teil der PmBok Philosophie ist.
Wenn Sie eine Phase als Sprint bezeichnen und darauf die 5 Prozessgruppen (Initiierung, Planung, Überwachung und Steuerung, Ausführung und Abschluss) des Pmbok abbilden und im Anschluss die benötigten Prozesse dieser Prozessgruppen mit den SCRUM Tools matchen, und des Weiteren nur das planen, was Sie wirklich wissen (Rolling Wave Planning), sind Sie automatisch in einem agilen Modus. Allerdings mit dem Vorteil, dass der PmBok Guide, Ihnen weit mehr Handlungsanweisungen in Form von Werkzeugen und Methoden anbietet, als SCRUM. Man muss diese Vorschläge ja nicht als in Stein gemeißelte Vorschriften interpretieren. Die zeitlichen Abläufe in den PmBok Prozessen, werden jedoch nicht genauer beschrieben, da kann man durchaus die Regeln von SCRUM verwenden. Diese Symbiose zeigt ja nun auch der PmBok Guide 7 auf.
Nehmen wir ein Beispiel zur Hand:
Frank Düsterbeck definiert Qualitätsmanagement nicht als Prozess innerhalb von SCRUM, sondern sieht in SCRUM „schon gelebtes Qualitätsmanagement“. Daraus leitet er ab, das Qualitätsmanagement schon in der Entwicklung integriert ist und hauptsächlich durch Testautomatisation geleistet wird und nicht als dedizierte Phase stattfindet.
Diese Erkenntnis ist ein Bestandteil der PmBok Guides der letzten 12 Jahre. Der PmBok Guide erfasst im Wissensgebiet QM, 3 Prozesse: Q-Planung, Q-Sicherung und Q-Lenkung. Zitat aus der Beschreibung des Q-Sicherung Prozess:
„„Q-Sicherung durchführen“ trägt dazu bei, Gewissheit über die Qualität zu haben; durch die Verhinderung von Fehlern durch Planungsprozesse oder durch das Aufdecken von Fehlern während der laufenden Umsetzung.“
Wobei die Identifizierung von Fehlern, auf drei Ebenen vorgenommen wird: 1.Antizipierend und 2.während der Umsetzung oder Entwicklung im Prozess „Q-Sicherung durchführen (Testautomatisation in SCRUM), sowie 3.reaktiv im Prozess „Q-Lenkung“ durchführen, was wiederum den Regressionstests aus SCRUM entspricht. Die Daten des Q-Lenkungsprozess, fließen zurück in den Q-Sicherungsprozess, um die Fehlerhäufigkeit schon modifizierter Fehler, an der Wurzel, antizipierend zu eliminieren.
Zusätzlich sei erwähnt, dass der PmBok Guide immer zwischen den Produkt- und Projektmanagementprozessen unterscheidet. Dies natürlich auch bezüglich der Qualitätsansprüche beider Prozess Dimensionen. Auch Projektmanagement aus Sicht des PMI, ist gelebtes Qualitätsmanagement. Dies wird besonders deutlich, wenn auf Seite 233 5th erklärt wird, dass Q-Planung immer parallel zu den anderen Planungsprozessen durchgeführt werden muss. Das Prinzip der Antizipation, gilt als Maxime im Projektmanagement, nicht nur die Qualitätsanforderungen optimal zu erfüllen, sondern die Qualitätsanforderungen zu den geringsten Qualitätskosten zu erreichen. Von daher lautet das übergeordnete Motto:
„Qualität wird nicht hineingeprüft, sondern hinein geplant!“ Planung ist übrigens auch immer Teil des Projektcontrollings, was vielen Agilisten nicht bekannt ist, weil Planung eher verpönt ist.
Gerade diese Philosophie im QM umzusetzen, bedeutet, Qualitätskosten signifikant zu reduzieren. Die drei oben genannten Prozesse Q-Planung, Q-Sicherung und Q-Lenkung, enthalten dazu die „Seven Tools of QM“, sowie 16 weitere Werkzeuge und Methoden, die im Kontext dieser Philosophie, wahlweise angewendet werden können. Die Handlungsvorschläge des PmBok Guides 6th sind vielfältig und in den meisten Situationen brauchbar.
Die SCRUM Elemente können in die PmBok Prozesse problemlos integriert werden. Bspw. „Testearly&Often“ in den Q-Sicherungsprozess oder „Review&Retrospectives“ in den Q-Lenkungsprozess. Speziell für Software Entwicklung Projekte kommen hier nur spezielle Testverfahren in Frage. In anderen Anwendungsbereichen dagegen, andere Vorgehensweisen um Qualitätsanforderungen zu validieren. Auch dafür bietet der PmBok Guide Vorschläge.
Wenn ich Bücher oder BLOGS von Agilisten lese, fällt mir immer wieder auf, dass diese Autoren sich nie mit dem Klassiker des klassischen Projektmanagements, dem PmBok Guide, beschäftigt haben. So behauptet Saso Nikolev in seinem Buch „SCRUM Master Examen“, im Gegensatz zu SCRUM würde man im klassischen PM, Erfahrungen erst am Ende eines Projekts als Lessons Learned dokumentieren, um diese dann in späteren Projekten zu nutzen. Tatsache ist, dass man in jeder Phase, die man auch als Sprint bezeichnen könnte (Eine Phase kann auch nur 4 Wochen dauern), die Abschlussprozessgruppe durchführt. Wenn es bspw. 10 Phasen oder Sprints in einem Projekt gibt, dann gibt es auch 10 Abschlussprozessgruppen sowie eine „Meta – Abschlussprozessgruppe“, die die Lessons Learned, über alle Phasen des Projekts integriert und zur Anwendung zur Verfügung stellt.
Ebenso die Rollenaufteilung in PO und SM. Die o.g. Unterscheidung von Produkt- und Projektmanagement Prozessen im PmBok Guide….da erscheint mir die Rollenaufteilung in einen SCRUM Master und Product Owner fast wie ein Plagiat zu erscheinen! Zwar werden aus Sicht des PmBoks beide Prozesskategorien durch einen Projektmanager gemanaged, die Aufteilung auf zwei Rollen, bietet sich aber geradezu an. So manches Mal wird deutlich, dass der PmBok Guide ein erhebliches Inspirations-Tool für Agilisten darstellte.
Des Weiteren, finden Sie eine Umsetzung oder Assoziierung der PmBok Werkzeuge und Methoden, in der vom PMI veröffentlichten Ausgabe „Software Extension to PMBOK® Guide fifth Edition“.
Beispiel: Anstatt des hier erwähnten Projektstrukturplans (Work breakdown structure), wird der Prozess „Define Activity“ des PmBok Guides in der Software Extension in das Werkzeug „Story breakdown structure“ ungewandelt und der Vorgang des dekompositierens einer Epic aufgezeigt. Außerdem werden zwei weitere Werkzeuge aus dem agilen Umfeld hinzugefügt: Das Storyboard und der use case. Wobei der use case auch im klassischen Projektmanagement eine Rolle spielt.
Wording
Im Glossar des PmBok Guides, findet man etwa 50 Akronyme und über 500 PM Begriffe. 20% – 30% sind den meisten Projektmanagern bekannt wie bspw. Kritischer Weg, Puffer, Terminplan etc. Geht es dann tiefer, hören die Kenntnisse auf: Unterschied Freier und gesamter Puffer, Kritische Kette und Kritischer Pfad, TCPI, CPI oder ETC… wichtige Kennzahlen des Projektcontrollings etc.
In offenen Seminaren sitzen häufig getriebene Projektmanager, die aus internationalen Projekten kommen und dort mit diesem Wording konfrontiert wurden. Die meisten Begriffe haben natürlich mit den Werkzeugen und Methoden zu tun, so dass Sie sich beiläufig einprägen, wenn man die Werkzeuge und Methoden kennenlernt.
Empfehlung
Gerade jungen Projektleitern kann ich empfehlen, sich mit dem grundlegenden interdisziplinären Handwerkszeug eines Projektleiters auf den Weg zu machen.
Ursprünglich: 1. PMP Zertifizierung, 2. Software Extension insgesamt ca. 3 Monate Vorbereitung, 3. 2 – 3 Tage das SCRUM Rahmenwerk als Seminar oder Buch.
Aktuell: PmBok 7 und die PMIStandards+ Plattform (Inhalte de PmBok Guides und dem Agile Practice Guide. Die PMIStandards+ Plattform ist online für Mitglieder des PMI im Zugriff. Auch den PmBok Guide müssen wir noch etwas warten.
Ein hervorragendes Marketing rund um die agilen Methoden, suggeriert Projektleitern ohne Vorbildung im klassischen Projektmanagement, da gäbe es mit den „agilen“ etwas vollkommen neues, nie Dagewesenes, vollkommen ausreichend, Projekte in Time & Budget zu steuern. Dem ist nicht so!
Ich höre immer wieder von Entwicklern, dass wenn es zu Problemen im SCRUM Umfeld kommt, einfach zu wenig Handlungsanweisungen zu Stande kommen. Von daher ist das Zitat von Saso Nikolov in dem Buch „SCRUM Master Examen Vorbereitung“ von hoher Relevanz: „SCRUM selbst sieht keine speziellen Tools vor. Vielmehr wird nur das Konzept mit den Rollen, Prozessen und Regeln beschrieben. Die konkrete Umsetzung wird dem SCRUM Team überlassen“. In dem von Saso Nikolov entwickelten Szenario eines ersten SCRUM Projekts in einem Unternehmen, wird dann auch ein „erfahrener Projektmanager“ als PO eingesetzt.
Hier kann die PMIstandards+ Plattform Abhilfe schaffen.
Mit den entwickelten Fertigkeiten auf Basis des PmBok Guides, finden Projektleiter sich in jeder Projektmanagementumgebung sehr schnell zurecht. Mit einem SCRUM Master dagegen, würden Sie in den meisten Projektmanagementumgebungen erst mal lange im Kreis laufen.
Was den PmBok Guide 7th angeht: Agil kann ein PMP sehr schnell. PmBok Guide dagegen, bedeutet für einen Agilisten Gehirn, viele neue Netzwerke zu entwickeln.
Renee Ossowski, PMP