„Wir machen das jetzt agil“ – oder: „Bei uns geht nur Wasserfall.“ In vielen Unternehmen wird die Frage nach dem richtigen Vorgehen wie eine Glaubensfrage behandelt. Dabei ist die Wahl zwischen agilem und klassischem Projektmanagement vor allem eine Sachfrage: Wie klar sind die Anforderungen, wie groß ist die technische Unsicherheit, welche Vorgaben gelten, und wie arbeitet die Organisation? Dieser Artikel zeigt die wesentlichen Unterschiede, nennt konkrete Entscheidungskriterien und erklärt, wann ein hybrides Vorgehen sinnvoll ist – und wann nicht.
Beim klassischen Projektmanagement – oft als Wasserfall oder plangetriebenes Vorgehen bezeichnet – wird das Projekt in aufeinanderfolgende Phasen gegliedert: Initiierung, Analyse, Konzeption, Umsetzung, Test, Einführung und Abschluss. Umfang, Termine und Budget werden zu Beginn möglichst vollständig geplant; Lasten- und Pflichtenheft beschreiben, was geliefert wird. Meilensteine und Phasenfreigaben (Quality Gates) machen den Fortschritt messbar. Im öffentlichen Bereich ist das V-Modell XT verbreitet, das jeder Entwicklungsstufe eine passende Teststufe gegenüberstellt.
Die Stärke des klassischen Ansatzes ist Planbarkeit: Alle Beteiligten wissen früh, was wann geliefert wird und was es kostet. Die Schwäche zeigt sich, wenn sich Anforderungen während des Projekts ändern. Dann wird jede Änderung zum formalen Change Request, und Fehlentwicklungen werden oft erst im Test sichtbar – zu einem Zeitpunkt, an dem Korrekturen teuer sind.
Agiles Projektmanagement geht davon aus, dass sich nicht alles im Voraus planen lässt. Statt eines vollständigen Plans gibt es ein Produktziel und ein priorisiertes Backlog. Das Team liefert in kurzen Iterationen – in Scrum sind das Sprints von höchstens einem Monat – jeweils ein nutzbares Inkrement, holt Feedback ein und passt die Planung an. Grundlage ist das Agile Manifest von 2001, das unter anderem funktionierende Software und Reaktion auf Veränderung höher bewertet als umfassende Dokumentation und das Befolgen eines Plans.
Die bekanntesten Frameworks sind Scrum und Kanban; für mehrere Teams gibt es Skalierungsansätze wie SAFe oder LeSS. Agilität ist dabei mehr als ein Satz Meetings. Ohne echte Entscheidungskompetenz beim Product Owner und ohne eine Organisation, die Ergebnisse statt Pläne bewertet, bleibt es bei agilen Ritualen in einem klassischen Rahmen – mehr dazu in unserem Artikel Agile Transformation: Was Scrum wirklich bedeutet.
Eine hilfreiche Orientierung bietet die Frage nach Klarheit und Unsicherheit, wie sie auch die Stacey-Matrix beschreibt: Je klarer die Anforderungen und je bekannter die Technologie, desto besser funktioniert ein plangetriebenes Vorgehen. Je unklarer das Ziel und je neuer die Technik, desto mehr spricht für iteratives Arbeiten. In der Praxis kommen weitere Kriterien hinzu:
Ein Kriterium wird oft übersehen: die Vertragsform. Ein klassischer Festpreis mit fixem Leistungsumfang passt schlecht zu einem Vorgehen, bei dem sich der Umfang bewusst verändert. Wer agil arbeiten will, sollte das schon in Ausschreibung und Vertrag berücksichtigen, etwa mit einem festen Budgetrahmen und variablem Umfang.
Viele IT-Projekte in mittelständischen Unternehmen und Konzernen arbeiten heute hybrid. Ein typisches Muster: Ein klassischer Rahmenplan mit Meilensteinen, Budget und Phasenfreigaben gibt dem Management Planungssicherheit, während die Softwareentwicklung innerhalb dieses Rahmens in Sprints organisiert ist. Ein anderes Muster kombiniert agile Entwicklungsteams mit klassisch geplanten Gewerken wie Infrastruktur, Datenmigration oder Schulung.
Hybrid funktioniert, wenn die Schnittstellen bewusst gestaltet werden: Wie fließen Erkenntnisse aus den Sprints in den Rahmenplan zurück? Wer entscheidet über Umfangsänderungen? Wie wird ein Meilenstein bewertet, wenn der Umfang variabel ist? Bleiben diese Fragen offen, entsteht das Schlechteste aus beiden Welten: ein starrer Plan, der regelmäßig verfehlt wird, plus agile Meetings ohne echten Entscheidungsspielraum. Auch der PMI-Standard trägt dem Rechnung: Der PMBOK Guide beschreibt seit der siebten Ausgabe ausdrücklich prädiktive, adaptive und hybride Vorgehensweisen.
Besonders deutlich wird der Unterschied beim Testen. Im klassischen Vorgehen gibt es eigene Testphasen mit Systemtest, Integrationstest und Abnahme, geplant in einem Testkonzept. Das Risiko: Wird die Umsetzung knapp, wird die Testphase gekürzt. Agil ist Testen Teil jeder Iteration. Eine Story gilt erst als fertig, wenn sie die Definition of Done erfüllt – inklusive Tests. Damit das bei jedem Sprint funktioniert, braucht es wachsende, idealerweise automatisierte Regressionstests. In beiden Welten gilt: Qualitätssicherung muss im Projektplan fest eingeplant sein, nicht als Puffer am Ende.
Die Frage „agil oder klassisch?“ lässt sich nicht pauschal beantworten. Klassisches Projektmanagement spielt seine Stärken bei klaren Anforderungen, festen Vorgaben und vielen Abhängigkeiten aus. Agiles Projektmanagement ist überlegen, wenn das Ziel erst im Lauf des Projekts klar wird und frühes Feedback den Unterschied macht. Häufig ist ein bewusst gestaltetes hybrides Vorgehen die realistischste Lösung. Entscheidend ist, die Methode an Projekt und Organisation anzupassen – nicht umgekehrt. Wie Sie Termine und Budget unabhängig von der Methode im Griff behalten, lesen Sie in IT-Projekte im Zeit- und Budgetplan: So geht es wirklich.
Nicht grundsätzlich. Agiles Projektmanagement eignet sich besonders, wenn Anforderungen unklar sind oder sich häufig ändern. Klassisches Projektmanagement ist im Vorteil, wenn Umfang, Vorgaben und Abhängigkeiten früh feststehen. Entscheidend ist, welcher Ansatz zum konkreten Projekt und zur Organisation passt.
Hybrides Projektmanagement kombiniert Elemente beider Ansätze, zum Beispiel einen klassischen Rahmenplan mit Meilensteinen und Budget und eine agile Umsetzung der Softwareentwicklung in Sprints. Damit das funktioniert, müssen Entscheidungswege und Schnittstellen zwischen beiden Ebenen klar geregelt sein.
Ja, aber nicht mit einem fest definierten Leistungsumfang. Bewährt haben sich Verträge mit festem Budget- und Zeitrahmen, in denen der Umfang über Priorisierung gesteuert wird. Ein Festpreis mit fixem Umfang und agiler Umsetzung führt dagegen häufig zu Konflikten über Änderungen.
30 Minuten Erstgespräch — kostenlos und unverbindlich. Wir schauen gemeinsam auf Ihr Vorhaben und zeigen, ob klassisch, agil oder hybrid am besten passt.
Jetzt Erstgespräch vereinbarenMehr zu unserer Leistung: IT-Projektmanagement in Hamburg →
Passend dazu: Scrum Master & Agile Coach in Hamburg →