Warum IT-Projekte selten plötzlich kippen

Schieflagen entstehen selten über Nacht. Meist sieht man sie lange vorher – wenn man weiß, worauf man achten muss.

Wenn ein Projekt in eine kritische Schieflage gerät, hört man oft denselben Satz: Das kam plötzlich.

Meistens stimmt das nicht. Was von außen wie ein plötzlicher Umschwung aussieht, hat sich oft über Wochen oder Monate aufgebaut. Nur war es nicht für alle sichtbar. Ein Projekt kippt selten von einem Tag auf den anderen. Es kippt, wenn sich viele kleine Abweichungen so lange summieren, bis sie nicht mehr zu ignorieren sind.

Grün nach außen, Druck nach innen

Ein Statusbericht zeigt oft ein saubereres Bild, als die Realität im Projekt gerade hergibt. Das liegt selten an bewusster Schönfärberei. Es liegt daran, dass ein Ampelstatus immer eine Momentaufnahme ist, keine Entwicklung. Er zeigt: Aktuell nicht kritisch. Er zeigt nicht: Seit wie vielen Wochen hängt dieser Punkt schon in der Warteschleife, und wie viele ähnliche Punkte gibt es gerade gleichzeitig?

Intern sieht man das oft früher – nicht in Zahlen, sondern in der Stimmung. Entscheidungen ziehen sich hin. Dieselben Abhängigkeiten tauchen Meeting für Meeting wieder auf. Anforderungen bleiben vage, obwohl schon lange daran gearbeitet wird. Und die Energie im Team beginnt zu sinken, lange bevor irgendein Report das zeigt. Genau diese Diskrepanz zwischen offiziellem Status und gefühlter Realität ist eines der zuverlässigsten Frühwarnsignale, die es gibt.

Schieflagen kündigen sich an – nur meist leise

Bevor ein Projekt offiziell kritisch wird, gibt es fast immer Anzeichen: eine Anforderung, die drei Mal umformuliert wurde, weil sie nie wirklich klar war. Ein offener Punkt, der seit sechs Wochen im gleichen Statusbericht steht, jedes Mal unter „in Bearbeitung“. Eine Abhängigkeit zu einem anderen Team, die im Daily kurz erwähnt und dann nicht weiterverfolgt wird. Eine Testphase, die zum zweiten oder dritten Mal verschoben wird, weil die fachliche oder technische Basis noch nicht steht. Und, weniger greifbar, aber genauso aussagekräftig: eine Teamstimmung, die spürbar kippt, ohne dass jemand genau benennen kann, warum.

Jedes dieser Signale für sich ist meist harmlos. Es ist normal, dass Anforderungen sich klären, dass Abhängigkeiten Zeit brauchen, dass eine Testphase auch mal verschoben wird. Kritisch wird es erst, wenn sich mehrere dieser Signale gleichzeitig häufen – und niemand den Gesamtüberblick hat, der sie zusammenbringt.

Genau das ist die Aufgabe eines Fluglotsen: nicht ein einzelnes Flugzeug beobachten, sondern erkennen, wann sich mehrere Bewegungen gleichzeitig zu nahekommen. Ein Signal allein sagt wenig. Die Kombination sagt oft sehr viel.

Warum diese Signale oft übersehen werden

Es gibt gute Gründe, warum solche Anzeichen nicht früher auffallen. Statusberichte fassen zusammen, statt zu erklären. Ein gelbes Feld im Report zeigt selten, wie lange ein Punkt schon offen ist oder wie viele andere Themen ebenfalls gelb sind. Verantwortung ist oft aufgeteilt: Der Fachbereich kennt seine eigenen offenen Punkte, die Entwicklung ihre, das Testteam wieder andere – aber selten sieht jemand alle drei gleichzeitig.

Dazu kommt eine menschliche Komponente: Niemand berichtet gern früh über ein Problem, das sich vielleicht noch von selbst löst. Aus einer kleinen Verzögerung wird so eine größere, ohne dass irgendjemand bewusst etwas verschwiegen hätte. Oft fehlt nur der Moment, in dem jemand klar sagt: Das hier beobachten wir jetzt genauer.

Der Unterschied liegt im genauen Hinschauen

Projekte, die auch in kritischen Phasen steuerbar bleiben, unterscheiden sich meist nicht dadurch, dass sie weniger Probleme haben. Sie unterscheiden sich dadurch, dass Probleme früher auffallen.

Das heißt: Nicht nur fragen, ob ein Status grün, gelb oder rot ist, sondern wie lange er das schon ist. Nicht nur zählen, wie viele offene Punkte es gibt, sondern ob sie sich in dieselbe Richtung häufen – zum Beispiel alle rund um dieselbe Schnittstelle oder denselben Fachbereich. Und nicht nur auf einzelne Berichte schauen, sondern die Verbindung zwischen ihnen: Was bedeutet ein offener fachlicher Punkt für den Testplan? Was bedeutet eine verzögerte technische Entscheidung für die Qualität am Go-live?

Diese Verbindungen herzustellen ist selten die Aufgabe einer einzelnen Rolle. Es ist die Aufgabe von jemandem, der bewusst über alle Bereiche hinwegschaut – ähnlich wie ein Fluglotse, der nicht nachvollzieht, was in einem einzelnen Cockpit passiert, sondern sieht, wie sich alle Bewegungen zueinander verhalten.

Projektsteuerung beginnt deshalb nicht erst, wenn eskaliert wird. Sie beginnt in der alltäglichen Bewertung genau dieser kleinen Signale – lange bevor jemand das Wort Eskalation überhaupt in den Mund nimmt.

Was das im Projektalltag bedeutet

Konkret heißt das für uns: offene Punkte nicht nur sammeln, sondern regelmäßig fragen, warum sie noch offen sind. Abhängigkeiten zwischen Teams aktiv nachverfolgen, statt sie einmal zu dokumentieren und dann zu vergessen. Und vor allem: auch unbequeme Zwischenstände ansprechen, bevor sie zu einem Endstand werden, den niemand mehr ändern kann.

Das bedeutet nicht, jedes kleine Risiko dramatisch zu behandeln. Es bedeutet, früh genug hinzuschauen, damit aus einer Verzögerung kein Rückstand wird und aus einem Rückstand keine Krise.

Fazit

Ein Projekt kippt selten plötzlich. Meist wird es kritisch, weil genug kleine Signale lange genug ignoriert wurden. „Plötzlich kritisch“ bedeutet in der Praxis oft: Es wurde zu lange nicht ehrlich hingeschaut.

Die gute Nachricht dabei: Genau das macht Schieflagen auch vermeidbar. Wer weiß, worauf zu achten ist – wiederkehrende Verzögerungen, Signale, die sich häufen, eine Teamstimmung, die kippt –, erkennt eine Schieflage oft Wochen bevor sie einen Namen bekommt. Die eigentliche Aufgabe der Projektsteuerung ist deshalb nicht, erst auf die Krise zu reagieren. Sie liegt darin, nah genug am Projekt zu sein, um die Signale zu erkennen, bevor sie sich zu einer Krise summieren.

Häufen sich in Ihrem Projekt kleine Verzögerungen, offene Punkte oder Abhängigkeiten, ohne dass klar ist, was das in der Summe bedeutet? In einem unverbindlichen Austausch ordnen wir gemeinsam ein, welche Signale gerade wirklich zählen.

Kontaktieren Sie uns unter: office@gruener-it.at

Das ist der zweite Teil unserer PM-Serie über die Dinge, die im Projektalltag wirklich den Unterschied machen. Im nächsten Teil geht es darum, warum ein grüner Status nicht automatisch bedeutet, dass alles in Ordnung ist.