Gestern habe ich am Beispiel illustriert: Wenn man Projekte nacheinander abarbeitet, statt sie parallel laufen zu lassen, kann man erhebliche Verzögerungskosten einsparen. Das liegt daran, dass einige Projekte früher fertig werden, wodurch ihre Verzögerungskosten nicht weiterlaufen. Wir haben dafür mehr Kapazität auf jedes einzelne Projekt konzentriert, wodurch die Projektlaufzeit entsprechend kürzer wird.

Das ist natürlich idealisiert, und es kommt gleich der Einwand: “Dann könnten wir ja mit der ganzen Organisation jeweils nur an einem einzigen Projekt arbeiten. Das würde zwar ein Maximum an Verzögerungskosten sparen, aber die Leute treten sich dann so auf die Füße, dass auch nichts mehr fertig wird.”

Zum Beispiel: Es laufen immer ungefähr 100 Projekte gleichzeitig, mit einer IT-Organisation von 200 Leuten, und jedes Projekt dauert 50 Personenmonate (so wie gestern die Projekte Alpha und Beta). Wenn ich dann alle 200 Leute jeweils auf ein einziges Projekt ansetze, braucht jedes Projekt nur 1/4 Monat. Sie sehen schon, das klingt absurd. Es erinnert an den Wernher von Braun zugeschriebenen Spruch:

Crash programs fail because they are based on theory that, with nine women pregnant, you can get a baby in a month.

Weniger Projekte gleichzeitig betreiben heißt, dass mehr Leute zugleich an einem Projekt arbeiten (müssen). Je größer die Gruppe, die an etwas arbeitet, desto größer wird natürlich der Koordinationsaufwand. Allein dieser Koordinationsaufwand wird irgendwann alle Vorteile der Verzögerungskosten zunichte machen, ganz zu schweigen davon, dass wir auch noch auf externe Zuarbeit oder Feedback warten müssen.

Das ist aber nur das extreme Ende des Spektrums. Im Alltag des Projektmanagements bewegt man sich eher am anderen Ende: zuviele gleichzeitig laufende Projekte, die sich dadurch automatisch in die Länge ziehen.

Statt 100 gleichzeitige Projekte mit 200 Leuten zu betreiben, sollte man dann lieber daran arbeiten, die Parallelität schrittweise zu reduzieren. Das ist klassisches Lean Thinking: gleichzeitig laufende Projekte sind work in process, ein WIP-Limit begrenzt diese. Durch schrittweise Verringerung des Limits werden Probleme aufgedeckt und gelöst. Das können z.B. Koordinationsprobleme sein, oder unnötiges Warten. Im Ergebnis werden wir immer besser darin, Projekte zügig abzuarbeiten.

Matthias Berth