Projekte doppelt so schnell umsetzen: ein ganz einfacher Trick! Oder warum die ideale Teamgröße möglicherweise unter 10 liegt.

Wenn Zeitrahmen und Umfang feststehen, gelangen klassische Projekte häufig an den Punkt, an dem festgestellt wird, dass sich der Termin unter den gegebenen Bedingungen nicht halten lässt. Ursachen sind vielfältig und liegen häufig in geänderten Anforderungen, geänderten Rahmenbedinungen etc. Nun wird häufig folgendes versucht: in dem die Kapazität (Teamgröße) gesteigert wird, soll der zusätzliche Umfang dennoch bis zum gewünschten Termin bewältigt werden. Die Lösung liegt demnach darin, mehr Kapazität heranzuschaffen. Doch funktioniert dieses Modell in der Realität?

Mehr Kapazität fürs Projekt

Aus der Erfahrung lässt sich diese Frage tendenziell mit Skepsis beantworten. Ich möchte der Sache auf den Grund gehen, welche Annahmen für die Geschwindigkeit der Umsetzung eines Projekts getroffen werden können und wie sich die Deadline halten lässt.

Die Geschwindigkeit in Abhängigkeit von der Teamgröße

Lineare Entwicklung der Teamgeschwindikeit

Hinter der Steigerung der Projektteamgröße steckt die Annahme, dass sich die Geschwindigkeit des Teams linear mit der Anzahl der Personen steigert (Beispiel: drei Personen schaffen drei Arbeitseinheiten pro Zeit, vier schaffen vier). Diese Annahme berücksichtigt einen sehr wichtigen Punkt nicht: den Abstimmungsaufwand. Nun lässt sich das Modell etwas exakter gestalten, in dem der insgesamt Aufwand für Abstimmungen im Team abgezogen wird. D.h. die Geschwindigkeit wird um den prozentualen Abstimmungsaufwand verringert (Beispiel: drei Personen verbringen zusammen 10% ihrer Zeit in Meetings, demnach werden 10% von der Geschwindigkeit abgezogen. Dass kann beispielsweise ein wöchentliches Teammeeting sein).

Lineare Entwicklung der Geschwindkeit abzüglich Abstimmung

Ist diese Annahme besser? Demnach entwickelt sich die Leistungsfähigkeit eines Projektteams linear und ist durch teamweite Aufwände verringert. Allerdings wird ein sehr wichtiger Punkt weiterhin nicht berücksichtigt.

Abstimmung zwischen den einzelnen Projektteam-Mitgliedern

In einem Projektteam ist davon auszugehen, dass
a) das Wissen im Team verteilt ist und
b) Aufgaben dynamisch zugeordnet werden (insbesondere in agilen Teams)

Um eine Tätigkeit erfolgreich auszuführen zu können, muss deshalb eine Abstimmung mit allen Wissensträgern stattfinden (z.b. Productowner, Requirementsengineer, Frontend, Backend, Architekt, Entwickler des ersten Funktionsreleases, …). Auf einer Teamebene ist eine solche Abstimmung nicht effizient, da die Informationen einzelne Teilnehmer betreffen. Der Wissenstransfer wird in Folge bilateral stattfinden (teilweise auch in kleinen Gruppen, der Annahme halber wird dieses jedoch vernachlässigt). Die Schlussfolgerung: es müssen 1:1-Abstimmungen im gesamten Team als Aufwand berücksichtigt werden.

Abstimmungswege im Projekt

Die Anzahl der erforderlichen Kommunikationswege lässt sich einfach ermitteln. Als Beispiel betrachten wir ein Team von drei Personen: die erste Person muss mit zwei weiteren Personen sprechen, die zweite Person nur noch mit einer weiteren Person, dann haben sich alle im Team abgestimmt. Bei vier Personen muss sich die erste Person mit drei weiteren Abstimmen, die zweite mit zwei weiteren, usw. Das lässt sich ganz einfach berechnen.

Berechnung der Anzahl der Abstimmungswege

Diese Zahlenfolge ist durch den jungen Schüler Carl Friedich Gauß bekannt geworden. Er hat die Strafaufgabe, alle Zahlen zwischen eins und 100 zu addieren, ganz schnell gelöst: als Ergebnis hat er 50 Paare mit der Summe 101 gebildet (1+100, 2+99, …) und multipliziert.

Jetzt werden wir diesen „Intrateam“-Kommunikationsaufwand mit einem gewissen Prozentsatz ap von der Leistung eines Projektteams abziehen.

Berechnung der Geschwindigkeit in Berücksichtigung der Intra-Team-Abstimmung

Nicht lineare Entwicklung der Geschwindigkeit

Nun haben wir eine Formel, die uns sagt, welche Geschwindigkeit ein Team von Größe p mit Gesamtabstimmungsaufwand a0 und einem Intra-Team-Abstimmungsaufwand von ap erreichen kann. Es zeigt sich dass sich unter diesen Annahmen eine maximale Teamgröße und damit maximale Geschwindigkeit ergibt (grün), die nicht überschritten werden kann.

Einige wichtige Überlegungen: Zunächst nimmt das Modell an, dass sich Jeder mit Jedem abstimmt. Das ist eine eher pessimistische Annahme. Bei festeren Rollenaufteilungen wird sich die Anzahl der Kommunikationswege reduzieren. Außerdem wird unter sonst gegebenen Bedingungen (Druck durch Projektzeitrahmen und Umfang) die Geschwindigkeit höher sein und dieser Effekt weniger intensiv zum Tragen kommen – denn es wird weniger Kommunikation als gewünscht stattfinden. Die Folgen der fehlenden Kommunikation sind sinkende Qualität (Fehler, Geringere Schlüssigkeit der Lösung, Schlechtere Performance) und steigender Aufwand (da Aufgaben mehrfach oder nicht ideal gelöst werden). Wir gehen folglich in den Überlegungen von einem idealtypischen Bild aus.


Stagnation der Geschwindigkeit mit zunehmender Teamgröße

Nun werden wir einen Beispielfall betrachten um den Effekt zu verstehen. Dazu treffen wir eine Annahme für den Intra-Team-Kommunikationsaufwand – nach einem ersten Bauchgefühl werden wir ihn auf 10% setzen. Überlegung hierzu: wenn die Aufgaben stark fragmentiert sind und im Team die Aufgaben tauschen, ist er hoch (Scrum), wenn es klare Zuständigkeiten und kaum Abhängigkeiten gibt, eher niedrig (Support). Berechnen wir mit dieser Annahme die Geschwindigkeit zunächst für die Teamgröße von fünf:


Wir erhalten eine Performance von 3,25 FTE (Full-Time-Equivalent). Jetzt stellen wir diese Berechnung für verschiedene Teamgrößen zwischen Null und 9 Personen an.

Maximale Geschwindigkeit im Beispielfall

Es zeigt sich, dass bei einer angenommen erforderlichen Intra-Team Kommunikation von 10% die Geschwindigkeit ab ca. 6 Personen nur noch marginal steigt und bei ca. 9 Personen ein Maximum von 4,05 FTE erreicht.

Schlussfolgerung: die Steigerung der Kapazität über einen gewissen Grad hinaus ist unter diesen Annahmen nicht kontinuierlich möglich. Begrenzt wird die Geschwindigkeit durch den 1:1 Kommunikationsaufwand. Nur komplett unabhängigen Aufgaben (so dass keine Kommunikation mehr erforderlich ist) lassen sich beliebig skalieren, abhängige Aufgaben nicht in dieser Form. An welchen Stellen exakt diese Grenzen liegen, hängt selbstverständlich von der Stärke des Effekts und dem prozentual notwendigen Aufwand ab.

Zeitliche Entwicklung der Geschwindigkeit

Bei Änderungen der Projektteamgröße im Projektverlauf ist neben diesem Effekt auch die Einlernzeit zu bedenken.

Zeitliche Entwicklung bei Einlernzeit

Ein neuer Projektteilnehmer senkt zunächst die Kapazität, da wenig Beitrag geleistet wird und „Teamzeit“ für die Einführung benötigt wird. Wenn das Projektteam um einige Teilnehmer erweitert wird, könnte folgender Effekt auf die zur Verfügung stehende Produktivität beobachtet werden.

Phasen beim Erweitern des Projektteams

Zunächst verringert sich die Geschwindigkeit des Teams. Hierfür ist der zusätzliche Aufwand für das Einlernen neuer Teammitglieder verantwortlich. In dieser Phase werden demnach weniger Aufgaben abgeschlossen. Im Anschluss – nachdem das erweiterte Team eingespielt ist – wird weitere Zeit benötigt, um diesen Rückstand zunächst aufzuarbeiten. Je nach dem in welchem Verhältnis Aufwand und benötigte Zeit für das Einlernen und die zusätzliche Leistung durch das größere Team stehen, wird die neutrale Phase (in der kein Mehrwert geschaffen wird) länger als die Einlernzeit ausfallen. Dieser Effekt wird häufig unterschätzt.

Die Projektgeschwindigkeit erhöhen

Doch wie kann ein Projekt schneller umgesetzt werden? Wie sich zeigt, lässt sich die Geschwindigkeit nicht beliebig durch das Erhöhen der Teamgröße beschleunigen. Viel mehr begrenzt der notwendige Abstimmungsaufwand zwischen den Teammitgliedern die Skalierbarkeit. Eine mögliche Optimierung ist es, bis zur ideale Größe zu skalieren, wenn diese noch nicht erreicht ist. Tasks sollten außerdem „schlau“ aufgeteilt werden, um dem Effekt der notwendigen Kommunikation entgegenzuwirken.

Doch nun zum „ganz einfachen Trick“: um ein Projekt in der doppelten Geschwindigkeit abzuschließen, ist es die beste Alternative, den Projektumfang auf die wesentlichen Faktoren zu reduzieren. Doch dieses Vorgehen ist häufig schwierig umzusetzen. Auf „Evolution statt Revolution“ zu setzen kann ein zielführender Weg sein, wenn die Rahmenbedingungen es zulassen. Die Entwicklung entlang von real abgerufenen Anforderungen minimiert die falsche Investition von Kapazitäten.

Was sind Eure Erfahrungen zur Beschleunigung von Projekten?

3 Gedanken zu “Projekte doppelt so schnell umsetzen: ein ganz einfacher Trick! Oder warum die ideale Teamgröße möglicherweise unter 10 liegt.

  1. Danke für diese verständliche und eindrückliche Darstellung eines „bekannten Problems“!

    Allerdings ist meiner Ansicht nach noch ein zusätzlicher Faktor zu berücksichtigen bei der Teamgrösse: die Kompetenzen.

    Wenn wir ein reelles Projekt anschauen, dann haben wir ja nicht von Start bis Ende permanent eine Teamgrösse von z.B. 10 „aktiven“ Mitarbeitern. Sondern es gibt nebst dem PL – als fast einziges, dauerhaftes Element im Projekt – je nach Projektphase und dazugehörigen Arbeitspaketen unterschiedliche Personen, welche eine Arbeitsleistung erbringen müssen.

    Die von dir aufbereitete Kalkulation kommt sicher dann zum Einsatz, wenn man innerhalb einer Projektphase die Teamgrösse einer einzelnen Kompetenz steigern will. Beispiel: für die Fertigstellung eines Konzeptes 10 anstatt 3 Consultants einzusetzen.

  2. Ich stimme dir absolut zu! Danke für diese wichtige Ergänzung. Das oben aufgeführte Modell ist auf die Beziehungen in einer homogenen Gruppe reduziert.
    Das Modell unter der Berücksichtigung von Kommunikation verschiedener Teams untereinander (Projektmanagement, Fachbereich, Umsetzung etc. ) und der Teamentwicklung in verschiedenen Bereichen weiterzudenken, ist wichtig um eine reelle Annahme zu erhalten.

  3. Ein sehr schöner Artikel! Wie weiter oben schon erwähnt ist dieses Problem bekannt, aber ich finde den Artikel sehr angenehm zu lesen, da dieser die Problematik auf das wesentliche herunterbricht. Klar kann man jetzt noch 100 Variablen einfügen, die dann jeden einzelnen Fall betrachten, aber das würde die eigendliche Aussage verwischen.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*

*

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>