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

3 Gedanken zu „Sollen Muster gebrochen werden?“

  1. Hallo Peter,

    ich finde, dass das ist eine sehr berechtigte Frage ist!
    Nur weil man ein Muster gebrochen hat, weiß man ja nicht, ob man schon funktionierende alternative Muster gebildet hat.
    -> also handlungsfähig ist.

    Hinzu kommt – Auch wenn wir manche Muster negativ bewerten, so kann es doch sein, dass diese lebenswichtig sind (oder mal waren).

    Viel wichtiger als das Brechen von Mustern, erscheint mir das ERKENNEN von Mustern, der eigenen Beziehung, die man zu ihnen hat und eine Kultur des offenen und lebendigen Umgangs damit.
    Dadurch erzeugt man (glaube ich) nicht nur neue Handlungsmöglichkeiten, sondern fördert das Entstehen weiterer fundamentalistischer Lösungsmöglichkeiten.
    (Statt Gegenwehr zu erzeugen, weil etwas Gewohntes gebrochen werden soll).

    Wo ich grad mal wieder am Schreiben bin…
    Deinen Beitrag „Wann kippt ein Projekt und warum“ fand ich ausgesprochen wertvoll für mich.
    Das Testen und die Anforderungsgenerierung halte ich, neben der Gestaltung einer Kultur, die Verbundenheit ermöglicht, für existentiell in (IT)-Projekten.

    Viele Grüße,
    Bernd

  2. Hallo Bernd

    Freut mich, dass der Artikel über den Kipppunkt in einem System nützlich war.

    Ja, das ist richtig, vielleicht haben auf den ersten Blick auch negative Muster ihre Funktion. Allerdings scheint es mir, dass fundamentale, durchdachte Lösungen zumindest meistens bequemen schnellen Lösungen vorzuziehen sind.

    Wie erkennt man sie: Wie gesagt, indem man die zehn Systemarchetypen von Senge kennt. Wenn Du sie kennst und Dich für ein System (Projekt, Unternehmen, Familie, etc.) überlegst: „Was geht gerade ab?“, dann kannst Du sehr oft und leicht Muster erkennen, die sich auf einen oder mehrere Systemarchetypen abbilden lassen.

    Herzlichst,
    Peter


  3. Allerdings scheint es mir, dass fundamentale, durchdachte Lösungen zumindest meistens bequemen schnellen Lösungen vorzuziehen sind.

    Für mich klingt das, in diesem Kontext, wie ein Beführworten „bewusst“ zu agieren, statt „automatisch“ (oder unbewusst) zu reagieren.

    (Das geht – glaube ich- meist nur, indem man den Automatismus unterbricht und oder sich in die Lage versetzt ihn anzuschauen und im nachhinein zu verstehen.)

    DAS beführworte ich übrigens ebenso!

    (Auch wenn mir natürlich klar ist, dass man mit einer Taschenlampe in der Hand nicht Alles gleichzeitig beleuchten kann -und daher auch nicht immer Alles verstehbar ist – oder einem bewusst sein muss)

    Danke für deinen nochmaligen Hinweis auf Senge und seine wertvolle Arbeit!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.