Wir plädieren oft dafür, in einer Organisation weniger Projekte parallel laufen zu lassen. Dann kommt manchmal der Einwand: “In der Theorie mag das ja stimmen, aber bei uns …” und dann werden Argumente angegeben, warum das Multitasking auf der Organisationsebene unvermeidlich ist.

Ich möchte also heute eine Situation betrachten, die schon ziemlich realistisch ist, und an diesem Beispiel die Nachteile dieses Multitaskings (viele Projekte parallel bearbeiten) offensichtlich machen. Hier ist ein kleines Portfolio aus fünf Projekten:

Die Projekte sind eher kurz, sie variieren von 10 Personentagen (GoCloud) bis zu 60 PT (NESSi). Wenn bei Ihnen die Projekte größer sind, können Sie die Zeiteinheit gern zu Personenwochen oder sogar Personenmonaten ändern, an der Diskussion ändert sich nichts.

Wir haben ein Team von sechs Leuten, die mehr oder weniger gleichzeitig an den Projekten arbeiten sollen. Im normalen Alltag arbeitet jede/r an dem “was gerade anliegt”, als Beispiel habe ich hier die Themen dargestellt, mit denen eine Person (Marcel) im Laufe von 28 Arbeitstagen (also 5-6 Wochen) beschäftigt ist:

Die Farbe eines Streifens gibt an, zu welchem Projekt eine Aufgabe gehört. Pausen, Wochenenden usw. blenden wir aus, damit das Bild nicht zu unübersichtlich wird. Die Breite der Streifen variiert natürlich: manche Aufgaben sind in ein paar Stunden erledigt, andere brauchen bis zu fünf Arbeitstagen (etwa die Aufgabe aus dem Projekt BGR, von Tag 8-12). Manchmal hat Marcel mehrere Aufgaben aus demselben Projekt hintereinander, manchmal muss er zwischen Projekten umschalten. Die Umschaltzeiten zwischen Aufgaben und Projekten vernachlässige ich hier komplett, auch wenn sie in der Realität erheblich sein können.

Wenn man das für das ganze Team visualisiert, sieht es so aus:

Ich simuliere hier den Arbeitsalltag, indem ich mit einem Script die Aufgaben eines Projektes zufällig den Leuten zuordne. Dabei hat Lukas ziemlich wenig abbekommen, im realen Leben würde man ihn schon mit dem nächsten Projekt auslasten. Dennis hat ein paar Tage länger zu tun als alle anderen. Er könnte beispielsweise ein Spezialist sein, dessen Kompetenzen wir für die Projekte Alpha und BGR brauchen.

Das Bild zeigt, dass die Projekte ziemlich fragmentiert bearbeitet werden. Die meiste Zeit sind alle fünf Projekte aktiv, und es wird häufig zwischen Projekten gewechselt. Abgesehen von den Verlusten durch Kontextwechsel hat dieses Vorgehen noch einen weiteren wesentlichen Nachteil:

Alle Projekte werden spät fertig

Das kleinste Projekt, GoCloud, hat zwar nur 10 Personentage Umfang, wird aber erst an Tag 30 fertig. Und das, obwohl wir vier Leute daran arbeiten lassen! Ein Projekt ist ja erst dann abgeschlossen, wenn seine letzte Aufgabe abgearbeitet ist. In der Simulation ergeben sich die folgenden Enddaten:

Projekt      Ende
-----------------
Alpha      Tag 36
BGR        Tag 35
GoCloud    Tag 30
NESSi      Tag 31
Replay     Tag 28

Hier ist dieselbe Information nochmal grafisch aufbereitet, die Linien starten mit der ersten Aufgabe eines Projekts und enden bei seiner Fertigstellung.

Alle Projekte werden spät fertig, weil “immer etwas dazwischen kommt” – die Projekt verzögern sich gegenseitig.

Abarbeiten nach Priorität des Projekts

Die radikale Gegenmaßnahme wäre: “Single Tasking” – das Team arbeitet nur noch an einem Projekt zur gleichen Zeit und schaltet erst nach Fertigstellung auf das nächste Projekt um. Und da kommen dann die Einwände: “Wir können die Aufgaben nicht beliebig den Personen zuordnen” (es gibt also Spezialisten); “Wir müssen manchmal auf Zuarbeit warten”, “Der Kunde erwartet, dass wir schon mal anfangen” usw.

Weniger radikal ist ein einfaches “Defragmentieren” der Abarbeitung. Dazu ordnet man die Projekte nach ihrer Priorität, z.B.

1. GoCloud
2. BGR
3. Replay
4. Alpha
5. NESSi

und sagt dann zu jedem einzelnen: “Nimm Dir die nächste Aufgabe immer aus dem Projekt mit der höchsten Priorität.”

Wie kann die Priorität bestimmt werden? In der Simulation nehme ich die Regel “Kleinere Projekte haben Vorrang”. In einem realen Projektportfolio würde man Verzögerungskosten und Projektdauer (in Kalendertagen) schätzen und dividieren (“Weighted Shortest Job First”). In der Simulation mache ich ein paar Vereinfachungen: die Verzögerungskosten für alle Projekte werden als gleich angenommen (z.B. 500 Euro pro Arbeitstag), und die Abarbeitungszeit (Kalendertage) wird als proportional zum Projektumfang (Personentage) angesetzt. Dann gewinnt immer das kleinste Projekt.

Mit Abarbeitung nach Priorität sieht das Bild so aus:

Alle arbeiten also zuerst das (kürzeste) Projekt GoCloud (10 PT) ab. Erst, wenn man dort keine Aufgaben mehr hat, nimmt man sich Aufgaben von Projekt BGR (20 PT) usw. Es werden immer noch dieselben Aufgaben von denselben Personen abgearbeitet, nur in anderer Reihenfolge. In der Grafik sieht man, dass es jetzt wesentlich weniger fragmentiert zugeht.

Entsprechend früher werden die Projekte fertig:

Projekt      Ende
-----------------
Alpha	   Tag 29
BGR        Tag 13
GoCloud	   Tag  7
NESSi	   Tag 36
Replay	   Tag 16

Im Vergleich zur willkürlichen Zuordnung laufen auch weniger Projekte parallel:

Wir können die ökonomischen Folgen einfach ausrechnen, indem wir die Verzögerungskosten vergleichen. Wenn für jedes der fünf Projekte Verzögerungskosten von 500 Euro pro Tag auflaufen, ergibt sich:

• bei willkürlicher Zuordnung 36 + 35 + 30 + 31 + 28 = 160 Tage Verzögerung, mithin 80.000 Euro Verzögerungskosten
• bei Zuordnung nach Prioritäten 29 + 13 + 7 + 36 + 16 = 101 Tage Verzögerung, also 50.500 Euro Verzögerungskosten.

Ein Unterschied von knapp 30.000 Euro. Natürlich sind weitere Einsparungen durch kürzere Feedback-Zyklen und verringerte Umschaltverluste zu erwarten.

Wenig Aufwand für die Umstellung

Den Nutzen der Defragmentierung bekommt man schon relativ “billig”, d.h. ohne allzu große Umstellungen von der Organisation zu verlangen. Es setzt natürlich voraus, dass sich die Organisation auf eine Rangfolge der Projekte verständigen und diese über einen längeren Zeitraum stabil halten kann.

Falls also bei Ihnen die Aufgaben eher so bearbeitet werden

als so

dann könnte der erste Schritt sein, sich zu fragen:

Wie sieht eine sinnvolle Rangfolge der aktuell laufenden Projekte aus?

Matthias Berth