De zin en onzin van projecten plannen met behulp van een rooster.
De afgelopen tijd heb ik contact gehad met een aantal organisaties dat heeft 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 continu 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 tachtig procent van hun bezetting. De planning van projecten deden ze in spreadsheets, maar dat was niet meer te doen. Het was 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 roosteren van het zorgpersoneel. Dat werkte goed, dus bedachten ze dat ze er prima hun projecten mee konden plannen.
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 die activiteiten van het projecten konden ze makkelijk roosteren. 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. Toen werden de eerste problemen met het projecten roosteren zichtbaar.
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.
Een tweede knelpunt van het plannen van een project in een rooster, 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 een percentage gereed te rapporteren. Dit moest ook handmatig door de projectmanager geïnventariseerd en geregistreerd worden.
Een laatste knelpunt dat 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 twintig procent 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.
Conclusie
Het plannen van projecten bestaat eigenlijk uit twee componenten:
- Project planning
- 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 dit niet lukt wanneer je een project met roosterpakket probeert te plannen. 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 dan allerlei alerts ontstaan. Op deze diensten zijn namelijk nog geen mensen 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 veertig 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.
Project 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.
