Warum ist die Wahl des Vorgehens so wichtig?
Das Vorgehen bestimmt, wie ein Projekt geplant, gesteuert und abgenommen wird. Ein klassisches Vorgehen legt Umfang, Termine und Kosten früh fest und steuert gegen diesen Plan. Ein agiles Vorgehen setzt einen Rahmen und plant die Umsetzung in kurzen Zyklen, wobei der Detailumfang auf Basis von Feedback angepasst wird. Wer das falsche Vorgehen wählt, erlebt typische Probleme: In einem klassisch geplanten Projekt mit unsicheren Anforderungen entstehen ständige Änderungsanträge und Konflikte; in einem agil geführten Projekt mit festem Ergebnis entsteht unnötiger Abstimmungsaufwand ohne echten Nutzen.
Die Norm ISO 21502 behandelt die Wahl des Liefermodells als bewusste Entscheidung und nennt prädiktive, inkrementelle, iterative, adaptive und hybride Vorgehen einschliesslich agiler Ansätze als Optionen [1]. Auch der PMBOK Guide betont in der achten Auflage, dass Vorgehen an den Kontext angepasst werden [2]. HERMES lässt bei der Initialisierung zwischen klassischem und agilem Vorgehen wählen [3].
Welche Kriterien entscheiden über das Vorgehen?
| Kriterium | spricht für klassisch | spricht für agil |
|---|---|---|
| Klarheit der Anforderungen | Ergebnis vollständig beschreibbar | Anforderungen unsicher oder entstehen erst durch Feedback |
| Kosten von Änderungen | Änderungen spät sehr teuer, etwa im Bau | Änderungen vergleichsweise günstig, etwa in Software |
| Technische Unsicherheit | bekannte Technik, erprobte Lösung | neue Technik, unbekannte Lösung |
| Verfügbarkeit der Fachleute | nur zu Meilensteinen verfügbar | regelmässig für Feedback verfügbar |
| Erwartung des Auftraggebers | feste Zusagen zu Umfang, Termin, Kosten | fester Rahmen, flexibler Umfang akzeptiert |
| Nutzen früher Teilergebnisse | Nutzen erst mit dem Gesamtergebnis | Teilergebnisse früh nutzbar |
| Regulatorische Vorgaben | formale Phasen und Dokumente vorgeschrieben | Vorgaben lassen iteratives Vorgehen zu |
Selten zeigen alle Kriterien in dieselbe Richtung. Deshalb hilft es, sie einzeln zu bewerten und dann zu entscheiden, welches Vorgehen überwiegt und welche Elemente der anderen Welt sinnvoll ergänzt werden. Wichtig ist, die Bewertung gemeinsam mit Auftraggeber und Team vorzunehmen und das Ergebnis festzuhalten, damit später nachvollziehbar ist, warum ein Vorgehen gewählt wurde.
Punkteraster: So bewerten Sie Ihr Projekt
Ein einfaches Raster macht die Entscheidung greifbar. Bewerten Sie jedes der sieben Kriterien auf einer Skala von eins (spricht klar für klassisch) bis fünf (spricht klar für agil). Die Summe liegt zwischen sieben und 35. Ein Wert bis etwa 15 spricht für ein klassisches Vorgehen, ein Wert ab etwa 27 für ein agiles, dazwischen für eine hybride Kombination. Das Raster ersetzt keine Entscheidung, strukturiert aber das Gespräch und macht unterschiedliche Einschätzungen sichtbar.
| Kriterium | Kundenportal | Büroumbau | CRM-Einführung |
|---|---|---|---|
| Klarheit der Anforderungen | 4 | 1 | 3 |
| Kosten von Änderungen | 4 | 1 | 3 |
| Technische Unsicherheit | 3 | 1 | 2 |
| Verfügbarkeit der Fachleute | 4 | 2 | 3 |
| Erwartung des Auftraggebers | 3 | 1 | 2 |
| Nutzen früher Teilergebnisse | 5 | 1 | 4 |
| Regulatorische Vorgaben | 4 | 2 | 3 |
| Summe | 27 (agil) | 9 (klassisch) | 20 (hybrid) |
Das Kundenportal profitiert von frühem Feedback der Nutzenden und günstigen Änderungen, deshalb agil. Der Büroumbau hat nach der Planung kaum Spielraum für Änderungen, deshalb klassisch. Die CRM-Einführung liegt dazwischen: Konfiguration und Datenmigration brauchen Planung, die Gestaltung der Abläufe profitiert von Iteration, deshalb hybrid mit klassischem Rahmen und agiler Umsetzung.
Wann ist hybrid die richtige Antwort?
Hybrid ist die Antwort, wenn Auftraggeber Planungssicherheit brauchen, die Umsetzung aber von Feedback profitiert. Typisch ist ein klassischer Rahmen mit Projektauftrag, Budget, Meilensteinen, Freigaben und Abschluss, innerhalb dessen das Team in Sprints arbeitet. HERMES bildet genau diese Kombination ab: Initialisierung und Abschluss werden immer klassisch abgewickelt, dazwischen liegt beim agilen Vorgehen die Phase Umsetzung [3]. Wie die Schnittstelle zwischen Rahmen und Team gestaltet wird, beschreibt der Beitrag Hybrides Projektmanagement in der Praxis.
Hybrid darf aber keine Ausrede für fehlende Regeln sein. Es muss klar sein, welche Elemente fix sind, welche flexibel bleiben, wer worüber entscheidet und wie berichtet wird. Wer das offen lässt, erhält nicht die Stärken beider Welten, sondern ihre Nachteile: die Bürokratie klassischer Planung und die Unverbindlichkeit schlecht gemachter Agilität.
Beispiele aus verschiedenen Branchen
- Softwareentwicklung für ein neues Produkt: agil, weil Anforderungen durch Nutzerfeedback entstehen und Releases früh Wert liefern.
- Migration eines Systems mit festem Abschalttermin des Altsystems: hybrid, mit klassischem Terminrahmen und agiler Abarbeitung der Migrationspakete.
- Bau eines Gebäudes: klassisch, weil Änderungen nach der Ausführungsplanung sehr teuer sind; agile Elemente höchstens in der Planungsphase.
- Marketingkampagne: agil oder Kanban, weil Inhalte auf Basis von Daten laufend angepasst werden.
- Organisationsentwicklung: agil in kurzen Zyklen mit Pilotbereichen, weil die Wirkung erst im Betrieb sichtbar wird.
- Öffentliche Ausschreibung mit festem Leistungsverzeichnis: klassisch, sofern der Vertrag keine iterative Konkretisierung vorsieht.
Woran erkennen Sie eine Fehlentscheidung?
Eine Fehlentscheidung zeigt sich meist in den ersten Wochen. Bei einem klassisch geplanten Projekt mit eigentlich unsicheren Anforderungen häufen sich Änderungsanträge, Abnahmen werden zum Streit, und das Team arbeitet an Lösungen, die bei der ersten Vorführung als falsch erkannt werden. Bei einem agil geführten Projekt mit festem Ergebnis klagt der Auftraggeber über fehlende Planungssicherheit, Reviews bringen kaum neue Erkenntnisse, und der Abstimmungsaufwand wirkt übertrieben.
In beiden Fällen ist eine Korrektur möglich und sinnvoll. Ein klassisch begonnenes Projekt kann in der Umsetzung auf kurze Zyklen umstellen; ein agiles Projekt kann einen verbindlicheren Rahmen mit Meilensteinen erhalten. Entscheidend ist, das Vorgehen als Werkzeug zu betrachten, das dem Projekt dient, und nicht als Bekenntnis.
Vorgehen im Werkzeug abbilden
Ein Projekttool sollte beide Vorgehen unterstützen: Phasen, Meilensteine und Budget für den klassischen Teil, Boards, Backlog und Zyklen für den agilen Teil. In Flenio lassen sich Projekte mit Phasen und Meilensteinen anlegen und Aufgaben gleichzeitig auf Boards planen, sodass ein Projekt auch während der Laufzeit zwischen den Welten wechseln kann. Wer klassisch plant, findet im Hub Projektplanung Schritt für Schritt die Grundlagen; wer agil startet, beginnt mit dem Beitrag Scrum Guide 2020 verständlich erklärt oder Kanban einführen.
Welche Denkmodelle helfen bei der Einordnung?
Zwei Denkmodelle werden häufig genutzt, um Projekte einzuordnen. Die Stacey-Matrix ordnet Vorhaben nach zwei Achsen: wie klar die Anforderungen sind und wie gut die technische Lösung bekannt ist. Sind beide klar, ist das Vorhaben einfach und lässt sich gut planen; ist beides unklar, ist es chaotisch. Dazwischen liegt der Bereich komplizierter und komplexer Vorhaben, in dem agile Ansätze ihre Stärken ausspielen. Das Cynefin-Modell unterscheidet ähnlich zwischen klaren, komplizierten, komplexen und chaotischen Situationen und empfiehlt für komplexe Situationen ein Vorgehen aus Ausprobieren, Beobachten und Reagieren.
Beide Modelle sind Orientierungshilfen, keine Rechenformeln. Ihr Wert liegt darin, ein gemeinsames Vokabular zu schaffen: Wenn Auftraggeber und Team sich einig sind, dass ein Vorhaben komplex ist, fällt die Entscheidung für iteratives Vorgehen leichter. Ist es dagegen kompliziert, aber gut analysierbar, kann eine sorgfältige Planung durch Fachleute der effizientere Weg sein.
Wie halten Sie die Entscheidung fest?
Die Wahl des Vorgehens gehört in den Projektauftrag oder das Projekthandbuch, mit einer kurzen Begründung: Welche Kriterien waren ausschlaggebend, welche Elemente der anderen Welt werden ergänzt, und wann wird die Entscheidung überprüft? Eine Überprüfung nach den ersten Zyklen oder beim ersten Meilenstein hat sich bewährt. So bleibt die Entscheidung bewusst, und ein Wechsel ist möglich, ohne dass er als Scheitern empfunden wird. Ein Projekt, das mit klassischer Planung beginnt und in der Umsetzung auf Sprints umstellt, hat nichts falsch gemacht, sondern gelernt.
Eine praktische Ergänzung ist ein kurzer Workshop zu Projektbeginn, in dem Auftraggeber, Projektleitung und Team das Punkteraster gemeinsam ausfüllen. Unterschiedliche Bewertungen sind dabei kein Problem, sondern wertvolle Hinweise: Wenn der Auftraggeber die Anforderungen für klar hält und das Team für unsicher, liegt genau dort das grösste Projektrisiko, und es lohnt sich, diese Differenz vor dem Start zu klären.
Die Entscheidung ist damit keine Glaubensfrage, sondern eine nüchterne Abwägung, die sich an der Situation des Projekts orientiert. Sie darf und soll im Verlauf überprüft werden.
Ein Wechsel des Vorgehens ist kein Eingeständnis eines Fehlers, sondern Ausdruck guter Steuerung, die auf neue Erkenntnisse reagiert.
Vorgehenswahl in ISO 21502, PMBOK und HERMES
Die ISO 21502 behandelt alle Liefermodelle als gleichwertig und verlangt, das passende bewusst zu wählen. Der PMBOK Guide stellt mit Fokusbereichen und Tailoring ein Rahmenwerk bereit, das prädiktive, agile und hybride Vorgehen abdeckt. HERMES lässt in der Initialisierung zwischen klassischem und agilem Vorgehen wählen und hält Initialisierung und Abschluss in beiden Fällen klassisch. Den Gesamtzusammenhang zeigt der Leitfaden Agiles Projektmanagement in der Praxis.