Wenn Requirements Management fehlt
Serie: Wenn Infrastrukturprojekte entgleisen
Teil 2: Wenn Requirements Management fehlt
Die Technologie war nie das Problem.
Das Problem war, dass niemand wusste, was die Technologie eigentlich leisten sollte.
Im ersten Teil dieser Serie habe ich beschrieben, wie das Projekt als „reines Infrastrukturprojekt" gerahmt wurde – und warum diese Rahmung bereits den Keim des Scheiterns enthielt. Das Business war nicht einbezogen. Die Annahme: Die Anforderungen liessen sich aus der bestehenden Infrastruktur ableiten.
Was dann folgte, war unvermeidlich.
---
Das Vakuum, das Requirements füllen
In vielen Projekten existiert zu Beginn eine trügerische Ruhe. Es gibt bestehende Systeme, Standorte, Arbeitsplätze. Die Frage „Was brauchen wir?" stellt sich nicht – weil die Antwort implizit vorhanden zu sein scheint.
In diesem Projekt war das nicht anders. Das Infrastrukturdesign war bereits in Arbeit, als aus den Fachbereichen die ersten Fragen kamen – nicht als strukturierter Input, sondern als beiläufige Nachfragen:
Welche Anwendungen gelten als geschäftskritisch?
Welche Standorte haben Sonderanforderungen?
Welche zukünftigen Services sind bereits in Planung?
Welche Abhängigkeiten bestehen zu Produktionssystemen?
Fragen, die vor Projektstart hätten beantwortet sein müssen. Stattdessen tauchten sie mitten in der Umsetzung auf – zu einem Zeitpunkt, an dem Entscheidungen bereits getroffen waren.
---
Das eigentliche Problem ist der Zeitpunkt
Requirements verschwinden nicht, weil man sie ignoriert. Sie tauchen später wieder auf – aber dann nicht mehr als steuerbare Eingabe, sondern als unkontrollierbare Störgrösse.
Wenn Anforderungen erst während der Umsetzung sichtbar werden, entstehen Folgekosten, die selten sauber ausgewiesen, aber im Projektverlauf deutlich spürbar werden: bereits getroffene Entscheidungen müssen revidiert werden, Prioritäten verschieben sich, Zusatzaufwände entstehen ohne Budget. Das Projekt verliert seine inhaltliche Grundlage.
Was in diesem Mandat dazukam: Der externe Dienstleister hatte das entstandene Vakuum genutzt. Er hatte selbst begonnen, Anforderungen bei den Fachbereichen einzusammeln – ohne Struktur, ohne Priorisierung, ohne Klärung von Zielkonflikten. Das Ergebnis war kein Requirements-Dokument. Es war ein unkontrollierter Scope-Aufbau. Dazu mehr in Teil 3.
---
Was Requirements Management wirklich ist
In vielen Organisationen wird Requirements Management als formale Pflichtübung verstanden: ein Workshop, ein Dokument, ein Häkchen in der Projektdokumentation. Das verfehlt den Punkt.
Requirements Management ist einer der zentralen Steuerungsmechanismen eines Projekts. Es geht nicht darum, eine Liste zu befüllen. Es geht darum:
relevante Stakeholder früh zu identifizieren – bevor sie selbst aktiv werden
Anforderungen strukturiert aufzunehmen und zu dokumentieren
Zielkonflikte sichtbar zu machen, bevor sie sich in der Umsetzung materialisieren
Prioritäten zu klären und als Entscheidungsgrundlage festzuhalten
Wer diesen Schritt überspringt, überspringt nicht eine Formalität. Er überspringt die Grundlage, auf der alle nachfolgenden Entscheidungen getroffen werden müssen.
---
Fazit
Requirements entstehen nicht von selbst. Wenn sie vor Projektstart nicht sauber aufgenommen werden, kommen sie zurück – meist im ungünstigsten Moment, oft über die falschen Kanäle und meist ohne die Struktur, die eine saubere Steuerung noch ermöglichen würde.
In diesem Projekt kam der Moment. Und er kam durch den Dienstleister.
---
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 (erscheint nächste Woche)
Teil 4 – Wenn der Projektsponsor verschwindet
Teil 5 – Der gefährliche Tenant-Fehler