Kapazitätsmanagement im Lean Portfolio Management – Teil 01: Der Umgang mit Unsicherheit

empty road surrounded with trees with fog

Das Wort Unsicherheit ist in Wirtschaft, Politik und Management unbeliebt. Wir wollen gerne einen stabilen Markt, die Politik soll die Voraussetzungen dazu schaffen und das Management soll mit einer sorgfältigen und vorausschauenden Planung den Erfolg nachhaltig sichern.

Mit der dot.com Krise, der Finanzkrise, aber spätestens mit Corona haben wir hoffentlich gelernt, dass die Welt nicht sicher ist. Die Welt ist voller Unsicherheit, im Kleinen wie im Grossen.

Das Fatale an Unsicherheit ist nicht die Unsicherheit selbst, sondern unsere Reaktion auf diese. Anstatt Unsicherheit zu akzeptieren und Strategien zu entwickeln, diese positiv für uns zu nutzen (Versicherungen kennen das Spiel schon lange), ist unsere typische Reaktion „es nun ganz genau“ wissen zu wollen. Die Folge ist eine Menge Arbeit, um (unsichere) Details zu erheben, zu analysieren, zu kombinieren, um das „bessere Bild“ zu erstellen. Nur bleibt die Unsicherheit leider, sie ist lediglich mit viel Arbeit verteilt und versteckt worden, wir haben sie nur scheinbar „im Griff“ und sind dann um so überraschter, wenn sich eine unvorhergesehene Veränderung ergibt, oder wir feststellen, das sich Unsicherheit multipliziert.

Lean Portfolio Management bricht bewusst mit diesem Muster. Das Lean Portfolio Management (LPM) baut auf der Strategie auf, Unsicherheit bewusst zu akzeptieren und mit dieser zu arbeiten. In dieser Blogserie will der Autor den Umgang mit Unsicherheit am Beispiel von Kapazitätsmanagement aufzeigen.

Der klassische Ansatz des Kapazitätsmanagements

Nach dem klassischen Ansatz bedingt das Kapazitätsmanagement das Schätzen von Projekten und Programmen. Wenn die Ziele des Projektes definiert sind, zum Beispiel das Projekt „Harmonisierung der beiden Plattformen X und Y zur Plattform Z“, erfolgt eine so genannte work breakdown structure: Die einzelnen Tasks werden von Teams geschätzt und letztlich die Summe der Schätzungen erstellt. Gute Schätzungen verwenden dazu drei Werte pro Task: „minimum“, „maximum“ sowie „most likely“. So bekommt die Schätzung eine Reichweite. An der Stelle empfehle ich das Buch „Software Estimation: Demystifying the Black Art“ von Steve McConnell.

Sample Work Break Structure with Samples Decomposed at WP Level

Wer das Buch liest, der versteht, dass Schätzungen für Aufgaben, die weit in der Zukunft liegen, mit einer höheren Unsicherheit verbunden sind, als Schätzungen für Aufgaben, die demnächst starten. Ein wesentlicher Grund liegt in der Tatsache, dass die zukünftige Aufgabe auf Voraussetzungen aufbaut, welche eine frühere Aufgabe erstellt hat. Das Erreichen dieser Voraussetzungen ist mit einer Unsicherheit verbunden. Die Schätzung der zukünftigen Arbeit basiert somit bereits auf einem Ausgangspunkt, der mit Unsicherheit behaftet ist. So multipliziert sich Unsicherheit.

Statistiken, zum Beispiel der regelmässig erscheinende Annual State Of Agile Report oder der folgende Research Artikel [1] weisen zudem nach, dass Schätzungen des Aufwands von Projekten mit einer längeren Laufzeit als ein Jahr erheblich am tatsächlich benötigten Aufwand vorbeigehen – zumeist leider in die ungewünschte Richtung von Mehraufwand. Der Artikel [1] nennt Zahlen: rund 75% der Projekte weisen einen Mehraufwand von 30% bis 50% zur ursprünglichen Schätzung aus.

Wir streben ein Flow-optimiertes Pull System an

Das Bestreben eines Unternehmens ist es, die Wertgenerierung für den Kunden und das Unternehmen zu maximieren. Ein Schlüssel zum Erfolg ist, ein wertorientiertes und Flow-optimiertes Pull System im Unternehmen zu etablieren. Dies bedeutet:

  1. Wir minimieren Wartezeiten (Delay). Dabei besitzt das Vermeiden von Cost of Delay (siehe das Buch von Reinertsen, Principle E3) die höchst Priorität. Gemäss Reinersten sind Queues und vor allem der zu hohe Füllgrad von Queues (Principles Q3, Q9, Q13) die Ursache für Cost of Delay. Da das Portfolio des Unternehmens im Prinzip eine Queue darstellt, gilt es also, diese Prinzipien auf das Portfolio anzuwenden.
  2. Wir arbeiten immer an den Themen, die den höchsten Wert für Kunden und Unternehmen generieren und die höchste positive Wirkung auf diesen beiden Seiten erzielen. Das bedeutet, die Elemente in der Portfolio Queue nach Wert zu priorisieren.
  3. Wir wollen schnell und regelmässig Wert erzeugen, d.h. das Ergebnis der Arbeit setzt der Kunde produktiv und operativ ein, unter Anerkennung des Wertes. Anerkennung des Wertes bedeutet in den meisten Fällen, dass er sich für das Produkt oder den Service entscheidet und bereit i, stden Preis für die Nutzung zu bezahlen.

Die Herausforderung im Kapazitätsmanagement im Bauen von Produkten oder Services ist, dass

  1. die Fähigkeiten und Kapazitäten der Teams im Unternehmen nur selten optimal mit den benötigten Fähigkeiten und Kapazitäten für die anstehenden Arbeit zusammenpassen.
  2. in der Realisierung einer grösseren Aufgabe Abhängigkeiten zwischen Teams (Squads, ARTs, Tribes – wie auch immer…) bestehen, die nie komplett aufgelöst werden können.

Fähigkeiten und Kapazität der Teams sind einfach nicht beliebig verschiebbar. Eine Mitarbeiter*in, die heute in der Logistik arbeitet, kann nur selten morgen im Marketing ebenso produktiv wirken, eine Entwickler*in aus dem Umfeld SAP wird nicht morgen in der Lage sein, Java zu programmieren. Sind die Fähigkeiten und deren Kapazität nicht stimmig zum Demand, so entstehen Wartezeiten, die Cost of Delay schlagen zu.

Es gilt somit, in einem skaliert agilen System mit einer gewissen Voraussicht und Wahrscheinlichkeit eine Aussage zu formulieren, welche Veränderung von Fähigkeiten und deren Kapazität stattfinden sollten, um sowohl aus einer kurzfristigen Sicht, als auch aus einer mittelfristigen Betrachtung den Demand abdecken zu können.

Diese Blogserie zeigt einen Ansatz auf, proaktiv mit der Unsicherheit im Portfolio Management umzugehen und ein Kapazitätsmanagement in diesem Umfeld zu adressieren. In unserem Training zum Lean Portfolio Management lernen Sie, wie Sie dies in Ihrem Unternehmen einsetzen.


Literatur:

[1]: Alexei Botchkarev, Artikel: Accuracy of Estimating Project Costs and Benefits: An Overview of
Research in Information Systems, Journal of Emerging Trends in Computing and Information Sciences, Vol. 6, No. 6 June 2015, ISSN: 2079-8407,

[2]: Steve McConnell, Software Estimation: Demystifying the Black Art (Developer Best Practices), Microsoft Press (22 Mar. 2006); ISBN-13: 978-0735605350

About the author:

Did you find this interesting? Share this Article.

LinkedIn
Twitter
Email
Facebook

What we do

How we do it

Who we are

How we do it

Not your language? Switch it!