So haben wir uns das
nicht vorgestellt.
Der Kickoff war gut.
Das Budget war genehmigt.
Der Zeitplan wirkte realistisch.
Alle haben zugestimmt.
Sechs Monate später sieht es anders aus.
Mehrkosten die niemand geplant hat, ein Zeitplan der mehrfach verschoben wurde, ein Team das frustriert ist — und irgendwo der Satz der in solchen Momenten immer fällt.
Die Erklärung die danach kommt klingt meistens so:
… der Dienstleister hat nicht geliefert
… die Technik hat nicht funktioniert
… die Anforderungen haben sich geändert.
Manchmal stimmt das.
Meistens ist es unvollständig.
Denn die eigentliche Frage ist selten was schiefgelaufen ist.
Die eigentliche Frage ist: Was war nie klar genug definiert?
Technik scheitert selten.
Was davor ungeklärt bleibt, umso öfter.
Technik funktioniert — sie ist berechenbar, dokumentiert, testbar.
Was nicht funktioniert sind die Dinge die vor der Technik geklärt sein müssten und es meistens nicht sind.
Zieldefinition.
Was soll das Projekt konkret erreichen — nicht in technischen Spezifikationen, sondern in unternehmerischen Ergebnissen?
Was ändert sich für wen, was wird besser, was wird aufgegeben?
Wer diese Fragen nicht beantwortet hat, startet ein Projekt ohne Ziel.
Und ohne Ziel gibt es keinen Erfolg.
Entscheidungsgeschwindigkeit.
Projekte stocken selten weil Technik stockt.
Sie stocken weil Entscheidungen warten, weil niemand zuständig ist, weil Abstimmungen eskalieren statt entschieden zu werden.
Jede Woche ohne Entscheidung ist eine Woche n der das Projekt Kosten erzeugt ohne voranzukommen.
Priorisierung.
Was hat Vorrang wenn zwei Anforderungen kollidieren?
Was ist Muss — und was ist Wunsch?
Wer das nicht vorab klärt, entscheidet es unter Druck. Und Entscheidungen unter Druck
sind selten die besten.
Interne Verantwortung.
Wer trägt das Projekt auf Unternehmensseite — nicht den Dienstleister koordinieren,
sondern Verantwortung übernehmen.
Wer diese Frage offenlässt, hat ein Projekt ohne Eigentümer.
Und ein Projekt ohne Eigentümer gehört niemandem.
Das sind keine Technikfragen.
Das sind Führungsfragen.
Was Führung in IT-Projekten bedeutet.
Drei Dinge — kein Micromanagement.
Erfolg klar definieren bevor das Projekt beginnt.
Was konkret erreicht werden soll, was sich für wen verändert, woran alle erkennen ob das Projekt erfolgreich war. Diese Definition ist keine technische Aufgabe.
Sie ist eine Führungsaufgabe.
Und sie kann nicht delegiert werden.
Entscheidungswege klären bevor sie gebraucht werden.
Wer entscheidet was, wie schnell, und was passiert wenn Entscheidungen eskalieren müssen.
Ein Projekt das diese Fragen vorab klärt läuft anders als eines das sie im laufenden
Betrieb beantwortet.
Eingreifen wenn Ziel und Realität auseinanderlaufen.
Nicht wenn das Projekt fertig ist.
Nicht wenn das Budget überschritten ist.
Sondern wenn die ersten Signale sichtbar werden.
Das braucht kein technisches Wissen. Es braucht die Bereitschaft hinzuschauen.
Fast jedes gescheiterte IT-Projekt hat eine Erklärung — meistens zeigt sie auf die Technik,
auf den Dienstleister, auf äußere Umstände.
Manchmal stimmt das.
Meistens ist es der bequemere Teil der Wahrheit.
Der unbequemere Teil ist dieser:
Die meisten IT-Projekte scheitern nicht weil etwas Unvorhergesehenes passiert.
Sie scheitern weil Dinge die vorab hätten geklärt werden müssen es nicht wurden.
Ziele. Entscheidungswege. Verantwortung.
Das ist keine Schuldzuweisung.
Es ist eine nüchterne Beobachtung.
Und nüchterne Beobachtungen haben einen Vorteil:
Sie lassen sich beim nächsten Mal berücksichtigen.
Ein IT-Projekt ist kein Technikprojekt.
Es ist ein Veränderungsprojekt.
Technik implementiert man.
Veränderung führt man.
Wenn du gerade beim Lesen das Gefühl hattest: „Das klingt vertraut — wir haben ein Projekt das sich gerade so anfühlt“ — dann ist das der Moment. Der IT-Risiko- & Zukunftsreport stellt das vollständige Bild her bevor ein Projekt beginnt. Was kritisch ist, welche Abhängigkeiten bestehen, was als nächstes priorisiert werden sollte. Die Grundlage die Projekte trägt.
→ Zum IT-Risiko- & Zukunftsreport