Kategorie-Archiv: Projektmanagement

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

Ist das Web kaputt?

Zweifellos tragen Internet und Web in hohem Masse zu der Komplexität in Wirtschaft und Gesellschaft bei. Ohne Internet geht gar nichts mehr. Vor allem das Web befindet sich in einem Phasenübergang, was Sascha Lobo zum Urteil bewegte, es sei „kaputt“.

Daten sollten öffentliches Gut sein

Es zeigen sich Probleme, die zu Beginn des Webs nicht vorstellbar waren. Vorratsdatenspeicherung, Internetzensur, Erstellen von Verhaltensmuster durch Big Data Analysen, Handel mit persönlichen Daten, rechtliche Fragen betreffend Schutz der Privatsphäre, etc. Zwar wurde Frau Merkel ausgelacht, als sie sagte, dass das Web Neuland sei, aber sie hatte völlig recht. Die Problemstellungen, die das Web heute aufwirft, sind völlig neu und stellen uns alle vor grosse Herausforderungen. Wer soll sie lösen?

Ursprünglich war die Idee des Webs, dass alle daran gleichermassen partizipieren können. Für viele waren Daten ein öffentliches Gut, wie Luft und Wasser. Nur für die Aufbereitung des letzteren fallen Gebühren an. Daten müssen öffentlich sein, sonst könnte man keine webweiten Recherchen machen (viele nennen das „googeln“, aber es gibt noch andere Suchmaschinen). Zu diesem Zweck wurde auch die Creative Commons Lizenzen entwickelt. Netizen (Netzbürger) stellen ihre Werke als Gemeingut zur Verfügung. Auf meinen Artikeln und Fotos will ich kein Copyright beanspruchen.

Der Sinn des Webs liegt im Recherchieren

Webrecherchen sollen alle machen dürfen. Weiter ist es jedem freigestellt, die Recherchenresultate für Auswertungen zu speichern. Die israelitische Datenexpertin Kira Radinsky hat kürzlich ein interessantes Modell vorgestellt, mit der sie eine Pestepidemie vorhersagen konnte. Dazu sammelte sie u.a. auch Millionen von Facebook- und Twittereinträge und wertete diese mittels Big Data Algorithmen aus. Das ist bestimmt eine gute Sache!

Es wird nicht möglich sein, den Geheimdiensten zu verbieten, dasselbe zu tun. Hingegen ist es moralisch nicht vertretbar, wenn sie Unternehmen zwingen, ihre Daten herauszugeben. Wenn allerdings diese Unternehmen die Daten so oder so verhökern, dann können sie auch von Geheimdiensten gekauft werden.

Der Moloch “Allgemeine Geschäftsbedingungen”

Die Frage ist also, inwieweit Unternehmen, wie z.B. Google, auf Daten, die durch ihre Server rauschen, zugreifen und sie kopieren dürfen. Ein Jurist würde vielleicht nach den Allgemeinen Geschäftsbedingungen fragen (AGB). Wenn Sie eine Dienstleistung von Google beanspruchen, dann akzeptieren Sie Google’s AGB. Und wenn in diesen AGB steht, dass es Google erlaubt ist, alles, was Sie versenden, weiter zu geben, dann wird die Sache kompliziert.

Hannes Grassegger (1) hat zum Thema AGB einen interessanten Artikel veröffentlicht, den jeder Netizen lesen sollte. Für mich ist das Fazit nicht „Das ist ja ungeheuerlich!“, sondern „Hier gibt es noch viel zu tun“, denn Grassegger suggeriert eigentlich nur die Ablehnung der AGB. Wenn ich aber googeln will, habe ich keine Wahl, ob ich Googles AGB annehmen will. Ich will die Dienstleistungen von Facebook nutzen. Dann bleibt mir keine andere Wahl, als ihre AGB zu akzeptieren

Ich habe meinen Projektverträgen immer AGB beilegen müssen, und in zwei bis drei Fällen sogar eigene verfasst. Es war schon immer üblich, dass Dienstleistungserbriger die AGB vorschreiben. Z.B. ist der Gerichtsstand stets am Ort des Dienstleistungserbringers. Gerade, wenn ein Erbringer Millionen von Kunden hat, die auf der ganzen Welt verstreut sind, kann er nicht für jeden individuellen Kunden einen anderen Gerichtsstand definieren.

Neu ist, dass Dienstleistungen quasi in der Wolke erbracht werden können, dass also kein Erbringungsort identifiziert werden kann. Neu ist auch die Dimension, mit der Millionen von Kunden gleichzeitig gleiche oder ähnliche Dienstleistungen beanspruchen können. Es gibt keinen Check-out, wo man abrechnet. Diese Dimension setzt eine ungeheure Infrastruktur voraus. Die Netzkultur fordert aber, dass zumindest Basisdiensleistungen im Web gratis sind.

Vorratsdatenspeicherung kann auch eine gute Seite haben

Der Vorwurf, dass Google (und andere) unsere Daten speichert, kann ich schlecht nachvollziehen. Ich hoffe doch sehr, dass meine Daten gespeichert und verbreitet werden. Es wird das einzige sein, das von mir übrig bleibt. Wer sich schon mal in der eigenen Familiengeschichte umgesehen hat, der weiss, wie wertvoll Kirchenrodel sind. Da stehen zuweilen auch schon mal intime Dinge drin. Dass sich ein Vorfahre von mir beschwert hat, weil die Gemeinde an seiner Hochzeit keine Musikkapelle stellte, kann noch als lustige Anekdote angesehen werden. Wenn aber die ledige Mutter im Kindbett gezwungen wird, den Namen des Kindvaters rauszurücken (damit die Gemeinde nicht zahlen muss), dann wird’s schon heikler.

Heute gibt es keine Kirchenrodel mehr. Ich freue mich, wenn ich z.B. auf http://archive.org/web/ die Entwicklung meiner Website von 1996 bis heute nachvollziehen kann, weil sie auch ohne mein Einverständnis periodisch gespeichert wurde. Ich freue mich, wenn Google Newsgroup-Einträge „auf immer und ewig“ speichert und ich dort stets die Antworten nachschlagen kann, die mir auf meine Fragen gegeben wurden. Ich freue mich, wenn WordPress meinen Blog möglichst ewig speichert und offen hält.

Was soll man tun?

Ich möchte nicht den Eindruck erwecken, als würde ich die Entwicklung des Webs nur rosig sehen. Im Gegenteil: sie macht mir manchmal Angst. Wie ich eingangs erwähnt habe, gibt es grosse Herausforderungen zu meistern. Alles kann zum Guten und zum Schlechten genutzt werden. Es wäre aber falsch, wenn Gesetzgeber das Web zu regeln versuchen. Genau das wollen wir nicht. Wir müssen uns vielmehr dafür einsetzen, dass staatliche Eingriffe und Zensurmassnahmen abgebaut werden und zwar nicht mit der lapidaren Forderung “löschen statt sperren”.

Webabstinenz ist jedenfalls kein hilfreicher Ansatz. Niemand kann sich aus dem Einfluss des Webs fern halten. Die Welt findet zum grossen Teil im Web statt und wirkt sich auf alle aus, ob sie nun teilnehmen oder nicht.

(1)    Grassegger, Hannes. Schlechter Deal. Das Magazin, 23/2014. S. 18. 7. Juni 2014.

Können charismatische Persönlichkeiten die Gesetze von Zahl und Wahrscheinlichkeit austricksen?

Im Siebenjährigen Krieg hatte sich Friedrich der Grosse gegen Österreich, Frankreich, Russland und das übrige Deutschland gestellt. Eigentlich hätte Preussen gegenüber der zahlenmässigen Übermacht seiner Gegner keine Chance gehabt.

Der Zufall kommt zu Hilfe

K1024_friedrich_der_grose-3Dennoch glaubte Friedrich in enormer Selbstüberschätzung an einen Sieg. Er verstand zwar, dass er sich in einer Alles-oder-nichts-Situation befand, glaubte aber daran, dass die Siegeschancen nicht zu gering seien.

Zufälligerweise starb die Zarin, während ihr Nachfolger als Bewunderer Friedrichs mit Preussen sofort einen Friedens- und Bündnisvertrag schloss. Das hatte Signalwirkung und schwächte die Koalition der Preussengegner dermassen, dass sie zerfiel und der Krieg mit der Festsetzung des Status quo ante bellum beendet wurde.

In einer Friederich-Dokumentation, die der Sender ZDF_neo am Donnerstag, 3. April 2014, ab 08:05 Uhr, ausstrahlte, sagte ein Historiker über Friederichs Auseinandersetzung gegen eine Übermacht:

Daraus hat die Nachwelt im Ersten Weltkrieg, im Zweiten Weltkrieg, geschlossen, dass wenn man nur die richtige Einstellung hätte, wenn man so handeln würde wie Friedrich, wenn solche Personen an der Spitze sind, dann könne man die Gesetze von Zahl und Wahrscheinlichkeit erneut ausser Kraft setzen

Wird das nicht sogar in Führungsseminarien gelehrt? Geniessen heute nicht “charismatische Persönlichkeiten” und “Macher mit Selbstvertrauen” grosses Prestige?

Genügt allein der feste Glaube, um alles zu erreichen?

Mir scheint, dass wir in den letzten Jahrzehnten wenig dazu gelernt hätten. Noch immer wird propagiert, dass man alles erreichen könne, wenn man nur fest daran glaube. Das ist Quatsch und fördert Selbstüberschätzung, die nicht nur zu aussichtlosen Projekten verleitet, die scheitern müssen, sondern auch grosse wirtschaftliche Schäden und sogar unsägliches menschliches Leid verursachen können.

Immerhin forderte der Siebenjährige Krieg über eine halbe Million Soldatenopfer und nochmals so viele zivile Opfer. Die Zahl der Kriegsversehrten ist unbekannt, dürfte aber die Zahl der Toten weit überschreiten. Armut und Hunger verbreitete sich. Für die Bevölkerung waren die Kriegsfolgen katastrophal. Der Bankrott des Königreichs Frankreich hat der Siebenjährige Krieg mitverursacht. Der Bäckermeister Abelmann aus Hannover schrieb:

Verheerte Länder, in welchen die Dörfer von Menschen leer… Thränende Augen! Blutende Wunden! verstümmelte Glieder zu Tausenden! … Gemißhandelte, Barbarisch Gemißhandelte!

P.M.Magazin, 27.3.2013
P.M.Magazin, 27.3.2013

In “Selbstüberschätzung ist positiv” erklärt P.M. Online, dass Forscher herausgefunden haben wollen, dass Selbstüberschätzung von der Evolution begünstigt wurde.(1) Das ist zweifellos richtig, und ohne Selbstüberschätzung wären wir nicht da, wo wir heute sind, sondern würden vielleicht immer noch in Höhlen wohnen. Damals befähigte sie uns, ein Haus zu bauen.

Das heisst aber nicht, dass Selbstüberschätzung für immer und ewig positiv bleiben muss. Ich behaupte, dass sie heute nicht mehr vorteilhaft ist.

Wie weit können wir uns auf unsere Intuition verlassen?

Die Überschätzung der Intuition und Infragestellung der Rationalität geht mitunter auf den Eindruck zurück, der Friedrichs Handeln angesichts einer Übermacht hinterlassen hat. Seine Intuition sagte ihm, dass er gegen alle Vernunft die Gesetze der Wahrscheinlichkeit aushebeln könne. Dass seine Intuition falsch war und er nur aufgrund von Zufällen – also gerade dank der Wahrscheinlichkeit – vor einer Niederlage verschont blieb, interessiert im Nachhinein offenbar niemand mehr.

Die Überschätzung der Intuition verhindert ein analytisches Hinterfragen von Zusammenhängen und verleiht falsche Sicherheit. Das ist meines Erachtens in einer Zeit hochkomplexer technischer, gesellschaftlicher und wirtschaftlicher Systeme gefährlich. Der alte Fritz hätte die Verhältnisse vielleicht noch halbwegs überblicken können. In unserer Zeit ist das definitiv vorbei. Wir sind auf unsere Ratio und denkunterstützende Werkzeuge angewiesen!

(1) Dräger, Juliane. Selbstüberschätzung ist positiv. P.M. Online, 27.03.2013

Projekte sind so verschieden wie Einfamilienhäuser, Hochregallager und Spitäler

In Diskussionen über Projekte wird meist so getan, als gäbe es das Phänomen „Projekt“ schlechthin. Manchmal kennen sich die Diskussionsteilnehmer aber nur in ihrer Projektart aus und schliessen dann aus ihren Erfahrungen unzulässig auf andere Projektarten.

Das ist auch nicht verwunderlich. Ein Projekt dauert oftmals mehrere Jahre. Wenn es erfolgreich war, wird der Projektmanager in einem ähnlichen wieder eingesetzt. Bis er um die zehn Projekte durchgeführt hat, sind 20 bis 30 Jahre vergangen. Dann hat er grosse Projekterfahrung, aber eben meist ausschliesslich in dieser einen Projektart.

Man kann Projekte nicht schubladisieren

Projekte so verschieden, wie Gebäude. Das Projektmanagement verschiedener Projekte unterscheidet sich, wie das Leben in verschiedenen Gebäuden. In einem Einfamilienhaus zu leben “fühlt” sich ganz anders an, als in einem Hochregallager zu arbeiten. Für den Betrieb eines Spitals gilt das Augenmerk auf anderen Dingen, als es für den Betrieb einer Universität. Niemand käme auf die Idee, das Management einer Schule mit demjenigen eines Hochregallagers auf einen Nenner zu bringen, nur weil es in beiden z.B. eine Eingangstüre gibt.

Nur betreffs Projektmanagement ist man immer noch der Überzeugung, dass es einen gemeinsamen Nenner geben muss. Warum unterscheiden wir nicht deutlich zwischen so verschiedenen Dingen wie Strassen- und Hochbauprojekte oder IT-Entwicklungs- und Migrationsprojekten?

Es spielt eine Rolle, ob der Auftraggeber unter demselben Dach ist oder nicht

Allenfalls wird zwischen IT- und Bauprojekten unterschieden, obwohl es viele IT-Projekte gibt, die näher an Bauprojekten sind, als an anderen IT-Projekten. Ein IT Entwicklungsprojekt gehorcht ganz anderen Gesetzmässigkeiten als ein IT Migrationsprojekt. Diese Gesetzmässigkeiten werden noch viel zu wenig berücksichtigt, wenn es darum geht, ein Projekt zu beurteilen.

Kürzlich wurde im Fernsehen gezeigt, was es braucht, um einen Sender an den Olympischen Spielen zu installieren. Das Schweizer Fernsehen musste tonnenweise Kisten nach Sotchi verschicken,  mit Dutzenden von Bildschirmen, elektronischen Geräten, Kabel, Stellwände, Kameras, etc. Material, das am Bestimmungsort angekommen ist, muss geprüft, installiert und getestet werden.

Das brauchte eine sehr professionelle Planung, Koordination und Projektleitung. Das Projekt ist eng verwandt mit einem IT Integrationsprojekt. Während für das TV-Projekt der Auftraggeber und der Projektführer zu derselben Unternehmung gehören, sind in einem IT-Projekt Auftraggeber und Projektführer zwei unterschiedliche Unternehmen, zwischen denen grundsätzlich Misstrauen herrscht.

Zwar haben in beiden Projekten die Auftraggeber Tausende von Endkunden, aber im TV-Projekt ist der Auftraggeber angestellt, während er im IT-Projekt eine Unternehmung ist, deren Existenz wesentlich vom Projekterfolg abhängt. Die Interessenlagen, Befindlichkeiten, organisatorischen Gegebenheiten, Machtstrukturen und Motivationen sind jeweils ganz verschieden.

IT heisst nicht einfach nur programmieren 

Noch unterschiedlicher sind z.B. ein IT-Entwicklungsprojekt und ein IT-Migrationsprojekt. Auf ein Entwicklungsprojekt kommen hoffentlich 100 Integrations- und Migrationsprojekte, in welchen das einmal entwickelte Produkt ausgerollt und verkauft werden kann.

IT heisst nicht a priori entwickeln und programmieren. Der grössere Teil des „Kuchens“ nimmt eher der Betrieb ein. Obwohl Betrieb stetig und ohne Ende ist, wird er von vielen kleineren und grösseren Projekten begleitet. Jedes Mal, wenn ein System „end of life“ ist, muss es ersetzt werden. Das macht man in einem Migrationsprojekt. Da wird nichts entwickelt, sondern eingekauft, installiert, getestet und eingeführt. Das kann schon mal ein paar Monate dauern.

Fehler, die in den Tests manifest werden, müssen vom Produktemanagement wohl gefixt werden, aber das ist eher Produkteunterhalt und nicht mehr Entwicklung. Das Entwicklungsprojekt ist möglicherweise längst abgeschlossen, obwohl ihm die zutage geförderten Fehler angelastet werden müssten. Insofern weiss man beim Abschluss eines Entwicklungsprojekts nicht einmal, wie erfolgreich es war. Das ist in Bauprojekten völlig anders. Wenn die Brücke einstürzt, wir der Projektleiter zur Rechenschaft gezogen, während der Projektleiter eines Entwicklungsprojektes meist längst woanders arbeitet, wenn gravierende Produktefehler auskommen.

Die Umstände sind in jedem Projekt so verschieden, dass man nicht allgemeine Projektmanagementregeln aufstellen kann. Weder kann man behaupten, dass am Anfang eines jeden Projekts eine Breakdown Structure stehen müsse, noch dass jedes Projekt mit agilen Methoden durchgeführt werden kann. Das sind bloss undifferenzierte Betrachtungsweisen.

Das Prinzip Verantwortung

Unter diesem Titel hat der deutsche Philosoph Hans Jonas 1979 sein Hauptwerk veröffentlicht. Es sollte eine Ethik für die technologische Zivilisation sein.

Die Komplexität der Welt nimmt zu, weil immer mehr Systeme miteinander verbunden sind und voneinander abhängen. Ein Fehler in einem System kann einen Schneeball auslösen, wie beispielsweise in Fukushima. Das Unerwartete tritt zwar zunächst in technischen Systemen auf, da diese aber die Gesellschaft bedienen, greift es auch auf soziale Gruppen über.

Ist übermässiges Vertrauen noch zu verantworten?

Ohne auf Jonas‘ Werk einzugehen, möchte ich eine Passage herauspflücken, die mir in unserem Zusammenhang hilfreich erscheint. Jonas sagt, dass man sich im Handeln eher nach dem „worst case“ anstatt nach dem „best case“ richten sollte, um der Versuchung der Abwiegelung zu entgehen.

Leider ist auch nach Tschernobyl, 9/11, Deepwater Horizon und Fukushima die „We can“-Haltung beliebt und verbreitet. Übermässiges Vertrauen zeichnet soweit jede Projektplanung aus. Je komplexer unsere Welt aber ist, desto sensibler reagiert sie auf unsere Unterlassungen und desto mehr Verantwortung muss der Einzelne übernehmen, wie ich das in meinem letzten Blogpost gefordert habe[1]. Ich kann aber meine Veranwtortung nur übernehmen, wenn alle anderen sie auch übernehmen. Geht das Projekt schief, fühle ich mich als Projektmanager nicht in der Verantwortung, wenn die anderen Stakeholders am Projekt ihre Verantwortung nicht wahrgenommen haben.

Ein Beispiel für die Verantwortung, die ich meine, liegt bei Absolventen einer Weiterbildung. Üblicherweise gehen sie zu vorgegebenen Zeiten in ein Schulzimmer und erwarten, dass ihnen dort ein Dozent etwas erklärt. Das schreiben sie dann auf und nehmen sich vor, es vor der Prüfung auswendig zu lernen. Einen Tag nach der Prüfung haben sie das Wissen wieder vergessen. Hauptsache ist jedoch, dass das Diplom bleibt.

In letzter Zeit macht ein Konzept von sich reden, das sich „Inverted Classroom“ nennt. Dabei sollten sich die Studierenden das Wissen selber aneignen. In der Klasse wird es dann nur angewendet, um zu testen, ob es überall verstanden ist. Ich habe einige Versuche unternommen, Inverted Classroom durchzuführen. Die Erfahrung hat gezeigt, dass sich die Studierenden nicht in der Verantwortung sehen, sich den Stoff selbstständig anzueignen. Wozu bezahlen sie denn Schulgeld?

Zur Übernahme der Verantwortung in unserer hochkomplexen Welt gehört für mich auch die Präsenz in den digitalen Medien. Es genügt nicht, sich ab und zu mit einem neuen Berufskollegen oder Kunden in XING zu verlinken, ohne dort auch in Gruppen und Foren aktiv zu sein. Der ständige Dialog mit Personen, die sich ebenfalls in komplexen Situationen befinden, z.B. via Twitter, gehört ebenso zur individuellen Verantwortung.

Die Ursachen des Unerwarteten kann selbstverschuldet sein

In Projekten gibt es neben den üblichen Risiken, die man kennt und sich auf ihr Eintreffen rüstet, das Unvorhersehbare. Es gibt dafür keine Beispiele, denn sobald ich ein Beispiel nenne, ist es nicht mehr unvorhersehbar. Edward Yourdon hat in seinem Buch „Himmelfahrtskommando“[2] versucht, Beispiele von Unvorhergesehenem in Projekten zu geben:

Ihre zwei besten Programmierer sind gerade in Ihr Büro marschiert, um Sie darüber zu informieren, dass sie a) heiraten werden, b) den Zeugen Jehovas beitreten und c) heute ihr letzter Tag in ihrem alten Job ist

Jetzt, wo er das gesagt hat, wäre es für Sie nicht mehr unerwartet, wenn es in Ihrem Projekt tatsächlich eintreffen würde. Sie können sich jetzt Gedanken machen, wie Sie reagieren würden, wenn Ihr Projekt tatsächlich plötzlich Ressourcen abgeben müsste.

In der Tat kann man versuchen, die Ursachen des Unerwarteten zu unterteilen in gänzlich extrinsische (der buchstäbliche „Blitz aus heiterem Himmel“) und teilweise selbstverschuldete. War z.B. Fukushima unerwartet? Das Seebeben und der darauffolgende Tsunami waren in der Tat völlig unvorhergesehen und hatten extrinsische Ursachen. Dass hingegen die Sicherheitssysteme der direkt am Ufer erbauten Atomanlagen dabei in Mitleidenschaft gezogen wurden, war durchaus selbstverschuldet. Die Betreiber machten sich offenbar zu wenig Gedanken, was an diesem Standort alles passieren konnte. Das war unverantwortlich.

Wir entscheiden (in Projekten) meistens aufgrund pragmatischer und kostenspezifischer Leitlinien und ohne weitergehende Folgeabschätzungen. In einem Projekt musste ich für einen Telefonprovider auf ein neues Voice Messaging System migrieren. Das Produkt war eben erst entwickelt worden. Die Entwicklungsabteilung, die sich weit weg vom Kunden im Ausland befand, übernahm die de facto Projektleitung, während ich bloss de jure Projektleiter und kommerzieller Partner des Kunden war. Trotz meines Protestes verkaufte der Accountmanager das System, weil er das Geschäft machen wollte.

Für mehr Handlungsfolgeabschätzungen in Projekten

Es zeigte sich jedoch, dass das System in der speziellen Kundenumgebung nicht funktionierte und der Kunde verlangte Schadenersatz vom Lieferanten, den ich vertrat. Die Entwicklungsabteilung behauptete, dass wir den Kunden nicht im Griff gehabt hätten und weigerte sich, zu zahlen. So kam es zu einem unnötigen Streit, in dessen Verlauf in der lokalen Organisation Köpfe rollten. Der unverantwortliche „We can“-Optimismus wider besseren Wissens, das Aus-dem-Wind-Schlagen jeglicher Warnungen und die Gier nach dem Geschäft haben das Unerwartete verursacht.

Wie kann man aber mittel- und langfristige Konsequenzen von Entscheidungen und Handlungen vorhersagen? Es ist klar, dass es keine Möglichkeit gibt, in die Zukunft zu sehen. Pfadabhängigkeiten engen aber mögliche Entwicklungen schon mal ein, so dass nicht einfach „alles“ passieren kann. Vergleiche mit ähnlich gelagerten Projekten können wertvolle Hinweise geben, auch wenn jedes Projekt einzigartig ist. Im Übrigen gibt es mittlerweile mächtige Entscheidungsunterstützungswerkzeuge, die helfen, mögliche Entwicklungsszenarien aufzuzeigen. Ein Beispiel sind Peter Senges systemische Archetypen. Systemisches Denken ist eine Hauptkompetenz einer verantwortungsvollen Gesellschaft in einer hochkomplexen Welt[3].

Wer nun sagt, dass Unerwartetes nicht simuliert werden könne, hat zwar recht, macht sich aber mitverantwortlich für Katastrophen, die vielleicht durch weitergehende Analysen hätten verhindert werden können.

[1]Addor, P. Muss Führung Überzeugungsarbeit leisten? Dieser Blog, 2014

[2]Yourdon, Edward. Himmelfahrtskommando. Aussichtslose IT-Projekte überleben. Verlag Moderne Industrie. 2004

[3]Senge, Peter. Die fünfte Disziplin. Kunst und Praxis der Lernenden Organisation. Klett-Cotta Verlag. 2008 und
Senge, Peter et al. Das Fieldbook zur Fünften Disziplin. Klett-Cotta Verlag. 2008