Hybride Projektarchitekturen
Hybride Projektarchitekturen
„Hybride Projektarchitekturen kombinieren bewusst Kernelemente unterschiedlicher Vorgehensmodelle, um für ein konkretes Projekt in seiner spezifischen Umwelt eine möglichst funktionale Vorgehensweise zu konstruieren.“
Was bitte? Um das greifbarer zu machen, müssen wir einige Schritte zurück gehen. Was ist überhaupt eine Projektarchitektur?
Die Projektarchitektur ist die Entscheidung für eine Vorgehensweise im Projekt, die die Zielerreichung bestmöglich unterstützt. Sie stellt die gewählte Vorgehensweise zielgruppengerecht dar. Sie ermöglicht damit insbesondere zum Start eines Projekts, Klarheit über die Vorgehensweise zu schaffen. Auftraggeber:innen, Stakeholder und das Team können auf diese Weise schnell verstehen, wie grundsätzlich an die Projektaufgabe herangegangen werden soll. Während des Projekts dient die Architektur dazu, den Überblick über den aktuellen Stand im Projekt zu behalten. An welcher Stelle stehen wir gerade? Wann kann mit nutzbaren Ergebnissen gerechnet werden? Neigt sich die Projektreise dem Ende zu oder sind wir gerade erst aufgebrochen? Wann stehen Entscheidungen über das Projekt an? All diese Fragen werden so schnell beantwortbar – die Architektur unterstützt daher immens die Kommunikation innerhalb und außerhalb des Projektes.
Projektarchitekturen basieren dabei auf idealtypischen Vorgehensmodellen – und ergänzen, kombinieren und konkretisieren diese. Zwei in der Praxis zentrale idealtypischen Vorgehensmodelle schauen wir uns hier genauer an.
Das sequenzielle Vorgehen, auch „Wasserfallmodell“ genannt, ist eines davon. Hier werden die Ergebnisse des Projekts im Vorhinein geplant und in aufeinander aufbauenden, klar durch Meilensteine getrennte Phasen bearbeitet.
Eine Phase ist dabei ein fester Zeitraum, in dem zusammengehörige Aufgaben gebündelt bearbeitet werden. Ein Meilenstein ist ein Punkt ohne Dauer, an dem ein vorher definiertes Teilergebnis erreicht ist. Meilensteine stehen am Anfang und am Ende, bei Bedarf auch innerhalb einer Phase. Sie sind Grundlage für den Abschluss, die Wiederholung bzw. Verlängerung oder den Abbruch einer Phase oder des gesamten Projekts.
Ein Beispiel für eine solche Vorgehensweise wäre das folgende Projekt: In einem größeren Unternehmen sollen die bestehenden PCs (Desktop und Laptops) aller 1.000 Mitarbeiter an 3 Standorten mit aktuellen, standardisierten Laptops ausgetauscht werden. Die Projektarchitektur könnte in diesem Fall so aussehen: Mit freigegebenem Projektauftrag (Meilenstein 1) kann das Projekt in die Initialisierungsphase starten, die mit dem Meilenstein 2, einer abgeschlossenen Projektplanung, endet. Damit startet die Konzeptionsphase (Phase 2). An deren Ende steht Meilenstein 3, der umfasst, dass die Rahmenverträge mit dem Hardware-Lieferanten und dem Dienstleister, der beim Austausch der Endgeräte unterstützen soll, unterschrieben sind. Weiter soll das Software-Image, also das Standard-Abbild der gewünschten Endgeräte-Vorkonfiguration für den Rollout vorliegen. Zuletzt muss auch die Rollout-Planung vollständig erarbeitet sein. Erst wenn all diese Dinge vorliegen, darf das Projekt in die dritte Phase, nämlich den Rollout, starten. Diese wurde unterteilt, um das Risiko zu begrenzen: Zunächst wird nur einer der drei Unternehmensstandorte migriert, und die Rolloutplanung danach ggf. angepasst (Meilenstein 4). Wenn das erfolgreich stattgefunden hat, werden die verbleibenden zwei Standorte parallel migriert. Die Rolloutphase endet mit der erfolgreichen Migration (Meilenstein 5). Nun folgt eine Abschlussphase, die enden kann, wenn die Erfahrungen aus dem Projekt für ähnliche Vorhaben gesichert sind und das Projekt abgeschlossen ist (Meilenstein 6).
Das iterativ-inkrementelle Vorgehen, z.B. „Scrum-Sprints“, ist ein zweites idealtypisches Vorgehensmodell. Iterativ bedeutet dabei, dass das Endprodukt in Überarbeitungsschleifen (Iterationen) entwickelt wird. Ein Eindruck vom Gesamtsystem besteht von Anfang an und man nähert sich schrittweise an die exakte bzw. endgültige Lösung an. Inkrementell bedeutet, dass das Endergebnis in Teilergebnissen (Inkrementen) entwickelt und ausgeliefert wird. Das Gesamtsystem existiert erst, wenn alle Inkremente erstellt worden sind. Jedes Inkrement verfügt aber bereits über eine eigene, komplette Funktionalität und kann daher prinzipiell bereits genutzt werden.
Iterativ-inkrementelle Vorgehensmodelle kombinieren beides: Das Endprodukt wird Stück für Stück entwickelt, wobei in jeder Überarbeitungsschleife auch die bereits erstellten Teile wieder überarbeitet werden.
Ein Beispiel für diese Vorgehensweise ist das folgende Projekt: In einem Unternehmen für Industrieelektronik, das als Kernprodukt technisch anspruchsvolle Kühlaggregate für Seefrachtcontainer herstellt und vertreibt, soll ein Produktangebot zur automatischen Statusverfolgung für Container entwickelt werden. Davon verspricht das Unternehmen sich, seine Wettbewerbsposition zu stärken, eine Aufwands- und Kostenersparnis bei den Kunden des Unternehmens (internationale Reedereien) zu ermöglichen, zusätzliche Sicherheit durch Echtzeit-Informationen bereitzustellen und den Transport durch Datenanalyse optimieren zu können. Die verschiedenen Bestandteile der Lösung, wie die Datenerhebung am Container, die Datenübertragung an ein Monitoring-System, die Analyse und Auswertung der Daten innerhalb dieses Systems sowie die Datenabfrage durch die Endkunden sollen dabei iterativ-inkrementell entwickelt werden. In mehreren Sprints werden also jeweils einzeln nutzbare Bestandteile des Endprodukts designt, entwickelt, getestet und bereitgestellt, wobei die Ergebnisse der vergangenen Sprints im jeweils nächsten mit integriert und bei Bedarf angepasst und verbessert werden. So kann ein erstes Produkt schnell auf den Markt gebracht und vom Feedback der Nutzer gelernt werden, um das Produkt laufend zu verbessern und den Funktionsumfang zielgerichtet und nachfragebasiert zu erweitern.
Der Vergleich: Stellen wir die beiden vorgestellten, idealtypischen Vorgehensmodelle einmal nebeneinander, um ein Gefühl dafür zu bekommen, wann sich der Fokus auf welches Modell in der Entwicklung einer konkreten Projektarchitektur lohnt:
Es ist also sehr vom jeweiligen Projektvorhaben und seiner Natur abhängig, welches Vorgehensmodell eine konkrete Projektarchitektur mehr prägen wird. Gibt das Vorhaben eine langfristige(re) Vorausplanung her, oder „müssen“ wir iterativ-inkrementell Vorgehen? Hilfreich bei dieser Annäherung ist der Blick auf das Kontext-Modell1 und die Frage, ob es uns als Projektteam gelingt, die Ergebnisse bereits konkret und kleinteilig festzuhalten. Auch Cynefin/Stacey Landscape kann bei der Einordnung helfen, wie sicher oder unsicher sich unser Anforderungs- und Lösungsraum im Projekt darstellt, um daraus Empfehlungen für das Vorgehensmodell abzuleiten. Und nicht zuletzt ist der Blick auf die Organisation, in der bzw. für die das Projekt läuft: Welche Voraussetzungen an das Vorgehen werden hier gestellt? Wie viel und welche Erfahrung liegt mit den Vorgehensweisen jeweils vor?
Aber nicht nur der Fokus auf ein idealtypisches Vorgehensmodell ist bei der Erarbeitung einer tragfähigen Projektarchitektur wichtig. Weitere hilfreiche Fragen sind die Folgenden:
- Brauchen wir Module oder Teilprojekte, um die Komplexität zu reduzieren (z.B. bei mehr als 10 Personen im Projektteam)
- Brauchen wir zur Lösungsentwicklung eine pilothafte Erprobung (Pilotgruppe?)
- Erfolgt die Bereitstellung als Big Bang oder im schrittweisen Rollout?
- Braucht es eine besondere Einbindung der Stakeholder und intensives Change Management (Link zum Text), um die Lösung zu erarbeiten bzw. für eine breite Akzeptanz der Ergebnisse Sorge zu tragen?
Fast immer wird man dann feststellen, dass nur die bewusste und zielgerichtete Kombination idealtypischer Vorgehensmodelle echten Erfolg verspricht. Eine hybride Projektarchitektur also!
Zur Erinnerung: „Hybride Projektarchitekturen nutzen bewusst Kernelemente unterschiedlicher Vorgehensmodelle, um für ein konkretes Projekt in seiner spezifischen Umwelt eine möglichst funktionale Vorgehensweise zu konstruieren.“
Wie kann das also konkret aussehen?
In der Praxis finden sich vor allem drei grobe Spielarten hybrider Architekturen:
1. Die sequenzielle Anwendung
Hier werden innerhalb eines Projektes phasenweise, also zeitlich aufeinander folgend, unterschiedliche Vorgehensmodelle eingesetzt. Oft sieht man hier die Kombination von sequenziellem „wasserfallartigen“ Vorgehen zu Beginn und Ende des Projekts in Kombination mit einem iterativ-inkrementellen Vorgehen, z.B. in „Scrum-Sprints“ in der Mitte.
Ein Beispiel: Gut passend stellte sich dieses Vorgehen bei der Anpassung und Weiterentwicklung von Prozessen und für diese genutzte digitale Tools in einer von uns begleiteten Organisation heraus. Zum Start des Projekts gibt es eine Reihe voneinander abhängigen Tätigkeiten, die dazu führen, dass das Projekt überhaupt starten kann. So muss ein Kernteam gebildet und ein Entscheidungsgremium/Steuerkreis eingerichtet werden. Vision und Ideen für Verbesserungen müssen (z.B. in einem großen Workshop mit allen relevanten Stakeholdern) gesammelt und in kleineren, intensiveren Sessions (z.B. Anforderungsworkshops) genauer erarbeitet werden. Diese Anforderungen fließen dann in ein initiales Backlog. Damit starten wir in die iterativ-inkrementelle Umsetzung. In 4-wöchigen Sprints werden kleine Verbesserungen erarbeitet und möglichst auch schon entschieden und in die Organisation ausgerollt. Das können z.B. Prozessveränderungen, neue (Teil-)Prozesse, Klärung von Themen zwischen Abteilungen, Anpassungen an bereits genutzten Tools etc. sein, aber auch die stückweise Entwicklung eines neuen Softwaretools auf Basis einer Standardsoftware. Da absehbar ist, dass nicht alle Themen direkt in die Linienarbeit ausgerollt werden können, insbesondere das neue Softwaretool, und es auch aus Perspektive der beteiligten Organisationsmitglieder sinnvoll erschien, einen expliziten Zeitraum für Einführungsevents und Schulungen vorzusehen, folgt auf die iterativ-inkrementelle Umsetzung eine wasserfallartige Implementierungsphase. Zuletzt braucht es eine wasserfallartige Abschlussphase, die die Übergabe in den Betrieb und den Aufbau von Ressourcen und Verantwortlichkeit für die kontinuierliche Betreuung und Verbesserung der Tools, eine übergreifende Lessons-Learned-Session sowie die formelle Auflösung des Projektteams sicherstellt.
2. Die parallele Anwendung
Eine weitere Spielart hybrider Architekturen ist die parallele, also zeitlich gleichzeitige Anwendung unterschiedlicher Vorgehensmodelle im selben Projekt. Um im vorigen Beispiel zu bleiben wäre es denkbar, dass die Entwicklung und Einführung des neuen Tools wasserfallartig durchgeführt wird, sofern die Anforderungen klar und stabil wären (was sie in der Realität nicht sind). Oft eingesetzt wird diese Architektur auch in der Produktentwicklung, wo Teile des (physischen) Produkts aus Effizienzgründen wasserfallartig entwickelt werden müssen (z.B. Fahrgestellt, Motor, Karosserie,… ) während Softwarebestandteile des Produkts (Motorsteuerung, Fahrassistenzsysteme, Entertainmentsysteme,…) aufgrund der schnellen Weiterentwicklung der digitalen Technologie und sich gleichzeitig schnell ändernden Kundenanforderungen iterativ-inkrementell weiterentwickelt werden sollten, teilweise sogar über die Produktionsreife hinaus (man denke an Updates over-the-air). Dasselbe ist denkbar bei vielen Produkten, die inzwischen Software enthalten. So gibt es beispielsweise bei vielen Büroleuchten inzwischen Apps zur Steuerung, der Kühlschrank informiert via App, was eingekauft werden muss u.v.m..
3. Die integrierte Anwendung
Bei dieser dritten Spielart hybrider Architekturen entfernen wir uns von der reinen Kombination verschiedener Vorgehensmodelle und schauen tiefer: Lassen sich beispielsweise Sprint-Logiken mit ihrem steten Rhythmus der Auswahl von Aufgaben, ihrer Umsetzung und des Einholens von Feedback auch auf wasserfallartige Ansätze übertragen. Über mehrere Sprints vorgedachte thematische Releases bringen eine Meilenstein-Logik in iterativ-inkrementelle Ansätze etc. Hier liegt die Kunst im funktionalen Denken. Was will ich erreichen, und welches Element eines bestimmten Vorgehensmodells kann mir dabei helfen? So entstehen passgenaue und hilfreiche Architekturen. Gerade weil die funktionale Kombination und Integration unterschiedlicher Schulen die Kür ist, kann sie uns einerseits neue Möglichkeiten und Wirksamkeiten bieten, erfordert auf der anderen Seite aber auch ein hohes Maß an Vorsicht: Das blinde Kombinieren verschiedener Elemente ohne tiefes Verständnis ihrer Wirkungsweise kann auch leicht zum Verlust handfester Vorteile und zur Konstruktion einer dysfunktionalen Vorgehensweise führen. Kombiniere daher nur, was du auch verstanden hast!
1 (Daniela Mayrshofer, Hubertus Kröger: Prozesskompetenz in der Projektarbeit – Ein Handbuch mit vielen Praxisbeispielen für Projektleiter, Prozessbegleiter und Berater)
