Über die meisten Gesetze, die in Organisationen zitiert werden, kann man hervorragend streiten. Bei Conway’s Law kann man über den Mechanismus streiten. Bei Dunbar’s Number über die genaue Zahl und deren Herkunft. Bei Brooks über den Geltungsbereich. Das ist auch völlig in Ordnung, das sind Beobachtungen, und Beobachtungen haben bzw. brauchen Kontext. Bei einem geht das nicht. Little’s Law kann man nicht widerlegen. Man kann es höchstens ignorieren.
John Little hat 1961 einen Aufsatz veröffentlicht mit dem Titel "A Proof for the Queuing Formula: L = λW". Der Titel sagt schon alles Wesentliche: Die Formel war unter Operations-Research-Leuten längst in Gebrauch, nur hatte sie niemand bewiesen. Little hat das nachgeholt.
Warteschlangentheorie ist eine Disziplin voller Annahmen. Die klassischen Modelle setzen voraus, dass man weiss, wie Arbeit ankommt und wie lange sie dauert. M/M/1 heisst bspw.: Ankünfte poissonverteilt, Bedienzeiten exponentiell, ein Bediener. Ändert man eine dieser Annahmen, ändert sich das Ergebnis. Deshalb gibt es unzählige Modelle, die alle nur unter bestimmten Bedingungen gelten.
Little hat bewiesen, dass L = λW keine dieser Bedingungen braucht. Übersetzt: Durchlaufzeit = Anzahl paralleler Arbeit geteilt durch Durchsatz. Egal, wie Arbeit ankommt. Egal, wie lange sie dauert. Egal, in welcher Reihenfolge sie abgearbeitet wird. Egal, wie viele Leute parallel daran arbeiten.
Das ist der Punkt, den man einmal sacken lassen muss. Der übliche Einwand gegen jedes Modell lautet "unser Umfeld ist zu komplex, bei uns gilt das nicht". Bei Warteschlangenmodellen ist dieser Einwand oft berechtigt. Bei Little’s Law ist er schlicht nicht verfügbar.
Eine Voraussetzung gibt es dann doch. Das System muss stabil sein – einigermassen. Über die Zeit muss ungefähr so viel rausgehen wie reingeht. Genau die Bedingung verletzt so ziemlich jedes Portfolio, welches mir je begegnet ist. Lustigerweise ist der Reflex darauf immer derselbe: Bedingung nicht erfüllt, Gesetz gilt nicht, weiter im Text. Das ist exakt falsch herum. Wenn mehr reingeht als rausgeht, konvergiert die Durchlaufzeit nicht auf einen Wert. Sie wächst einfach weiter, Quartal für Quartal. Die verletzte Bedingung ist keine Entwarnung. Sie macht das Problem nur noch grösser.
Nehmen wir ein Rechenbeispiel. Zwölf Entwicklungsprojekte laufen parallel, sechs werden pro Jahr fertig. Durchlaufzeit gemäss Little’s Law: zwei Jahre. Ein paar Jahre später laufen dreissig Projekte. Die Mannschaft ist die gleiche geblieben, es werden also weiterhin sechs pro Jahr fertig. Durchlaufzeit nun: knapp fünf Jahre. Ohne dass irgendwer langsamer geworden wäre.
Und das ist die optimistische Variante. Little’s Law nimmt den Durchsatz als gegeben an. In der Realität sinkt er, weil dieselben Leute jetzt zwischen mehr Projekten hin und her wechseln. Die Formel unterschätzt den Schaden sogar noch. Dazu kommt: In den meisten Organisationen weiss niemand wirklich, wie viele Projekte tatsächlich laufen.
Es gibt die Liste im Portfolio-Board, und es gibt die Realität. «Zombie-Projekte», die formal nie beendet wurden. «U-Boote», die laufen, von denen aber keiner weiss, Nebenaufträge, die als Gefallen begonnen haben. Support für Produkte, die seit Jahren im Markt sind. Nichts davon taucht in der Rechnung auf, aber alles davon bindet Kapazität. Der reale «Work-in-Progress» (WP) ist immer höher als das gemessene. Die Rechnung oben ist also nicht nur optimistisch, sie ist zu freundlich in mehrfacher Hinsicht.
Kurze Antwort: Weil die Verlängerung nie dem Verursacher zugeordnet wird. Das neue Projekt #31 wird nicht langsam. Das ältere Projekt #7 wird langsam, und zwar Monate später, nachdem das neue Projekt gestartet hat. Und wenn dann jemand fragt, warum Projekt #7 nicht mehr so vorankommt, gibt es immer eine lokale Erklärung und der Verursacher, Projekt #31, wird aussen vor gelassen: Ein Lieferant hat nicht geliefert. Ein Regulator hatte Rückfragen. Ein Schlüsselentwickler ist krank. Ein technisches Problem war schwieriger als gedacht.
Das Ärgerliche ist: Das stimmt alles. Diese Dinge sind wirklich passiert. Sie sind nur nicht die Ursache. Deshalb landet die Diagnose zuverlässig bei "wir müssen effizienter werden" und nicht bei "wir machen zu viel gleichzeitig". Und dann wird ein Effizienzprogramm aufgesetzt. Also noch ein Projekt.
Wenn die Mechanik so simpel ist und die Konsequenzen so gross sind, warum passiert es trotzdem? Weil die Kosten so verteilt sind, dass sie in einer einzelnen Entscheidung niemand spürt.
Ein Key Account braucht eine Variante. Eine Region hat regulatorischen Bedarf. Ein Wettbewerber hat etwas gelauncht. Jemand aus dem Board hatte eine Idee. Jedes dieser Projekte ist für sich genommen begründbar, budgetiert und sinnvoll. Und keines kostet in dem Moment, in dem es gestartet wird, sichtbar etwas.
Es gab nie ein Meeting mit dem Titel "Verdoppelung des Portfolios". Es gab zig einzelne Meetings, in denen jeweils ein Projekt dazukam, und in jedem einzelnen war die Entscheidung richtig. Keine einzelne Entscheidung ist falsch. Erst ihre Summe ist es. Und die Summe entscheidet niemand. Der Zustand ist nicht das Ergebnis einer Entscheidung, die schlecht getroffen wurde, sondern das Ergebnis einer Entscheidung, die nie zu einer geworden ist. Es gibt in den meiste Organisationen schlicht keinen Ort, an dem sie hätte getroffen werden können.
Ein WIP-Limit kostet kein Budget, keine Tools, keine Reorganisation. Es ist der billigste Hebel im ganzen System. Und trotzdem sitzt kaum jemand in einem Portfolio-Review, in dem tatsächlich etwas gestrichen wird (geschweige denn tatsächlich WIP-Limits existieren). Weil das Problem nicht die Methode ist. Die Mechanik ist trivial. Es fehlt die Instanz, für die das Portfolio als Ganzes eine Entscheidung ist.
Und damit ist es genau das, was solche Probleme fast immer sind: kein technisches Problem, sondern ein organisatorisches. Die Frage, die ich mir stelle, wenn ich in eine R&D-Organisation komme, ist deshalb nicht, ob zu viel gleichzeitig läuft. Das ist meistens schon klar. Die Frage ist: Wo genau wird die Summe entschieden? Und wird sie überhaupt irgendwo entschieden?