(12) Krisen und Erfolg von Projekten

Was ist eigentlich Erfolg im Projekt, und was eine Krise? Mit meinem Kollegen Christian Botta suche ich in diesem Video-Training mit Ihnen nach Erfolgs- und Misserfolgsfaktoren und wir reden offen über das Scheitern von Projekten. Klassiker sind der CHAOS-Report. Wir reflektieren Projektcontrolling, Machbarkeit, Kosten-Nutzen-Analysen und Stakeholdermanagement.
Wir betrachten das Komplexitätsdilemma, scheitern als Chance, Lernen und den Umgang mit Scheitern.

Sie erfahren, wie Sie Krisen erkennen und diese meistern können. Auch die Themen Gesundheit und persönliche Krisen werden angesprochen.

In sieben Projektgeschichten erfahren Sie abschließend, wie eng Erfolg und Misserfolg in einem Projekt oft bei einander liegen und welche Nuancen über einen glücklichen oder unglücklichen Ausgang eines Projektes entscheiden können.

Hier geht es zu Folge (12): Krisen & Erfolg
Und hier zum vollständigen Kurs:
https://www.linkedin.com/learning/paths/ihr-weg-zum-projektmanager
Und einen Flyer mit der vollständigen Kursbeschreibung gibt es hier.

 

 

#675 Best of… Das Komplexitätsdilemma

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.
(Hier geht´s zum Original-Post)

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

 

#626 Reporting, BI & Big Data

Reporting ist ein Klassiker.
BI (Business Intelligence) und Big Data sind allgegenwärtige Buzz Words.
Zeit sich hier einmal dem Thema zu widmen und das nicht nur für Projektmanager.

Möglichkeiten und Grenzen von Big Data

Ein Beispiel für die Nutzung von Big Data ist der Fall des Autobahn-Snipers: Ein frustrierter LKW-Fahrer schießt während der Fahrt über mehrere Jahre aus seiner Fahrzeugkabine auf andere Fahrzeuge. Überführt wird er letztlich über eine systematische Auswertung von Kennzeichen-Erfassungen auf deutschen Autobahnen. Der Aufwand dafür beträchtlich, sowohl in finanzieller als auch in zeitlicher Hinsicht.
Nicht nur im Zusammenhang mit dem NSA-Skandal wird die Aussagekraft von Kommumikations-Metadaten immer wieder thematisiert. Dimitri Tokmetzis zeigt auf netzpolitik.org, was allein schon Metadaten über uns aussagen.
Oder haben Sie sich schon einmal gewundert, was soziale Netzwerke bereits über uns wissen ohne, dass wir es ihnen gesagt haben (z.B. weil unsere Kontakte uns in ihrem Adressbuch führen oder es ungewöhnliche Schnittmengen in den Kontakten unserer Kontakte gibt).
Big Data per se ist weder gut noch böse. Die Möglichkeiten sind einerseits beeindruckend aber andrerseits auch beängstigend. Wir können uns nicht davor verschließen, aber um so wichtiger ist eine kritische Auseinandersetzung mit dem Thema. Wir haben in der digitalen Welt bereits einen Kontrollverlust über unsere Daten erlitten .(Diese Tage erscheint hierzu das Buch: Das neue Spiel von Michael Seemann – siehe auch sein Blog ctrl-Verlust.) Wer argumentiert, er hätte nichts zu verbergen, ist naiv, denn aus der Kombination an sich „harmloser“ Daten entsteht mitunter eine kritische Information. Stellen Sie doch einmal einen Kreditantrag oder unterziehen sich der Gesundheitsprüfung für den Abschluss einer Versicherung und Sie sind schneller in Erklärungsnöten, als Sie sich vorstellen können.

Garbage in – Garbage out

Worüber auch Big Data nicht hinwegtäuschen kann sind die elementaren Grundprinzipien der Datenverarbeitung. Nach wie vor gilt Garbage in – Garbage out. Nur in der Flut der Daten vergessen wir manchmal welches Datum tatsächlich ein Information enthält und welches nicht oder überbewerten oder missinterpretieren dessen Informationsgehalt. Wir können unser Reporting und unsere Prozesse beliebig optimieren, aber wenn der Inhalt nicht stimmt…

Nicht Äpfel mit Birnen vergleichen

Natürlich dürfen wir auch nicht Äpfel mit Birnen vergleichen (inhaltlich).
Und zeitliche Synchronität wäre für die Vergleichbarkeit auch schön.

Korrelationen nicht mit Kausalität verwechseln

Bei der Interpretation von Daten dürfen wir selbstverständlich auch nicht Korrelationen mit Kausalitäten verwechseln. Handelt es sich tatsächlich um Ursache-Wirkungsbeziehungen oder möglicherweise nur um 2 Symptome der gleichen Krankheit…

Unwort: Komplexitätsreduktion

Es ist i.d.R. eine irrige Annahme, dass sich Komplexität reduzieren lässt. Eine Reduktion hilft uns vielleicht bei der Erfassung des Überblicks oder in Bezug auf Facetten, sie reduziert aber nicht die Komplexität des realen Systems und verführt uns so zu möglichen Kurzschlüssen und Fehlentscheidungen. Wir sollten uns gerade auch bei der Erstellung von Reports und Auswertungen stets ihrer Unvollkommenheit bewusst sein. Mitunter ist hier weniger mehr: Wenige Zahlen, die wir aber vernünftig einordnen und erklären können, deren Grenzen uns bewusst sind, sind besser als pseudowissenschaftliche Tiefe, deren Grundannahmen auf fragilen Mauern stehen, uns aber aufgrund ihrer vermeintlichen Exaktheit eine falsche Glaubwürdigkeit suggeriert. Allzu oft tappen wir in eine psychologische Falle und glauben viel leichter an die Richtigkeit einer Aussage, weil sie vermeintlich bis auf 2-Nachkommastellen belegt ist.

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

#601 Gelesen: Logik des Mißlingens

Dietrich Dörner, Die Logik des Misslingens, Strategisches Denken in komplexen Situationen, 11. Auflage, Hamburg 2012, ISBN-13: 978-3-499-61578-8

Strategien für den Umgang mit komplexen Situationen hört sich wie ein Patentrezept für Projektarbeiter an. So trivial ist es aber nicht. Dörner identifiziert eher aus einer psychologischen Warte mögliche Handlungsoptionen und typische Fehler, das Ganze durchaus fundiert aus der Beobachtung von unzähligen Planspielen und Experimenten, aber auch aus der Analyse historischer Situationen wie dem Atomunfall in Tschernobyl.

Einen Schönheitsfehler hat  die Betrachtung allerdings: Dis Schlussfolgerungen werden nicht aus komplexen Situationen, sondern aus komplizierten gezogen. Planspiele haben feste Regeln, Operations Research hat eine vollständige Modellbildung der Welt, a posteriori lässt sich die Welt erklären – aber gerade das alles haben wir in komplexen Situationen ja nicht. Vielleicht ist diese Unsauberkeit im Umgang mit dem Komplexitätsbegriff auch dem ursprünglichen Erscheinungsdatum (1989) geschuldet. Nichtsdestotrotz sind die Darlegungen auch für komplexe Situationen hilfreich und fundiert.

Als eher erfolgversprechenden Handlungsoptionen nennt Dörner u.a.:

  • Arbeitshypothesen permanent hinterfragen und prüfen
  • Hohes Maß an Selbstorganisation und Strukturierung, Fähigkeit zur Selbstkritik
  • Dekomposition komplexer Situationen
  • Balance & Kompromiss
  • Umgestaltung des Systems (um negative Zielkonflikte und Abhängigkeiten aufzulösen)
  • Zielkonkretisierung
  • „Reperaturdienstverhalten“/Muddling-Through – Auch wenn Dörner die Gefahren eines solchen Verhaltens sieht (siehe unten): Behebung von Missständen ist die bessere Alternative zum Gar nichts tun.
  • Anpassung an wandelnde Kontexte/Kontextspezifisches Verhalten
  • Institutionelle Trennung von Informationssammlung und Entscheidung
  • Vorausschau zukünftiger Szenarios
  • Vorwärts- und Rückwärtsplanung
  • Strategien zur Suchraumeinengung:

o Heurismen
o Hill Climbing (nur solche Aktionen in Betracht ziehen, die einen Fortschritt in Richtung auf das Ziel versprechen mit der Gefahr auf einem Nebengipfel zu landen statt am eigentlichen Ziel)
o Zwischenzieleo    Effizienz-Divergenz, d.h. Situationen anstreben, die möglichst viele Handlungsoptionen mit relativ hoher Erfolgswahrscheinlichkeit offen lassen
o Frequency-Gambling (Was hat in der Vergangenheit funktioniert?)

  • Strategien zur Suchraumerweiterung:

o Freies Probieren (Trial & Error)
o Ausfällen des gemeinsamen nach Duncker (Welche Gemeinsamkeiten haben die bislang erfolglosen Lösungsversuche?)
o Analogieschlüsse

  • Wechselspiel von Suchraumeinengung und Suchraumerweiterung

 

Tendenziell zu fehlerhaftem Verhalten/Misserfolg verleitet hingegen:

  • Arbeitshypothesen werden als wahr hingenommen und nicht weiter hinterfragt.
  • Sprunghafter Themenwechsel, Aktionismus, Ablenkung
  • Übersteuerung
  • Gruppendenke/Groupthink (nach Janis)
  • „Reperaturdienstverhalten“/Muddling-Through (Konzentration auf die Behebung isolierter Missstände, wobei die Vorstellung des eigentlich angestrebten Zielzustandes auf er Strecke bleibt)
  • Überbetonung des aktuellen Motivs
  • Informationelle Überlastung
  • Similarity Matching (Tendenz, eher auf Ähnlichkeiten als auf Unterschiede zu reagieren)
  • Schematisierungen und Reglementierungen
  • Nichtberücksichtigung von Friktionen („Unvorhersehbarkeiten“)

Alles in allem eine empfehlenswerte Lektüre und bemerkenswert auch: Welches deutschsprachige Buch zu einem abstrakten, wissenschaftlichen Thema kann schon auf so viele Auflagen verweisen?

#562 Gelesen: Management 3.0


Jurgen Appelos Buch „Management 3.0 – Leading Agile Developers, Developing Agile Leaders“ ist der legitime Nachfolger von DeMarco/Lister´s „Peopleware“ (zu Deutsch: „Wien wartet auf dich„).

Appelo versucht Management-Konzepte vor dem Hintergrund agiler Software-Entwicklung und moderner Systemtheorie neu aufzurollen. Dies gelingt ihm sympatisch und kompetent. Das Buch hat sicherlich seine Macken (ich finde die Konzentration auf Software-Entwicklungsteams etwas künstlich und sein Umgang mit Fußnoten, die i.d.R. auf die eigene WebSite referenzieren ist zumindest gewöhnungsbedürftig, obwohl interessierte Leser mehr als genug (auch wissenschaftliche) Literaturhinweise finden). Alles in allem ist es aber anregend, kritisch, trotz theoretischem Fundaments praktisch orientiert und vor allem gut lesbar. Jurgen Appelo´s Pragmatismus kommt in seinem Schlusswort zum Ausdruck:

I know my book is „wrong,“ but I sincerely hope you find it useful.

Aus dem bunten Konglomerat von Agiler Software Entwicklung, Systemtheorie und moderner Management Theorie leitet Jurgen sein Management 3.0 Modell mit der Comic-Figur Martie (sein Buch lebt auch von den Illustrationen), die sechs Augen hat und damit sechs unterschiedliche Sichtweisen repräsentiert, die ein agiles Management nach Jurgens Auffassung haben sollte:

  • Energize People
  • Empower Teams
  • Align Constraints
  • Develop Competence
  • Grow Structure
  • Improve Everything


Den ganzen Beitrag lesen…

#484 Komplexität in Beratungsprojekten

Projektarbeit nimmt immer mehr zu und häufig wird dabei auch auf externe Unterstützung in Form von Unternehmensberatern zurückgegriffen. Bastian Hanisch hat an der EBS nun in einer Studie untersucht, wie es um die Komplexität in Beratungsprojekten steht. (Zur Teilnahme an der Studie hatten wir hier aufgerufen.) Im Vordergrund steht die Frage, wie man sowohl auf Kunden- als auch auf Beraterseite mit der Komplexität umgeht, um den möglichen Projekterfolg zu steigern.

Die Studie unterscheidet 3 Arten von Komplexität in Projekten:

• Aufgabenbezogene Komplexität: resultiert aus der zu lösenden Aufgabenstellung

• Strukturelle Komplexität: resultiert aus Anzahl und Wechselwirkungen der beteiligten Elemente

• Zeitbezogene Komplexität: resultiert aus Veränderungen im Projekt im Zeitverlauf

Der Autor kommt zum Fazit, dass strukturelle Komplexität reduziert und insbesondere die Qualität der Zusammenarbeit sowie die Transparenz gestärkt werden sollte.

Eine Zusammenfassung finden sich auf den Seiten der GPM.

#430 Studie: Komplexität in Beratungsprojekten

Bastian Hanisch von der ebs führt im Rahmen seiner Promotion eine Studie zum Thema Komplexität in Beratungsprojekten durch. Wer an der Studie teilnehmen möchte gelangt über diesen Link direkt zur Umfrage.

Im Gegensatz zu anderen Umfragen über Projekte wird explizit bei der Beantwortung zwischen Berater und Auftraggeber unterschieden. Allerdings scheinen Auftrag, Umfang, Organisation und Projektbeteiligte in der Theorie viel klarer, als wir es häufig in der Praxis vorfinden, aber vielleicht liegt das nur an meinen Projekten… Vielleicht liegt es an der Nähe von IT-Projekten zur IT-Regelorganisation.

Seltsamerweise gerate ich bei der Beantwortung solcher Umfragen immer wieder in ungeahnte Schwierigkeiten. So „banale“ Dinge, wie beispielsweise die Frage nach dem Projektaufwand sind bei genauer Betrachtung gar nicht so leicht zu beantworten: Projekte passieren nicht isoliert, sondern sind eingebettet in einem Umfeld. Gehört eine Leistung noch zum Projekt oder schon zur Regelorganisation? De facto gibt es einen permanenten Austausch und Wandel von Anforderungen wie auch Leistungen.

Alles wesentlich zur Umfrage hat auch Andreas auf PJMB/Unlocking Potential zusammengefasst.

#359 Komplexität in Projekten

In meinem Feedreader hängen geblieben bin ich an einem Beitrag von Torsten J. Koerting zum Thema Komplexität von (Prozess-)Projekten. Der Kollege hat einen generischen Ansatz entwickelt in dem er für bestimmte Ausprägungen in fünf vordefinierten Dimensionen konkrete Handlungsempfehlungen für Projekte gibt. Das Ganze ist sehr klug und inspirierend, aber hängen geblieben ist bei mir insbesondere das Zitat, in dem er diesen Ansatz als pragmatisch bezeichnet, den ich trotz seiner Vorzüge doch eher als theoretisch bezeichnen würde.



bernhardschloss.de