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

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.

#656 Das Komplexitätsdilemma von Projekten

In der Blogparade des PM Camps Berlin (ich werde übrigens auch dabei sein) ist schon viel Kluges und Grundsätzliches über Komplexität gesagt worden. Ich will daher hier nur auf einen speziellen, projektspezifischen Aspekt eingehen, den ich an anderer Stelle schon einmal entwickelt habe:

Das Komplexitätsdilemma von Projekten

Unterstellen wir ein tatsächlich komplexes Projektvorhaben. Für viele von uns ist Komplexität sogar ein konstituierendes Merkmal von Projekten, bloß dummerweise vergessen wir das sofort wieder, wenn wir ein Projekt in Angriff nehmen. Spätestens mit dem Projektauftrag machen wir uns auf die Suche nach dem eindeutigen Ziel, versuchen den großen Wurf und selbst im agilen Projektmanagement versuchen wir uns diesem Ziel (wenn auch in inkrementalen Schritten) zu nähern.

Diese Negierung der Komplexität erklärt sicherlich auch, warum so viele Projekte scheitern.

Wir brauchen in Projekten mehr „Komplexitätsbewusstsein“. Wir müssen uns der inhärenten Komplexität stellen, ohne künstlich hausgemachte Komplexität, wie im vielfach bekannten und praktizierten Planungs- und Reportingwahnsinn, zu produzieren.

Projektmanagement per se ist ein Paradoxon: Einerseits setzen wir bewusst Projekte auf um komplexe Problemstellungen zu bearbeiten, andererseits blenden wir die Komplexität gleich wieder aus und versuchen uns stattdessen an komplizierten Vorgehensweisen. Und das gilt gleichermaßen für agile und für traditionelle Projektmethoden.

 

#618 Beyond Project Management

Dies ist mein Beitrag zur Blogparade von Marcus Raitner zum diesjährigen Motto des PM-Camp Dornbirn.

Projekte werden bleiben. Und sie werden wichtiger denn je. Nichtsdestotrotz gibt es diesen Wunsch nach einem „beyond project management“ zu verzeichnen und auch dieser Wunsch ist durchaus nachvollziehbar:

  1. Es gibt eine wahre Inflation an Projekten („Projektitis), d.h. vieles (egal ob es sich um ein Projekt handelt oder nicht) wird in ein Projektkorsett gepresst. Da wird ein Projekt schon mal schnell zum Formalismus und der gesunde Menschenverstand bleibt auf der Strecke.
  2. In der Projektarbeit wird glatt vergessen, dass es bei Projekten um komplexe Problemlösungsaufgaben geht, stattdessen wird mit Patentrezepten nach schnellen Lösungen gesucht.
  3. Innerhalb des Projektmanagement gibt es seit Jahren Abgrenzungskämpfe: Einmal zwischen den Verbänden (GPM, PMI,…) und zum Anderen klassisch vs. agil.

An (1) sind aktuelle Management-Strukturen nicht unschuldig: Projekte werden als Werkzeug zur Unternehemenssteuerung eingesetzt – nein: missbraucht. Da sind Projekte das Vehikel beispielsweise der Budgetplanung und wenn für ein Thema Budget gebraucht wird, dann plant man dafür ein Projekt – unabhängig von Art und Charakter der Aufgabe. Außerdem will man alle Projekte miteinander vergleichen können und die Dashboards und KPI´s in denen das Portfolio dargestellt werden, sind der Traum des Managements, aber mitunter des Albtraum der Projekte, denn komplexe Sachverhalte auf Kennzahlen zu reduzieren ist nicht nur mutig, sondern auch gefährlich. Vielleicht steckt hinter „beyond project managememt“ also mehr ein „beyond management„.

Bei (2) möchte ich von einem Komplexitätsdilemma von Projekten sprechen (siehe auch die Betrachtung im Rahmen der Design Thinking Reihe). Die Komplexität der Aufgabenstellung ist einerseits konstituierendes Merkmal eines Projektes, andererseits verdrängen wir das sofort wieder in dem wir uns auf die Suche nach der einen Lösung machen, egal ob im großen Wurf oder in inkrementalen Schritten. Wenn wir uns das Komplexitätsdilemma bewusst machen, ist es kein Wunder, warum so viele Projekte scheitern. Vielleicht brauchen wir hier einen Perspektivenwechsel: Weg von der Erfolgsbetrachtung des einzelnen Projekts, hin zu einer Entwicklungs- und Lernperspektive.

Ad (3): Ich bin ganz bei Stefan Hagen und Reinhard Wagner: Die künstlichen Abgrenzungsversuche sind reiner Quatsch. Was die Scharmützel der Verbände angeht, so sehe ich diese v.a. als Ergebnis der ökonomischen Interessen des mittlerweile auswuchernden Zertifizierungsbusiness (aber das ist eine andere Diskussion). Die vielen unnötigen Diskussion agil vs. klassisch der letzten Jahre gehen mir mittlerweile reichlich auf den Senkel. Zunächst muss man feststellen, dass dieses „klassische Projektmanagement“ erst von den „Agilisten“ erfunden wurde, nämlich im Versuch der Abgrenzung. Wir sind uns sicher schnell einig, dass es viele fragwürdige und überholenswerte Methoden und Vorgehensweisen gibt, die wir gerne anpacken sollten, aber bitte keine Glaubenskriege. Es gibt keinen Grund ein humanistisches Menschenbild, iterative Vorgehensweisen, Selbststeuerung und Teams in Projekten (á la Agiles Manifest) abzulehnen. Das tut auch keiner – nur die Abgrenzung klassisch vs. agil. Es gibt nur ein Welt, aber diese mit sehr vielen Facetten und vielen unterschiedlichsten Versuchen die Fragen dieser Welt zu beantworten. Primär ist für mich dir Frage nach dem Kontext entscheidend und nicht die Frage nach der Schule mit der ich versuche einen Kontext zu bearbeiten. Somit schließt sich wieder der Kreis zur Argumentation von Stefan Hagen und Reinhard Wagner.



bernhardschloss.de