Wenn der Dienstleister das Projekt führt
Serie: Wenn Infrastrukturprojekte entgleisen
Teil 3: Wenn der Dienstleister das Projekt führt
Ein Projekt, das über ein Jahr läuft und zwei Projektleiter verschlissen hat, ist kein Projekt mehr. Es ist ein Symptom.
Als ich das Mandat übernahm, war die Situation ungefähr so: Das Budget war zur Hälfte verbraucht. Die Ergebnisse standen in keinem Verhältnis dazu. Und der externe Dienstleister hatte sein Team von ursprünglich fünf auf zwanzig Mitarbeiter aufgestockt – Mitarbeiter, die er eigens für dieses Projekt eingestellt hatte.
Zwanzig Leute. Für ein Projekt, das mit fünf gestartet ist.
Und niemand hat gefragt, warum.
Man muss kein Forensiker sein, um zu verstehen, was hier passiert war.
---
Vom Infrastrukturprojekt zum Gemischtwarenladen
Wie in Teil 1 und 2 beschrieben, hatte der Dienstleister das Requirements-Vakuum aktiv genutzt, um den Scope auszuweiten. Aber „ausweiten“ ist eine höfliche Umschreibung.
Was tatsächlich passiert war: Aus einem Infrastruktur-Modernisierungsprojekt – Hardware erneuern, Netzwerk standardisieren, IP-Adressen harmonisieren – war ein IT-Transformationsprogramm geworden. Plötzlich standen ServiceNow als neues Ticket-System und ein unternehmensweiter Windows-11-Rollout auf der Agenda. Beides nie vom Auftraggeber beauftragt. Beides vom Dienstleister als „sinnvolle Erweiterung“ verkauft.
Für den Dienstleister war das natürlich sehr sinnvoll. Mehr Scope bedeutet mehr Mitarbeiter bedeutet mehr Umsatz. Die Fachbereiche, nie zuvor gefragt und jetzt plötzlich mit Möglichkeiten überschüttet, sagten begeistert Ja zu allem.
Niemand hatte Nein gesagt. Weil niemand die Autorität hatte, Nein zu sagen.
---
Zwei Vorgaben. Nicht verhandelbar.
Bevor ich das Mandat annahm, stellte der CIO zwei Bedingungen. Keine Empfehlungen. Bedingungen.
Erstens: Das ursprüngliche Budget wird unter keinen Umständen erhöht. Es war bereits zur Hälfte verbraucht – und der Rest musste reichen.
Zweitens: Die geplante Ablieferungsfrist darf nur moderat nach hinten verschoben werden.
Das waren die Leitplanken. Eng, aber klar. Und genau das brauchte dieses Projekt: Klarheit.
---
Die Notbremse
Meine erste Massnahme als neuer Projektleiter war nicht populär.
Ich habe das Projekt nicht „gebremst“.
Ich habe es gestoppt. Komplett. Von einem Tag auf den anderen.
Alles, was Geld kostet oder neue Komplexität erzeugt: eingefroren.
Kein weiterer Change. Keine weitere Bestellung. Keine weitere Rechnung. Geplant hatte ich mit etwa vier Wochen – genug Zeit, um zu verstehen, wo wir wirklich standen, und um einen Plan zu machen, der innerhalb der Budgetgrenzen funktioniert.
Die Reaktion des Dienstleisters kam schnell. Und sie kam nicht über den Projektkanal.
---
Wenn der Dienstleister zum Angreifer wird
Innerhalb weniger Tage nach dem Projektstopp schrieb der CEO des Dienstleisters – gleichzeitig einziger Gesellschafter – direkt an die Geschäftsleitung und den Verwaltungsrat meines Auftraggebers. Per E-Mail und per eingeschriebenem Brief.
Der Inhalt sinngemäss: Der neue Projektleiter macht alles kaputt. Er muss sofort abgezogen werden. Andernfalls behält man sich rechtliche Schritte vor. Klageandrohungen in Millionenhöhe.
Nicht wegen Projektinhalt. Sondern wegen entgangenem Umsatz.
Verständlich, wenn man bedenkt, dass der Dienstleister plötzlich zwanzig eigens eingestellte Mitarbeiter nicht mehr auf das Projekt buchen konnte. Die mussten jetzt aus eigener Tasche bezahlt oder freigestellt werden.
Für mich war das der Moment, in dem sich zeigt, ob die Governance hält. Ob Geschäftsleitung und Verwaltungsrat hinter der Entscheidung stehen – oder einknicken.
Sie standen dahinter. Ruhig, sachlich, ohne Panik. Und sie liessen mich meine Arbeit machen.
Das war der eigentliche Wendepunkt. Nicht der Projektstopp selbst – sondern die Tatsache, dass alle relevanten Stakeholder verstanden hatten, dass ein Weiter-so die teurere Option gewesen wäre.
---
Das Bauherrenberater-Modell
Ein Projekt zu stoppen ist das eine. Es danach richtig wieder aufzusetzen, das andere.
Mir war klar: Ich konnte nicht gleichzeitig das Projekt steuern, die politischen Konflikte mit dem Dienstleister managen und die technischen Architekturentscheidungen fachlich beurteilen. Wer das versucht, verbrennt.
Also holte ich einen unabhängigen IT-Architekten ins Projekt – jemand aus meinem Netzwerk, dem ich vertraue und der dem Dienstleister technisch auf Augenhöhe begegnen konnte. Seine Aufgabe: Jede vergangene und zukünftige Architekturentscheidung fachlich bewerten. Alternativen aufzeigen, die sinnvoller und kostengünstiger sind.
Das Prinzip kennt man aus der Bauwirtschaft: Man engagiert keinen Architekten, der gleichzeitig baut. Man engagiert einen unabhängigen Bauherrenberater, der im Interesse des Bauherrn prüft, ob das, was der Generalunternehmer vorschlägt, tatsächlich sinnvoll ist.
In der IT passiert oft genau das Gegenteil:
Derjenige, der baut, entscheidet auch, was gebaut wird.
---
Zurück zum Ursprung
Die wichtigste Entscheidung war keine technische.
Sondern eine Streichliste.
Alles raus, was nie beauftragt war.
Ich habe das ganz ursprüngliche Zielmodell wieder in Kraft gesetzt. Das Modell, das vor all den vom Dienstleister als „sinnvoll“ verkauften Erweiterungen existiert hatte. Kein ServiceNow. Kein unternehmensweiter Windows-11-Rollout. Sondern genau das, was ursprünglich beauftragt war: Infrastruktur modernisieren und vereinheitlichen.
DAS wollten wir ursprünglich bauen. Und genau das würden wir abliefern.
Nicht mehr. Aber auch nicht weniger.
Und plötzlich war das Projekt wieder steuerbar.
Nicht weil wir mehr gemacht haben – sondern weil wir aufgehört haben, alles zu machen.
---
Was das mit Governance zu tun hat
Dieses Projekt hätte nie so weit eskalieren müssen. Was gefehlt hatte, war nicht technische Kompetenz. Es fehlte eine Governance-Struktur, die verhindert, dass ein externer Dienstleister die inhaltliche Führung eines Projekts übernimmt.
Wenn der DL entscheidet, was gebaut wird – statt der Auftraggeber – hat das Projekt keine Steuerung. Es hat einen Autopiloten. Und der fliegt dahin, wo es für den DL am profitabelsten ist.
Wenn der Dienstleister entscheidet, was gebaut wird, ist die Governance nicht geschwächt.
Sie ist weg.
Das ist kein Vorwurf. Das ist ein Geschäftsmodell. Und es funktioniert genau so lange, bis jemand die Notbremse zieht.
---
Teil der Serie: Wenn Infrastrukturprojekte entgleisen
Teil 1 – Der Irrtum vom reinen Infrastrukturprojekt
Teil 2 – Wenn Requirements Management fehlt
Teil 3 – Wenn der Dienstleister das Projekt führt
Teil 4 – Wenn der Projektsponsor verschwindet (erscheint nächste Woche)
Teil 5 – Der gefährliche Tenant-Fehler
---
Solche Situationen entstehen nicht plötzlich.
Sie bauen sich über Monate auf – und eskalieren dann sehr schnell.