Deel 4 Projecten opvolgen

We bepalen per activiteit de flexibiliteit. Dat noemen we ook de free fl oat of slack. Dat kenmerk bepaalt de flexibiliteit van de activiteit en vertelt ons hoeveel een activiteit (achterwaarts) kan schuiven of kan wachten zonder de doorlooptijd van ons project te beïnvloeden. Slack is het verschil tussen ES en LS (of EF en LF).

3 We zoeken de activiteiten waarvan de slack gelijk is aan 0.

Op basis van CPM weten we nu dat de minimale doorlooptijd van het project 24 dagen zal zijn. Sneller is niet mogelijk op basis van onze (realistische en betrouwbare) inschatting. We zien ook dat activiteit B een flexibiliteit heeft van vier dagen. Die activiteit kan met andere woorden vier dagen verschuiven of wachten alvorens ze de opleverdatum van het project beïnvloedt.

Wanneer we de projecttijdlijn en het kritieke pad voorleggen aan en laten valideren door de stuurgroep, hebben we onze schedule baseline bepaald. Die baseline met betrekking tot time blijft dan het referentiepunt door het volledige project heen. Aanpassen kan in principe enkel na goedkeuring van een change request.

8 Tijdlijn optimaliseren: wat als het sneller moet?

De doorlooptijd van het project bepalen volgens de regels van de kunst kan soms tot onverwachte of onverhoopte resultaten leiden. Vaak heeft de klant of de projectmanager andere oplevertermijnen in gedachten. Deze paragraaf wil enkele technieken aanreiken die toelaten het schedule nog te verfijnen of te optimaliseren. Desalniettemin moet het duidelijk zijn dat ook aan die optimalisatie grenzen verbonden zijn.

Om het schedule te optimaliseren moeten we een onderscheid maken tussen twee situaties: het project heeft resourcebeperkingen of het project dient rekening te houden met tijdsbeperkingen. Dat zijn twee volledig gescheiden situaties. We kunnen in realiteit nooit een project optimaliseren voor beide constraints

Als we de berekende tijdlijn moeten herbekijken vanwege beperkte resources, dan leidt dat tot een langere doorlooptijd. Het kritieke pad wordt met andere woorden verlengd. De meest toegepaste techniek om het gebruik en de benutting van resources te optimaliseren is resource leveling. Die techniek houdt rekening met het inzetten van mensen die op meerdere projecten werken, resources die slechts een beperkte opdracht hebben op het project of resources die cruciaal zijn voor het welslagen van het project. We moeten de vraag naar resources vanuit het project afstemmen op die beschikbaarheid.

Als de doorlooptijd ingekort moet worden, spreken we over een time constraint scenario. De technieken die we kunnen aanwenden, trachten de tijdlijn te comprimeren. In het Engels spreekt men over schedule compression. Twee technieken worden vaak toegepast: fast tracking en crashing. Op grote projecten met complexe schedules gebeurt het vaak dat beide technieken toegepast worden, al dan niet cumulatief.

Bij fast tracking trachten we activiteiten waar mogelijk parallel uit te voeren. Veelal kan dat jammer genoeg niet vanwege de belangrijke afhankelijkheden. Als parallel werken wel mogelijk is, kan dat positieve effecten hebben op de doorlooptijd van het project. Er dient echter wel altijd rekening gehouden te worden met een verhoogd risico op rework. Bij IT-projecten zien we dat vaak al gestart wordt met het ontwikkelen van een programma alvorens de technische specificatie afgewerkt of gevalideerd is. Als de draft waarop de ontwikkeling gebaseerd is, nog significant wijzigde in tussentijd, kan het nodig zijn om de programmatie opnieuw te starten. Dat toont een gekend risico van fast tracking.

Bij activity crashing trachten we de doorlooptijd van het project in te korten door via bijkomende investeringen de doorlooptijd van individuele activiteiten in te korten. Het spreekt voor zich dat we ons bij crashing enkel richten op kritieke activiteiten. Die bepalen namelijk de minimale doorlooptijd.

Door deze oefening heen is het van het grootste belang om continu het kritieke pad te herevalueren. Dat kan immers wijzigen door het inkorten van activiteiten. Op dat moment dienen we ons te richten op de ‘nieuwe’ critical activities

Deel 4 Projecten opvolgen

Voorbeelden

Crashing technieken

– Vragen aan medewerkers om overuren te presteren. De extra kost of toeslag voor die overuren is in dit voorbeeld de crash cost.

– Incentive of motivatiepremies voorzien wanneer deliverables sneller opgeleverd worden.

– Aanwerven van bijkomende resources, bovenop de voorziene staffing in het projectmanagementplan.

– Kiezen voor SaaS-oplossingen die ervoor zorgen dat de installatie out-of-the-box kan gebeuren in plaats van configuratie from scratch.