30 Prozent über Budget - weil der Plan nicht zum Projekt passte?
Ergebnis zuerst: Was schiefgehen kann
30 Prozent Budgetüberschreitung und drei Wochen Verzug. So endete ein Produktkonfigurator-Projekt bei einem mittelgroßen Online-Händler. Der Grund war nicht fehlende Planung, sondern die falsche Art zu planen.
Ahmed sitzt im Kickoff-Meeting, Mittwoch, 10 Uhr. Seine Teamleiterin präsentiert einen durchgetakteten Projektplan: acht Wochen, fünf Phasen, feste Meilensteine. Ziele, Umfang, Budget und Abnahmekriterien stehen im Projektauftrag. Ahmed hat ihn selbst mitanalysiert, alle Pflichtbestandteile sind vorhanden. Dann meldet sich die Person aus dem Produktmanagement: "Die Ergebnisse aus dem letzten Kundentest liegen erst in zwei Wochen vor. Danach kommen garantiert noch Änderungen."
Der Plan steht, aber die Anforderungen nicht. Woran erkennst du, ob ein durchgeplanter Ablauf zu diesem Vorhaben passt?
Zwei Grundansätze: Wasserfall vs. agil
Projektmanagement kennt zwei Grundansätze:
Beim Wasserfallmodell durchläuft das Projekt feste Phasen nacheinander: Anforderungen erheben, planen, umsetzen, testen, live schalten. Jede Phase wird abgeschlossen, bevor die nächste beginnt. Änderungen nach Phasenabschluss sind teuer.
Bei agilen Methoden wie Scrum arbeitet das Team in kurzen Zyklen, sogenannten Sprints (meist zwei bis vier Wochen). Nach jedem Sprint gibt es ein funktionsfähiges Zwischenergebnis und Feedback. Anforderungen dürfen sich zwischen Sprints ändern, weil sie nicht von Anfang an komplett feststehen müssen.
Ahmeds Problem wird greifbar: Ein Wasserfallplan funktioniert, wenn alle Anforderungen zu Beginn klar sind. Fehlen sie, erzwingt jede spätere Änderung einen formalen Änderungsantrag - mit Kosten- und Zeitfolgen.
🤔 Frage dich: Was unterscheidet einen Shop-Relaunch, bei dem das komplette Design vorab feststeht, von der Entwicklung eines neuen Features, bei dem Kundenfeedback erst nach dem Start einfließt - und warum brauchen beide ein anderes Vorgehen?
Welche Methode passt zu welchem E-Commerce-Projekt?
Fünf Kriterien, zwei Projekttypen
Nicht jedes E-Commerce-Projekt braucht dieselbe Methode. Fünf Kriterien helfen bei der Zuordnung:
Ein Shop-Relaunch mit festem Corporate Design und fixem Migrationstermin passt zum Wasserfall: Die Anforderungen stehen, der Zeitrahmen ist starr.
Wann kippt die Entscheidung Richtung agil?
Drei Signale im Projektauftrag deuten auf ein agiles Vorgehen hin:
- Anforderungen sind unklar oder ändern sich voraussichtlich - wie beim Produktkonfigurator, wo Kundentests erst nach Projektstart Ergebnisse liefern.
- Kundenfeedback soll laufend einfließen, nicht erst am Ende. Typisch bei neuen Shop-Features, die echte Nutzungsdaten brauchen.
- Die Komplexität ist hoch und das Ergebnis lässt sich nicht vollständig vorausplanen. Je mehr Unbekannte, desto wertvoller sind kurze Feedback-Zyklen.
Umgekehrt spricht für Wasserfall: stabile Anforderungen, regulatorische Vorgaben (z.B. Datenschutz-Migration mit fester Deadline) und ein klar abgrenzbarer Projektumfang.
🧑🏫 Erkläre es im Kopf: Stell dir vor, du erklärst einer neuen Auszubildenden Person in je einem Satz, wann Wasserfall und wann Scrum die bessere Wahl ist - wie würdest du formulieren?
Was kostet die falsche Methode?
Drei Dimensionen, sechs Konsequenzen
So hätte es bei Ahmeds Produktkonfigurator enden können, wenn das Team beim Wasserfallplan geblieben wäre:
- Budget: Jeder nachträgliche Änderungsantrag erzeugt Mehrkosten für Analyse, Umplanung und erneute Tests. Bei drei bis vier größeren Änderungen steigt das Budget leicht um 30 Prozent. Gleichzeitig werden Fachkräfte doppelt gebunden, weil sie alte Phasen nacharbeiten und neue vorbereiten.
- Termine: Verschiebt sich eine Phase, verschieben sich alle folgenden Meilensteine mit. Der Livegang-Termin platzt. Bei einem saisonalen Online-Händler heißt das: Das Weihnachtsgeschäft läuft ohne den neuen Konfigurator.
- Teamstruktur: Im Wasserfall steuert die Projektleitung zentral. Wenn das Team kreative Lösungen für unklare Anforderungen finden soll, bremst diese Struktur. Entwickelnde warten auf Freigaben statt eigenständig zu entscheiden.
Deine Bewertung: Checkout-Optimierung
Neues Projekt: Ein Online-Händler will seinen Checkout-Prozess optimieren. Die Abbruchrate liegt bei 68 Prozent. Erste A/B-Tests zeigen, dass kleinere Änderungen (Formularfelder reduzieren, Zahlungsoptionen umstellen) große Wirkung haben. Welche Kombination am besten funktioniert, weiß noch niemand. Die Geschäftsführung will in sechs Wochen messbare Ergebnisse.
📝 Fasse mental zusammen: Welche drei Kriterien bestimmen, ob dieses Checkout-Projekt agil oder klassisch durchgeführt werden sollte - und wie fallen sie hier aus?
Teste dein Wissen
Alex' Projektteam nutzt ein klassisches Phasenmodell. Vergleiche die Risiken dieses Modells mit einem agilen Ansatz bei einem Shop-Feature-Projekt mit unklaren Anforderungen.