Open Loops

Der Begriff “Eskalation” ist häufig negativ besetzt: Man verbindet damit gewöhnlich das (unnötige) Ausufern eines Konfliktes oder eines Problemes, ohne dass damit eine Lösung in Sicht gerät. Immer wieder wird in Projekten auch mit einer Eskalation gedroht, um den Druck zu erhöhen. Diese negative Konnotation von “Eskalation” ist sehr schade, denn richtig angewandt können Eskalationen dazu beitragen, Probleme dort zu lösen, wo sie entstehen. Ich verwende bei Kunden daher gern den Begriff der Konstruktiven Eskalation als Lösung für die im Folgenden beschriebenen Situationen.

In Projekten treten fast zwangsläufig Probleme auf. “Gutartige” Probleme lassen sich in der Regel innerhalb des Projektumfeldes und damit im Wirkungsbereich des Projektleiters lösen. Es gibt jedoch immer wieder auch Probleme, die ihre eigentliche Ursache außerhalb des Projektkontextes haben, das Projekt aber extrem stören können. Solche Probleme lassen sich daher meist nicht alleine durch den Projektleiter lösen. Wenn z.B. ein Mitarbeiter der Fachabteilung nicht im zugesagten Umfang zur Verfügung steht, hat dies massive Auswirkungen auf den Fortschritt der Konzeption oder Umsetzung. Mangels disziplinarischer Macht kann der Projektleiter den Mitarbeiter in der Fachabteilung in der Regel aber nicht zu mehr Mitarbeit zwingen. Meistens möchte derjenige ja auch gerne am Projekt mitwirken, kann dies aber nicht im gewünschten Maße, da er nicht von anderen Aufgaben entbunden wird. Ein solches Problem kann nicht vom Projektleiter allein gelöst werden. Er kann aber mittels einer konstruktiven Eskalation eine Lösung des Problems bei den Verantwortlichen einfordern. Konkret sollte wie folgt vorgegangen werden:

Die eigentlichen Ursachen des Problems sind zu analysieren und zu prüfen, ob diese im Projektkontext gelöst werden können. Ist dies nicht der Fall, muss der potentielle Adressat einer Eskalation ermittelt werden: Durch wen außerhalb des Projektes kann das Problem gelöst werden? Ohne einen Adressaten oder mit einem falschen Adressaten besteht die Gefahr, dass die gewünschte Entscheidung nicht getroffen wird, weil der Angesprochene dazu schlicht nicht befugt ist. Ist der Adressat ermittelt, gilt es Lösungsszenarien aufzuzeigen. Im obigen Beispiel könnte dies sein, den Mitarbeiter der Fachabteilung von anderen Aufgaben zu entbinden oder dem Projekt einen anderen Ansprechpartner zuzuordnen. Die Szenarien sind dann mit Vor- und Nachteilen in Hinblick auf das Projekt und - soweit möglich - auf sonstige Betroffene anzureichern. Es sollten immer mindestens zwei mögliche Lösungen ermittelt werden. Zu viele Optionen wiederum führen aber ebenfalls nicht zu einer schnelleren Lösung. Anhand der Vor- und Nachteile sollte auch immer eine aus Sicht des Projektes präferierte Lösung benannt werden. Zur Aufbereitung eines Szenarios gehört auch das Aufzeigen der Konsequenzen für das Projekt. Dies gilt auch für den Fall, dass keine Lösung des Problems zustande kommt.

Mit den bewerteten Szenarien kann dann von den Verantwortlichen eine Entscheidung eingefordert werden. Dies kann im Rahmen eines Steuerungsgremiums geschehen oder auch unabhängig davon. Die Verantwortung für die Lösung liegt durch die konstruktive Eskalation wieder dort, wo auch die Ursache des Problems zu finden ist: außerhalb des Projekts. Es gilt hierbei natürlich, auch eine solchermaßen konstruktiv durchgeführte Eskalation nicht als Standardweg zur Problemlösung zu verwenden. Es besteht ansonsten die Gefahr, dass die Eskalationen nicht mehr Ernst genommen werden und sich im Ernstfall wichtige Entscheidungen nicht mehr herbeiführen lassen.

Unentbehrlich sein zu wollen ist menschlich. Wer möchte nicht gerne gefragt sein und im Mittelpunkt stehen? Das gilt auch für Manager. Besonders externe Berater haben ein Interesse daran. Das hat ganz sicher auch finanzielle Vorteile.

In Großprojekten und Turnarounds hingegen wirkt dieses gelernte und verinnerlichte Muster kontraproduktiv. Zieht man zuviel Arbeit an, kann man nicht schnell genug delegieren. Als Kopf wird man zum Flaschenhals - unentbehrlich zu sein führt in diesen herausfordernden Umgebungen unweigerlich zu Überlastung und Misserfolg.

Ich möchte erfolgreich sein. Da stellt sich die Frage: Wie wird man entbehrlich? Meiner Erfahrung nach gelingt dies durch das Schaffen von Strukturen und Abläufen in Projekten und Organisationen. Ich habe dabei die folgenden Erfahrungen gemacht:

Die Strukturen dürfen auf keinen Fall zentralistisch sein. Statt “alle berichten an einen”, berichtet vernetzt jeder an jeden, für den die Information wichtig ist. Dafür müssen Gremien geschaffen werden. Statt “alle bitten eine Person um eine Entscheidung”, bereiten die Personen, die am meisten zur Entscheidung beitragen können, die Entscheidung vor, so dass sie schon “getroffen ist”. Das impliziert: Strukturen werden dynamischer, gelten vielleicht nur für Phasen im Projekt, ggf. sogar nur für wenige Tage. Und es strengt an, ist aber effizient und fördert Redundanzen und damit die Reaktionsfähigkeit des Projektteams auf unvorhersagbare Ereignisse. Nicht mehr einzelne Personen sind wichtig, sondern die vernetzte und dynamische Struktur.

Verlässlichkeit und Ordnung schafft man hingegen durch Abläufe. Meetings finden immer zum gleichen Zeitpunkt, für die gleiche Dauer und den gleichen Teilnehmerkreis statt. Sie haben eine feste Struktur und werden in immer der gleichen Weise effizient moderiert. Beispiele sind die morgendliche Telko und die wöchentliche Projektleiterrunde. Aus diesen festen Abläufen ergeben sich häufig auch die angesprochenen virtuellen Strukturen, quasi kleine Projekte im Projekt: “Sorgt ihr drei bitte binnen vier Wochen dafür, dass die benötigten Daten da sind”.

Meine These: In großen und komplexen Projekten werden Strukturen dynamischer und Abläufe fester. Für mich ist diese Erfahrung wichtig, um entbehrlich sein zu können und Erfolg zu haben.

Und wenn das alles bei Ihnen nicht klappt oder Sie der These nicht zustimmen mögen, lesen Sie doch noch den Artikel Verschnaufpausen für Unentbehrliche von Monika Setzwein.

Unter dem Titel “Marchionne verordnet Chrysler sein Patentrezept” veröffentlichte die FAZ am 17. Juni einen Artikel, der auch für Turnaround Manager interessant ist. Welche Muster wendet der berühmte Sanierer bei einer Übernahme an, welche Vorgehensweisen haben sich schon bei Fiat, der Traktorensparte CNH und der Nutzfahrzeuggesellschaft Iveco bewährt?

Systemische Ähnlichkeiten lassen sich bei Projekten in der Krise, Unternehmen in der Krise oder bei Übernahmen sicherlich dann verwerten, wenn die Machtfülle eines Marchionne vorhanden ist. Denn es fängt blutig an: Bereits nach zwei Tagen hat der neue Chef 17 der 23 Führungspositionen neu besetzt. Zugleich vermeidet er aber den Eindruck einer Kolonialisierung, indem er mit lediglich 3 Topleuten (Finanzen, Kommunikation, Vertrieb) im Gepäck nach Amerika kommt. Von Anfang an versucht Marchionne eine zu große Belastung von Chrysler und Fiat durch Reisen und Abstimmungen zu vermeiden. Anders als bei Daimler sind Videokonferenzen zur Abstimmung das Mittel der Wahl.

Exportiert hat Marchionne besonders seine Organisationsstruktur, eine Matrixorganisation mit Spartenverantwortlichen. Denn in der steilen Hierarchie haben sich durch das Abschotten in Silos Wohlfühlpositionen aufgebaut. Mit der Matrix baut Marchionne eine gegensätzliche Zielposition auf, die zu Konflikten führt. Das Bearbeiten dieser Konflikte als Moderator ermöglicht ihm, das Unternehmen schrittweise in die gewünschte Zielrichtung zu bringen. Dabei zählt vor allem eins für die neue Führungsmannschaft: Tempo! Durch das Stecken konkreter und enger zeitlicher Ziele bewirkt Marchionne eine Fokussierung der Kräfte des Unternehmens.

Zusammengefasst lassen sich folgende Muster des Vorgehens festhalten:

• Führungspositionen neu besetzt
• keine Kolonisalisierung, sondern Autonomie des übernommenen Systems
• Kontrolle von Finanzen, Vertrieb, Kommunikation
• Wenig Reisen, Kommunikation über Videokonferenzen
• Matrixorganisation zum Aufdecken von Konflikten, die dann bearbeitet werden können
• Bearbeiten der Konflikte als Moderator
• Enge zeitliche Ziele bewirken Fokussierung der Kräfte

Mir hilft diese Sammlung als Checkliste von Möglichkeiten beim nächsten Turnaround mit Abwandlungen und Ergänzungen bestimmt.

Auch wenn Sie kein Sportfreak sind, kennen Sie sicherlich den 4 x 100 Meter Lauf bei den olympischen Spielen oder Weltmeisterschaften. Und Sie erinnern sicherlich auch Bilder aus der 4 x 100 Meter Freistilstaffel, die aus der olympischen Schwimmarena übertragen wurden. Staffelrennen scheinen sich doch irgendwie ähnlich zu sein, meint der Laie. Doch schaut man genauer hin, gibt es einen feinen Unterschied in der Art, wie die Staffel ausgetragen wird.

Ein Schwimmer muss am Beckenrand warten, so lange, bis sein Vorgänger angeschlagen hat. Erst dann darf er die harte Grenze Beckenrand verlassen. Anders ist es in der Leichtathletik-Staffel. Es gibt eine Übergabezone, in der beide Läufer gleichzeitig und nebeneinander herlaufen. Die Übergabe erfolgt durch den Staffelstab. So kann die Leistung eines schwächeren Läufers durch einen starken Läufer, der schon mitläuft und gut startet, leichter ausgeglichen werden. Beim Schwimmen addiert sich die Gesamtzeit der Staffel im Wesentlichen aus den Einzelzeiten der Schwimmer. Bei der Übergabe mit Staffelstab ist das Gesamtergebnis wesentlich durch die perfekte und manchmal auch tragische Übergabe zwischen den Läufern bestimmt.

Im Projektgeschäft habe ich beide Arten von Staffellauf kennengelernt.
Einmal eher die Schwimmer:

• Architekten, die auf die Arbeit des Fachbereichs warten, bevor sie loslegen und sich die ersten Gedanken machen.
• Entwickler, die erst programmieren dürfen, wenn bestimmte Dokumente fertiggestellt sind.
• Entwickler, die nach getaner Arbeit die Szene völlig dem QA-Team überlassen.

Auf der anderen Seite die Läufer mit Staffelholzübergabe:

• Architekten, Testmanager und Entwickler, die dem Fachbereich helfen, eine möglichst nützliche fachliche Spezifikation zu schreiben.
• Entwickler, die es als selbstverständlich ansehen, den technischen Schreibern zur Hand zu gehen, wenn die nicht richtig fertig werden.
• Entwickler, die nach getaner Arbeit dem Testteam helfen, möglichst gründlich zu testen und Fehler sofort beseitigen.

Auch im Projektgeschäft sind diese beiden unterschiedlichen Herangehensweisen völlig andere “Sportarten”. Auf der einen Seite Einzelkämpfer, die ihre Leistung zu optimieren suchen und auf keinen Fall Anteil an einem möglichen Mißsserfolg haben möchten. Auf der anderen Seite Team-Player, die für den gemeinsamen Erfolg die anderen Teammitglieder unterstützen und dafür auch proaktiv Arbeiten der anderen Disziplinen tatkräftig begleiten.

Modernes Management, das alle Ressourcen nutzen möchte, heißt für mich, den Läufern mit Staffelholz nachzueifern. Es gibt keine feste Grenze Beckenrand, sondern die Übergabe wird mit dem Staffelholz ausgehandelt. Der Teamerfolg steht im Vordergrund, nicht die Leistung eines Einzelnen.

Wo können Sie den Staffelstab in Ihren Projekten einsetzen und eine feste Grenze verschwinden lassen?

In komplexen Projektumgebungen oder größeren Organisationszusammenhängen hilft die Suche nach einfachen Fehlerursachen nicht. Fehler und Probleme haben meist einen systemischen Charakter, d.h. sie lassen sich nicht auf eine einzelne Ursache zurückführen, und unmittelbar ersichtliche Gründe für einen Fehler sind selten dessen tiefere Ursache. Ist man sich dessen bewusst und sucht nicht einfach nach Schuldigen, sondern nach einer Lösung von Problemen, so kann die Fragetechnik der 5 Why’s weiterhelfen. Die Idee dazu stammt aus dem Toyota Production System und ist im gleichnamigen Standardwerk zur Lean Production von Taiichi Ohno beschrieben. Dieses bereits 1990 ersterschienene Buch ist 2009 in deutscher Fassung heraus gekommen. Das Lesen lohnt sich - nicht nur für Manager in der Automobilindustrie.

Haben Sie sich bei einem Problem oder Fehler schon einmal fünfach hintereinander gefragt, warum der Fehler aufgetreten ist? Ohno veranschaulicht dieses Vorgehen in seinem Buch an einem Beispiel aus der Automobilindustrie:

“Warum hat die Maschine angehalten?
Es hat eine Überlastung gegeben, und die Sicherung ist durchgebrannt.
Warum ist eine Überlastung aufgetreten?
Das Lager war nicht ausreichend geschmiert.
Warum war es nicht ausreichend geschmiert?
Die Ölpumpe hat nicht genügend gepumpt.
Warum hat sie nicht genügend gepumpt?
Die Welle ist ausgeschlagen und rattert.
Warum ist die Welle ausgeschlagen?
Es war kein Sieb angebracht, und deshalb gerieten Metallsplitter in die Maschine.”

Doch auch in Zusammenhängen von IT-Projekten und Turnarounds überzeugt diese einfache Technik durch ihre Wirkung. Ein Beispiel:
Warum sind so viele Fehler noch im Produktionssystem aufgetreten?
Die Entwickler und Tester hatten keine ausreichende Möglichkeit zur Qualitätssicherung.
Warum hatten sie keine ausreichende Möglichkeit zur Qualitätssicherung?
Sie hatten zu wenig Zeit und vor allem waren die Anforderungen nicht klar.
Warum waren die Anforderungen nicht klar? (hier wird nur ein Pfad verfolgt, die zweite Frage nach der Zeit wäre auch zielführend)
Das Dokument, in dem sie beschreiben sind, ist zu groß und völlig unübersichtlich.
Warum ist das Dokument so groß und völlig unübersichtlich?
Entwickler, Tester und Leute aus dem Produktmanagement setzen sich zu wenig zusammen und sprechen miteinander.
Warum sprechen sie nicht miteinander während der Erstellung der Anforderungspezifikation?
Das ist in unserem Prozess so nicht vorgesehen. Dafür hat niemand Zeit.

Ich selbst nutze diese Technik für Kernprobleme, die mir in Turnarounds auffallen. Alleine der Weg, durch den einen die Fragerei führt, ist interessant und legt Möglichkeiten zur Veränderung offen. Wo sind Probleme, Fehler oder Knackpunkte in Ihrem Projekt oder Unternehmen? Welche Antworten liefern die 5 Why’s in Ihrem Team?

Warum haben Sie die Technik der 5 Why’s noch nicht eingesetzt?
….