Der Irrtum vom „reinen Infrastrukturprojekt“
Serie: Wenn Infrastrukturprojekte entgleisen
Teil 1: Der Irrtum vom „reinen Infrastrukturprojekt"
Wenn mich jemand ruft, ist meistens schon etwas passiert.
In diesem Fall hatte ein internationales Technologieunternehmen ein Infrastrukturprojekt gestartet. Technisch solide geplant. Intern gut aufgestellt.
Und trotzdem irgendwo zwischen Planung und Realität ins Schleudern geraten.
Was fehlte, war nicht Technik. Es fehlte etwas anderes.
---
Der Plan war eigentlich einfach
Die globale IT-Infrastruktur sollte modernisiert und vereinheitlicht werden:
Hardware erneuern
Netzwerktopologien standardisieren
IP-Adressierung harmonisieren
Namenskonventionen definieren.
Technisch ergibt das alles Sinn.
Das Projekt wurde intern als reines Infrastrukturprojekt verstanden. Entsprechend konzentrierte sich die Planung fast ausschliesslich auf technische Aspekte. Das Business wurde nicht einbezogen – mit der Annahme, dass sich die Anforderungen aus der bestehenden Infrastruktur ohnehin ableiten lassen würden.
Diese Lücke blieb zunächst unsichtbar.
Bis der externe Umsetzungsdienstleister sie entdeckte.
---
Der Dienstleister als inoffizieller Requirements Engineer
Was dann passierte, war kein klassisches "vergessenes Stakeholder-Management". Es war aktives Scope-Creep – mit System.
Der Dienstleister begann, eigenständig in den Geschäftsbereichen unterwegs zu sein. Nicht um bestehende Anforderungen aufzunehmen. Sondern um neue zu wecken. Die Botschaft war sinngemäss: Die schöne neue Welt könnte auch so aussehen.
Und die Geschäftsbereiche – nie zuvor gefragt, nun plötzlich einbezogen – hatten naturgemäss Ideen.
Die Folge war vorhersehbar:
Anforderungen, die vor Projektstart nie diskutiert worden waren, tauchten plötzlich auf
Bereits getroffene Entscheidungen mussten neu bewertet werden
Der Scope wuchs – ohne formalen Änderungsprozess
Prioritäten verschoben sich, zusätzliche Kosten entstanden
Technisch lief das Projekt weiter. Organisatorisch hatte es die Kontrolle verloren.
---
Zwei Fehler, nicht einer
Rückblickend lagen hier zwei Fehler übereinander.
Der erste: fehlendes Requirements Management vor Projektstart. Das Business war nie systematisch befragt worden. Die Lücke war real.
Der zweite – und gefährlichere: Ein externer Dienstleister nutzte diese Lücke aktiv. Nicht aus böser Absicht, sondern weil es in seinem Interesse lag, den Scope zu erweitern. Mehr Anforderungen bedeuten mehr Arbeit. Mehr Arbeit bedeutet mehr Umsatz.
Das ist kein Vorwurf.
Es ist ein Muster, das ich in vielen Projekten sehe.
Und es erklärt, warum gutes Requirements Management allein nicht gereicht hätte. Es hätte auch klare Governance gebraucht – wer darf Anforderungen einbringen, wer bewertet sie, wer entscheidet.
---
Die Fragen, die vor Projektstart fehlen
Bevor ein Infrastrukturprojekt startet, lohnen sich zwei Fragen – nicht eine:
Wer ausser der IT wird von dieser Infrastruktur später abhängen?
Und: Wer darf während des Projekts mit diesen Stakeholdern sprechen – und in wessen Namen?
Die zweite Frage klingt bürokratisch. Sie ist es nicht. Sie ist Projektschutz.
---
Fazit
Infrastrukturprojekte scheitern selten an Technologie.
Sie geraten ins Wanken, wenn zentrale Anforderungen zu spät sichtbar werden – oder aktiv von aussen eingebracht werden, ohne dass jemand die Kontrolle darüber hat.
Der wichtigste Schritt vor dem Start ist deshalb nicht die technische Planung.
Es ist eine saubere Aufnahme der Anforderungen – und die klare Regel, wer während des Projekts neue einbringen darf.
---
Teil der Serie: Wenn Infrastrukturprojekte entgleisen
Teil 1 – Der Irrtum vom reinen Infrastrukturprojekt
Teil 2 – Wenn Requirements Management fehlt (erscheint nächste Woche)
Teil 3 – Wenn der Dienstleister das Projekt führt
Teil 4 – Wenn der Projektsponsor verschwindet
Teil 5 – Der gefährliche Tenant-Fehler