Communities ticken anders. Entsprechend funktionieren Community-Projekte auch anders als andere Projekte. Was Communities anders macht ist das Prinzip der „Freiwilligkeit„. Egal ob es um Open Source Software-Entwicklung geht oder um ein Entwicklungshilfeprojekt eines NGOs, wenn die Akteure auf freiwilliger Basis an Bord sind, stellt das viele Spielregeln auf den Kopf.

Eine liebe Freundin trieb mich einst beinahe in den Wahnsinn, weil für sie vor der Arbeit noch das Tee-Kochen und ein freundlicher Plausch wichtig waren, während ich erst einmal (auch im Ehrenamt) die Arbeit schaffen wollte, um dann in aller Ruhe mit ihr und den anderen noch weiter „abzuhängen“. Die Lektion, die ich damals lernen musste, ist, dass man bei „Freiwilligkeit“ nichts einklagen kann und wir die Eigenheiten der anderen weit mehr akzeptieren müssen, als wir im (Berufs-)Alltag bereit wären, das zu tun. Letztlich müssen wir froh sein, egal ob im Sportverein, im Sozialen oder wo auch immer, wenn sich jemand engagiert und die Grenzen der Kritikfähigkeit verlaufen einfach anders bei Volunteers.

Um Communites besser zu verstehen bin ich vor einer Weile über ein schönes Werkzeug gestolpert. Wie könnte es auch anders sein: Es ist ein Canvas – Der Community-Canvas.

Mit seinen Feldern bietet der Canvas bereits eine Tiefenstruktur zur Analyse einer Community. Im ersten Schritt reicht vielleicht schon die Grobstruktur (gekennzeichnet durch die Farben): Identity (blau) – Expierience (rot) – Structure (grün).

Wenden wir dieses Werkzeug exemplarisch auf 3 Beispiele an:

openPM ist zum Einen ein Projektmanagement-Wiki, aber auch Bestandteil einer verbandsunabhängigen Projektmanagement-Community, die sich im Rahmen der PM-Camp-Bewegung gefunden hat. Hinter openPM steckt ein gemeinnütziger Trägerverein, der mittlerweile nicht nur das Wiki betreibt, sondern bei einigen PM-Camps auch als Veranstalter auftritt (München, Stuttgart, Karlsruhe) und auch die PM-Camp-Internet-Domain verwaltet. Bei all meinem persönlichen Enthusiasmus für openPM, legt der Canvas gleich den Finger in die Wunden dieser Community: Bei Identity und Structure können wir einen Haken setzen, hier ist die Aufstellung vorbildlich. Kritisch wird es in einzelnen Expierience Feldern. Dem Wiki mangelt es teilweise an Inhalt (Content). Offenbar werden die Erfahrungen (Shared Expierience) nicht in dem Umfang geteilt wie erhofft. Einen möglichen Ansatzpunkt liefert der Canvas gleich mit: Die Etablierung von Ritualen. Das könnte im Konkreten ein noch weitergehendes Engagement in der PM-Camp-Bewegung und auf PM-Camps sein, aber vielleicht auch die Etablierung weiterer Austausch- und Diskussionsformate.

Beispiel 2 hatten wir bereits eingangs erwähnt: Freiwilligen-Arbeit mangelt es mitunter an Effizienz, die sich auch nicht „einklagen“ lässt. Im Canvas bewegen wir uns auch hier in den Expierience Feldern. Einen Lösungsansatz könnten Rules, Rituals und Roles bieten.

Sind Communities grundsätzlich im gemeinnützigen Bereich angesiedelt? Nein, es gibt auch andere Beispiele, die aber ebenfalls unter den Restriktionen der „Freiwilligkeit“ leiden – man denke nur an Barcamps und Open Space-Veranstaltungen, Supervision oder WOL-Circle. Aber auch firmenintern lassen sich Beispiele finden, wie unser Beispiel 3: Eine Community von IT-Experten einer bestimmten Software in einem Konzern. Gemeinsam helfen sich die Kollegen mit Know How und Tools aus. Die Gemeinschaft wächst schnell und ihr Aktivitätsradius nimmt zu, weil alle profitieren, allerdings bleibt die Community informell, womit sich selbst zugesagte Leistungen kaum einfordern lassen. Bei Gemeinschaftsprojekten knirscht es. Möglicherweise stehen einzelne IT-Abteilungen auch im Konkurrenzkampf: Abteilung A könnte System und Aufgaben von Abteilung B übernehmen). Defizite liegen zum Einen im Bereich Structure (Organization, Governance und Financing), aber auch beim Miteinander (Shared Expieriences) fehlt es an Rules und Roles.

Die 3 Beispiele zeigen bereits eindrucksvoll Stärken des Canvas. Allerdings sehe ich auch ein strukturelles Defizit: Der Canvas unterstellt eine Homogenität der Teilnehmer der Community. Heterogenität (z.B. rivalisierende Positionen) lassen sich schwer im Schema verankern. Das könnte z.B. durch eine begleitende Stakeholder-Analyse kompensiert werden. Aber nichtsdestotrotz: das ist Kritik/Jammern auf hohem Niveau. Der Community Canvas stellt eine hervorragende Bereicherung in der Auseinandersetzung mit Communities und Community Projekten dar.

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.

Sascha Demarmels, Agilität & Kommunikation – Agile Kommunikation und Kommunikation im agilen Kontext, Baden-Baden, Zürich 2018

Ein kleines aber feines Buch von Sascha Demarmels thematisiert Kommunikation im agilen Kontext. Zweifelsohne spielt Kommunikation in jeder Form des Projektmanagements eine entscheidende Rolle, aber die Autorin bringt es in Bezug auf Agilität auf den Punkt: Agilität baut auf Selbstorganisation „…und ist daher noch fundamentaler auf die Verständigung zwischen den Mitarbeitenden angewiesen.“
Das Buch ist in der Reihe VERSUS kompakt erschienen und folgt dem Aufbau der Reihe: Zunächst knapp 60 Seiten mit allem Wesentlichen zum Thema, dann ein A-Z von Methoden, Modellen und Instrumenten und schließlich ein Praxisteil mit Beispielen.
Auf letzteren hätte ich gerne verzichten können, denn solche Success-Stories haben gerne einen faden Beigeschmack, weil sich doch jeder im besten Licht präsentieren will und wenn dann eine Beitragende gleich ihre eigene Masterarbeit zitiert, dann wird das unfreiwillig komisch. Dem Gesamteindruck macht dies aber keinen Abbruch (und die Kritik ist sicherlich auch Geschmackssache).
Wer in das Thema Kommunikation näher einsteigen will – egal wie groß oder klein Agilität im eigenen Umfeld geschrieben wird – dem kann ich dieses Buch gerne empfehlen. Der eine oder andere Leser wird erstaunt sein wie wenig explizit agile Methoden dabei eine Rolle spielen. Natürlich tauchen User Stories, Time-Boxes und Poker auf, aber eben auch grundsätzliche Themen wie die 4-Seiten-einer-Nachricht von Schulz von Thun, Feedback und Gesprächsführung. Agilität hat Kommunikation nicht neu erfunden, ist aber ganz besonders auf sie angewiesen.
Das Buch ist als Einstieg und als Nachschlagewerk geeignet. wer schon tiefer im Thema steckt, wir wenig Überraschendes finden, aber das ist ja auch kein Manko, dem eigenen Anspruch eine kompakte Übersicht zu geben wird es vollstens gerecht. Die Gestaltung ist ansprechend mit einer ganze Reihe eingestreuter Sketchnotes und farbigen Übersichten in den Innenseiten des Buchcovers.

Aktuell bereite ich neue LinkedIn-Learning Kurse vor. In diesem Zusammenhang entstand ein Template für einen Change Request.

Das Musterdokument steht auf openPM jedem zur Verfügung.

Änderungsanträge/Change Requests oder Requests for Change gehören zum Projektalltag. Selten sind die initialen Anforderungen vollständig oder fehlerlos. Mit einem Änderungsantrag wird formal eine entsprechende Änderung an Anforderungen und Scope eingebracht. Der Formalismus soll für Transparenz sorgen und auch eine möglichst vollständige Bewertung der Auswirkungen (Impact) ermöglichen.

Auch wenn ein solcher Änderungsantrag mit seinem Formalismus eher einem klassischen Projektmanagement entspricht, so stellen sich auch im Agilen die dahinter stehenden Fragen immer wieder aufs Neue, nämlich jedes mal, wenn eine konkrete Anforderung in die Realisierung geht.

Wer sich für das neue Jahr vorgenommen hat, sich in Sachen Projektmanagement weiterzubilden, dem sei unsere LinkedIn Learning Reihe ans Herz gelegt.

Mein Co-Autor Christian und ich haben einen kompletten Lernpfad entwickelt und einzelne ergänzende Trainings kommen noch dazu.

Wer einen LinkedIn-Premium Account hat, kann die Kurse kostenlos absolvieren. Alle Texte sind transkribiert und es gibt auch noch Begleitmaterial.

Neugierig geworden?

Wir haben einen Flyer mit ausführlicher Kursbeschreibung für euch erstellt.

Und hier geht es zum vollständigen Kurs: https://www.linkedin.com/learning/paths/ihr-weg-zum-projektmanager

Klassich. Agil. ist ein kleiner Projektmanagement-Krimi der in 6 Folgen für den schlossBlog entstand. Für alle, die den Krimi in 2018 verpasst haben…

Alle Folgen gibt es hier:

Intro: Klassisch. Agil. – Ein Projektmanagement-Krimi
Teil 1: Ein Workshop in den Bergen
Teil 2: Ein Toter
Teil 3: Antipoden Klassisch. Agil.
Teil 4: Das Bargespräch
Teil 5: Dekonstruktion
Teil 6: Frühstück

Viel Spaß beim Lesen!

In der aktuellen Folge geht es um den openPM-Canvas.

Diese Woche in unserer Reihe zur Business Visualisierung auf LinkedIn Learning: Der #openPM #Canvas. Nur diese Woche frei und dann für die Premmium-Abonnenten von LinkedIn. #PMDE https://t.co/oFRuBimpQX

— Bernhard Schloß (@schlossblog) 13. Dezember 2018

Zur Canvas-Seite auf openPM (u.a. mit dem Template in verschiedenen Formaten und viel mehr Informationen) geht es hier. 

Unsere Reihe erscheint wöchentlich auf LinkedIn Learning. Die aktuelle Folge ist frei im Internet verfügbar. Archivzugriff ist den Abonnenten von LinkedIn Learning vorbehalten.

Eine Übersicht über Methoden, Techniken und Werkzeuge im Projektmanagement-Kontext. Eine einzigartige Übersichtsliste und Linksammlung. Und jeder ist eingeladen die Liste weiter zu pflegen. Von der Abnahme, über die ABC-Analyse, Canvas, Earned Value,  Kanban, Lessons Learned, Meilensteintrendanalysee, Offene Punkte Liste, Persona, Quality Gates, Risikoanalyse, Stakeholdermanagement, World Cafe und Zukunftsbaum.

Da sage nochmal einer, der schlossBlog sei kein Methodenfuzzy.

Und für alle, die sich für visuelle Methoden interessieren, sei unser Buch „Business Visualisierung“ wärmstens empfohlen.

Agil, klassisch, hybrid – was ich von diesen Unterscheidungen halte habe ich schon hinreichend kundgetan z.B. in meiner kleinen Polemik „Warum hybrides Projektmanagement Bullshit ist„. 

Ich halte die Frage nach den PM-Schulen für grundlegend irreführend. Es gibt nur ein Projektmanagement. Statt ideologischer Grundsatzdiskussionen braucht es eine differenzierte Betrachtung. Vielmehr als auf das Etikett kommt es darauf an, was dahinter steckt, um erfolgreich zu sein braucht ein Projektmanagement vor allem drei Dinge:

These 1: Die Auftragsklärung und die Auseinandersetzung mit den Prämissen für Planung und Steuerung sind elementar.

Was sich zunächst trivial anhört, wird in der Praxis schnell oberflächlich übergangen. Der Projektauftrag, die Aufgabe ist meist weniger eindeutig und klar als es zunächst anmutet und wer sich nicht von Anfang an damit auseinandersetzt erlebt oft ein böses Erwachen.

Hinter den Prämissen für Planung und Steuerung verbergen sich eigentlich ganz einfache Fragen: wer plant wann, was, in welcher Tiefe, mit welchem Zeithorizont mit welcher Verbindlichkeit und welchem Vorgehensmodell. Was zunächst für die Planung gilt, lässt sich auch generell auf die Organisation im Projekt übertragen: zentrale oder dezentrale Steuerung (Selbstorganisation ist hier ein Zauberwort).

Die PM-Schulen liefern uns eine (unlautere) Abkürzung bei der Beantwortung dieser Fragen. Zum jeweiligen Zeitpunkt und im jeweiligen Kontext müssen wir uns diesen Fragen immer wieder aufs Neue stellen und ja, es kann durchaus sinnvoll sein diese Fragen mitunter unterschiedlich zu beantworten.

Warum dies so ist habe ich auf dem PMCamp München versucht mit einer Life Cycle Betrachtung zu erklären.

Selbst in einem so klassisch geprägten Umfeld wie dem Bauprojektmanagement haben wir Spielraum bei der Beantwortung dieser Fragen. Auch wenn die Projektplanung zunächst klassisch startet, gibt es innerhalb der einzelnen Gewerke sicher agilen Spielraum, bei unvorhergehenen Ereignissen auf der Baustelle oder auch später bei Betrieb und Unterhalt eines Bauwerks.

Wir haben Abhängigkeiten und Vorgaben, seien es Firmenvorgaben oder Industriestandards, amtliche Zulassungsverfahren oder eine Baugenehmigung, die uns in ein sequentielles Korsett zwingen – ob wir wollen oder nicht (ich hatte hierzu mal eine interessante Diskussion mit einem Software-Entwickler aus der Automobilindustrie, aber da gibt es noch viel mehr Branchen angefangen von Pharmazie, Medizintechnik, Luft- und Raumfahrt, ….).

Wenn wir uns im konkreten Kontext mit diesen Fragen auseinandersetzen, werden einige Schalter bereits gesetzt sein, ob wir wollen oder nicht. Vielleicht ergibt sich dann etwas wie ein hybrides Bild, aber ich würde es nicht so nennen wollen, weil es sich nicht um ein Cherry-Picking sondern um eine differenzierte Ausarbeitung handelt.

These 2: Jedes Projekt braucht Agilität.

…aber nicht jedes Projekt braucht agiles Projektmanagement. Diesen Satz habe ich Drings im PM-Krimi (Teil 1, 2, 3, 4, 5, 6) sagen lassen und er entspricht meiner Überzeugung. Agilität ist eine notwendige Eigenschaft im Umgang mit Unvorhergesehenem. Und egal ob uns die Komplexität oder das Chaos mit Ungewissheit konfrontieren: in Projekten müssen wir immer damit rechnen, dass sich Anforderungen oder Voraussetzungen ändern oder Unvorhergesehenes eintritt, ja vielleicht sogar unser Projekt von einem Moment zum anderen obsolet wird, obwohl wir gar nichts falsche gemacht haben. Auch in diesem Bereich gibt es ein paar Zauberwörter, wie Resilienz, Fehlerkultur, Changemanagement und…und…und….

These 3: Mindset, Kommunikation und Transparenz sind die wesentlichen Erfolgsfaktoren in Projekten.

Dem agilen Projektmanagement liegt ein Mindset zugrunde, dass im agilen Manifest zum Ausdruck kommt. 

Ein solches oder ein vergleichbares Mindset tut jedem Projekt gut, egal mit welchem Vorgehensmodell und Prämissen gearbeitet wird. Letztlich ist es lediglich Ausdruck eines gesunden Menschenverstandes. Es ist Grundlage für eine „Projektkultur“.

Warum braucht es eine solche Projektkultur? Nun, eine gemeinsame Haltung, zumindest als kleinster gemeinsamer Nenner bildet die Basis für ein Team. Um im Team erfolgreich zu arbeiten braucht es neben dieser Basis die Etablierung von Kommunikation, die letztlich Transparenz zu Vorgehen und Projektgegenstand schafft.

Agile Vorgehensweisen haben eine ganze Reihe von Kommunikationsritualen und Prozessen etabliert, aber gerade bei der Skalierung oder der Implementierung in einem Umfeld ohne entsprechendes Mindset entstehen dann agile „Zombie-Projekte“.

Es gibt aber noch einen weiteren Grund für ein solches Mindset und die Werte von Teamarbeit – nein, das hat nichts damit zu tun, dass ich ein naiver Gutmensch bin: wir sind in Projekten i.d.R. auf eine gewisse Freiwilligkeit und Motivation aller Beteiligten angewiesen. Das Zusammenspiel von Linie und Projekt ist beileibe nicht so selbstverständlich und reibungsfrei wie es sein sollte. Auch die Zusammenarbeit im Team ist keine Selbstverständlichkeit. Die Befristung von Projekten stellt viele Beteiligte vor eine persönliche Herausforderung. Interessenskonflikte sind vorprogrammiert.

Kein Patentrezept!

Diese drei Thesen liefern leider kein Patentrezept, sondern zwingen uns uns auf den eigenen Hosenboden zusetzen, die Ärmel hochzukrempeln und uns mit unserem Projekt und unserer Umwelt auseinander zusetzen. Wie immer gibt es keine einfachen Antworten, sondern wir brauchen eine differenzierte Betrachtung. Vielleicht ist diese differenzierte Betrachtung das, was der eine oder andere unter hybriden Projektmanagement versteht. Wenn diese Differenzierung nicht erfolgt, dann sind wir ganz schnell beim Zusammenpanschen von Tütensuppen und so praktisch Tütensuppen (und einfache Antworten) auch sein mögen, auf Dauer vergeht mir da der Appetit und ich glaube nicht, dass auf dieser Basis erfolgreiche Projektarbeit nachhaltig möglich ist. Küchen-Sterne sind damit auf jeden Fall nicht zu gewinnen.

Wer mich kennt, weiß, dass ich für openPM und die PMCamp-Bewegung unterwegs bin.

Zwei nette Purschen erzählen ein bisschen über #OpenPM #Opas #PMCampmuc pic.twitter.com/PXnDLIXYVh

— Visual Braindump (@VisualBraindump) 30. Juni 2017

Und jede Menge Inhalte gibt es natürlich auch:

• Interessante Artikel, z.B.:
  • Stakeholderanalyse
  • SWOT-Analyse
  • Risikosystematik
  • …
• PMCamp-Dokumentationen
• Listen:
  • Meta-Glossar der Projektmanagement-Begriffe mit Links zu vielen anderen Quellen
  • PM-Literatur
  • Methoden

Und vieles mehr.

openPM e.V. ist mittlerweile auch Träger dreier PMCamps (Karlsruhe, Stuttgart und München).

Nutzen kann openPM jeder, auch ohne Anmeldung. Wer aktiv beitragen will, muss sich allerdings registrieren. Wer uns finanziell unterstützen will, wird entweder Mitglied oder spendet an den gemeinnützig anerkannten e.V.  (es gibt natürlich eine Spendenquittung für das Finanzamt).

Wer zur Weiterentwicklung von e.V. und/oder Plattform beitragen will, meldet sich am besten unter info@openpm.info. Mitstreiter sind immer herzlich willkommen!