Neue Server. Neue Netzwerkstrecke. Neuer Standort. Migration in die Cloud.
Infrastrukturvorhaben wirken auf den ersten Blick handhabbar, weil sie technisch klar umrissen sind. Genau deshalb werden sie unterschätzt. Der Aufwand steckt nicht im Aufbau, sondern in dem, was ihn umgibt.
Drei Aufgaben entscheiden. Sie sind unspektakulär, und sie werden regelmäßig übersprungen.
Aufgabe 1: Was wird eigentlich gebraucht?
„Vier CPUs.“ „Hundert Megabit.“ „Ein Fünf-Gigahertz-Netz.“
Das sind Spezifikationen, keine Anforderungen. Sie beschreiben eine Lösung, die jemand bereits im Kopf hatte — meist die, die er kennt. Die eigentliche Anforderung liegt eine Ebene darüber:
- Hohe Verfügbarkeit, weil Produktionsunterbrechungen unmittelbar Umsatz kosten
- Geringe Verzögerung, weil ein Echtzeitprozess davon abhängt
- Nachweisbare Trennung von Netzen, weil eine Zertifizierung sie verlangt
Der Unterschied ist nicht akademisch. Wer die Spezifikation beschafft, bekommt genau sie — und stellt nach dem Umstieg fest, dass der eigentliche Bedarf ein anderer war.
Die Zahlen dazu sind eindeutig. Rund vierundsechzig Prozent aller Fehler entstehen in der Anforderungs- und Entwurfsphase, und die Nacharbeit daran verbraucht achtundzwanzig bis zweiundvierzig Prozent der Umsetzungskosten. Vor allem aber wird die Behebung mit jeder Phase teurer:
Wie stark der Aufwand mit jeder Phase steigt, zeigt die folgende Übersicht — die Zahlen stammen aus einer Auswertung der NASA und werden seit Jahrzehnten in ähnlicher Form bestätigt (ScopeMaster, Requirements Defects):
Der Sprung zwischen der ersten und der letzten Zeile ist der Grund, warum sich Sorgfalt am Anfang rechnet — und zwar unabhängig davon, wie gut das Team später arbeitet.
Eine Woche mehr für die Anforderungen ist keine Verzögerung. Sie ist der billigste Teil des Vorhabens.
Praktisch heißt das: Fragen Sie bei jeder technischen Angabe nach dem Warum. Wenn die Antwort „das haben wir immer so gemacht“ lautet, haben Sie die Anforderung noch nicht.
Und schreiben Sie auf, was das Vorhaben ausdrücklich nicht leisten wird. Verbindliche Nicht-Ziele verhindern später mehr Konflikte als jede Zielformulierung.
Aufgabe 2: Der Plan hält bis morgen früh — und das ist in Ordnung
Ein Plan, der nach zwei Wochen noch stimmt, war zu grob.
Das ist kein Scheitern der Planung, sondern ihr Zweck: Der Plan ist kein Versprechen, sondern ein Messinstrument. Er zeigt Abweichungen früh genug, um zu reagieren. Ein Plan, von dem nie abgewichen wird, misst nichts.
Vier Dinge machen den Unterschied.
Puffer einbauen — offen. Puffer ist keine Schwäche und kein Verhandlungsspielraum. Er ist die professionelle Antwort auf bekannte Unsicherheit. Wer ihn versteckt, verliert ihn bei der ersten Diskussion.
Den kritischen Pfad benennen. Und zwar so, dass jeder Beteiligte weiß, ob er darauf steht. In Infrastrukturvorhaben liegt er fast nie in der Technik — sondern bei Lieferzeiten, Genehmigungen und Wartungsfenstern.
Lieferzeiten früh prüfen. Hardware, Leitungen und Zertifikate haben Vorlaufzeiten, die niemand beeinflussen kann. Sie gehören in die erste Planversion, nicht in die dritte.
Abnahmekriterien vor dem Start. Wer erst am Ende definiert, wann etwas fertig ist, verhandelt über die Abnahme statt sie durchzuführen.
Aufgabe 3: Kommunikation ist keine Nebenaufgabe
Die dritte Aufgabe ist die, die am häufigsten als weich abgetan wird — und die am zuverlässigsten über den Ausgang entscheidet.
Infrastrukturvorhaben treffen Menschen, die nichts bestellt haben. Ein Netzumbau verändert für den Fachbereich nichts Positives; er bringt bestenfalls keine Nachteile. Wer das nicht einkalkuliert, wundert sich über Widerstand gegen eine technisch einwandfreie Lösung.
Drei Regeln, die in meinen Mandaten funktionieren.
Vor der Störung reden, nicht danach. Ein angekündigtes Wartungsfenster ist eine Information. Dasselbe Fenster ohne Ankündigung ist ein Ausfall.
In der Sprache des Empfängers. Die Geschäftsführung braucht Wirkung, Kosten und Risiko. Der Fachbereich braucht: Was ändert sich für mich, ab wann, und wen rufe ich an. Beides sind unterschiedliche Texte.
Schlechte Nachrichten zuerst. Ein Statusbericht, der mit den Erfolgen beginnt und das Problem im vierten Absatz versteckt, wird beim nächsten Mal nicht mehr gelesen.
Was ist mit der Technik?
Die kommt danach — und sie ist selten das Problem.
In Infrastrukturvorhaben ist die technische Lösung meistens bekannt. Der Hersteller hat sie hundertfach ausgeliefert, der Dienstleister kennt sie, die Referenzarchitektur liegt vor. Wo es klemmt, sind die Ränder: die Schnittstelle zu einem Altsystem, das niemand mehr betreut. Die Abhängigkeit von einem Wartungsfenster, das nur einmal im Quartal offen ist. Die Zuständigkeit für ein Netzsegment, die seit einer Umstrukturierung ungeklärt ist.
Es lohnt sich deshalb, die Ränder zuerst zu kartieren und nicht zuletzt. Konkret: eine Liste aller Systeme, die an das betroffene angebunden sind, mit je einem Namen dahinter. Wo kein Name steht, liegt das Risiko. Diese Liste entsteht in zwei Terminen und verhindert regelmäßig die Überraschung, die sonst im Wartungsfenster auffällt — also zu dem Zeitpunkt, an dem niemand mehr umplanen kann.
Methodik schlägt Technologie. Nicht, weil Technologie unwichtig wäre — sondern weil sie in diesen Vorhaben selten die knappe Ressource ist.
Was passiert in den ersten zwei Wochen?
Die drei Aufgaben klingen abstrakt. In der Praxis sind sie ein Ablauf, und er dauert kürzer, als die meisten fürchten.
| Woche | Was passiert | Ergebnis |
|---|---|---|
| 1 | Bestandsaufnahme und Zielbild | eine Seite mit Zielen und Nicht-Zielen |
| 2 | Plan mit kritischem Pfad, Kommunikationsplan | Termine, die auf Lieferzeiten beruhen |
| 3–4 | Beschaffung anstoßen, Wartungsfenster festlegen | verbindliche Zusagen von Dritten |
| ab 5 | Umsetzung | messbarer Fortschritt statt Aktivität |
Woche eins — Bestandsaufnahme. Was steht heute da, wer betreut es, welche Verträge laufen dazu, und welche Abhängigkeiten sind nirgends dokumentiert? Der letzte Punkt ist der ergiebigste. Er kommt nicht aus Unterlagen, sondern aus Gesprächen mit den Leuten, die das System betreiben.
Woche eins — Zielbild und Nicht-Ziele. Ein Termin mit Geschäftsführung, IT-Leitung und den betroffenen Fachbereichen. Ergebnis ist eine Seite: Welchen Geschäftsbedarf deckt dieses Vorhaben, woran messen wir das, und was gehört ausdrücklich nicht dazu.
Woche zwei — Plan mit kritischem Pfad. Lieferzeiten abfragen, Wartungsfenster festlegen, Genehmigungen anstoßen. Erst danach die technischen Arbeitspakete. Diese Reihenfolge ist entscheidend, weil die langen Vorlaufzeiten den Termin bestimmen — nicht der Aufbau.
Woche zwei — Kommunikationsplan. Wer erfährt was, wann, von wem. Zwei Sätze je Empfängergruppe reichen. Wichtig ist nur, dass es vor der ersten Störung existiert.
Der teuerste Fehler in Infrastrukturvorhaben
Mit der Beschaffung anfangen, bevor der Geschäftsbedarf schriftlich vorliegt. Hardware, die falsch dimensioniert bestellt wurde, lässt sich nicht zurückgeben — und der Termin ist dann schon vergeben.
Warum Verzögerung überproportional teuer wird
Ein Vorhaben, das schwimmt, wird nicht von allein besser. McKinsey und die Universität Oxford haben an mehr als 5.400 großen IT-Vorhaben gemessen, dass jedes zusätzliche Projektjahr die Kostenüberschreitung um durchschnittlich fünfzehn Prozent erhöht (McKinsey, Delivering large-scale IT projects on time, on budget, and on value).
In Infrastrukturvorhaben kommt ein zweiter Effekt dazu, den diese Zahl nicht abbildet: Hardware und Verträge altern während der Verzögerung weiter. Was am Anfang eine Modernisierung war, ist nach zwei Jahren Verzug eine Ablösung im Betriebsnotstand — mit denselben Kosten und ohne Wahlmöglichkeit.
Fazit
Anforderungen, Planung, Kommunikation. In dieser Reihenfolge, und keine davon lässt sich später nachholen.
Wenn Sie vor einem Infrastrukturvorhaben stehen und eine einzige Frage stellen wollen, nehmen Sie diese: Können Sie in einem Satz sagen, welcher Geschäftsbedarf hinter der Beschaffung steht — ohne eine technische Angabe zu verwenden?
Wenn nicht, fangen Sie dort an.
Häufige Fragen
Was unterscheidet eine Anforderung von einer Spezifikation?
Eine Spezifikation beschreibt eine Lösung, eine Anforderung den Bedarf dahinter. „Vier CPUs“ ist eine Spezifikation. „Die Anwendung muss bei zweihundert gleichzeitigen Nutzern unter einer Sekunde antworten“ ist eine Anforderung. Die erste legt die Lösung fest, bevor sie geprüft wurde; die zweite lässt mehrere Wege offen und macht die Abnahme messbar.
Wie viel Puffer ist angemessen?
Weniger eine Frage des Prozentsatzes als der Verortung. Puffer gehört an die Stellen mit der größten Unsicherheit — meist Lieferzeiten, Genehmigungen und Abhängigkeiten von Dritten — und er gehört sichtbar in den Plan. Ein pauschaler Aufschlag am Ende wird als Verhandlungsmasse behandelt und ist damit weg.
Wer sollte in einem Infrastrukturprojekt kommunizieren?
Die Projektleitung, und zwar konsequent aus einer Hand. Sobald Dienstleister, IT-Betrieb und Projektleitung parallel an dieselben Empfänger schreiben, entstehen widersprüchliche Aussagen — und der Fachbereich glaubt danach keiner Quelle mehr.
Wie erkenne ich, dass die Anforderungen nicht tragen?
An zwei Anzeichen: Der Anforderungskatalog besteht überwiegend aus technischen Angaben, und niemand kann zu einer einzelnen Angabe sagen, aus welchem Geschäftsbedarf sie stammt. Dann ist der Katalog eine Bestellliste, kein Anforderungsdokument.
Lohnt sich das auch bei kleinen Infrastrukturvorhaben?
In verkürzter Form ja. Die drei Aufgaben skalieren mit: Bei einem Standortumzug reichen eine Seite Anforderungen, ein Plan mit benanntem kritischem Pfad und zwei Mitteilungen an die Betroffenen. Was nicht skaliert, ist das Weglassen — auch ein kleines Vorhaben scheitert an einer ungeklärten Zuständigkeit.
Passend dazu
- Warum IT-Projekte scheitern – und was externe Projektleitung ändert — Was externe Projektleitung in kritischen Vorhaben leistet
- Projektportfolio-Management im Mittelstand — Warum Einzelprojekte ohne Portfolio nicht vorankommen
- IT Carve-Out und Carve-In: Was IT-Teams erwartet — Carve-Outs als Sonderfall mit eigenen Regeln