Medewerkers plannen op basis van omvang en zekerheid.
Veel dienstverleners worstelen met de inzet van hun medewerkers op projecten. Dit is vooral wanneer verschillende delen van het bedrijf gaan touwtrekken om medewerkers. Dit wil je voorkomen, want dat touwtrekken is funest voor een goede en tijdige uitvoering van projecten. Het voorkomen doe je door de juiste projectaanpak te kiezen. Ten eerste doe je dit door medewerkers fulltime toe te wijzen aan projecten. Daarnaast is het belangrijk om ook een goed onderscheid te maken tussen projecten en ander werk. 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. Ons voorbeeldbedrijf werkt projectmatig, maar voert ook kleine opdrachten uit voor klanten. Dit doen ze met enige tientallen medewerkers. Verder gaan we er ook vanuit dat het management niet meer werk aanneemt dan dat er beschikbare medewerkers zijn. Doen ze dit wel, dan krijgt het getrek aan medewerkers er een hele andere dimensie bij.
We gaan uit van de situatie dat een bedrijf over voldoende medewerkers beschikt. Ze hebben alleen een probleem. Het bedrijf slaagt er niet in om projecten en overig type werk efficiënt en effectief uit te voeren. De uitvoering hapert, omdat medewerkers tussen projecten en opdrachten heen en weer worden getrokken. Dit komt bijvoorbeeld doordat er plots urgente incidenten zijn, de scope van projecten wijzigt, er tegenvallers zijn, enzovoort.
We onderscheiden drie mogelijke oorzaken:
- Verkeerde projectaanpak
- Versnipperde en verkeerde inzet van medewerkers
- 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 kiezen er voor om de ene of de andere benadering bedrijfsbreed en voor elk project te hanteren. Dit is alleen een valkuil. Je zou dit namelijk 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, begint met het project in stukken opdelen. Daarna geldt in de regel dat je niet eerder met stap twee begint, voordat stap één klaar is. 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.
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. Bij het plannen van je resources is dan ook eenvoudig te bepalen wanneer, hoeveel uren en welke competenties nodig zijn. Op basis daarvan kan je een geschikte resource plannen.
Agile
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 bij het resources plannen, 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 planning van je resources heb je als een passende puzzel in elkaar gezet. Dan wijzigen vervolgens de kaders van het project en klopt de hele puzzel niet meer.
Voor projecten met veel onzekerheid is het beter om een Agile methode te hanteren, 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 planning van je resources betreft werk je met een fulltime en vast team, 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 resources worden op basis van de inhoud van het werk gepland. Bij projecten met veel onzekerheid is dat niet mogelijk, omdat dit erg in beweging is. Bij een Agile benadering draai je het vertrekpunt van de planning om. Je gaat dus uit van een vast team en vanuit daar ga je te werk.
De aanpak ten aanzien van de resource planning verschilt fundamenteel bij de watervalmethode ten opzichte van een Agile methode. We hebben gezien dat de watervalmethode tot problemen leidt bij onzekere projecten. Daarnaast sluit Agile niet perfect aan bij een project met veel zekerheid. 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 werk kunt houden.
2. Versnipperde en verkeerde inzet van medewerkers
Dedicated vs. multi-tasking
Idealiter plan je resources 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.
In bovenstaand figuur zie je dat als je fulltime kunt werken aan project A, dat het werk al na twee dagen af is vergeleken met vier dagen bij multi-tasking. Nu zou de inzet over meerdere projecten goed op elkaar afgestemd kunnen zijn. Echter, op het moment dat projectmanager A meer inzet gaat eisen, dan gaat dit 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 resources fulltime op projecten kunt plannen, dan kun je het bovengeschetste probleem vermijden. Alleen wordt er vaak gezegd dat het niet mogelijk is om medewerkers geheel vrij te spelen. Ze houden er dan rekening mee dat hun expertise ook elders nodig is. Dat kan natuurlijk zo zijn. Echter kan je er voor kiezen om een minder competente medewerker in te zetten, omdat deze wel fulltime beschikbaar is. Daarmee voorkom je het getouwtrek om medewerkers en dat geeft een hoop rust.
Specialisten vs. generalisten
Bij de watervalmethode laat het werk van je resources zich goed plannen. In deze situatie kan je precies aangeven wanneer, hoeveel uren en welke competenties nodig 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, stel je een team met alle benodigde disciplines samen. Dat vraagt om de inzet van generalisten die breder inzetbaar zijn. Hierdoor kunnen de leden van het team ook taken oppakken die niet tot hun primaire discipline behoren.
Als je een specialist inzet in een generieke rol, dan haakt hij of zij op enig moment af. De medewerker wordt dan namelijk niet genoeg op zijn competenties 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 het resources plannen is het verstandig om te kijken of de projectomgeving bij de medewerkers past. Een Agile benadering van een project vraagt om medewerkers die zich snel kunnen aanpassen. 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.
Plan je daarentegen een project met de watervalmethode, dan heb je een ander soort medewerker nodig. Hier komen namelijk medewerkers die hun werk tot in detail kunnen plannen, beter tot hun recht. 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. Je weet namelijk niet altijd wanneer deze opdrachten zich voordoen en hoeveel werk ze met zich meebrengen. Dit is bijvoorbeeld het geval bij het oplossen van een incident. Nu zie je vaak dat resources zowel op deze kleine opdrachten worden ingepland alsook op projecten. Dat is niet handig, want dat werkt het getouwtrek van medewerkers weer in de hand. Er wordt dan bijvoorbeeld voorrang gegeven aan het oplossen van een urgent incident. Dit gaat vervolgens ten koste van de inzet op een project, met alle gevolgen van dien.
Binnen de kleine opdrachten kan je ook weer onderscheid maken tussen de echt kleine opdrachten en de wat grotere. Hierom is het raadzaam om twee aparte teams in te stellen, namelijk het support team en het service team.
Het support team
Veel bedrijven kennen al een support desk. Zij nemen bijvoorbeeld vragen, incidenten en kleine verzoeken voor hun rekening. Dit team houdt zich voornamelijk bezig met kleine alledaagse verzoeken van klanten. Hierdoor is de cyclus van een opdracht kort en met betrekking tot de planning, redelijk onzeker. Opdrachten duren typisch niet langer dan een paar uur.
In dit geval is het niet raadzaam om het resources plannen op het niveau van de opdrachten te doen. Daarvoor is het werk veel te onvoorspelbaar en te klein. Zie hiervoor ook de blog Fijnmazig plannen? 3 beslisfactoren. Een support desk plan je in diensten. Hierdoor weet je zeker 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 flink aantal uren vragen. Hierdoor zijn ze te groot voor het support team, maar te klein om er een project van te maken. Denk bijvoorbeeld aan een wijzigingsverzoek waar een ontwikkelaar en een tester tachtig 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 dus kan je er resources op plannen.
Voor de omslag naar een project zou je bijvoorbeeld de grens kunnen trekken bij 360 uur. Dan wordt het echt een substantiële klus, omdat je dan drie medewerkers drie weken fulltime aan het werk hebt. Een opdracht kan zich tijdens de uitvoering plots ontvouwen van een duur van initieel 300 uur naar 3.000 uur. Als dat gebeurt, dan maak je er een project van en haal je het bij het service team weg.
Conclusie
Het werk in de vorm van projecten en kleine opdrachten beweegt zich op de assen van omvang en mate van zekerheid. Hierdoor kunnen we vier werkdomeinen onderscheiden, zoals weergegeven in onderstaande figuur.
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. Is er veel onzekerheid, kies dan voor een Agile benadering. Bij de kleine opdrachten maak je eigenlijk een zelfde tweedeling. Al het kleine onvoorspelbare werk wordt afgehandeld door het support team. Daarnaast laat je de grotere opdrachten uitvoeren door het service team.
Door deze vierdeling en het profiel van je medewerkers weet je in welk domein de resources het beste passen. Gaat het om een generalist? Dan past de medewerker het beste in een support team of een in Scrum project. Gaat het om een specialist, dan past deze het beste in een service team of in een traditioneel project. Op deze manier kan hij of zij de verdieping van kennis en vaardigheden 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
