Facilitation ist eine Zauberwaffe um Meetings, Workshops, Projekte oder Prozesse erfolgreich zu gestalten. In den letzten Wochen habe ich in einer kleinen Reihe auf Twitter und LinkedIn „spielerisch“ erklärt worum es geht. Hier die Zusammenfassung:
Definition:
Facilitation ist eine Moderationsform, die einer Gruppe erleichtern soll ihre Ziele in Meetings, Entscheidungen, bei der Problemlösung und in Prozessen zu erreichen.
Unser organisatorisches Umfeld ist häufig geprägt von hierarischen Strukturen, aber:
Diskussionen über Hierarchiegrenzen sind selten ergebnisoffen.
Hört sich erstmal reißerisch an. SuperBetter ist ein Buch, ein Spiel, eine App, aber in erster Linie ist SuperBetter ein smartes Framework um mit den Mitteln der Gamification jegliche Herausforderungen erfolgreich zu bewerkstelligen.
[Kurzer Exkurs – Gamification: Unter Gamification versteht man die Anwendung von Spielelementen in spielfremden Kontexten. Mehr dazu hier auf schlossBlog oder in unserem LinkedIn Learning Training.]
Aber zurück zu SuperBetter. Ist SuperBetter dann eine eierlegende Wollmilchsau, ein Patentrezept, ein Heilsversprechen?
Ja und nein. Ja, es liefert eine Blaupause und ja, es verspricht Erfolg, aber nein, nicht per TschakaTschaka, sondern über die gezielte Nutzung eines spielerischen Mindsets („Living Gamefully“) und die Anwendung von Gamification. Versprochen werden auch nicht 1.000.000,-€, sondern ein Entwicklungsprozess.
SuperBetter ist Gamification par excellence. Jane McGonigal, amerikanische Autorin, Game Designerin und Wissenschaftlerin mit einem Doktortitel aus Berkeley, zeigt uns, wie wir einige wenige Spielelemente aus einem (Arkade-)Game nehmen können und für unsere persönliche Strategie und Entwicklung nutzen können. Aber nicht als Heilsversprechen, sondern durchaus wissenschaftlich fundiert, die entsprechenden Arbeiten und Beispiele sind im Buch belegt.
Konkret geht es um die folgenden Spielelemente:
Herausforderungen/Challenges
Power-Ups (also kleinen Aufbauhilfen)
Bad Guy (unsere „inneren und äußeren Dämonen“ die es zu bekämpfen gilt)
Quests (einfache, tägliche Aktivitäten, die uns helfen unser größeren, übergeordneten Ziele zu erreichen)
Allies/Verbündeten (aus Spielen können wir Lernen, wie wir Verbündete gewinnen und ihre Unterstützung bekommen können)
Secret Identity (jetzt doch sehr verspielt und ein kleines bisschen mystisch)
Epic Wins (den Meilensteinen unseres Erfolgs)
Nutzen wir diese Elemente in einem Setting wie der App oder einem Abenteuer (einem vorkonfigurierten Set solcher Spielelemente) hilft uns das im Prozess der Zielerreichung, wobei es durchaus unterschiedliche Formen von Zielen gibt: Ganz konkrete, messbare, aber auch „Ich gebe mein Bestes“-Ziele oder strategische Ziele, die darauf zielen neue Handlungsstratgegien zu entdecken oder entwickeln.
Das Buch SuperBetter wendet die eigene Methodik dabei konsequent an, denn es selbst gespickt mit Quests für den Lesern und enthält viele Beispiele und Tipps, z.B. auch, wie man Verbündete gewinnt und wie man diesen am Besten SuperBetter erklärt, aber auch wie man selbst zu einem großartigen Helfer und Verbündenten wird.
Der Framework-Gedanke für einen solchen Gamification Ansatz gefällt mir (obwohl Jane McGonigal gar nicht von einem Framework spricht, das ist mein Wording). Ein Spiel á la Super-Mario wird zur Metapher für eine Herausforderung. Darüber hinaus stecken noch weitere nützliche Metaphern im Konzept. Wir lernen gezielt Hilfen zu erkennen und zu nutzen (Power-Ups), Hindernisse und Schwierigkeiten zu identifizieren und zu überwinden (Bad Guys), bewusst Aufgabenstellungen, die uns weiterbringen in Angriff zu nehmen (Quests), Hilfe zu suchen und zu akzeptieren (Allies), uns zu motivieren (z.B. mit unserer geheimnisvollen Secret Identity) um letztlich größere Erfolge (Epic Wins) anzustreben
Die Lektüre macht Lust auszuprobieren. Ist eben NICHT ideologisches TschakaTschaka, sondern plädiert für eine spielerische Haltung, verführt zum Ausprobieren und Lernen. Bei mir ist das entsprechende Kopf-Kino bereits gestartet.
Wir haben uns nicht nur vorgenommen auf dieser Plattform Content zum Thema Projekte und Projektmanagement zu generieren und mit der Community zu teilen (also am Besten gleich dem Projekt-Werkraum auf LinkedIn folgen), diese Reihe war auch der Versuch unser eigenes Setup und die eigene Video-Produktion zu challengen. Durch die Zusammenarbeit mit den lieben Kollegen von LinkedIn Learning sind wir verwöhnt und unsere Ansprüche sind hoch. Wir haben die Ärmel hochgekrempelt und im Werkraum erstmal losgelegt und das Ergebnis kann sich sehen lassen:
In Folge 1 geht es um die Frage: Wann ist ein Projekt erfolgreich? Es folgen Definition/Beispiele von Erfolg. Es geht erstmal um die inhaltliche Dimension von Erfolg.
Die Reihe basiert auf einem Vortrag, den ich im Juni auf den PMDays der Kayenta halten durfte (nochmal vielen lieben Dank an Werner Plewa für die Einladung!).
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.
Facilitation ist eine Zauberwaffe um Meetings, Workshops, Projekte oder Prozesse erfolgreich zu gestalten. In den letzten Wochen habe ich in einer kleinen Reihe auf Twitter und LinkedIn „spielerisch“ erklärt worum es geht. Hier die Zusammenfassung:
Definition:
Facilitation ist eine Moderationsform, die einer Gruppe erleichtern soll ihre Ziele in Meetings, Entscheidungen, bei der Problemlösung und in Prozessen zu erreichen.
Unser organisatorisches Umfeld ist häufig geprägt von hierarischen Strukturen, aber:
Diskussionen über Hierarchiegrenzen sind selten ergebnisoffen.
Was ist eigentlich Erfolg im Projekt, und was eine Krise? Mit meinem Kollegen Christian Botta suche ich in diesem Video-Training mit Ihnen nach Erfolgs- und Misserfolgsfaktoren und wir reden offen über das Scheitern von Projekten. Klassiker sind der CHAOS-Report. Wir reflektieren Projektcontrolling, Machbarkeit, Kosten-Nutzen-Analysen und Stakeholdermanagement.
Wir betrachten das Komplexitätsdilemma, scheitern als Chance, Lernen und den Umgang mit Scheitern.
Sie erfahren, wie Sie Krisen erkennen und diese meistern können. Auch die Themen Gesundheit und persönliche Krisen werden angesprochen.
In sieben Projektgeschichten erfahren Sie abschließend, wie eng Erfolg und Misserfolg in einem Projekt oft bei einander liegen und welche Nuancen über einen glücklichen oder unglücklichen Ausgang eines Projektes entscheiden können.
Die erste Konsequenz aus dieser Diskussion lautet ganz banal:
Scheitern gehört dazu. Scheitern ist ganz normal, auch wenn uns Gott und die Welt etwas anderes erzählen wollen. Die Studien von Gartner & Co haben es schon immer gesagt, aber wir wollten es einfach nicht wahr haben und haben das Stigma des Scheiterns gepflegt.
Ich würde sogar noch weiter gehen und die folgende These aufstellen:
In Projekten zeigt sich die Fähigkeit einer Organisation zur Veränderung und Selbsterneuerung.
Das Scheitern einzelner Projekte stellt lediglich die Lernkurve in einer solchen organisatorischen Entwicklung dar und ist unumgänglicher Bestandteil.
Kritisch wird es aber, wenn eine Organisation oder Gesellschaft gar nicht mehr in der Lage ist Projekte erfolgreich durchzuführen. Nicht das Scheitern ist zu verurteilen, sondern das Ignorieren des Scheiterns. Nicht das Scheitern des Euro-Hawk-Debakels ist zu verurteilen, sondern dass die Notbremse erst (geschätzt) mehr als ein Jahr nach dem Bekanntwerdens gezogen wird. Natürlich ist der Verlauf von BER desaströs, aber es hat erst den alten Haudegen Mehdorn gebraucht um triviales PM-Turnaround-Management zu starten, Know-How zu sichern, Risiken z.B. durch eine gestaffelte Inbetriebsetzung zu minimieren, fatale Terminaussagen zu kippen und jenseits eines reinen Rechtfertigungsdenkens die Projektarbeit wieder fortzusetzen.
Angesichts des heutigen Umgangs mit Großprojekten stellt sich berechtigt die Frage, wie weit die bundesdeutsche Gesellschaft noch diese Fähigkeit zur Veränderung und Selbsterneuerung besitzt.
Ein weiterer wichtiger Impuls aus dieser Sicht auf das Scheitern von Projekten ergibt sich für die Business Case-Betrachtung: Wie weit macht die heute übliche Praxis Business Cases für Projekte zu berechnen noch Sinn? Wenn wir die hohe Quote des Scheiterns berücksichtigen, ist nahezu jede Business Case-Betrachtung, die wir kennen vollkommen utopisch. Ich habe auch kein Patentrezept hierfür, aber wir brauchen diese Selbsterkenntnis, wenn wir uns mit den entsprechenden Modellrechnungen beschäftigen.
Der im voranstehenden Beitrag zitierte Gunter Dueck beziffert die Erfolgswahrscheinlichkeit von Innovationsprojekten bei 5% und unter optimalen Umständen, wenn entsprechende Investoren mit den erforderlichen Managementfähigkeiten vorhanden sind auf 11%. Venture Capitalists berücksichtigen solche Zahlen in ihren Kalkulationen, d.h. sie gehen davon aus, dass von 10 Investitionen vielleicht nur eine fliegt, aber diese muss dann auch die Kosten der anderen decken. Übertragen auf das ganz normale Projektmanagement in Organisationen, heißt dass, dass der Business Case sich eben nur über alle Projekte und i.d.R. nicht für ein einzelnes Projekt rechnet, aber wie lösen wir die Wirtschaftlichkeitsbetrachtung vom einzelnen Projekt und heben sie auf die Ebene des Portfolios?
Bleiben wir noch einen Augenblick bei Dueck und dem Thema Management-Fähigkeit: Dueck rechnet gnadenlos mit den Alibi-Management-Funktionen in (zumeist Großunternehmen) ab. Und fordert eine Abkehr von einem solchen Management. Sein Antwort-Ansatz geht Richtung agilem (Projekt-)Management. Diese Sicht teile ich nur mit Einschränkungen. Ich sehe durchaus weiterhin eine Berechtigung von klassischen PM-Ansätzen (neben agilen Methoden), sofern sie sich von den von Dueck zu Recht kritisierten Management-Attitüden verabschieden. Weshalb ich agile Ansätze nicht für die alleinige Lösungsmöglichkeit halte liegt zum Einen daran, dass auch agile Methoden eigene Attitüden mitbringen (können) und zum anderen, dass sich nicht jedes Problem in die im Agilen beschriebenen Scheiben schneiden lässt – es gibt auch Elefanten, die tot sind, wenn man sie in Scheiben schneidet.
Für den von Dueck kritisierten Management-Begriff sollten wir auch im PM keinen Platz mehr lassen. Die Lösung würde ich aber nicht rein im Agilen suchen, sondern in einem anderen Buch Duecks: Professionelle Intelligenz(Amazon Affiliate Link) könnte der Schlüssel sein. Wir brauchen eine Professionalisierung und gesunden Menschenverstand statt eines Rechtfertigungsmanagements um Veränderungsprozesse zu bewerkstelligen und auch um vielleicht in dem einen oder anderen Projekt mehr erfolgreich zu sein.
Viele Projekte sind ggf. nur Teilschritte eines größeren Veränderungsvorgangs (vgl. Portfoliomanagement). Möglicherweise ist in einer Sequenz von Projekten ein scheinbarer Misserfolg nötig, ggf. sind die Misserfolge nur Lernschritte auf einem größeren Weg auf dem das konkrete Projekt nur einen Teilschritt darstellt.
Die Beurteilung des Projekterfolgs erfolgt also nicht mehr auf der Ebene des einzelnen Projekts (Projektauftrag, Stakeholdererwartung, etc.), sondern im Kontext des organisatorischen Anpassungs- und Erneuerungsprozesses.
Das Scheitern vieler Projekte vor dem Hintergrund innovativer Prozesse scheint normal. Scheitern heißt lernen. Interessant scheint die Implikation auf die Business Case Betrachtung. Sind hart gerechnete Business Cases vor dem Hintergrund der hohen Rate gescheiterter Projekte überhaupt sinnvoll?
Aber trotzdem brauchen Organisationen Projekte um ihre Fähigkeit zur Selbsterneuerung und Erhaltung zu beweisen.
Wir stehen erst am Anfang einer spannenden Diskussion!
Nachdem hier schon des öfteren vom Scheitern von Projekten die Rede war, wollen wir uns diesmal positiv der Sache annähern. Den Anfang macht Judith Andresens Präsentation auf Slideshare, die sich zentral mit Projektkultur als Erfolgsfaktor auseinandersetzt. Das erinnert mich an ein lange zurückliegendes Projekt in dem ich eine zentrale Projektdatei mit dem Kennwort „Projektkultur“ geschützt habe – ich war mir sicher, dass niemand im Projekt dieses Passwort knacken würde.