Inspired by Michael Hatfield: Game Theory in Management, www.projectmanagement.com

In gefühlt jedem zweiten amerikanischen B-Movie (aber beileibe nicht nur dort: auch in vielen hoch bewerteten Blockbustern!) kommt unweigerlich der Moment, wo ein Helfer der Hauptperson dem Oberschurken so auf die Nerven geht, dass der zu seinem Vizeschurken sagt: „Löse das Problem!“ Und der, als gut ausgebildeter Fiesling, weiß natürlich, wie diese Aufforderung gemeint ist, und findet eine funktionierende Lösung, die im Wesentlichen abhängt von dem Budget des Films: der nervtötende Helfer endet spektakulär in einem Haifischbecken oder wird zumindest in das Betonfundament eines gerade entstehenden Neubaus der Schurkenzentrale eingegossen.

Als trainierte Zuschauer wissen wir natürlich, wie es weitergeht: ist das Drehbuch gut aufgebaut, kommt diese Lösung noch zweimal zum Einsatz: ganz zum Schluss erleidet der Oberschurke den entsprechenden Abgang; das bedeutet, die Lösung funktioniert erneut. Aber kurz vorher wird sie auf die Hauptfigur angewendet, und dort funktioniert sie eben nicht; sonst gäbe es ja kein Happy End.

Wir haben es also mit zwei immer wiederkehrenden Mechanismen der Dramaturgie zu tun:

1. Der Auftraggeber fordert eine passende Problemlösung, spezifiziert sie aber nicht.
2. Der Auftragnehmer findet einen Lösungsweg; der funktioniert aber nicht durchgängig.

Unterdessen zurück in der Welt des Projektmanagements …

Wir erinnern uns (vielleicht): In vor-agilen Zeiten gab es auch schon Projekte, für die hat man Phasenmodelle erfunden, und die waren nach einigen wenigen Prinzipien aufgebaut; eines dieser Prinzipien war, dass der Projektmanager in der Initiierungsphase eines Projekts nach der Zieldefinition ein Lösungskonzept vorlegen musste. Und nur wenn das Konzept mit einiger Wahrscheinlichkeit Aussicht auf Erfolg versprach, wurde das Projekt überhaupt gestartet; andernfalls musste man die Erfolgsaussichten mit einem Vorprojekt nachweisen. Und auch die Tragfähigkeit des Business Case musste mittels Machbarkeitsstudien nachgewiesen werden, andernfalls machte man sich gar nicht die Mühe einer Detailplanung, geschweige denn der Realisierung des Projekts.

Ohne einen Proof of Concept hätte man also ein endgültiges, oft auch Unsummen verschlingendes Projekt gar nicht gestartet. Die Zeiten scheinen sich geändert zu haben; der Auftraggeber startet ein Projekt, und wenn gravierende Probleme auftauchen, dann heißt es: „Finde eine Lösung!“ Der Projektmanager und das Team finden eine; da sie aber aus der Not geboren ist, ohne vorherigen Proof of Concept, funktioniert sie entweder technisch nicht, oder sie wird so aufwendig, dass der Business Case nachhaltig beschädigt wird.

Projekte so vorhersehbar wie ein schlechter Film

Dieser Mechanismus kommt inzwischen so häufig vor, dass man ihn beim Start eines anspruchsvollen Großprojekts vorhersagen kann, auch wenn man nicht über hellseherische Fähigkeiten verfügt, sondern nur über einen leichten, fachmännisch getrübten Einblick in die Start- und Randbedingungen des Projekts.

Aber zum Glück leben wir in aufgeklärten Zeiten, und deshalb endet hier die Analogie zu einem Film-Plot: der Vize-Schurke, sprich Projektmanager, wird nicht ein physisches Opfer seines eigene Lösungskonzepts; er wird allenfalls gelegentlich ausgewechselt, wenn sein Konzept nicht funktioniert. Und auch beim nächsten Stuttgarter Elbflughafen müssen wir nicht damit rechnen, dass irgendwann das Fundament wieder geöffnet werden muss, damit man den Auftraggeber wiederfinden kann.

Und das ist gut so, auch wenn es der dramaturgischen Spannung sicherlich eher abträglich ist. Aber vom cinephilen Standpunkt aus sind das alles eben doch nur B-Movies.