Projektarbeit: Agile Methoden oder klassisch planen?

Hallo Sara, das Thema hatte ich im Projektmanagement-Modul auch als Fallstudie, daher kurz meine Einschätzung.

Für dein Beispiel (Prozesseinführung in einer Bankfiliale) würde ich mir die Anforderungsstabilität als zentrales Abgrenzungskriterium anschauen. Klassische Methoden funktionieren gut, wenn du zu Beginn schon weißt, wie der Zielprozess am Ende aussehen soll und die Umsetzung vor allem eine Frage der sauberen Planung und Reihenfolge ist. Bei Bankprozessen kommt oft noch die regulatorische Seite dazu - wenn Compliance-Vorgaben feststehen, ist das eher ein Argument für klassisch.

Die Vorteile von agilen Methoden liegen aber genau da, wo diese Stabilität fehlt:

• Flexibilität: Anforderungen können nach jedem Sprint angepasst werden, ohne dass gleich der ganze Projektplan umgeworfen wird
• schnelles Feedback: durch kurze Zyklen merkst du früh, ob der neue Prozess in der Praxis überhaupt funktioniert, bevor viel Aufwand investiert wurde
• bessere Einbindung der Mitarbeitenden: gerade bei Prozessänderungen, die Akzeptanz brauchen, hilft iteratives Vorgehen, weil Betroffene laufend Rückmeldung geben können

Als Argumentationslinie in der Arbeit würde ich empfehlen: nicht "agil vs. klassisch" als Dogma behandeln, sondern anhand von Kriterien wie Komplexität, Unsicherheit und Stakeholder-Einbindung abwägen. Hybride Ansätze sind in der aktuellen PM-Literatur durchaus anerkannt, also kein Vermeidungsgrund, sondern eher ein Zeichen für differenzierte Betrachtung.

Hallo Sara, Phil hat das schon gut aufgeschlüsselt, ich möchte die klassische Seite nochmal etwas stärker verteidigen, weil sie in solchen Diskussionen gerne etwas altbacken wegkommt - zu Unrecht, finde ich, gerade in deinem Bankkontext.

Wenn Ziel und Endzustand klar definiert sind und es feste Deadlines gibt (z. B. ein regulatorisch vorgegebenes Einführungsdatum oder ein Audit-Termin), bringt dir ein klassischer Ansatz mit Netzplantechnik handfeste Vorteile:

• Planungssicherheit: Du kannst Meilensteine, Budget und Ressourcen von Anfang an durchrechnen, das schätzen gerade Finance-nahe Bereiche, weil Controlling und Reporting darauf aufsetzen können.
• Nachvollziehbarkeit: Bei Projekten mit Dokumentationspflicht (und das ist im Bankenumfeld fast immer der Fall) ist die lückenlose Planungsdokumentation ein echter Pluspunkt, auch für spätere Prüfungen.
• Kritischer Pfad: Mit der Netzplantechnik siehst du sofort, welche Vorgänge zeitkritisch sind und wo Pufferzeiten überhaupt sinnvoll einsetzbar sind. Das ist bei festen Deadlines Gold wert, weil du frühzeitig siehst, wo es eng wird.
• Geringeres Abstimmungsaufwand im laufenden Betrieb: Wenn die Anforderungen stehen, musst du nicht in jedem Sprint neu priorisieren, das spart bei stabilen Projekten tatsächlich Zeit.

Als Merksatz für deine Arbeit: Klassisch punktet dort, wo Planbarkeit mehr wert ist als Anpassungsfähigkeit. Ich würde das in der Argumentation klar gegen die Unsicherheits-Dimension von Phil stellen, dann hast du eine runde Abwägung.

Finde eure Punkte beide gut, möchte aber nochmal aus der Praxis ergänzen. Bei uns im Marketing haben wir letztes Jahr die Einführung eines neuen CRM-Prozesses begleitet, und wir sind tatsächlich hybrid gefahren - klassisch in der Grobplanung (Budget, Schulungstermine, Rollout-Datum standen fest und mussten ans Management berichtet werden), aber die eigentliche Prozessgestaltung lief in kurzen Zyklen mit Feedbackrunden aus den Teams.

Mein Learning daraus für solche Projektarbeiten: Die reine Theorie-Abwägung "klar definiert vs. unsicher" greift in der Praxis oft zu kurz, weil ein Projekt selten durchgehend das eine oder andere ist. Bei uns war z.B. der Zeitrahmen stabil (Pflichtargument für MaxFinance), aber wie genau die Mitarbeitenden den Prozess im Alltag nutzen würden, war am Anfang gar nicht klar - das kam erst durch Testläufe raus.

Für deine Arbeit, Sara, würde ich das so argumentieren: nimm die Kriterien (Stabilität der Anforderungen, Stakeholder-Einbindung, regulatorische Vorgaben) und prüfe sie für einzelne Projektphasen statt für das Projekt als Ganzes. Dann kannst du begründen, warum z.B. die Rahmenplanung klassisch bleibt, aber die Umsetzung agile Elemente bekommt. Das wirkt methodisch reflektierter als eine pauschale Entscheidung für eine Seite und lässt sich auch gut mit Literatur zu hybridem PM stützen.