Algemeen
Tijdsplanningtechnieken worden gebruikt om planningen te ontwikkelen en te presenteren die laten zien wanneer werkzaamheden zullen worden uitgevoerd en producten opgeleverd. De doelen van de tijdsplanning zijn om:
- een model te maken voor gebruik bij numerieke analyse;
- datums te berekenen voor onderdelen van het werk;
- te bepalen waar flexibiliteit in de planning zit.
De tijdsplanningprocedure bestaat uit drie stappen.
Zodra de werkzaamheden geïdentificeerd zijn, wordt een model gemaakt dat de volgorde van de werkzaamheden en de tijd die nodig is om elk onderdeel te voltooien weerspiegelt. Dit "logische model" moet worden aangevuld met externe beperkingen, zoals externe besluiten (bv. een wettelijke goedkeuring of de levering van een aangeschaft onderdeel). Zodra het model de interne logica van de werkzaamheden en de externe beperkingen weerspiegelt, wordt de planning berekend.
In werkelijkheid zijn deze stappen geenszins opeenvolgend. Het model zal worden aangepast, beperkingen zullen worden herbeoordeeld en de berekening zal worden herhaald om tot een optimale planning te komen.
De beschikbare technieken voor het modelleren, plannen en rapporteren van de werkzaamheden in een project, programma of portfolio zijn zeer breed. De juiste keuze van techniek hangt af van de context en hoeveel informatie beschikbaar is op het moment dat de planning wordt uitgevoerd. Factoren die van invloed zijn op de keuze van de techniek omvatten bijvoorbeeld of de:
- planning plaatsvindt in de identificatie- of leveringsfase van de levenscyclus;
- omvang van de werkzaamheden goed gedefinieerd of flexibel is (traditionele versus agile benaderingen);
- planning een samenvatting van andere planningen representeert;
- producten gericht zijn op leden van het leveringsteam of op externe stakeholders;
- werkzaamheden per definitie innovatief of onzeker is.
Het gebruik van planningsmethodes die niet geschikt zijn voor de behoeften van het project, programma of portfolio kan aanzienlijke problemen veroorzaken. Een al te complexe aanpak is net zo slecht als een (te) simplistische aanpak, dus we moeten ervoor zorgen dat de technieken geschikt zijn en correct worden toegepast.
Het meest gebruikelijke mechanisme voor het bouwen van een model is een netwerkschema dat bestaat uit alle onderling verbonden activiteiten die nodig zijn om de doelen te bereiken. Dit is de basis voor het schatten en plannen van steeds toenemende complexiteit. De eenvoudigste vorm van het berekenen van een schema is kritieke pad analyse (KPA). KPA berekent begin- en einddata voor alle activiteiten in het netwerk. Sommige activiteiten zullen flexibel zijn (door speling) en andere niet. De opeenvolging van activiteiten die geen speling hebben wordt het kritieke pad genoemd - vandaar de naam.
De KPA vertoont twee belangrijke tekortkomingen. In de eerste plaats wordt geen rekening gehouden met de gevolgen voor het plannen van de beperkte resources. Dit wordt geadresseerd door verdere analyse in de resourceplanning. Ten tweede, het veronderstelt één schatting van de tijd die nodig is om elke activiteit uit te voeren. Schatten is een onnauwkeurige wetenschap en het is veel realistischer om een reeks duurramingen te gebruiken in plaats van een schatting op één punt. Dit leidt tot statistische technieken zoals PERT of Monte Carlo.
Ongeacht de techniek die wordt gebruikt om datums van activiteiten te berekenen, worden de resultaten meestal weergegeven in de vorm van een staafdiagram dat bekend staat als een Gantt chart.
Het grote voordeel van het netwerkschema is dat het vaak met nieuwe informatie snel kan worden bijgewerkt en herberekend. Dit is een continu proces gedurende de hele levenscyclus en maakt gebruik van informatie over de werkelijke voortgang om de uiteindelijke voltooiing van de werkzaamheden te voorspellen.
Bij de activiteiten in het netwerkschema kunnen zowel kosten als looptijden zijn toegerekend. Een techniek die het effect van zowel tijd als kosten combineert als onderdeel van projectbeheersing is earned value management. Deze meet de voortgang in termen van geleverde waarde in plaats van de verstreken tijd en wordt gebruikt om nauwkeuriger voorspellingen te doen over toekomstige voortgang en voltooiing op basis van de voortgang tot nu toe.
Projecten, programma's en portfolio's
Netwerkdiagrammen zijn meer geschikt voor projecten dan voor programma's, maar ook hier zijn ze niet altijd de beste aanpak. Netwerkschema's worden bij voorkeur toegepast in een traditioneel project met een specificatie voor een uniek product. Twee voorbeelden van situaties waarin ze niet worden gebruikt zijn:
projecten die meerdere repetitieve producten produceren, bijvoorbeeld een project voor de nieuwbouw van een woonwijk. In dit geval kan een techniek als line of balance geschikter zijn;
agile projecten waarbij de prestaties van activiteiten veel vloeiender zijn en er geen volledige specificatie beschikbaar is om in het definitieproces te modelleren. Agile projecten richten zich meer op technieken als timeboxen en MoSCoW.
De meeste tijdsplanning wordt uitgevoerd met behulp van gespecialiseerde softwarepakketten. Hoewel deze pakketten de mogelijkheid bieden om geavanceerde modellen van een project te bouwen en te analyseren, bieden ze ook de capaciteit om zeer grote modellen te bouwen. Naarmate projecten groter en complexer worden, is de verleiding groot om steeds grotere modellen te bouwen, omdat de analyse door de huidige rekenkracht vrijwel onmiddellijk plaatsvindt.
De kunst van het P3-management is echter om inzicht te hebben in oorzaak en gevolg van de werkzaamheden die worden gemanaged. Hoe groter en verfijnder het model, hoe moeilijker het voor een manager is om een goed gevoel te hebben voor oorzaak en gevolg bij het nemen van beslissingen. Gevoeligheidsanalyse kan nuttig zijn bij het beoordelen van het effect van verschillende factoren op de planning.
Het creëren van één homogeen model voor een programma is zelden succesvol. Programma's en grotere projecten, moeten meerdere planningen maken die gekoppeld kunnen worden door een paar belangrijke mijlpalen of gerangschikt als een hiërarchie. Idealiter zal deze reeks van onderling verbonden planningen de organisatiestructuur tot op zekere hoogte weerspiegelen, zodat individuen de werkzaamheden kunnen plannen waarvoor ze verantwoordelijk zijn zonder dat hun planning voortdurend en automatisch wordt veranderd door bijstelling van een planning van iemand anders.
Deze planningen werken natuurlijk niet geïsoleerd en er moet rekening worden gehouden met de onderlinge afhankelijkheid. Dit is waar specialisten op het gebied van planning tot hun recht komen, wellicht als onderdeel van een afdeling ondersteuning. Deze specialisten kunnen de invloed van de ene planning op de andere inschatten en de implicaties voor het managementteam interpreteren.
De logische onderlinge afhankelijkheid tussen projecten en programma's in een portfolio moet minimaal zijn. Indien er bijvoorbeeld sprake is van significante afhankelijkheden tussen twee of meer projecten, dient het portfoliomanagementteam na te gaan of deze beter als één project of programma kunnen worden gemanaged.
Met dank aan het BPUG-team voor de vertaling naar het Nederlands
