Stop het getouwtrek om medewerkers

Resource planning op basis van omvang en mate van zekerheid
Stop het getouwtrek om medewerkers

Veel dienstverleners worstelen met de inzet van hun medewerkers op projecten. Met name het getouwtrek aan medewerkers vanuit verschillende delen van het bedrijf blijkt funest te zijn voor een goede en tijdige uitvoering van de projecten. Door de juiste projectaanpak te kiezen, fulltime medewerkers toe te wijzen en goed onderscheid te maken tussen projecten en overig werk, kun je hieraan het hoofd bieden. In deze blog gaan we hier nader op in.

Voor dit vraagstuk nemen we projectmatig werkende dienstverleners als uitgangspunt, zoals een ICT bedrijf of een internetbureau. Ze werken projectmatig, maar voeren ook kleine opdrachten uit voor klanten en voeren dit uit met een personeelsbestand van enige tientallen medewerkers. Verder gaan we er ook vanuit dat het management niet meer werk aanneemt dan dat er beschikbare medewerkers zijn, want anders krijgt het getrek aan medewerkers er een hele andere dimensie bij.

We gaan uit van de situatie dat een bedrijf over voldoende medewerkers beschikt, maar er niet in slaagt om projecten en overig werk efficiënt en effectief uit te voeren. De uitvoering hapert omdat medewerkers tussen projecten en opdrachten heen en weer worden getrokken, vanwege urgente incidenten die zich voordoen, wijzigingen in de scope, tegenvallers, enzovoort. We onderscheiden 3 mogelijke oorzaken:

  • 1.  Verkeerde projectaanpak
  • 2.  Versnipperde en verkeerde inzet van medewerkers
  • 3.  Geen scheiding tussen projecten en overig werk


1. Verkeerde projectaanpak

Grofweg kun je een project op twee manieren aanpakken: volgens de klassieke watervalmethode of met een Agile methode. Deze twee methoden vormen het uiterste van het spectrum, want daar tussenin kunnen nog mengvormen onderscheiden worden. Veel organisaties hebben gekozen om de ene benadering dan wel de andere benadering bedrijfsbreed voor elk project te hanteren, maar dat is een valkuil. Je zou dit per project moeten beoordelen.

De watervalmethode

De watervalmethode is een aanpak waarin de stappen regelmatig vloeiend naar beneden lopen, als een waterval. Het concept van deze aanpak, is dat het project in verschillende stappen wordt opgedeeld en dat men niet eerder met stap 2 start, dan wanneer stap 1 is afgerond. Wanneer in een van de stappen een fout ontdekt wordt, ga je terug naar die stap om de fout te corrigeren en de daaropvolgende stappen opnieuw uit te voeren.

De watervalmethode
Figuur 1: De watervalmethode

Deze methode werkt goed als de beoogde projectresultaten goed gespecificeerd zijn, niet wijzigen en als het verloop van het project in een stabiele omgeving plaatsvindt. Er is dan een hoge mate van zekerheid, want het verloop van het project is goed te voorspellen. Ten aanzien van de resource planning is dan ook eenvoudig per stap te bepalen wanneer, hoeveel uren en welke competenties nodig zijn. Op basis daarvan kan een geschikte medewerker worden ingepland.

Een Agile methode

Je hebt ook projecten waarvan de projectresultaten niet goed gespecificeerd zijn en zich in een dynamische omgeving afspelen. Tijdens het project kan er dus nog van alles wijzigen. De eindbestemming is ongeveer bekend (er is een richting), maar de route ernaar toe ontvouwt zich gedurende de reis. Deze projecten gaan gepaard met relatief veel onzekerheid.

Als je voor zo'n project de watervalmethode hanteert, dan vraag je om problemen. Je zult zien dat je constant de planning moet aanpassen aan de gewijzigde omstandigheden. Vanwege afhankelijkheden tussen stappen, leidt dit direct tot vertragingen in de uitvoering en problemen in de beschikbaarheid van medewerkers. De resource planning was van te voren als een passende puzzel in elkaar gezet en nu wijzigen de kaders, waardoor de hele puzzel niet meer klopt.

Voor projecten met een hoge mate van onzekerheid is het beter om een meer Agile methode te hanteren, zoals bijvoorbeeld Scrum. Het Engelse woord Agile betekent behendig, lenig. Een Agile methode is er op gericht om zich snel aan te passen aan de veranderende werkelijkheid. Wat de resource planning betreft ga je werken met een vast team met fulltime inzet gedurende het hele project. Van te voren schat je in welke disciplines je nodig hebt.

De mate van zekerheid is bepalend

Bij projecten met een hoge mate van zekerheid, kun je gaan redeneren vanuit het werk dat gedaan moet worden. De resource planning wordt op basis van de inhoud van het werk afgeleid. Bij projecten met veel onzekerheid is dat niet mogelijk, omdat dit erg in beweging is. Bij een Agile benadering zie je dus dat het vertrekpunt van de resource planning wordt omgedraaid: je gaat uit van een vast team (capaciteit) en vanuit daar ga je te werk.

De aanpak ten aanzien van resource planning verschilt fundamenteel bij de watervalmethode ten opzichte van een Agile methode. We hebben gezien dat de klassieke watervalmethode tot problemen leidt bij onzekere projecten, maar ook de Agile benadering zal niet perfect aansluiten bij een project dat veel zekerheid kent. Je beschikt dan over een vaste capaciteit, terwijl de uitvoering vraagt om specifieke inzet op specifieke momenten. Dat leidt tot een inefficiënte inzet van medewerkers omdat je waarschijnlijk niet iedereen aan het werkt kunt houden.


2. Versnipperde en verkeerde inzet van medewerkers

Dedicated vs. multi-tasking

Idealiter zet je medewerkers zoveel mogelijk fulltime in op projecten. Een Agile methode als Scrum stelt dat zelfs als voorwaarde. Multi-tasking is namelijk inefficiënt, zie hiervoor ook de blog 4 tijdverspillers in project planning, en het werkt het getouwtrek om de medewerkers juist in de hand. Dit komt omdat medewerkers op meerdere fronten voortgang moeten boeken en projectmanagers hier hen op aansturen.

Effecten van multi-tasking
Figuur 2: Effecten van multi-tasking

In bovenstaand figuur zie je dat als je fulltime kunt werken aan project A, dat het werk al na 2 dagen af is vergeleken met 4 dagen bij multi-tasking. Nu zou de inzet over meerdere projecten goed op elkaar afgestemd kunnen zijn, maar op het moment dat projectmanager A meer inzet gaat eisen (en het ook voor elkaar krijgt), dan gaat dit direct ten koste van de andere projecten. Als tegenreactie gaan projectmanager B en C ook trekken aan de medewerker, oftewel het getouwtrek is begonnen.

Als je medewerkers fulltime op projecten kunt inplannen, dan kun je het bovengeschetste probleem vermijden. Nu wordt vaak als tegenargument gebruikt dat het simpelweg niet mogelijk is om medewerkers geheel vrij te spelen, omdat hun expertise ook elders benodigd is. Dat kan natuurlijk zo zijn, maar je kunt er natuurlijk ook bewust voor kiezen om dan maar een iets minder competente medewerker in te zetten, wiens capaciteit in ieder geval onvoorwaardelijk fulltime kan worden ingezet. Daarmee voorkom je het getouwtrek om medewerkers en dat geeft een hoop rust.

Specialisten vs. generalisten

Bij de watervalmethode laat het werk zich goed plannen en kan precies worden aangeven wanneer, hoeveel uren en welke competenties benodigd zijn. Deze situatie leent zich goed om heel gericht specialisten te plannen. Je weet immers precies wat er benodigd is en zoekt daarvoor de medewerker die het beste aansluit.

Bij een Agile benadering ligt dat anders. Om het hoofd te bieden aan de onzekerheid van de omgeving en het feit dat de specificaties van het beoogde projectresultaat niet geheel duidelijk zijn, wordt er een team samengesteld dat op hoofdlijnen alle benodigde disciplines bevat. Dat vraagt meer om de inzet van generalisten die breder inzetbaar zijn en dus ook taken kunnen oppakken die in eerste instantie niet tot hun primaire discipline behoren.

Als je een specialist inzet in een generieke rol, dan heb je de kans dat de specialist op enig moment afhaakt, omdat hij niet kan voldoen aan de vraag en niet genoeg op zijn competenties wordt ingezet. Omgekeerd: als je de generalist voortdurend inzet op hele specialistische taken, dan wordt hij daar ook niet gelukkig van. Hij krijgt juist energie van een breed takenpakket. Zorg dus dat je de juiste mensen inzet op basis van de gekozen projectaanpak.

Flexibiliteit vs. planmatig werken

Bij de resource planning is het ook verstandig om te kijken of de dynamiek van de projectomgeving goed past bij het profiel van de medewerkers. Als je een project aanpakt met een Agile benadering, dan vraagt dat om medewerkers die zich snel kunnen aanpassen aan een veranderende werkelijkheid. Flexibiliteit is hier een belangrijke waarde. Medewerkers die slecht functioneren in zo'n dynamische omgeving komen dan niet tot hun recht. Hun toegevoegde waarde zal niet optimaal zijn.

Pak je daarentegen een project aan met de watervalmethode, dan heb je medewerkers nodig die gewend zijn om hun werk tot in detail te plannen. Ze moeten precies kunnen aangeven wanneer ze welke resultaten verwachten op te leveren. Als je medewerkers inzet die moeite hebben met planmatig werken, dan wordt je project planning mogelijk onbetrouwbaar. Daarbij voelt de betreffende medewerker zich mogelijk gefrustreerd, omdat hij of zij niet kan voldoen aan de verwachtingen.


3. Geen scheiding tussen projecten en overig werk

Nu hebben we alleen maar onderscheid gemaakt in projecten die veel onzekerheid en projecten die weinig onzekerheid vertonen. Bij projectmatige dienstverleners bestaat echter lang niet al het werk uit projecten. Vaak wordt een substantieel deel van het werk gevormd door kleinere opdrachten. Denk bijvoorbeeld aan incidenten, onderhoud en wijzigingsverzoeken.

Deze kleine opdrachten kunnen een behoorlijk beslag leggen op de medewerkers, omdat je niet altijd weet wanneer ze zich voordoen en hoeveel werk ze met zich meebrengen, zoals bij het oplossen van een incident. Nu zie je vaak dat medewerkers zowel op deze kleine opdrachten worden ingezet alsook op projecten. Dat is niet handig, want dat werkt het getrouwtrek van medewerkers weer in de hand. Er wordt dan bijvoorbeeld voorrang gegeven aan het oplossen van een urgent incident ten koste van de inzet op een project, met alle gevolgen van dien.

Omdat je binnen de kleine opdrachten ook weer onderscheid kunt maken in de echt kleine opdrachten en de wat grotere, is het raadzaam om hiervoor twee aparte team in te stellen: het support team en het service team.

Het support team

Veel bedrijven kennen al een support desk voor het in behandeling nemen van vragen, incidenten en kleine verzoeken zoals het doorvoeren van wijzigingen op de website. Dit support team houdt zich voornamelijk bezig met kleine alledaagse verzoeken van kanten, die heel kort cyclisch verlopen en redelijk onzeker zijn met betrekking tot de planning. Opdrachten duren typisch niet langer dan een paar uur.

Vanuit de resource planning bekeken is het niet raadzaam om de medewerkers van dit team in te plannen op het niveau van de opdrachten. Daarvoor is het werk veel te onvoorspelbaar en te klein. Zie hiervoor ook de blog Fijnmazig plannen? 3 beslisfactoren. Je zult veelal de bezetting van het support team in diensten willen plannen om te waarborgen dat er altijd voldoende medewerkers zijn om het werk af te handelen.

Het service team

Het service team houdt zich bezig met opdrachten die een substantieel aantal uren vergen, te groot zijn voor het support team en te klein om er een project van te maken. Denk bijvoorbeeld aan een wijzigingsverzoek waar een ontwikkelaar en een tester 80 uur mee bezig zijn. Zo’n wijzigingsverzoek vraagt vaak om een andere aanpak en meer specialistische kennis dan bij het support team aanwezig is. De uitvoering van deze opdrachten is goed te overzien en te plannen.

Voor de omslag naar een project zou je bijvoorbeeld de grens kunnen trekken bij 480 uur. Dan wordt het echt een substantiële klus, omdat je dan 3 medewerkers 3 weken fulltime aan het werkt hebt. Op het moment dat een opdracht tijdens de uitvoering zich opeens ontvouwt van initieel 300 uur naar 3.000 uur, dan is het ook zaak om er een project van te maken en het weg te halen bij het service team.


Conclusie

Samenvattend kunnen we stellen dat het werk in de vorm van projecten en kleine opdrachten, zich beweegt op de assen van omvang en mate van zekerheid. Hierdoor kunnen 4 werkdomeinen onderscheiden zoals weergegeven in onderstaande figuur.

Werkdomeinen naar omvang en mate van zekerheid
Figuur 3: Werkdomeinen naar omvang en mate van zekerheid

Bij een bepaalde omvang van het werk kiezen we ervoor om het werk projectmatig aan te pakken. Een belangrijke keuze daarin is de projectaanpak. Bij duidelijke specificaties en een stabiele omgeving kun je de watervalmethode kiezen. Bij veel onzekerheid kies je voor een Agile benadering. Bij de kleine opdrachten maak je eigenlijk een zelfde tweedeling. Al het kleine onvoorspelbare binnenkomende werk wordt afgehandeld door het support team en de grotere opdrachten laat je uitvoeren door het service team.

Op basis van deze vierdeling en het profiel van de medewerker blijkt ook snel in welk domein de medewerker het beste tot zijn recht komt. Ben je meer een generalist? Dan pas je het beste in een support team of een in Scrum project. Ben je meer een specialist, dan pas je het beste in een service team of in een traditioneel project waarin je de verdieping van je kennis en vaardigheden kunt toepassen.

  • Het getouwtrek aan de medewerkers voorkom je vervolgens door:
  •  het werk in het juiste werkdomein te laten landen
  •  medewerkers fulltime in één van deze domeinen te laten werken

Vragen of opmerkingen naar aanleiding van dit artikel? Neem contact op met Timewax.


Founder
Mark de Jong
Mark is directeur Sales & Marketing bij Timewax. Hij heeft een achtergrond als project- en resourcemanager bij o.a. PricewaterhouseCoopers Management Consultants met expertise op het gebied van Professional Service Automation (PSA).