Brooks' Gesetz: Warum mehr Leute Projekte langsamer machen

Vier Wochen Verzug, fünf neue Leute, neun Wochen Verzug: Der Beitrag erklärt, was Fred Brooks aus dem Desaster von IBM OS/360 gelernt hat, warum der Mann-Monat ein Mythos ist, wie die Zahl der Kommunikationswege mit jedem Mitarbeiter explodiert, warum Führungskräfte trotzdem immer Personal nachschieben und welche vier Alternativen funktionieren, vom Umfangsschnitt bis zum chirurgischen Team.

Großes Projektteam beugt sich von oben gesehen über Baupläne auf einem Tisch, Sinnbild für Brooks' Gesetz, nach dem mehr Leute ein verspätetes Projekt weiter verzögern

Das Projekt war vier Wochen hinter dem Plan, und der Geschäftsführer tat, was Geschäftsführer in dieser Lage fast immer tun: Er gab dem Projektleiter fünf zusätzliche Leute. Sechs Wochen später war das Projekt neun Wochen hinter dem Plan. Der Projektleiter wurde ausgetauscht. Der neue Projektleiter bekam drei weitere Leute. Man muss kein Prophet sein, um zu wissen, wie es weiterging. Fred Brooks hat diese Geschichte 1975 in einem Buch beschrieben, das auf den Erfahrungen des größten Softwareprojekts seiner Zeit beruht, und er hat daraus ein Gesetz gemacht, das seinen Namen trägt und das in jeder Branche gilt, in der Menschen gemeinsam etwas Kompliziertes bauen: Wer einem verspäteten Projekt Leute hinzufügt, verspätet es weiter.

Das Buch, das aus einem Desaster entstand

Brooks leitete in den Sechzigern bei IBM die Entwicklung des Betriebssystems OS/360, ein Projekt mit Tausenden von Mitarbeitern, das Jahre zu spät fertig wurde und ein Vielfaches des Budgets verbrauchte. Nachdem es vorbei war, schrieb er auf, was er gelernt hatte. The Mythical Man-Month von Frederick P. Brooks (Amazon Affiliate Link) ist seitdem nie vergriffen gewesen, und die Jubiläumsausgabe von 1995 enthält ein Kapitel, in dem Brooks zwanzig Jahre später prüft, welche seiner Thesen gehalten haben. Fast alle. Das Buch ist über Software geschrieben, aber ich empfehle es Geschäftsführern aus Maschinenbau, Bauwesen und Beratung, weil sein eigentliches Thema nicht Software ist. Es ist die Frage, warum Menschen nicht addierbar sind.

Der Titel zielt auf den Kern: Der Mann-Monat, die Rechengröße, mit der Projekte geplant werden, ist ein Mythos. Er unterstellt, dass Menschen und Zeit austauschbar sind, dass zwölf Leute in einem Monat schaffen, was einer in zwölf Monaten schafft. Das stimmt für Aufgaben, die sich ohne Abstimmung aufteilen lassen, für das Pflücken von Äpfeln oder das Eintüten von Briefen. Es stimmt nicht für Aufgaben, bei denen die Teile zusammenpassen müssen. Brooks' Bild dafür ist unvergesslich: Neun Frauen bringen ein Kind nicht in einem Monat zur Welt.

Warum mehr Leute weniger Ergebnis bringen

Brooks nennt drei Gründe, und alle drei lassen sich in jedem verspäteten Projekt beobachten, das mit Personal gerettet werden soll:

  1. Die Einarbeitung frisst die, die einarbeiten. Neue Leute können nicht sofort produktiv sein. Sie müssen verstehen, was gebaut wird, warum, und was schon da ist. Wer sie einarbeitet, sind die erfahrenen Mitglieder, also genau die, die bisher die Arbeit gemacht haben. In den ersten Wochen sinkt die Leistung des Teams, weil die Besten lehren statt zu bauen.
  2. Die Arbeit lässt sich nicht beliebig teilen. Ein Projekt, das vier Wochen zurückliegt, hat meist nicht zu wenige Aufgaben, sondern zu viele Abhängigkeiten. Die nächste Aufgabe wartet auf die vorherige. Fünf neue Leute finden keine fünf freien Arbeitspakete vor, sie finden ein Team, das auf drei Entscheidungen wartet. Sie füllen die Wartezeit mit Meetings.
  3. Die Kommunikation wächst schneller als das Team. Das ist Brooks' eigentlicher Beitrag. Bei n Personen, die sich abstimmen müssen, gibt es n mal (n minus 1) geteilt durch 2 Kommunikationswege. Bei fünf Leuten sind das zehn. Bei zehn Leuten 45. Bei zwanzig 190. Jeder neue Mensch erhöht nicht nur seinen eigenen Abstimmungsbedarf, er erhöht den aller anderen. Irgendwann verbringt das Team mehr Zeit damit, sich abzustimmen, als zu arbeiten, und die Verspätung wächst mit jeder Verstärkung.

Der dritte Punkt ist derselbe Mechanismus, den ich in Sägezahneffekt im Zeitmanagement für den Einzelnen beschrieben habe: Jede Unterbrechung setzt die Konzentration zurück, und die Rückkehr zur Aufgabe kostet Zeit, die niemand plant. In einem Team von zwanzig Leuten ist jeder der 190 Kommunikationswege eine potenzielle Unterbrechung. Brooks hat das nicht als Psychologie beschrieben, sondern als Arithmetik. Beides führt zum selben Ergebnis.

Verknotete Netzwerkkabel in einem Serverschrank, Sinnbild für die Kommunikationswege, die nach Brooks' Gesetz mit jedem zusätzlichen Teammitglied explodieren

Warum Führungskräfte trotzdem immer Leute nachschieben

Das Gesetz ist seit fast fünfzig Jahren bekannt, und es wird täglich gebrochen. Das liegt nicht an Unwissen. Es liegt daran, dass Leute nachschieben für die Führungskraft die einzige sichtbare Handlung ist. Ein Geschäftsführer, der einem verspäteten Projekt Personal gibt, hat etwas getan. Einer, der sagt „Wir warten und schneiden den Umfang zurück“, hat scheinbar nichts getan, und das ist in den meisten Unternehmen die gefährlichere Position. Brooks' Gesetz wird gebrochen, weil es dem Bedürfnis widerspricht, handelnd zu wirken.

Dazu kommt der Mechanismus, den ich in Planungsfehlschluss beschrieben habe: Projekte werden optimistisch geplant, mit der Annahme, dass diesmal nichts dazwischenkommt. Wenn dann etwas dazwischenkommt, wird die Verspätung nicht als Planungsfehler gedeutet, sondern als Kapazitätsproblem. Und Kapazität, so die Logik, kauft man nach. Brooks' Antwort darauf ist nüchtern: Ein Projekt, das zu spät ist, war meist von Anfang an zu knapp geplant, und die einzige ehrliche Reaktion ist, den Plan zu korrigieren, nicht das Team zu vergrößern.

Und schließlich unterschätzen Führungskräfte, was Teamgröße mit Teamdynamik macht. Ein Team, das nach Monaten eingespielt ist, wird durch fünf Neue in eine frühere Phase zurückgeworfen. Wer das Tuckman-Modell kennt, weiß, dass Teams Phasen durchlaufen, bevor sie leistungsfähig sind. Verstärkung mitten im Projekt heißt, diese Phasen noch einmal zu durchlaufen, mit weniger Zeit als beim ersten Mal. Dazu kommt, dass in größeren Gruppen der Einzelbeitrag unsichtbar wird und die Leistung sinkt, was ich in Soziales Faulenzen beschrieben habe. Brooks' Gesetz und der Ringelmann-Effekt sind zwei Seiten derselben Rechnung.

Was man stattdessen tut, wenn ein Projekt zu spät ist

Brooks' Buch ist kein Buch der Verzweiflung. Es beschreibt, was funktioniert, und die Vorschläge sind so alt wie das Gesetz und so selten angewendet:

  • Schneide den Umfang, nicht die Qualität: Ein verspätetes Projekt hat drei Stellschrauben: Zeit, Umfang, Personal. Brooks zeigt, dass die dritte nicht funktioniert. Die zweite funktioniert fast immer, wird aber am seltensten gewählt, weil sie ein Eingeständnis verlangt: Wir schaffen nicht alles. Wer sprachliche Weichmacher vermeidet, kann diesen Satz sagen, ohne dass er wie eine Kapitulation klingt. Er ist die einzige Aussage, die dem Auftraggeber tatsächlich hilft.
  • Verändere die Struktur statt die Größe: Brooks schlägt das chirurgische Team vor: eine kleine Kerngruppe, die die eigentliche Arbeit macht, umgeben von Unterstützern, die ihr alles abnehmen, was nicht Kernarbeit ist. Das ist die Antwort auf die Kommunikationsarithmetik: Nicht mehr Leute, die mitreden, sondern mehr Leute, die den wenigen den Rücken freihalten.
  • Verstärke früh oder gar nicht: Wenn Personal nötig ist, dann am Anfang, wenn die Einarbeitung noch keine Fertigstellung kostet und die Struktur sich auf die Größe einstellen kann. Verstärkung im letzten Drittel ist fast immer ein Verlustgeschäft.
  • Rechne den Mann-Monat ehrlich: Wer plant, sollte für jede Aufgabe fragen, ob sie teilbar ist. Teilbare Aufgaben skalieren mit Personal. Unteilbare skalieren mit nichts. Ein Plan, der beides gleich behandelt, ist der Ursprung der Verspätung, die später mit Personal bekämpft wird.

Ich schicke Führungskräfte, die ein Projekt „mit Leuten retten“ wollen, ungern zu Brooks, weil das Buch technisch klingt. Aber seine 300 Seiten enthalten mehr über Führung als die meisten Führungsbücher, und das Kapitel über das chirurgische Team ist die klarste Beschreibung, die ich kenne, wie man ein Team so baut, dass Größe nicht zur Last wird. Wer nur ein Kapitel liest, sollte das zweite lesen, in dem Brooks an einem Beispiel vorrechnet, wie ein Vorhaben, das drei Leute in vier Monaten schaffen sollten, durch zwei nachgeschobene Kollegen nach dem ersten Monat später fertig wird, als wenn man die drei einfach hätte weiterarbeiten lassen. Die Rechnung ist fünfzig Jahre alt und wurde noch nie widerlegt.

Chirurgisches Team arbeitet konzentriert im Operationssaal, Sinnbild für Brooks' Modell des chirurgischen Teams mit kleiner Kerngruppe und Unterstützern

Häufige Fragen zu Brooks' Gesetz

Was besagt Brooks' Gesetz?

Wer einem verspäteten Projekt zusätzliche Mitarbeiter zuweist, verzögert es weiter. Formuliert hat es Fred Brooks 1975 in The Mythical Man-Month auf Basis seiner Erfahrungen mit der Entwicklung von IBM OS/360. Gründe sind der Einarbeitungsaufwand, die begrenzte Teilbarkeit von Aufgaben und der überproportional wachsende Kommunikationsaufwand.

Gilt Brooks' Gesetz nur für Softwareprojekte?

Nein. Es gilt für jede Arbeit, deren Teile aufeinander abgestimmt werden müssen: Bauprojekte, Produktentwicklung, Beratungsmandate, Reorganisationen. Für leicht teilbare Arbeit ohne Abstimmungsbedarf gilt es nicht, dort hilft zusätzliches Personal tatsächlich.

Wie viele Kommunikationswege hat ein Team?

Bei n Personen n mal (n minus 1) geteilt durch 2. Fünf Personen haben zehn Wege, zehn Personen 45, zwanzig Personen 190. Jeder neue Mitarbeiter erhöht den Abstimmungsbedarf aller anderen, nicht nur seinen eigenen.

Was tut man stattdessen, wenn ein Projekt zu spät ist?

Den Umfang zurückschneiden, den Plan ehrlich korrigieren, die Struktur des Teams verändern, etwa nach dem Modell des chirurgischen Teams, und Verstärkung nur früh im Projekt einsetzen, nicht in der Endphase.

Brooks' Gesetz: Wer Menschen addiert, sollte wissen, dass er auch Wege addiert

Das Projekt aus dem Anfang wurde am Ende mit einem Team von sechs Personen fertig, halb so groß wie auf dem Höhepunkt, mit einem Umfang, den man um ein Drittel gekürzt hatte, und einem Kunden, der über die Kürzung weniger verärgert war als über die vorherigen Verschiebungen. Der Geschäftsführer sagte danach, er habe seit zwanzig Jahren gewusst, dass man Projekte nicht mit Leuten rettet, und es trotzdem jedes Mal versucht. Das ist die ehrlichste Zusammenfassung von Brooks' Gesetz, die ich kenne. Ich habe das Buch Geschäftsführern gegeben, die mit Software nichts zu tun haben, und die Rückmeldung war fast immer dieselbe: Sie haben beim Lesen an ein eigenes Projekt gedacht, meist an das, das gerade läuft. Das ist der Wert von Brooks: Er erklärt nicht, warum Software schwierig ist. Er erklärt, warum Zusammenarbeit es ist. Wenn dein Projekt gerade zu spät ist und du kurz davor stehst, Leute nachzuschieben, ist meine Teamentwicklung der Ort, an dem wir vorher die Kommunikationswege zählen und die Struktur bauen, die die Verstärkung tragen könnte, falls sie überhaupt nötig ist. Menschen sind nicht addierbar. Nur ihre Abstimmungen sind es, und die kosten Zeit.