Projektmanagement – klassisch, agil oder hybrid?
Projektmanagement – klassisch, agil oder hybrid?
21. März 2023
Wann sollte das klassische Projektmanagement und wann das agile genutzt werden? Diese Frage scheint auch nach Jahren des Aufkommens der agilen Methodik nicht flächendeckend beantwortet zu sein. Laut Google ist dies noch immer eines der am häufigsten gesuchten Themen rund um Projektmanagement und einer der Gründe, warum ich dieser Frage, den damit verbundenen Unsicherheiten und Lösungsmöglichkeiten auf den Grund gehen möchte.
Überblick über die klassische vs. agile Methode
Starten wir hierzu zunächst mit einem kurzen Überblick über die Unterschiede entsprechend der Theorie (es handelt sich hierbei um die wichtigsten Auszüge):
|
Themenbereich |
Klassisch |
Agil |
|
Vorgehensweise |
Aufeinanderfolgendes, klares Vorgehen |
Vorgehen wird von Sprint zu Sprint geplant |
|
Lieferergebnisse |
Werden vor allem am Projektende erwartet |
Werden nach jedem Sprint erwartet |
|
Arbeitspakete |
Definition von Arbeitspaketen, deren Abhängigkeiten und Anordnen in logischer Reihenfolge |
Arbeitspakete werden iterativ zusammengestellt und innerhalb einer bestimmten Zeit bearbeitet (ohne Abhängigkeit zueinander) |
|
Risikomanagement |
Tendenz zur Verschiebung von Meilensteinen, wenn der Plan nicht zutrifft |
Verringerung der Aufwände / des Lieferumfangs, bei nicht zutreffender Sprintplanung |
|
Qualitätsmanagement durch den Anwender |
Meist nur während Testphase |
Ständige Reviews / kontinuierliches Testing |
|
Organisation |
Projektorganisation wird meistens über die Linie organisiert und ist zumeist in mehreren Projekten parallel aktiv |
Projektorganisation besteht aus einem selbstorganisierten Team, welches ausschliesslich auf diesem einen Projekt aktiv ist |
|
Änderungen |
Änderungen müssen zuerst auf ihre Auswirkungen mit Hinblick auf die Rahmenbedingungen bewertet und freigegeben werden, um die Abhängigkeiten zwischen den Arbeitspaketen nicht zu gefährden |
Änderungen sind einfacherer zu handhaben, da die Arbeitspakete iterativ in den Sprints zusammengestellt werden |
|
Kosten |
Hohe Kosten für späte Änderungen |
Mässige Kosten bei Änderungen |
Soweit die Theorie, welche die Unterschiede eigentlich klar darstellt und uns somit einen Leitfaden an die Hand gibt, welche Projekte zum jeweiligen Ansatz gehören. Kurz kann man die oben genannten Punkte in die nachfolgende Grafik übersetzen:
Aber wie es immer so ist, sind Theorie und Praxis eben doch zweierlei. Wenn man die Theorie statisch, ohne weitere Abstraktion, auf die Praxis übertragen würde, würde es meistens nicht klar auf klassisch oder agil hinauslaufen, da es immer Gründe gibt, die für die eine oder andere Vorgehensweise sprechen. Einige betrachten das Projekt daher nicht mehr anhand der Rahmenbedingungen, welche oben verglichen werden, sondern anhand der Arbeitspakete, aber auch hier gibt es immer Gründe, welche eher klassisch oder eben andersherum agil behandelt werden müssten – laut der Theorie. Dies könnte man dann weiter herunterbrechen auf die Aktivitätenebene und so weiter. Die Entscheidungsschwierigkeiten ziehen sich dabei aber letztlich immer weiter durch. Somit ist es also verständlich, warum eine klare Entscheidung für das Vorgehensmodell schwerfallen kann.
Um dies zu verdeutlichen, zeige ich Ihnen im nächsten Schritt anhand zwei unserer Projekte auf, welche Ansätze wir, als Qudits, aus welchen Gründen angewandt haben. Sie werden sehen, dass es oft gar nicht schwarz oder weiss sein muss und warum die Arbeitspakete tatsächlich die richtige Ebene zur Auswahl des Ansatzes sein.
Zwei verschiedene Use Cases im Vergleich
Lassen Sie mich Ihnen also einen ersten Abriss über zwei verschiedene Projektbeispiele geben und diese, rein entsprechend der Theorie, auf dem obersten Level in die jeweilige Vorgehensweise kategorisieren.
- Beispiel 1 – Umsetzung eines neuen Gesetzes in die notwendigen Prozesse und Systeme unter Berücksichtigung der bestehenden IT-Architektur
- Beispiel 2 – Update und Validierung einer bestehenden, regulatorisch-kritischen Anwendung innerhalb eines begrenzten Zeitraums
Eine erste Kategorisierung sieht dabei nun wie folgt aus:
|
Themenbereich |
Beispiel 1: Neues Gesetz |
Beispiel 2: Update & Validierung |
|
Vorgehensweise |
Das Gesetz ist neu und damit die Vorgehensweise zur Umsetzung nicht absolut klar Agil |
Das Update wird auf jährlicher Basis durchgeführt, das Vorgehen ist sehr klar Klassisch |
|
Lieferergebnisse |
Werden in kurzen Abständen erwartet Agil |
Werden auch zwischendurch, aber auf jeden Fall am Ende erwartet Klassisch / Agil |
|
Arbeitspakete |
Die Arbeitspakete sind weitestgehend definiert und die logische Reihenfolge ist klar Klassisch |
Die Arbeitspakete sind mit ihren Abhängigkeiten definiert und die logische Reihenfolge ist klar Klassisch |
|
Risikomanagement |
Aufgrund des definierten Datums, zu welchem das Gesetz in Kraft tritt, müssen potenzielle Auswirkungen auf die Meilensteine durch Anpassungen der restlichen Rahmenbedingungen abgefangen werden Agil |
Aufgrund der anzuwendenden Regularien zu einem Stichtag müssen potenzielle Auswirkungen auf die Meilensteine ebenfalls durch Anpassung der restlichen Rahmenbedingungen abgefangen werden Agil |
|
Qualitätsmanagement durch den Anwender |
Die Prozesse und Systeme müssen bis zum Inkrafttreten ständig gereviewed und kontinuierlich getestet werden Agil |
Die Installationen auf den verschiedenen Umgebungen müssen jeweils kontinuierlich gereviewed und getestet werden Agil |
|
Organisation |
Projektorganisation ist über die Linie gesteuert Klassisch |
Projektorganisation ist ebenfalls durch die Linie gesteuert Klassisch |
|
Änderungen / Kosten |
Jede Änderung generiert Kosten aufgrund der Programmieraufwände im System, da die notwendigen Prozesse aber noch nicht absolut klar sind, sind neue Anforderungen bei der Entwicklung gut handhabbar Klassisch / Agil |
Änderungen können teilweise iterativ eingeplant werden, wodurch sie kaum zusätzliche Kosten generieren, da sie selten auftreten und Puffer eingeplant ist (Benchmarking der letzten Jahre) Klassisch / Agil |
Anhand dieser Tabelle und der bisher betrachteten Informationen wäre die Entscheidung basierend auf der reinen Theorie nicht absolut klar. Es lässt sich aber für die Praxis bereits eine Tendenz ablesen: Beispiel 1 geht in Richtung agil, während Beispiel 2 eine leichte Tendenz zur klassischen Herangehensweise hat.
Das versteckte Entscheidungskriterium: Komplexität
Rein auf Grundlage der Theorie und Grobeinschätzung der Rahmenbedingungen könnte man nun sagen:
- Beispiel 1 ist doch eigentlich schon klar, das machen wir agil, aber wie können die Themengebieten, welche klassisch gehandhabt werden sollten dann doch im agilen Ansatz bearbeitet werden?
- Beispiel 2 konnte noch nicht so fundiert betrachtet werden, dass man wirklich mit dem klassischen Ansatz arbeiten würden beziehungsweise ist auch hier die Frage, wie man mit den agilen Themengebieten in einem klassischen Ansatz umgehen würde?
Zwischenfazit: Es fehlt also noch irgendwas, um endgültig entscheiden zu können, welche Herangehensweise die sinnvollere ist.
Gehen wir daher nun im nächsten Schritt einmal auf die Ebene der wichtigsten Arbeitspakete, die bei beiden nach derzeitigem Stand ja klar sind und somit nach der klassischen Methodik bearbeitet werden würden.
Lassen Sie mich Ihnen hierzu nachfolgend noch ein paar weitere Informationen zu den Projektinhalten geben:
- Beispiel 1 – Das neue Gesetz beschäftigt sich mit der Handhabung, wenn Wohnraum umgebaut oder abgerissen wird. Um die Mieter zu schützen, muss der Eigentümer dies im Vorfeld der zuständigen Behörde melden, welche wiederum das Vorhaben und die daraus resultierende Mieterhöhung freigeben müssen.
- Beispiel 2 – Die Software, welche upgedatet wird, ist notwendig, um Einreichungen an Behörden durchzuführen. Diese verlangen bestimmte Templates, welche mit der Aktualisierung eingespielt werden. Die Validierung hat nach GAMP 5 – Kategorie 3 zu erfolgen (das gibt eine gewissen Reihenfolge beziehungsweise einen gewissen Dokumentationsaufwand vor).
Für Beispiel 1 ergeben sich daraus die nachfolgenden Arbeitspakete:
- Projektmanagement
- Technische Umsetzung
- Neuentwicklung der Fachapplikation, um digital die Anträge zu erstellen und im weiteren Verlauf die Bewertung, Freigabe sowie Berechnung der neuen Miete zu unterstützen
- Erweiterung der vorhandenen Einreichungsplattform für die ausgefüllte Fachapplikation sowie deren Anhänge
- Implementierung und Konfiguration der neuen Schnittstelle von der Einreichungsplattform zur Datenbank
- Erweiterung der Datenbank
- Organisation
- Definition und Implementierung der neuen Rollen und Verantwortlichkeiten
- Definition, Implementierung und Training der neuen Geschäftsprozesse
Für Beispiel 2 wiederum gelten diese Arbeitspakete:
- Projektmanagement
- Technische Umsetzung
- Installation und Konfiguration der Testumgebung
- Installation und Konfiguration der Validierungsumgebung (VAL)
- Installation und Konfiguration der Produktionsumgebung (PRD)
- Validierung
- Risikoanalyse
- Installations Qualifikationen für VAL und PRD (müssen nacheinander erfolgen)
- Performance Qualifikationen für VAL und PRD (müssen nacheinander erfolgen)
- SNOW Standard Change
Sieht man jetzt also genauer hin, erkennt man, dass für Beispiel 1 die Komplexität doch deutlicher für eine Durchführung entsprechend der agilen Methodik spricht – es muss nämlich eine Fachapplikation neu entwickelt werden, was nicht nach einem klassischen Schema passieren kann. Dies vervollständigt unter anderem auch den betrachteten Punkt der Änderungen und Kosten, welcher bisher nicht eindeutig der klassischen oder agilen Methode zugesprochen werden konnte. Gleichzeitig zeigen die gelisteten Arbeitspakete aber auch, dass die Tendenz zur klassischen Methodik bei Beispiel 2 noch stärker untermauert werden kann. Die Arbeitspakete sind überschaubar, die Inhalte bekannt und die Reihenfolge ist sowohl bei der technischen Umsetzung wie auch bei der Validierung vorgegeben.
Dies zeigt, dass die Theorie oft nicht in Gänze ausreicht, um eine praxisorientierte Entscheidung treffen zu können. Durch die Ebene der Arbeitspakete wird ein weiteres, wichtiges Entscheidungskriterium, nämlich die Komplexität, ergänzt. Des Weiteren ist dies eine Ebene, auf der sich die Projektleitung auch bereits in der Initialisierung beziehungsweise Planung bewegt, so dass die Herangehensweise auch frühzeitig sinnvoll definiert werden kann.
Wie bereits beschrieben könnte man dies nun noch weiter auf der Ebene der Aufgaben zu den jeweiligen Arbeitspaketen betrachten, aber da dies am Anfang eines Projektes allgemein meistens noch nicht bis ins letzte Detail beschrieben werden kann und auch in diesem Artikel zu weit führen würde, behalten wir die Ebene der Arbeitspakete im Weiteren bei.
Wenn weder klassisch noch agil der richtige Ansatz ist …
Damit möchte ich gerne zu den Methodiken überleiten, welche wir als Qudits bei den jeweiligen Projekten angewandt haben.
Im Falle von Beispiel 1 ist ein Mix-Modell von klassisch und agil angewandt worden, der sogenannte hybride Ansatz. Die Gründe ergeben sich dabei aus der initialen Grobeinschätzung der Rahmenbedingungen sowie den eben aufgezeigten Arbeitspaketen. Hinzu kommt die vorgegebene Struktur der Verwaltung, innerhalb welcher sich das Projekt ansiedelt. Es ist dadurch unbedingt erforderlich, dass im Arbeitspaket des Projektmanagement eine gewisse Abfolge beachtet wird, zum Beispiel, dass der Projektauftrag freigegeben wurde, bevor eine Entwicklung der Fachapplikation gestartet werden darf. Gleichzeitig ist es aber für die Entwicklung der Fachapplikation nicht sinnvoll diese nach klassischem Ansatz durchzuführen und so wurde für die Realisierungsphase (die Durchführung) ein agiler Ansatz, die Entwicklung in Sprints, genutzt.
Mit Hinblick auf Beispiel 2 wurde das Projekt tatsächlich nach dem klassischen Ansatz durchgeführt. Einerseits ist dies den regulatorischen Anforderungen geschuldet und gleichzeitig hat bereits die Tendenz der initialen Kategorisierung sowie die Ebene der Arbeitspakete aufgezeigt, dass die Gründe für den agilen Ansatz nicht ausreichen. Hierbei wurde aber dennoch der Fokus auf die Zwischenergebnisse verstärkt, so dass dem Aspekt der kontinuierlichen Kontrolle/der Testung trotzdem Rechnung getragen werden konnte.
Ergänzend gilt es zu hervorzuheben, dass es nicht eine hybride Vorgehensweise gibt, sondern, dass diese individuell ausfallen kann, je nach Bedarf des jeweiligen Projektes. Am Ende ist die Auswahl des Vorgehens also tatsächlich nicht ausschliesslich schwarz und weiss, sondern sollte mit Fokus auf die jeweiligen Rahmenbedingungen, die Arbeitspakete, aber auch auf die Organisation, spezifisch auf das jeweilige Projekt angewandt werden (Best of Both Worlds).
Autorin
Julia Heumos
Julias Beratungsschwerpunkte liegen darin, wirksame Organisationen zu etablieren, High-Performance-Teams zu entwickeln und ihre Ergebnisorientierung zu stärken. Damit führt sie Programme und Projekte zum Erfolg und treibt die Digitale Transformation ihrer Kunden voran.
