Schlagwort: Risikomanagement

Komplexität – Blogparade PM Camp Berlin 2015

Komplexität – Blogparade PM Camp Berlin 2015

Die Kollegen vom PM Camp Berlin haben zur Blogparade aufgerufen. Ihr diesjähriges Motto lautet Komplexität – reduzieren oder erhöhen? Wenn ich mich dem Thema Komplexität annähere, ist mein erster Gedanke Komplexität überhaupt zu erkennen. Um sie zu erkennen muss zuerst der Begriff klar sein:1
Komplexität bezeichnet allgemein die Eigenschaft eines Systems oder Modells, dessen Gesamtverhalten man selbst dann nicht eindeutig beschreiben kann, wenn man vollständige Informationen über seine Einzelkomponenten und ihre Wechselwirkungen besitzt. Der Begriff leitet sich ab von lateinisch complexum, Partizip Perfekt von complecti ‚umschlingen‘, ‚umfassen‘ oder ‚zusammenfassen‘. Dabei handelt es sich um ein Kompositum aus der Präposition lateinisch cum ‚mit‘, oder ‚zusammen mit‘ und plectere ‚flechten‘ oder ‚ineinander fügen‘ im Sinne von ‚verflochten‘, ‚verwoben‘.
Es geht also um Systeme, die eine Vielzahl von miteinander wechselwirkenden Einzelkomponenten enthalten. Wenn die Komponenten und / oder Wechselwirkungen nicht bekannt sind, heißt das noch nicht, dass das System komplex ist. Es ist erst dann komplex wenn auch mit vollständigem Wissen eine Beschreibung oder Vorhersage des Verhaltens nicht möglich ist. Unwissenheit macht also noch keine Komplexität. Zu Beginn jedes Projektes besteht die Hauptaufgabe darin Unbekanntes aufzufinden. Erst im Laufe des Projektes kann zwischen Kompliziertheit und Komplexität unterschieden werden. Um nicht gleich vom Schlimmsten auszugehen, könnten mann/frau mit der Annahme beginnen, dass es “nur” kompliziert werden wird. An dieser Stelle möchte ich noch auf einen älteren Text verweisen, in dem ich auf die Unterscheidung zwischen kompliziert und komplex eingehe: Komplexität wird überbewertet Meines Erachtens wird zu oft mit zu hohem Einsatz gegen nicht vorhandene Komplexität gekämpft. Wenn es dann mal wirklich komplex wird, helfen ohnehin nur Vereinfachung bzw. schlanke Methoden und Werkzeuge. Wenn der Komplexität mit komplizierten Methoden begegnet wird, kommen nur weitere Variablen ins Spiel, die das System noch unvorhersehbarer machen. In diesem Zusammenhang fällt mir eine historische Science-Fiction Geschichte von Stanislaw Lem2 ein. In der Geschichte Ananke3 beschreibt er den Absturz eines neuen Raumschiff-Typs. Die Ursache für den Absturz liegt im Hauptcomputer, der versucht die Situation mittels umfassender Abfragen aller technischen Parameter in den Griff zu bekommen und sich dabei selbst die Rechenkapazität beschneidet, bis er nicht mehr in der Lage ist, in Echtzeit zu reagieren.4 Als die Protagonisten der Geschichte den Unfall analysieren wird ein Vergleich mit einem General gezogen, der immer mehr Soldaten als Melder und Kundschafter abstellt, um besser informiert zu sein und am Ende nicht mehr genügend Truppen zum Kämpfen hat und dadurch die Schlacht verliert. Ich denke wir sollten in komplexen Kontexten diesen Fehler nicht begehen sondern mehr Mut zur Lücke zeigen. Auf dem PM Camp Berlin von 10. bis 12. September 2015 besteht die Gelegenheit sich diesen Mut zu holen.

 

  1. Wikipedia Komplexität []
  2. Stanislaw Lem: Pilot Pirx, Erzählungen []
  3. Wikipedia: Pilot Pirx, Ananke []
  4. Ein derartiger Effekt trat z.B. durch einen Fehler im Handbuch auch bei der Mondladung von Apollo 11 auf. []
Aus den Apollo-Missionen für Projekte lernen

Aus den Apollo-Missionen für Projekte lernen

Die erste Mondlandung liegt 40 Jahre zurück. Der erste Mann auf dem Mond Neil Armstrong hat kürzlich seinen 80. Geburtstag gefeiert. Die Nasa stellt die Mission-Reports im Internet zum Download bereit. Das ist nochmal eine Gelegenheit die Apollo Missionen unter dem Projekt-Gesichtspunkt zu betrachten. Das Apollo-Programm war ein riesiges Projekt, 40000 Mitarbeiter, Milliardenbudget, mehr als 10 Jahre Laufzeit, haufenweise technologische Herausforderungen und ein immenses Risikopotential. Ein Projekt, das eigentlich kaum zu managen war aber dennoch zum Erfolg führte. Woran lag es? Was können wir für ganz normale Projekte daraus lernen. Es war die Vision, das Ziel des Projektes. Dieses Ziel war unglaublich groß, herausfordernd fast furchteinflößend und dennoch in einem Satz zu formulieren. Lassen wir John F. Kennedy zu Wort kommen:
to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth.
Eine Vision von bestechender Klarheit. Jede(n) der 40000 MitarbeiterInnen hätte man fragen können “Warum macht ihr das?” und jede(r) hätte geantwortet. Unsere Jungs sollen zum Mond fliegen, landen und wieder heil zurückkommen. Die Klarheit der Vision ist der erste Schritt zum Erfolg. Obwohl in normalen Projekten immer auf die Klarheit der Vision und Ziele gepocht wird sieht die Realität oft anders aus. In vielen Projekten ist es die Regel auf die Frage nach dem “Warum” eine Multiple Choice Antwort zu erhalten. Mit Apollo 11 wurde die von Kennedy formulierte Vision erfüllt. Aus den nachfolgenden Apollo-Missionen lässt sich noch mehr für die Projektarbeit lernen. Apollo 13 liefert Erkenntnisse über Risiken und die kollektive Intelligenz eines Teams. Die Explosion im Apollo 13 Raumschiff entstand aus der Wechselwirkung mehrerer Ursachen mit einer möglicherweise nicht kommunizierten Spezifikationsänderung. Das ist kein Witz. Tausenden von Ingenieuren und Wissenschaftlern war entgangen, dass zwar die Spezifikation der Thermoschalter in den Sauerstofftanks von 28 auf 65 Volt geändert wurde, die Schalter aber nicht ausgetauscht wurden. Einer der Schalter schmolz aufgrund der hohen Spannung bei der Flugvorbereitung durch und verursachte dann an Bord die Explosion mit den bekannten Folgen, dass Strom und Sauerstoff an Bord knapp wurden. Es lohnt sich zwei Gedanken aus diesem Ereignis mitzunehmen:
  • Es gibt immer etwas was man übersehen hat.
  • Selbst wenn es sich um eine Kleinigkeit handelt kann die Auswirkung riesig sein.
Und was hat das mit einem Team und kollektiver Intelligenz zu tun? Eine der wichtigsten Ideen bei der Rettung der Crew war es die Sauerstoffaufbereitung (Kohlendioxid-Filter) des Landers und des Mutterschiffs zu koppeln. Eine einfach umzusetzende Idee, wenn die Filteranschlüsse kompatibel gewesen wären. Die Einen waren dreieckig, die Anderen viereckig, ein Adapter war natürlich nicht an Bord. Hier drängt sich der Gedanke auf, dass bei der Spezifikation der Systeme vielleicht nicht ausreichend kommuniziert wurde 😉 Nun aber zur Lösung des Problems. Das Problem wurde zuerst exemplarisch auf dem Boden gelöst. Dieses Meeting von technischen Spezialisten der Apollo Mission ist die Mutter aller Teamübungen. Bei Teamentwicklungsmaßnahmen spricht man heute noch von einer NASA-Übung. Dieses Meeting zeichnet sich wiederum durch glasklare Ziele sowie eine materielle und zeitlich Begrenzung aus:
  • Wir müssen innerhalb weniger Stunden, diese zwei Anschlüsse verbinden.
  • An Material steht nur das zur Verfügung was auf dem Tisch liegt.
Auf dem Tisch lagen die losen und entbehrlichen Teile, die in einer Apollokapsel zur Verfügung standen. Mit zerschnittenen Plastikteilen, der Kunststofffolie des Bordbuch-Einbandes und Klebeband entstand der Adapter, der das Überleben der Crew ermöglichte. Das zusammengewürfelte Team hatte Erfolg. Die Ideen der Einzelnen vereinten sich konstruktiv zu einer Lösung, die im ersten Moment nicht für möglich gehalten wurde. Eine klare Aufgabe ist immer der Einstieg in eine konstruktive und lösungsorientierte Teamarbeit. Auch in ganz normalen Projekten können Krisen kreativ gelöst werden. Manchmal ist Projektmanagement nur eine Aneinanderreihung vieler NASA-Übungen.    
Das Schweizer Taschenmesser des Projekt-Berichtswesen

Das Schweizer Taschenmesser des Projekt-Berichtswesen

Berichtswesen im Projektmanagement, das ist so etwas wie eine Hassliebe. Als freiberuflicher Projektleiter bin ich nahezu in jedem Projekt mit anderen Vorlagen oder Formularen konfrontiert. Ãœber die Unsinnigkeit mancher Berichte möchte ich heute nicht viele Worte verlieren. Ich möchte nur ein negatives Beispiel kurz anreißen: Ein Bericht, der nur die verbrauchten Stunden erfasst die Erledigung der Aufgaben jedoch außen vor lässt, nützt niemandem. Der so ermittelte Ampelstatus ist sogar mehr als überflüssig, weil er Probleme eher verschleiert als aufzeigt. Anstelle weitere schlechte oder gute Bespiele anzuführen möchte ich eine Form des Berichtes vorstellen, die ich selbst in sehr vielen Projekten verwende. Es handelt sich um ein Projekttagebuch oder Projektjournal. Wie der Name nahelegt, wird das Journal sehr regelmäßig geführt. Regelmäßig – das heißt mindestens einmal die Woche. Inhaltlich liefert es Antworten auf folgende Fragen:
  • Was wurde in der vergangenen Woche erledigt?
  • Was soll in der kommenden Woche erledigt werden?
  • Welche Risiken sind hinzugekommen, welche haben sich verändert?
  • Wie sieht der gefühlte Gesamtstatus des Projektes aus?
  • Gibt es Entscheidungs- und Eskalationsbedarf?
Continue reading “Das Schweizer Taschenmesser des Projekt-Berichtswesen”
von verstopften Rohren, Engpässen und höheren Gewalten

von verstopften Rohren, Engpässen und höheren Gewalten

Vielleicht sollte ich die Worte der Ãœberschrift etwas erläutern. Das verstopfte Rohr ist ein aktuelles und reales Problem im Hause. Nichts was sich nicht durch etwas Arbeit und die Hilfe eines Rohrreinigungs-Service wieder lösen ließe, aber es kostet unvorhergesehen Zeit, Nerven und Geld. Anstatt wichtige Dinge zu erledigen, stehe ich in Gummistiefeln auf dem Hof und versuche den Engpass im Abflussrohr zu beseitigen. Mit der Projektleiterbrille sehe ich das Ganze als eine unvorhergesehene Störung, einen plötzlich auftretenden Zeitengpass, die zu einer Planabweichung des eigentlichen Projektes führen wird. Ein Stück weit ist das verstopfte Rohr höhere Gewalt. Auch die Wolke aus Vulkanasche, die heute über Deutschland hinweg zieht und Flughäfen lahm legt, ist höhere Gewalt. Weder das verstopfte Rohr noch der Vulkanausbruch sind in einem Projektplan als mögliches Zeitverlust-Risiko enthalten. Ich stelle mir gerade vor in einem Projektantrag würde stehen “Puffer, für unvorhergesehene Ereignisse wie “verstopfte Rohre” oder “Vulkanausbrüche”. Eine solche Formulierung würde im günstigsten Fall für Heiterkeit sorgen. Vorhersehen und präventiv einplanen lassen sich solche Ereignisse also nicht. Das ändert aber nichts daran, dass sie eintreten. Letztendlich lässt sich dieses Problem auch nicht lösen. Es geht mehr darum eine innere Einstellung zu finden um stressreduziert mit solchen Störungen umzugehen. Ich habe mir dazu drei Dinge hinter die Ohren geschrieben:
  • Akzeptiere, dass es Störungen gibt, und freue Dich über jeden Tag, der ohne Störung verläuft.
  • Eine Störung ist nur eine kurzzeitige Verschiebung der Prioritäten.
  • Eine gründlich beseitigte Störung kommt nicht so schnell wieder, und schafft neuen Freiraum.
und jetzt ziehe ich meine Gummistiefel an 😉
Von Projekten, Risiken und Seereisen (reload)

Von Projekten, Risiken und Seereisen (reload)

Erstens: Sie sind nicht immer lustig. Zweitens: Eine Seereise liefert schöne Analogien zum Risikomanagement 😉 Die Neuartigkeit eines Projekts enthält zwangsläufig unbekannte Faktoren, die sich zu Risiken entwickeln können. Ein zu Beginn des Projekts erstellter Plan kann die Risiken des Projektes nie vollständig berücksichtigen. Risikomanagement ist daher unerlässlich. Risikomanagement ist eine eigene Disziplin und kann sehr aufwändig gestaltet werden. Ich möchte bewusst einen einfachen Ansatz dagegen halten.

Es ist besser ein einfaches Risikomanagement anzuwenden als ein aufwändiges zu vernachlässigen.

Anstelle einer Definition beginne ich mit einem einfachen Vergleich. Es ist nicht ganz klar woher das Wort Risiko stammt. Eine Erklärung führt es auf das griechische Wort rhizikon (“Klippe”) zurück. Die Bedeutung Klippe, die umschifft werden muss um nicht zu scheitern, liefert mit den bildlichen Vergleich. Ein Projekt ist wie eine Seereise zu einem weit entfernten Wunsch-Ziel durch unbekanntes Gewässer. Die Vorräte an Bord des Schiffes sind begrenzt d.h. das Ziel sollte möglichst in der geplanten Zeit erreicht werden. Auf der Reise müssen unter Umständen viele Klippen umschifft und andere Hindernisse überwunden werden. Die Hauptaufgaben des Risikomanagements
  • Risiken erkennen
  • Risiken bewerten
  • Gegenmaßnahmen planen
werden mit dem Vergleich greifbar. Zuerst müssen möglichst viele der Klippen und Schwierigkeiten auf dem Weg erkannt werden. Schön wäre natürlich eine Seekarte auf der alle Klippen und Untiefen verzeichnet sind. Dann kommt noch eine Karte der Meeresströmungen, eine Wetterkarte usw. hinzu. Da solche Karten bei der Fahrt in wirklich unbekannte Gewässer in der Regel nicht existieren ist man überwiegend auf Vermutungen angewiesen und muss sich seine Karten selbst zeichnen. Selbst wenn bereits Karten vorhanden sind stellt sich immer noch die Frage nach der Verlässlichkeit des Kartenmaterials. Wenn man glaubt die meisten Klippen und Untiefen zu kennen, muss im nächsten Schritt geprüft werden wie gefährlich jedes Hindernis wirklich ist. Wie tief ist eine Untiefe wirklich, wie dicht liegen Untiefen und Klippen neben einander, wie sehen die Meeresströmungen an dieser Stelle aus, wie gut lässt sich manövrieren. Nimmt man ein Schiff mit weniger Tiefgang (wannenförmiger Rumpf = Mississippi Dampfer) lässt sich vielleicht die eine oder andere Untiefe einfach überfahren. Liegen viele Klippen dicht beieinander ist wiederum ein wendiges manövrierfähiges Schiff von Vorteil. Das wendige Schiff hat dafür aber wieder mehr Tiefgang als ein Schiff mit wannenförmigem Rumpf. Liegen Klippen und Untiefen im Weg sind vielleicht mehrere kleine, wendige Schiffe gegenüber einem großen im Vorteil. Mit mehreren kleinen Schiffen wäre ein Kompromiss zwischen Wendigkeit und geringem Tiefgang gefunden. Hinzu kommt jetzt die Schwierigkeit die Schiffe zu koordinieren um die Flotte z.B. bei Nebel zusammenzuhalten. Es wird deutlich, dass aus einer gründlichen Betrachtung der Risiken sich meist auch Ansätze für Gegenmaßnahmen zur Beherrschung oder Vermeidung derselben ergeben. Auch die Rückwirkung auf den Plan und die Projektorganisation ergeben sich relativ leicht (z.B. bedeuten mehrere Schiffe mehrere Kapitäne + einen Commodore). Dennoch wird in vielen Projekten systematisches Risikomanagement sträflich vernachlässigt. Meist steht der Aspekt Ressourcen – Planung zu stark im Vordergrund. Im Bild der Schiffsreise gesprochen wird oft zu viel Zeit auf die Katalogisierung der Ladung und die Mannschaftsliste verschwendet und dabei der Blick auf die Seekarte vergessen. Der Aufwand für Risikomanagement wird gerne eingespart. Wie kann ein pragmatisches und schlankes Risikomanagement in einem Projekt aussehen? Mit einer Liste und 4 Fragen, die sich die Projektleitung regelmäßig stellen sollte kommt mann/frau schon sehr weit:
  • Sind die drei größten Risiken bekannt?
  • Was sind heute die drei größten Risiken?
  • Hat jeder im Team sein größtes Risiko benannt?
  • Welche Risiken sind in der letzten Woche hinzugekommen?
Aus der Formulierung der Fragen lässt sich schon erahnen, dass sie regelmäßig, das heißt jede Woche oder sogar täglich neu gestellt und beantwortet werden müssen. Sind die drei größten Risiken bekannt? Selbst wenn im Projekt ein ausgewiesenes Risikomanagement betrieben wird, heißt das noch lange nicht, dass die größten Risiken bekannt sind. In der Formulierung “groß” steckt eine intuitive Mischung der Faktoren Eintrittswahrscheinlichkeit und Auswirkung. Diese sind leider nicht konstant und müssen ständig neu bewertet werden. Bevor man sich in seitenlangen Abwägungen und Wahrscheinlichkeitsrechnungen verheddert, ist es besser sich regelmäßig die zweite Frage nach dem heutigen Risiko zu stellen – getreu dem Motto: “Wo drückt der Projektschuh jetzt in diesem Moment?” Bei der dritten Frage wird es heikel. Keine Projektleitung kann alle Risiken finden. Sie letztendlich darauf angewiesen, dass alle im Team mit der Sprache rausrücken und das größte Risiko von dem sie wissen benennen. Die simple Frage “Weiß noch jemand was?” hilft hier nicht viel weiter. Es ist wichtig, dass im Team nicht ein Klima der Angst vorherrscht. Wenn die Angst regiert wird niemand gerne über Risiken sprechen. Die letzte Frage greift das Problem der unvollständigen Risikolisten nochmals in anderer Form auf. Ich schließe mit einer provokanten Aussage und einer Wiederholung:
  • Es ist besser ein einfaches Risikomanagement anzuwenden als ein aufwändiges zu vernachlässigen.
  • Projektarbeit ohne Risikomanagement ist grob fahrlässig.
Dieser Text ist unter Creative Commons BY NC ND (Namensnennung – Nicht Kommerziell – Keine Bearbeitung) lizenziert. Er ist Teil des Buchprojekts “Menschen im Projekt”. Er gehört zum Abschnitt X, siehe Mindmap zu Inhalt und Struktur.
© pentaeder 2019 / 2020