Die Verflechtungsfalle (II)

Bild: Flickr / Oregon State University - CC BY-SA 2.0

Unter den gedanklichen Konstrukten, die ich aus der Politikwissenschaft in meinen Beruf übernommen habe, ist die Verflechtungsfalle einer meiner Favoriten. Sie beschreibt die Situation in der sich überschneidende Verantwortlichkeiten zu einer Koordinations-, Kooperations- und Kontrollbürokratie führen, die alles lähmt, die aber auch einen derartigen Komplexitätsgrad hat, dass sie nur mit erheblichen Aufwänden wieder auflösbar ist. Fast alle grossen Organisationen sitzen in dieser Falle.

In welcher Form sie auftritt kann von Fall zu Fall unterschiedlich sein, es gibt aber einen grossen, immer wieder anzutreffenden Klassiker: eine Matrix-Organisation, die einer auf dem Anforderungsmanagement basierenden Budgetplanung unterliegt. Eine derartige Struktur ist ein fast sicherer Garantiefaktor für das Zuschnappen der Verflechtungsfalle - und bemerkenswerterweise ist sie trotzdem die Grundlage für das Organisationsdesign vieler Grossunternehmen.

Wie sieht das in der Realität aus? Zunächst so, dass die Verantwortung für einzelnen Programme, Projekt- oder Produktteams aufgeteilt wird. Häufig ist eine Trennung in Personal- und Produktverantwortung, auch die lassen sich aber nochmal unterteilen. Die Produktverantwortung lässt sich z.B. trennen in Entwicklung und Betrieb, der Personalverantwortung in Disziplinarisch und Fachlich. Es wirken also zwei, drei, vier (oder noch mehr) Manager gleichzeitig auf die Menschen der Umsetzungs-Ebene ein.

Das verkompliziert sich nochmal dadurch, dass die Gruppen, auf die die jeweiligen Manager einwirken, sich nur zum Teil überschneiden. So sind z.B. die Projektleiter für ihre jeweiligen Projekte zuständig, die Abteilungsleiter für jeweils eine über alle Projekte verteilte Gruppe von Spezialisten (etwa die Frontend-Entwickler) und die Architekten dafür, dass diese Menschen sich in bestimmten Themenfeldern (etwa bei der Weiterentwicklung des Intranets) an bestimmte system- und projektübergreifende Standards halten.

Alleine das wäre schon ausreichend, um für regelmässige Abstimmungsprobleme zu sorgen, aber jetzt kommt die Budgetierung dazu. In solchen Konstellationen verfügen in der Regel die Programm- oder Projektleiter über die Budgets. Diese nutzen sie um auf einem unternehmens-internen Markt von den Abteilungen jeweils die Spezialisten einzukaufen, mit denen die gerade anliegenden Anforderungen umgesetzt werden können. Und nur damit werden diese dann beauftragt.

Die anderen Manager bringt das in ein Problem. Die Ziele der Personalentwicklung (z.B. alle lernen regelmässig neue Programmiersprachen) oder der Architektur (z.B. alle Anwendungen bestehen aus Self Contained Systems) können den Zielen der Produktentwicklung widersprechen, da sie die Umsetzung von Anforderungen temporär oder dauerhaft verlangsamen würden. Da aber an der Produktentwicklung das Budget hängt, droht allen anderen Zielen permanent das Schicksal "wegpriorisiert" zu werden.

Um diesem Schicksal zu entgehen, wird oft versucht, auf einem anderem Weg als über das Budget Einfluss auf die Produktentwicklung zu nehmen. Es gibt beispielsweise Organisationen, in denen Architekten unternehmensweit geltende Entwicklungsvorschriften machen können, deren Einhaltung in einer Qualitätssicherungsphase überprüft wird. Und die Abteilungsleiter können ihre Ziele in die Jahresziele ihrer Untergebenen schreiben, wodurch die versuchen werden, sie irgendwie unterzubringen.

Die häufige Folge eines solchen Organisationsdesigns ist eine auf allen Ebenen ausgetragener ständiger Zielkonflikt, bestehend aus Verhandlungen, Eskalationen, verweigerten Freigaben, zurückgehaltenen Informationen, Kompromissen und Versuchen vollendete Tatsachen zu schaffen, wodurch sich alle Beteiligten gegenseitig behindern. Und wenn dann auch noch jeder Manager Teile seines Gehalts mit der Erreichung seiner Ziele verknüpft hat, wird er für ein solches Verhalten sogar noch belohnt.

Wenn es das Ziel einer Organisation ist, agile Produltentwicklung zu betreiben, ist das alles natürlich nicht zielführend. Wie man davon wegkommt hängt sehr von der Ausgangssituation ab, gute Ideen sind aber, Produkt- und Personalverantwortung zusammenzulegen, die Verfolgung gegenläufiger Ziele nicht zu belohnen (alleine das wäre ein Thema für sich) und die Budgetierung nicht mehr auf Anforderungen beruhen zu lassen sondern auf stabilen, produktorientierten Teams.

In fast allen Fällen sind das tiefgreifende Eingriffe in die bisherigen Strukturen und Abläufe, wodurch das unschöne Kriterium erfüllt wird, das aus einer Verflechtung die Verflechtungsfalle macht - man kommt nur schwer wieder heraus. Aber man kommt heraus, wenn man es darauf anlegt. Ganz nebenbei ist das auch ein guter Test um herauszufinden, wie ernst es mit der Agilität gemeint ist. Dort, wo es keine derartigen Anpassungen gibt, im Zweifel nicht so sehr.