Die Gesetze der Wahrscheinlichkeitsrechnung gelten also offenbar nicht für Projekte. Warum eigentlich? In anderen Lebensbereichen ergeben sich Chancen und Glücksfälle regelmäßig: Beim Stöbern im Buchladen finden wir ein interessantes Buch, beim Flanieren durch die Stadt treffen wir alte Bekannte, ein Kollege macht uns auf ein lukratives Projekt aufmerksam, oder eine Fluglinie stuft uns kostenlos in die Business Class hoch.

Die meisten Menschen erleben mehr positive als negative Zufälle und sind insgesamt sehr zufrieden mit dem Schicksal. Projekte hingegen, das zeigen Statistiken überdeutlich, quälen sich von einer Katastrophe zur nächsten.

Bauboom bei Luftschlössern

Ein wichtiger Grund für diese Asymmetrie ist, dass viele Projektpläne völlig unrealistisch sind und viel zu hohe Erwartungen wecken. Wer Luftschlösser baut, wird zwangsläufig enttäuscht und darüber Chancen übersehen. Wenn wir einen Buchladen betreten, werden wir nicht enttäuscht, weil wir dort keinen Goldschatz finden, sondern freuen uns, wenn wir dort erfahren, dass einer unserer Lieblingsautoren hier bald eine Lesung abhält.

Ein gutes Beispiel für unrealistische Erwartungen ist das Wüstenstromprojekt DESERTEC, beschrieben im Artikel "Abbildung von Risiken in Großprojekten oder was Risiken und Cocktails gemeinsam haben" von Dr. Philipp Gausling. Naiv betrachtet hätte das Projekt 35 Milliarden Euro Gewinn abwerfen können. Eine genauere Analyse zeigt aber, dass in 99% aller Szenarien das Projekt einen Verlust erwirtschaftet hätte und dass die durchschnittliche Höhe des Verlustes 40 Milliarden Euro betragen hätte (siehe das Kapitel "Der Cocktail-Effekt" im oben genannten Artikel).

Welche Chancen wird man erkennen können, wenn die Kluft zwischen Erwartung (35 Milliarden Euro Gewinn zu machen) und Realität (wahrscheinliches Ergebnis: 40 Milliarden Euro Verlust) so riesig ist? Die sich öffnende Tür war in diesem Fall das späte Einsehen der Verantwortlichen, die das Projekt inzwischen beendet haben. Leider wird es offenbar immer mehr zur Mode, Projekte trotz unrealistischer Annahmen zu starten, nicht selten sogar ohne ausreichende Risikoanalyse (siehe Methodensteckbrief dazu).

Alle legen sofort los

Schauen Sie sich manchmal Statistiken über die Ursachen von Projektkrisen an? Sie ähneln sich alle sehr und fast immer ist der Punkt "unklare Anforderungen" unter den ersten fünf Punkten. Leider hindern unklare Anforderungen viele nicht daran loszulegen: Der moderne Mitarbeiter ist schließlich höchst dynamisch und produktiv und beginnt mit der Arbeit selbst dann, wenn die Ziele des Projekts nur ungefähr und unvollständig bestimmt sind.

Ich arbeite in der Softwarebranche und weiß daher, dass Softwareentwickler Anforderungen als langweilig und überflüssig empfinden. Und was überflüssig ist, darf auch ruhig unklar sein. Wer Anforderungen nicht analysiert, verschafft sich viele Vorteile: Er muss weniger lesen, kann stattdessen mehr programmieren – und ohne Anforderungen ist alles korrekt – zumindest vorläufig.

Auf dieser Weise kann gerade in der Anfangsphase des Projekts eine erstaunliche Menge Code geschrieben werden, was alle Projektmitglieder als Zeichen hoher Kompetenz interpretieren – die vielen Fehler und teuren Korrekturen später im Projekt sind dann Pech, schlechtes Karma oder liegen daran, dass der Kunde doof ist.

Auch die Softwarearchitektur zu entwickeln, ohne die Anforderungen zuvor ausreichend analysiert zu haben, ist ein in der Praxis übliches Vorgehen. Das macht aber gar nichts, da die meisten Softwareentwickler die Softwarearchitektur genauso wenig berücksichtigen wie die Anforderungen. Fehler in der Architektur haben deswegen keine größeren Auswirkungen. Dass der liebe Kunde währenddessen die Anforderungen ständig ändert und erweitert, stört natürlich niemanden.

Irgendwann passt gar nichts mehr zusammen, dann fängt man eben von vorne an (Beispiel folgt unten). Chancen werden bei einem solchem Vorgehen natürlich nicht erkannt. Wer nicht weiß, wohin die Reise gehen soll, findet auch keine Abkürzungen!

Vorschnell wird das gesamte Projekt durchgeplant

Dass wir in einen guten Buchladen fast immer auf ein interessantes Buch stoßen, liegt auch an der hohen Anzahl der Bücher, die ein guter Laden führt und an unserer Bereitschaft, so lange mit der Auswahl zu warten, bis wir uns genügend umgesehen haben.

Chancen können sich also nur dort ergeben, wo es Optionen gibt. Das setzt voraus, sich nicht vorschnell festzulegen, sondern bewusst Lücken zu lassen, Freiraum zu schaffen und abzuwarten, bis sich möglichst viele Alternativen ergeben. Stakeholder aber mögen keine Lücken und Projektleiter treffen gerne Entscheidungen und zwar am liebsten ganz am Anfang des Projekts, wo alles so gut läuft und alle noch motiviert sind.

Während Entwickler Zeit "sparen", indem sie keine Anforderungen lesen, "beschleunigen" Projektleiter gerne ihre Arbeit durch "alternativlose Entscheidungen". Keine Optionen zu haben ist manchmal ganz angenehm, denn es verhindert langwierige Diskussionen und schnelle Entscheidungen lassen den Projektleiter kompetent und durchsetzungsstark erscheinen. Sind dann alle Entscheidungen getroffen, gibt es fortan keine Chancen mehr, sondern nur noch Risiken!

Ein abschreckendes Beispiel: Über 30 Jahre für ein System

Wie sehr man sich in einem Projekt dazu entschließen kann, Chancen nicht wahrzunehmen, zeigt das Child Support Enforcement System (CSES) des US-Bundesstaats South Carolinas: 1988 wurden alle Bundesstaaten per Gesetz aufgefordert, bis 1995 ein automatisches System einzurichten, um Unterhaltszahlungen von Eltern zu überwachen.

Da sämtliche 52 Staaten dieses System einrichten mussten, hätte es zahlreiche Möglichkeiten gegeben, den Aufwand und die Kosten zu teilen. South Carolina entschied sich jedoch, ein eigenständiges System zu entwickeln und beauftragte die Unisys Corporation mit der Entwicklung. Die Zusammenarbeit endete 2001 vor Gericht.

South Carolina lernte nichts aus seinen Fehlern und gab den Auftrag weiter an Hewlett Packard. HP unterschätzte den Aufwand, 2015 endete auch diese Zusammenarbeit vor Gericht. Nach über 20 Jahren kam South Carolina dann auf die Idee, das System eines anderen Bundesstaats zu übernehmen und beauftragte die Xerox Corporation damit, das System von Delaware zu adaptieren. Es ist geplant, 2019 fertig zu werden. Da das System von Delaware schon über 20 Jahre im Einsatz ist, wird die Lösung von Beginn an veraltet sein.

South Carolina ist inzwischen der einzige Bundesstaat ohne CSES-System und wird neben den Entwicklungskosten voraussichtlich bis zu 200 Millionen Dollar an Strafen zahlen müssen. Die Gesamtkosten werden auf 500 Millionen Dollar geschätzt. Über die Anzahl der verpassten Chancen gibt es keine Schätzung.