Portfolio Deprioritization

Systemproblem

In 90% der Unternehmen herrscht die Auslastungsfalle (Resource Utilization Trap). Das Management sieht 100 Entwickler und startet 50 "Prio 1" Projekte gleichzeitig, damit "jeder zu 100% beschäftigt ist". Die kybernetische Wahrheit (Little's Law): Wenn die Auslastung einer Autobahn über 85% steigt, verwandelt sich der Verkehr in Stau. Die Geschwindigkeit fällt auf Null. Projekte blockieren sich gegenseitig im QA-Bottleneck, Feature-Branches verrotten ungemerged seit Monaten (Delay), und der "Context Switch" (Das Springen von Ticket zu Ticket) beeinträchtigt die verbleibende Aufmerksamkeit der Ingenieure.

Intervention

"Portfolio Deprioritization" (das Begrenzen angefangener Arbeit) ist ein WIP-Limit auf Portfolio-Ebene. Die Intervention lautet: Ein Teil der laufenden Projekte wird bewusst pausiert, damit die verbleibenden Vorhaben mit ausreichend Fokus abgeschlossen werden können. Der Zweck ist nicht lokale Auslastungsoptimierung, sondern die Wiederherstellung von Flow über das gesamte Portfolio.

Erwartete Wirkung

Der Stau im Portfolio löst sich schrittweise auf. Obwohl die Firma auf dem Papier weniger parallele Projekte betreibt, kann sie in kürzerer Zeit mehr relevante Arbeit fertigstellen. Die Lead Time sinkt. Häufig steigt auch die Codequalität, weil Entwickler und unterstützende Spezialisten nicht mehr über Dutzende parallele Prioritäten verteilt werden.

Nebenwirkungen und Risiken

Die Nebenwirkungen sind vor allem politisch. Viele pausierte Projekte haben Sponsoren, Status oder Bonuslogiken. Wenn Projekte depriorisiert werden, können Manager versuchen, ihre Vorhaben über Nebenkanäle weiterzuführen. Eine Portfolio-Depriorisierung funktioniert deshalb nur, wenn Führung die Entscheidung konsistent schützt und Ressourcen nicht informell wieder aufteilt.

Diagramm

Wann diese Intervention wirksam wird

Diese Intervention ist purste "Queueing Theory" (Warteschlangentheorie nach Donald Reinertsen). Wir managen in der Entwicklung keine Autos, Maschinen oder Pakete. Wir managen unsichtbare Information (Code). Da der Lagerbestand (Stock) von Code völlig unsichtbar ist, merkt niemand, dass sich unfertiger Code auf den Festplatten stapelt. Ein halbfertiges Feature auf einem Git-Branch ist der teuerste Altlast des Unternehmens: Es hat tausende Euro Gehalt gekostet, erzeugt 0 Euro Wert beim Kunden, und es blockiert das Refactoring anderer Teams durch Merge-Konflikte. Depriorisierung stoppt diese Altlastenbildung.

Wodurch sich diese Intervention von anderen Hebeln unterscheidet

Dependency Mapping und das Bottleneck-Design decken auf, wo genau der Stau der Firma verortet ist (z.B. "Die Architektur-Security-Freigabe-Abteilung"). Die Portfolio Deprioritization ist der Feuerwehr-Schalter, der abgedrückt wird, um zu verhindern, dass die Firma den erkannten Bottleneck weiterhin mit neuen Neugeschäften überflutet.

Wie du die Intervention sauber einleitest

Erzwinge das konsequente "Pull"-Prinzip. Wenn der Vorstand ein neues KI-Projekt vorschlägt, nimm die Prio-Liste aus der Tasche (1-10) und frage: "Super. Welches der aktuellen Projekte 1 bis 10 nehmen wir für die KI heute aus dem Sprint? Nennt mir ein Projekt, das dafür pausiert wird." Wenn die Vorstände sagen "Das läuft alles on-top (Zusätzlich)", verlasse den Raum. "Zusätzlich" existiert in der Systemtheorie nicht ohne Überlastung.

Erste Umsetzungsschritte

Gestalte die "Stop-Linie" (WIP-Limit) verbindlich. Wenn Teams versuchen, gestoppte Vorhaben nebenbei weiterzuführen, muss diese Regelverletzung sichtbar und adressiert werden. Der Flow der Wertauslieferung sollte Vorrang vor lokaler Ressourcenauslastung haben. Optimiere daher nicht primär auf die Frage "Ist jeder beschäftigt?", sondern auf "Wie schnell wird relevante Arbeit fertig?"

Woran du Wirkung erkennst

Gibt es in unserer IT ein von ganz oben diktiertes, unumstößliches Limit für die maximale Menge an parallel aktiven "Epics" in der Firma, bevor das System weitere Projekt-Budget-Bewilligungen rein technisch verweigert?

Quellen

Donald Reinertsen — The Principles of Product Development Flow (Celeritas, 2009)

Wikipedia: Little's Law

Gene Kim et al. — The Phoenix Project, Kap. 14: WIP Limits (IT Revolution, 2013)