
Marc H.,
TLDR;
Die meisten IT-Projekte überschreiten ihr Budget nicht wegen schlechter Planung oder unfähiger Anbieter – das Problem ist strukturell. 70% aller IT-Projekte kosten mehr als geplant, durchschnittlich 27-43% über Budget. In diesem Artikel zeigen wir dir die versteckten Kostentreiber, die Anreizprobleme der Branche, und wie du budgetierst wie jemand, der das schon hundert Mal gemacht hat.

Das IT-Projekt-Paradox
Du kennst das Szenario.
Das Angebot kommt rein. CHF 150'000 für die neue Software. Alles klar definiert, schöne Präsentation, der Anbieter wirkt kompetent. Du unterschreibst.
Sechs Monate später: CHF 230'000. Und du fragst dich, was schiefgelaufen ist.
Hier ist die Sache... es ist wahrscheinlich nichts schiefgelaufen. Zumindest nichts Ungewöhnliches. Du hast einfach die Statistik erlebt.
70% der IT-Projekte überschreiten ihr Budget. Das ist kein Ausreisser – das ist der Normalfall.
Die Zahlen, die niemand ausspricht
Lass uns kurz über die Realität sprechen. Nicht die Marketing-Version, die dir Anbieter erzählen. Die echte.

Was die Forschung zeigt:
70% der IT-Projekte überschreiten ihr Budget (PMI, Standish Group)
27-43% durchschnittliche Kostenüberschreitung bei diesen Projekten
Nur 35% werden im ursprünglichen Budget abgeschlossen
17% sind "Black Swans" – Projekte mit 200-400% Kostenüberschreitung
Lies das nochmal. Nur etwa ein Drittel aller IT-Projekte bleibt im Budget. Zwei Drittel nicht.
Und dann gibt es die Extremfälle. McKinsey hat herausgefunden, dass fast jedes fünfte IT-Projekt ein "Black Swan" ist – ein Projekt, das völlig aus dem Ruder läuft. Nicht 20% über Budget. 200-400% über Budget.
Das sind keine schlechten Projekte von schlechten Firmen. Das ist die Realität der IT-Branche.
Scope Creep ist nicht das Problem
"Scope Creep!" – das ist meistens die erste Erklärung, wenn Projekte teurer werden.
Aber hier ist, was wir nach dutzenden Projekten gelernt haben: Scope Creep ist nicht das Problem. Scope Creep ist ein Symptom.
52% aller Projekte sind von Scope Creep betroffen. Aber warum?
Die eigentlichen Ursachen:
Unklare Anforderungen von Anfang an – 37% der Projektfehlschläge kommen von unklaren Zielen
Verträge, die Änderungen nicht realistisch abbilden – "Was nicht explizit drinsteht, kostet extra"
Fehlende Puffer für Unvorhergesehenes – Jede Änderung wird zum teuren Change Request
Das Problem ist nicht, dass sich Anforderungen ändern. Das tun sie immer. Das Problem ist, dass die ursprüngliche Schätzung so tut, als würden sie das nicht.
Die versteckten Kostentreiber
Jetzt wird's interessant. Diese Kosten stehen in keinem Angebot – aber sie kommen. Garantiert.

1. Integrations-Komplexität
Das Problem: Deine bestehenden Systeme sind komplexer als dokumentiert.
Typische Auswirkung: +15-30% der geschätzten Kosten
Das alte ERP, das "eigentlich nur eine Schnittstelle braucht"? Hat drei undokumentierte Workarounds, die irgendwann vor zehn Jahren eingebaut wurden. Niemand weiss mehr genau warum. Aber ohne sie bricht alles zusammen.
2. Datenmigration
Das Problem: Die Datenqualität ist schlechter als angenommen. Mapping ist komplexer als gedacht.
Typische Auswirkung: +20-40% der Migrationskosten
"Die Daten sind sauber" – haben wir schon hundert Mal gehört. Waren sie noch nie. Nie. Duplikate, fehlende Felder, inkonsistente Formate, historische Altlasten. Das alles muss bereinigt werden, bevor migriert werden kann.
3. Training & Adoption
Das Problem: Schulung und Change Management werden chronisch unterschätzt.
Typische Auswirkung: +10-20% der Gesamtkosten
Die Software ist live. Technisch alles perfekt. Und dann... nutzt sie niemand richtig. Weil niemand Zeit hatte, die Mitarbeiter vernünftig zu schulen. Also läuft das alte System parallel weiter. Oder es entstehen Workarounds, die die neue Logik untergraben.
4. Parallelbetrieb
Das Problem: Altes und neues System müssen gleichzeitig laufen.
Typische Auswirkung: +15-25% während der Übergangsphase
Du zahlst plötzlich für zwei Systeme, zwei Wartungsverträge, zwei Teams die beide kennen müssen. Und der "kurze Parallelbetrieb" von drei Monaten wird zu sechs. Oder zwölf.
5. Versteckte technische Schulden
Das Problem: Die technischen Schulden im Altsystem werden erst während des Projekts sichtbar.
Typische Auswirkung: Unvorhersehbar – oft +20-50%
"Das haben wir damals so gemacht, weil es schnell gehen musste." Diese Shortcuts von vor fünf Jahren? Die rächen sich jetzt. Und sie aufzuräumen war nie Teil des Angebots.
6. Vendor-Abhängigkeiten
Das Problem: Externe Partner liefern nicht pünktlich oder in der erwarteten Qualität.
Typische Auswirkung: +10-15%
Dein Projekt wartet auf die API vom Drittanbieter. Die kommt zwei Monate später. Dein Team steht in der Zwischenzeit nicht still – sie arbeiten an Workarounds, die später wieder umgebaut werden müssen.
Das Angebots-Problem
Hier ist eine unbequeme Wahrheit: Die Anreizstrukturen in der IT-Branche arbeiten gegen realistische Schätzungen.
Wie Anbieter kalkulieren
Low-Ball Bids: Der Anbieter mit dem niedrigsten Angebot gewinnt. Also wird knapp kalkuliert. Sehr knapp. Die Differenz holt man später über Change Requests rein.
Optimistische Schätzungen: Das Angebot basiert auf dem Best-Case-Szenario. Alles läuft perfekt, keine Überraschungen, der Kunde weiss genau was er will. Das passiert... eigentlich nie.
Stundenabrechnung: Bei Time & Material hat der Anbieter keinen Anreiz zur Effizienz. Längeres Projekt = mehr Umsatz. Das ist nicht böswillig. Es ist einfach... Geschäft.
Scope-Ambiguität als Feature: Was nicht explizit im Vertrag steht, wird später als Zusatzleistung berechnet. Je vager das ursprüngliche Angebot, desto mehr Spielraum für Nachträge.
Versteh uns nicht falsch – die meisten IT-Anbieter sind keine Betrüger. Sie arbeiten einfach in einem System, das unrealistische Schätzungen belohnt und realistische bestraft.
Wie du realistisch budgetierst
Genug Problemanalyse. Hier ist, was erfahrene Projektleiter anders machen.
Die Drei-Punkt-Schätzung
Vergiss einzelne Zahlen. Jedes seriöse Budget braucht drei Szenarien:
Szenario | Beschreibung | Wahrscheinlichkeit |
|---|---|---|
Optimistisch | Alles läuft perfekt | ~10% |
Realistisch | Normale Hürden, typische Verzögerungen | ~70% |
Pessimistisch | Signifikante Probleme treten auf | ~20% |
Die Formel: Budget = (Optimistisch + 4×Realistisch + Pessimistisch) / 6
Wenn dein Anbieter dir nur eine Zahl gibt, hast du wahrscheinlich die optimistische Schätzung bekommen.
Contingency-Planung
Jedes IT-Projekt braucht einen Puffer. Aber wie gross?
Projekttyp | Empfohlene Reserve |
|---|---|
Kleine, bekannte Projekte | 15-20% |
Mittlere Projekte | 20-30% |
Grosse, komplexe Projekte | 30-50% |
Neue Technologie | 40-60% |
Ja, 40-60% bei neuer Technologie. Das klingt nach viel. Aber schau dir die Statistiken oben nochmal an.
Was erfahrene Projektleiter tun
Historische Daten nutzen – Wie liefen ähnliche Projekte in der Vergangenheit?
Unabhängige Schätzungen einholen – Nicht nur vom Anbieter, der den Auftrag will
Bottom-up UND Top-down schätzen – und die Unterschiede verstehen
Phasenweise Budget-Gates – Nicht alles auf einmal freigeben
Change Management von Anfang an definieren – Wie werden Änderungen bewertet und bepreist?
Die Fragen, die du deinem Anbieter stellen solltest
Hier ist dein Werkzeugkasten für das nächste Anbietergespräch:
Vor der Unterschrift:
"Was ist NICHT im Angebot enthalten?"
"Welche Annahmen haben Sie für diese Schätzung getroffen?"
"Was passiert, wenn sich Anforderungen ändern?"
"Wie viel Contingency ist eingerechnet?"
"Können Sie mir Referenzprojekte nennen – mit finalen Kosten vs. ursprünglichem Angebot?"
Die letzte Frage ist die wichtigste. Ein Anbieter, der dir ehrlich sagen kann "Das Projekt X war 15% über Budget wegen Y", ist Gold wert. Einer, der behauptet, alle Projekte seien im Budget geblieben... na ja.
Die kurze Version
Hier ist, was du mitnehmen solltest:
70% der IT-Projekte überschreiten ihr Budget – das ist der Normalfall, nicht die Ausnahme
Scope Creep ist ein Symptom, nicht die Ursache – das Problem sind unklare Anforderungen und unrealistische Verträge
Versteckte Kostentreiber (Integration, Migration, Training, Parallelbetrieb, Tech Debt) sind vorhersehbar – auch wenn sie nicht im Angebot stehen
Die Anreizstrukturen der Branche belohnen optimistische Schätzungen
Realistische Budgetierung heisst: Drei-Punkt-Schätzung, angemessene Reserves, historische Daten nutzen
Was tun?
Das nächste Mal, wenn ein IT-Angebot auf deinem Tisch landet:
Nimm die Zahl
Frag nach den Annahmen
Rechne mindestens 25-30% Reserve ein
Stell die fünf Fragen von oben
Und wenn du dir denkst "Ich hätte gerne jemanden, der mir hilft, das Angebot realistisch einzuschätzen, bevor ich unterschreibe" – genau das machen wir. Ohne eigene Agenda, ohne Vendor-Partnerschaften, ohne Interesse daran, dass das Projekt grösser wird als nötig.
(Wir verdienen nicht mehr, wenn dein Projekt teurer wird. Das macht einen Unterschied.)
Verwandte Artikel:


