In den meisten Multiprojekt-Organisationen ist der WIP (Work In Progress, Workload) viel zu hoch.
Dadurch werden Mechanismen in Gang gesetzt, die die Durchlaufzeit der Projekte verlängern:
- schädliches Multitasking
- dünne Ressourcenverteilung
- DeSynchronisation
- DeFokussierung
Verlängerte Durchlaufzeiten erzeugen Verspätungen. Daraus entsteht der Druck, jedes neue Projekt so schnell wie möglich anzufangen, was den WIP erneut erhöht. Ein Teufelskreis!
Der erste Schritt hin zu einer bewussten Kontrolle/Steuerung des Workloads besteht darin, einen Teil der Projekte einzufrieren, d.h. die Arbeit an diesen Projekten vorübergehend zu unterbrechen. Dadurch konzentrieren sich Mitarbeiter und Führungskräfte auf weniger Projekte gleichzeitig. In Folge dessen
- reduziert sich schädliches Multitasking
- sind die laufenden (nicht eingefrorenen) Projekte besser mit Ressourcen ausgestattet
- erfolgt die Arbeit an den Projekten synchronisierter
- reagieren Manager früher und wirksamer auf Unterstützungsanforderungen der Projekte
Diese Effekte verringern die Restlaufzeit der laufenden Projekte. Sowie ein Projekt abgeschlossen ist, wird ein „eingefrorenes“ Projekt wieder aufgenommen. Sind keine eingefrorenen Projekte mehr vorhanden, kann das erste neue Projekt gestartet werden.
Diese Vorgehensweise erhöht die Projektfertigstellungsrate signifikant: die vorübergehend eingefrorenen Projekte und die erst später gestarteten neuen Projekte werden deutlich früher fertig (als sie ohne WIP-Reduzierung fertig geworden wären).
Problem:
Aufgrund langjähriger Prägung sind viele Führungskräfte darauf fokussiert, lokal zu optimieren (eine einzelne Abteilung, ein einzelnes Projekt). Deshalb ist es sehr verständlich, dass sie auch die WIP-Reduzierung aus Abteilungssicht betrachten; sie wollen den WIP für die verschiedenen Ressourcen reduzieren – und zwar unterschiedlich stark, abhängig davon, wie stark die einzelnen Teams aus-/überlastet sind.
Dieser Ansatz ist nicht nur wenig effektiv, er ist sogar schädlich. Beides wird im Folgenden erläutert:
Multiprojektmanagement ist geprägt von Variabilität und Murphy. Deshalb schwankt – auch bei hervorragender Organisation – der Workload der verschiedenen Bereiche erheblich. Mal ist die eine Abteilung, mal die andere besonders belastet.
Die bei zu hohem Workload entstehenden Effekte führen in der Regel dazu, dass alle Ressourcen vollkommen überlastet AUSSEHEN, während sie tatsächlich SEHR viel mehr leisten könnten. Besonders stark ist die dramatische Ineffektivität an zwei typischen Stellen sichtbar:
a. bei den Ressourcen, die nicht nur in einer Projektphase intensiv benötigt werden – diese SEHEN dann extrem überlastet AUS
b. im Projektverlauf in der Phase, in der die zuvor parallel verlaufenden Arbeiten wieder zusammengeführt werden (der Integrationsphase)
Die Kombination von Variabiltät / Murphy und WIP-induzierter Ineffektivität macht es unmöglich, eine sinnvolle Aussage über die tatsächliche Kapazität (und damit über die tatsächliche Überlastung) einer Abteilung / Ressourcengruppe zu machen. Der Versuch, es dennoch zu tun, führt zu:
- verlorengehende Zeit: solange untersucht, diskutiert und spekuliert wird, findet keine reale WIP-Reduzierung und damit auch keine Verbesserung des Durchsatzes statt).
- Frustration: wo spekuliert wird, ist man nicht auf dem Boden der Tatsachen. Wo man den Boden der Tatsache verlässt, erlangt irrationale Argumentation die Oberhand. Wo irrationale Argumentation die Handlungen bestimmt, entsteht Frustration. Wo Frustration entsteht, geht Vertrauen (z.B. in die Wirksamkeit der WIP-Reduzierung) verloren.
- Fortsetzung der Prägung aller Beteiligten auf lokale Optimierung, während ihnen gleichzeitig gesagt wird, dass lokale Optimierung kontraproduktiv ist.
Wie es viel einfacher und erheblich wirksamer funktioniert:
1. Das Management priorisiert die Projekte und weist den STOP von so viel niedrig priorisierten Projekten an, dass dadurch eine pauschale WIP-Reduzierung von wenigstens 25% erfolgt.
2. Sowie ein Projekt die besonders kritische Integrationsphase durchlaufen hat, wird ein eingefrorenes Projekt wieder aufgenommen. So wird das reduzierte WIP-Niveau in etwa aufrecht erhalten.
Details dazu finden sie in Kapitel 19 von Projects that Flow.
