Thomas Suppes

Steuerungslogiken im Projektmanagement — Teil 1 von 2

Es ist Dienstagmorgen, und in der Fabrik stimmt was nicht. Was genau los ist, weiß der Projektmanager nicht. Vielleicht ist ein Mitarbeiter ausgefallen, weil er krank wurde, oder zu einem Einsatz beim Kunden raus muss. Oder es gab an anderer Stelle technische Schwierigkeiten, die den Zeitplan durcheinander wirbelten. Aber eigentlich spielt das auch gar keine Rolle. Was zählt: Ein Termin ist nicht zu halten.

Die Antwort des Systems ist klar. Es gibt ein Formular dafür. Terminverschiebung beantragen, Begründung eintragen, Genehmigung durch den Projektmanager abwarten. Ihm stehen zwei Optionen zur Verfügung: genehmigen oder ablehnen. Die Ablehnung wird als Handlungsoption verkauft. Sie ist keine. Ein Nein zum Formular verschiebt den Termin nicht zurück.

Was hier passiert ist als Steigerung der Effizienz gedacht. Etwas klappt nicht? Schnell ein Formular öffnen und die Info weiterreichen. Die Intention ist gut! Nur kann die Lösung kaum sein, dass ein verschobener Temin im schlimmsten Fall eine ganze Kaskade an Folgeverschiebungen und damit einen anderen Liefertermin auslöst. Und der Projektmanager? Wird vom Lösungsanbieter zum Überbringer schlechter Nachrichten. 

Vor oder nach der Handlung steuern?

Es gibt zwei grundlegend verschiedene Steuerungslogiken im Projektmanagement, und sie schließen sich gegenseitig aus.

Die erste: Ich entwerfe ein Modell, handle danach, und beobachte. Die Steuerung liegt vor der Handlung – im Prozessdesign oder in der Wahrscheinlichkeitsrechnung. Diese Logik funktioniert hervorragend, wo sie hingehört: bei wiederholbaren, vorhersehbaren Abläufen. Die Montagelinie. Der Buchungsvorgang. Der standardisierte Onboarding-Prozess. Auch komplexere Fälle, die sich statistisch modellieren lassen, gehören hierher: Wettervorhersagen, Risikokalkulationen, Versicherungsmodelle. Das Gemeinsame: Ein Modell vor dem Handeln ist möglich und sinnvoll.

Die zweite Logik kehrt das Verhältnis um. Ich handle, beobachte das Ergebnis, passe an, handle erneut. Die Steuerung entsteht nicht aus einem Modell davor – sie entsteht aus dem Tun. Kein Plan ist ausreichend, weil die entscheidenden Informationen erst durch das Handeln selbst sichtbar werden. Der Arzt in der Notaufnahme bei unklarem Krankheitsbild arbeitet so. Der Kletterer in unwegsamem Gelände ohne bekannten Pfad. Und – ob es einem gefällt oder nicht – das Projektteam, das mit einem Terminproblem konfrontiert ist, das noch keine klare Ursache und noch keine klare Lösung hat.

Das Gespräch als Werkzeug

Zurück zur Fabrik. Das Formular setzt voraus, dass alle relevanten Informationen bereits bekannt und in Prozess-Ablauf-Logik kodierbar sind. Es behandelt ein empirisches Problem so, als wäre es ein definierter Prozessfall. Es kanalisiert, statt zu öffnen. Es simuliert Steuerungsfähigkeit, ohne sie herzustellen.

Was stattdessen gebraucht wird, ist kein besseres Formular. Es ist ein kommunikativer Raum: Fertigung, Montage, Projektmanagement sprechen miteinander. Verteilt vorhandenes Wissen – das in keinem System vollständig abgebildet ist – wird zusammengebracht. Optionen werden gemeinsam ausgelotet, nicht aus einem Menü gewählt. Dann wird entschieden und gehandelt.

Sprechen ist hier kein Umweg zur Lösung. Sprechen ist die Lösung.

Das klingt weich. Ist es nicht. In Situationen, die kein Modell vorab erlauben, ist der kommunikative Akt das entscheidende Werkzeug, das tatsächlich funktioniert. Wer das durch ein Formular ersetzt, hat nicht zu wenig Prozess. Er hat den falschen Werkzeugkasten.

Der verführerische Prozess

Es lohnt sich, kurz innezuhalten bei der Frage, warum das Formular trotzdem so verführerisch ist. Es erzeugt Dokumentation – das fühlt sich nach Kontrolle an. Es schafft Verantwortlichkeit auf dem Papier. Es ist skalierbar, reproduzierbar, passt in bestehende Systeme. Es hat alle Tugenden eines guten Prozesswerkzeugs. Für ein Problem, das kein Prozessproblem ist.

Doch das Verführerische hat eine Kehrseite, die gefährlich wird. Wer konsequent nach Prozessen arbeitet, schafft Distanz – zwischen dem Problem und dem, der es lösen soll. Das Formular befördert ein Behördendenken: Wir haben alles korrekt abgewickelt, also haben wir alles richtig gemacht. Der Prozess rückt in den Vordergrund, bekommt Gewicht, wird zur eigentlichen Leistung. Was dabei aus dem Blick gerät, ist die Frage, die am Anfang stand: Was wollten wir dem Kunden wann eigentlich liefern? Nicht die korrekte Einhaltung eines Ablaufs. Sondern ein Produkt. Eine Lösung. Einen funktionierenden Termin. Wenn der Prozess zum Selbstzweck wird, ist das kein Schönheitsfehler. Es ist Gift für das Unternehmen – weil die Energie, die in die Lösung fließen sollte, jetzt in die Verwaltung der Nicht-Lösung fließt.

Zwei Werkzeugkästen

Die Trennlinie zwischen den beiden Werkzeugkästen verläuft nicht entlang von Projektgröße, Budget oder Dauer. Sie verläuft entlang einer einzigen Frage: Ist das Problem vorhersehbar – oder nicht? Ist es vorhersehbar, gehört es in den ersten Werkzeugkasten. Ist es das nicht, hilft nur der zweite.

Die meisten Projekte enthalten beide Arten von Problemen. Wer das System gestaltet, trägt die Verantwortung dafür, dass es das weiß. Der Projektmanager am Dienstagmorgen folgt dem Prozess, den andere entworfen haben. Die Frage, ob dieser Prozess zum Problem passt, darf er sich nicht stellen – sie wurde ihm nicht gelassen. Das ist die eigentliche Aufgabe der Prozess- und Systemgestalter: nicht mehr Prozesse, sondern die richtigen. Und dort, wo kein Prozess taugt, den Raum zu schaffen, der stattdessen gebraucht wird.

Warum wir danebengreifen

Am Dienstagnachmittag hatte ich Gelegenheit, mit Projektmanagern darüber zu sprechen. Die Frage, die im Raum stand: Warum ist das so? Warum greifen wir gerade in technischen Branchen so verlässlich zum falschen Werkzeugkasten?

Eine Antwort liegt in der Ausbildung selbst. Wer Maschinenbau studiert hat, hat gelernt, in Abläufen zu denken. Konstruktion, Fertigung, Inbetriebnahme – Schritt folgt auf Schritt, das Ergebnis ist vorab beschreibbar. Diese Denkweise ist kein Fehler. Für die Maschine, die gebaut wird, ist sie genau richtig.

Das Problem entsteht, wenn dieselbe Denkweise auf etwas angewendet wird, das noch nicht existiert – ein neues Produkt, eine neue Lösung, einen Weg durch eine Situation, die es so noch nicht gab. Hier braucht es nicht mehr Ablaufplanung, sondern das Gegenteil: iteratives, inkrementelles Vorgehen, das sich erst im Tun herausbildet.

Beides ist nötig. Das eine schließt das andere nicht aus – es ergänzt es. In der Organisationsforschung nennt man diese Fähigkeit, zwei gegensätzliche Logiken gleichzeitig zu beherrschen, Ambidextrie. Für den Projektmanager heißt das: Er muss nicht nur sein Fach verstehen. Er muss erkennen, wann sein Fach mit der falschen Methode arbeitet – und dann den Mut haben, die Methode zu wechseln. Nicht das Formular ist die nächste Lösung. Die nächste Lösung ist die Fähigkeit, zu unterscheiden, welches Werkzeug gerade gebraucht wird.

Die Debatte um Agilität hat diese Unterscheidung lange dogmatisch verhandelt – als wäre es eine Entscheidung zwischen zwei Lagern. Klassisch oder agil. Das Bewährte reproduzieren oder das Neue suchen. Aber dieser Riss verläuft nicht zwischen Projekten. Er verläuft mitten durch sie hindurch. Dieselbe Initiative enthält Abschnitte, die einen Plan brauchen, und Abschnitte, die nur im Tun ihre Form finden.

Was wir brauchen, ist kein Lagerwechsel.
Wir brauchen ein feineres Sensorium.

Teil 2 dieser Serie: Die richtige Diagnose

Quellen

• Duncan, R. B. (1976). The ambidextrous organization: Designing dual structures for innovation. In R. H. Kilmann, L. R. Pondy, & D. Slevin (Eds.), The management of organization design (Vol. 1, pp. 167–188). North-Holland.
• O’Reilly, C. A., & Tushman, M. L. (2004). The ambidextrous organization. Harvard Business Review, 82(4), 74–81.
• Ryle, G. (1949). The concept of mind. University of Chicago Press.
• Snowden, D. J., & Boone, M. E. (2007). A leader’s framework for decision making. Harvard Business Review, 85(11), 68–76.