Archiv der Kategorie ‘Projektmanagement‘

 
 

Projektmanagement-Trainings auf LinkedIn Learning

Wie hier schon das eine oder andere mal zu lesen war sind in den letzten gut 1 1/2 Jahren eine ganze Reihe von Projektmanagement-Trainings für die LinkedIn Learning Plattform entstanden.

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

Dies ist Beitrag #741 auf schlossBlog.

Projektleiter 2030: Taschenspielertricks & Etikettenschwindel

Das Projektmagazin fragt in seiner aktuellen Blogparade, ob im Jahr 2030 de Projektleiterrolle längst abgeschafft ist oder ob sie sogar zu Schaltzentrale der digitalen (Projekt-)Welt mutiert.

Den zweiten Teil der Frage ignoriere ich geflissentlich, die ganze Digitalisierungsdebatte langweilt mich. Ich halte sie schlicht für überbewertet. Nicht dass ich disruptive Entwicklungen verleugnen will – ganz im Gegenteil – aber dieses Digitalisierungsetikett passt nicht. Wer erfolgreich sein will muss sich stets mit Veränderungen auseinandersetzen, egal ob analog oder digital. Gerade in Projekten ist das selbstverständlich. Das Schlagwort lautet schöpferische Zerstörung und entstammt nicht der Digitalisierungsdebatte, sondern kommt von einem gewissen Herrn Schumpeter, Ökonom, Anfang des 20. Jahrhunderts. An Digitalisierung war da noch nicht zu denken und der Umgang mit (Ver-)Änderungen war schon immer elementar im Projektgeschäft.

Schwenk zurück – zur Rolle des Projektleiters. Allein der Begriff scheint antiquiert. In Scrum gibt es ihn gar nicht. Ist er deswegen überholt?

Ich möchte hier unterscheiden zwischen Funktion & Aufgaben einerseits und der formalen Rolle des Projektleiters andererseits.

Funktion & Aufgaben wird es immer geben. Selbst in Scrum, dort sind sie nur anders verteilt und werden mit einem anderen Selbstverständnis gelebt.

Spannend ist hingegen die Frage nach der formalen Projektleiterrolle. Haben nicht einst findige HR-Spezialisten die Projektkarriere als Alternative zu Linienkarriere erfunden? Ein schöner Job-Titel für die Visitenkarte. Aber wenn Unternehmen zunehmend agiler werden (und das beschränkt sich nicht nur auf das Projektmanagement), dann bröckelt dieses fragile Konstrukt. Aber keine Angst auch in vermeintlich agilen Umfeldern findet der Bedarf nach solchen Etiketten immer wieder Einzug. Die Agilität erweist sich all zu oft als Pseudo-Agilität. Und einher damit geht eine Aufweichung solcher Rollenbegriffe und eine Inflation neuer Begriffe wird kommen, die sind nämlich nicht geschützt und verleihen einen Hauch von Innovatvität. Dabei sind die neuen Begriffe und Rollen für sich so innovativ wie neue Schläuche und die eigentlich interessante Frage wäre die nach dem Wein in den Schläuchen.

Aber Details… Alles Lug und Trug. Taschenspielertricks und Etikettenschwindel.

Ich bin mir sicher auch 2030 wird es noch Projektleiter geben, ich bin mir nur nicht sicher, ob ich dann gerne hätte, dass man mir dieses Etikett anheftet.

 

Dies ist Beitrag #738 auf schlossBlog und mein Beitrag zur Blogparade des Projektmagazins: Projektleiter 2030

Agiles Projektmanagement

Auf LinkedIn-Learning ist gerade unser neues Video-Training „Agiles Projektmanagement“ erschienen. Eine kleine Schnupperprobe gibt es hier:

Was heißt eigentlich agil? aus Agiles Projektmanagement von Christian Botta und Bernhard Schloß

Das Training ist in sich völlig eigenständig, aber als Ergänzung zu unserer 12-teiligen Projektmanagement-Reihe gedacht. In der hatten wir zwar auch agile Themen behandelt, aber den Bogen noch weiter gespannt. Hier wollen Christian und ich den Fokus auf Agilität legen, auf die Ideen und Konzepte, auf Scrum als Platzhirsch unter den agilen Frameworks, auf Werkzeuge agilen Vorgehens, aber auch einen Ausblick geben auf agile Konzepte, die noch weit über das Projektmanagement hinaus gehen.

Best of… Erklärvideo zum openPM Canvas

Nachdem ich den openPM-Canvas initiiert und mitentwickelt habe, habe ich mich nun an einem Erklärvideo für den Canvas versucht.

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.

Der openPM-Canvas steht unter Creative Commons-Lizenz jedem zur Nutzung/Weiterentwicklung auf openPM zur Verfügung: https://www.openpm.info/display/openPM/Canvas

Dieser Beitrag erschien ursprünglich hier.

Konzernkommunikation & Agilität

Konzernkommunikation über Agilität hat mitunter eine unfreiwillig komische Note:

„Die Unit XYZ bekommt ein agiles Mindset“

Autsch, man bekommt also ein Mindset verordnet, dabei hat man das oder entwickelt es, aber per order di mufti.

Stirnrunzeln.

Ebenfalls sehr beliebt: euphorische Begeisterungselogen.

Hallo Kollegen, vielleicht mal eine Retrospektive in den eigenen Reihen gefällig?

Agilität ist gut, aber kein Wundermittel. Und so ein unkritischer, verkäuferischer Umgang mit ihr schadet der Sache mehr als dass es ihr dient.

BER evakuiert!

Was für eine Überraschung: Schaue gerade Folge 11 der fünften Statffel Homeland auf Amazon Prime und da wird der BER evakuiert. Habe anscheinend irgendetwas verpasst. Da sind Hollywood und der Dschihad schneller als das Projektmanagement…

Vielfalt statt Beliebigkeit

Wir dürfen Vielfalt nicht mit Beliebigkeit verwechseln. Meinungs- und Methodenvielfalt sind eine Bereicherung. Beliebigkeit nicht.

Wie weit müssen wir vor dieser Frage agiles und klassisches Projektmanagement voneinander abgrenzen?

Agiles Projektmanagement ist ein scharfes, effektives Werkzeug im Umgang mit nicht oder nur schwer planbaren Zusammenhängen – im Umgang mit Unsicherheit, aber wenn wir es ohne Sinn und Verstand einsetzen ist es auch nur ein beliebiges Tool und führt zu einer Beliebigkeit der Ergebnisse.

Klassisches Projektmanagement ist hingegen stark von einer initialen Planung getrieben.

Ich durfte jüngst Zeuge einer agilen Planung werden: Das 1-Personen Entwicklerteam haben wir anhand der Anforderungen aus einem Feinkonzept in einem GANTT-Chart geplant – das war noch nicht einmal falsch, aber warum musste das Etikett agil daran kleben?

Es gibt Spezialisierung, Sachzwänge und sequentielle Abhängigkeiten.

Ein lieber Kollege wollte einmal einen agilen Versuchsballon starten und einen Proof of Concept agil durchziehen. Im Konzernumfeld war leider eine exakte Aufgabenteilung vorgegeben – vordefinierte Silos: Infrastruktur, Application Management, …

Wenn es obendrein technische Abhängigkeiten gibt wird man nicht um eine sequentielle Planung herum kommen. Da hilft kein Sprint. Da bleibt vielleicht ein Timeboxing, aber das kann keine sequentiellen Abhängigkeiten aushebeln.

Ich habe sequentielle Planungen gesehen, die sehr gut funktioniert haben: Beim Go-Live von Großprojekten. Zu einem Zeitpunkt, wo die wirklichen Probleme längst gelöst waren – und zwar agil (auch wenn das keiner so genannt hat). Da wurden dann Abhängigkeiten konsequent ausgearbeitet, berücksichtigt und akribisch umgesetzt. Ohne Akzeptanzprobleme.

Mein lieber Kollege Thomas Mathoi würde jetzt darauf verweisen, dass es z.B. im Baumanagement Sachzwänge gibt, die uns zu einer sequentiellen Planung zwingen, wie die Abstimmung verschiedener Gewerke.  Da hat er natürlich Recht – die Frage ist nur: auf welcher Planungesebene? Natürlich muss die Mauer erst stehen, bevor sie verputzt wird und dann der Maler anrückt. Aber muss ich planen ob der Maler rechts oben oder links unten anfängt? In welchem Maß müssen die Gewerke im Vorfeld geplant werden oder können von den Handwerkern auf einer Baustellenbesprechung eigenverantwortlich modifiziert werden. Kein Maler käme auf die Idee eine noch nicht vorhandene Mauer streichen zu wollen… Und wenn die Dinge aus dem Ruder laufen, z.B. weil eine Wasserleitung angebohrt wurde oder Material nicht rechtzeitig eintrifft, kann improvisiert werden – und das ist gut so.

Die Methodenwahl: klassisch oder agil sollte also bewusst und kontextspezifisch erfolgen und nicht beliebig.

Die Frage, welches Vorgehensmodell momentan in unserem Kontext am sinnvollsten ist, kann man versuchen mit dem Stacey-Matrix bzw. dem Cynefin-Modell (auf dem die Stacey-Matrix aufsetzt) zu beantworten.

Die beiden Modelle erlauben uns in einer ersten Annäherung zu erkennen, wann welche Vorgehensweise sinnvoll ist.

Das Cynefin-Modell unterscheidet 4 Domänen:

  • einfach
  • kompliziert
  • komplex
  • chaotisch

Bei einfach und kompliziert können wir klassisch planen, bei komplex agil, denn wir wissen nicht wirklich, was die Konsequenzen unseres Handeln sind. Im Chaotischen versuchen wir zunächst mit agilen Strategien Land zu gewinnen um ins Komplexe oder Komplizierte zu gelangen.

Aus diesen Modellen können wir also sogar Handlungsstrategien ableiten.

Das führt uns zurück zu unserer Ausgangsfrage nach Vielfalt und Beliebigkeit.

Ich kann mich nicht losgelöst vom konkreten Kontext für klassisch oder agil entscheiden und nicht losgelöst von der Domäne in der ich mich gerade befinde.

Ich plädiere also für ein bewusstes sowohl als auch. Nicht für Beliebigkeit. Und nicht für eine willkürliche Vermischung.

Zwar können wir einzelne PM-Werkzeuge hybrid einsetzen, nicht aber unseren PM-Ansatz, denn hinter klassisch und agil verbergen sich grundlegende Annahmen, die mit dem Cynefin-Modell verknüpft sind (und die agilen Werte möchte ich dabei sogar noch außen vor lassen):

  • Annahmen bzgl. Planbarkeit und Änderungen
  • Annahmen bzgl. Planungstiefe und Planungshorizont
  • gezielte zentrale vs. dezentrale Planung & Steuerung
  • Strategien zum Umgang mit Unsicherheit

Je nach Domäne in der wir uns zu einem Zeitpunkt X befinden, können sich diese Annahmen auch verändern.

Gewusst wo und wofür. Das ist die Frage. Und dann konsequent umgesetzt.

Ein erstes Modell ist vielleicht einfach, die Verfeinerung ist schon kompliziert und erfordert eine detaillierte Planung und Umsetzung. Passiert dann Unerwartetes, müssen wir agil reagieren (und darauf sollten wir vorbereitet sein, weil normalerweise immer auch etwas Unerwartetes passieren kann).

Unter Umständen braucht auch agiles Vorgehen Orientierung an komplizierten Modellen, wenn wir nichts besseres greifbar haben. Auf dieser Basis planen wir Produkt oder Release, aber nicht die einzelne Iteration und natürlich hat eine Iterationsplanung wiederum eine Rückwirkung auf Release und Produkt.

Die Wahl unseres Vorgehens ist also abhängig von Kontext und Situation – und nicht von Ideologien.

Lasst uns unnötige Grabenkämpfe im Projektmanagement beerdigen und uns auf konkrete Problemstellungen konzentrieren.

In diesem Sinn ist Vielfalt befruchtend, aber Beliebigkeit bringt uns nicht weiter. Wir müssen bewusst über unsere Prämissen entscheiden. Und das kontextspezifisch.

 

Der Post #732 auf schlossBlog ist mein Beitrag zur Blogparade des PM-Camp Berlins 2017.

Dieser Post wurde insbesondere angeregt von einigen Diskussionen auf dem PM-Camp MUC. Versuchen wir doch den PM-Camp übergreifenden Brückenschlag.

PMCampMUC – Sessiondokus

Auf dem PMCampMUC habe ich dieses Jahr zwei Session initiiert:

 

Die Anforderungspyramide

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.
 

Bürgerbeteiligung & Stakeholderanalyse

Im Eifer des Gefechts meiner aktuellen Projekte wäre beinahe eine Buchveröffentlichung untergegangen:

Für den ersten Band „Beteiligungsprozesse erfolgreich planen“ der Reihe „Methodenhandbuch Bürgerbeteiligung“ durfte ich einen ausführlichen Artikel zur Stakeholderanalyse beitragen. Die Interpretation von Projekten (und ihrem Umfeld) als soziale Systeme lassen sich natürlich auch auf den öffentlichen Raum übertragen. Mit Konzepten wie der Stakeholderanalyse hat man dann ein Werkzeug, das auch in diesem Kontext genutzt werden kann. Die Stakehholderanalyse ist eine auf Interessen und Interessensgruppen fokussierte Form der Umweltanalyse.

Stakeholdermanagement, in: Hrsg.: Peter Patze-Diordiychuk, Jürgen Smettan, Paul Renner, Tanja Föhr, Methodenhandbuch Bürgerbeteiligung – Beteiligungsprozesse erfolgreich planen, München 2017



bernhardschloss.de