Schlagwort-Archive: Systemarchetypen

Sollen Muster gebrochen werden?

Das Thema des Barcamps über Projektmanagement, das vom 19. bis am 21. November in Dornbirn stattfindet, lautet „Muster brechen“.

Ein Musterbeispiel

In komplexen Projekten gibt es in der Tat viele Muster. Davon lebt die Komplexität des Projekts. Einige Muster könnten das Projekt verzögern. Folgendes Beispiel soll das illustrieren:

Es wird immer deutlicher, dass die verbleibende Arbeit in der nur noch kurzen Zeit bis zum geplanten und versprochenen Fertigstellungstermin des Projekts nicht bewältigt werden kann. Es ist offensichtlich, dass das Projekt nicht rechtzeitig fertig wird. Was tun?

In Wann kippt ein Projekt und warum? habe ich dargelegt, dass sich für viele vermeintlich fertig gestellte Arbeiten nachträglich herausstellt, dass sie noch Mängel aufweisen und nachgebessert werden müssen. Das nennt sich „Rework Cycle“. Manchmal gibt es explizit eine Qualitätssicherung, die gute Arbeiten durchwinkt und mangelhafte identifiziert. In IT-Projekten übernehmen Tests diese Aufgabe.

Symptomatische versus fundamentale Lösung

Wenn man sieht, dass der gesamte Arbeitsbacklog in der verbleibenden Zeit nicht mehr zu erledigen ist, wäre die symptomatische Lösung, zum Schluss auf die Qualitätssicherung zu verzichten und alle Arbeiten als „definitiv erledigt“ zu deklarieren. Damit könnte das Projekt in der Zeit abgeliefert werden. Allerdings besteht die Gefahr, dass der Kunde beträchtliche Mängel reklamiert, deren nachträgliche Bearbeitung teuer zu stehen käme, ganz zu schweigen von dem Imageverlust.

Demgegenüber steht die fundamentale Lösung, die Qualitätssicherung bis zum Schluss durchzuziehen und das Projekt zu spät abzuliefern, auf die Gefahr hin, Konventionalstrafe bezahlen zu müssen. Diese ist aber berechenbar.

Wir können die Situation so darstellen:

Shifting_the_Burden_Projekt

 

Die blauen Pfeile stellen einen verstärkenden Einfluss dar, die roten einen abschwächenden (1). Das liest sich also so: Je grösser das Problem, dass sich das Projekt verzögert, desto grösser meine Lösungsanstrengung, die QA zu umgehen. Je mehr ich die QA umgehe, desto kleiner wird das Problem, dass sich das Projekt verzögert.

Die symptomatische Lösung entpuppt sich als Sucht

Sollte ich während der symptomatischen Lösung plötzlich „kalte Füsse“ bekommen und mich doch noch für die fundamentale Lösung entscheiden, käme ich in erhebliche Argumentations-schwierigkeiten. Denn erklären Sie einmal dem Kunden kurz vor Projektabschluss, warum vieles von dem, was Sie am Schluss gemacht haben, mangelhaft ist und das Projekt jetzt doch nicht, wie erwartet, fertig wird.

Je mehr ich also von der symptomatischen Lösung Gebrauch mache, desto unglaubwürdiger würden meine Erklärungen, wenn ich mich plötzlich doch für die fundamentale Lösung entscheiden möchte. Das bedeutet, dass die fundamentale Lösung immer mehr abrückt, je mehr und je länger ich den Weg der symptomatischen Lösung begehe. Die symptomatische Lösung wird dadurch zu einer Art „Sucht“, von der man nicht mehr abrücken kann oder wenn, dann nur mit externer Hilfe.

Shifting_the_Burden_Projekt_ganz

 

Brechen des Musters

Dieses Muster wird „Problemverschiebung“ genannt und ist eines von zehn berühmten Mustern, die nach Peter Senge „Systemarchetypen“ genannt werden (2). Zu jedem dieser Muster gibt es eine Durchbrechungsstrategie (3).

Die symptomatische Lösung ist immer der schnelle und bequeme Weg. Im Geschäftsleben wird diese Lösung bevorzugt, weil es meist schnell gehen muss und keine Zeit für fundamentale Lösungen zur Verfügung stehen. Die unsolide Basis der symptomatischen Lösungen holen einem aber meist auf schmerzliche Art ein. Daher sollte sie unbedingt vermieden werden.

Ich bin mir jedoch nicht sicher, ob es in jedem Fall richtig ist, diese Muster zu brechen, in der Meinung, dadurch das Projekt zu beschleunigen. Es könnte auch sein, dass durch das Brechen von irgendwelchen Mustern die Projektkomplexität leidet, was dazu führen würde, dass das Projektziel nicht erreicht wird.

Anmerkungen

(1) Genau genommen sollten wir sagen: die blauen Pfeile sind gleichgerichtet in dem Sinne, dass wenn die Ursache zunimmt, dann auch die Wirkung zunimmt, und wenn die Ursache abnimmt, dann die Wirkung ebenfalls abnimmt. Die roten Pfeile sind gegen-gerichtet in dem Sinne, dass wenn die Ursache zunimmt, dann nimmt die Wirkung ab, und wenn die Ursache abnimmt, dann nimmt die Wirkung zu.
Mit „Ursache“ bezeichne ich hier bloss die Grösse, bei der der Pfeil startet und mit „Wirkung“ bezeichne ich die Grösse, bei der der Pfeil endet. In einem solchen zyklischen Diagramm gibt es aber keine ultimativen Ursachen und Wirkungen.

(2) Die fünfte Disziplin: Kunst und Praxis der lernenden Organisation. Schäffer-Poeschel; 11. Auflage,völlig überarbeitete und aktualisierte Auflage (11. März 2011). ISBN 978-3791029962

(3) http://www.anchor.ch/wissen/Archetypendiagramme.html

(4) Die Figuren wurden mit kumu.io gemacht: https://kumu.io/peteraddor/shifting-burden-project#shifting-burden-project

Unmündigkeit ist ja so bequem!

In Man schlägt den Esel und meint den Sack habe ich ein typisches Migrationsprojekt vorgestellt, das dem Computerhersteller Hewlett-Packard HP mindestens 160 Millionen US-Dollar Verlust verursachte. Kleine unvermeidliche Programmierfehlerchen führten dazu, dass Bestellungen stecken blieben, ohne dass es jemand merkte. Einige der erzürnten Kunden erkundigten sich nach dem Liefertermin. Deren Bestellungen konnten gesucht und nachträglich erfüllt werden. Schlimmer war die Situation mit denjenigen Kunden, die gar nicht erst reklamierten, sondern gleich zu der Konkurrenz – z.B. Dell oder IBM – abwanderten.

Warum sind kleine Programmierfehler unvermeidlich? Weil der Entwickler niemals alle Eventualitäten voraussehen kann, auf die seine Software reagieren muss. Unerwartete Situationen sind unvorhersehbar, andernfalls wären sie nicht unerwartet. In solchen Fällen wird eine Software meistens eine Fehlermeldung ausgeben. Ganz selten – und hier war es der Fall – gibt es keine Fehlermeldung, und die Anwender merken zu spät, dass etwas schief gelaufen ist. Bei der europäischen Trägerrakete Ariane V wurde die Navigationssoftware der Vorgängerrakete Ariane IV angepasst. Dabei wurde eine Kleinigkeit übersehen, was zum Absturz der Rakete führte. In der Software eines Marslandungsgerätes wurde an einer Stelle metrische mit US- Masseinheiten verwechselt, was ebenfalls zum Verlust des Geräts und zum Abbruch der Mission führte.

Der Autor der HP-Fallstudie betont, dass das Risikomanagement in den meisten IT-Projekten Sache des Business und Auftraggebers sein müsse. Stattdessen wird das Risikomanagement einfach auf die IT abgewälzt: „Seht zu, dass Ihr keine Fehler macht!“. Wie wir gesehen haben, können unscheinbare Programmierfehler riesige kommerzielle Konsequenzen haben. Das ist eine Art Schmetterlingseffekt. Das Business schneidet sich also selber ins Fleisch, wenn es die Risikoverantwortung einfach an die IT delegiert.

Die Grafik zeigt die Situation als Systemarchetypus der Problemverschiebung. Es gibt grundsätzlich zwei „Lösungen“, eine symptomatische und eine fundamentale. In unserem Fall ist die symptomatische „Lösung“ die Delegation der Risikoverantwortung an die IT. Was kann sie tun? Sie schickt ihre Leute – Entwickler und Projektmanager – in die Ausbildung und delegiert ihre Verantwortung gerade noch einmal. Immerhin: wenn die Projektmanager ein Zertifikat als „Project Management Professional“ vorweisen können, dann muss doch einfach alles gut gehen….

Wie immer ist der Weg zu der fundamentalen Lösung steiniger und mühsamer, als derjenige zu der symptomatischen. Daher wird dieser bevorzugt. Mit der Delegation der Verantwortung an die IT, entmündigt sich der Auftraggeber selbst, denn je mehr die symptomatische Lösung präferenziert wird, desto unwahrscheinlicher wird es, dass der Auftraggeber die fundamentale Lösung überhaupt versucht. Der Pfeil, der von der „Qualität der Projektführung“ zum „Veranwortungsdruck auf das Business“ führt, verringert letzeren Parameter. Je besser und kompetenter die Projektführung, desto unnötiger erscheint es, dass sich das Business zusätzliche Gedanken zum Risikomanagement macht. Was kann denn bei zertifizierten Projektmanagern noch schief gehen?

Dennoch sollte die fundamentale Lösung begangen werden, nämlich dass der Auftraggeber das Risikomanagement übernimmt.  Wenn ich diese Aufgabe erhielte, würde ich sämtliche Bestellungen, die in das alte Order Entry System (ERP) hinein gegangen sind, in den Produktions- und Speditionsaufträgen suchen. Wenn ich keine eindeutige Zuordnung machen könnte, würde ich die Alarmglocken läuten (siehe die beiden Abbildungen in Man schlägt den Esel und meint den Sack).

Es ist nicht Sache der IT diese Kontrolle durchzuführen, es sei denn, sie erhält einen Auftrag zur Entwicklung einer Software, die Eingänge und Ausgänge vergleicht. Das wäre ein anderes Projekt als das ursprüngliche Migrationsprojekt, welches in seinem Budget solche Kontrollen nicht vorgesehen hat. Zudem muss damit gerechnet werden, dass auch die Vergleichssoftware fehlerbehaftet ist. Daher müssen zusätzliche (menschliche) Kontrolleure eingesetzt werden.

Doch welcher Manager wagte es, solche Entscheidungen zu treffen? Wie oft hört man: „Nur keine schlafenden Hunde wecken“, bis dann einer der Hunde eben doch zubeisst.

7 Schritte im intuitiven Umgang mit Komplexität

Dass Reduzieren und Vereinfachen keine angemessenen Methoden im Umgang mit Komplexität sind, ist mittlerweile ja wohl allenthalben akzeptiert (es gebe aber immer noch Bildungsinstitute, sogar in der Schweiz, die davon noch nichts gehört haben!). Dass die Art und Weise, wie unser Gehirn komplexe Situationen verarbeitet, „Intuition“ genannt wird, erstaunt offenbar immer noch einige Zeitgenossen. Dass aber Intuition Denken nicht ausschliesst, ist wohl noch weitgehend unbekannt. Zur Verwirrung tragen sicher auch Experten bei, die sagen: „Rationales Durchdringen ist keine gute Strategie im Umgang mit Komplexität. Die einzige Strategie, die wirklich greift, ist die Intuition“. Das ist zwar richtig, kann aber falsch verstanden werden. Intuition ist nicht nur auf die regelbasierte Ebene unseres Gehirns beschränkt. Man kann auch intuitiv denken! Peter Senge macht es uns vor1.

Projektleiter wollen nicht einfach schlafwandlerisch-intuitiv durch das komplexe Projekt hindurch stolpern, sondern verlangen nach systemischen Denkwerkzeugen, die die Intuition unterstützen. Das gibt es, nur sind sie schwierig anzuwenden. Wer glaubt, er könne einfach ein paar Zahlen in eine Vestermatrix pressen und bekäme auf bequeme Art – so quasi, ohne zu denken – eine Entscheidungshilfe oder, noch besser, eine Handlungsanweisung heraus, der sucht vergeblich nach Lösungen. Gefragt ist intuitives Denken!

Ich mache das jeweils so:

  1. Erfasse die Situation in einem Kawa oder Kaga von Birkenbihl2. Das ist eine ausgesprochen intuitionsunterstützende Massnahme. Manchmal muss man Schritt 2 vorher machen, manchmal unterstützt eine Kaga die Archetypenbildung.
    Kaga heisst übrigens „kreativ – Analograffiti – grafisch – assoziativ“. Kawa heisst dementsprechend „kreativ – Analograffiti – Wort – assoziativ“.
    Hier ein Beispiel aus einem Projekt, in welchem mir der Gegensatz zwischen immer grösser werdenden Verzögerung und schlechter (Produkte-)Qualität zu schaffen machte. Ein Kaga muss nicht immer derart figürlich sein. Das ist eine Charakterfrage des Zeichners. Ich würde auch lieber nichtfigürliche Grafiken machen. Das sähe „gescheiter“ aus. Aber immer kommen bei mir solche figürlichen Kagas heraus, weil es meiner Intuition entspricht.

    Klicke auf Grafik zum Vergrössern
    Klicke auf Grafik zum Vergrössern
  2. Formuliere die wesentlichen Charakteristiken des komplexen Systems als Senge Archetypen1. Die richtigen zu finden, geschieht intuitiv. Man darf aber nicht starr an Senges Darstellungen kleben, sondern muss seine Archetypen auf die eigene Situation anpassen. Auch das geschieht weitgehend intuitiv.Der Umgang mit den Archetypen will gelernt sein. Die Archetypen mögen mit einfachen Werkzeugen vergleichbar sein. Das richtige Führen eines Stechbeutels oder einer Feile bedarf aber einiger Stunden Trainings.
    Das Abbilden der aktuellen Situation in Archetypen ist eine schwierige und langwierige Angelegenheit. Sie erfordert viel Geduld. Wer meint, schnell, schnell einen Archetypen zu zeichnen und die Parameter zu benennen, der wird enttäuscht.
  3. Wende die „Seven Action Steps“ an, die Bob Braun zu jedem Archetypen entwickelt hat3. Sie sind leider nicht immer Eins-zu-Eins anwendbar, sondern müssen ebenfalls an die aktuelle Situation angepasst werden. Z.B. geht Braun davon aus, dass der Archetypus „Success to Successful“ auf einer Konkurrenzsituation zweier Individuen basiert. Häufig sind es aber zwei Handlungsalternativen, die gegenseitig im Widerstreit stehen (Dilemma). Die eine setzt sich dann plötzlich durch und bindet uns an eine Pfadabhängigkeit. Das muss in den betreffenden „Seven Action Steps“ berücksichtigt werden.
  4. Wenn ein Dilemma besteht, formuliere es als Dilemmawolke von Goldratt4. Gehe nach Goldratts Regeln zum Lösen von Dilemmawolken vor. Dazu müssen die Hypothesen formuliert und hinterfragt werden, die den Pfielen in der Wolke entsprechen. Die „Injections“, die zur Auflösung der Dilemmawolke führen, sind kreative Einfälle, die auf Intuition basieren. Sie kann gefödert werden, indem man den Archetypus aus Schritt 1 „anstarrt“ oder damit herum spielt.
  5. Versuche, die Hypothesen aus Schritt 3 mit den „fünf Warums“ von Rick Ross zu Fall zu bringen 5. Wenn die Hypothese allen fünf Warums standhält, ist das ein Indiz, dass die Hypothese „gut“ ist. Die Anführungszeichen weisen darauf hin, dass die Bewertung intuitiv ist.
  6. Intuitionscheck! Achte darauf, wie Du in Schritt 2 zum Archetypen gekommen bist, wie in Schritt 3 zu der Formulierung neuer „Seven Action Steps“, in Schritt 4 zu den Hypothesen und den „Injections“ und in Schritt 5 zu den Warum-Fragen. Hat irgendwo eine der folgenden Denkfallen ihr Unwesen getrieben?6:
    • Anchoring and Ajustment
    • Verfügbarkeitsheuristik
    • Repräsentativitätsheuristik
    • Frequency Gambling und Similarity Matching
    • Einkapselung
    • Thematisches Vagabundieren
    • Reduktive oder magische Hypothesenbildung und dogmatische Verschanzung
    • Übermässiges Vertrauen und Hang zur Bestätigung
    • Überbewertung des aktuellen Motivs
    • Horizontale oder vertikale Flucht

    Wenn ich mich ertappt habe, dann muss ich die Findings in den Schritten 2-4 korrigieren.

  7. Nachdem ich mich bis dahin „durchgekämpft“ habe, weiss ich sehr viel mehr über die komplexe Situation und würde sie als Senge-Archetypen vielleicht anders formulieren, als ich es am Anfang tat. Daher beginne ich gegebenenfalls wieder mit Schritt 1.

1Peter Senge. Die fünfte Disziplin. Die fünfte Disziplin. Kunst und Praxis der lernenden Organisation. Schäffer-Poeschel Verlag , März 2011
2 Vera F. Birkenbihl. Birkenbihls Denkwerkzeuge: gehirn-gerecht zu mehr Intelligenz und Kreativität. mcg Verlag, Heidelberg 2007
siehe z.B. Kaga zum Thema „Ideen auftauchen“
http://www.analograffiti.ch/index_102_50_kaga_vfb_01.html
3
William Braun. The System Archetypes. http://www.anchor.ch/archetypen.pdf
4
Paul Bayer, Problemdilemma, 2010. http://www.wandelweb.de/blog/?p=870
und Paul Bayer. Efrats Wolke. 2008. http://www.wandelweb.de/blog/?p=91
5
Rick Ross, Die fünf „Warums“ auf S. 125 in Peter Senge et al. Das Fieldbook zur fünften Disziplin. Klett-Cotta Verlag, Stuttgart 2000
und Bella Achmadulina. Fünf „Warums“ 2009. http://www.gedankenteich.de/2009/01/20/funf-warums/
6
Peter Addor. Projektdynamik – Komplexität im Alltag. Liebig Verlag. Frauenfeld 2010. http://www.anchor.ch/Projektdynamik