Portfolio Deprioritization

Systemproblem

In 90% der Unternehmen herrscht die absolute "Auslastungs-Lüge" (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 physikalisch 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) zerstört die verbleibende Restintelligenz der Ingenieure.

Intervention

"Portfolio Deprioritization" (Das Töten von Halbfabrikaten) ist das WIP-Limit (Work In Progress) auf CEO-Ebene. Die Intervention lautet: Ihr friert sofort 40 der 50 laufenden Projekte hart ein. Es werden keine neuen Zeilen Code mehr geschrieben. Niemand darf mehr Code in Projekt-Ordnern pushen, die gestoppt sind. Alle 100 Entwickler stürzen sich ("Swarming") massiv fokussiert auf die verbleibenden 10 Projekte, um sie vom "In-Progress"-Friedhof unbarmherzig in die Produktion ("Done") zu peitschen.

Erwartete Wirkung

Der Stau auf der Autobahn löst sich instantan auf. Obwohl die Firma auf dem Papier 80% ihrer Projekte "gestoppt" hat, liefert sie plötzlich in zwei Monaten mehr Umsatz-schaffende Features aus, als in den drei Jahren zuvor. Die "Lead Time" (Zeit von der Idee bis zum Kunden) stürzt spektakulär abwärts. Zusätzlich steigt die Code-Qualität dramatisch an, weil Devs und Ops (z.B. Datenbank-Admins) nicht mehr für 50 verschiedene Projekt-Sitzungen in Scheiben geschnitten werden, sondern kohärent als ein Gehirn an einer Architektur arbeiten können.

Nebenwirkungen und Risiken

Politisches Kriegsgebiet. Jedes der 50 Zombie-Projekte hat einen Manager, der seinen persönlichen Bonus daran geknüpft hat. Wenn der CTO 40 Projekte "depriorisiert", fühlen sich 40 Manager degradiert. Sie werden über Shadow-IT, Backchanneling und Lügen versuchen, Ressourcen für ihr (eingefrorenes) Projekt abzuzapfen. Eine Depriorisierung auf Portfolio-Ebene, die nicht eisern vom Vorstand gegen alle weichenden Ego-Verletzungen der Middle-Manager verteidigt wird, hält keine 3 Wochen.

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 Giftmüll 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 Gift-Produktion.

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 hirnlos gestarteten Neugeschäften überflutet.

Wie du die Intervention sauber einleitest

Erzwinge das knochenharte "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 schmeißen wir für die KI heute aus dem Sprint? Nennt mir ein Projekt, das sterben darf." Wenn die Vorstände sagen "Das läuft alles on-top (Zusätzlich)", verlasse den Raum. "Zusätzlich" existiert in der Systemtheorie nicht ohne Kollaps.

Erste Umsetzungsschritte

Gestalte die "Stop-Linie" (WIP-Limit) psychologisch so hart wie möglich. Wenn Teams versuchen zu schummeln ("Wir machen das Prio 8 Projekt freitags nebenbei"), bestrafe diesen Regelbruch so hart wie einen Produktions-Ausfall. Mache den Flow (Wertauslieferung) heilig und unantastbar. Optimiere nie auf Ressourcenauslastung ("Ist jeder beschäftigt?"), sondern immer auf Liefergeschwindigkeit ("Liegt der Code nutzlos rum?").

Woran du Wirkung erkennst

Gibt es in unserer IT ein von ganz oben diktiertes, unumstößliches Limit für die absolute Maximal-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)