Eén persoon of een team? Zo bepaal je de minimale projectbezetting op basis van vaardigheden, afhankelijkheden en risico

Onderzoek ondersteunt geen simpele regel zoals "kleinere teams zijn altijd beter" of "grotere teams leveren altijd meer".

Een meta-analyse uit 2023 met 208 onafhankelijke effecten en 21.435 teams vond in het algemeen vrijwel geen verband tussen teamgrootte en taakprestatie, maar wel grote verschillen per context. De auteurs laten zien dat het belang van teamgrootte onder meer verandert met taakcomplexiteit en coördinatiebehoefte. [4]

Een experiment met een complexe crisiskaarttaak liet eveneens zowel voordelen als kosten van grotere teams zien: samenwerking nam toe met teamgrootte, terwijl patronen van individuele inzet veranderden. In dat specifieke experiment presteerden de grootste teams beter dan een gelijk aantal zelfstandig werkende personen. Dat is geen universeel recept voor ieder soort werk. [5]

De praktische conclusie is eenvoudig: het aantal mensen moet volgen uit de aard van het werk, niet uit een magisch getal.

De Scrum Guide van 2020 beschrijft een Scrum Team als klein, multidisciplinair en zelfsturend. Ook staat er dat zo'n team doorgaans 10 mensen of minder telt. [3]

Dat is nuttige richtlijn binnen Scrum, maar geen universele wet voor ieder project, iedere dienst, sector of uitvoeringsvorm.

Een bouwproject, marketingcampagne, beveiligingsbeoordeling, financieel systeem en kleine informatieve website hebben heel verschillende behoeften. Eén getal moet niet rechtstreeks tussen zulke situaties worden overgenomen.

De Britse Service Standard vereist dat teams voor digitale diensten multidisciplinair zijn en toegang hebben tot een passende mix van vaardigheden. Ook moet de samenstelling passen bij wat het team in de betreffende fase moet bereiken. [1]

Aanvullende GOV.UK-richtlijnen geven aan dat teamgrootte en benodigde rollen veranderen tijdens de verschillende fasen van een dienst. [2]

Daaruit volgt een praktische regel:

breng eerst werk en verantwoordelijkheden in kaart, bepaal daarna de vaardigheden en koppel pas daarna concrete personen.

Je kunt een team niet goed dimensioneren bij een onduidelijke scope.

Leg minimaal vast:

• welk resultaat moet ontstaan,
• wat binnen de scope valt,
• wat buiten de scope valt,
• welke kwaliteitseisen het belangrijkst zijn,
• welke tijd- en budgetbeperkingen gelden,
• wie het resultaat accepteert,
• of het team alleen oplevert of de oplossing ook moet beheren.

Een project "een applicatie bouwen" en een project "een applicatie ontwerpen, bouwen, beveiligen, uitrollen en een jaar beheren" vereisen een heel andere dekking van werkzaamheden.

In plaats van meteen functietitels toe te wijzen, noteer je eerst welke soorten werk echt moeten gebeuren.

Voor een digitale dienst kan dat bijvoorbeeld zijn:

• gebruikersbehoeften begrijpen,
• de oplossing ontwerpen,
• de zichtbare gebruikerslaag bouwen,
• serverlogica en integraties bouwen,
• testen,
• beveiliging,
• toegankelijkheid,
• uitrol en beheer,
• scope en beslissingen coördineren.

Bij een ander projecttype ziet de lijst er anders uit.

GOV.UK geeft aan dat een team dat een digitale dienst bouwt en beheert een brede set vaardigheden nodig heeft, waaronder gebruikersbehoeften, ontwerp, bouw, testen, beveiliging, uitrol en live beheer. [2]

Niet iedere benodigde vaardigheid vraagt om een fulltime persoon in het team.

Classificeer per gebied:

Permanent - regelmatig nodig en direct van invloed op dagelijkse beslissingen.
Periodiek - nodig in specifieke fasen of controlepunten.
Extern beschikbaar - kan door een andere persoon of een ander team worden geleverd als reactietijd en verantwoordelijkheid voldoende duidelijk zijn.

GOV.UK staat expliciet toe dat specialistische expertise beschikbaar is voor een team zonder dat de specialist een permanent teamlid hoeft te zijn. [1]

Zo voorkom je vaak dat het team kunstmatig groter wordt zonder belangrijke expertise te verliezen.

Twee mensen kunnen samen alle benodigde vaardigheden bezitten en toch een slechte bezetting vormen als al het werk in één smalle afhankelijkheidsketen zit.

Controleer:

• welke taken parallel kunnen verlopen,
• welke op andere moeten wachten,
• wie beslissingen neemt die later werk blokkeren,
• van welke externe teams of leveranciers het project afhankelijk is,
• waar afwezigheid van één persoon meerdere gebieden tegelijk stillegt.

GOV.UK noemt het beheren van afhankelijkheden met andere teams als een van de benodigde capaciteiten bij het bouwen van digitale diensten. [2]

Als meerdere teams aan een dienst werken, ontstaat daarnaast extra behoefte om plannen en voortgang tussen teams te coördineren. [8]

Sommige noodzakelijke expertise zie je niet terug in een lijst met productfuncties, maar het ontbreken ervan kan kostbaar zijn.

Afhankelijk van het project kan het gaan om:

• beveiliging,
• gegevensbescherming,
• toegankelijkheid,
• juridische of sectorspecifieke eisen,
• betrouwbaarheid,
• gegevensmigratie,
• integraties met kritieke systemen,
• technologie die het team nog niet eerder gebruikte.

GOV.UK adviseert toegang tot specialistische expertise wanneer het project die nodig heeft en stelt dat teamsamenstelling ook de risicovolste aannames van de huidige fase moet weerspiegelen. [1]

Dat betekent niet automatisch een aparte fulltime functie voor ieder risico. Het betekent wel dat iemand met de juiste expertise expliciete verantwoordelijkheid en echte invloed op beslissingen moet hebben.

Eén persoon kan ontwerp, ontwikkeling, testen en uitrol beheersen. Dat betekent niet dat die persoon al die soorten werk tegelijk binnen iedere deadline kan uitvoeren.

PMI-materiaal over capaciteitsplanning benadrukt het afstemmen van vaardigheden, beschikbaarheid, kosten en ervaring op projectbehoeften. [7]

Controleer per persoon:

• hoeveel tijd werkelijk beschikbaar is,
• welke taken om aandacht concurreren,
• of werk parallel moet verlopen,
• of de planning onrealistisch veel wisselen tussen soorten werk veronderstelt,
• of iemand na de lancering de oplossing moet blijven beheren.

Vaardigheden afdekken zonder tijd af te dekken is geen volledige projectdekking.

Een minimale bezetting moet ook rekening houden met continuïteit.

Vraag:

• wat gebeurt er als een sleutelpersoon niet beschikbaar is,
• of slechts één persoon een kritisch onderdeel begrijpt,
• of beslissingen en kennis zijn vastgelegd,
• of iemand anders de belangrijkste taken kan overnemen,
• of het project veilig kan pauzeren tijdens afwezigheid.

Niet ieder klein project heeft volledige vervangbaarheid nodig. Bij een kort project met laag risico kan het bewust accepteren van dit risico redelijk zijn.

Bij een kritisch project kan dezelfde afhankelijkheid van één persoon onaanvaardbaar zijn.

Een project heeft niet voor iedere rolnaam een aparte persoon nodig.

Als één persoon echt de benodigde vaardigheden bezit, voldoende capaciteit heeft en geen onaanvaardbaar risico veroorzaakt, kan die persoon meerdere gebieden verantwoord afdekken.

In een klein project kan één persoon bijvoorbeeld interfaceontwerp combineren met realisatie. In een ander project kan één persoon bedrijfsanalyse combineren met scopecoördinatie.

Combineer verantwoordelijkheden niet alleen omdat "iemand het moet doen". De combinatie is pas logisch als de persoon beide verantwoordelijkheden op het vereiste niveau kan uitvoeren en er voldoende tijd voor heeft.

Eén persoon kan een verstandige bezetting zijn als tegelijk geldt:

• de scope is klein en duidelijk,
• de benodigde vaardigheden passen echt bij de mogelijkheden van die persoon,
• taken vereisen weinig parallel werk,
• externe afhankelijkheden zijn beperkt,
• het risico is acceptabel,
• de deadline past bij de echte capaciteit,
• gebrek aan vervanging wordt bewust geaccepteerd.

Dat kan bijvoorbeeld een klein informatief product, eenvoudige analyse, eenmalig advies of beperkte implementatie in een bekende omgeving zijn.

Het hangt nog steeds af van de concrete scope. Het label "klein project" geeft op zichzelf geen antwoord.

Een team wordt beter verdedigbaar wanneer meerdere van deze omstandigheden optreden:

• de benodigde vaardigheden zijn te breed voor één persoon,
• veel werkzaamheden moeten parallel lopen,
• de deadline is korter dan realistische sequentiële uitvoering,
• het project heeft veel afhankelijkheden en interfaces,
• risico vereist onafhankelijke specialistische kennis,
• de oplossing moet tegelijk worden gebouwd en beheerd,
• één persoon zou een kritisch punt voor het hele project worden,
• de verantwoordelijkheid beslaat meerdere duidelijk verschillende disciplines.

Onder zulke omstandigheden is het aanvullen van ontbrekende capaciteiten belangrijker dan simpelweg meer mensen toevoegen.

Meer mensen vergroten de beschikbare kennis en potentiële capaciteit, maar kunnen ook afhankelijkheden, overdrachten en de noodzaak tot afstemming vergroten.

Een onderzoek naar softwareprojecten in het Journal of Systems and Software liet zien dat relaties tussen teamgrootte, productiviteit, inspanning en tijd complex zijn en niet altijd overeenkomen met intuïtieve verwachtingen. [6]

Ook de meta-analyse over teamgrootte laat zien dat resultaten afhangen van taakcontext en de kosten van teamprocessen. [4]

De vraag is dus niet "hoeveel mensen kunnen we toevoegen?", maar "neemt de volgende persoon een echte projectbeperking weg in grotere mate dan de coördinatiekosten toenemen?"

Niet iedere belangrijke vaardigheid hoeft dagelijks aanwezig te zijn.

Permanente aanwezigheid is logischer wanneer iemand regelmatig beslissingen neemt, het werk veel afhankelijkheden met andere gebieden heeft of snelle reactie belangrijk is.

Periodieke ondersteuning kan genoeg zijn wanneer expertise op specifieke momenten nodig is, bijvoorbeeld voor beoordeling, advies, risicoanalyse of specialistische acceptatie.

Er is één voorwaarde: beschikbaarheid moet echt zijn. Het moet duidelijk zijn:

• wie verantwoordelijk is,
• wanneer de specialist beschikbaar is,
• welke reactietijd geldt,
• welke beslissingen genomen mogen worden,
• wat er gebeurt wanneer een probleem wordt gevonden.

Toegang tot een specialist zonder duidelijke verantwoordelijkheid kan goed staan in een organigram en toch falen in een echt project.

Stel dat het doel is een online reserveringssysteem te lanceren.

Variant A: eenvoudig prototype om het idee te testen
De scope is beperkt, er zijn geen betalingen of bijzonder gevoelige gegevens en het doel is het proces met een kleine gebruikersgroep te testen. Eén veelzijdige persoon kan mogelijk ontwerp en realisatie afdekken, met periodiek advies waar nodig.

Variant B: publieke dienst met accounts, betalingen en integraties
Er ontstaan meer specialisatie, tests, risico's, afhankelijkheden en parallel werk. Een team van meerdere mensen wordt veel beter onderbouwd.

Variant C: continu draaiende dienst met snelle reactie op problemen
Naast ontwikkeling komen beheer, monitoring, incidentrespons en continuïteit van kennis. De bezetting om te lanceren is mogelijk niet voldoende voor duurzaam beheer.

Het algemene producttype is hetzelfde, maar verschillende scope, risico en bedrijfsmodel creëren verschillende teambehoeften.

1. Je begint met een vaste lijst functietitels in plaats van het werk dat moet gebeuren.

2. Je neemt aan dat iedere rol een aparte persoon vereist.

3. Je kijkt alleen naar vaardigheden en negeert beschikbare tijd.

4. Je voegt mensen toe zonder afhankelijkheden en knelpunten weg te nemen.

5. Je negeert risicogedreven vaardigheden omdat ze geen zichtbare productfunctie opleveren.

6. Je maakt meerdere kritieke gebieden afhankelijk van één persoon zonder het risico bewust te accepteren.

7. Je behandelt de bezetting bij de start als onveranderlijk tot het einde.

GOV.UK stelt expliciet dat teamgrootte en rollen veranderen tijdens de verschillende ontwikkelfasen van een dienst. [2]

Dat is ook buiten publieke diensten een verstandig principe:

• vroeg in het project kan meer onderzoek en probleemdefinitie nodig zijn,
• tijdens realisatie worden uitvoerings- en testvaardigheden belangrijker,
• voor lancering kan meer aandacht nodig zijn voor beveiliging, kwaliteit en operationele gereedheid,
• na lancering verschuift de balans tussen ontwikkeling en beheer.

De minimale bezetting hoort bij fase en scope, niet bij één vast getal voor het hele project.

Noteer voor ieder belangrijk gebied vijf zaken:

Werkgebied - wat moet gebeuren?
Vaardigheid - welke kennis en kunde zijn nodig?
Verantwoordelijkheid - wie beslist en is eigenaar van het resultaat?
Beschikbaarheid - is de vaardigheid permanent, periodiek of extern?
Risico bij afwezigheid - wat gebeurt er als de vaardigheid ontbreekt of de persoon niet beschikbaar is?

Wijs pas daarna concrete mensen toe.

Als één persoon meerdere regels afdekt, controleer tijd en afhankelijkheden. Als één regel meerdere mensen vraagt, bepaal of capaciteit, onafhankelijke controle of parallel werk de reden is.

1. Heeft ieder verplicht werkgebied een eigenaar?
2. Heeft iedere kritieke verantwoordelijkheid iemand met de juiste vaardigheid?
3. Dekt iemand meerdere rollen af en is daar realistisch genoeg tijd voor?
4. Vereist het project parallel werk dat de huidige bezetting niet aankan?
5. Kennen we de belangrijkste afhankelijkheden van andere mensen, teams en leveranciers?
6. Hebben belangrijke risico's toegang tot de juiste specialistische expertise?
7. Kan één afwezigheid het hele project stoppen?
8. Is de bezetting voldoende voor niet alleen bouw, maar ook lancering en beheer als dat binnen de scope valt?
9. Weten we welke vaardigheden periodiek in plaats van permanent beschikbaar kunnen zijn?
10. Zijn er momenten vastgelegd waarop de bezetting na scope- of fasewijzigingen opnieuw wordt beoordeeld?

Teamontwerp moet niet beginnen met:

"hoeveel mensen hebben projecten als dit meestal nodig?"

Een betere volgorde is:

resultaat -> werk -> vaardigheden -> afhankelijkheden -> risico -> capaciteit -> mensen.

Als één persoon na deze analyse echt alles afdekt, kan één persoon de juiste keuze zijn.

Als vaardigheden, tijd, onafhankelijke controle, continuïteit of parallelle uitvoering ontbreken, heb je extra mensen of betrouwbare toegang tot specialisten nodig.

Het doel is niet het kleinste team. Het doel is de kleinste bezetting die het vereiste resultaat realistisch kan leveren op het vereiste niveau van risico en kwaliteit.

[1] GOV.UK Service Standard - Have a multidisciplinary team
Bron openen

[2] GOV.UK Service Manual - Set up a service team at each phase
Bron openen

[3] The Scrum Guide, 2020 - Scrum Team
Bron openen

[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
Bron openen

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

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

[7] Project Management Institute - Solving The Resource Puzzle
Bron openen

[8] GOV.UK Service Manual - Running more than one service team
Bron openen

Methodologische toelichting: sommige bronnen gaan over digitale publieke diensten, andere over Scrum teams, projectmanagement of onderzoek naar teams en softwareontwikkeling. Deze gids gebruikt iedere bron alleen voor de punten die zij daadwerkelijk ondersteunt. De methode in zeven stappen is een redactionele synthese van die principes en geen formele norm van de genoemde organisaties.