Co-Projektleitungen bestehend aus je einer Vertretung der IT und dem Business wurden ursprünglich eingeführt, um die Dominanz der IT zu brechen und die Fachbereiche als gleichberechtigte Business-ProjektleiterInnen zu etablieren.
Neben ein paar Vorteilen hat man sich damit aber auch erhebliche Risiken eingehandelt. Die beiden wichtigsten sind zusätzliche Management-Komplexität und die Gefahr von Reibungsverlusten, falls zwischen den beiden Projektleitenden die "Chemie nicht stimmt".
Im Unterschied zur Linienführung geht es bei der Projektarbeit darum, zahllose Aktivitäten auf ein bestimmtes Zieldatum hin auszurichten. Die Gefahr, dass sich Reibungsverluste zwischen Fachbereich und IT direkt oder indirekt auf den Projekterfolg auswirken, ist deshalb gross.
Die Quintessenz ist, dass auch im Zeitalter modernster Technologie am Ende immer noch der menschliche Faktor (mit)entscheidet über den Erfolg oder Misserfolg grosser IT-Vorhaben.
Entstehungsgeschichte der Doppelspitzen
In den Anfangszeiten der IT, als sie noch "Elektronische Datenverarbeitung" (EDV) hiess und in den Kinderschuhen steckte, galt es als selbstverständlich, dass bei Automatisierungsvorhaben ein IT-Vertreter die Projektleitung innehatte.
Bald jedoch wurde den Fachbereichen klar, dass gegen Ende dieser Projekte die IT-Leute detaillierter über die fachliche Seite Bescheid wussten als die Fachvertreter selbst. Während die IT in späteren Projekten immer dominanter agierte, fühlten sich die Fachbereiche zunehmend frustriert und hilflos gegenüber der offenbar allmächtigen IT.
Um diese IT-Dominanz zu brechen, entschied das Management schliesslich, dass sich ein IT-Verantwortlicher die Leitung eines Projektes mit einer gleichberechtigten Business-Vertreterin teilen sollte. Geboren waren damit die "Doppelspitzen", manchmal auch als "Tandem" oder "Co-Projektleitung" bezeichnet.
Die Absicht war klar: Die Business-Projektleiterin sollte das WAS definieren und der IT-Vertreter sich um das WIE, das heisst die Umsetzung, kümmern. Im Kern gilt diese Aufgabenteilung bis heute, unabhängig von der Vorgehensmethodik.
Die Frage stellt sich, weshalb Doppelspitzen bei Projekten ein Problem sein sollen, wenn es doch an der Spitze grosser Unternehmen (Apple, Microsoft, HP, Google/Alphabet) oder politischer Parteien oft vorkommt, dass vorübergehend oder dauerhaft ein Tandem an der Spitze steht? Dazu gibt es zwei Antworten:
- Im Unterschied zu den eher linienmässigen Aufgaben an der Spitze von Unternehmen und politischen Parteien gelten Projekte als einmalige Vorhaben. Sämtliche Aktivitäten orientieren sich an einem spezifischen Zieldatum, der Projekteinführung. Jeder Fehler der Projektleitung kann sich direkt oder indirekt auf das (Nicht-)Erreichen des Zieldatums auswirken und letztlich die Einführung als Ganzes gefährden.
- Co-Leitungen an der Unternehmensspitze bilden sich – zumindest in den Gründungszeiten – organisch aus den unterschiedlichen Neigungen und Begabungen der Beteiligten (kaufmännisch/wirtschaftlich vs. kreativ/technisch), während es sich bei Doppelspitzen in IT-Projekten um eine vorgegebene, unfreiwillige Co-Leitung handelt.
Vorteile und Chancen: 1 + 1 = 3?
Ein wesentlicher Vorteil von Co-Projektleitungen ist, dass die beiden Hauptbeteiligten (IT und Fachbereich) ebenbürtig vertreten sind. Ein weiterer Vorteil ist, dass die "Einsamkeit des Entscheiders", zum Beispiel bei schwierigen Personalentscheidungen, weniger schwer wiegt, wenn sich die Projektleiterin die Last der Verantwortung mit jemandem teilen kann.
Darüber hinaus können Doppelspitzen zu besseren Resultaten führen,
- wenn die beiden Verantwortlichen auch auf persönlicher Ebene harmonieren und
- wenn sich ihre unterschiedlichen Stärken und Erfahrungen ergänzen und sich dadurch bessere Entscheidungen ermöglichen.
Ausserdem ist bei Tandems die Gefahr kleiner, dass sich ein Projektleiter mit seinem "Baby" überidentifiziert und sich dabei in etwas verrennt, das dem Vorhaben als Ganzes schadet.
Risiken und Nebenwirkungen
Die Doppelspitze als Führungsmodell hat auf der anderen Seite ein paar erhebliche Risiken beziehungsweise klare Nachteile gegenüber dem "single command"-Ansatz:
- Die Anzahl der im Projekt mitredenden Personen vervielfacht sich auf einen Schlag, weil mit der zweiten Projektleitung auch deren Linienorganisation in die Entscheidungen miteinbezogen wird und die jeweiligen Linienvorgesetzten ihren Einfluss geltend machen wollen und müssen;
- Die dazu nötige Abstimmung unter den Beteiligten kompliziert und verlangsamt die Entscheidungsprozesse und lässt im schlimmsten Fall die Verantwortlichkeiten verschwimmen;
- Jede Reorganisation im Business- oder IT-Management gefährdet die personelle Konstanz im Projektausschuss;
- Die beiden Projektleitenden laufen Gefahr, gegeneinander ausgespielt zu werden. Manche Software-Anbieter und Beratungsfirmen sind sehr geschickt darin, direkte Abmachungen mit demjenigen Projektleiter zu treffen, von dem sie mehr Entgegenkommen erwarten;
- Ein wichtiges Organisationsprinzip wird verletzt: Funktionen mit intensivem Kommunikationsbedarf, wie dies zwischen IT- und Business-Seite typischerweise der Fall ist, sollten idealerweise an denselben Vorgesetzten rapportieren.
Ein selbst erlebtes Beispiel mag den letzten Punkt verdeutlichen:
Während eines Fusionsprojektes zwischen zwei Schweizer Grossbanken habe ich mir als Business-Vertreter eines Teilbereiches das Organigramm zusammen mit dem IT-Verantwortlichen genauer angeschaut.
Dabei haben wir festgestellt, dass es bei einem allfälligen Konflikt zwischen uns keine Führungsstufe bis hinauf zum CEO (!) des Konzerns gab, die Entscheidungsgewalt über beide Bereiche hatte. Konflikteskalationen auf beiden Seiten hätten deshalb mit jeder zusätzlichen Hierarchiestufe zu nichts weiter als politischem Hickhack geführt, uns beide aber viel Zeit und Energie gekostet.
Dem IT-Verantwortlichen und mir wurde in diesem Moment klar, dass wir bei Uneinigkeit von höheren Managementebenen keine Hilfe erwarten konnten, und deshalb auf Gedeih und Verderb miteinander klarkommen mussten.
Zusammenfassend lässt sich der Tandem-Ansatz als typisches "Schönwettermodell" beschreiben. Ist die Harmonie zwischen den beiden ExponentInnen und möglicherweise auch ihren Teams getrübt (Stichwort: Lagerbildung), kann das Projekt als Ganzes in Mitleidenschaft gezogen und im schlimmsten Fall sogar zum Stillstand gebracht werden.
Alternativen zu Doppelspitzen
Inner Circle: In einem meiner Projekte habe ich den "Inner Circle" als taugliche Alternative zur Doppelspitze erlebt. Mit einem Beratergremium bestehend aus vier erfahrenen Seniors konnte ich vor einer Entscheidung auch schwierige Themen, wie beispielsweise eine anstehende Team-Reorganisation, eingehend diskutieren. Ein Grund für die Wahl eines sehr kleinen Inner Circle war, dass dadurch die nötige Vertraulichkeit einfacher zu gewährleisten war.
Fachspezifische Alleinverantwortung: Bewährt hat sich auch eine Organisationsform, bei der für Business-lastige Vorhaben ein Projektleiter aus dem Fachbereich die oberste Verantwortung trägt, während umgekehrt ein IT-Projektleiter die Alleinverantwortung übernimmt, falls es sich um ein eher technisches Projekt handelt.
Dieses Modell kam vor einigen Jahren bei der Übernahme einer grossen Zürcher Privatbank durch eine der Grossbanken zum Tragen. Weil nicht nur die Kunden, Daten und IT-Systeme der Privatbank zu integrieren waren, sondern auch Mitarbeitende, Gebäude und Geschäftsprozesse, wurde das Grossvorhaben als Business-Projekt eingestuft. Die Gesamtverantwortung wurde deshalb einem hochrangigen Fachbereichs-Stabschef mit langjähriger Projekterfahrung übertragen. Im Interesse kurzer Entscheidungswege rapportierte er einmal pro Woche direkt an den CEO der Grossbank.
Zusammenfassung und Fazit
Mit der Einführung des Doppelspitzenmodells liess sich zwar die Dominanz der IT abbauen, aber dafür hat man sich andere Probleme eingehandelt:
- Gefahr von Reibungsverlusten aufgrund persönlicher Konflikte zwischen den Projektleitenden;
- Zusätzliche Managementkomplexität und dadurch aufwändigere Entscheidungsprozesse;
- Erhöhtes Risiko interner Politik bei Konflikt-Eskalationen.
Das Single-Command-Modell auf der anderen Seite führt nicht nur zur "Einsamkeit an der Spitze", sondern enthält auch ein erhöhtes Qualitätsrisiko bei der Personalauswahl.
Weil bei der Projektarbeit die Beteiligten intensiver zusammenarbeiten müssen als bei Linienaufgaben, funktioniert eine Doppelspitze nur, wenn das Führungs-Tandem auch auf persönlicher Ebene harmoniert. Bei Störungen in der Zusammenarbeit braucht es einen ausgefeilten Konfliktlösungsprozess, um Reibungsverluste (oder Schlimmeres) zu verhindern.
Es ist deshalb kritisch zu hinterfragen, ob eine Tandem-Führung für jede Art von IT-Projekten geeignet ist. Im Zweifelsfall sollte darauf verzichtet und einer Single-Command-Lösung der Vorzug gewährt werden.
Über den Autor
Im
"Thüring-Test" analysiert Markus Thüring quartalsweise IT-Projekte und deren Probleme. Der Grossprojektleiter hat in seiner 40-jährigen Karriere für Schweizer Finanzinstitute als Business Analyst, Projektleiter und Program Manager gearbeitet. Vor seiner Pensionierung leitete er Projekte mit zweistelligen Millionenbudgets. Derzeit ist er wieder in Teilzeit in der Projektleitung tätig. Im letzten Herbst ist sein Buch "Projektmanagement für Profis" im Omnino Verlag erschienen. Es geht darin vor allem um Hinweise auf die gröbsten Fehler und mögliche Gegenmassnahmen in IT-Projekten. Er äussert hier seine persönliche Meinung.