Schlagwort-Archive: Problemverschiebung

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.

Pfadabhängigkeit im Projektmanagement

Jeff Kight scheint ein Student am MIT zu sein. Er berichtet er, dass Problemlösestrategien oft das Gegenteil bewirken von dem, was man erwartet. Er gibt ein paar Beispiele, z.B. das der Bau paralleler Strassen den Verkehrsfluss nicht beruhige, sondern noch mehr Staus verursache oder dass ein Markt von günstigen Generikas die Gesundheitskosten nicht senke, sondern erhöhe, etc. Das ist das typische „Verschlimmbesserungsmuster“. Kight schreibt:

Jay Forrester, credited as the founder of System Dynamics, spoke to our graduate class at MIT.  He said that 98% of the time people pull the wrong lever in a system when trying to fix a problem1.

Wahrscheinlich fasst das Forresters Worte etwas salopp zusammen. Forrester sagte eher, dass Menschen in 98% der Fälle – und nicht der Zeit –, die falschen Interventionen machen. Wenn man diese Aussage auf Projektsituationen anwendet, dann heisst das, dass 98 von 100 Entscheidungen des Projektmanagers genau das Gegenteil bewirken, von dem, was er eigentlich erreichen wollte! Das können wir kaum glauben. Aber wenn es nur 50 falsche von 100 Entscheidungen wären, dann wäre ein enormes Verbesserungspotential für das Projektmanagement vorhanden.

Es handelt sich eigentlich immer um die Archetypen „Fixes that Fail“ („Verschlimmbesserung“) und „Shifting the Burden“ („Problemverschiebung“) oder einer Kombination davon. Im ersten Fall führen unsere Interventionen kurzfristig zum erwünschten Resultat, bewirken aber langfristig genau das Gegenteil, weil wir unerwünschten Nebenwirkungen keine oder zu wenig Aufmerksam zukommen liessen. Wenn wir sehen, dass ein Nagel heraussteht, dann denken wir sofort an einen Hammer, mit dem wir den Nagel einschlagen. Wir sind dann froh, dass wir eine Lösung für das Problem „hervorstehender Nagel“ gefunden haben und denken nicht weiter über Nebenwirkungen nach.

Im Fall „Shifting the Burden“ wird eine schnelle Lösung des Problems gewählt, die das Problem nur vorübergehend lindert. Die grundlegende Lösung rückt so immer mehr in den Hintergrund. Sie würde das Problem nachhaltig aus der Welt schaffen, aber sie ist teuer und zeitintensiv. Daher wählt sie niemand und wurstelt sich lieber durch.

Die symptomatische Lösung hat Nebenwirkungen, die das Problem verstärken („Fixes that Fail“), während die grundlegende Lösung durch die symptomatische Lösung immer mehr verdrängt wird („Shifting the Burden“). Schliesslich ist man auf dem schlechten Weg gefangen. Das ist genau das Phänomen, welches in der Theorie der Pfadabhängigkeit adressiert wird. Frank Dievernich schreibt in seinem Buch „Pfadabhängigkeit im Management“: Manager oder Mitarbeiter [können] nicht andere Entscheidungen treffen, bzw. diese selbst durch die Entscheidungshistorie gefangen sind…2

1Kight, Jeff. Policy Resistance in our economy. 2009 http://www.examiner.com/x-11746-Fort-Worth-Economic-Policy-Examiner~y2009m5d24-Policy-Resistance-in-our-economy.
Zitiert mit http://www.webcitation.org/5h2APd04k

2Dievernich, Frank E. P. Pfadabhängigkeit im Management. Wie Führungsinstrumente zur Entscheidungs- und Innovationsunfähigkiet des Managements beitragen. Verlag W. Kohlhammer. Stuttgart 2007

Wie räumen Sie ein Haus?

Gestern musste ich bei der Räumung eines leerstehenden Hauses mit anpacken.

  • Die Ausgangslage war: Im Haus stehen eine Menge Gegenstände und Möbel, vor dem Haus eine Mulde.
  • Ziel war: Alles, was jetzt (noch) im Haus ist, muss sich vollständig in der Mulde befinden

Wie macht man so etwas? Nun, man räumt vorerst alles, was in und auf den Möbeln – Schränke, Regale, Tische – ist, weg. Vorzugsweise steckt man dieses Zeugs in Säcke und wirft diese in die Mulde. Auch Blumentöpfe, Lampen, Fussschemel, der ganze Kleinkram wirft man am besten zuerst in die Mulde, bis nur noch die leeren Möbel herumstehen. Diese geben etwas mehr zu tun. Man muss sie zerlegen und einzeln hinunter tragen. Damit sie in der Mulde nicht zu viel Platz weg nehmen, zerschlägt man sie in einzelne Leisten und Bretter. Die Bretter wirft man dann in die Mulde.
Sie kommen nun aber horizontal auf den Kleinkram zu liegen und decken diesen ab, wie ein Tischblatt. Unter den Brettern hat es „beliebig“ viele Leerräume, weil der Kleinkram luftig und sperrig sein kann. Nachdem Sie ein paar Bretter in die Mulde geworfen haben, hat sich diese bereits gefüllt und sie merken, dass es eigentlich schlauer gewesen wäre, die Bretter vertikal entlang einer Muldenwand zu stellen. So hätten sie am wenigsten Platz weg genommen. Also gehen Sie daran, den Muldeninhalt umzuorganisieren. Das ist zeitraubend und gefährlich.

Irgendwie kam mir das bekannt vor. Geht man nicht zuweilen auch in teuren und professionellen Migrations- und Integrationsprojekten so vor? Das hat etwas mit Planung zu tun. Ich habe hier immer wieder darauf hingewiesen, dass man Projekte nicht so planen könne, wie sich das die Literatur des herkömmlichen Projektmanagements vorstellt, weil in einem komplexen Projekt zu viel Unvorhergesehenes passieren kann. Allerdings haben gewisse Planungselemente durchaus ihren Sinn, vor allem, wenn es um die Reihenfolge von Arbeitspaketen geht. Es kann sich in der Tat vorteilhaft auf das Budget- und Zeitmanagement auswirken, wenn der Plan die Tasks in der richtige Reihenfolge vorsieht. Nur ist es manchmal nicht so einfach, im Voraus zu verstehen, welches die richtige Reihenfolge ist. Man lernt es eben erst, indem man das Projekt durchführt. Erinnern Sie sich an den Artikel Komplexität in Projekten, in welchem ich zeigte, dass erst die Beschäftigung mit dem Projektgegenstand (Work in Progress) das relevante Wissen generiert, um die Arbeiten zu planen? Manchmal aber ist die Reihenfolge durchaus evident, und man unterdrückt ihre Planung, weil sie unbequem ist. Man fällt auf den Problemverschiebung-Archetypus herein1.

Shifting_the_Burden_Hausraeumung

Solange es noch Material im Haus hat, trägt man weg, was herumsteht, das leichte (und luftige) Material zuerst. Das ist die symptomatische Lösung des Problems. Dadurch fällt die Dichte des Muldeninhalts und der Füllungsgrad nimmt schnell zu. Die grundsätzliche Lösung des Problems wäre aber, das leichte Material zuerst in ein Zwischenlager zu stellen, das schwere Material – die Möbel – zu zerlegen, die Bretter vertikal in die Mulde zu stellen und zu guter Letzt das leichte Material zu entsorgen. Diese Lösung wird aber verhindert, je mehr leichtes Material wir schon in die Mulde geworfen haben, weil sie schon voll ist, bevor wir alle Bretter entsorgt haben.
Hier sind im Prinzip zwei Projektpläne dargestellt, und dabei wird manifest, wie der eine den anderen verhindert. Das ist der Vorteil eines Causal Link Diagram, das auf Senges Archetypen aufsetzt.

1Senge, Peter. Die fünfte Disziplin – Kunst und Praxis der lernenden Organisation. Schäffer-Pöschel Verlag. Stuttgart, 2008

Im Himmel ist alles viel einfacher

Kürzlich nahm ich an einer Strategiediskussion einer Gruppe von Mitgliedern einer humanitären Organisation teil. Es ging dabei um die Frage, welche humanitären Aktionen man als nächstes in Angriff nehmen wolle. Nachdem sich unterschwellig ein paar Konflikte abzeichneten, lief die Diskussion darauf hinaus, dass man nur noch Ideen sammelte, wem man Geld spenden will. Anstatt zu überlegen, was man mit den eigenen Kräften tun könnte, begann man aufzuzählen, welche notleidenden Zielgruppen es gibt, die die Hilfe nötig haben. Eine solche Aufzählung ist leider sehr einfach, denn die Not in der Welt ist bekanntlich gross. Am Schluss überlegte sich die Gruppe, wem sie grosszügigerweise Geld zukommen lassen will, ob der Schule in einer ärmlichen Region Osteuropas oder Brandopfern in einer hiesigen Universitätsklinik. Es ist natürlich bedeutend angenehmer, in Gedanken Geld zu verteilen, als zu überlegen, was man arbeiten sollte. Schliesslich bestimmte die Gruppe ein Mitglied, das sich bis zum nächsten Treffen Gedanken machen soll, mit welcher konkreten Aktion man das Geld verdienen könnte, das man dann der Zielgruppe zukommen lassen will.

Solche Diskussionen erlebe ich in Projekten und im Management fast täglich. Wenn einer darauf hinweist, dass man thematisch abgleite, wird ihm unwirsch erklärt, dass die Diskussion von Grundfragen der wirklich wichtige Schritt sei. Psychologen nennen diesen Verhalten vertikale Flucht. Stefan Strohschneider schreibt darüber, dass man sich von der Ebene profanen Handelns löst und sich in Gedanken damit beschäftigt, wie es wäre, wenn die Probleme schon gelöst seien. Dazu gehört auch die ständige Entwicklung neuer Zielvorstellungen, gekoppelt mit dem Verschleppen von Terminen, bei denen man sich konkret mit dem in Frage stehenden Problemen auseinander setzen müsste. In einer angenehmen Gruppenatmosphäre wird besonders die Vermeidung von Konflikten wichtig1. Die Gruppe verlegt sich auf die angenehme oder beherrschbare Ebene (hinauf, deshalb vertikale Flucht genannt) und erklärt, dort die eigentlichen Grundfragen des Projekts zu behandeln. Vor allem, wenn die Vergangenheit von Misserfolgen geprägt war, kapselt man sich gerne gegenüber unangenehmen oder schwierigen Fragen ab. Harald Schaub erklärt das Phänomen der Einkapselung so: Handeln in komplexen Realitäten ist für viele Entscheider gekennzeichnet durch ständig neue Probleme und Schwierigkeiten, durch Misserfolge, Pannen und Enttäuschungen. Es ist kaum verwunderlich, wenn in solchen Konstellationen die Tendenz zur Einkapselung in gut beherrschte Realitätsausschnitte zu beobachten ist. Der frustrierte [Projektmanager] sucht seine Aufgaben nicht mehr nach deren Wichtigkeit und Dringlichkeit aus, sondern nach der individuellen Bewältigbarkeit, also nach der Erfolgswahrscheinlichkeit. Er macht das, was er kann und vergisst, was er machen sollte2. Beide Fehler – vertikale Flucht als auch Einkapselung – können als Verschiebung des Problems betrachtet werden. Peter Senge hat 1990 zehn Handlungsarchetypen beschrieben3. Eine davon nannte er Shifting the Burden. Das eingangs erwähnte Problem der humanitären Organisation liesse sich mit dem Shifting-the-Burden-Archetypus wie folgt darstellen:

Ursprünglich wurde eine Aktionsidee gesucht, also eine Grobbeschreibung der Aktion, mit der man notleidenden Menschen helfen will. Die grundsätzliche Lösung wäre also, den Prozess zu planen, mit dem man helfen will. Stattdessen beschreibt man lieber, wem man helfen will. Das ist eine symptomatische Lösung. Die Vorstellung, man hätte das Geld, das man spenden will, bereits verdient und könnte es nun dem Nutzniesser übergeben, ist sehr angenehm. Immerhin weiss man nun, wem man helfen will und braucht nur noch die Kleinigkeit einer Aktionsbeschreibung. Diese delegiert man und schiebt damit die Entscheidung über den eigenen Arbeitseinsatz hinaus. Je mehr man den Endzustand beschreibt, desto glücklicher werden die Diskussionsteilnehmer und umso weniger sehen sie die Notwendigkeit, einen Arbeitsprozess beschreiben zu müssen. Zwar hat man am Schluss des Tages das Gefühl, etwas erreicht zu haben. Die ursprünglich gestellte Aufgabe ist anscheindend gelöst. Spätestens aber, wenn der Delegierte seine Vorschläge vorstellt, beginnt die Diskussion auf’s Neue, diesmal aber viel heftiger.

1Stefan Strohschneider. Kompetenzdynamik und Kompetenzregulation beim Planen. In S. Strohschneider/R. van der Weth (Hrsg). Ja mach nur einen Plan – Pannen und Fehlschläge – Ursachen, Beispiele, Lösungen. S. 35-51. Verlag Hans Huber. Bern 2002

2Harald Schaub. Exception Error“: Über Fehler und deren Ursachen beim Handeln in Unbestimmtheit und Komplexität. In: gdi impuls 4. Gottlieb Duttweiler Institut, Rüschlikon 1996.

3Peter M. Senge. Die Fünfte Disziplin – Kunst und Praxis der lernenden Organisation. Klett-Cotta. Stuttgart 1996.