Warum IT-Projekte scheitern – und wie Sie es verhindern
Es liegt selten an der Technik
Ein neues IT- oder Digitalisierungsprojekt startet meistens motiviert. Ziele wirken klar. Und trotzdem endet es oft mit Zeitverzug, Mehrkosten oder einem Ergebnis, das intern niemand wirklich will. Aber warum scheitern dann so viele IT-Projekte an zeit- oder Budget-Überschreitungen?
Dominik Wagner von do.vision bringt es im Gespräch auf den Punkt:
Es scheitert ja selten an der Technik.“
Dominik Wagner
Der häufigste Fehler im Requirement Engineering
Viele Fachbereiche formulieren Anforderungen als fertige Lösung. „Wir brauchen diesen Button.“ „Wir brauchen genau diesen Workflow.“
Das Problem dahinter bleibt oft ungeklärt. Dann baut das Team sauber. Aber am falschen Ziel vorbei.
Besserer Ansatz: Problem statt Feature
Starten Sie mit dem Problem in einem Satz: Was soll besser werden? Was kostet heute Zeit? Wo passieren Fehler?
Und dann erst klären: Welche Lösung hilft wirklich?
Kommunikation: Prototypen schlagen Annahmen
Ein Muster ist immer gleich: Es wird lange entwickelt. Dann sieht der Fachbereich das Ergebnis. Dann kommt die große Korrekturschleife.
Das ist teuer. Und es kostet Vertrauen.
Was hilft in der Praxis
- Klickbare Prototypen statt langer Dokumente
- Kurze Zyklen statt großer Releases
- Klare Rückfragen statt stiller Annahmen
Prioritäten sind ein Kostenhebel
Wenn „alles wichtig“ ist, wird es unkontrollierbar. Dominik sagt dazu: „Wenn alles dringend ist, ist irgendwie nichts dringend.“
Parallelität wirkt nach Geschwindigkeit. In Wahrheit sinkt Qualität. Und Nacharbeit frisst Zeit und Budget.
Die Rolle, die oft fehlt
Es braucht ein Zielbild. Und jemanden, der es verteidigt. Sonst gewinnen Einzelwünsche statt Nutzen.
Golden Hammer vermeiden: Nicht jedes Problem braucht Code
Manche Probleme lösen sich nicht durch neue Software. Manchmal ist der Prozess das Problem. Oder es gibt bereits ein System, das 80% abdeckt.
Wer vor dem Bauen den Grund klärt, spart später Wartung und Komplexität.
KI und Vibe Coding: sinnvoll, aber nicht blind
KI kann beim Prototyping helfen und bei einfachen Aufgaben. Sie ersetzt aber keine Architekturentscheidungen, Reviews und Qualitätsstandards.
Wenn KI einfach nur mehr Code liefert, steigt oft der Review-Aufwand. Und Fehler werden schwerer zu finden.
Mini-Checkliste vor dem Projektstart
- Haben wir ein klares Zielbild, das alle verstanden haben?
- Gibt es eine Priorisierung, die auch durchgesetzt wird?
- Haben wir frühe Feedback-Schleifen (Prototypen, kurze Zyklen)?
- Sind Reviews, Tests und Standards fix eingeplant?
Bewerben Sie sich als Gast im Podcast
Sie haben ein Thema über das Sie gerne einer breiten Öffentlichkeit erzählen wollen?
Dann erzählen Sie es doch in unserem Podcast!
Schicken Sie Ihre Kontaktdaten mit Ihrem Thema an office@quickdraw.at
