Risikomanagement als Werkzeug zum Umgang mit Unsicherheit

Olaf Hinz schreibt im Lotsenblog über das Management der „nächsten Gesellschaft“, wie unsicher unser Planungsumfeld geworden ist. Dazu bringt er anschauliche Beispiele:

Seit Herbst 2010 hatten sich die EU Regierungschefs ihre Treffen sicher anders geplant. Es war einfach nicht damit zu rechnen, dass Mitgliedsstatten innerhalb von Stunden die Liquidität ihres Landes von für Monate auf für Tage ausreichend korrigieren würden. Genauso hatte Amazon sein Weihnachtsgeschäft sicher anders vorgesehen und nicht damit gerechnet, durch koordinierte Angriffe von Unterstützern eines ehemaligen Geschäftspartners lahm gelegt zu werden. Und sicher ging es der Projektmanager eines deutschen Anlagenbauer auch von einem anderen Tagesablauf aus, als er eines Morgens die Mitarbeiter seines wichtigsten Unterlieferanten nicht mehr auf der Baustelle antraf. Erst nach zwei Tage dauernden Telefonaten stellte er fest, das die Firma über das Wochenende in die plötzliche Abwicklung ging.

Sein Fazit dazu ist, dass die Unsicherheit der heutigen Welt so groß ist, dass Planänderungen alltäglich sein werden – was aber Planung keineswegs obsolet macht, sondern Denken in Alternativen erforderlich macht.

Zugespitzt: Planung ist aussichtslos, aber notwendig.

Auch der Projektalltag spielt sich nicht selten in sehr variablem Umfeld ab. Darauf gibt es verschiedene Antworten. Für einige Themen (z.B. SW-Entwicklung) sind agile Ansätze, Scrum, etc. ein gangbarer Weg, mit der Unsicherheit umzugehen.

Was aber in Projekten, deren Arbeitspakete lange Vorlaufzeiten erfordern oder sich aus anderen Gründen nicht für „Agilität“ eignen ? Das „klassische“ Risikomanagement bietet hier einen sehr brauchbaren Ansatz.

Zwar geht man von einem Projektplan aus, es werden aber mögliche Eventualitäten berücksichtigt und Szenarien dafür vorbereitet. Im obigen Beispiel des Bauunternehmers etwa würde ein Punkt in der Risikoliste lauten: „Plötzlicher Ausfall eines Subunternehmers“. Und angesichts der Schwere des Impacts wären auch Maßnahmen definiert zur Früherkennung, Vermeidung und Schadensminimierung.

Methodisch gibt es sehr ausgereifte Ansätze zum Risikomanagement, die auch nicht allzu aufwändig in der Implementierung sind. Trotzdem beobachte ich in der Praxis, dass das Thema vielfach stiefmütterlich behandelt wird. Entweder wird es als „nicht notwendig“ erachtet oder als „zu teuer“:

Beides zeigt, dass der Mehrwert von Risikomanagement bei Projektleitern und Projektauftraggebern nicht wirklich wahrgenommen wird.

Eine der Ursachen ist, dass häufig das Augenmerk vor allem auf der quantitiativen Risikoanalyse liegt – was kostet der Eintritt eines Risikos und wie wahrscheinlich ist es.Das sinnvoll zu bewerten ist vergleichsweise aufwändig und praktisch nicht immer nützlich.

Praktisch hilfreicher ist es, möglichst viele potenzielle Risiken zu entdecken (Risikoidentifikation). Diese dann zu bewerten (rasche qualitative Einschätzung von Wahrscheinlichkeit und Auswirkung). Und schließlich für die wichtigeren davon Maßnahmen zu planen – sowohl in Hinsicht auf Risikovermeidung oder -reduktion als auch auf Schadensminimierung im Eintrittsfall.

Fokussiert man darauf, läst sich mit gleichem Aufwand wesentlich mehr praktischer Nutzen lukrieren.

Ein Weg, zu prüfen, ob verbessertes Risikomanagement für Ihre Organsation unterm Strich Gewinn bringt, ist die Analyse abgeschlossener Projekte bzw. Lessons Learned.

Welche Abweichungen vom Plan sind aufgetreten ?
Welche davon haben wir vorab zumindest als möglich in Betracht gezogen ?
Waren wir darauf vorbereitet ?
Wenn ja: Was hat uns das gespart ?
Wenn nein: Was hätte es uns gespart, wären wir darauf vorbereitet gewesen ?

Ich freue mich auf Ihre Meinung, Erfahrung oder Widerspruch in einem Kommentar.

Advertisements

„Geheimwaffe“ Projektstrukturplan

Nicht selten taucht in Projekten die Frage auf „Ist X im Projekt enthalten ?“. Meist nicht mal in Frageform, sondern der Gegenüber meint, oft zur Überraschung des Projektleiters „ist X eigentlich schon fertig ?“

Dann beginnt meist eine hektische Suche in Dokumenten und emails, an deren Ende der Streit steht, ob jetzt das mail vom 4.7 gilt oder das Protokoll vom 2.6.

Die Theorie nennt diese schleichende Erweiterung des Projektumfangs „scope creep“ und der saubere Umgang mit Umfang und Inhalt eines Projekts „Scope Management“.

Ein sehr nützliches (Kommunikations-)Werkzeug dafür ist der Projektstrukturplan (PSP, englisch „Workpackage Breakdown Structure“, WBS). Wird in jedem guten Training gelehrt, dennoch sehe ich es in der Praxis nur selten. Auch in meinen eigenen Projekten ernte ich von Kunden und Projektpartnern oft erstaunte Blicke.

Was ist nun ein Projektstrukturplan ?  Nach PMI eine Übersicht über alle Deliverables (Liefer- und Leistungsgegenstände) eines Projekts. (Die IPMA hat hier eine etwas andere Philosophie, aber ich finde den Deliverables-Ansatz sehr hilfreich).

Dargestellt meist als Baumstruktur, in der jede Ebene 100% der Deliverables der darüber liegenden Ebene abdeckt.

 Der abgebildete PSP hat eine geringe Tiefe, die ich oft schon nach dem ersten Durchlesen einer Ausschreibung oder beim Formulieren eines Projektauftrages erreiche.
Mit dem Team gemeinsam weiterentwickelte PSPs haben bis zu 250 Einträge, gelegentlich auch mehr.

Die ideale Ergänzung dazu ist das WBS-Dictionary, ein Dokument, in dem jedes Arbeitspaket beschrieben ist. Erhöht den praktischen Wert deutlich, kommt mir jedoch noch weit seltener unter als das PSP an sich.

Wozu braucht man einen PSP ?
Zunächst wie oben beschrieben, als Kommunikationswerkzeug, wenn es um den Projektinhalt / –umfang geht. Aber auch in der Planung. Zuerst lege ich im WBS fest, was zu tun ist (Deliverables = Projektergebnisse), erst dann geht es ins Zeitplanungstool, in dem die Aktivitäten festgelegt werden, etc.

Auch im Tracking und Reporting ist ein PSP übersichtlich und für alle leicht verständlich.

  • Welche Arbeitspakete wurden bereits begonnen ?  => einmal durchstreichen
  • Welche sind fertig ? => kreuzweise durchstreichen
  • So ist rasch erkennbar, wo das Projekt etwa steht

Wann ist der richtige Zeitpunkt, einen PSP zu erstellen ?
Wenn Sie noch keinen haben: JETZT. Ich selbst beginne den PSP bereits beim Erstellen des Projektauftrages und verfeinere ihn dann laufend weiter.

Und welches Tool ist geeignet ?
Wie immer gibt es eine Vielzahl von Tools – das perfekte ist mir noch nicht untergekommen. Ich arbeite zu Anfang im MindManager, bis der Scope eingermaßen gut definiert ist (weil das Eingeben schneller geht). Wenn der PSP eingermaßen final ist, exportiere ich über den Umweg Microsoft Project das Ergebnis nach „WBSPro“ und verwende es für Tracking und Reporting.

Wenn man gleich in MS-Project beginnt, sind die Gedanken meist schon bei „Wie“, „Wer“, „Wann“, wenn eigentlich das „Was“ noch nicht klar definiert ist. Plan ist dann rasch erstellt, es fehlen aber wichtige Teile.

Generell muss die Struktur im Zeitplan nicht unbedingt dem PSP folgen – es empfiehlt sich aber, eine (manuelle) Spalte PSP-Code einzubauen und die einzelnen Aktivitäten den Deliverables zuzuordnen. So ist sichergestellt, dass bei der Zeitplanung nichts vergessen wird. Die von MS-Project automatisch generierten „PSP-Codes“ sind Unfug, weil für jede Aktivität eine neue Nummer generiert wird – Aktivitäten sind aber nun mal keine Deliverables.

Wichtiger als die Frage nach dem Tool ist allerdings das Vorgehen. Mehr dazu in einem weiteren Posting. Wer nicht warten kann: Hier gibt es ein sehr gutes Whitepaper von Charles Jones (englischsprachig, für Nicht-PMI-Mitglieder fällt ein geringer Betrag an, ist aber gut investiert).

Fazit: Wer noch keinen PSP hat, braucht einen. Von der Entwicklung des Projektauftrags über die Planung zu Steuerung und Reporting. Und wie jedes gute PM-Werkzeug ist es ein Kommunikations-Tool und soll auch als solches verwendet werden.

PJM-Witze (1) – Der Wahrsager

Zwei Männer mit Krawatten hocken auf einem Baum und sägen an dem Ast, auf dem sie sitzen.

Kommt ein Projektmanager auf dem Weg zum Meeting vorbei. Er sieht die beiden und warnt: „Wenn ihr so weiter macht, werden ihr runterfallen.“

„Ach, hör doch auf mit der Schwarzmalerei !“ lautet die Antwort.

Nach einer Stunde kommt er wieder vorbei. Zwei Männer mit Beulen sitzen neben einem abgebrochenen Ast auf dem Boden. Als die den Projektmanager sehen, rufen sie: „Schau mal, der Wahrsager ist wieder da.“

Ähnliche Erfahrungen ? Andere PJM-Witze ? Dann schreib doch einen Kommentar.

Keine Zeit für Planung – was tun ?

Im letzten Posting habe ich das Patentzrezept für einen guten Kostenplan dargestellt.

Was aber tun, wenn ich glaube, „so viel Zeit“ nicht zu haben ?

Oder das Management unbedingt sofort einen „ungefähren Richtwert“ braucht ?

Soweit möglich, sollte man die im letzten Artikel dargestellten Schritte zumindest rudimentär durchführen.

Wenn auch das nicht geht, hier der versprochene „Plan B“:
Disclaimer: Wer glaubt, keine Zeit für gute Planung zu haben, braucht in Summe meist deutlich länger – und deutlich mehr Geld.

Bei Aussagen, die man ohne gute Planung treffen muss, geht es darum, die Unsicherheit einerseits durch Rückfragen wenigstens etwas einzugrenzen und andererseits sichtbar (neudeutsch: transparent) zu machen.

Konkret sieht das so aus:

  • Wenn möglich, nicht sofort antworten, sondern kurz erläutern, dass etwas Zeit doch notwendig ist, um eine auch nur in Größenordnungen plausible Zahl zu bestimmen.
  • Fragen, Fragen, Fragen – die Dinge so konkret wie möglich machen („Soll das System für 2.000 oder 20.000 User ausgelegt sein ?“)
  • Schritte / Phasen des Projekts darstellen
  • Annahmen benennen / darstellen
  • Einflussgrößen erläutern
  • wo möglich, Grobwerte aus der Vergangenheit heranziehen
  • die Berechnung nachvollziehbar machen
  • Bereiche angeben / annehmen (von … bis …) 

Das klingt dann z.B. so: „Eine Webseite mit 3 Mandanten und 20 Seiten pro Mandanten, und einem einfachen CMS-System mit eingebauter Datenbank kann, je nachdem wie gut  die Anforderungen abgestimmt sind, zwischen 3.000 und 25.000 EUR kosten. Um es genauer einschätzen zu können. müsste ich noch X, Y und Z wissen und mich mit N. und M. abstimmen.“

Weitere Tipps zum Umgang mit fordernden Managern und anderen „politischen“ Themen finden sich im Buchtipp „Stopp playing games“.

Wie komme ich zu einem guten Projektkostenplan ?

Für alle, die hier das Patentrezept zum Projektkostenplan erwarten, die gute Nachricht: Genau das ist das Thema des Artikels.

Die schlechte Nachricht: Ein wirklich tragfähiger Projektkostenplan steht eher am Ende einer Kette von (notwendigen) Vorgängen. Und die braucht Zeit.

Noch mehr gute Nachrichten:  Was rauskommt, ist realistisch(er als die Hausnummer, die entsteht, wenn man die Schritte weglässt). Und es gibt einen „Plan B“ für Eilige (der folgt im nächsten Post am Freitag, 7.10.).

Hier das „Patentrezept“ (in Kurzfassung):

  • Erste Äußerung des Projektauftraggebers, dass es ein Projekt geben soll
  • Indentifizierung von Einflussnehmern, Betroffenen, Entscheidungsträgern, kurz: Stakeholder
  • Abholen der Erwartungen der verschiedenen Stakeholder (zu Inhalt und Rahmenbedingungen).
  • Auflösen von eventuellen Widersprüchen, ausformulieren konkreter Ziele und Rahmenbedingungen => abgestimmter Projektauftrag
  • Konkreten Inhalt und Umfang festlegen (Darstellung aller Deliverables im WBS (Workpackage Breakdown Structure))
  • Aktivitäten für das Erstellen der Deliverables definieren
  • Reihenfolge der Aktivitäten festlegen, Ressourcen zuordnen, Aufwände und Durchlaufzeiten schätzen => erster Zeitplan, Kostenplan
  • Plan mit Fachabteilungen / Ausführenden abstimmen
  • Risken indentifizieren, einschätzen und für die wichtigsten Maßnahmen definieren und Puffer einplanen (Zeit, Kosten)
  • JETZT ist der Zeitpunkt da, ein erstes Budget / Projektkostenplan zu erstellen
  • Für Qualität den Prozess iterativ mehrmals durchlaufen

Wichtig: Nicht im stillen Kämmerlein, sondern mit dem (zumindest Kern)Team durchführen. Projektmanagement ist ein People-Business. Was in den dargestellten Schritten passiert, ist Kommunikation.

Wann scheitert ein Projekt

„Wer Großes versucht, ist bewundernswert, auch wenn er fällt“ (Seneca)

Immer wieder liest man von Studien, die belegen sollen, dass ein unglaublich hoher Prozentsatz an Projekten scheitert. Die gängigste Definiton für „scheitern“ ist: Ergebnis nicht oder „nicht in time & budget“ erreicht.

Natürlich verkaufen sich solch alarmierende Studien gut. Und viele der dort dargestellten Beobachtungen und Schlussfolgerungen treffen zu.

Dennoch scheint mir im Blick auf ein einzelnens Projekt eine differenziertere Betrachtung angebracht. Ich schlage folgende Kriterien vor:

  • Projektergebnis (Umfang, Inhalt, Qualität)
  • Dauer
  • Kosten
  • Projektnutzen (gewünschter Zweck des Projekts erfüllt ?)

Für jedes dieser Kriterien lässt sich nun (einzeln) sagen, ob es erreicht, über- oder untererfüllt ist.

Diese Kriterien müssen zusammen mit den Rahmenbedingungen betrachtet werden. So kann ein Projekt später fertig werden als erwartet – die Erwartung war aber von vornherein unrealistisch undcdas Ergebnis nützlich. Umgekehrt ist ein Projekt, das mit einem Viertel der Kosten zeitgerecht und mit vollem Umfang fertiggestellt wird, wahrscheinlich eher ein Beispiel für schlechte Budgetplanung als eine Erfolgsstory.

Selbst ein Projekt, das on time, in budget und in quality fertig wird, kann ein Fehlschlag sein, weil der erwartete Nutzen aufgrund einer Änderung der Rahmenedingungen nicht eintritt.

Die wichtigste Frage, um zu beurteilen, ob ein Projekt „gescheitert“ ist, lautet alerdings: Hätten wir das Projekt auch begonnen, wenn bereits zu Beginn bekannt gewesen wäre, wie das konkrete Ergebnis aussieht, wann und zu welchen Kosten es fertig wird und welchen Nutzen es bringt ?

Die Antwort auf diese Frage lässt so manche Bewertung (positiv oder negativ) in einem neuen Licht erscheinen.

Projektkultur

A “project culture” is about the shared notion of “how we do things around here in the project”.

BasdeBeer bringt in seinem „projectshrink“-Blog eine interesante Definition von „Projektkultur“:

Projektkultur ist die im Meinung des Projektteams, „wie wir die Dinge im Projekt tun“.

Sich dieses “ wie wir die Dinge tun“ immer wieder vor Augen zu führen und in eine wünschenswerte Richtung zu steuern, scheint mir eine der wichtigsten Aufgaben des Projektmanagers.

Fragen dazu können sein:

  • Was treibt uns an ?
  • Wofür wird man im Team respektiert ?
  • Was sind „No No“s ?
  • Was „stimmt“ im Projekt ?
  • Was möchte ich ändern ?

Wie kann ich nun diese Projektkultur beeinflussen ? Kulturen entstehen über Symbole, Tradition sowie Verhalten und Nachahmung – hier kann man ansetzen.

  • Geschichten erzählen statt Aussagen – Die Geschichte vom LKW-Fahrer, der auch bei Blizzard und Schneewehen rausfährt, um die Zeitung zuzustellen inspiriert mehr als die Phrase „zu 100% für unsere Kunden im Einsatz“
  • Symbole schaffen – z.B. eine Schiffsglocke im Teamraum, die bei jedem erreichten Meilenstein geläutet wird
  • Mein eigenes Verhalten – Sollte dem entsprechen, was ich erreichen will. Schreibe ich meine mails so, dass sie für den Empfänger kurz und prägnant sind ? Bin ich pünktlich ? Höre ich zu ?

Welche Geschichten gibt es in Ihrem Projekt ? Lassen Sie uns mittels Kommentar teilhaben.