Das Projektmagazin lädt wieder zu einer Blogparade: Grenzen im Projektmanagement abbauen oder bewahren?

Für einen System Thinker stellt sich die Frage nicht wirklich, denn Systeme konstituieren sich durch ihre Grenzen. Also lohnt sich der Blick auf die Grenzen allemal. Aber welches System wollen wir betrachten? Das Projekt selbst? Den Projektgegenstand? Das Unternehmen, das ein Projekt initiiert und durchführt? Die Gesellschaft? Oder die Projektmanagement-Community?

Und schon schwimmen sie wieder die Grenzen. Je nach Wahl des Betrachtungsgegenstandes, je nachdem welches System wir betrachten rücken andere Grenzen in den Fokus.

Das Spiel mit den Grenzen ist also Bestandteil des Perspektivenwechsels und ohne Perspektivenwechsel ist in unseren komplexen Welt kaum eine Problemlösung möglich – egal ob bei der Scope-Definition für unser Projekt, bei der Wahl des Vorgehensmodells oder bei der Methodenauswahl.

Insofern ist die Antwort auf die Eingangsfrage ein sowohl als auch – und permanenter Auftrag, denn Grenzen verschieben sich. Nichts ist so stetig wie der Wandel. Wir haben nicht nur eine einmalige Betrachtung, sondern müssen auch die zeitliche Dimension im Auge behalten. Das ist vielleicht lästig, aber unvermeidlich. Es ist unser Job…

Freitag/Samstag war wieder PMCampMuc und wenn ich als „Buchhalter“ schon fast zum Orgateam gehöre, dann bin ich auch dabei, wenn´s irgendwie geht. Und natürlich hat es sich wieder gelohnt. Diesmal eher exqusit – das womöglich erste PMCamp mit Liftboy – der Location geschuldet.

Und wiedermal ein grandioses Klassentreffen mit vielen wertvollen Impulsen.

Bei Michael, unserem Keynote-Speaker, muss ich mich noch beschweren: Seine Aufgabe („Finde einen Teilnehmer, den du noch nicht kennst.“) wird zunehmend schwieriger zu erfüllen, aber diese Kritik nimmt er leichten Herzens hin, ist sie doch ein Indikator für den Erfolg und die gelungene Vernetzung.

Die Sessiondoku gibt es – wie immer – auf openPM.

Eine eigene Session habe ich auch mitgebracht: (Falsche) Selbstverständlichkeiten im Projektmanagement.

Darin gibt es nicht nur einige Hypothesen, die nachdenklich machen, sondern auch Einblick in die Resonanz auf unsere Videotrainings, sowie eine Auswertung von Publikationen im Projektmagazin.

Ich bin nicht nur mit openPM und der PMCamp-Bewegung zutieft verwachsen – beide kriegen mich auch so schnell nicht mehr los.

Und das ist auch gut so.

😉

Nach dem PMCamp ist definitiv vor dem PMCamp! Ich weiß nur noch nicht, welches mein nächstes sein wird. Karlsruhe am nächsten Wochenende schaffe ich definitiv nicht, aber dann unterstütze ich sie wenigsten und mach halt ihre Buchhaltung…

Fit werden für Integrationsaufgaben in Projekten aus Projektmanagement: Integration von Bernhard Schloß, Christian Botta und Daniel Reinold

Integrationsmanagement, ja, das ist so ein Thema, das insbesondere im PMBOK („Project Management Body of Knowledge“) des amerikanischen PMI explizit hervorgehoben wird.
Ich habe damit selbst lange „gefremdelt“, weil für mich Integrationsaufgaben so elementarer Bestandteil von Projektmanagement sind, dass ich nicht auf die Idee gekommen wäre, das als eigenes Wissensgebiet innerhalb der Disziplin anzusehen. Mit den verschiedensten Integrationsebenen und -aufgaben beschäftigt sich unser neues Training auf LinkedIn Learning. In Projekten werden wir mit den unterschiedlichsten Aufgaben konfrontiert, aber wie wird aus den vielen einzelnen Aktivitäten ein erfolgreiches Ganzes? Genau darum geht es in unserem Kurs. Wir wollen alle Teilnehmer genau dafür fit machen!

Änderungen sind unausweichlich aus Projektmanagement: Änderungsmanagement von Bernhard Schloß, Daniel Reinold und Christian Botta

Schlag auf Schlag geht es weiter mit einem neuen Training auf LinkedIn Learning – diesmal zum Thema Änderungsmanagement.
Wir beschäftigen und damit, was ein Change ist und wie wir damit umgehen. Änderungen sind im Projektalltag unausweichlich, umso wichtiger ist dieses Thema und wir unterstützen Sie dabei.

LinkedIn-Learning Time auf schlossBlog. Unser neues Projektmanagement-Training: Ethik und Compliance ist erschienen. Und was sich auf den ersten Blick theoretisch und abstrakt anhört, ist gar nicht so, denn es geht vor allem um Entscheidungs- und Handlungsgfähigkeit. Neugierig geworden? Dann würden wir uns auf einen neuen Kursteilnehmer freuen 😉

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.