Auf LinkedIn hat mich (wohl aufgrund unserer agilen Projektmanagement-Angebote auf LinkedIn Learning) eine Frage erreicht:
„Was sind mögliche Requirements der Kunden?“ – also nicht allgemein, sondern im agilen Umfeld. Ich wurde um ein, zwei Stichworte gebeten.
Hier nun meine Antwort:
Also ganz ohne Kontext ist eine solche Frage nur schwer zu beantworten, da muss ich auf die Metaebene ausweichen:
Der Kunde benötigt frühzeitig erste Ergebnisse um zu Lernen und Feedback geben zu können.
Es gibt ein paar Voraussetzungen, die dafür erforderlich sind und die allzu leicht übersehen werden:
Die Requirements/Backlog Items/Users Stories müssen „schneidbar“/modularisierbar sein (historisch war ja auch die modularisierte Webentwicklung eine der Turbostränge des agilen Projektmanagements).
Entsprechend ist die Skalierbarkeit des Projekts/der Lösung häufig ein Problem. Es gibt zwar auch hoch skalierte Formen agilen Projektmanagements, ob diese aber immer den Namen „agil“ verdienen darf bezweifelt werden.
Wenn ich über meine Antwort von heute morgen noch weiter nachdenke, dann könnte man auch noch Voraussetzungen für die Zusammenarbeit im Sinne des Mindset des agilen Manifests anführen, aber da verlassen wir die Anforderungsebene noch mehr.
Wem weitere Aspekte dazu einfallen, der ist herzlich eingeladen die Kommentarfunktion zu nutzen.
Im „allgemeinen“ Lernpfad finden übrigens agile, wie traditionelle Ansätze gleichermaßen Berücksichtigung. Der allgemeine Lernpfad „Projektmanager:in werden“ ist übrigens auch das von Microsoft für alle kostenlos frei zugänglich geschaltete Kursangebot – also auch ohne LinkedIn Premium Account.
Freitag/Samstag waren wieder intensiv: PMCampVirtual war angesagt.
Eher eine kleine exklusive Runde, aber trotzdem intensiv und kein Abbruch gegenüber anderen PMCamps.
Highlight des PMCampVirtual sicher der Lighting Vortrag von Gitta Peyn.
Ich bin ja durchaus ein „Fan“ sozialer Systeme, selbst á la Luhmann, aber was mir fehlt ist die Verknüpfung materieller und sozialer Systeme. Nicht dass ich ein Technokrat wäre, aber die Entwicklung materieller Systeme kann durchaus zum Gamechanger werden. Regeln könne aus ihren Angeln gehoben werden. Auch Regeländerungen in materiellen Systemen interagieren mit sozialen Systemen.
Hamid Rahebi und Michel Frahm haben ein Buch über Megaprojekte im Bauwesen (Amazon Affiliate Link) geschrieben und u.a. der geschätzte Kollege Thomas Mathoi und meine Wenigkeit durften im Vorfeld ihre 5 Cent beisteuern. Ich glaube, die Autoren haben uns anfangs verflucht, aber unser Input hat sicher geholfen an der einen oder anderen Stelle nachzuschärfen.
Umso mehr freue ich mich für Michel und Hamid, dass sie ihr Werk jetzt auch in gedruckter Form in Händen halten können. Euch beiden herzlichen Glückwunsch!
Und auch Dankeschön für mein Exemplar samt Widmung.
Jetzt haben wir noch einmal nachgelegt, d.h. eigentlich „vorgelegt“, denn der neue Kurs Berufsbild: Projektmanagement geht eigentlich den anderen Kursen voraus – ein Prequel sozusagen.
Einen Punkt aus dem neuen Kurs möchte ich gerne auch hier aufgreifen: Ja, die Projektmanagement-Standards und Methoden sind nicht in Stein gemeißelt und entwickeln sich weiter, aber: unsere Kursinhalte sind weiter relevant.
Niemand wird Projektmanagement neu erfinden!
Die überarbeitenten Standards der Verbände reflektieren lediglich aktuelle Trends und Entwicklungen. Wir haben nach der Veröffentlichung von ICB 4.0 unsere Kursunterlagen, die vereinzelt auf ICB 3.0 verwiesen haben, gereviewt, aber inhaltlich hat sich kein Änderungsbedarf ergeben, da wir von Haus aus den Blick über die Grenzen der einzelnen Standards hinaus gelenkt haben.
Auch zum Lernpfad agiles Projektmanagement wird ein ähnlicher Kurs, dann eingesprochen von Daniel Reinold folgen.
Eine Besonderheit teilen beide Kurse: Corona-bedingt können wir derzeit nicht in die Grazer Studios von LinkedIn und mussten daher auf einen reinen Screencast ausweichen, das hat aber besser geklappt als gedacht.
Nun vorab: Über Facilitation als Geheimwaffe im Projektmanagement habe ich erst im Projektmagazin geschrieben und ganz ehrlich: ich habe mich selbst in der Projektarbeit, sei es in eigenen Projekten oder in Kundenprojekten, immer als Facilitator verstanden – selbst als ich den Begriff noch gar nicht kannte.
Stefans Frage war für mich aber Anlass genug unsere LinkedIn Learning-Trainings noch einmal zu durchforsten.
Gleich zu Beginn ein Zitat aus der fünften Auflage des PMBOK: „Facilitation techniques have broad application within project management processes and guide the development of the project charter.“ (Affiliate Link zur aktuellen Ausagbe)
Das findet sich bereits im Werkzeugkasten für die Auftragsklärung in unserem Kurs zu Initiierung und Setup von Projekten. Es gibt an dieser Stelle auch schon einen Hinweis auf Graphic Facilitation (und Graphic Facilitation ist ja auch eines unserer Steckenpferde, denn Business Visualisierung gibt es von uns sowohl auf LinkedIn als auch in Buchform(Affiliate Link)).
Der PMBOK selbst nennt einige Beispiele für Facilitation-Methoden: „Brainstorming, Konfliktlösung, Problemlösung und das Management von Besprechungen sind Beispiele für Schlüsseltechniken die Moderatoren benutzen um Teams und Einzelpersonen zu helfen Projektaktivitäten erfolgreich durchzuführen.“
Zu den in unserem Kurs behandelten Facilitation-Techniken (ohne Anspruch auf Vollständigkeit) gehören Methoden der Umfeldanalyse, wie Stakeholderanalyse, Stakeholderdiagramm, Multiple-Cause-Diagramm, Context Map, Branchenanalyse, Moderations- und Analysewerkzeuge (angefangen mit der Kartenabfrage, Mindmaps, Gap-Analyse) und last but not least Ishikawa, Problemskizze und Canvas. Und wen wundert es da, dass sich dort auch der openPM-Canvas wiederfindet.
Natürlich geht es auch im Kurs Team, Führung, Zusammenarbeit um Facilitation, auch wenn der Begriff nicht explizit fällt.
Der Kommunikation in Projekten haben wir in unserem Lernpfad einen eigenen Kurs gewidmet. Dabei geht es natürlich auch um Moderation und Moderationskompetenz. Facilitation übersetzen wir an dieser Stelle als Prozessbegleitung und Moderation und geben noch den Tipp: Wirken Sie als Facilitator!
Auch in unserem Kurs zur Qualität stolpern wir wieder auf den PMBOK Hinweis zu Facilitation-Techniken.
Bei den Werkzeugen und Hilfsmitteln tauchen bei uns statt des unvermeidlichen MS Project dann so Konzepte auf, wie Coaching und Gamification und es geht um Lernen (Wissensmanagement hingegen haben wir im Kurs über den Projektabschluss berücksichtigt).
Der Kurs Krisen und Erfolg enthält eines unserer Lieblingskapitel der gesamten Lernpfades: Die Projektgeschichten. Und gleich in zweien dieser Projektgeschichten ist von Facilitation die Rede: Einmal bei den Anfangsschwierigkeiten bei denen wir Facilitation als Möglichkeit anpreisen Kommunikation und Zusammenarbeit in Gang zu bringen und auch auf der psychologischen Seite zur Überwindung von „Scheuklappen“.
Natürlich sind auch unsere agilen Kurse voll mit Hinweisen auf Facilitation. Da finden sich alte Bekannte, wie der openPM Canvas. Facilitation Techniken werden als Werkzeuge aufgeführt. Neben Canvas, Mindmaps und Context Maps tauchen dann auch Boards auf. Ein Scrum Master ist doch ein Facilitator par excellence!
In unserer eigenen Arbeit (und dabei darf ich meine Kollegen Christian, Daniel und Stefan mit einschließen), versuchen wir Facilitation tatsächlich anzuwenden. Entsprechend findet das Thema auch in unseren Trainings einen hohen Stellenwert. Nur logisch, dass auch ein eigenes Facilitation-Training für LinkedIn Learning aktuell in Vorbereitung ist. Diesmal aber „ganz allgemein“ und nicht mit einem projektspezifischen Fokus. Ihr dürft gespannt sein!
Mit einer auf dem Kopf stehenden Pyramide lassen sich schematisch die Anforderungen (Englisch: Requirements) an ein Produkt, System oder einen Prozess darstellen. Die Pyramidenform ergibt sich aus der Priorisierung der einzelnen Anforderungen. Es wird vermutlich wenige besonders wichtige Anforderungen, aber sehr viele „nette“ Zusatzanforderungen geben – auf die möglicherweise sogar verzichtet werden kann ohne die Grundeigenschaften des Systems zu gefährden.
Grundsätzlich können zwei Arten von Anforderungen unterschieden werden: funktionale und nichtfunktionale Anforderungen.
Funnktionale Anforderungen legen fest, was ein System tun soll. Nichtfunktionale Anforderungen spiegeln eher Qualitätseigenschaften und Randbedingungen wieder. Solche können z.B. Zuverlässigkeit, Look & Feel, Benutzbarkeit, Leistung und Effizienz, Betrieb und Umgebungsbedingungen, Wartbarkeit, Änderbarkeit, Sicherheitsanforderungen, Korrektheit, Flexibilität oder Skalierbarkeit sein.
In der Darstellung hier, werden die nichtfunktionalen Anforderungen noch einmal gebündelt in relativ systemnahe Anforderungen, wie beispielsweise das Handling und die Benutzerführung, Sicherheitanforderungen oder Security-Requirements und sonstige nichtfunktionale Anforderungen.
Zahlen haben fast schon eine „magische“ Wirkung auf uns. Wir schenken ihnen Vertrauen und sie liefern uns exakte Aussagen.
Schön wäre es, denn im Detail liegen ein paar Tücken: Messen bzw. zeigen die Zahlen tatsächlich das, was sie vermeintlich vorgeben zu zeigen? Und mit welcher Zuverlässigkeit und Genauigkeit tun sie es?
Die Krux mathematischer Modelle und Berechnungen liegt darin, dass sie uns Ergebnisse mit Nachkommastellen liefern. Das aber ist lediglich eine Scheingenauigkeit, denn das Ergebnis kann nicht besser sein als das zugrundeliegende Modell. Wie sehr uns das überfordert, zeigt der aktuelle Umgang mit den Covid Statistiken. Von uns Laien werden Zahlen vogelwild interpretiert ohne das wir wirklich wissen, was sie aussagen, ohne das wir statistische Effekte aus Erfassung und Verarbeitung, wie z.B. durch die Änderung der Teststrategie oder das Meldeverhalten, berücksichtigen.
Wir sind in guter Gesellschaft. Seit langem bemängelt Gerd Gigerenzer (Amazon Affiliate Link), dass die meisten Mediziner, medizinische Wahrscheinlichkeitsaussagen nicht interpretieren können. Wie soll das dann bei Covid anders sein?
Oder im Risikomanagement?
Die bekannteste Quantifizierung eines Risikos ergibt sich aus der versicherungmathematischen Formel als Produkt von Eintritswahrscheinlichkeit und potentiellem Schaden, dem sogenannten Erwartungwert.
Aber welche Aussagekraft hat der Erwartungswert?
Nun statistisch gesehen, ist das der durchschnittlich zu erwartende Schaden. Aber nutzt uns das was? Das ist in etwas wie die durchschnittliche Fiebertemperatur aller Krankenhauspatienten. Nehmen wir einmal an, ein Unternehmen würde aufgrund eines solchen Modells finanzielle Rückstellungen in Höhe des Erwartungswerts treffen. Bei Risiken die digital eintreten, d.h. sie treten entweder ein oder sie treten nicht ein, stecken wir in dem Dilemma, dass wir im einen Fall zu niedrige und im anderen Fall zu hohe Rückstellungen getroffen haben. Worst case ist beides existenzbedrohend, z.B. im Falles des Eintretens eines „schwarzen Schwans“ (Amazon Affilitate Link), also eines äußerst unwahrscheinlichen Ereignisses – z.B. einer Covid-Pandemie….
Mit Facilitation als Moderationsmethode/Einstellung gelangt man zu besseren Ergebnissen in Meetings, Prozessen und Entscheidungen. Ein eigenes LinkedIn-Learning Training dazu wird im Juni aufgezeichnet und unsere Masterclass ist auch am Start.
Im Artikel geht es darum, was Facilitation überhaupt ist, sie sie funktioniert und wie der Facilitation-Prozess aussieht. Weiter geht es um die Grundlagen der Facilitation und dann um deren Anwendung im Projektmanagement, denn deren gibt es genug und im Beispiel muss dann der openPM-Canvas ran.
Aber auch etwaige Fallstricke werden thematisiert.
Facilitation bietet auch im Projektmanagement viele Chancen und Möglichkeiten.
Facilitation ist vor allem ein Rollenverständnis. Prozess und Inhalte werden entkoppelt. Konflikte werden dadurch vorwiegend auf die Sachebene verlagert. Gleichzeitig ist der Facilitator der Gralshüter für methodisch sauberes Vorgehen und Zielorientierung.
Beiträge zur Facilitation auf schlossBlog gab es schon zur Genüge:
Seit langem mal wieder ein reinrassiger Projektmanagement Beitrag. Jüngst bin ich über einen Artikel von Ron Quartel auf medium gestolpert: „Why Story Pointing Needs to Die„
Wortwörtlich ins Auge gefallen sind mir vor allem die beiden Zitate in der Illustration:
„I may have invented points. If I did, I´m sorry now.“ – Ron Jeffries
„Velocity is killing agility!“ – Jom Highsmith
Vor allem das zweite spricht mir aus der Seele. Das Konzept der Velocity wollte mir nie so recht eingehen.
Also nicht, dass ich nicht verstanden hätte, worum es dabei geht und wie es funktioniert, aber Velocity-Betrachtungen laufen meinem Verständnis von Projekten fundamental entgegen.
Projekte sind einzigartige, komplexe Herausforderungen und Velocity zielt auf die Optimierung einer gleichmäßigen und prognostizierbaren Teamauslastung. Finde den Fehler!
Klar, wenn sich ein Projekt an das andere reiht, dann können wir nicht immer auf 120% fahren. Das macht uns kaputt. Aber die Vorstellung Projektfortschritt sei ein kontinuierlicher Prozess ist schon schizophren, denn sind nicht Disruption und sprunghafte Entwicklungen gerade in komplexen Projekten zu beobachten?
Nichts gegen eine Auslastungsoptimierung. Sie sichert Effizienz. In Projekten steht aber vor der Effizienz vor allem die Effektivität. Erreichen wir überhaupt, was wir erreichen wollen?
Effizient Scheitern ist keine Option!
Ich will das Konzept Velocity gar nicht in Frage stellen. Dafür gibt es sicher Anwendungsfälle, aber eher weniger in Projekten.
Bevor ich nun wieder in die Schublade des traditionellen Projektmanagements gesteckt werde, will ich dem schon vorab widersprechen. „Gutes“ Projektmanagement hatte immer schon agile Züge, denn nur mit einer solchen Einstellung kann man komplexen Anforderungen gerecht werden. Das hat aber nur bedingt mit der Umsetzung agiler Projektmanagement-Ansätze zu tun. Die großen Stärken von beispielsweise Scrum sind für mich, die Stärkung des Teams, Facilitation (in der Rolle des Scrum Masters), die intensive Einbindung der Anforderungsseite (Product Owner) sowie die Etablierung von Lernprozessen und Kommunikation. Diese Dinge helfen aber in jeder Form des Projektmanagements weiter und erhöhen unsere Erfolgswahrscheinlichkeit. Lediglich formale Implementierungen von Scrum sind wie alle halbherzigen Projektmanagementimplementierungen zum Scheitern verurteilt.
Überbewertete Konzepte gibt es aber auch im traditionellen Projektmanagement. Mein „Lieblingsbeispiel“ hier ist der Earned Value, also die laufende Quantifizierung des Projektfortschritts. Der bereits geschaffene Wert im Projekt wird kontinuierlich ermittelt. Ich halte diesen Ansatz für gefährlich. Er suggeriert, dass tatsächlich bereits ein Wert geschaffen wurde. Der Wert eines Projektgegenstandes ist mitunter aber digital zu sehen: Das fertige Produkt funktioniert oder funktioniert nicht. Zugegeben, die Argumentation ist stark vereinfacht. Vielleicht haben wir tatsächlich etwas gelernt oder es sind brauchbare Zwischenprodukte entstanden, gemessen an unserm Projektauftrag sind wir aber gescheitert. Als Gegenpol dazu gefällt mir hingegen die Idee des „Minimum Viable Product“, die zu einer Rückbesinnung und Ergebnisorientierung führt. Mit dem MVP ist ein Projekt zwar in der Regel noch nicht am Ziel, aber das Risiko des Scheiterns wird minimiert.
Alle Earned Value-Implementierungen, die ich in der Praxis gesehen habe, dienten – böse gesagt – auch eher der Befriedigung des Management Reportings, als dem Projekterfolg.
Facilitation is something magical to make meetings, workshops, projects or processes successful. Usually blog posts here are in German so this is an exception. It is a translation of the previous post which is a summary of a small series I recently posted on Twitter and LinkedIn:
Definition: Facilitation is a form of moderation supporting a group to meet their goals in meetings, decisions, in problem solving or in processes.
