Weil wir heute im Workshop wieder auf den openPM Canvas zu sprechen gekommen sind, hier noch einmal das Erklärvideo.
Hinter dem openPM-Canvas verbirgt sich die Idee anhand eines vorgegebenen Rasters auf einer „Leinwand“ in grafisch, visueller Form ein Projekt samt seiner Besonderheiten und Restriktionen darzustellen. Es handelt sich dabei um eine Art Mischung aus Strukturierung, Visualisierung & Storytelling.
Vor einer Weile habe ich hier über einen 3-C-Projekmanagement-Approach geschrieben. Mittlerweile würde ich gerne das 3-C zu einem 4-C erweitern.
Die Idee dahinter war, unabhängig von der jeweiligen Projektmanagementsystematik oder -schule den Fokus auf Kerngebiete für den Projekterfolg zu legen, um die Wahrscheinlichkeit für den Projekterfolg signifikant zu erhöhen.
Es gibt Bereiche mit außergewöhnlichen Einfluss auf den Projekterfolg, aber auch wenn man sich auf diese konzentriert, kann man das Ergebnis immer noch grandios „versemmeln“. Es handelt sich nicht um simple Erfolgsfaktoren, die bei Einhaltung, die Erfolgswahrscheinlichkeit multiplizieren, sondern um besonders sensitive Bereiche, deren Vernachlässigung ebenso fatal sein kann, wie deren Ausgestaltung zum Erfolg beitragen kann. Aber es gilt nicht nur ihnen hinreichend Beachtung zu schenken, wir müssen dabei das Richtige tun. Ein Beispiel: Es gilt nicht nur zu kommunizieren, sondern „richtig“ zu kommunizieren. Also die richtigen Inhalte, zur richtigen Zeit, an den richtigen Adressatenkreis in der richtigen Form…
Aber, von welchen Bereichen (welchen Cs) sprechen wir? (Nun, damit es „schöne“ Cs werden, bedienen wir uns des Englischem.)
Die Fokus-Areas erfolgreicher Projektarbeit sind demnach:
Common Sense – Gesunder Menschenverstand
Context
Communication
Collaboration – Zusammenarbeit
Aber kommen wir zu den einzelnen Bereichen im Detail:
Common Sense
Machen wir uns nichts vor: Projektmanagement ist keine Rocket Science, sondern vor allem die systematische Anwendung von gesundem Menschenverstand. Dabei die Betonung auf „systematisch“ bitte nicht vergessen. Es geht schließlich nicht darum zwischendurch mal sein Hirn einzuschalten, sondern der Anspruche (zumindest eines professionellen Projektmanagers) sollte sein, dies laufen zu tun. Das lässt immer noch Platz für Intuition und Improvisation, zumindest wenn man Kahnemanns Interpretation von schnellem und langsamen Denken (Amazon Affiliate Link) folgt.
Context
Projekte sind immer kontext- und situationsspezifsch. Dem hat erst jüngst das PMI bei der Neuauflage des PMBOK Rechnung getragen (Amazon Affiliate Link). Während früher die Inhalte prozessorientiert dargestellt wurden, wird nun gepredigt die (gleichen) Inhalte kontextspezifisch anzupassen. Das schöne an der Kontextorientierung ist, dass dabei spielend dogmatische Grenzen überwunden werden. Traditionell, agil oder hybrid spielt nicht wirklich eine Rolle – es muss halt zum Kontext passen!
Communication
Um Transparenz über Problem und Lösung, aber auch in der Zusammenarbeit herzustellen braucht es Kommunikation. Die Facetten der Kommunikation sind vielschichtig, denn wir reden nicht vom Austausch von Bits und Byte, sondern von Informationen aus Menschenhand. Eine kleine Referenz auf den guten alten Schulz-von-Thun und seine 4-Seiten-einer-Nachricht und ein weiterer auf das Thema Empathie sollen hier reichen. Kommunikation lässt sich nicht rein auf die Sachebene beschränken, sondern findet immer in verschiedenen Dimensionen statt. Jede Nachricht, offenbart auch etwas über den Sender, enthält seinen Appell an den Empfänger und sagt zugleich etwas über deren Beziehung aus. (An dieser Stelle immer eine Empfehlung: Good old Schulz-von-Thun im Original (Amazon Affiliate Link)). Und Kommunikation betrifft nicht nur das Team, sondern auch alle Stakeholder!
Collaboration
Projekte sind normalerweise kein Einzelkämpfertum, sondern Teamarbeit. Insofern muss die Zusammenarbeit im Team eines unserer Fokus Areas sein. Im 3-C-Modell war das nur implizit enthalten, denn Zusammenarbeit kann ohne Kommunikation nicht funktionieren. Es besteht einfach an allen Ecken und Enden Abstimmungsbedarf. Aber es gilt nicht nur über Dinge zu sprechen, sondern ein gemeinsames Modell für eine Zusammenarbeit zu finden – egal ob traditionell oder agil – vollkommen wertfrei, das gewählte Modell muss nur von allen Beteiligten mitgetragen werden.
Also lasst uns unseren Fokus auf die 4-C setzen.
Das ist der erste Schritt.
Es gibt dafür keine einfache Patentrezepte und selbst mit dem richtigen Fokus können wir scheitern, aber ohne diesen Fokus werden wir ganz sicher scheitern.
Strategien für den Umgang mit komplexen Situationen hört sich wie ein Patentrezept für Projektarbeiter an. So trivial ist es aber nicht. Dörner identifiziert eher aus einer psychologischen Warte mögliche Handlungsoptionen und typische Fehler, das Ganze durchaus fundiert aus der Beobachtung von unzähligen Planspielen und Experimenten, aber auch aus der Analyse historischer Situationen wie dem Atomunfall in Tschernobyl.
Einen Schönheitsfehler hat die Betrachtung allerdings: Dis Schlussfolgerungen werden nicht aus komplexen Situationen, sondern aus komplizierten gezogen. Planspiele haben feste Regeln, Operations Research hat eine vollständige Modellbildung der Welt, a posteriori lässt sich die Welt erklären – aber gerade das alles haben wir in komplexen Situationen ja nicht. Vielleicht ist diese Unsauberkeit im Umgang mit dem Komplexitätsbegriff auch dem ursprünglichen Erscheinungsdatum (1989) geschuldet. Nichtsdestotrotz sind die Darlegungen auch für komplexe Situationen hilfreich und fundiert.
Als eher erfolgversprechenden Handlungsoptionen nennt Dörner u.a.:
Arbeitshypothesen permanent hinterfragen und prüfen
Hohes Maß an Selbstorganisation und Strukturierung, Fähigkeit zur Selbstkritik
Dekomposition komplexer Situationen
Balance & Kompromiss
Umgestaltung des Systems (um negative Zielkonflikte und Abhängigkeiten aufzulösen)
Zielkonkretisierung
„Reperaturdienstverhalten“/Muddling-Through – Auch wenn Dörner die Gefahren eines solchen Verhaltens sieht (siehe unten): Behebung von Missständen ist die bessere Alternative zum Gar nichts tun.
Anpassung an wandelnde Kontexte/Kontextspezifisches Verhalten
Institutionelle Trennung von Informationssammlung und Entscheidung
Vorausschau zukünftiger Szenarios
Vorwärts- und Rückwärtsplanung
Strategien zur Suchraumeinengung:
o Heurismen
o Hill Climbing (nur solche Aktionen in Betracht ziehen, die einen Fortschritt in Richtung auf das Ziel versprechen mit der Gefahr auf einem Nebengipfel zu landen statt am eigentlichen Ziel)
o Zwischenzieleo Effizienz-Divergenz, d.h. Situationen anstreben, die möglichst viele Handlungsoptionen mit relativ hoher Erfolgswahrscheinlichkeit offen lassen
o Frequency-Gambling (Was hat in der Vergangenheit funktioniert?)
Strategien zur Suchraumerweiterung:
o Freies Probieren (Trial & Error)
o Ausfällen des gemeinsamen nach Duncker (Welche Gemeinsamkeiten haben die bislang erfolglosen Lösungsversuche?)
o Analogieschlüsse
Wechselspiel von Suchraumeinengung und Suchraumerweiterung
Tendenziell zu fehlerhaftem Verhalten/Misserfolg verleitet hingegen:
Arbeitshypothesen werden als wahr hingenommen und nicht weiter hinterfragt.
„Reperaturdienstverhalten“/Muddling-Through (Konzentration auf die Behebung isolierter Missstände, wobei die Vorstellung des eigentlich angestrebten Zielzustandes auf er Strecke bleibt)
Überbetonung des aktuellen Motivs
Informationelle Überlastung
Similarity Matching (Tendenz, eher auf Ähnlichkeiten als auf Unterschiede zu reagieren)
Schematisierungen und Reglementierungen
Nichtberücksichtigung von Friktionen („Unvorhersehbarkeiten“)
Alles in allem eine empfehlenswerte Lektüre und bemerkenswert auch: Welches deutschsprachige Buch zu einem abstrakten, wissenschaftlichen Thema kann schon auf so viele Auflagen verweisen?
PMI (Hrsg.), Der Standard für das Projektmanagement und A guide to the project management body of knowledge (PMBOK guide), 7. Ausgabe, Newtown Square, Pennsylvania 2021 (Amazon Affiliate Link)
Mit Standards ist das so eine Sache: Einerseits wünschen wir uns Stabilität und Orientierung von ihnen, andererseits müssen sie sich natürlich im Laufe der Zeit weiterentwickeln. Perfide kann es dann werden, wenn Standards auch noch Grundlage für ein Geschäftsmodell (z.B. ein Zertifizierungsbusiness) sind. Da kommt dann manchmal der Verdacht auf, dass es Änderungen braucht, um das Geschäftsmodell am Laufen zu halten, da muss dann allein schon was geändert werden, um die neue Ausgabe, Materialien und Trainings verkaufen zu können oder Inhalte richten sich nach dem Geschäftsmodell aus.
Nachdem sich PMI (genauso wie auf der anderen Seite die GPM) solche Geschäftsmodelle zu eigen gemacht haben, werden Änderungen kritisch beäugt. Die jüngst erschienene siebte Ausgabe des PMBOK ist aber weit mehr als ein solcher, eher kosmetischen Eingriff um den Rubel weiter rollen zu lassen. Sie ist einerseits ein fundamentaler Paradigmenwechsel und gleichzeitig ist sie das nicht.
Um eines vorneweg zu sagen: Der PMBOK hat Projektmanagement nicht neu erfunden, auch wenn er kaum wiederzuerkennen ist. Eine Disziplin wie das Projektmanagement erfindet sich nicht einfach neu, auch wenn die Diskussion über traditionelles und agiles Projektmanagement in den letzten 15 Jahren das nahelegen könnte. Diese Kontroverse (zuletzt noch erweitert um den dritten unsäglichen Weg des hybriden Projektmanagement) umgeht der PMBOK elegant mit einem Sprung auf die Metaebene, denn egal welcher Schule man folgt, auf der Metaebene sind Projekte immer noch Projekte. Ein Projekt ist ein Projekt, ist ein Projekt.
Wer sich mit Projekten beschäftigt wird daher in der neuen Ausgabe des PMBOK nicht zwangsläufig etwas Neues lernen. Wenn ich nach einer alten Version oder einem anderen Standard zertifiziert bin, muss ich jetzt dann komplett umlernen? Nein, natürlich nicht.
Um zu verstehen, was den neuen PMBOK so grundlegend anders macht, werfen wir erst einmal einen Blick zurück und vergleichen ihn mit den anderen beiden internationalen Projektmanagementstandards, der von GPM und IPMA verfolgten ICB und PRINCE2. In der Vergangenheit haben diese drei Standards den gleichen Gegenstand und die gleichen Vorgehensweisen betrachtet, aber aus einem jeweils anderen Blickwinkel, während PRINCE2 Projektmanagement als Managementsystem betrachtet und beschrieben hat, stellt die ICB die für Projekte erforderlichen Kompetenzen in den Mittelpunkt und der PMBOK (alt) hat generisch Projektmanagementprozesse und die dabei zum Einsatz kommenden Wissensgebiete in den Fokus gerückt. Und genau darauf verzichtet der neue PMBOK. Er sagt mit keiner Silbe, dass diese Logik falsch war – ist sie auch nicht, er gibt sie lediglich als Gliederungs- und Strukturierungslogik auf. Und ehrlich gesagt: zurecht. Für unsere LinkedIn Learning Projektmanagementkurse habe ich mich immer wieder mit den drei Standards (aber selbstverständlich auch mit agilem Projektmanagement) auseinandergesetzt. Für jedes Training habe ich dann immer auch die Prozessperspektive des PMBOK abgeklopft, aber ehrlich gesagt, war diese Übung aufgrund des generischen Charakters des PMBOK eher dröge. Ich habe noch nie ernsthaft in einem Projekt in die Prozessdarstellung des PMBOK geschaut oder wäre auf die Idee gekommen dort praktischen Rat zu suchen, lediglich zur Prüfung unseres Curriculums hat mir der PMBOK (alt) gedient. Obendrein gab es gewisse Redundanzen, den in den unterschiedlichsten Prozessen kommen natürlich immer wieder die gleichen Werkzeuge, z.B. Facilitation zum Einsatz.
Der PMBOK (neu) verzichtet auf diese Darstellung, aber die Inhalte sind schon noch da, eingebettet in einem generalüberholten Ansatz – auf der Metaebene und der sieht wie folgt aus:
Ganz am Anfang steht der (ANSI) Projektmanagementstandard. Dieser war in unterschiedlichster Form und an unterschiedlicher Stelle (nachzulesen bei Thomas Wuttke im projektmagazin) immer schon Bestandteil des PMBOK. Aber auch dieser Abschnitt ist kaum wiederzuerkennen, denn auch hier wird auf die gewohnte Prozessbetrachtung verzichtet. In der Einleitung, die vor allem auch wichtige Begriffe und Konzepte definiert und uns dabei auch nicht im Geringsten überrascht, folgt ein Abschnitt über das System der Werterstellung (ich tät halt neudeutsch sagen: Value proposition) und ein weiterer mit grundlegenden Prinzipien des Projektmanagement. Klingelt es? Wieso muss ich dabei an das (geflissentlich nicht erwähnte) Agile Manifest denken?
Die Prinzipien des Projektmanagements basieren auf den vier Grundwerten des PMI Code of Ethics and Professional Conduct (was zeigt, dass Inhalte und Grundalgen des PMI grundlegend eingearbeitet und enthalten sind). Diese sind:
Der Norm folgt der eigentliche Guide. Da ist jetzt von acht Leistungsdomänen (Performance Domains) die Rede. Hört sich spontan nach den alten Wissensgebieten an, ist aber etwas anderes.
Die Leistungsbereiche sind:
Stakeholder
Team
Entwicklungsansatz und Lebenszyklus
Planung
Projektarbeit
Lieferung
Messung
Unsicherheit
Ein Thema wie die Stakeholder, das oft leichtfertig als selbstverständlich hingenommen wird (projektmagazin), bekommt die zentrale Einbettung, die ihm gebührt und auch die anderen Domänen überraschen uns nicht, weder vom Thema noch von den Inhalten, aber wozu auch, Projektmanagement 2021 erfindet die Welt nicht neu und trotzdem trägt der PMBOK mit der Leistungsdomäne Unsicherheit den Diskussionen um die VUCA-Welt Rechnung, allerdings wieder ohne Referenz, ähnlich wie beim agilen Manifest. So sehr ich die Aufnahme dieser Themen begrüße, da haben salopp gesagt „die Eier gefehlt“, als wären das originäre PMI Inhalte. Es macht ein bisschen den Eindruck, als wolle man sich da mit fremden Federn schmücken. Ich würde mir hier mehr Souveränität wünschen. Diese Attitüde gefällt mir nicht.
Den Domänen folgt das Kernstück: Die Anpassung (Tailoring). Die Sinnhaftigkeit eines One-size-fits-all-Projektmanagements wird grundsätzlich in Frage gestellt und die Notwendigkeit zur Anpassung an den organisatorischen Kontext hervorgehoben. Projektmanagement muss also kontextspezifisch bzw. situativ sein. Ach. Gute Projektmanager haben das schon immer gepredigt. Schon immer praktiziert. Und jetzt wird diese Anpassung zum Markenzeichen des PMBOK. Gut so. Wenn ICB weiterhin die Kompetenzperspektive hochhält und PRINCE2 sich als Managementsystem versteht, dann ist die Philosophie des PMBOK (neu) jetzt situatives oder kontextspezifisches Projektmanagement. Das ist nicht nur klug, sondern auch elegant, denn auf dieser Ebene lassen sich die verfluchten Grabenkriege traditionell vs. agil wunderbar überwinden.
Den fehlenden Baustein zu Projektmanagementmethoden schließt das Kapitel: Modelle, Methoden und Artefakte – eine Methodensammlung, die zum trojanischen Pferd überleitet. Ein solches verbirgt nämlich auch noch im PMBOK: PMIstandards+.
Hier schließt sich der Kreis zum eingangs erwähnten Geschäftsmodells. Das PMI versucht damit eine interaktive digitale Plattform zu etablieren, die – wer weiß – vielleicht sogar eines Tages den PMBOK ablösen kann, denn wer liest denn heute zutage noch Bücher? Mit openPM hatte ich mit einigen Mitstreitern vor 10 Jahren versucht so eine Plattform mit freien Inhalten zu etablieren. Mangels Umfang und Relevanz sind wir daran vermutlich gescheitert. Zu meinem Grundverständnis und Berufsethos gehört, dass solche grundlegenden Inhalte transparent sein sollten und d.h. dass sie bis zu einem gewissen Grad auch frei und offen zugänglich sein sollten (deren Anwendung, Ausarbeitung und Umsetzung ist dann wieder etwas anderes). Ehrlich gesagt habe ich kein gutes Bauchgefühl, wenn nun das PMI versucht hier Pflöcke einzuschlagen und Claims abzustecken – vermutlich mit kommerziellen Interessen. Fehlende Referenzen im PMBOK und das über Jahrzehnte entwickelte Zertifizierungsbusiness stimmen mich da nachdenklich.
Den grundsätzliche Paradigmenwechsel des PMBOK, der keiner ist, der Fokus auf das Tailoring, eine mögliche Überwindung von traditionell und agil (ohne das blöde hybrid) sind echte Errungenschaften des PMBOK, der ihm einen Sprung in eine neue Zeit ermöglicht ohne die bisherigen Inhalte aufzugeben oder über Bord zu werfen. PMIstandards+ enthält übrigens auch noch die Prozesswelt des PMBOK 6th edition (Amazon Affiliate Link). Dies widerspricht sich nicht, denn die „alte“ Prozesswelt ist lediglich eine sehr generische Betrachtung des Projektmanagements ohne spezifisches Tailoring, also quasi ein Art Maximal-Ausprägung.
Die Anhänge hätte ich jetzt beinahe noch vergessen. Sponsor und Projektmanagementbüro hätte man sicher auch an anderer Stelle integrieren können. Bemerkenswert ist ein eigener Anhang zum Thema „Produkt“ in dem die Perspektiven von Projekt- und Produktmanagement einander gegenübergestellt werden. Nur wenige Seiten, aber vielleicht mit Potential für künftige Auflagen.
Alles in Allem ein guter Weg, den der PMBOK eingeschlagen hat, auch wenn mich die „hidden agenda“ etwas skeptisch zurücklässt. Das tut der Qualität des PMBOK aber keinen Abbruch.
Von einem unserer Teilnehmer der LinkedIn Learning Projektmanagement-Kurse, ein Entwicklungsingenieur eines Automobilzulieferers, kam die Tage eine Anfrage nach Tipps und Empfehlungen zu Fortbildungen und evtl. Zertifizierungen um den nächsten Schritt zu machen. Hier meine Antwort:
Lieber…, zunächst einmal freut es mich, dass unser Angebot auf Resonanz stößt und Interesse nach mehr geweckt wird. Mission accomplished. Beim Thema Zertifizierung bin ich hin und hergerissen. Erstmal stellt sich die Frage, was mit einer Zertifizierung erreicht werden soll. Um Grundlagen zu lernen, waren Sie ja schon bei uns. Darüber hinaus sehe ich im Wesentlichen einen Grund für eine Zertifizierung: Ein Passierschein für HR- und Einkaufs-Abteilungen, die können bei Ausschreibungen, Bewerbungen dann nämlich einen Haken in ihren Checklisten setzen. Aber auch eine erfolgreiche Zertifizierung heißt nicht, dass man ein erfolgreicher Projektmanager ist. Im traditionellen PM sind vor allem PMI und GPM die Platzhirsche. Von einer IHK-Zertifizierung oder ähnlichem würde ich eher absehen (es sei denn es geht wieder um die Grundlagen). Was die geeignetste Zertifizierung ist, würde ich vom individuellen Umfeld abhängig machen. Wenn in Ihrer Firma die Fahnen des PMI hochgehalten werden, würde PMI Sinn machen, umgekehrt GPM, wenn dieser Standard wertgeschätzt wird. Ich würde das eher pragmatisch als dogmatisch sehen. Agile ist dann nochmal eine eigene Welt. Für die eigene Entwicklung (wenn es nicht nur um den erwähnten Passierschein geht), kann ich nur Praxis und Eigeninitiative empfehlen. Statt sich mit der ganzen Breite des PM-Kanons berieseln zulassen, macht es vielleicht mehr Sinn eigene Schwerpunkte zu setzen. Kontext- und persönlichkeitsspezifisch. Stärkung von Kommunikation und Moderationsfähigkeiten sind immer gut. Welche besonderen Anforderungen gibt es in ihrem konkreten Umfeld? Ich persönlich schätze Maturity Modelle nicht besonders, ich weiß aber, dass in Teilen der Automobilindustrie diese hochgehalten werden. Sollte das in Ihrem Umfeld der Fall sein, macht eine Auseinandersetzung damit vielleicht Sinn. Was ich obendrein nur empfehlen kann ist sich zu vernetzen. Meine Persönliche Empfehlung sind da vor allem die PM-Camps (www.pm-camp.org), wo man auf Gleichgesinnte trifft und viele Impulse mitnimmt. Die Szene hat Corona-bedingt etwas gelitten, ich bin mir aber sicher, dass sie in einer Post-Corona-Ära wieder umso mehr nachgefragt wird. Ich hoffe, diese Anregungen helfen Ihnen weiter. Viel Erfolg auf Ihrem Weg! Gruß Bernhard Schloß
Mit openPM (https://www.openpm.info/) ist ein Freigeist im Business/Projektmanagement-Umfeld entstanden. Eine Community, die Wert auf das freie Teilen und Offenheit legt. Und das seit 10 Jahren. Eng verwoben mit den PM-Camps.
Aber auch wir haben unsere Krisen und Probleme.
Aktuell fragen wir uns, ob das Wiki mit dem wir gestartet sind noch die zeitgemäße Antwort ist. Wir diskutieren wie viel Social Media wir brauchen oder wie weit wir uns davon wieder emanzipieren wollen.
Es gibt kein richtig und kein falsch.
Wir suchen Ideen, wie wir einen freien Austausch in Business/Projekt/Prozess-Managementthemen künftig schaffen können. PM-Camps und Veranstaltungen sind ein Weg, aber was wollen wir darüber hinaus? Ein Stack Overflow für Projekte? Ein Forum? Oder doch eine Wissensdatenbank á la Wiki?
Bitte gebt Euren Input hier. Helft uns diese Diskussion zu befruchten.
In der vergangenen Woche durfte ich das Team eines Kunden 2-Schulungstage (verteilt auf 3 Arbeitstage durch ein Projektmanagement-Training begleiten. Für die Tage hatten wir kein strenges Curriculum, sondern die Vorgabe war eher als Personalentwicklungs- und Förderungsmaßnahme gedacht. Entsprechend haben wir den Titel „Projektmanagement“ mehr als Thema/Motto verstanden und nicht als harte Vorgabe. Aufgrund der Hinweise und Wünsche des ersten Tages, konnten die Inhalte dann teilnehmerspezifisch für die folgenden Tage angepasst werden.
Nachdem es sich um ein verteiltes Team handelte, haben wir auch MIRO intensiv genutzt- hier ein Eindruck von einem unserer Boards:
Ich bin ja nicht unbedingt ein „Zertifizierungsfan“, aber ein so flexibel gestaltetes interaktives Schulungsangebot kann sicher einen wertvollen Beitrag für alle Teilnehmer leisten. Und wenn sie mich nicht alle angelogen haben (was ich jetzt nicht glaube), dann waren die Tage nicht nur intensiv und zielführend, sondern auch der Spaß in der Gruppe und am Lernen kam nicht zu kurz.
Wir haben ganz gezielt versucht auch über das Kursende hinaus Impulse zu setzen.
Vielen Dank, dass ich dieses Team auf ihrer Reise ein Stück begleiten durfte.
Gerade wurde unser Kurs „Agiles Projektmanagement“ im Rahmen der Reihe »Beliebteste Kurse auf LinkedIn Learning« vom 1.9. bis 15.10.2021 für den deutschsprachigen Raum freigeschaltet, d.h. auch ohne Premium-Account habt Ihr kostenlos Zugriff auf den Kurs.
Daneben läuft weiterhin die Microsoft-Kampagne in deren Rahmen unser Lernpfad „Projektmanager:in werden“ ebenfalls kostenlos freigeschaltet ist.
As I am just preparing an English training in project management I am trying to sort my thoughts. I do not want to focus on traditional vs. agile (or even hybride), I would like to focus on what really counts in any kind project management and this is what I would call the 3-C approach, setting a clear focus in three areas – the three Cs:
Common Sense
Context
Communication
I have to admit: these three seem to be quite trivial but even knowing better we are loosing track on those so easily. Actually they even do not seem to be project management specific. But in complex challenges as projects are they are so important.
But let us have a short look on them.
Common Sense
Obviously we should practice common sense in everything. But do we really do that? Nothing against intuition but there are so many biases affecting our perception that we should be aware of.
Having a look on the agile manifesto most of its messages also seem to be just common sense. Even a traditional old school project manager would agree with most of them but why did theys became such a milestone for agile project management? (Got the irony?) Well, practice of traditional project management often became something very formal and bureaucratic. Focus on customers, working results and collaboration got lost. Of course that was not the fault of traditional project management, that´s just the fault of bad practice. And we can find bad practice anywhere – even in agile project management.
A last aspect of common sense I would like to reflect here: Due to their importance and complexity it should be quite obvious that we should try to face projects systematically and in a professional way (independent of the school we are following). Honestly, even this simple truth has to be recalled in our minds from time to time.
Context
Context is everything. There is no simple truth (beside the 3Cs). Most questions can only be answered with yes or no for a specific context. Even that 1+1=2 is only true in our sense of mathematics. The tricky thing with projects is that we usually don´t really know our context enough. That is a major difference to routine jobs and processes. There we do not even have to think about the context – it is a fixed setup. But projects are different. We have to explore the context first. And even worse: the context might not be something fix and can change anytime.
In my personal opinion even the choice of our project management approach (traditional/agile/hybride) should always be the result of our context. Too often this is handled differently: we are pressing our projects and their respecting context in our ideological setup. And later we wonder why we failed.
Communication
The last of the three Cs is communication. Any kind of collaboration needs communication. If we try to explore our context, try to learn, try to solve our problems, try to convince others, and so on. We always depend on communication.
In any complex area we can only reach transparencey through communication.
Again my personal opinion: one of the major success factors in SCRUM is the institutionalization of communication. Daily standups, retrospectives, etc. are a booster for our communication. They are the opposite of paper work and status reports. We shouldn´t take so much political care of the colour of our traffic lights in a status report and focus on our common understanding shared e.g. in our daily or any other form of communication. If a working commuication model is in place, the choice of our project management approach is less important.
There is nothing right or wrong on the various approaches of project management. In the end we well only be asked: Did we succeed? Did we reach our goal?
To be honest: even a perfect implementation of project management might fail. But the 3Cs, I mentioned here, can help to raise the probabilty to succeed – and not only in project management. Loosing the focus on them is a short track to failure.
Als kleine Fingerübung entstand dieses Erklärvideo über die Entstehung von Projekten.
Mal schauen, vielleicht wird das auch eine lose Video-Reihe hier im Blog. Solche Trainingsvideos sind ein Beispiel für visuelle Kommunikation, deren Bedeutung immer mehr zunehmen wird und deren Einsatzmöglichkeiten immer vielfältiger und auch einfacher werden.
