Eine Person oder ein Team? So bestimmen Sie die minimale Projektbesetzung anhand von Kompetenzen, Abhängigkeiten und Risiken

Die Forschung stützt keine einfache Regel wie "kleinere Teams sind immer besser" oder "größere Teams leisten immer mehr".

Eine Meta-Analyse aus dem Jahr 2023 mit 208 unabhängigen Effekten und 21.435 Teams fand insgesamt praktisch keinen Zusammenhang zwischen Teamgröße und Aufgabenleistung, zugleich aber große Unterschiede je nach Kontext. Die Autoren zeigen, dass die Bedeutung der Teamgröße unter anderem von Aufgabenkomplexität und Koordinationsbedarf abhängt. [4]

Auch ein Experiment mit einer komplexen Krisenkartierungsaufgabe zeigte zugleich Vorteile und Kosten größerer Teams: Mit der Teamgröße nahm die Zusammenarbeit zu, während sich das individuelle Einsatzverhalten veränderte. In diesem konkreten Experiment schnitten die größten Teams besser ab als eine entsprechende Zahl unabhängig arbeitender Personen. Das ist jedoch keine allgemeingültige Empfehlung für jede Art von Arbeit. [5]

Die praktische Schlussfolgerung ist einfach: Die Personenzahl sollte aus der Art der Arbeit folgen, nicht aus einer magischen Zahl.

Der Scrum Guide von 2020 beschreibt ein Scrum Team als klein, funktionsübergreifend und selbstverwaltend. Er sagt außerdem, dass ein solches Team typischerweise 10 oder weniger Personen umfasst. [3]

Das ist eine nützliche Orientierung im Kontext von Scrum, aber kein universelles Gesetz für jedes Projekt, jede Dienstleistung, jede Branche und jedes Liefermodell.

Ein Bauprojekt, eine Marketingkampagne, eine Sicherheitsprüfung, ein Finanzsystem und eine kleine Informationsseite haben völlig unterschiedliche Anforderungen. Eine einzelne Zahl sollte nicht direkt zwischen diesen Situationen übertragen werden.

Der britische Service Standard verlangt, dass Teams für digitale Dienste multidisziplinär sind und Zugang zu einer angemessenen Bandbreite an Kompetenzen haben. Zugleich soll sich das Team danach richten, was es in der jeweiligen Phase erreichen muss. [1]

Eine weitere GOV.UK-Leitlinie hält fest, dass sich Teamgröße und benötigte Rollen in den verschiedenen Phasen des Aufbaus eines Dienstes verändern. [2]

Daraus folgt eine praktische Regel:

Zuerst Arbeit und Verantwortung abbilden, dann Kompetenzen bestimmen und erst danach konkrete Personen zuordnen.

Ein Team lässt sich nicht sinnvoll für einen unklaren Umfang planen.

Halten Sie mindestens fest:

• welches Ergebnis entstehen soll,
• was zum Umfang gehört,
• was nicht zum Umfang gehört,
• welche Qualitätsanforderungen besonders wichtig sind,
• welche Zeit- und Budgetgrenzen bestehen,
• wer das Ergebnis abnimmt,
• ob das Team nur liefert oder die Lösung auch betreiben soll.

Ein Projekt "eine Anwendung bauen" und ein Projekt "eine Anwendung entwerfen, bauen, absichern, bereitstellen und ein Jahr betreiben" benötigen völlig unterschiedliche Arbeitsabdeckung.

Statt sofort Stellenbezeichnungen einzutragen, listen Sie die Arten von Arbeit auf, die tatsächlich erledigt werden müssen.

Bei einem digitalen Dienst könnten das zum Beispiel sein:

• Nutzerbedürfnisse verstehen,
• die Lösung gestalten,
• die für Nutzer sichtbare Schicht umsetzen,
• serverseitige Logik und Integrationen umsetzen,
• testen,
• Sicherheit,
• Barrierefreiheit,
• Bereitstellung und Betrieb,
• Umfang und Entscheidungen koordinieren.

Bei einer anderen Projektart wird die Liste anders aussehen.

GOV.UK weist darauf hin, dass ein Team, das einen digitalen Dienst aufbaut und betreibt, ein breites Kompetenzspektrum benötigt, darunter Nutzerbedürfnisse, Gestaltung, Umsetzung, Tests, Sicherheit, Bereitstellung und laufender Betrieb. [2]

Nicht jede benötigte Kompetenz erfordert eine Vollzeitperson im Team.

Ordnen Sie jeden Bereich ein:

Dauerhaft - regelmäßig nötig und direkt an täglichen Entscheidungen beteiligt.
Zeitweise - in bestimmten Phasen oder Kontrollpunkten nötig.
Extern verfügbar - kann von einer anderen Person oder einem anderen Team bereitgestellt werden, wenn Reaktionszeit und Verantwortlichkeit ausreichend klar sind.

GOV.UK erlaubt ausdrücklich, dass Spezialwissen für ein Team verfügbar ist, auch wenn der Spezialist kein dauerhaftes Teammitglied ist. [1]

So lässt sich eine künstliche Vergrößerung des Teams oft vermeiden, ohne wichtige Expertise zu verlieren.

Zwei Personen können zusammen alle benötigten Kompetenzen besitzen und dennoch eine schlechte Besetzung bilden, wenn die gesamte Arbeit in einer engen Kette von Abhängigkeiten liegt.

Prüfen Sie:

• welche Aufgaben parallel laufen können,
• welche auf andere warten müssen,
• wer Entscheidungen trifft, die spätere Arbeit blockieren,
• von welchen externen Teams oder Lieferanten das Projekt abhängt,
• wo die Abwesenheit einer Person mehrere Bereiche gleichzeitig stoppen würde.

GOV.UK nennt das Management von Abhängigkeiten zu anderen Teams als eine der nötigen Fähigkeiten beim Aufbau digitaler Dienste. [2]

Arbeiten mehrere Teams an einem Dienst, entsteht zusätzlicher Bedarf, Pläne und Fortschritt zwischen den Teams zu koordinieren. [8]

Manche notwendige Expertise ist auf einer Funktionsliste des Produkts nicht sichtbar, doch ihr Fehlen kann teuer werden.

Je nach Projekt kann es unter anderem gehen um:

• Sicherheit,
• Datenschutz,
• Barrierefreiheit,
• rechtliche oder branchenspezifische Anforderungen,
• Zuverlässigkeit,
• Datenmigration,
• Integrationen mit kritischen Systemen,
• Technologien, die das Team bisher nicht eingesetzt hat.

GOV.UK empfiehlt den Zugang zu Spezialwissen, wenn ein Projekt es benötigt, und sagt, dass die Zusammensetzung auch die riskantesten Annahmen der jeweiligen Phase widerspiegeln sollte. [1]

Das bedeutet nicht automatisch eine eigene Vollzeitstelle für jedes Risiko. Es bedeutet aber, dass eine kompetente Person eine klare Verantwortung und echten Einfluss auf Entscheidungen haben muss.

Eine Person kann Gestaltung, Entwicklung, Tests und Bereitstellung beherrschen. Das bedeutet nicht, dass sie all diese Arbeiten gleichzeitig unter beliebigem Termindruck leisten kann.

PMI-Material zur Ressourcenplanung betont die Bedeutung, Kompetenzen, Verfügbarkeit, Kosten und Erfahrung mit den Projektanforderungen abzugleichen. [7]

Prüfen Sie für jede Person:

• wie viel Zeit sie tatsächlich einbringen kann,
• welche Aufgaben um ihre Aufmerksamkeit konkurrieren,
• ob erforderliche Arbeiten parallel stattfinden müssen,
• ob der Termin unrealistische Wechsel zwischen vielen Arbeitsarten voraussetzt,
• ob nach dem Start weiterhin jemand die Lösung betreiben muss.

Kompetenzabdeckung ohne Zeitabdeckung ist keine vollständige Projektabdeckung.

Eine minimale Besetzung sollte auch Kontinuität berücksichtigen.

Fragen Sie:

• was passiert, wenn eine Schlüsselperson nicht verfügbar ist,
• ob nur eine Person einen kritischen Teil der Lösung versteht,
• ob Entscheidungen und Wissen dokumentiert sind,
• ob jemand anderes die wichtigsten Aufgaben übernehmen kann,
• ob das Projekt während einer Abwesenheit sicher pausieren kann.

Nicht jedes kleine Projekt braucht vollständige Redundanz. Bei einem kurzen Projekt mit geringem Risiko kann die bewusste Akzeptanz dieses Risikos sinnvoll sein.

Bei einem kritischen Projekt kann dieselbe Abhängigkeit von einer Person unvertretbar sein.

Ein Projekt braucht nicht für jede Rollenbezeichnung eine separate Person.

Hat eine Person die nötigen Kompetenzen wirklich, verfügt über genügend Kapazität und erzeugt kein unvertretbares Risiko, kann sie mehrere Bereiche verantwortungsvoll abdecken.

In einem kleinen Projekt kann eine Person beispielsweise Schnittstellengestaltung und Umsetzung verbinden. In einem anderen Projekt kann eine Person Geschäftsanalyse und Umfangskoordination kombinieren.

Verantwortungen sollten nicht nur deshalb zusammengelegt werden, weil "es jemand machen muss". Die Kombination ist erst sinnvoll, wenn die Person beide Verantwortungen auf dem erforderlichen Niveau erfüllen kann und dafür genug Zeit hat.

Eine Person kann eine vernünftige Besetzung sein, wenn gleichzeitig gilt:

• der Umfang ist klein und gut definiert,
• die nötigen Kompetenzen liegen tatsächlich in ihren Fähigkeiten,
• die Aufgaben erfordern wenig parallele Arbeit,
• externe Abhängigkeiten sind begrenzt,
• das Risiko ist akzeptabel,
• der Termin passt zur realen Kapazität,
• fehlende Vertretung wird bewusst akzeptiert.

Beispiele können ein kleines Informationsmaterial, eine einfache Analyse, eine einmalige Beratung oder eine begrenzte Umsetzung in einer vertrauten Umgebung sein.

Entscheidend bleibt der konkrete Umfang. Die Bezeichnung "kleines Projekt" entscheidet die Frage nicht von selbst.

Ein Team wird eher notwendig, wenn mehrere dieser Bedingungen vorliegen:

• die nötigen Kompetenzen sind für eine Person zu breit,
• viele Arbeiten müssen parallel laufen,
• der Termin ist kürzer als eine realistische sequentielle Umsetzung,
• das Projekt hat viele Abhängigkeiten und Schnittstellen,
• Risiken erfordern unabhängiges Spezialwissen,
• die Lösung muss gleichzeitig gebaut und betrieben werden,
• eine Person würde zum kritischen Punkt des gesamten Projekts,
• die Verantwortung umfasst mehrere klar unterschiedliche Fachgebiete.

Unter solchen Bedingungen ist das Ergänzen fehlender Kompetenzen wichtiger als das bloße Erhöhen der Personenzahl.

Mehr Personen vergrößern den verfügbaren Wissenspool und die mögliche Kapazität, können aber zugleich Abhängigkeiten, Übergaben und Abstimmungsbedarf erhöhen.

Eine im Journal of Systems and Software veröffentlichte Untersuchung von Softwareprojekten zeigte, dass die Beziehungen zwischen Teamgröße, Produktivität, Aufwand und Zeit komplex sind und intuitive Erwartungen nicht immer bestätigen. [6]

Auch die Meta-Analyse zur Teamgröße zeigt, dass Ergebnisse vom Aufgabenkontext und den Kosten von Teamprozessen abhängen. [4]

Die Frage lautet daher nicht "wie viele Personen können wir hinzufügen?", sondern "beseitigt die nächste Person eine reale Projektbeschränkung stärker, als sie Koordinationsaufwand erzeugt?"

Nicht jede wichtige Kompetenz muss täglich im Team präsent sein.

Dauerhafte Präsenz ist sinnvoller, wenn die Person regelmäßig Entscheidungen trifft, ihre Arbeit viele Abhängigkeiten zu anderen Bereichen hat oder schnelle Reaktion wichtig ist.

Zeitweise Unterstützung kann ausreichen, wenn Expertise an bestimmten Punkten benötigt wird, etwa für Prüfung, Beratung, Risikobewertung oder fachliche Abnahme.

Eine Bedingung gilt: Verfügbarkeit darf nicht nur auf dem Papier bestehen. Es muss klar sein:

• wer verantwortlich ist,
• wann die Person verfügbar ist,
• welche Reaktionszeit erwartet wird,
• welche Entscheidungen sie treffen darf,
• was passiert, wenn sie ein Problem findet.

Zugang zu einer Fachperson ohne definierte Verantwortung kann auf einem Organigramm gut aussehen und im echten Projekt trotzdem nicht funktionieren.

Nehmen wir an, das Ziel ist ein Online-Buchungssystem.

Variante A: einfacher Prototyp zum Testen der Idee
Der Umfang ist begrenzt, es gibt keine Zahlungen oder besonders sensiblen Daten, und das Ziel ist, den Ablauf mit einer kleinen Nutzergruppe zu testen. Eine vielseitige Person könnte Gestaltung und Umsetzung abdecken, bei Bedarf ergänzt durch zeitweise Beratung.

Variante B: öffentlicher Dienst mit Konten, Zahlungen und Integrationen
Mehr Spezialisierung, Tests, Risiken, Abhängigkeiten und parallele Arbeiten kommen hinzu. Ein Team aus mehreren Personen ist deutlich besser begründet.

Variante C: dauerhaft laufender Dienst mit schneller Störungsreaktion
Zur Entwicklung kommen Betrieb, Überwachung, Reaktion auf Störungen und Wissenskontinuität hinzu. Die Besetzung für den Start reicht möglicherweise nicht für einen nachhaltigen Betrieb.

Es handelt sich um denselben allgemeinen Produkttyp, aber unterschiedlicher Umfang, Risiko und Betriebsmodell erzeugen unterschiedliche Teambedürfnisse.

1. Sie beginnen mit einer fertigen Liste von Stellenbezeichnungen statt mit der zu erledigenden Arbeit.

2. Sie nehmen an, dass jede Rolle eine eigene Person braucht.

3. Sie betrachten nur Kompetenzen und ignorieren verfügbare Zeit.

4. Sie fügen Personen hinzu, ohne Abhängigkeiten und Engpässe zu beseitigen.

5. Sie übersehen risikobedingte Kompetenzen, weil daraus keine sichtbare Produktfunktion entsteht.

6. Sie machen mehrere kritische Bereiche von einer Person abhängig, ohne das Risiko bewusst zu akzeptieren.

7. Sie behandeln die Startbesetzung als unveränderlich bis zum Projektende.

GOV.UK sagt ausdrücklich, dass sich Teamgröße und Rollen in den verschiedenen Phasen der Serviceentwicklung verändern. [2]

Das ist auch außerhalb öffentlicher Dienste eine sinnvolle Regel:

• am Anfang können mehr Forschung und Problemklärung nötig sein,
• während der Umsetzung gewinnen Umsetzung und Tests an Bedeutung,
• vor dem Start können Sicherheit, Qualität und Betriebsbereitschaft mehr Aufmerksamkeit verlangen,
• nach dem Start verschiebt sich das Verhältnis zwischen Weiterentwicklung und Betrieb.

Die minimale Besetzung ist eine Eigenschaft von Phase und Umfang, keine dauerhaft festgeschriebene Zahl.

Halten Sie für jeden wichtigen Bereich fünf Dinge fest:

Arbeitsbereich - was muss erledigt werden?
Kompetenz - welches Wissen und welche Fähigkeit werden benötigt?
Verantwortung - wer entscheidet und trägt die Ergebnisverantwortung?
Verfügbarkeit - ist die Kompetenz dauerhaft, zeitweise oder extern?
Risiko des Fehlens - was passiert, wenn die Kompetenz fehlt oder die Person nicht verfügbar ist?

Ordnen Sie erst danach konkrete Personen zu.

Deckt eine Person mehrere Zeilen ab, prüfen Sie Zeit und Abhängigkeiten. Braucht eine Zeile mehrere Personen, prüfen Sie, ob Kapazität, unabhängige Kontrolle oder parallele Arbeit der Grund ist.

1. Hat jeder verpflichtende Arbeitsbereich einen Verantwortlichen?
2. Hat jede kritische Verantwortung eine Person mit der passenden Kompetenz?
3. Deckt jemand mehrere Rollen ab und hat realistisch genug Zeit dafür?
4. Erfordert das Projekt parallele Arbeit, die die aktuelle Besetzung nicht leisten kann?
5. Kennen wir die wichtigsten Abhängigkeiten zu anderen Personen, Teams und Lieferanten?
6. Haben wesentliche Risiken Zugang zur richtigen Spezialexpertise?
7. Kann die Abwesenheit einer Person das ganze Projekt stoppen?
8. Reicht die Besetzung nicht nur für die Umsetzung, sondern auch für Start und Betrieb, falls diese zum Umfang gehören?
9. Wissen wir, welche Kompetenzen zeitweise statt dauerhaft verfügbar sein können?
10. Gibt es Zeitpunkte, an denen die Besetzung nach Änderungen von Umfang oder Phase neu bewertet wird?

Teamplanung sollte nicht mit der Frage beginnen:

"Wie viele Personen braucht man normalerweise für ein solches Projekt?"

Die bessere Reihenfolge lautet:

Ergebnis -> Arbeit -> Kompetenzen -> Abhängigkeiten -> Risiko -> Kapazität -> Personen.

Wenn eine Person nach dieser Prüfung tatsächlich alles abdeckt, kann eine Person die richtige Wahl sein.

Fehlen Kompetenzen, Zeit, unabhängige Prüfung, Kontinuität oder Möglichkeiten für parallele Arbeit, benötigen Sie zusätzliche Personen oder verlässlichen Zugang zu Spezialisten.

Ziel ist nicht das kleinste Team. Ziel ist die kleinste Besetzung, die das geforderte Ergebnis realistisch auf dem erforderlichen Risiko- und Qualitätsniveau liefern kann.

[1] GOV.UK Service Standard - Have a multidisciplinary team
Quelle öffnen

[2] GOV.UK Service Manual - Set up a service team at each phase
Quelle öffnen

[3] The Scrum Guide, 2020 - Scrum Team
Quelle öffnen

[4] Bernerth, Beus, Helmuth, Boyd - The more the merrier or too many cooks spoil the pot? A meta-analytic examination of team size and team effectiveness, Journal of Organizational Behavior, 2023
Quelle öffnen

[5] Mao, Mason, Suri, Watts - An Experimental Study of Team Size and Performance on a Complex Task, PLOS ONE, 2016
Quelle öffnen

[6] Rodríguez, Sicilia, García, Harrison - Empirical findings on team size and productivity in software development, Journal of Systems and Software, 2012
Quelle öffnen

[7] Project Management Institute - Solving The Resource Puzzle
Quelle öffnen

[8] GOV.UK Service Manual - Running more than one service team
Quelle öffnen

Methodischer Hinweis: Einige Quellen betreffen digitale öffentliche Dienste, andere Scrum Teams, Projektmanagement oder Forschung zu Teams und Softwareentwicklung. Dieser Leitfaden nutzt jede Quelle nur für die Aussagen, die sie unterstützt. Die sieben Schritte zur Bestimmung einer minimalen Besetzung sind eine redaktionelle Synthese dieser Prinzipien und kein formaler Standard der genannten Organisationen.