PmBok Guide und agiles PM? In diesem Artikel soll es um die erste Säule aus SCRUM gehen: Das Prinzip „Transparenz“. Im Teil 1 haben wir die marginalen Inhalte SCRUMS zum Thema Transparenz betrachtet. Heute soll es um die signifikanten Inhalte zum Thema „Transparenz“, initiiert durch Kommunikation, gehen. Des Weiteren aufzuzeigen, dass die Rootagile nichts wirklich Neues erfunden hat, und dass das prognostizierende PM (pPM), notwendige Wissensbereiche für das Projektmanagement erheblich kompetenter vermittelt, als die Rootagile. PPM benötigt keine SRUMBUTS, es liefert sie!
Liest man agile BLOGS oder sieht Videos zum Thema Agilität, werden dem pPM grundsätzlich negative Attribute unterstellt. Unter dem Hashtag #classicpmbashing soll dem destruktiven Marketing der Rootagile Grenzen gesetzt werden.
#ClassicPMBashing
PmBok Guide und agiles PM als optimierte Symbiose
- Kommunikationsmanagement planen
- Kommunikation managen
- Kommunikation über wachen
KK = n(n-1)/2
KK steht für Kommunikationskanäle, n für die Anzahl der Teammitglieder! PPM innerhalb des PmBok Guides, macht sich seit mindestens 20 Jahren Gedanken über die Anzahl der Kommunikationskanäle und deren Transparenz in wachsenden Teams und Unternehmen. Transparenz in kleinen Teams mit 5 – 10 Teammitgliedern, das ist kein Kunststück!
Bei bspw. 8 Teammitgliedern ergeben sich rund 28 Kommunikationskanäle. Das lässt sich auch ohne Kommunikationsplanung noch meistern. Aber wie sieht es bei…..sagen wir mal, 16 Teammitgliedern aus? Sind es dann doppelt so viele Kommunikationskanäle? Natürlich nicht. Die Kurve steigt exponentiell! Jetzt handelt es sich um 120 Kommunikationskanäle! Rechnen Sie nach, die Formel haben Sie ja jetzt.
Sie meinen solche theoretischen Herangehensweisen an Kommunikation und Transparenz sind überflüssig? Warum meinen Sie, machen viele Startups, die einen erfolgreichen Start hingelegt haben, nach ein paar Jahren wieder dicht? Sie sind zu schnell gewachsen. Besser gesagt, sie haben versäumt, die Kommunikationskanäle zu regeln. Wenn am Anfang jeder den Chef duzte, kennen nach 3 oder 4 Jahren gut die Hälfte aller Mitarbeiter nicht mehr persönlich. Die Kommunikation in der Kaffeeküche und auf dem Flur erhält Lücken.
Wurde das exponentielle Kommunikationskonstrukt durch agile Autoren erfunden?
Falls Sie in agilen Seminaren schon davon gehört haben, der Ansatz kommt aus dem „klassischen oder traditionellen PM“, der Ansatz wurde nicht durch Ken Schwaber & Co erfunden. Auch wenn man in den Rootagiles so tut, als würde man alles neu erfinden. Hier wieder ein Beispiel.
Zitat aus dem agilen BLOG: „Wenn es nicht gelingt, die Aufgaben untereinander gut aufzuteilen, dann kann es außerdem passieren, dass sich (zu) viele Teammitglieder eher im Weg herumstehen und gegenseitig bei der Arbeit behindern.“
Allein dieser Satz – oder sollte ich sagen, diese Bauernweisheit – impliziert, dass Kommunikation ab einem bestimmten Komplexitätsgrad geplant werden muss. Die Probleme im „klassischen PM und agilen PM“ sind also identisch. Die Lösungen ebenfalls. Der PmBok Guide greift diese Probleme mit der Erfahrung von 30 Jahren, in allen Entwicklungsansätzen auf.
Die Werkzeuge und Methoden des PmBok Guides für Kommunikation und Transparenz in Projekten!
Der PmBok Guide bietet zertifizierten PMPs, PMPs in Spe als auch SCRUM Master und Product Owner insgesamt 8 Werkzeuge und Methoden*, Kommunikationsmanagement zu planen. Ergebnis sollte ein Kommunikationsmanagementplan sein, der natürlich nicht in jedem Projekt neu erstellt werden muss. Aber er muss in jedem Projekt bei veränderten Bedingungen angepasst, aktualisiert oder erweitert werden. Bspw. kam es durch Corona vermehrt zu Online Konferenzen. So sollte beschrieben werden, wie bspw. eine Konferenz mit ZOOM oder dem Teamviewer stattzufinden hat. Es muss ein Administrator bestimmt werden, der Gesprächskanäle steuert oder „Räume“ für Teile von Teams zuteilt etc.
Auch könnte es sein, dass bisher rein deutsch sozialisierte Teams, durch Chinesen oder Inder erweitert werden. Dazu müssten Verhaltensweisen trainiert werden und Regeln, basierend auf kulturellen Unterschieden, um Konflikte antizipierend zu eliminieren.
Alle Mitarbeiter sollten mal was von den vier Ohren von Schulz von Thun gehört haben. Wenn anhand von Rollenspielen z.B. trainiert worden ist, dass die Beziehungsebne die Sachebene dominiert, dann wird sich dies auf die Verhaltensweisen der Mitarbeiter im Tagesgeschäft positiv auswirken.
*Falls Sie Mitglied bei PMI sind, haben Sie Zugriff auf das Kapitel Kommunikationsmanagement auf der PMIstandards+ Plattform.
Wenn ich über Beziehungsebene schreibe oder spreche, fällt mir der Begriff „Vertrauen“ ein. Vertrauen wird in den Rootagiles quasi befohlen. „Vertrauen“ ist in der heutigen Zeit ein inhaltlich extrem inflationärer Begriff! Ich halte Vertrauen in Teams nicht für unmöglich, wenn ein guter Projektmanager oder SCRUM Master in der Lage ist, dies im Team zu etablieren.
Was aber dagegen spricht, ist der allgemeine Way of Life in den Unternehmen. Ich habe kaum ein Unternehmen kennengelernt, in denen dem Profit nicht alles andere rigeros untergeordnet wird. Wie wirkt sich dies aus?
Interessant ist in diesem Kontext der Bericht der Französin Mathilde Ramadier in der Zeit online, die in 12 verschiedenen Berliner Startups gearbeitet hat. Der Bericht ist wirklich lesenswert und spiegelt den Zeitgeist der heutigen Wirtschaftswelt. Frau Ramadier hat zwei Studienabschlüsse und hat jedes mal für Hungerlöhne gearbeitet.
Die gesamten Rootagiles entsprechen einer ähnlichen Kultur, einer Motivations Fata Morgana, ähnlich dem Wegfall der Stempeluhren.
Hinweis: Den Begriff „Rootagiles“ habe ich im Teil 1 kreiert. Er fasst alle agilen Ansätze außerhalb des PmBok Guides zusammen. In den Rootagiles erkennt man primär einen destruktiven Verdrängungswettbewerb. Er äußert sich in Lügen und Manipulationen in agilen BLOGS und Seminaren. Der Beweis soll in dieser Reihe unter dem Hashtag #ClassicPMbashing erbracht werden. Im Gegensatz zu den ständig anwachsenden notwendigen SCRUMBUTS in den Rootagiles, benötigen die agilen Ansätze des PmBok Guides keine SCRUMBUTS! Alle gewachsenen Werkzeuge und Methoden fügen sich hier in eine Symbiose mit agilen Entwicklungsansätzen zusammen.
Fortsetzung folgt