Projecten roosteren: kan dat?

De zin en onzin van projecten plannen in een roosterpakket
Projecten roosteren: kan dat?

De afgelopen tijd heb ik contact gehad met een aantal organisaties die hebben geprobeerd om hun projecten te plannen in Workforce Management software. Oftewel, ze hebben geprobeerd hun projecten te roosteren in een roosterpakket. Kan dit eigenlijk wel en waar liggen de grenzen? In deze blog gaan we dit aan de hand van een praktijkcase bekijken.

Met betrekking tot planning heb je in de wereld twee segmenten: roostering van diensten aan de ene kant en planning van projecten aan de andere kant. Zo ook met planningspakketten. Aan de ene kant zien we roosterpakketten die vaak onderdeel uitmaken van Workforce Management software. Aan de andere kant zien we project planning toepassingen die deel uitmaken van projectmanagement software.

In deze blog leggen we de focus op de planning van mensen op diensten en projecten. Logistieke planning en productieplanning laten we buiten beschouwing. Dat is een wereld op zich. Voordat we de praktijkcase in duiken, gaan we eerst kijken naar de definitie van een dienst, een project en waarin ze verschillen.


Verschillen tussen projecten en diensten

Project

Het doel van een project is het bereiken van een eenmalig uniek resultaat. De gewenste kwaliteit wordt van te voren vastgesteld en het project wordt gekenmerkt door een beperkt tijdsbestek en budget. Een voorbeeld van een project is het invoeren van een nieuw elektronisch patiënten dossier.

  • Typische kenmerken van een project:
  •  Een project en de activiteiten zijn eenmalig
  •  Voornaamste focus ligt op resultaat
  •  Activiteiten hebben onderling afhankelijkheden
  •  Een project planning wijzigt regelmatig
  •  Er zijn duidelijke deadlines

Dienst

Een dienst is herhalende arbeid die door medewerkers wordt verricht. Bij de invulling van diensten is het doel de capaciteit van de medewerkers zo optimaal mogelijk te benutten. Een voorbeeld van een dienst is het dagelijkse onderzoek van bloedmonsters in een ziekenhuislaboratorium.

  • Typische kenmerken van een dienst:
  •  Een dienst heeft een herhalend karakter
  •  De uitvoering wordt continue geoptimaliseerd
  •  Minimale afhankelijkheden met andere diensten
  •  Een rooster staat voor langere tijd vast
  •  De uitvoering is gebonden aan normen

Projectmanagement vs. procesmanagement

Het grootste verschil zit hem in het feit dat een project eenmalig is en een dienst herhaaldelijk. Dat zorgt voor een hele andere focus in de beheersing van een project en een dienst. Bij een project zal minder aandacht zijn voor het 'hoe', zolang het resultaat maar wordt behaald. Bij een dienst is juist meer focus op de efficiency. De dienst herhaalt zich immers en men streeft ernaar om deze steeds meer te optimaliseren. Typisch procesmanagement.

Toch is er wel een gemene deler te vinden in de efficiency. Een project heeft namelijk geen oneindige middelen (tijd en geld) tot zijn beschikking, dus ook daar is aandacht voor een optimale inzet van middelen. Uiteindelijk hebben we het hier dan over mensen. De juiste mensen, dus met de juiste competenties op het juiste moment in de tijd (planning). Daar ligt dus de overeenkomt: resource planning.


Praktijkcase: een project roosteren

De IT-afdeling van een ziekenhuis draaide projecten voor 80% van hun bezetting. De planning van projecten deden ze in spreadsheets, maar dat was niet meer te doen. Te arbeidsintensief en te foutgevoelig. Ze gingen op zoek naar een pakket om hun projecten in te plannen. Nu maakte het ziekenhuis al gebruik van Workforce Management software voor het inroosteren van het zorgpersoneel. Dat werkte goed, dus dachten ze daar ook maar gebruik van te maken.

Hoe ze te werk gingen

Ze maakten in eerste instantie elke activiteit binnen het project als een dienst aan. Vervolgens gingen ze de verschillende projectleden inplannen op de diensten. Sommige activiteiten liepen meerdere weken, dus daar kon makkelijk op geroosterd worden. Tot zover ging het goed.

Nu waren er ook vele kleine activiteiten die slechts een dag of een week duurde. Die werden ook ingebracht in het roosterpakket. Dat zorgde al voor minder overzicht, want dat gaf veel items tot gevolg, die bovendien zich niet herhaalde. Ze waren eenmalig. Ook niet alle activiteiten hoefde per se op een bepaalde dag te gebeuren, als het maar voor de deadline plaatsvond. Daar kon het roosterpakket niet zo goed mee omgaan.

Wat niet werkte

De projectmanager kreeg uit het roosterpakket geen goed overzicht van alle activiteiten in het project en hun onderlinge samenhang. Dit overzicht had hij nodig om de planning met de opdrachtgever, projectleden en leveranciers te communiceren. Hij was op zoek naar een balkenplanning oftewel een Gantt Chart.

Voorbeeld balkenplanning / Gantt Chart
Figuur 1: Voorbeeld balkenplanning / Gantt Chart

Een tweede knelpunt was de rapportage. Omdat het een groot project betrof met veel inzet van interne en externe medewerkers, moest er strak gestuurd worden op de uren. Nu was de urenregistratie via de Workforce Management software wel geregeld, maar de projectmanager had geen standaardrapport waarmee hij met een druk op de knop de begrote, geplande en werkelijke uren met elkaar kon vergelijken. Dit moest hij alsnog handmatig doen.

Aanvullend op de rapportage was het voor de projectleden ook niet mogelijk om de status en voortgang (in % gereed) te rapporteren. Dit moest ook handmatig door de projectmanager geïnventariseerd en geregistreerd worden.

Een laatste knelpunt die de projectmanager ervoer, was dat de inzet van medewerkers niet makkelijk te wijzigen was. Bepaalde activiteiten liepen vertraging op en daardoor moest hij handmatig allerlei diensten verplaatsen en mensen opnieuw inplannen. Bovendien had hij in het systeem niet alle rechten, omdat hij anders ook roosters van het zorgpersoneel kon aanpassen. Hij werd afhankelijk van de roosterplanners om hem te helpen.

Integrale resource planning

De manager van de afdeling zag in dat hij met het systeem de resource planning van de gehele IT-afdeling kan beheersen. Zowel de projecten alsook 20% van de bezetting die niet projectmatig werkt. Deze uren konden bij uitstek als diensten worden ingepland. Denk hierbij aan helpdesk, standby diensten en vaste beheersactiviteiten. Dat zou de afdeling meer grip geven op de beschikbaarheid van medewerkers enerzijds en de vraag vanuit projecten en de normale diensten anderzijds.


Conclusies

  • Het plannen van project bestaat eigenlijk uit twee componenten:
  • 1.  Project planning
  • 2.  Resource planning

1. Project planning

Met de project planning wil de projectmanager het project structureren. Het is het raamwerk waarlangs hij het project wil beheersen en communiceren. Uit de ervaringen in de praktijkcase blijkt dat een roosterpakket hiervoor niet geschikt is. De projectmanager kreeg de structuur met activiteiten wel in het pakket, maar kreeg er geen goede overzichten van de planning uit ten behoeve van de communicatie en rapportage. Hij ging alsnog zijn eigen balkenplanning in een spreadsheet maken.

In deze case bij het ziekenhuis was het niet aan de orde, maar projectmanagers willen vaak ook activiteiten in de planning opnemen, waar ze geen mensen op plannen. Denk bijvoorbeeld aan review activiteiten door klanten. Een ander voorbeeld zijn mijlpalen. Dit zijn gewoon vaste punten in de tijd om visueel weer te geven dat er dan een deadline of een beslismoment is. Op deze activiteiten plan je dus geen capaciteit in. Het inbrengen van deze soort activiteiten in een roosterpakket zal contra-intuïtief werken, omdat er allerlei alerts ontstaan omdat op deze diensten nog geen mensen zijn ingepland.

2. Resource planning

De resource planning moet waarborgen dat er mensen zijn toegekend aan de activiteiten van het project. Het beheersen van capaciteit is bij uitstek waar een roosterpakket goed in is. Bovendien stijgt resource planning boven alle projecten en diensten uit om de totale vraag en aanbod van capaciteit te beheersen.

Bij het ziekenhuis stelde ze dan ook vast dat het beheersen van de capaciteit in het roosterpakket van één project niet zo veel zin had. Ze konden bijvoorbeeld wel zien of ze binnen het project een medewerker niet meer dan 40 uur per week op één activiteit boekte, maar dat zei natuurlijk niets over de werkelijke beschikbaarheid van de medewerker in het licht van andere projecten en afdelingsactiviteiten waarbij ze betrokken zijn.

Projecten roosteren: zinvol of niet?

Als instrument voor de projectmanager om zijn planning te beheersen: een dikke nee. Het voelt als het wassen van je kleding in een vaatwasser. Je weet dat de vaatwasser ook reinigt, maar je kleding komt er niet uit zoals je wilt.

Voor de resource planning van projecten is het wel degelijk interessant. De randvoorwaarde is echter dat je wel alle projecten en diensten (afdelingsactiviteiten) gaat plannen. Het is alles of niets. Anders heeft het geen zin. De primaire belanghebbenden zijn de afdelingsmanager en teamleiders. Zij krijgen hiermee goed grip op de beschikbare capaciteit van hun mensen enerzijds en de vraag vanuit projecten anderzijds.

Uiteindelijk zullen ook de projectmanagers het nut er van inzien, omdat zij veel beter afspraken kunnen maken met de afdelingsmanager en teamleiders over de inzet van de medewerkers. Wat het detailniveau betreft, is het niet noodzakelijk om per projectactiviteit medewerkers te gaan inroosteren. Je houdt het gewoon simpel door een project als dienst aan te maken en medewerkers hierop in te roosteren. De projectmanager en de planner moeten voortdurend bewaken dat de inzet nog passend is, zodat ze kunnen anticiperen op wijzigingen.

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).
Optin Architect