Schlagwort-Archive: Risikomanagement

Den Teufel „Unsicherheit“ mit dem Beelzebub „Ungewissheit“ austreiben – Risikomanagement revisited

Menschen sind keine Rädchen in einem Getriebe und Entscheider keine Uhrmacher. Soziale und wirtschaftliche Organisationen sind komplexe Systeme, die viel Ungewissheit enthalten. Ein Selbstbild, das eng mit der Fähigkeit zur Kontrolle verbunden ist, ist in solchen Systemen ein ernstzunehmendes Risiko.

Weicht das Gefühl der Sicherheit einer neuen Unsicherheit, weil angenommene Ereignisketten nicht in dem Sinne vollständig sind, dass sie alle denkbaren Möglichkeiten abdecken, ist eine Theorie in Anschlag zu bringen, die auch neue Faktoren in Szenarien einbezieht…..Der Markt schreibt nichts in eine durch Modelle prä-determinierte Richtung nur weiter fort. Er setzt auf Vielfalt und wehrt sich gegen die Standardisierung durch Musterlösungen. Austariert zwischen widergelagerten Interessen, sind Ereignisse mehr oder weniger gelungene Kompromisslösungen. An Fähigkeiten, Möglichkeiten und Umfelder angepasst, müssen Akteure ihre eigenen Strategien [und] Problemlösungen finden1.

Erfahrung und Standardisierung sind im Komplexen schädlich

Risikomanagement auf der Normalverteilung basierend
Risikomanagement auf der Normalverteilung basierend

Viele unselige Ansätze versuchen heute, durch Standardisierung und Zertifizierung von sogenannten Best Practices wieder Sicherheit und Gewissheit in den Alltag zu bringen und Komplexität zu reduzieren. Das ist falsch und fatal. Je mehr auf der Grundlage von Erfahrung standardisiert wird, desto widerspenstiger verhalten sich die Systeme und Organisationen, desto mehr Unerwartetes passiert. Dagegen fährt man im Allgemeinen ein Risikomanagement (RM) auf, das auf dem Paradigma von Wiener Prozess und Normalverteilung aufbaut, obwohl nicht erst seit Nassim Taleb bekannt ist, dass es viel mehr schwarze Schwäne gibt, als die Normalverteilung erlaubt. Schon Aristoteles hat gesagt, dass es wahrscheinlich ist, dass das Unwahrscheinliche geschieht.

Risikomanagement auf der Paretoverteilung basierend
Risikomanagement auf der Paretoverteilung basierend

Es kann sein, was nicht sein darf, ist das Dilemma, das Wahrscheinlich-keitsrechnung ins RM trägt, wenn mit Münzen, Würfeln und Glücks-rädern als Risiken essentialisierende Grössen wie von Geisterhand aus dem schwer handhabbaren Komplexen (Nicht-Lineare) das mathematisch noch handhabbar Komplizierte (Lineare) wird1.

Herkömmliches Risikomanagement adressiert meist technische Aspekte

In Anbetracht der eher mageren Resultate von RM muss man sich zu Recht fragen: reicht das Denken in Wahrscheinlichkeiten noch aus? Das Objekt des herkömmlichen RM klammert den menschlichen Faktor aus und fokussiert auf Eintrittswahrscheinlichkeiten von technischen Ereignissen.

Risikomanagement darf nicht länger ein Abschätzen der Launen der Natur sein, sondern muss intuitiv oder emotional handelnde Subjekte berücksichtigen. Ein Risiko „Das Projekt wird mit 75% Verzögerung einfahren“ ist ziemlich trivial und nichtssagend. Der dazugehörende Contingency Plan „Es wurde eine zusätzliche Ressource eingearbeitet“ ist schon fast peinlich.  Es wäre sinnvoller, den Grund der Verzögerung zu benennen – z.B. gegenläufige Interessen des Kunden und des Lieferanten. Das Projekt verzögert sich vielleicht, weil ein Test ungeplant durchgeführt werden muss und Fehler an den Tag befördert hat, deren Verbesserung länger dauert. Der Test wurde vom Kunden verlangt, nachdem er angesichts der schlechten Qualität das Vertrauen verloren hat. Die Qualität ist schlecht, weil der Entwicklungschef unter Zugszwang stand und das Produkt auf den Markt bringen musste. Das muss alles in die Risikobeurteilung einfliessen. Ein Trivialisieren und unter den Tisch wischen der Fakten hilft da auf die Dauer wenig und ist nicht nachhaltig. Projekte werden immer scheitern, solange das nicht klar ist.

Ausweg: Spieltheorie

Hier bietet sich die Spieltheorie als Systematik zur Beschreibung von Strategie und Vorhersage handelnder und mitdenkender Akteure an.

Dabei erweitert Spieltheorie das simple Modell vom „homo oeconomicus, weil mit Spielern und Spielen die Beziehung zwischen den Teilen und dem Ganzen auf ihrem Grund liegen, wenn Entscheidungssituationen durch Spiele facettenreich abzubilden sind, um sie mathematisch streng zu lösen….Es wird Zeit, die in Spielanalysen vorhandenen Potentiale zu nutzen1.

Es ist nun zu befürchten, dass die meisten Projekt- und andere Manager denken: „Spieltheorie? Nie gehört!“ und treu dem Motto „Not invented here“ zur Tagesordnung übergehen. Aber es lohnt sich, ein wenig in der Spieltheorie zu schökern und zumindest einmal den Wikipedia-Artikel darüber zu lesen. Darüber hinaus habe ich hier verschiedentlich  einführende Artikel geschrieben, z.B. Ist Gier rational? oder Dulden Sie in Projekten keine Hinterlist. Der Artikel Wo würden Sie sich als Eisverkäufer auf der Costa del Sol platzieren geht mit der Spieltheorie schon einen Schritt weiter.

1Volker Bieta. 60 Jahre Spieltheorie – Das Rechnen mit dem Unvorhergesehenen. Jahr unbekannt. Letzter Zugriff Juni 2012

Man schlägt den Sack und meint den Esel

Auch wenn es vielleicht manchmal nicht offensichtlich ist, aber bei all meinen Beiträgen geht es mir um den Praxisbezug. Es gibt zwar nichts Praktischeres, als eine gute Theorie, aber wenn daraus nicht hervor geht, was ein Manager machen muss, um bessere Ergebnisse zu erzielen, dann ist die Theorie noch unausgereift.

Obwohl ich hier schon einmal auf den Artikel When Bad Things Happen to Good Projects1 aufmerksam gemacht habe (Was ist billiger? Ein Mitarbeiter oder eine Zertifizierung? in diesem Blog, 29. September 2009), möchte ich nochmals mit Nachdruck darauf hinweisen. Die Lessons Learned, die man aus diesem Artikel ziehen kann, weisen eindeutig in die richtige Richtung.

Ein typisches Migrationsprojekt

Es handelt sich um eine Fallstudie eines typischen Migrationsprojekts. Nachdem HP einige Unternehmen inklusive ihren Prozessen und IT-Systemen akquiriert hat – z.B. Compaq – sah sie sich vor das Problem gestellt, die verschiedenen IT-Systeme, die dieselbe Funktionen haben, zusammen zu führen. Beispielsweise hat jede Unternehmung ein sog. Order Entry System, also eine IT-Einrichtung, die Bestellungen entgegen nimmt und in Produktions- und Speditionsanweisungen umwandelt. Die Bestellungen geben die Kunden über das Internet (bzw. das Web) direkt in das Order Entry System ein. Kleinere Kunden können ev. auch einen Support Mitarbeiter anrufen und die Bestellung mündlich durchgeben.

Bei HP ist das Order Entry System ein Teilsystem ihres SAP. Einige Unternehmen, die HP akquiriert hat, haben allerdings kein SAP eingesetzt. HP wollte nun alle Order Entry Systeme in ihrem Unternehmen auf SAP konsolidieren.

Umleiten des Outputs des einen Systems in das andere System

Das machte sie in mehreren Etappen und stets auf dieselbe Weise: Der Output eines Order Entry Systems R wurde in das SAP-System umgeleitet. Für das SAP-System waren dann die Bestellungen, die via R herein gekommen sind, gleichbedeutend, wie Bestellungen, die von einem externen Kunden kamen. Haben die Kunden, die via R bestellten, einmal begriffen, dass sie jetzt via das SAP-System bei HP bestellen müssen, kann R abgeschaltet werden.

Dazu müssen die Produktions- und Speditionsanweisungen, die das System R verlassen, in Bestellungen für das SAP-System übersetzt werden. Es braucht also zwischen dem R-System und dem SAP-System ein kleines Stück Software, das diese Übersetzung macht. HP hat diese Übersetzungssoftware für das Order Entry System einer jedem akquirierten Unternehmung geschrieben. Jedes Mal ging das gut und jedes Mal erhöhte sich die Erfahrung von HP für dieses Vorgehen bei der Übernahme einer neuen Unternehmung….bis sie die fremden Order Entry Systeme für das Servergeschäft migrieren wollten. Das Servergeschäft ist der grösste Geschäftszweig von HP.

Der Krug geht zum Brunnen bis er bricht

Die letzte und umfangreichste Migration ging schief! Die Übersetzungssoftware enthielt kleine Fehler, die dazu führten, dass viele Bestellungen im SAP-System stecken blieben und gar nie in die Produktion kamen, bzw. die bestellte Ware gar nie spediert wurde. Kunden beschwerten sich oder – noch schlimmer – wanderten ohne Kommentar ab. Der Schaden betrug 160 Millionen US-Dollar!

HP hat die Übersetzungssoftware auf Herz und Nieren getestet. Dennoch enthielt sie Fehler, denn man konnte nicht alle möglichen Bestellformate voraussehen, die die Kunden anliefern. Es gab Bestellungen, die enthielten unvorhergesehene Elemente oder Zeichen, die die Übersetzungssoftware nicht richtig interpretieren konnte. Das kann man mit den umfangreichsten und sorgfältigsten Tests nicht verhindern.

Lehren

Es gibt viele Lehren, die wir daraus ziehen können, und ich möchte in einem oder zwei Folgebeiträgen auf ein paar Lehren hinweisen, die der Autor des Artikels nicht erwähnt hat. Er betont vor allem, dass das Risikomanagement vom Business wahrgenommen werden muss und nicht auf die IT abgeschoben werden darf. Oft wird nämlich die IT „geschlagen“, obwohl man das Business meint.

Die IT versucht, durch Zertifizierung die Projektmanagement-Fähigkeiten zu erhöhen, was zwar machbar ist, aber offensichtlichs nichts taugt. Gegen die Unvorhersehbarkeit der Bestellformate hilft eben z.B. ein Gantt-Diagramm oder eine Earned Value Analysis nichts. Risikomanagement auf der Businessebene ist hingegen viel schwieriger und unangenehmer, weshalb es gerne auf die IT abgewälzt wird. Das ist der Systemarchetypus der Problemverschiebung, auf den ich im nächsten Beitrag zu sprechen komme.
Schliesslich forderte der Autor bereits 2004, dass man im Projektmanagement endlich vom Kost-Termin-Denken wegkommen sollte. Was nützt einem ein Projekt, dass kosten- und terminmässig erfolgreich abgeschlossen wurde, nachträglich dem Business aber 160 Mio Dollar Verlust bringt? Sagen Sie nicht, dass das Projekt in dem Fall nicht erfolgreich war! Es wurde vom Auftraggeber zufriedenstellend abgenommen, nachdem er sogenannte Akzeptanztests gemacht hatte, denn auch er hatte sich nicht abschliessend vorstellen können, was für Bestellungen eintreffen werden.

1Koch, Christopher. When Bad Things Happen to Good Projects, in CIO.com, 2. April 2007

Projektentropie

Das Hauptübel in turbulenten Projekten ist die Ungewissheit oder Unsicherheit1. Ein Mass für die Ungewissheit ist die Entropie, wie sie von Claude Shannon schon 1948 definiert wurde2. Er lehnte sich an den Begriff der thermodynamischen Entropie an, wie sie 1859 von Rudolf Clausius eingeführt wurde.
Nehmen wir an, wir hätten in unserem Projekt nur gerade ein Risiko R, das mit der Wahrscheinlichkeit p eintrifft und somit mit der Gegenwahrscheinlichkeit 1-p nicht eintrifft. Dann hat das Projekt die Entropie

H(R)=-p·lb(p)-(1-p)·lb(1-p)

lb bezeichnet den Logarithmus zur Basis 2.

Beispiel 1: Die Wahrscheinlichkeit p, dass das Risiko eintritt, sei 0.25. Das ist p=2-2 , also lb(2-2)=-2
Die Gegenwahrscheinlichkeit 1-p beträgt somit 0.75. Das ist 3·2-2 und lb(3·2-2)=lb(3)-2=1.585-2=-0.415

Die Entropie H(R) dieses Risikos schlägt somit mit -0.25·(-2)-0.75·(-0.415)=0.5+0.31=0.81 zu Buche.

Beispiel 2: Die Wahrscheinlichkeit p, dass das Risiko eintritt, sei 0.5. Das ist p=2-1 , also lb(2-1)=-1.
Die Gegenwahrscheinlichkeit 1-p beträgt somit ebenfalls 0.5. Das ist der Fall grösster Unsicherheit. lb(1-p)  ist also ebenfalls -1.

Die Entropie H(R) eines Risikos, von dem man nicht weiss, ob es eher eintrifft oder eher nicht eintrifft, ist demnach -0.5·(-1)-0.5·(-1)=-1.

Beispiel 3: Die Eintretenswahrscheinlichkeit betrage 0.75, das Risiko tritt also mit ziemlicher Wahrscheinlichkeit ein.
Ich überlasse es dem Leser auszurechnen, dass die Entropie in diesem Falle auch 0.81 beträgt.

Bei maximaler Ungewissheit (Wahrscheinlichkeit 0.5) ist die Entropie ebenfalls maximal (hier: 1)

Entropieverteilung H bei einem einzigen unsicheren Ereignis. Wenn es gleichermassen (un)sicher ist, dass das Ereignis eintritt, wie dass es nicht eintritt, ist die Entropie am grössten, nämlich 1

Interessant ist nun folgende Erkenntnis: Was immer Sie zur Verminderung der Eintretenswahrscheinlichkeit eines Risikos unternehmen, Sie vergrössern damit die Ungewissheit (Entropie) im Projekt!

Wenn wir dem Eintritt eines Risikos die Wahrscheinlichkeit q zuordnen und eine Abwehrstrategie bereit legen, die mit der Wahrscheinlichkeit p greift, dann haben wir folgende vier Möglichkeiten, die eintreten können. Eine davon wird ganz sicher eintreten.

Wahrscheinlichkeit pq: Die Abwehrmassnahme greift mit der Wahrscheinlichkeit p und das Risiko trifft dennoch mit der Wahrscheinlichkeit q ein

Wahrscheinlichkeit p(1-q):  Die Abwehrmassnahme greift mit der Wahrscheinlichkeit p und das Risiko trifft mit der Wahrscheinlichkeit (1-q) nicht ein

Wahrscheinlichkeit (1-p)q: Die Abwehrmassnahme versagt mit der Wahrscheinlichkeit 1-p, während das Risiko mit der Wahrscheinlichkeit q eintritt

Wahrscheinlichkeit (1-p)(1-q):  Die Abwehrmassnahme versagt mit der Wahrscheinlichkeit 1-p, aber das Risiko trifft mit der Wahrscheinlichkeit (1-q) dennoch nicht ein

Die Entropie in einem solchen Projekt wäre dann nach der Formel von Shannon:

H(Risk_und_Abwehr)=-pq·lb(pq)-p(1-q)·lb(p(1-q))-(1-p)q·lb((1-p)q)-(1-p)(1-q)·lb((1-p)(1-q))

H(Risk_und_Abwehr)=-pq·lb(p)-pq·lb(q)-p(1-q)·lb(p)-p(1-q)·lb(1-q)-(1-p)q·lb(1-p)-(1-p)q·lb(q)-(1-p)(1-q)·lb(1-p)-(1-p)(1-q)·lb(1-q)

H(Risk_und_Abwehr)=-p·lb(p)·(q+1-q)-q·lb(q)·(p+1-p)-(1-q)·lb(1-q)·(p+1-p)-(1-p)·lb(1-p)·(q+1-q)

H(Risk_und_Abwehr)=-p·lb(p)-(1-p)·lb(1-p)-q·lb(q)-(1-q)·lb(1-q)=H(Abwehr)+H(Risk)>H(Risk))

Das heisst, wenn Sie eine Masssnahme zur Risikoabwehr vorsehen, dann vergrössern Sie die Ungewissheit im Projekt. Eigentlich logisch, aber wer hat sich das schon mal überlegt? Alle gehen immer davon aus, dass Risikoabwehr von jedem Standpunkt aus gesehen eine positive Sache sei.

1Ebeling W et al. Komplexe Strukturen: Entropie und Information. Teubner Verlag. Stuttgart und Leipzig, 1998
2Havil J. Gamma – Eulers Konstante, Primzahlstrände und die Riemannsche Vermutung. Springer. Berlin, 2006

Was kann passieren, wenn Sie sich einen Nagel eintreten?

Die Schwierigkeiten des Projektmanagements ergeben sich aus der zunehmenden Zahl von unvorhergesehenen und unerwarteten Ereignisse, die den Fortschritt des Projekts ernsthaft gefährden. Das bedeutet, dass Risikomanagement praktisch mit Projektmanagement zusammen fällt. Gehen wir noch einmal zurück zum Problem, ein zum Verkauf freigegebenes Haus zu leeren (siehe Wie räumen Sie ein Haus?). Wir können in diesem einfachen „Projekt“ drei Arten von Risiken erkennen:

  1. Man stellt plötzlich fest, dass das Füllen der Mulde falsch oder gar nicht geplant war und sie deshalb mit mehr Luft als Material gefüllt worden ist. Konsequenz: Zeitraubendes und gefährliches Umschichten des Muldeninhalts.
  2. Durch das gewaltsame Zerlegen der Möbel liegen überall Bretter herum, aus denen lange Schrauben und Nägel senkrecht nach oben heraus ragen. Konsequenz: Wenn man darauf tritt, bohrt sich die Schraube durch den Schuh in den Fuss.
  3. Es kann ein unbekanntes und unerwartetes Risiko auftreten, das zur Folge hat, dass gewisse Möbel in das Haus zurück getragen werden müssen (z.B., weil sie in zeitaufwändigen Anstrengungen an bedürftige Leute verschenkt werden sollen).

Das erste Risiko hätte man voraussehen können. Aber nicht derjenige, der entschieden hat, ohne Planung zu beginnen. Möglicherweise ist ihm das Risiko gar nicht bewusst gewesen, dann ist es ebenso unvorhersehbar wie das dritte Risiko. Möglicherweise ging er das Risiko bewusst ein, in der Hoffnung, den Aufwand zu minimieren und damit die Marge zu maximieren. Unter diesen Bedingungen hätte er das Risiko natürlich in allen Riskassessments und Streering Boards verschwiegen. Damit wäre dieses Risiko für alle ausser ihm ebenfalls unvorhersehbar gewesen.

Das zweite Risiko zeigt eindeutig eine Schwäche des üblichen Risikomanagements in Projekten. Man trägt die Eintretenswahrscheinlichkeit gegen den Schweregrad des Schadens bei Eintritt ab. Der Schaden selbst ist aber eventuell ebenfalls eine Zufallsvariable. Die Wahrscheinlichkeit, dass Sie in einen Nagel stehen, beträgt einen Drittel (ich trat mir tatsächlich eine Schraube in den Fuss!). Wenn es aber passiert ist, dann kann der Schaden immer noch sehr unterschiedlich sein und hängt hier ab von dem Zustand der Schraube, Ihrer Widerstandsfähigkeit gegen Tetanus, Eindringtiefe der Schraube, Verfügbarkeit von Desinfektionsmittel, etc. Was genau passiert, ist eine Wahrscheinlichkeitsverteilung über alle möglichen Konsequenzen, von „gar nichts“ bis zur Amputation des Fusses. So wie das Risikomanagement in Projekten angewendet wird, ist es unbrauchbar, weil es die Schwere des Schadens nicht als Zufallsvariable misst.
Risikomanagement auf Grund von Wahrscheinlichkeiten kann zynisch sein. Dass die Titanic in diesen Gewässern auf Eisberge trifft, war äusserst unwahrscheinlich. Zwar gab es eine Warnung, die aber nicht ernst genommen wurde. Das Unglück kam deshalb unerwartet. Die Formel „Erwartungswert des Schadens = Eintretenswahrscheinlichkeit mal Auswirkung“ läuft z.B. auf die Rechnung 0.001 mal 2200 Personen = 2.2 Tote hinaus und das wurde in Kauf genommen. Deshalb waren es dann um die 1500 Tote.

Das dritte Risiko kann überhaupt nicht abschliessend behandelt werden, weil ein unbekanntes Risiko eben unbekannt bleibt, und man damit nicht darüber nachdenken kann. Hier gibt es bloss eine Hoffnung: Mittels formaler Modelle kontraintuitive Zusammenhänge aufdecken, die auf verborgene Risiken Hinweise geben. Die Modelle können Agent Based, System Dynamics oder spieltheoretischer Natur sein. Dabei ist nicht einmal so sehr die Analyse des Modells massgebend, sondern sein Design. Das Finden der Variablen in einem System Dynamics Modell oder das Finden des geeigneten Spiels macht es vielleicht aus, dass verborgene Risiken an den Tag treten. Volker Bieta et al. behaupten, dass nur ein auf Spieltheorie fussendes Risikomanagement für offene, hochgradig komplexe und nicht-lineare Systeme angepasst ist1.

1Biete, Volker / Kirchhoff, Johannes / Milde, Hellmuth / Siebe, Wilfried. Szenarienplanung im Risikomanagement – Mit der Spieltheorie die Risiken der Zukunft erfolgreich steuern. Wiley-VCH Verlag. Weinheim 2004

An den Schalthebeln des Projektmanagements

Lassen sich Turbulenzen in Migrations- und Intergrationsprojekten (MIP) über die im Eintrag Wann sind Projekte instabil? vom 3. August 2008 genannten Faktoren tatsächlich mindern? Natürlich nicht, denn der Projektmanager kann keinen der Faktoren beeinflusst. Es sind keine Hebel des Projektleiters, sondern reine Randbedingungen des Projekts. Sie beschreiben das Projektumfeld, das der Projektleiter hinzunehmen und in die Planung einzubeziehen hat. Achten Sie bei der Planung Ihrer Projekte auf solche Randbedingungen? Fiel Ihre Planung bisher tatsächlich anders aus, wenn im Projekt z.B. Personen aus drei verschiedenen Nationen mitarbeiteten, als wenn alle demselben Sprachraum zugehören, in welchem das Projekt durchgeführt wird?

Was sind Hebel?

Hebel sind Projektparameter, die Sie als Projektmanager aktiv beeinflussen können. Zwar nicht immer mit Erfolg, das gebe ich zu, aber Sie können in jedem Fall Einfluss nehmen. Der Faktor von Nittbaur und Ernst, auf den ich im Nachtrag noch aufmerksam machte, ist ein solcher Hebel. Es liegt im Ermessen des Projektleiters, ob er ein Kickoff machen will und wen er dazu einlädt. Selbstverständlich können Sie darüber diskutieren, ob viele Teilnehmer förderlich oder kontraproduktiv sind. Selbstverständlich könnten Sie auch von allen Eingeladenen Absagen erhalten, so dass das Kickoff in’s Wasser fällt. Aber Sie können etwas tun.

Welche Resultate soll das Projekt ergeben?

Schreiben Sie einmal auf, welche Resultate oder Zielsetzungen Sie in Ihrem Projekt erreichen müssen und wie der aktuelle Stand eines jeden Resultats ist. Klar, da sind einmal die drei Resultate des magischen Dreiecks, oft auch als magisches Viereck dargestellt, nämlich

  • Termintreue
  • Kostentreue
  • Optimale Qualität
  • Ablieferung und Installation der geforderten Inhalte

Zusätzliche Resultate können sein:

  • Kundenzufriedenheit
  • Vertrauensbildung beim Kunden in das Lieferunternehmen und seine Produkte
  • Befriedigung der Interessen aller Stakeholders

Welche Hebel haben Sie?

Und jetzt machen Sie eine Liste aller Hebel, die Ihnen zur Verfügung stehen, also all derjenigen Faktoren, die Sie als Projektmanager direkt beeinflussen und regeln können. Schreiben Sie auch dazu, welche Ist- und welche Soll-Einstellung die einzelnen Hebel gerade haben. Ich weiss, das ist gar nicht so einfach, wie man zunächst glaubt. Aber überlegen Sie, welche Mitigations Sie bei erkannten Risiken angeben. Dort finden Sie Ihre Hebel. Sie werden schnell einsehen, dass es in MIP gar nicht so viele Faktoren gibt, auf die Sie wesentlichen Einfluss nehmen können. Diese Tatsache lässt alle gut gemeinten Ratschläge für ein aktives Projektmanagement hinter sich. Die Liste kann für Entwicklungsprojekte lang sein, aber in MIP gibt es weniger Hebel. Beispiele für Hebel können sein:

  • Durchführungsentscheid Kickoffmeeting
  • Teilnehmerzahl Kickoffmeeting
  • Aktualität des Projektplans
  • Detailreichtum des Projektplans
  • Zeitpunkt für das Vorlegen eines Projektplans
  • Häufigkeit von Projektmeetings
  • Teilnehmer an den Meetings
  • Zeitpunkt und Inhalt von Eskalationen
  • Insistierungsgrad bezgl. Ressourcen (wer am lautesten bellt, erhält den grössten Knochen)
  • Beantwortungspolitik von Change Requests

etc. etc. (Schreiben Sie weitere in Kommentare zu diesem Eintrag!)
Was fällt Ihnen auf, wenn Sie die beiden Listen vergleichen? Kein Resultat erscheint auf der Liste der Hebel und kein Hebel ist ein Resultat. Schlimmer noch: Die Hebel sind nur indirekt und oft über mehrere Ecken mit den Resultaten verbunden1. Mit anderen Worten: Sie können die Ereignisse überhaupt nicht direkt beeinflussen. Wenn Sie 10 Projektmeetings machen, kann das die Kundenzufriedenheit vielleicht fördern, aber es könnte ihr auch abträglich sein.

Wie finden Sie Hebel?

Sie erinnern sich an das Grundmodell von Migrations- und Integrationsprojekten? Siehe Komplexität im Projektmanagement. Dort hatten wir den Feedbackloop

anatomie_mip

Tasks to do liegt in Form einer Issuelist vor. Sie beeinflusst direkt die Termintreue, während von Work in Progress ein direkter Pfeil zu den totalen Projektkosten führt. Welche Hebel Sie für das Wissen haben, zeigte ich in Investieren Sie in Expertenwissen. Jetzt wollen wir dasselbe Schema des Growth and Underinvestment Archetypus anwenden, um einen Hebel für die Issuelist zu finden. Ist das Projekt längst überfällig, mag der Kunde toleranter gegenüber kosmetischer Mängel sein. Er ist qualitätstoleranter, was sich derart auswirkt, dass er nicht mehr gleich für jeden Schönheitsfehler des Produkts oder des Services einen Issue auf die Liste setzt. Das heisst, je grösser die Qualitätstoleranz, desto kleiner die Issuelist.
Ist der Endtermin des Projekts längst überschritten, kann das der Projektmanager des Lieferanten eskalieren. Dies ist sein Hebel! Dadurch erreicht er vielleicht, dass das Management die Notwendigkeit wahrnimmt, mehr Ressourcen aufzubauen, so dass das Projekt schliesslich doch noch fertig gestellt werden kann. Das Gesetz von Brooks gilt bei MIP nicht zwingend (Brooks‘ Gesetz: „Adding manpower to a late software project makes it later“2). Unsere Feedbacks sehen nun so aus:

termintreue

Der Kreis R ist schlecht für die Termintreue. Sie würde zwar durch den Kreis B1 eingedämmt, aber leider erst, nachdem das Projekt bereits aus dem Ruder gelaufen ist. Mit dem Kreis B2 hingegen, könnte der Termin gehalten werden, wenn er von Anfang an greifen würde. Allerdings besteht eine beträchtliche Verzögerung zwischen der Allokation von Ressourcen und ihren effektiven Auswirkungen auf die terminlichen Belangen. Der einzige Hebel in diesem Zusammenhang ist die Eskalation. Das zeigt, dass der Projektmanager mit der Eskalation nicht zu lange warten sollte. Meistens zögern Projektmanager, zu eskalieren oder denken, dass sie den Dingen noch ein wenig zuschauen wollen. Das ist ein Fehler.

1Denis Sherwood. Den Wald vor lauter Bäumen sehen – Reduktion von Komplexität – Anleitung zum systemischen Denken im Management. Wiley VCH Verlag. Weinheim 2003.
(Leider spricht auch Sherwood von Komplexitätsreduktion. Aber ich glaube, das ist bloss eine Verkaufstrick. Er soll dem potentiellen Käufer, der nicht weiss, was Komplexität ist, ein beruhigendes Gefühl geben)
2Frederick P. Brooks. Vom Mythos des Mann-Monats : Essays über Software-Engineering. Mitp-Verlag. Bonn 2003