Een projectmanager opent maandagochtend een planning en daar zijn ze dan. Kleine rode mensjes staan aan de linkerkant van het Gantt-diagram op een rij, het ene na het andere, en elk schreeuwt dat iemand voor meer uren is ingepland dan een dag daadwerkelijk telt. Je eerste reflex is om op de knop \u2018Alles op hetzelfde niveau brengen\u2019 te klikken en Project het te laten uitzoeken. Die reflex is de reden waarom veel goede planningen stilletjes ten onder gaan.<\/p>\n
Dit is wat niemand in alle drukte vermeldt. Het uitvlakken van de werkbelasting voegt niet op magische wijze uren toe aan iemands dag. Het verschuift het werk naar een later tijdstip, zodat dezelfde persoon niet twee dingen tegelijk hoeft te doen. Dit betekent dat de opleverdatum kan verschuiven \u2013 soms zelfs aanzienlijk \u2013 en dat dit met \u00e9\u00e9n enkele klik stilletjes kan gebeuren voor tientallen taken tegelijk.<\/p>\n
Voordat je dus iets aanraakt, is het de moeite waard om te begrijpen wat deze functie met de datums doet. Het verschil tussen een nuttige opschoning en een verpest plan is namelijk of iemand wist wat er stond te gebeuren.<\/p>\n
De meeste handleidingen doen allemaal hetzelfde: ze wijzen naar het rode personage-icoontje, zeggen dat je op \u2018Level All\u2019 moet klikken, en daar houdt het artikel op. Wat ze echter over het hoofd zien, is juist het belangrijkste deel: het levelen herschrijft het schema op basis van regels die niemand heeft vastgesteld.<\/p>\n
Standaard mag Project taken zo ver uitstellen als nodig is om het conflict op te lossen. Bij een planning met strakke afhankelijkheden kan dat de opleverdatum met weken vertragen, en omdat de wijziging in \u00e9\u00e9n keer voor zoveel taken geldt, wordt het achteraf echt moeilijk om te achterhalen wat er precies is verschoven.<\/p>\n
En er is nog een tweede lacune. Bijna niemand legt uit hoe je dit ongedaan kunt maken. Mensen voeren een \u2018levelling\u2019-bewerking uit, zien hun tijdlijn uitrekken, raken in paniek en laten de functie helemaal links liggen omdat ze ervan uitgaan dat de schade onomkeerbaar is. Dat is niet zo. Maar juist omdat ze dat niet weten, blijven teams urenlang handmatig taken heen en weer slepen, terwijl een beperkte, omkeerbare bewerking dit in enkele seconden had kunnen oplossen.<\/p>\n
Het punt is: de knop werkt prima. Het probleem is dat je hem blindelings gebruikt.<\/p>\n
Leveling bekijkt elke resource die als overbelast is gemarkeerd en stelt \u00e9\u00e9n simpele vraag: kan dit werk zo worden verdeeld dat niemand dubbel wordt ingepland? Om deze vraag te beantwoorden, stelt Project een taak uit, splitst deze op in delen of herschikt de volgorde waarin een persoon taken afhandelt.<\/p>\n
De totale hoeveelheid werk neemt nooit af. Een taak van 40 uur<\/strong> blijft 40 uur<\/strong>. Wat verandert, is wanneer<\/em> die uren op de kalender worden ingepland.<\/p>\n \u201cNivellering geeft niemand meer uren in een dag. Het voorkomt alleen dat iemand hetzelfde uur twee keer besteedt, en de prijs die daarvoor betaald moet worden, is tijd.\u201d<\/p><\/blockquote>\n In de documentatie van Microsoft zelf wordt deze afweging duidelijk benadrukt; daarin wordt opgemerkt dat het gelijk trekken van taken de voltooiing van afzonderlijke taken en zelfs het project zelf kan vertragen. Hun advies over hoe je het projectwerk gelijkmatig over het team verdelen<\/a> is het de moeite waard om dit te lezen voordat je het voor het eerst gebruikt, omdat hierin de functie wordt beschreven als een instrument voor herverdeling in plaats van als een oplossing.<\/p>\n Het veilige mentale model is dus als volgt: je ruilt de duur van het project in voor een realistische werkbelasting. Soms is die afweging prima. Soms gaat daardoor een aan een klant beloofde deadline niet meer op. De enige manier om daar achter te komen, is door te bepalen hoever Project mag gaan.<\/p>\n Voordat je iets uitvoert, moet je een referentiepunt opslaan. Ga naar \u2018Project\u2019 en vervolgens naar \u2018Referentiepunt instellen\u2019. Hiermee wordt een momentopname van de huidige gegevens gemaakt, zodat je de situatie voor en na kunt vergelijken. Eerlijk gezegd is dit de allerhandigste gewoonte voor iedereen die zich zorgen maakt over het resultaat.<\/p>\n Nu de echte \u2018safe pass\u2019. Er is een instelling waar de meeste mensen nooit aan komen, maar die alles verandert: nivelleren alleen binnen de beschikbare speling. Speling is de speelruimte die een taak heeft voordat deze invloed gaat uitoefenen op de einddatum. Beperk het nivelleren tot alleen de speling, en Project krijgt de opdracht om het werk te herschikken, maar mag de einddatum van het project niet<\/em> opschuiven. Taken met speling worden verplaatst. Taken op het kritieke pad blijven op hun plaats.<\/p>\n Dat is de veiligste manier om taken in Microsoft Project gelijkmatig te verdelen zonder de tool toestemming te geven om de deadline te verschuiven.<\/p>\n Om dit in te stellen:<\/p>\n Dit is een eerlijke afweging. Omdat Project de einddatum niet kan verlengen, kan het mogelijk niet elk<\/em> conflict oplossen. Sommige rode pictogrammen blijven mogelijk bestaan na deze bewerking. Dat is geen mislukking; het is de tool die je laat weten dat die conflicten echt niet kunnen worden opgelost zonder meer tijd of meer mensen. En dat is precies de informatie die je nodig had.<\/p>\n De handleiding van Microsoft bij het dialoogvenster \u2018Resource Levelling\u2019<\/a> loopt alle opties in dat venster door voor iedereen die een volledig overzicht wil van wat elk selectievakje precies doet.<\/p>\n Het blindelings oplossen van overtoewijzingen is giswerk. Je wilt eerst het probleem in kaart brengen<\/em>, en het overzicht van het resourcegebruik is precies daarvoor bedoeld.<\/p>\n Ga hiernaar toe via het tabblad \u2018Weergave\u2019 en kies \u2018Bronnengebruik\u2019. Elke bron wordt weergegeven met een overzicht van de toegewezen uren, uitgesplitst per dag. Cellen met overbelasting worden rood weergegeven, waardoor het probleem nu duidelijk zichtbaar wordt: of iemand nu op \u00e9\u00e9n dag 20%<\/strong> overbelast is of een hele week lang met 300%<\/strong> overbelast zit.<\/p>\n Projectmanagers die op zoek zijn naar een oplossing voor het rode persoonspictogram in Project, komen meestal hier terecht, bij \u2018Resource Usage\u2019, omdat hier de overbelasting wordt weergegeven in plaats van alleen de waarschuwing.<\/p>\n Dit is van belang omdat de oplossing afhangt van het patroon. Een piek van \u00e9\u00e9n dag lost zich vaak vanzelf op met een \u2018within-slack\u2019-cyclus. Een aanhoudende overbelasting gedurende weken betekent dat je te weinig personeel hebt, en geen enkele vorm van \u2018levelling\u2019 kan de ontbrekende uren compenseren. In de discussies van de MS Project-community op Reddit over het voorkomen van overtoewijzing van middelen<\/a> wordt ditzelfde punt herhaaldelijk benadrukt: de tool legt de waarheid bloot, maar cre\u00ebert geen capaciteit.<\/p>\n Dit is het onderdeel dat in bijna geen enkele handleiding aan bod komt, en het is de reden waarom mensen bang zijn voor deze functie. Levelen is volledig omkeerbaar.<\/p>\n Als een doorvoer de data naar een ongewenste positie verschuift, ga dan naar het tabblad \u2018Resource\u2019 en klik op \u2018Clear Levelling<\/strong>\u2019. Je kunt dit voor het hele project doen of alleen voor geselecteerde taken. Project verwijdert de toegevoegde uitsteltermijnen en zet de taken terug naar hun posities van v\u00f3\u00f3r de nivellering. Combineer dit met de eerder opgeslagen basislijn en je kunt precies vergelijken wat er is verschoven, waarna je kunt beslissen of je het zo laat, het aanpast of opnieuw begint.<\/p>\n Omdat dit vangnet er is, kun je zonder veel risico experimenteren. Voer een test uit met de standaardinstellingen, bekijk het resultaat, wis het als het je niet bevalt, pas de opties aan en voer de test opnieuw uit. Zo gaat er bij niemand een plan verloren.<\/p>\n Soms is de beste oplossing helemaal niet om de planning aan te passen. Als uit het overzicht van het resourcegebruik blijkt dat iemand al een maand lang met 250%<\/strong> overbelast is, zal spreiding die overbelasting alleen maar over een langere periode uitsmeren, waardoor de deadline in het gedrang komt.<\/p>\nDe veilige eerste stap: alleen binnen Slack een referentiepunt vastleggen<\/h2>\n
\n
De overtoewijzing opsporen voordat je het probleem oplost<\/h2>\n
\n\n
\n \nAanpak<\/th>\n Wat het doet met datums<\/th>\n Omkeerbaar<\/th>\n Het meest geschikt voor<\/th>\n<\/tr>\n<\/thead>\n \n Alleen binnen de speling<\/td>\n Voltooiingsdatum beschermd<\/td>\n Ja, via Clear Levelling<\/td>\n Eerste veilige doorloop op een actief plan<\/td>\n<\/tr>\n \n Alles op hetzelfde niveau (standaard)<\/td>\n De einddatum kan vrij worden aangepast<\/td>\n Ja, via \u2018Nivellering wissen\u2019<\/td>\n Ontwerpplannen met flexibele deadlines<\/td>\n<\/tr>\n \n Handmatig slepen van taken<\/td>\n U bepaalt zelf elke wijziging<\/td>\n Alleen handmatig<\/td>\n Kleine conflicten, een handvol taken<\/td>\n<\/tr>\n \n Een hulpbron toevoegen<\/td>\n Geen vertraging, voegt capaciteit toe<\/td>\n N.v.t.<\/td>\n Aanhoudende overbelasting die het schema niet kan opvangen<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n Hoe je het levelen ongedaan kunt maken als het misgaat<\/h2>\n
Wanneer spreiding niet de oplossing is<\/h2>\n