PmBok Guide contra SCRUM? Schon im Teil1 und Teil2 wurden sinnvolle Argumente aufgezeigt, die den Nachweis erbringen, das Ken Schwaber und Jeff Sutherland sich vom im PmBok Guide erheblich inspirieren ließen. Unter dem Hashtag #classicpmbashing soll nachgewiesen werden, dass ein neues Wording, verkürzte Entwicklungsphasen, Umverteilung der Verantwortung und der Daily SCRUM schon alles ist, was das agile vom prognostizierten (klassisch oder traditionell, nach agil ideologischen Bashings) Projektmanagement (pPM) unterscheidet. Agile Trainer lügen und manipulieren in Seminaren und BLOGS, implizieren, dass sogenannte SCRUMBUTS nichts mit dem pPM zu tun haben. Dabei werden sukzessive Werkzeuge und Methoden durch die Hintertür als SCRUMBUTS deklariert in agile PM eingeführt. Im Teil 1 haben wir dazu einen ersten Nachweis erbracht: Die Kommunikationsformel
KK = n(n-1)/2
Der PmBok Guide 6 und der neue PmBok Guide 7 in Verbindung mit der PMIstandards+ Plattform, schaffen eine optimierte Symbiose zwischen agilen und prognostizierenden Methoden. Alle bewährten Werkzeuge und Methoden, stehen hier direkt zur Verfügung, ohne sich als „Agilebut“ einschleichen zu müssen.
Auf die PMIstandards+ Plattform haben Sie nur als PMI Mitglied Zugriff.
Konstruktive Kommunikation = Transparenz!
Im Teil 1 und Teil 2 haben wir zum ersten „Transparenz“ aus der Perspektive SCRUMs beleuchtet, danach aus der Perspektive des PmBok Guides. Ob man in SCRUM Seminare oder BLOGS schaut, es werden immer sehr schön Sätze auf der Metaebene herunter gebetet. Handhabbares sucht man vergebens.
Zuletzt ging es um die Werkzeuge und Methoden, die der PmBok Guide im Rahmen der Kommunikationsplanung zur Verfügung stellt. Wir hatten festgehalten, dass es durchaus Sinn macht, Kommunikation zu planen.
Der zweite Prozess lautet „Kommunikation managen“. Dieser Prozess enthält neben diversen administrativen Werkzeugen und Methoden Softskills, wie z.B. das im Vorfeld angesprochene Konzept des aktiven Zuhörens.
Der dritte Prozess des Kapitels beinhaltet die Überwachung der Kommunikation. Nicht zu verwechseln mit Kontrolle. Ein Projektleiter oder SCRUM Master muss soziale Kompetenz mit einbringen, um im täglichen Miteinander Kommunikationsprobleme zu erkennen und empathisch zu lösen. Bleiben wir beim „aktiven Zuhören“.
Wenn er feststellt, dass Kommunikation destruktiv verläuft – gemeint sind nicht Konflikte -, müssen Maßnahmen ergriffen werden, um die Mängel zu beseitigen. Viele Menschen sind keine aktiven Zuhörer. Sie suchen während der Darstellungen des Kommunikationspartners die Lücke oder Pause in der Argumentation, um selbst die Initiative zu ergreifen. Ich nenne sie „Lücken-Kommunizierer“. So kommt es häufig zu Missverständnissen, die zur Intransparenz führen. Gute Kommunikatoren wissen, wie man aktiv zuhört. Das hat nichts mit intensiven Zuhören zu tun. Eine bestimmte Konzentration gehört immer zu einer konstruktiven Kommunikation.
Transparenz bedeutet eben nicht, Transparenz zu befehlen, sondern konstruktive Kommunikation zu beherrschen. Dadurch entsteht eine Säule der Transparenz.
In einem PMP Seminar lernen Projektleiter diverse Werkzeuge kennen, um Kommunikation zu planen, zu managen und zu überwachen um Kommunikation transparent und effektiv zu machen.
Exkurs: Kennen agile Trainer den PmBok Guide?
Der Begriff „Plangesteuert“ wird ebenfalls falsch vermittelt. MS Project frequentiert sehr gut die Methoden des PmBok Guides. In MS Project existiert ein PLAN (Geplant), ein SOLL (Berechnet ) und ein IST (Aktuell). Der Plan oder Basisplan in MS Project dient einerseits dem Earned Value Management, dass den „Wert“ des Liefergengenstands oder Artefakts im Fokus hält. Auf Basis der Plankosten (Basisplan 0) werden ständig die monetär bewerteten Anforderungen geprüft, inwieweit die erfüllt sind. Ein laissez fair definiertes „Done“ reicht dem pPM nicht aus. Kommt es zu signifikanten Abweichungen, die ein weiteres Tracking mit dem Basisplan 0, bezüglich der darauf basierenden Kennzahlen ( Tabelle auf Seite 267 PmBok Guide 6) unrealistisch werden lässt, wird ein Basisplan 1 mit dem eingearbeiteten Change gespeichert, der dann dem weitern Tracking dient.
Zum andern gilt es auf der SOLL Ebene Prognosen auf Basis der erreichten Ergebnisse, eingetretenen Risiken und anstehen Changes vorzunehmen.
Ist ein Projektplan vergleichbar mit einem Bauplan?
Die dritte Berechtigung eines Plans, zeigt folgendes Beispiel. Ein Bahnkunde wartet auf seinen Zug, der sich schon um 10 Minuten verspätet hat. Als ein Schaffner vorbei kommt murrt der Kunde sich in den Bart, „Warum macht die Bahn Pläne, wenn die Züge doch zu spät kommen?“ Antwort des Schaffners:“ „Damit die Bahn weiß, ob und welche Züge zu spät gekommen sind.“
Man muss sich keine schlaue „Retrospektive“ veranstalten, es reicht auch am Ende einer Phase – in der Abschlussprozessgruppe – alle Fehler und Probleme zu dokumentieren und für die Zukunft als Assets zur Verfügung zu stellen.
Ich gebe aber zu, „Retro-spektive“ hört sich einfach besser an als Abschluss-prozessgruppe oder Closing Prozess Group. Das aufgepeppte Wording im agilen PM, macht durchaus Sinn, wenn man die Generation Y erreichen will.
Von „Plangesteuert“ im eigentlichen Sinn, kann also keine Rede sein.
„Plangesteuert“ impliziert starres Festhalten an den Plan! Das unterstreicht dieser „Trainer“ zusätzlich mit einem banalen Beispiel eines Autofahrers, der sich strikt an die Aussagen seines Navis hält, obwohl die reale Lage ihm deutlich etwas anderes aufzeigt.
Ich kann immer nur wieder den Kopf schütteln, mit welchem Dummie-Wissen agile Trainer die Methoden des prognostizierenden Projektmanagements kommentieren, um agiles PM, als überlegen zu deklarieren.
PPM Change avers?
Auch der Begriff „change avers“ sollte sich mit dem MS Project Beispiel erledigt haben. Der PmBok Guide befasst sich auf den Seiten 113 – 120 ausführlich mit dem Prozess „Änderungssteuerung durchführen“. Im gesamten PmBok Guide, wird 93 Mal auf den Prozess „Änderungs-steuerung durchführen“ Bezug genommen.
Ist das „Change avers“?
PmBok Guide contra SCRUM?
Fortsetzung