CAS Agile Organisation

making your organisation agile

Agile Organisation – Beyond Portfolio

Posted by Marc Keiser on 05.12.2019

Damit das Folgende im richtigen Kontext gelesen werden kann, muss ich zuerst etwas ausholen. Ich arbeite in einer Wertschöpungskette mit rund 150 beteiligten Mitarbeiten und das Ganze nennt sich Projektgeschäft. Unsere Kunden unterliegen Gesetzen und Vorgaben, die sie erfüllen müssen (Man beachte den Imperativ!) und wir unterstützen die dahinterliegenden Prozesse mit IT Systemen. Die Planung zur Erstellung dieser digitalen Unterstützung bilden unsere Kunden in sogenannten Projektvorhaben ab. Diese werden in einem zentralen Portfolio geführt. Wer es noch nicht erahnt hat, dem sei hier bestätigt, dass die Kunden von denen ich spreche beim Bund eingebettet sind, namentlich im EJPD. Wie alle Departemente folgt auch das EJPD einer strikten Jahresbudgetierung. Ein Jahr ist in der IT bekanntlich der gefühlte Übergang der Kreide- in die Bronzezeit und weiter, hat sich mit abnehmender Halbwertszeit von Technologiewechseln gezeigt, dass sich die guten Absichten der Jahresplanungen im Dezember bereits im ersten Quartal nicht gerade als obsolet, aber mindestens gefühlt anders zeigt. Die Spannung zwischen den Extremen “Tradition, Kontrolle und Planung” auf der einen Seite und “Modern, Selbstorganisation und Experimentell” auf der anderen Seite, lässt sich sinnbildlich mit der Landung von Elon Musks Raumfahrtskapsel auf der Rütlischwurwiese vergleichen und ist wohl nirgends so frapant wie in der Bundesverwaltung.

Der geneigte Leser stellt sich vielleicht mitunter die berechtigte Frage, warum das überhaupt (m)ein Problem ist, daher versuche ich es wie folgt auf den Punkt zu bringen: Der Ansatz Unvorhergesehens zu meistern, wird in der Bundesverwaltung durch Bildung von Reserve angegangen. Damit soll die benötigte Leistung amTag x (wobei x ein unbekannter Tag im Jahr ist) , so sichergestellt werden, dass für das ganze Jahr Ressourcen eingeplant werden. Gute Idee eigentlich, den x ist ja irgendwo im Jahr enthalten. Aber gut gemeint ist noch nicht wirklich gut, oder? (Twinky). Der Effekt dieses Lösungansatzes liegt auf der Hand: Sehr teuer – das Warten auf Arbeit ist nicht gerade ein Kostenreduktionsverkaufsschlager – und ja, es weiss immer noch niemand, wann dieser Zeitpunkt x denn nun konkret im Jahr ist…

Transfer

Es gilt also zu erkennen, wann welche Ressourcen tatsächlich benötigt werden und wo aufgrund von Unsicherheit Reserve eingeplant wurde.

Damit ist für mich die Handlungsachse klar. Weder Sinn, noch die Rechtmässigkeit noch der Zweck verlangt ein Umdenken, sondern ausschliesslich der Beitrag [Quelle Unterlagen Haas]. Wir müssen Strukturen schaffen, welche der Inneffizienz der Reservenbildung entegegenwirkt.

Meiner Meinung nach, wirken folgende Aspekte in irgend einer Form auf das Wirkungssystem ein

  • Transparenz
  • Parallelität
  • Ressourcierungsprozesse
  • Disziplin
  • Vertrauen

Noch vor zwei Jahren konnten wir uns es leisten, Projekte völlig autonom zueinander zu betrachten und die Reservebildung aufgrund von Unsicherheiten waren deutlich kleiner. Natürlich hatten die dahinterliegenden IT-Systemen gewisse technische Zusammenhänge (Schnittstellen), aber Projektabwicklungstechnisch waren diese weitgehend losgelöst voneinander und damit auch besser entlang der Zeitachse planbar. Unser aktueller Portfolioressourcierungsprozess kann vereinfacht wie folgt dargestellt werden.

  • Vorhaben werden als Grössenordnung eingeschätzt -> Je höher die Unsicherheit, desto höher die eingeplante Reserven
  • Projektvorhaben werden gestartet, dann wenn erste Aktivitäten erkennbar sind (Unabhängig von Grösse (5 Personentage bis 2000 Personentage pro Jahr und Reife)
  • Projekt wird geplant -> Wasserfall und sehr Skill orientiert. Businessanalyst Jan – Feb, Entwickler Mrz-Aug, Integrator Sep, usw.)
  • Projekt wird ressourciert -> Sehr Skill fokussiert: Businessanalyst Jan-Feb 2h pro Woche, 3 Entwickler Mrz – Apr 40%, ..
  • Projekt wird umgesetzt -> Änderungen im Plan ziehen Replannings nach sich. Reserve wird ausgesessen oder zugunsten interessanter Features eingesetzt. Replannings betrifft zunehmend alle Projekte, mit denselben Ressorucen
  • Projekt wird abgeschlossen -> Zunehmendes Risiko, dass Replannings zu Verzug und höhere Kosten führen

Eine Chance könnte es also sein, den Portfolioprozess anzupassen.

Rahmenbedingungen / Voraussetzungen des Modells

Stehende Teams mit durchmischten Skills (z.B 7 Personen, 1 Methodiker (Scrummaster), 1 Fachowner (ProductOwner), 2 Experten mit Schwerpunkt Businessanalysten/Testing, 3 Fachspezialisten Entwicklung, 1-2 Fachspezialisten mit Sonderskill je nach Phase und/oder Typ von Projekt (z.B Architektur, Qualitätssicherung, Intergrator, usw.)

Stehende Teams können in einem höheren Kontext noch einmal gebündelt werden (Tribesansatz). Diese Bündelung haben wir bereits dieses Jahr eingeführt, bei uns heisst das Gefäss “Städte”. Bis anhin waren die Städte allerdings in erster Linie für das Reporting und die Diskussion um Ressourcen wichtig. Der Aspekt des Teilportfolios steht also noch aus.

Ich könnte mir als Big Picture dazu Folgendes vorstellen:

Vereinfacht gesehen, gibt es pro Ebene ein Kanban, mit Open, In Progress und Done/Cancel

Pro Ebene sollte es klare Strukturen, Regeln, Prinzipien geben welche die Übergänge regelt. In meinem Modell “zieht” (pull) jetzt jeweils die untere Ebene entlang der freigegeben und priorisierten Portfolioitems die Arbeiten und plant die Detailsschritte Ebenengerecht ein

Dazu würden die Beteiligten in einem Dialog mit Wissensträgern der benachbarten Ebenen treten und die Frage beantworten: “Was ist eine sinnvolle Reihenfolge zur Abarbeitung des Backlogs mit Blick auf’s Ganze?”. Die geplanten Detailschritte müssen Ebenengerecht sein und bilden die Basis zur Priorisierung der unteren Ebene.

Nach einem definierten Takt wird das Ergebnis konsolidiert und dient als Replanningsgrundlage der oberen Ebene. Dies ist der Magic Trick! . Die Reserve sollte damit in den Portoflios “stehenbleiben”, “parkiert” werden.

Ein möglicher Zeitplan/Takt pro Ebene könnte auf die Jahresplanung der Bundesverwaltung ausgerichtet sein. Die Teams haben zwei Wochen Intervalle und die Städte haben Monatsintervalle, was dem Controlling der Bundesverwaltung entspricht. Synchronistation auf Stufe der Ämter als Auftraggeberschaft wären quartalsweise im Sinne eines “Big Room Plannings” 4 Mal jährlich.