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):
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:
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).