Stellen Sie sich vor, Sie sitzen in einem sterilen Konferenzraum im vierten Stock eines mittelständischen Industrieunternehmens. Vor Ihnen liegt der Statusbericht für die Modernisierung der Produktionsstraße, ein Projekt, das eigentlich vor drei Monaten hätte abgeschlossen sein sollen. Der Projektleiter räuspert sich und schiebt Ihnen ein Dokument über den Tisch, in dem in sachlichem Corporate-Deutsch erklärt wird, warum die Kernfunktionen der neuen Software erst im nächsten Jahr kommen. Ganz unten in den Fußnoten steht der Satz, der erfahrene Berater nachts wachhält: The Following Upgrades Have Been Deferred Due To Phasing: Benutzerinterface-Optimierung, Echtzeit-Datenexport und die Anbindung an die Logistik-Schnittstelle. In diesem Moment wissen Sie, dass Sie gerade Millionen in ein System investiert haben, das im Grunde nur eine teure Schreibmaschine ist. Ich habe dieses Szenario in den letzten fünfzehn Jahren in der IT-Infrastruktur und im Anlagenbau immer wieder erlebt. Es ist der klassische Moment, in dem das Management versucht, das Gesicht zu wahren, während das Projekt technisch gesehen bereits gegen die Wand gefahren ist. Wenn diese Phasenverschiebung auftaucht, bedeutet das meistens nicht, dass man klug plant, sondern dass das Budget alle ist oder die technische Komplexität das Team erschlagen hat.
Das Missverständnis von Phasenplanung als Rettungsanker
Viele Projektverantwortliche glauben, dass sie ein Projekt retten, indem sie kritische Komponenten in spätere Phasen verschieben. Das klingt auf dem Papier logisch. Man sagt sich: "Wir bringen erst einmal das Grundgerüst zum Laufen, und die schwierigen Sachen machen wir später." Das ist ein gefährlicher Trugschluss. In der Realität führt das dazu, dass man eine Architektur baut, die die später geplanten Erweiterungen gar nicht tragen kann.
Ich war bei einem Automobilzulieferer in Stuttgart dabei, als man entschied, die Cybersecurity-Protokolle in "Phase 2" zu verschieben, um den Termin für den Prototyp zu halten. Das Ergebnis? Als man ein Jahr später die Sicherheit nachrüsten wollte, stellte man fest, dass die gesamte Hardware-Architektur dafür zu schwach dimensioniert war. Man musste alles wegwerfen und von vorne anfangen. Das hat das Unternehmen am Ende das Dreifache der ursprünglichen Summe gekostet. Wer "Phasing" als Euphemismus für "Wir haben keine Ahnung, wie wir das jetzt lösen sollen" benutzt, unterschreibt bereits den Scheck für die Nachbesserungen.
Echte Phasenplanung bedeutet, dass jede Phase für sich allein einen geschäftlichen Wert hat. Wenn die erste Phase ohne die aufgeschobenen Teile keinen Sinn ergibt, dann betreiben Sie kein Phasing, sondern Sie verzögern lediglich das Eingeständnis des Scheiterns. Man muss sich die Frage stellen: Funktioniert das Ding am Montag, wenn die versprochenen Upgrades niemals kommen? Wenn die Antwort "Nein" lautet, stoppen Sie das Projekt sofort.
## The Following Upgrades Have Been Deferred Due To Phasing Und Die Kostenfalle
Wenn dieser Satz in einem Bericht auftaucht, sollten bei jedem Controller die Alarmglocken schrillen. Es ist oft der Anfang vom Ende der Budgetdisziplin. In meiner Praxis habe ich gesehen, dass die Kosten für Upgrades, die aus dem Hauptprojekt herausgelöst wurden, exponentiell steigen. Warum ist das so? Weil das Team, das den Kontext des Projekts im Kopf hatte, sich auflöst.
Der Wissensverlust durch Zeitverzug
Sobald eine Funktion verschoben wird, geht das spezifische Wissen verloren. Ein halbes Jahr später müssen neue Entwickler oder Ingenieure eingearbeitet werden. Diese Leute müssen erst einmal verstehen, was sich ihre Vorgänger bei der Basis-Struktur gedacht haben. Das kostet Zeit. Viel Zeit. In einem Fall bei einem Logistikdienstleister in Hamburg führte das Verschieben der Datenbank-Optimierung dazu, dass die neuen Berater drei Monate brauchten, nur um den Code zu verstehen. Die Kosten für diese Einarbeitung waren höher als die eigentliche Implementierung gekostet hätte, wenn man sie direkt durchgezogen hätte.
Ein weiterer Aspekt ist die Inflation der Anforderungen. In der Zeit, in der die Upgrades warten, ändert sich der Markt. Was heute als "nice-to-have" gilt, ist in achtzehn Monaten vielleicht schon veraltet oder gesetzlich vorgeschrieben. Dann plant man nicht mehr nur ein Upgrade, sondern muss das gesamte Konzept an neue Normen anpassen. Das passiert besonders häufig bei Compliance-Themen im Finanzsektor. Wer hier schiebt, zahlt später die Strafzahlungen der Aufsichtsbehörden oben drauf.
Die Lüge der modularen Erweiterbarkeit
Ein häufiger Fehler ist die Annahme, dass moderne Systeme "einfach so" modular erweiterbar sind. Marketing-Broschüren versprechen das immer. Aber die Praxis sieht anders aus. Jede Schnittstelle, die man heute nicht baut, aber später braucht, ist eine potenzielle Bruchstelle.
Ich habe ein Projekt begleitet, bei dem ein ERP-System eingeführt wurde. Man verzichtete in der ersten Phase auf die Integration der Lagerverwaltung. "Das machen wir später über eine API," hieß es. Als es so weit war, stellte sich heraus, dass das Grundsystem die Datenfelder für die Bestandsführung in einer Weise logisch verknüpft hatte, die eine externe Anbindung unmöglich machte, ohne den Kern des Systems zu verändern.
Der Fehler liegt hier im mangelnden Verständnis der Abhängigkeiten. Ein System ist kein Lego-Bausatz. Es ist eher wie ein lebender Organismus. Wenn man das Herz einbaut, aber die Lunge auf später verschiebt, wird der Patient nicht überleben, egal wie modular man das Ganze nennt. Man muss die kritischen Pfade identifizieren. Wenn ein Upgrade technisch tief in die Kernstruktur eingreift, darf es niemals verschoben werden. Es muss Teil des Fundaments sein.
Der psychologische Kollaps des Teams
Es wird oft unterschätzt, was es mit der Moral eines Teams macht, wenn wichtige Meilensteine gestrichen werden. Ingenieure und Entwickler wollen etwas bauen, das funktioniert und auf das sie stolz sein können. Wenn sie merken, dass das Management nur noch "Mangelverwaltung" betreibt, sinkt die Qualität der Arbeit rapide.
In einem Softwareprojekt für eine große Versicherung erlebte ich, wie die besten Leute kündigten, nachdem die dritte Runde des Phasing angekündigt wurde. Sie wussten genau, dass sie nur noch an einer "Krücke" arbeiteten. Diejenigen, die blieben, taten nur noch das Nötigste. Der Code wurde schlampig, die Dokumentation wurde vernachlässigt.
Das ist ein unsichtbarer Kostenfaktor. Wenn man Funktionen aufschiebt, signalisiert man dem Team: "Eure Arbeit an diesen Modulen war umsonst, und wir glauben nicht mehr an den vollen Erfolg." Das führt zu einer Kultur des Mittelmaßes. Wer Erfolg will, muss Siege einfahren, auch wenn sie klein sind. Ein verstümmeltes Projekt ist kein Sieg, es ist eine Niederlage auf Raten.
Vorher-Nachher Vergleich: Die Realität der Umsetzung
Schauen wir uns ein konkretes Beispiel an. Ein Unternehmen will seine Kundenkommunikation digitalisieren.
Der falsche Ansatz (Vorher): Das Team merkt nach sechs Monaten, dass die Anbindung an das alte CRM-System viel schwieriger ist als gedacht. Die Kosten laufen aus dem Ruder. Das Management entscheidet: "Wir bauen erst einmal das neue Web-Portal. Die Daten der Kunden tippen die Mitarbeiter vorerst per Hand aus dem alten System ab. Die Automatisierung verschieben wir auf Phase 2." Das Ergebnis: Die Mitarbeiter hassen das neue Portal, weil es ihre Arbeit verdoppelt statt sie zu erleichtern. Die Kunden sind genervt, weil ihre Daten nicht aktuell sind. Nach einem Jahr ist das Budget für Phase 2 gestrichen, weil die Geschäftsführung sagt: "Das Portal wird ja kaum genutzt, warum sollen wir da noch mehr Geld reinstecken?" Das Projekt stirbt einen langsamen Tod.
Der richtige Ansatz (Nachher): Man erkennt das Problem mit dem CRM frühzeitig. Statt das Portal ohne Anbindung zu bauen, reduziert man den Umfang des Portals radikal. Man streicht das schicke Design, die Chat-Funktion und den News-Bereich. Stattdessen investiert man die gesamte Energie in eine einzige, perfekt funktionierende Schnittstelle für die Adressänderung. Das Ergebnis: Das Portal kann nur eine Sache, aber die funktioniert tadellos und spart den Mitarbeitern sofort Zeit. Der Erfolg ist messbar. Die Geschäftsführung sieht den Nutzen und gibt sofort das Budget für die nächste Funktion frei. Das Projekt wächst organisch und stabil.
Die Falle der "Phasing"-Strategie in der Ausschreibung
Oft beginnt das Problem schon bei der Vergabe. Dienstleister neigen dazu, Projekte in Phasen anzubieten, um den Einstiegspreis niedrig zu halten. Sie wissen genau, dass der Kunde am Haken hängt, sobald die erste Phase implementiert ist.
In meiner Zeit als technischer Prüfer habe ich Angebote gesehen, die so unrealistisch günstig waren, dass man schon beim Lesen wusste: Hier wird massiv geschoben. Die Klausel The Following Upgrades Have Been Deferred Due To Phasing ist dann oft schon im Kleingedruckten der Strategiepapiere angelegt. Der Dienstleister plant die profitablen Upgrades für später ein, wenn der Kunde keine Wahl mehr hat und jeden Preis zahlt.
Man muss hier als Auftraggeber extrem hart verhandeln. Wenn Phasen gebildet werden, müssen die Preise für die späteren Phasen heute schon feststehen – inklusive aller Integrationsleistungen. Wer sich darauf einlässt, die Kosten für Phase 2 erst später zu definieren, hat bereits verloren. Es ist wie beim Hausbau: Wenn man den Keller baut und sagt, über den Preis für das Dach reden wir in zwei Jahren, wird man eine sehr teure Überraschung erleben.
Wie man erkennt, ob Phasing sinnvoll oder gefährlich ist
Nicht jede Verschiebung ist schlecht. Aber man muss ehrlich zu sich selbst sein. Es gibt klare Kriterien, um den Unterschied zwischen kluger Priorisierung und verzweifeltem Aufschieben zu erkennen.
Fragen Sie sich: Ist die Funktion, die wir verschieben, ein "Zusatz" oder ein "Zentralorgan"? Ein neues Farbschema für die App kann man verschieben. Die Verschlüsselung der Nutzerdaten nicht. Fragen Sie sich auch: Haben wir das Budget für die nächste Phase bereits sicher auf dem Konto? Wenn die Finanzierung der Upgrades von zukünftigen Gewinnen abhängt, die das unfertige System erst noch erwirtschaften soll, dann betreiben Sie Glücksspiel, kein Projektmanagement.
Ein guter Indikator ist auch die Dauer der Pause zwischen den Phasen. Wenn mehr als drei Monate zwischen dem Abschluss der ersten Phase und dem Beginn des Upgrades liegen, wird das Projekt scheitern. Die Reibungsverluste durch das Wiederhochfahren der Maschinerie fressen jeden theoretischen Vorteil des Abwartens auf. In der deutschen Industrielandschaft, die oft von langen Entscheidungswegen geprägt ist, dauern diese Pausen oft eher zwölf Monate. In dieser Zeit verrottet das Projekt innerlich.
Realitätscheck: Die harte Wahrheit über komplexe Upgrades
Machen wir uns nichts vor: In neun von zehn Fällen ist die Verschiebung von Kernfunktionen der erste Schritt zur Beerdigung des Projekts. Wir leben in einer Zeit, in der technische Schulden schneller Zinsen ansammeln als jedes Bankkonto. Wenn Sie heute eine Entscheidung treffen, etwas "später" zu machen, dann entscheiden Sie sich in Wahrheit meistens dagegen.
Erfolg in der Umsetzung komplexer Systeme kommt nicht durch das Schieben von Problemen, sondern durch das radikale Streichen von Unwichtigem bei gleichzeitigem Festhalten an der technischen Exzellenz im Kern. Es ist besser, ein System zu haben, das nur zwei Dinge kann, diese aber perfekt und vollautomatisiert, als ein riesiges Software-Monster, das an allen Ecken und Enden manuell gefüttert werden muss, weil die Upgrades auf der Strecke geblieben sind.
In meiner Laufbahn habe ich mehr Geld durch das Stoppen von "Phasing-Projekten" gespart als durch deren Fortführung. Es erfordert Mut, vor den Vorstand zu treten und zu sagen: "Wir können Phase 1 so nicht machen, weil wir die Upgrades nicht schieben dürfen. Wir brauchen entweder mehr Geld oder wir bauen etwas viel Kleineres." Das ist nicht populär, aber es ist die einzige professionelle Haltung.
Wer glaubt, er könne die Gesetze der technischen Abhängigkeit durch klug klingende Projektberichte außer Kraft setzen, wird scheitern. Die Realität ist gnadenlos. Ein Upgrade, das heute zu teuer oder zu schwer ist, wird morgen unbezahlbar und unmöglich sein. Wenn Sie also das nächste Mal ein Dokument sehen, das mit der Verzögerung von Upgrades hantiert, wissen Sie jetzt, was das wirklich bedeutet: Es ist Zeit, die Reißleine zu ziehen oder das Fundament komplett neu zu überdenken. Alles andere ist nur teures Theater auf Kosten der Unternehmenszukunft. Was braucht es also wirklich? Es braucht die Eier, "Nein" zu sagen, wenn die Architektur noch nicht steht, und die Disziplin, das Schwierige zuerst zu erledigen, statt es in eine ferne, neblige Phase 2 zu verbannen. Das ist der einzige Weg, wie man am Ende nicht mit einem Haufen Elektroschrott und einer langen Liste von Ausreden dasteht.
