Die Perlenschnur einer Lösung – Teil 3

Ausgangssituation

„Wir haben unsere Projekte nicht. Im Griff. Wozu brauchen wir dann noch ein Programm?“

Eine absolut richtige Bemerkung. Und doch ….. wenn die Vorhaben zu gross/komplex sind, Zerkleinern nur bedingt hilft, sich so einiges zusammen geschoben hat und das Resultat benötigt wird, …. dann ist es von Vorteil, sich mit skalierten Strukturen auseinander zu setzen.

Nur … wenn schon ein Programm, so prüfen wir zuerst auf Verwendbarkeit der agilen Ausprägung. Denn diese ist weit einfacher zu verwenden und hat auch den agilen Grundkontext wie `good is good enough´ sowie `nur soviel als erforderlich´ im Gepäck mit. 

Struktur

Quelle: Dynamic Systems Development Method Limited, Web

Viele Teile dieser Abbildung sind selbsterklärend. Hervorzuheben ist der agile Charakter mit `genug ist genug´ und `lohnenswert´, d.h. im jeweiligen Abschnitt nur so lange dran zu bleiben, wie es Sinn macht – also lohnenswerte `Capabilities´ zu generieren, welche zu den gewünschten Nutzenaspekten führen.

Erzeugt ein Projekt einen `Output´ - also ein Produkt - so müssen diese Produkte in Stellung gebracht werden, um Wirkung erzeugen zu können. Das nennt man ein `Capability´. Stellen Sie sich vor, wie Sie eben die Struktur eines Programms gelernt haben – ein Produkt. Wenn Sie sich bspw. Vorlagen generieren, sind dies `Capabilities´. Denen noch andere folgen werden. Die Anwendung Ihrer Erkenntnisse und der Vorlagen führen zur Wirkung – dem `Outcome´. Da Wirkung nicht wirkungslos bleibt, sollte sich Nutzen (`Benefit´) einstellen – eine strategische Marktposition, Umsatz, Imagesteigerung u.ä..

Das Segment `Programme Foundations´ kann auch durchaus den Umfang eines eigenen Projekts aufweisen. Unbedingt zu prüfen ist da auch die Notwendigkeit einer Programmstruktur und die Eignung für agiles Vorgehen.

Die am meisten verwendeten Teile sind die `Capability Evolution´ und die `Tranche Review`. In einem werden die Projekte erzeugt und die `Capabilities´ in Stellung gebracht sowie soweit als möglich Nutzen kreiert. Im anderen Element wird der Status Quo samt Sinnhaftigkeit weiterer Projekte auf den Prüfstand gestellt und ggf. die in `Programme Foundations´ erzeugte Grobplanung für die folgenden Tranche detailliert. Die Erkenntnisse aus dem vorgehenden Abschnitt fliessen dabei wesentlich mit ein. Das entspricht der agilen Grundhaltung bei Projekten.

Wenn wir hier von Planung einer Tranche sprechen, so ist das zwar einerseits wesentlich komplexer bzw. umfangreicher, da hier mehrere Projekte zur gleichen Zeit in Angriff genommen werden. Aber für diese Projekte wird andererseits nur der Rahmen festgelegt. Parameter dazu sind:

•  Start-/Endzeit
•  Grobes Budget
•  Zugeteilte Ressourcen
•  Zweck des Vorhabens
•  Abhängigkeiten

Die Feinplanung der jeweiligen Projekte erfolgt dann pro Projekt im Abschnitt `Capability Evolution´ vor dem jeweiligen Einsatz. Auch hier absolut agil, da diese Feinplanung Stück für Stück entlang eines Pfades Form annimmt und die anfangs abgesteckten Eckpfeiler inhaltlich vertieft werden.

Eine Tranche erstreckt sich nmeist zwischen 6 und 12 Monaten. Was wiederum eine Durchlaufzeit eines üblichen Programms weit über die Durchlaufzeit eines üblichen Projekts signalisiert. So wie sich während eines Projekts Nutzen ergibt, so sollte ein Programm auch entsprechend dessen Einsatz Nutzen erzielen.

Die Nutzenbetrachtung erfolgt nicht nur während `Capability Evolution´, sondern wird gesamthaft vom Nutzenmanagement startend von `Programme Foundations´ bis zu `Programme Close´ angewendet.

Unterschiede Verantwortlichkeiten Programm: Projekt

Grundsätzlich bedeutet Agilität Selbstorganisation in den Entwicklungsteams. Das funktioniert auf der Projektebene sowohl bei AgilePM™ als auch für reine Produktentwicklungen á lá Scrum. Wobei bei ersterem der Projektmanager verantwortlich ist, für die erforderliche Arbeitsumgebung der Teams zu sorgen.

Wie Sie oben bei der Planung einer Tranche gelesen haben, ist dieses Konzept Projektmanager:Team umgelegt auf Programm:Projekt. Das Programm trägt hier also die Verantwortung für den erforderlichen Rahmen der Projekte. Die Details werden hingegen den Projektorganisationen gemäss deren Methodik selbst überlassen.

Der Umfang bzw. die Komplexität eines Programms erfordert dafür die Einhaltung dieses Rahmens. Was wiederum in der Natur agiler Einzelvorhaben liegt. Auch deren In-Frage-stellen auf weitere lohnenswerte Fortführung ist damit ermöglicht.

Bei nicht agilen Projekten – insbesondere Wasserfall-Umsetzungen – wird dies zu einer Herausforderung. Klassischer Wasserfall bedeutet wenig Einbeziehung des Kunden während der Erstellung und Testen zum Abschluss. Tests, welche dann oft bei Gefährdung des Lieferzeitpunkts stark reduziert und/oder mangelhaft ausgeführt werden. Das wiederum wirkt sich bekannterweise auf die Qualität enorm aus und damit sind Produkte, die fertig sein sollten oft mit versteckten Mängeln versehen. Die Capabilities´und die Nutzenaspekte sind damit eindeutig gefährdet.

Um das von Grund auf anders zu gestalten, sind folgende Massnahmen bei Einbeziehung nicht agiler Projekte empfohlen:

•  Mehr laufende Einbeziehung durch den Kunden/die Benutzer
•  Laufendes Testen und Rückschau
•  Nach Möglichkeit Zergliedern eines grossen Ganzen hin zu Teilen (Inkremente)

Genau gesagt – mehr Agilität einbauen!

Zurück zur Steuerung. Besonders von Bedeutung sind bei Programmen die Verhaltensweisen der oberen Ebenen:

•  Noch mehr Augenmerk auf die Kommunikation
•  Vertrauen und Ermächtigung der Projektverantwortlichen
•  Klarheit in der Vision und deren Abgrenzung
•  Setzen von Prioritäten
•  Mit Stolz und Leidenschaft voran gehen

Zur exakten Trennung der unterschiedlichen Verantwortlichkeiten existieren bei AgilePgM™ drei klare Ebenen. Die Steuerung obliegt dabei alleine der obersten Schicht, damit klare Vorgaben entstehen können. 

Quelle: Dynamic Systems Development Method Limited, Web

Abgrenzung

Ein agiles Projekt für sich hat eine sinnvolle Grenze von insgesamt ca. 1000 Anforderungen pro Team. AgilePM™ selbst kann mit bis zu 10 parallelen Teams geführt werden. 

Auch wenn immer wieder von Beispielen hoch skalierter Umgebungen die Rede ist, empfehlen wir eher eine geringere Anzahl an gleichzeitigen Entwicklungsgruppen.

Auf jeden Fall ist AgilePgM™ bei mehreren parallelen Projekten als Steuerungseinheit über alle Einzelvorhaben hinweg absolut empfehlenswert. Auch da würden wir eine Grenze bei 10 – 15 Projekten innerhalb eines Programms ziehen. Ebenso empfehlenswert ist es sogar eher, eine Programmebene einzuziehen anstatt zuviele Entwicklungsteams parallel in einem Projekt zu betreiben.

Erkenntnisse

Programmstrukturen sind hilfreich und sinnvoll. Grosse Vorhaben lassen sich nicht immer zerkleinern. Ganz im Gegenteil steigt der Umfang gepaart mit Komplexität enorm bei sinkender Durchlaufzeit. Zu lernen sind seitens der Unternehmen die agilen Blickwinkel `genug ist genug´ und `lohnenswert´. Zu oft wird noch auf volle Erfüllung aller Wünsche gepocht. AgilePgM™ ist für alle Fälle eine professionelle Methode erster Wahl.

Angebot

In unseren Ausbildungen und Workshops legen wir sehr viel Wert auf Maximum

Viable Projects - hinweg über alle Ebenen (Programmes & Portfolios) und Phasen. Wir bieten darüber hinaus die Begleitung beim Aufsetzen von Projekten sowie Programmen oder Portfolios und Ressourcen für Facilitation bzw. Business Analyse.

Den Wertschöpfungsketten und Ihrem Nutzen gilt dabei immer unser grösstes Augenmerk. 

Details finden Sie auf unserer Homepage im Bereich Richtung (Facilitation) und bei den Publikationen sowie zur Ausbildung unter Wissen (Training) und/oder in einem persönlichen Gespräch. Gerne demonstrieren wir Ihnen auch live die Effekte bei einer aktuellen Aufgabenstellung.

Der Autor ist Mitglied im Top-Trainerverzeichnis. Besuchen Sie sein Profil