Kategorie-Archiv: Projektmanagement

Fehler machen – gewusst wie!

borgertDieser Beitrag ist etwas ganz Besonderes. Es ist nämlich ein Gastbeitrag von niemand geringerem als Stephanie Borgert, die bekannte Erfolgsautorin mehrere Bestseller zum Themenkreis „Komplexität“.  Ihr neustes Buch „Die Irrtümer der Komplexität“ habe ich hier rezensiert.

komplexitaetIm folgenden Artikel sinniert Stephanie Borgert über neuguineanische Schweine in den Gärten der Nachbarn und was das mit dem Anspruch zu tun hat, dass alles fehlerfrei und definitiv sein muss.

Vielen Dank, Stephanie!


Das „Agieren in nicht vorhersagbaren Kontexten“ ist die Herausforderung für Manager. Täglich erscheinen Artikel mit den Schlagwörtern „experimentieren“, „Fehlermachen“, „scheitern“ und sie proklamieren deren Bedeutung. So weit, so gut. In einem komplexen Umfeld treffen Manager Entscheidungen auf der Basis von Experimentieren (Ausprobieren) und Muster erkennen. Dabei werden Fehler (also nicht erwünschte Ergebnisse) entstehen und das führt möglicherweise zum Scheitern.

Wird das Thema aufgegriffen, werden meistens Beispiele von Insolvenzen, „totalem“ Scheitern und einem dramatischen Untergang bemüht. Das ist zwar anschaulich und eindrücklich, aber auch irreführend. Denn meistens bewegen wir uns als Individuen genauso wie jede Organisation auf der vielfältigen Achse zwischen „makellos erfolgreich“ und „total in die Hose gegangen“. Gleichzeitig gehen die Artikel nie in die Tiefe. Da es konzeptionell große Unterschiede im Fehlermachen beziehungsweise -vermeiden gibt, ist das aber dringend notwendig.

Fail-safe oder Safe-fail

Ganz offensichtlich ist es von Vorteil, wenn in einem Kernkraftwerk durch mehrere Stromkreise sichergestellt ist, dass bei einem Stromausfall die Energieversorgung weiter gewährleistet ist. Umfangreiche technische Konstrukte arbeiten berechtigterweise mit diesem Fail-safe-Prinzip, bei dem Redundanzen auf der Basis errechneter Wahrscheinlichkeiten geschaffen werden. Leider wird dieses Prinzip oft eins zu eins auf Organisationen übertragen. Egal ob Produktionsprozess oder Projektmanagement, die Systeme werden robust, narren- und ausfallsicher aufgesetzt. Mit dem Ziel, der (möglichst) vollständigen Fehlervermeidung wird alles Erdenkliche unternommen, um deren Wahrscheinlichkeit zu reduzieren. Das führt zu dem Ergebnis, dass die Menschen sich so verhalten, als läge die Wahrscheinlichkeit bei null Prozent. Welch ein Denkfehler in komplexen Kontexten!

failsafeDadurch beschränkt sich auch das Experimentieren auf die Trial-and-Error-Methode. Bei einem neuen Produkt heißt das beispielsweise, es wird erst gelauncht, wenn es fertig ist und alle sicher sind, dass es erfolgreich sein wird. Diese Sicherheit ist aber ein Irrglaube, denn eine Garantie gibt es am Markt nie. Bleibt der Erfolg aus, wird das nächste Produkt platziert. Eins nach dem anderen, Trial-and-Error eben. Der Preis für diese Art des Managements ist hoch, die Währung Flexibilität, Schnelligkeit und Anpassungsfähigkeit.

Von Gärten und Schweinen

Ein alternativer Ansatz zur Schadensvermeidung ist die Schadensbegrenzung. Das Safe-fail-Prinzip unterstellt, dass Fehler passieren und nicht zu vermeiden sind. Experimentieren heißt in dem Fall, tatsächlich Fehler zu machen und zu scheitern. Ohne das lassen sich die Grenzen des Machbaren nicht ausloten. Systemisch bedeutet, „an Grenzen zu stoßen“, das System zu regulieren. Der kanadische Ökologe Buzz Holling erläuterte das Prinzip an dem Ritual einer Bevölkerungsgruppe Neuguineas: Die Menschen dort bauen einen Großteil ihrer Nahrung selbst an und zwar in ihren eigenen Gärten. Schweinefleisch ist dort ebenfalls ein wichtiges Lebensmittel, wird jedoch nur zu einem bestimmten zeremoniellen Anlass gegessen. Diese Zeremonie findet immer statt, wenn die „Betriebstemperatur“ hoch ist und Konflikte aufkeimen. Dann werden die Schweine verzehrt und die Götter um Versöhnung gebeten. Der wesentliche Grund für die Konflikte ist die hohe Schweinepopulation. Sie beginnen die Gärten zu verwüsten und das provoziert Streit unter den Nachbarn. Nach der Zeremonie ist der Streit ausgeräumt. Dabei dient das Ritual weniger dazu, die Schweinepopulation zu kontrollieren, sondern die Bevölkerung vor unkontrollierter Instabilität durch Konflikte zu bewahren.

schweinWäre das Zusammenleben dieser Menschengruppe in Neuguinea durch Prozesse, Verfahren und Richtlinien aus unseren Organisationen geregelt, so wäre sicher zuerst die Anzahl an Schweinen pro Familie definiert und festgelegt. Die Schweinepopulation könnte also insgesamt einen gewissen Schwellwert nicht überschreiten. Wenn gleichzeitig durch den Bau von Zäunen und der Regel die Einhaltung von „Schweine dürfen keine fremden Gärten betreten“ der Bewegungsradius geklärt ist, kann nichts mehr schiefgehen. Zur Feier der entstandenen Schadensvermeidung gäbe es halbjährlich eventuell eine Zeremonie, auch wenn dafür gar kein Anlass mehr existiert. Es wäre der übliche Versuch, ein komplexes System zu steuern und Fehler zu vermeiden.

Der kontrollierte Ausfall

In Neuguinea hat die Gruppe dagegen eine Methode gefunden, kontrollierte Ausfälle zu generieren. Die anschwellenden Konflikte unter den Nachbarn sind das sichere Signal, dass das System eine Korrektur benötigt. Die Zeremonie dient genau dieser Korrektur. Das System ist also nicht überreguliert (wie die meisten Organisationen), sondern selbstorganisiert. Einige, wenige Restriktionen regeln „wie diese Bevölkerungsgruppe tickt“. Die Menschen dort lassen also das System bis an seine Grenzen laufen, Fehler entstehen. Die sind der Anlass für eine Korrektur, finales Scheitern wird so verhindert. Die Flexibilität der Gesellschaft bleibt erhalten.

Was bedeutet das nun für Organisationen? Für die Antwort möchte ich ein Beispiel vorstellen, denn ein generelles Rezept existiert nicht. Komplexität ist immer Kontext, aber es existieren einige Inspirationen, von denen sich lernen lässt.

googleGoogle ist hier, wie so oft, eines der guten Beispiele. Als ein Meister der Safe-fail-Experimente bringt das Unternehmen laufend zahllose Produkte und Dienstleistungen auf den Markt. Angefangen von Dodgeball über Jaiku, Wave, Google Catalogs oder Mashup Editor. Die meisten dieser und vieler anderer Produkte sind unbekannt. Sie sind fehlgeschlagene Experimente. Es ist eine wesentliche Eigenschaft von Google, dass es die Fähigkeit zum Fehlermachen und aus ihnen zu lernen besitzt. Projekte werden beendet, sobald sie als Misserfolg bewertet werden. Scheitern ist ein wichtiger Teil des Erfolgskonzeptes. Fehler machen – gewusst wie:

  • Probiere viele Dinge aus.
  • Gehe davon aus, dass einige fehlschlagen.
  • Begrenze die Kosten des möglichen Fehlschlages.
  • Gestehe Fehler und ein Scheitern frühzeitig ein.

Hinter diesen vier Punkten steckt mehr als „sich einfach mal ein Experiment ausdenken“. Es geht um Haltungen und Sichtweisen im Management einer Organisation. Für das Meistern von Komplexität ist der „richtige“ Umgang mit Experimenten, Fehlern und Scheitern essentiell.

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

Projekte sind soziotechnische Systeme und erfordern Rationalität

Das diesjährige PMCamp Berlin, das vom 10. bis am 12. September stattfindet, steht unter dem Thema „Komplexität“. Für mich ist Komplexität eine Voraussetzung eines Systems, damit es seine Funktion erfüllen kann. So benötigt ein Projektsystem eine gewisse Komplexität, um das Projektziel zu erreichen. Würde man die Komplexität des Projekts reduzieren, könnte es das Ziel nicht mehr erreichen.

Aspekte soziotechnischer Systeme

Turbulent kann ein Projekt sein, weil seine Gegebenheiten ständig ändern (Dynamik) oder weil es sich anders entwickelt, als wir erwartet haben (Ungewissheit). Menschen, die in solchen Systemen entscheiden müssen, neigen dabei zu folgendem Verhalten:

  • Denken in linearen Ursache-Wirkungsketten
  • Nichtbeachtung von verzögertem Feedback
  • Hypothesenbildung aufgrund vermeintlicher Korrelation
  • Fehleinschätzung exponentieller Entwicklungen und von Wahrscheinlichkeiten

Ursache-Wirkungsketten

Passiert etwas Unvorhergesehenes, fragen wir sofort, wie das passieren konnte. Wir wollen die Ursache wissen, in der Meinung, man müsse bloss diese Ursache entfernen, damit die ungewünschte Wirkung nicht wieder auftritt. Das ist eine irrige Vorstellung. Bekannt ist das Ehepaar von Paul Watzlawick: Er geht ins Wirtshaus, weil er vor seiner nörgelnden Frau flüchtet, während sie ihm Vorwürfe macht, weil er ständig im Wirtshaus ist.

Den linearen Ursache-Wirkungsketten stehen die System-Archetypen gegenüber, die viele Projektsituationen als Ursache-Wirkungszyklen modellieren.

Verzögerter Feedback

Fast jede Handlung bewirkt nicht nur, was sie beabsichtigt, sondern hat darüber hinaus (unbeabsichtigte) Neben- und Fernwirkungen. Speziell Projekte werden oft von Entscheidungen eingeholt, die eigentlich schon lange erledigt waren.

Haben Sie gewusst, dass es verzögerter Feedback erster, zweiter und höherer Ordnung gibt? Kennen Sie den Unterschied? Sollten Sie, wenn Sie durch turbulente Projekte navigieren wollen.

Nichtlineare Entwicklungen und Wahrscheinlichkeiten

Hier sehen Sie eine Grafik der Weltbevölkerung zwischen 1000 v. Chr. und 1800 n. Chr., ohne Angabe der Grössenordnung.  So etwas kommt in Projekten oft vor, z.B. im Zusammenhang mit der Anzahl Change Requests oder Test Failures. Setzen Sie die Kurve bis ins Jahr 2000 fort! Die meisten Personen bleiben mit ihren Schätzungen bis zum Faktor 3 hinter dem tatsächlichen Betrag zurück.

Weltbevoelkerung_blind

David Kahneman hat verschiedentlich darauf hingewiesen, wie schlecht wir im Einschätzen von Wahrscheinlichkeiten abschneiden. Welches Spiel würden Sie lieber spielen, wenn Sie es wiederholt spielen könnten?

Sie erhalten acht Franken mit einer Wahrscheinlichkeit von 1/3

Sie erhalten drei Franken mit einer Wahrscheinlichkeit von 5/6

Die meisten Versuchspersonen entscheiden sich für das zweite Spiel, weil es anscheinend einen sichereren Gewinn verspricht. Aber im ersten Spiel haben Sie auf die Dauer mehr gewonnen.

Vermeintliche Korrelation

Nehmen wir an, in einem Projekt verhalten sich zwei Grössen auffällig ähnlich, z.B. so:

korrelation_blind

Der Korrelationskoeffizient beträgt 0.9926. Wir neigen in diesem Fall schnell dazu zu vermuten, dass die beiden Grössen etwas miteinander zu tun haben. Diese Hypothese über das Funktionieren des Projekts dient uns dann als Grundlage für unsere Entscheidungen.

Das obige Beispiel stammt aus dem neuen Buch „Spurious Correlations“ von Tyler Vigen. Die beiden Kurven geben übrigens die Entwicklung der pro Kopf Konsumation von Margarine einerseits und der Scheidungsrate im amerikanischen Maine andererseits zwischen 2002 und 2009 wieder.

Wir neigen in der Tat dazu, Zusammenhänge zu vermuten, wo gar keine sind.

Systemische Darstellungsmittel müssen nicht zwingend „komplex“ sein

Beschränkungen menschlicher Kognition manifestieren sich gerade bei ganzheitlichen Wahrnehmungsautomatismen. In komplexen Projektsystemen ist jedoch genügend Zeit, darüber bewusst zu reflektieren. Dabei kann die Ganzheitlichkeit auf der Strecke bleiben. Rationale Reflektion findet in geeigneten Modellen statt und bedarf systemischer Darstellungsmittel, um den Zusammenhang zur Ganzheitlichkeit nicht zu verlieren. Erkenntnisse aus dem Reflektionsprozess müssen nachträglich durch Achtsamkeitsübungen wieder in die Gesamtsicht eingepflegt werden.

In „Projektdynamik – Modelle für komplexe Umgebungen“ stelle ich die geeignetsten Darstellungsmittel vor. Das Buch kann frei heruntergeladen werden.

Auf Seiten 184ff erkläre ich den Umgang mit der Zeit und was es mit verzögertem Feedback auf sich hat. Ab Seite 202 folgt ein Tutorial zu nichtlinearen Entwicklungen und Wahrscheinlichkeiten. Auf den Seiten 219 bis 234 führe ich in die Verwendung von Causal Loop und Stock-and-Flow-Diagrams ein. Und auf Seiten 235ff zeige ich die kognitive Kraft von Modellen.

Der Verstand kann Defekte der unbewussten Kognition ausgleichen

In „Gestaltungsansätze für Soziotechnische Systeme“ (2005) stellen die Autoren eine Methodenhierarchie auf. Die mathematischen Ansätze des Operations Research werden auf „naturwissenschaftliches Denken“ reduziert, das soziotechnische Systeme nicht voll erfassen könne. Auch mit der nächst höheren Stufe, der Systemanalyse, sei

die Analyse komplexer Systeme … nur begrenzt möglich

Die Autoren schreiben:

Zur effizienten Bewältigung der Analyse und Gestaltung von soziotechnischen Systemen sind darüber hinaus Methoden und Werkzeuge erforderlich

und stellen dann Systeme, wie ERP, Datenmanagementsysteme, Managementinformationssysteme, Systeme des Wissensmanagement, Workflowsysteme, etc. vor, ohne sich Rechenschaft abzugeben, dass diese Systeme gerade auf den eingangs erwähnten Konzepten des Operations Research basieren.

Gewiss, der Artikel ist zehnjährig. Er drückt aber eine Haltung aus, die leider nach wie vor dominiert: da zum Verständnis quantitativer Methoden beträchtliche Denkleistungen erforderlich sind, werden sie als zweitrangig und ungenügend abgetan. Damit hat man eine Entschuldigung, sich nicht damit befassen zu müssen und weiterhin rein intuitiv vorgehen zu können. Aber damit kommt man in komplexen soziotechnischen Systemen nicht weit.

Können kleine Systeme komplex sein?

Komplexität ist eine Eigenschaft, die einer Systemstruktur zugeordnet ist (1). Die heutige Welt ist insofern komplexer als vor 50 Jahren, weil hauptsächlich Verkehrs- und Informationstechnologien neue globale Netzwerke ermöglicht und verursacht haben.

Verschiedene Kategorien

Das Zustandekommen von Komplexität ist im Allgemeinen ein Massenphänomen. Beispielsweise ist die Struktur einer Stadt komplex und kommt durch das Zusammenspiel von Hundertausenden von Menschen zustande. Städtebauliche Massnahmen und Gesetze tragen allenfalls dazu bei, dass die Entwicklung kompliziert wird und nicht so sehr zur eigentlichen Komplexität.

Dieses Nebeneinander von Kompliziertheit und Komplexität verleitet oft dazu, beide Kategorien in Verbindung zu bringen. Das wohl bekannteste Beispiel ist das Cynefin-Framework. So, wie es meist dargestellt wird, stellt es unglücklicherweise „kompliziert“ und „komplex“ nebeneinander, als wäre ein System entweder kompliziert oder komplex. Die beiden Kategorien korrelieren etwas so viel miteinander, wie die Inhalte des Hubraums und des Gepäckraums eines Autos.

Dave Snowden hat in sieben Blogbeiträgen geschrieben, wie er zum Cynefin-Model kam. Ausgehend von Max Boisots Information-Space, hat er zunächst ein Modell des Wissensmanagements und des Lernens gesucht. Boisots I-Space hat drei Dimensionen und zeigt den Weg von Wissen bei sozialem Lernen.

I-SpaceDie Entwicklung vom I-Space zum Cynefin-Framework kann ich im I-Space selbst nachvollziehen. Snowdens erstes Modell hatte die Dimensionen „Abstraktion“ und „Kultur“. Danach setzte sich das Vierfeldermodell mit „kompliziert“ und „komplex“ durch, war aber noch mit einer Metapher angereichert, die der Katastrophentheorie von René Thom entstammte(4). Damit das Modell aber verständlich blieb, durchlief es die „Diversity Reducing Phase“ und wird mittlerweile als ordentliches, starr kodiertes Bildchen in jeder Lebenslage präsentiert. Ich vermute, dass das nicht in Snowdens Sinn ist. Er schreibt in The Origins of Cynefin – Part 1:

Far too may people read up on something quickly and use the language without real real understanding

Projektkomplexität

Es stellt sich die Frage, ob auch ein „kleines“ System Komplexität aufweisen kann. Projekte sind Beispiele von „kleinen“ Systemen. Das sind Systeme, die aus Dutzenden bis höchstens ein paar Tausend Subsystemen bestehen. In einem Projekt gibt es meist ein paar Dutzend bis ein paar Hundert Stakeholder. Es ist ein kleines System. Ist es zur Komplexität fähig? Kann bereits Selbstorganisation entstehen? (2) Und da erinnere ich mich an Tierschwärme, die durchaus Selbstorganisation aufweisen. Es brauchen nicht einmal Herden zu sein, die aus über 100‘000 Individuen bestehen. Schon in relativ kleinen Vogelschwärmen können Strukturen emergieren. Als Beispiel habe ich einen Taubenschwarm aufgenommen, der regelmässig „Flugtraining“ absolviert. Es gibt vermutlich keinen „Führer“. Eine spontane Richtungsänderung wird weder vereinbart noch befohlen, sondern kommt per Selbstorganisation zustande. Die Tiere fliegen auch nicht schön geordnet und parallel zueinander, wie Soldaten bei der Zugschule. Es gibt durchaus Querflieger und Ausreisser.

Beachten Sie die Unsicherheit nach der ersten Runde und vor der abrupten Richtungsänderung!


Das ist ein Beispiel für eine Projektkomplexität (für die Vögel ist es ein Projekt), wie sie sich bereits in einer kleinen Gruppe bildet. Landet der Schwarm, ist das Projekt beendet und die Komplexität verschwunden. Nur die Umwelt konserviert die Komplexität unter Umständen. Das Projekt hinterlässt Strukturen, z.B. ein Haus oder ein entwickeltes Digitalprodukt. Es ist die vornehmste Aufgabe eines Projekts, die Komplexität der Welt ein wenig zu erhöhen.

Anmerkungen:

(1) Ich weiss, dass es viele Definitionen von Komplexität gibt und fast jedes Individuum seine eigene Meinung darüber hat. Sie dürfen mir also gerne widersprechen. Es macht keinen Sinn, über den Begriff zu streiten.

(2) Selbstorganisation ist nicht mit Selbstmanagement zu verwechseln.

Projektabschluss per Führungsentscheid

Zum Auftakt der PMCamp-Saison beschäftige ich mich wieder vermehrt mit Fragen zum Projektmanagement. Dabei ist mir eingefallen, wie wichtig es ist, Projekt und Betrieb zu trennen.

Der Rework Cycle

Ich habe hier auch schon darauf hingewiesen, dass Projekte oft gar kein Ende haben. Es gibt hier noch etwas zu flicken und dort etwas aufzuräumen, und so zieht sich der Abschluss des Projekts oft über Wochen und Monate hin. Das hat mit dem Rework Cycle zu tun, dem bestuntersuchten Phänomen des Projektmanagements. Im Nachhinein entpuppen sich bereits erledigte Arbeiten manchmal als mangel- oder gar fehlerhaft und müssen nachgebessert werden. Das kann zu beträchtlichen Verzögerungen führen. Ich habe hier den Rework Cycle schon mehrmals vorgestellt(1).

Verspätet auftauchende Mängel führen zu einem „langen Schwanz“ von Nacharbeiten. Auf der einen Seite ist der Druck des Controllings, das Projekt abzuschliessen, auf der anderen Seite weigert sich der Betrieb, die Mängel zu erben. Das führt dann zu einer manchmal monatelangen Überlagerung von Projekt und Betrieb.

Zwischen dem Projekt und dem Betrieb muss ein deutlicher Schnitt stattfinden.
Zwischen dem Projekt und dem Betrieb muss ein deutlicher Schnitt stattfinden, indem ab einem gewissen Zeitpunkt keine Nachbesserungen mehr gestattet werden.

Parallel- oder Schattenorganisationen

Vor allem in Weltkonzernen kann das oft beobachtet werden, wenn z. B. verschiedene Regionen ein System gestaffelt einführen. Während das Integrationsprojekt in Region A bereits abgeschlossen sein sollte, startet es in Region B gerade. Daher ist es nicht so wichtig, dass das Projekt in der Region A auch wirklich abgeschlossen wird. Schlimmstenfalls können Nacharbeiten zum Projekt in der Region B gerechnet werden, das fällt ja gar nicht auf. Während in Region A das System formal bereits dem Betrieb übergeben wurde, ist es in Region B noch in Einführung begriffen. Testuser in Region B wenden sich dann plötzlich an den Support in Region A, etc.

Solcherlei Vermischungen können oft zu einem jahrelangen Überlagerungszustand von Projekt und Betrieb führen. Ich habe schon Unternehmen gesehen, in denen das „Projekt“ zu einer ständigen Organisationseinheit wurde, die parallel zum Betrieb („Maintenance& Support“) existierte. Organigramme führten das Projekt tatsächlich als Kästchen und subordinierten es einem Linienmanager, obwohl ein Projekt definitionsgemäss zeitlich begrenzt sein sollte.

Das Projekt degenerierte so zu einer Parallelsupportorganisation. Es ist ein Führungsentscheid, dass ab einem gewissen Zeitpunkt das Projekt beendet ist und keine weiteren Nachbesserungen mehr erwartet und gestattet sind.

 

(1) Addor, P. Projekten in den Rachen geschaut. August 2008
und Addor, P. Die effektivste Massnahme, um Projektverzögerungen zu minimieren. August 2014

Ein übles Projekt

Eine erneute Blogparade fragt nach Projekterfahrungen, insbesondere diejenigen des erfolgreichsten und des übelsten Projekts(1).

Über ein erfolgreiches Projekt kann ich hier nicht berichten. Meine Projekte hatten keinen Anfang und kein Ende und waren stets problembeladen. Das mag auch darin gründen, dass ich als Projektberater oft als Troubleshooter geholt wurde.

Insofern waren alle Projekte, in die ich involviert war, relativ übel. Hier erzähle ich von einem Projekt, dessen unternehmerischer Kontext gar keinen Erfolg zuliess(2).

Das wirft die Frage auf, inweifern sich der Projektmanager im unternehmerischen Kontext eines Projekt engagieren soll und kann.

Der Projektkontext

Der Projektvertrag bestand zwischen dem Kunden und der nationalen Niederlassung eines internationalen Systemintegrators. Die Projektleitung und –durchführung oblag aber irgendeinem Competence Center im Ausland, das gleichzeitig mehrere Rollouts durchführte und sich natürlich auf diejenigen fokussierte, die am grössten und damit am lukrativsten waren.

Wenn immer der Kunde etwas zu bemerken oder gar bemängeln hatte, wandte er sich an seinen Vertragspartner, die Zweigniederlassung des Systemintegrators. Diese hatte aber keine Kompetenzen und musste alles dem Competence Center weiter geben. Dessen Ressourcen waren jedoch in Parallelprojekten beschäftigt und oft nicht verfügbar.

Eine detailliertere Sicht des Projektkontextes habe ich hier dargestellt:

pojekterfahrung

 

Das Verhalten der nationalen Niederlassung

Zunächst hat das Competence Center die Notwendigkeit jeglicher Aufwendungen der Zweigniederlassung abgestritten, während der Kunde das Risiko erkannt und mehrmals deutlich darauf hingewiesen hat, dass er volle Aufmerksamkeit für sein Projekt erwarte.

Die Zweigniederlassung konnte das Competence Center schliesslich überzeugen, dass der heikle Kunde Vorortbetreuung benötige. Die Zweigniederlassung funktionierte zunächst als Kommunikationsdrehscheibe zwischen dem Kunden und dem Competence Center.

Am Anfang konnte die Zweigniederlassung lediglich Druck auf das Competence Center machen, mehr Projektressourcen zu allozieren und diese lokal zu stationieren. Später warf das Competence Center der Zweigniederlassung dafür vor, ihre Kunden nicht im Griff zu haben.

Ich versuchte, dem CEO der Zweigniederlassung begreiflich zu machen, dass er in der Linie intervenieren soll, weil das Projekt in diesem Kontext zum Scheitern verurteilt sei. Leider konnte ich mich entweder nicht deutlich genug ausdrücken oder er hatte keine Möglichkeit, sich im Europäischen Management durchzusetzen.

Das Projekt endete mit einem grossen Knall, in welchem sich alle gegenseitig beschuldigten und keiner die Verantwortung übernehmen wollte. Dass das System nach Aufzehrung jeglicher Marge und mit einer Verzögerung von ca. 50% dennoch erfolgreich zum Laufen kam, war nebensächlich.

Es geht nicht um Systeme, sondern um Geschichten.

(1) JFtOptimizingPartner: Blogparade: Erfolgreichstes vs. Übelstes Projekt. 23. Januar 2015

(2) P. Addor, Projektdynamik – Komplexität im Alltag. Liebeig-Verlag, 2010. S. 40ff

Komplexitätsreduktion? Läuft bei mir nicht.

Am PMCamp in Dornbirn 2014 kam einmal mehr das Thema Komplexitätsreduktion auf. Erstaunlich, wie sich so etwas hält, trotz jahrzehntelanger Diskussion. 1956 publizierte Ashby sein berühmtes Gesetz(1). Obwohl er nicht der erste und einzige ist, der die Notwendigkeit der Komplexität oder Varietät verstand, ist seine Aussage doch die von der Öffentlichkeit am meisten akzeptierte.

Jeder hat seine eigene Vorstellung von Komplexität

In einem Pausengespräch sagte mir jemand, dass man doch nicht immer die ganze Welt in Betracht ziehen könne und sich auf einen Ausschnitt beschränken müsse. Wie wahr! Nur kümmert das die Welt nicht. Wer Mist baut und dieser anderen auf den Kopf fällt, darf sich nicht der Verantwortung entziehen. Was soll man also tun?

Das Problem beginnt mit dem Begriff „Komplexität“. Alle verwenden ihn, niemand weiss, was er bedeutet, bzw. jede Person versteht darunter etwas anderes(2). Die meisten Menschen setzen Komplexität einfach mit Intransparenz, Unordnung und hoher Varietät gleich. Für mich hat Komplexität aber weniger mit dem Sein als vielmehr mit dem Werden zu tun. Komplexität ist Dynamik, Rückkopplung und Potential zur Emergenz!

Dynamik ist in einem Projekt förderlich

Wird z.B. in einem Projekt die Dynamik und Rückkopplung reduziert, indem man strukturiert, Regeln aufstellt und Vorschriften erlässt, dann kann das dazu führen, dass das Projekt erstarrt und zusammenbricht, ins Abseits läuft oder abgebremst wird. Wenn das Projekt stoppt, kann nichts mehr schief, aber auch nichts mehr richtig gehen. Insofern erachte ich Dynamik, Rückkopplungen und Emergenzen in Projekten als förderlich, auch wenn das bedeutet, dass die Stakeholder vermehrt unter Stress stehen. Dann ist es eben eine Frage der Sichtweise, ob man Komplexität als grundsätzlich schlecht oder als hilfreich ansieht.

Vertrauen ist gut, Kontrolle ist besser?

NebelDas Problem liegt an unserem Drang, alles kontrollieren zu wollen. Das ist irgendwie ein menschliches Bedürfnis, kommt aber langsam in die Jahre. Unsere Welt ist überaus komplex geworden und kann längst nicht mehr kontrolliert werden. Wir müssen vielmehr lernen, mit Komplexität und Ungewissheit zu leben. Wir müssen uns fragen, wie wir uns im Nebel bewegen, wenn wir die Beschaffenheit des Weges vor unseren Füssen nicht mehr erkennen. Vielleicht wären Werkzeuge nützlich, wie z.B. ein Blindenstock oder ein Radar. Mit ihnen können wir zwar den Weg nicht vollständig kontrollieren, aber mindestens so viel, dass wir nicht ständig stolpern. (Zwar hinkt die Nebelmetapher! Den Weg gibt es, auch wenn wir ihn nicht sehen, die Zukunft gibt es noch nicht, sie liegt nicht im Nebel).

Das magische Dreieck der Komplexität

Es gibt solche Werkzeuge. Jedoch kommt hier ein ähnliches Gesetz, wie das von Ashby, zum Zuge: Das „Thorngatesche Postulat der angemessenen Komplexität“. Es besagt, dass von den drei metatheoretischen Tugenden „Allgemein, Genau und Einfach“ bloss stets zwei wahrgenommen werden können und die dritte vernachlässigt werden muss(3). Das bedeutet: allgemeingültige und einfache oder vereinfachende Handlungsanweisungen oder Methoden für Projekte sind Beliebigkeiten, d.h. Blahbla.

Modelle helfen, den Weg zu finden

ProjectscopeDaher würde ich auf Allgemeingültigkiet und Präzision setzen und die Forderung nach Einfachheit fallen lassen. Die gesuchten Werkzeuge, um in ungewissen und hochdynamischen Projekten zu bestehen, sind Modelle und Modellbildung. Mit Modellen lässt sich zwar auch nicht die ganze Welt einfangen, aber es kann zumindest untersucht werden, wo das Projekt „klemmt“ und welche Auswirkungen unsere Policies haben, auch ausserhalb des Projekts. Hier denke ich insbesondere an

  • Causal Loop Diagrams
  • System Dynamics
  • Bayesianische Netze
  • agentenbasierten Modelle.

Mit den heute zur Verfügung stehenden Möglichkeiten im Web 2.0, können alle, die sich dafür interessieren, unkompliziert die kompliziertesten Modelle bauen(4).

Quallen:

(1) R. Ashby: An introduction to Cybernetics. Wiley, New York 1956.

(2) M. Sussman: Ideas on Complexity in Systems – Twenty Views. 2000

(3) Karl E. Weick: Sources of order in Underorganized Systems: Themes in Recend Organizational Theory. In: Karl E. Weick (Hrsg.): Making Sense of the organization. University of Michigan/ Blackwell Publishing, Malden, MA 2001, ISBN 0-631-22317-7, S. 32–57

(4) Insightmaker für System Dynamics, Causal Loop Diagramme und agentenbasierte Modelle. GeNIe für bayesianische Netze. Beide sind gratis und dennoch professionell. Beide habe ich getestet und viel Erfahrung damit gesammelt.

Die rezipive Verzerrung durch des Kaisers neue Kleider

nackter_KaiserIn Köln stehen fünf kleine Fassaden-skulpturen, die das Märchen Des Kaisers neue Kleider von Hans Christian Andersen darstellen. Zwei Betrüger verkaufen dem Kaiser teure Gewänder, die angeblich nur von Personen gesehen werden, die ihres Amtes würdig und nicht dumm seien. Tatsächlich geben die Betrüger nur vor, Stoffe zu weben und Kleider zu schneidern. Aus Eitelkeit und Unsicherheit gibt der Kaiser nicht zu, dass er die Kleider auch nicht sehen kann, während die Menschen, denen er die angeblichen Kleider vorführt in Begeisterungsstürme ausbrechen ob derart nobler Bekleidung.

In unserer Zeit gibt es immer mehr Kaiser mit „neuen Kleidern“

Das Märchen endet leider etwas schwach. Ein Kind rief: „Aber der Kaiser ist doch nackt“, wodurch der Schwindel aufflog. Konsequenterweise könnten ja eben gerade Kinder die Kleider gar nicht sehen, da sie kein würdiges Amt haben und noch nicht die nötige Weisheit. Aber das Motiv ist verbreitet. Es wird auch in den Erzählungen Der Hauptmann von Köpenick und Kleider machen Leute aufgegriffen.

In sehr komplexen Umgebungen fallen die Menschen tatsächlich gerne auf Vereinfachungen und Verblendungen herein. Mir scheint, dass sich in den letzten Jahren die Fälle häuften, wo eine Marke, ein Managementkonzept oder ein Führungsstil hochgejubelt wird, auch und vor allem wenn gar nichts Geniales dahinter steckt. Und in allen Fällen finden diese „neuen Kleider“ viele Bewunderer, sogar auch in akademischen Kreisen. Es kommt zu regelrechten Fangemeinden, die sich über Social Media Kanäle nährt.

Ich denke z.B. an gewisse Projektmanagementmethoden, die regelrechte Schulen bilden und durch unabhängige Stellen kostenpflichtig zertifiziert werden; oder Computermarken, die zu einer Szene hochstilisiert werden und inkompatible Zusatzgeräte einen lukrativen Markt bilden. Ähnlich sind auch viele Management- und Führungskonzepte zu werten, die oft aus nicht mehr als einem Reizwort bestehen, das dann zuweilen monatelang durch die Social Media geistert, um crowdfunding Kapital zu generieren.

Nicht Eitelkeit, sondern Ausweg aus einer Kompliziertheitserstarrung

Allen Fangemeinden gemeinsam ist ein gewisser Fundamentalismus. Wer einmal auf den Zug einer virulenten Idee ausgesprungen ist, der verteidigt sie z.T. unter Verunglimpfung der „Nichtgläubigen“. Ein Beispiel ist die nicht endend wollende und oft unsachlich geführte Diskussion um das beste Betriebssystem von Computern.

Was hat dieses Phänomen zu bedeuten? Eines ist klar: Die Marken- und Konzeptidole sind nicht eines Kaisers neue Kleider. Während sowohl im Märchen, als auch beim Schneidergesellen Wenzel Strapinski oder beim Schuhmacher Friedrich Wilhelm Voigt Eitelkeit der treibende Faktor war, ist es hier Angst vor Kompliziertheit. Ein Konzept oder eine Technik entwickelt sich immer weiter und wird dabei immer komplizierter, bis zur Erstarrung. Dann fühlen sich die Anwender unwohl, verstehen nichts mehr und suchen nach etwas Einfacherem. Sobald sich am Horizont etwas auftut, wird es sofort als Erlöser vor dem überdrüssig gewordenen  willkommen geheissen. Später auftauchende, ebenso vielversprechende Konzepte, haben kaum mehr eine Chance. Dank Social Media findet die Aggregation einer Fangemeinde rasant statt. Sie kapselt sich sofort gegen konkurrenzierende Neuerungen ab. Ein gutes Beispiel ist das Projektmanagement. Während die Menschen seit Jahrtausenden Projekte machen, wurde Projektmanagement erst im Zweiten Weltkrieg begründet. Danach wurde es so lange weiterentwickelt, bis es zu einem regelrechten Moloch wurde, mit dem immer weniger Projekte erfolgreich abgewickelt werden konnten. In der 1990er Jahre entstanden neue Ideen, von denen vor allem das agile Projektmanagement viele Bewunderer fanden, von denen viele die konkurrenzierenden Ansätze nicht kennen  oder sie schlicht leugnen.

Abkapselung als komplexitätsvermeidene Heuristik

Ebenfalls gemeinsam ist allen diesen Marken- und Konzeptidolen, dass sie von ihren Anhängern in oft unzulässiger Weise verallgemeinert und in allen möglichen und unmöglichen Situationen angewendet oder empfohlen werden. Einerseits wird jeweils kaum sachlich untersucht, was die neue Idee taugt und andererseits werden auch keine Voraussetzungen angegeben, unter denen das neue Konzept praxistauglich ist. Wozu auch? Es ist über jeden Verdacht erhaben, und wer das in Zweifel zieht, ist ein Ewiggestriger. Auf diese Weise ist schon manches hohle Konzept zur Religion erhoben worden.

Zwar ist die Motivation nicht dieselbe, wie im Märchen von Des Kaisers neue Kleider, wohl aber das Tamtam, das um solche Marken- und Konzeptidole gemacht wird. Leider gibt es keine Kinder, die sie entlarven. Kritische Erwachsene werden hingegen schnell mundtot gemacht. Der englische Arbeitspsychologe James Reason, der sich mit der Erforschung menschlicher Handlungsgewohnheiten, die oft zu Fehlern führen können, einen Namen gemacht hat, nennt Abkapselung als eine häufig angetroffene Heuristik, um Komplexität auszuweichen(1). Dietrich Dörner spricht von vertikaler Flucht(2). Das Hochjubeln von wenig durchdachten Konzepten, nur weil die traditionellen zu kompliziert geworden sind, ist eine solche vertikale Flucht. Das anschliessende Abkapseln der Community gegenüber den „Ungläubigen“ nenne ich die rezipive (Wahrnehmungs-)Verzerrung (vom Lateinischen „zurücknehmen, befreien, annehmen“). Es ist möglicherweise eine Spielart der narrativen Verzerrung, die Nassim Taleb in seinem Schwarzen Schwan beschrieben hat(3).

 

(1) James Reason. Menschliches Versagen – Psychologische Risikofaktoren und moderne Technologien. S. 97. Spektrum Akademischer Verlag. Heidelberg 1994

(2) Dietrich Dörner. Die Logik des Misslingens – Strategisches Denken in komplexen Situationen. Rowohlt Verlag. Reinbek bei Hamburg 2003.

(3) Nassim Nicholas Taleb. Der Schwarze Schwan – Die Macht höchst unwahrscheinlicher Ereignisse. Hanser Verlag. München 2008

 

Haben Projekte ausgedient? – Beyond Project Management

Ein Projekt dauert eine bestimmte Zeit. Ein komplexes Projekt noch länger. Ist es im Zeitalter emergenter Organisationen überhaupt noch sinnvoll, Projekte anzureissen?

Projekte passen nicht zu emergenten Organisationen

Adrian W. Fröhlich stellte in seinem Buch Mythos Projekt(1) bereits 2002 fest, dass eine emergente Organisation in ständigem Wandel begriffen ist. In ihr ist die Konsensfindung unter den Mitarbeitern eine Daueraufgabe, ohne dass immer wieder Verantwortungsbereiche zur Disposition gestellt und soziale Umverteilungen vorgenommen werden. Fröhlich schreibt, dass Stabilität immer weniger erwartet und verlangt wird. Das Ziel sei nicht mehr das Festland, sondern bloss noch das schwankende Überwasserhalten. Was wirklich zählt, ist die Eleganz, mit der geschwankt wird (S. 151). Dabei folgt Fröhlich Truex et al. (2).

Daraus leitet Fröhlich ab, dass projektbasierte Analyse und Design veraltet seien. Wenn sich intensive Analysephasen in einer einigermassen stabilen Organisation noch gerechnet haben, weil der Projektgegenstand danach ja mehrere Jahre genutzt werden konnte, sei in der emergenten Organisation laufend Analyse notwendig.

Ebenfalls veraltet sei das Anstreben voller Benutzerzufriedenheit und die vollständige Erhebung von widerspruchsfreien Anforderungen. Nutzer können keine endgültige Meinung mehr haben, weil sich das organisatorische Umfeld ja ständig ändere.

Der neue Zielraum sei demzufolge permanente Analyse, dynamischer Anforderungsermittlung, lebendige Spezifikationen, Adaptierbarkeit bestehender Lösungen und kontinuierliche Umprogrammierung der laufenden Systeme.

Projekte lösen sich auf, wenn Entwicklung, Planung, Durchführung und Nutzung zusammenfallen und verfliessen.

Den Betrieb neu erfinden

Insbesondere Adaptierbarkeit bestehender Lösungen und kontinuierliche Umprogrammierung der laufenden Systeme erfordern die Abschaffung der herkömmlichen Projektmetapher, was um das Jahr 2000 noch ketzerisch geklingt haben mag. Ich habe noch 2005 ein Projekt geleitet, das zum Ziel hatte, ein Voice Messaging System zu migrieren. Das alte System kam mit 100‘000 Abonnenten an seine Grenzen und musste durch ein neues System ersetzt werden, das bis zu 300‘000 Abonnenten bedienen konnte. Das neue System bestand sowohl aus Hard- als auch aus einer Software, die mit der alten nicht kompatibel war, obwohl sie vom selben Hersteller stammte. Noch heute spricht man bei IT-Systemen von „end of life“ und erlaubt ihnen, einfach zu zerfallen. Dann muss die Organisation solange den Atem anhalten, bis ein neues System das zerfallende ersetzt (Fröhlich, S. 153ff).

Bis vor ungefähr zehn Jahren wurden die meisten Systeme organisationsintern eingesetzt und zur Aussenwelt hin isoliert. Heute jedoch sind alle Systeme vernetzt. Wenn eines zerfällt und ausfällt, hat das Auswirkungen auf ganze Supply Chains oder Märkte. Cloud-Konzepte wie SaaS und IaaS lösen Projekte auf und verweisen sie in den laufenden Betrieb.

lebensfaehigSolange jedoch „laufender Betrieb“ als Business as usual verstanden wird, kann er Projekte nicht aufnehmen. Der Betrieb muss sicherstellen, dass die Systeme lebensfähig sind und bleiben(3). Systeme sind lebensfähig, wenn sie sich an laufend verändernde Bedingungen anpassen können und resilient sind. „Betrieb“ heisst demzufolge nicht, die Systeme vor Changes und instabilem Umfeld schützen, sondern im Gegenteil, sie so zu betreiben, dass sie die Veränderungen mitschwingen können. Das bedeutet durchaus, dass ein aktueller Zustand lebensfähiger Systeme immer nur improvisiert und provisorisch ist. Er muss sich ja im nächsten Moment ändern.

Nicht nur in der IT sind Projekte veraltet

Projektmanagement kommt (leider) aus dem militärischen Bereich. Grosse Operationen, wie beispielsweise die Operation Overlord, mussten geplant und unter Risiken durchgeführt werden. Sie hatten Termine, Meilensteine und ein Ziel. Das ist heute kaum mehr denkbar. Kriege haben keine Fronten mehr. Es gibt keine Operationen mehr, die monatelang vorbereitet werden können, auch nicht zuletzt wegen der völligen Transparenz dank Satelliten und Informationstechnologien. Planung und Durchführung von Operationen finden in modernen Kriegsszenarien gleichzeitig statt.

Auch in der Organisationsentwicklung hat man, so paradox es klingt, Projekte gemacht. Beispielsweise gibt es eine Broschüre „Veränderungsprojekte erfolgreich planen und umsetzen“ oder einen Kurs „Planung und Steuerung von Veränderungsprojekten“ (4). Schon die Titel sind irreführend und atmen den Geist der 90er Jahre. Veränderung findet nicht in Projekten statt. Veränderung hat keinen Endtermin und kein Ziel. Die Projektmethodik ist zu träge, als dass sie die Veränderung transportieren könnte, die Unternehmen heute durchlaufen.

Dieser Artikel erscheint im Rahmen der Blogparade Beyond Project Management

1)Adrian W. Fröhlich. Mythos Projekt – Projekte gehören abgeschafft. Ein Plädoyer. Galileo Press GmbH, Bonn 2002. ISBN 3-89842-153-8

(2) D. Truex, R. Baskervill, H. Klein. Growing Systems in Emergent Organizations. Communications in the ACM, August 1999

(3) A. Ninck, L. Bürki, R. Hungerbühler, H. Mühlemann. Systemik – Vernetztes Denken in komplexen Situationen. Verlag Industrielle Organisation. 4. Auflage. 2004. S. 121ff

(4) Veränderungsprojekte erfolgreich planen und umsetzen und Planung und Steuerung von Veränderungsprojekten

Die effektivste Massnahme, um Projektverzögerungen zu minimieren

Am PM Camp in München, Ende Juli 2014, habe ich den Rework Cycle vorgestellt. Im Prinzip ist es ein Hauptschlüssel für erfolgreiches Projektmanagement. Das Rework Cycle Modell geht davon aus, dass vermeintlich erledigte Arbeiten nachgebessert oder wiederholt werden müssen, z.B. wegen Fehlern oder weil Policies geändert haben.

Der Rework Cycle

Der Bauingenieur David Ford berichtet von zwei Atomkraftwerkbauten (1). Während der Bauzeit flossen aus Erfahrungen beim Betrieb anderer AKW neue Bauvorschriften ein. Ich konnte das in meinen IT-Migrationsprojekten bestätigen. Die Systeme, die wir installierten, waren kurz vorher woanders in Betrieb genommen worden. Uns erreichten Meldungen über Laufzeitfehler, die unter Last auftraten. Das führte dazu, dass wir gewisse Tests wiederholen mussten, neue Lastverteilungsmassnahmen einbauen oder die geplanten Konfigurationen ändern mussten. Solche unvorhergesehenen Massnahmen sind die Ursache des Rework Cycle.

Die in realen Projekten gewonnen Daten stimmen so gut mit der Simulation des Modells überein, dass es heute ausser Zweifel steht, dass der Rework Cycle in jedem Projekt auftritt und es aufbläst. Wer den Rework Cycle ausser Acht lässt, wird sich regelmässig über Projekte wundern, die ihr terminliches Ziel nicht erreicht haben und die Ursache in Bereichen suchen, die gar nichts mit dem Problem zu tun haben, z.B. Kommunikation oder Management Awareness.

Wie umgeht man den Rework Cycle?

Gar nicht! Er ist Gesetz. Man kann aber die terminverzögernden Auswirkungen dämpfen, wenn man das Modell kennt. Dieses geht davon aus, dass die durchgeführten Arbeiten nicht gleich auf den Haufen „Erledigt“ kommen, sondern zuerst auf einen Haufen „zu begutachten“. Erst diejenigen Arbeiten, die sich bei der Kontrolle als gut erweisen, kommen auf den Haufen „Erledigt“. Die anderen müssen nachgebessert oder wiederholt werden. Sie kommen daher vorläufig auf den Haufen „Rework“.

ReworkCycleBasisMan sieht nun deutlich: Das Projekt wird nur dadurch fertig, indem man sich des Haufens „zu begutachten“ annimmt. Natürlich müssen die Originalarbeiten auch gemacht werden, aber „durchgewunken“ werden sie erst durch die Kontrolle. Das bedeutet, dass häufige Kontrollen das Projekt mehr voranbringen, als z.B. nur eine einzige Endkontrolle. Peter Lancy von der PA Consulting Group will das sogar genau wissen (2). Er hat gezeigt, wie sich die Laufzeit eines Projekts erhöht, wenn nur eine „grosse“ Schlusskontrolle, statt vier über das Projekt verteilte Kontrollen, gemacht wird. Aus seiner Grafik entnimmt man z.B., dass ein Projekt, in welchem die „Qualität“ (= Anteil an Arbeiten, die bei der Kontrolle auf den Haufen „Erledigt“ kommen) 0.85 beträgt dreimal länger geht als geplant, wenn nur eine Kontrolle gemacht wird und unwesentlich länger als geplant, wenn vier Kontrollen gemacht werden.

ProjektLaufzeit_Rework_LancyDer Anteil derjenigen Arbeiten, die bei der Kontrolle auf den Haufen „Erledigt“ kommen, werden in Lancys Grafik „Qualität“ genannt. In der Tat hängt es von diesem Anteil ab, ob das Projekt je fertig gestellt werden kann oder nicht. Es gibt einen „Kipp-Anteil“ (sog. tipping point), bei welchem das Projekt sozusagen an Ort tritt. Ist der Anteil höher als dieser Kippanteil, kommt das Projekt voran, andernfalls fällt es immer mehr zurück.

Damit heisst der Haupterfolgsfaktor: In einem Projekt so oft Reviews und Kontrollen machen, wie es nur geht! Das klingt einfach und selbstverständlich. Aber unterlassene Kontrollen sind der Hauptgrund für Verzögerungen in Projekten!

(1) Taylor, T./Ford, D. Tipping point failure and robustness in single development projects. Syst. Dyn. Rev. 22, 51–71, (2006)

(2) Lancy, P. Development Inefficienties – Managing the „Rework Cycle“ in Complex Projects. Australian Construction Law Newsletter ACLN, Issue #55, 1997