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.

#679 Fehlerkultur & Resilienz in Projekten

Fehlerkultur und Resilienz tauchen als Begriffe immer häufiger auf und erweisen sich in komplexen Aufgabenstellungen als erfolgreiche Strategie.  Wenn wir schon nicht alles planen und steuern können, dann können wir uns wenigstens auf die Unzulänglichkeiten des Lebens hinreichend vorbereiten. Das gilt in Ausnahmesituationen, ebenso wie im Unternehmensalltag oder in Projekten.

Resilienz mag der Überbegriff sein, aber die Fehlerkultur, als die Art und Weise, wie wir mit Fehlern umgehen ist ein wesentlicher Bestandteil, der zur Resilienz beiträgt. Ein wunderschönes Beispiel dafür, was Fehlerkultur ist, liefert ein Beitrag von Impulse über Fehlermanagement in der Luftfahrt oder: Was Unternehmer von Piloten lernen können.

Und was können sie lernen?  – Das Fehler ganz normal sind und dazu gehören, aber wir können uns auf sie vorbereiten und wenn wir vorbereitet sind, zwingt uns nicht der einzelne Fehler, sondern erst die unglückliche Verkettung mehrerer Fehler in die Knie.

Die Schuldfrage/Cover-your-ass sind unternehmenspolitische Machtspielchen, die nur leider jeden anderen Zweck verfolgen als den Projekterfolg. Mit Fehlerkultur haben sie nichts zu tun. Eher Unkultur…

Resilienz (von lat. resilire ‚zurückspringen‘ ‚abprallen‘) oder psychische Widerstandsfähigkeit ist die Fähigkeit, Krisen zu bewältigen und sie durch Rückgriff auf persönliche und sozial vermittelte Ressourcen als Anlass für Entwicklungen zu nutzen.
(Wikipedia)

Resilienz ist wohl auch eines der Merkmale agilen Projektmanagements, dass dieses so populär macht. Ein zweiter Faktor, der damit Hand in Hand einhergeht sind Kommunikation & Transparenz. Gerade im agilen Projektmanagement werden viele Kommunikationsformen mit Ritualen verstärkt und etabliert. Und last but not least ein spezielles Menschenbild, obwohl das bei der zunehmenden Verbreitung agiler Ansätze immer häufiger vergessen wird. Überhaupt wird der Begriff „agil“ mittlerweile inflationär gebraucht – missbräuchlich gegenüber der ursprünglichen Idee.

Nichtsdestotrotz: Die Erfolgsfaktoren hinter erfolgreichem agilen Vorgehen sind also Kommunikation, Transparenz und Resilienz und auch klassisches Vorgehen kann genauso erfolgreich sein, wenn diese Erfolgsfaktoren gegeben sind. Projekterfolg ist also weniger eine Frage des Vorgehensmodells (agil oder klassisch) als eine Frage der Umsetzung dieser Erfolgsfaktoren (Transparenz, Kommunikation und Resilienz).

#620 Spektrum der Projektarbeit

Projektarbeit muss kontext- und situationsspezifisch sein. Pauschalisierte Ansätze oder Ideologien sind vor diesem Hintergrund Quatsch. Das Spektrum der Projektarbeit (den Managementbegriff habe ich an dieser Stelle bewusst vermieden) ist im Wesentlichen gekennzeichnet durch das gewählte Vorgehensmodell und den praktizierten Führungsstil.

Beginnen wir beim Vorgehensmodell:

Das Spektrum reicht vom Wasserfall bis hin zu agilem, iterativen Vorgehen. Der reine Wasserfall existiert bei genauer Betrachtung eigentlich gar nicht. Nur ein Idiot würde einen einmal gefassten Plan blind in einem Wurf umsetzen. Weitaus häufiger finden sich modifizierte Wasserfallmodelle. Für den Umgang mit Unsicherheit gibt es unterschiedliche Lösungsstrategien: Ein Changemanagement, das Change Requests an ein Projekt behandelt, oder eine iterative Ausarbeitung. Aber auch hier ist die Unterscheidung nicht sinnvoll, weil es auch in der vermeintlich klassischen Projektwelt erlaubt ist iterative Elemente einzusetzen und umgekehrt scheint mir das agile Vorgehen als Postulat genauso überzogen, denn ich kann mir sehr wohl Vorhaben vorstellen, die für den großen Entwurf ein modifiziertes Wasserfallmodell wählen und erst in der Ausarbeitung agil werden, beispielsweise bei der Umgestaltung ganzer Unternehmensarchitekturen. Es gibt ergo keine harten Grenzen.

Auf Seiten des gewählten Führungsstils sieht es ähnlich aus:

Dem humanistischen Ideal des agilen Manifests, ein paritzipatives Modell, weitgehend selbstgesteuert, steht das autoritäre, taylorisitsche Denken gegenüber. Aber auch hier gebe ich zu Bedenken: Der gewählte Führugnsstil muss sowohl zu den Beteiligten und der betroffenen Organisation passen, als auch dem konkreten Kontext gerecht werden. D.h. z.B. dass ein rein agiles Vorgehen an bestimmte Voraussetzungen gebunden ist: Wenn eine Organisation noch nicht bereit ist für ein partizipatives Modell, so wird auch ein agiler Ansatz scheitern. Da hier kulturelle Prozesse betroffen sind, gibt es auch keine schnellen Veränderungen, sondern bestenfalls einen langwierigen, mit Anstrengungen verbundenen Prozess.

Einen zweiten kontextspezifischen Aspekt kann es aus sachlicher Notwendigkeit geben: Bei einem Notfall oder einem Rettungseinsatz, wird man schwerlich die Autortität des Einsatzleiters hinterfragen. Hier gibt es Notwendigkeiten in der zeitlich/sachlichen Koordination, die eine Unterordnung erfordern. Dies ist aber kein blinder Gehorsam, sondern lediglich eine situationsspetzifische Unterodnung. Sobald die sachliche Notwendigkeit entfällt besteht auch wieder die Möglichkeit zu Partizipation und autonomen Handeln.

Ein dritter und letzter wesentlicher Punkt bei der Wahl des Führungsmodells stellt die erforderliche Expertise dar. Die Tayloristische Arbeitsteilung wird allzu schnell auf ihre arbeitspsychologischen Nachteile reduziert. Ein weiterer Aspekt (und auch ein Vorteil) liegt in der Spezialisierung (und Expertise). Die Annahme eines SCRUM-Teams, in dem jeder theoretisch jede Aufgabe übernehmen kann, ist illusorisch. Natürlich gibt es komplexe Aufgaben die sinnvollerweise einem Experten zugeordnet werden. (Wer beispielsweise mal einen EDI-Experten in einem Unternehmen kennengelernt hat, weiß wovon ich spreche…)

Der Versuch die existierenden Schulen/Ansätze in diesem Spektrum zu verankern ist zugegebenermaßen gewagt und im Detail zwangsläufig auch falsch.

Ich möchte zwischen den verschiedenen Vertretern des „klassischen“ Projektmanagement (so fragwürdig dieser Begriff auch immer ist) gar nicht differenzieren und Scrum ist auch nur ein Vertreter der agilen Welt. Mittlerweile gibt es auch bei den „klassischen“ Vertretern  immer mehr das Aufrgreifen agiler Ansätze und umgekehrt in der rein agilen Welt muss man sich auch den Realitäten stellen: Wenn der Kunde sich nicht einbinden lässt, dann muss auch der Product Owner neu interpretiert werden. Und wenn dann die Voraussetzungen nicht passen, dann sieht auch ein Scrum Master genauso alt aus, wie ein im Stich gelassener klassischer PM.

De facto geht es halt doch nicht ohne eine kontextspezifische Betrachtung: Wichtiger als das Vorgehensmodell sind die konkreten Umstände. Welche Stakeholder sind eingebunden, nehmen welche Rolle war? Rollen lassen sich zum Teil nur definieren, zum Teil sind sie einfach nur gegeben. Ein gut eingebundener Kunde ist der Traum eines jeden Projetarbeiters – egal ob agil oder klassisch. In der Realität muss man den Kunden nehmen, den man hat. Das Leben ist kein Wunschkonzert.

#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.

#609 visualPM: klassisch, agil – Design Thinking

Auch wenn wir hier etwas einseitig auf die Prozessperspektive des Design Thinking blicken, so ist das doch ein hilfreicher Ansatz um auch Projektmanagement-Schulen zu reflektieren.

Das „klassische“ PM unterstellt fast schon tayloristisch den „one best way“ zum Projektziel, der anfangs geplant und dann konsequent sequentiell in einem Wasserfallmodell abgearbeitet wird. Dieses Bild ist natürlich stark vereinfacht, denn auch die „agilen“ Oesterreich und Weiß weisen bereits darauf hin, dass die Väter des Wasserfallmodells durchaus (Rück-)Sprünge zwischen Prozesschritten/-phasen gesehen haben.

Im agilen PM wird die Idee der Umsetzung auf dem direkten Weg in einem großen Wurf aufgegeben. Der Fokus bleibt zwar auf der Umsetzung einer Lösung, aber nicht auf der Umsetzung eines großen Plans, sondern auf der Umsetzung der Anforderungen im Backlog in vielen kleinen Schritten/Iterationen. Iteratives Vorgehen lässt bewusst Platz für permanente Changes, die den klassischen PM doch in Verzweiflung treiben. Schrittweises Vorgehen und die permanente Integration erlauben von Anfang an einen Lernprozess. Risiken werden durch die laufende Integration minimiert, da Fehler schnell erkannt werden und korrigiert werden können. Änderungen können problemlos in den laufenden Prozess einfließen. Was gerne vernachlässigt wird ist aber, dass agiles PM auch einige implizite Annahmen mit sich bringt, z.B. bzgl. der Skalierbarkeit von Anforderungen/Features und der Skalierbarkeit des Teams.

Während diese beiden Ansätze also auf die Umsetzung von Anforderungen fokussieren, fokussiert Design Thinking auf den kreativen Prozess, auf die Gestaltung und Problemlösung. Wir entwickeln ja erst die Lösung und auch nicht die EINE Lösung, sondern möglicherweise erst einmal eine ganze Reihe verschiedener Lösungsansätze, die wir parallel verfolgen und weiterentwickeln, bevor wir uns für eine Variante entscheiden. Wir suchen quasi die Lösung für ein komplexes Problem, statt von Anfang an einen mehr oder weniger komplizierten Plan zu verfolgen.

STOP. Denkpause.

Aber eigentlich ist doch Komplexität ein konstituierendes Merkmal der Projektdefinition. Heißt das dann nicht im Umkehrschluss, dass wir im Projektmanagement (egal ob klassisch oder agil) auf der Suche nach dem einen Weg zum Ziel die Komplexität (trotz besserem Wissen) ignorieren bzw. vernachlässigen?

Kein Wunder, dass so viele Projekte scheitern…

Umgekehrt benötigt der kreative Prozess aber Freiraum, Zeit und Ressourcen. Er ist vielleicht effektiv, aber möglicherweise nicht so effizient, wie es sich der eine oder andere Stakeholder erhofft.

Folgende Grafik skizziert noch einmal die drei Herangehensweisen, vom klassischen direkten Weg zum Projektziel, über das agile Herantasten, bis hin zur parallelen Entwicklung von Lösungsalternativen im Design Thinking:

#569 PM – Abschied vom Management

Die Betrachtung von Erfolg und Scheitern von Projekten wurde auf dem PM-Camp in Stuttgart auf die Meta-Ebene gehoben (hier in der Session-Doku auf openPM oder hier auf schlossBlog).

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 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.