Hoe kan ik een realistische prijs bepalen voor mijn initiatief? #inschatten

1 Inleiding en leerdoel

Om projecten onder controle te houden en de verwachtingen voor de organisatie kenbaar te maken, is een goede inschatting van het werk, en dus de doorlooptijd en de kost, essentieel. Als het project extern in de markt wordt gezet of je wenst als implementator een RFP te beantwoorden, dan zal het eveneens belangrijk zijn goed in te schatten hoeveel tijd en geld je nodig zult hebben om het project volgens de doelstellingen te realiseren.

Projecten inschatten kan op verschillende niveaus gebeuren: van heel oppervlakkig bij gebrek aan tijd of informatie tot erg nauwkeurig, bijvoorbeeld tijdens een commerciële onderhandeling. Los van de situatie wensen we met dit hoofdstuk een aantal principes en hulpmiddelen mee te geven die het inschatten kunnen ondersteunen en vooral de betrouwbaarheid verhogen.

Dit hoofdstuk zal de nadruk leggen op het inschatten van (doorloop)tijd van de activiteiten en het project. We zullen uiteindelijk kunnen aangeven wat de verwachte, minimale doorlooptijd is van ons project. Alles wat in dit hoofdstuk wordt toegelicht, kan ook integraal gebruikt worden om de kost van het project te berekenen. Het volstaat dan om de duur van een activiteit om te rekenen in de kost van die activiteit (bv. aantal dagen x prijs per dag van de consultant) en materiaalkosten in rekening te brengen.

Op het einde van dit hoofdstuk:

… ken ik de verschillende stappen die ik moet doorlopen om een betrouwbare schatting op te maken;

… ben ik vertrouwd met de voornaamste technieken om mijn project goed in te schatten;

… ben ik in staat mijn schatting te evalueren en onzekerheid op te vangen;

… kan ik de klant correct informeren over de verwachte doorlooptijd en de prijs van zijn project.

2 Projectbaseline

Wanneer we het project vanuit een tijdsperspectief analyseren, trachten we de schedule baseline op te maken. Die baseline geeft aan wanneer in de tijd bepaalde activiteiten starten en eindigen. Verder vertelt de schedule baseline ons ook wat de minimale doorlooptijd van het project is.

Om tot de schedule baseline te komen, doorlopen we achtereenvolgens vijf stappen. Die stappen correct doorlopen, in de juiste volgorde en met de juiste tools, laat ons toe een realistische en eerlijke inschatting te maken van de doorlooptijd van het project. De schatting dient eerlijk en haalbaar te zijn omdat we enkel op die manier faire en realistische verwachtingen kunnen scheppen ten opzichte van onze klant en/of sponsor.

Om de doorlooptijd van een project goed in te schatten, is er één voorname input noodzakelijk: de scopebeschrijving. Daarom is het erg belangrijk om de activiteiten zoals beschreven in bijvoorbeeld het hoofdstuk ‘Hoe plannen we de verschillende activiteiten in? #planning’ goed te doorlopen. Dan heb je in principe een WBS in handen of een deliverableoverzicht waarop de schatting kan steunen.

Volgende figuur toont de verschillende stappen die we doorlopen om tot de projecttijdlijn te komen. De paragrafen erna zullen elke stap uitdiepen.

Figuur 1 Stappenplan voor een eerlijke en realistische tijdlijn.

Definieer activiteiten

Activiteitenlijst

Bepaal volgorde

Netwerkdiagram

Schat resources

RBS resourcenoden

Schat doorlooptijd

Geschatte doorlooptijden

Finaliseer tijdslijn

Schedule baseline

Project schedule

Alvorens we de verschillende stappen doorlopen, willen we enkele aandachtspunten meegeven. Eerst en vooral moet men de planningsoefening met een open geest aanvatten. Uiteraard oefent het management druk uit om een bepaalde opleverdatum te halen, maar het is de planningsoefening die aantoont wat mogelijk is. Het objectief van die oefening is dus niet om het management of de sponsor te behagen. Op het einde van dit hoofdstuk reiken we een aantal technieken aan die toelaten om de tijdlijn te optimaliseren.

De sterkte van de uitgewerkte tijdlijn wordt bepaald door de mensen die ertoe hebben bijgedragen. – We raden aan een tijdlijn in groep op te stellen. Enkel op die manier kunnen een te conservatieve of te ambitieuze aanpak worden vermeden. – Ervaring is belangrijk: we raden aan zeker enkele ervaren mensen mee te laten werken aan de schatting.

– Blijf kritisch: we raden aan reviews in te plannen, tijdens de initiële inschatting, maar ook tijdens het uitvoeren van het project. Omstandigheden kunnen veranderen en je kunt lessen trekken uit je projectwerk. Daardoor dien je mogelijk je schatting te herzien.

We merken op dat de beschreven approach de scope in zijn geheel afdekt. Er zijn ook andere methodologieën, zoals een agile of SCRUM-aanpak, waarbij men er bewust voor kiest om de uitvoering in kleinere stukken te knippen. In het deel ‘Ontwikkelstrategieën’ komen we daarop terug. Maar zelfs in dynamischere manieren van werken blijft het accuraat inschatten van de doorlooptijd, het werk en de kost relevant.

Hoofdstuk 15 Hoe kan ik een realistische prijs bepalen voor mijn initiatief? #inschatten

We leggen in de volgende paragrafen de verschillende stappen verder uit. Hoewel het kan lijken dat elke stap mooi na elkaar en 100 % gescheiden van elkaar dient te gebeuren, is dat in de praktijk veelal niet het geval. Eens de stappen voldoende gekend en begrepen zijn, zullen die vaak gecombineerd worden doorlopen op een erg efficiënte manier.

3 Stap 1: definieer de activiteiten

Voor het defi niëren van de activiteiten volgen we dezelfde aanpak die we bij het uitwerken van de WBS gevolgd hebben. We splitsen de deliverables verder op in werkpakketten, waarna we die werkpakketten verder verfijnen tot in te plannen activiteiten. De indicatie ‘in te plannen’ is daarbij belangrijk.

Het is het projectmanagementteam of het team dat de planning uitwerkt en dat bepaalt tot op welk niveau van detail we de activiteiten moeten opsplitsen om ze te kunnen inschatten. Hier weegt het projectteam eigenlijk af hoe accuraat de schatting zal moeten zijn en hoeveel tijd ze wensen te investeren in het schattingsproces. Als het projectteam bijvoorbeeld veel ervaring heeft en veel informatie heeft over de deliverables, kan ervoor worden gekozen om de schatting te maken op deliverableniveau en niet verder op te splitsen.

Volgende figuur toont de relatie tussen de verschillende management- of planningsniveaus in die oefening. Men dient daarbij de 1-op-N-relatie in het achterhoofd te houden: een deliverable kan meerdere werkpakketten bevatten en elk werkpakket kan bestaan uit meerdere activiteiten. Die relatie toont duidelijk het principe van decomposition dat we hier volgen.

werkpakketten en activiteiten.

Het resultaat van deze uitsplitsing is de activiteitenlijst. Die lijst bevat naast alle uit te voeren en in te plannen activiteiten ook heel wat attributen van die activiteiten. Die attributen moeten ons helpen de verdere stappen van de planning te kunnen zetten. Typische voorbeelden zijn deadlines die we nu al kennen, belangrijke resources die we nodig zullen hebben voor deze activiteit, afhankelijkheden tussen deze en de andere activiteiten, inschatting van de complexiteit van de activiteit enz. Een bijna identieke lijst van attributen heb je ook op deliverableniveau opgemaakt bij het beschrijven van de scope van je project.

4 Stap 2: bepaal de volgorde van de activiteiten

In deze stap trachten we de geïdentificeerde activiteiten in de juiste volgorde te plaatsen. Dat vraagt vooral logisch inzicht in de afhankelijkheden van de activiteiten. Om deze stap uit te voeren kunnen we gebruik maken van drie relevante technieken.

4.1 Precedence diagramming-methode (PDM)

Op basis van deze techniek koppelen we de activiteiten grafi sch aan elkaar. De meest gehanteerde weergave is de activity-on-node (AoN)-weergave. Daarbij worden de activiteiten als knooppunten, veelal in de vorm van een cirkel, afgebeeld. Volgende figuur toont een voorbeeld.

Figuur 3 Weergave van de logische relatie tussen activiteiten volgens de AoN-techniek.

Naast de geïdentificeerde activiteiten voegen we ook altijd een startpunt (S) en eindpunt (E) toe aan het schema.

PDM maakt niet enkel de volgorde schematisch leesbaar, het helpt ons ook om de logische relatie op zich tussen de activiteiten te beschrijven. We onderscheiden vier mogelijke relaties. Volgende tabel geeft de opties weer, samen met een praktisch voorbeeld.

Tabel 1 Overzicht van de afhankelijkheden volgens de PDM-methode.

Finish-to-start (FS) De opvolger kan pas starten indien de voorganger beëindigd is.

Finish-to-finish (FF) De opvolger kan pas eindigen indien de voorganger beëindigd is.

Start-to-start (SS) De opvolger kan pas starten indien de voorganger gestart is.

Start-to-finish (SF) De opvolger kan pas eindigen indien de voorganger gestart is.

Men kan pas aan de eerste verdieping beginnen bouwen indien het gelijkvloers afgewerkt is.

De developmentcyclus wordt pas afgesloten indien ook de unittesting uitgevoerd is.

We kunnen pas starten met het formaliseren van de projectveronderstellingen, indien gestart werd met het beschrijven van de projectobjectieven en de projectscope.

De nachtploeg kan enkel stoppen indien de ochtendploeg haar heeft afgelost.

Door het verband tussen twee activiteiten zo te beschrijven, benoemen we de afhankelijkheid. Dat is een logische relatie en geen tijdsgebonden relatie. We richten ons dus op de oorzaak en het gevolg. Beschrijf de relatie dan ook met de woorden ‘indien’ en vermijd de woorden ‘wanneer’ of ‘als … dan …’.

4.2 Bepalen van afhankelijkheden

Het kan nodig of nuttig zijn te kijken naar de afhankelijkheden tussen activiteiten. Vaak zijn ze vooraf bepaald of extern vastgelegd. We maken een onderscheid tussen verplichte afhankelijkheden en voorkeurs afhankelijkheden. Het eerste type noemen we ook hard logic, terwijl het tweede type in de praktijk soft logic genoemd wordt. Verplichte afhankelijkheden kunnen niet genegeerd worden.

Het gaat hier vaak om contractuele of wettelijke voorschriften. Ook fysieke afhankelijkheden vallen in deze categorie.

Een klassiek voorbeeld van hard logic is het bouwen en oprichten van steunpilaren voor een brug. Dat dient te gebeuren alvorens de brug zelf kan worden geplaatst. Een ander praktijkvoorbeeld is een contractuele afspraak die aanleiding geeft tot het lanceren van een IT-project. Zo werden nieuwe energieleveranciers bij een grote Belgische bank verplicht om hun facturen elektronisch te verzenden. Voorkeursafhankelijkheden baseren zich op best practices. Als ervaring of expertise een bepaalde afhankelijkheid als beter beschouwt, bevelen we ook aan die te integreren in de tijdlijn. Het vinden van die afhankelijkheden onderstreept het belang van groepswerk. Ervaring kan bijvoorbeeld leren dat de kwaliteit van de functionele of technische specificaties niet toelaat om al parallel te starten met het ontwikkelen van een IT-programma. Die afhankelijkheid duidt erop dat beide activiteiten (het uitschrijven van een specificatie enerzijds en programmeren anderzijds) het best na elkaar gebeuren. Op die manier vermijden we dat we achteraf moeten herwerken vanwege de lage kwaliteit van de specificaties.

Naast bovenstaande afhankelijkheden kunnen we nog een andere classificatie volgen. We kunnen afhankelijkheden opdelen in interne en externe afhankelijkheden. Interne afhankelijkheden liggen binnen de controle van het projectteam, terwijl dat projectteam weinig of geen vat heeft op externe afhankelijkheden.

Afhankelijkheden moeten opgenomen worden als attribuut in de activiteitenlijst. Die lijst is de output van de vorige stap in het proces.

We merken wel op dat de keuze van de ontwikkelstrategie de afhankelijkheden kan beïnvloeden. In iteratieve methodes werken we niet noodzakelijk alle activiteiten achter elkaar af (zie het deel ‘Ontwikkelstrategieën’).

5 Stap 3: bepaal de resourcenoden

De doorlooptijd van activiteiten wordt sterk bepaald door het type resources dat ze zal uitvoeren. Daarom proberen we die resources in te schatten voor we verder gaan in het proces. Het schattingsteam dient in het achterhoofd te houden dat resources niet alleen betrekking hebben op mensen, maar ook op materialen en goederen. De behoeften van die laatste categorie zullen impact hebben op het bestel- en leveringsproces. Die processen hebben vaak een doorlooptijd die bepalend is voor de totale doorlooptijd van het project.

VOORBEELD

Er moet IT-hardware aangekocht worden voor het project. De lever- en installatietermijn kan oplopen tot tien of vijftien weken.

Het bepalen van de behoefte en het uitsturen van de bestelbon naar de leverancier wil dus niet zeggen dat er geen andere afhankelijkheden of doorlooptijden in rekening gebracht moeten worden. Dat onderstreept het belang van het in kaart brengen van resourcenoden, bijvoorbeeld IT-hardware.

Het is belangrijk te begrijpen dat we in deze stap nog niet bepalen wie een activiteit zal uitvoeren, maar enkel willen bepalen welk profiel, welke skills en welke ervaring vereist zijn om de activiteit zo efficiënt mogelijk uit te voeren.

6 Stap 4: schat de doorlooptijd van de activiteiten

Terwijl we in de vorige stappen de puzzelstukjes hebben verzameld, kunnen we in stap 4 starten met de echte uitwerking van de tijdlijn. Eerst en vooral dient de doorlooptijd van de activiteiten individueel geschat te worden. Het is onze betrachting om een zo realistisch mogelijke inschatting te maken.

Los van de technieken die we hieronder zullen aanreiken, bestaan er ook twee generieke schattingstechnieken die algemeen aanvaard zijn, namelijk de top-down - en de bottom-upinschatting. Bottomup inschatten duidt erop dat je vanuit de details van het project begint in te schatten. Door alle details te benoemen en in te schatten zal die techniek uiteraard meer tijd vragen maar wel erg accuraat zijn. Bij een top-downschatting begin je van het eindproduct en splits je het werk (beperkt) op tot op een niveau dat je de werklast of de doorlooptijd voldoende kunt inschatten. Het is echter belangrijk te beseffen dat een top-downinschatting veel minder accuraat zal gebeuren dan de technieken die we zullen bespreken. Een top-downinschatting is enkel wenselijk als er weinig informatie bekend is rond de scope die we dienen in te schatten en als er weinig tijd beschikbaar is om de schatting te maken.

De besproken technieken bieden elk hun toegevoegde waarde. Om de meest betrouwbare schatting te krijgen, kan overwogen worden om technieken te combineren. De gecombineerde aanpak verhoogt op die manier de kwaliteit van de schatting.

6.1 Schattingstechniek: analoge inschatting

De analoge inschattingstechniek baseert zich op gekende historiek en ervaring. Door terug te grijpen naar vorige projecten of vorige inschattingen, kan men tot een realistische schatting komen. Het voordeel van die techniek is de korte doorlooptijd en het gemak qua uitvoering. Jammer genoeg wegen de voordelen amper op tegen de nadelen. Het is namelijk zeer moeilijk relevante projecten te vinden, in een gelijkende omgeving (elke klant is verschillend) en met een gelijkende scope (elk bedrijf heeft specifieke noden). Verder dient ook geëvalueerd te worden welke expertise vereist is om correct te kunnen schatten volgens die methode. Het belang om de juiste mensen aan boord te hebben, speelt hier meer dan ooit.

We zien echter dat die techniek vaak wordt toegepast om een eerste, ruwe inschatting te maken. Dat noemen we dan ook een order of magnitude-inschatting. In een latere fase van het project of eens het project verkocht is, worden dan meer accurate technieken toegepast. Deze techniek heeft zijn waarde wel bewezen in de markt van de packaged IT solutions. Meer en meer hebben software vendors ervoor gekozen om hun product of hun functionaliteiten in pakketten aan te bieden. Die solutions zijn dan eenvoudig te implementeren met een goed beschreven initiële scope. De standaardisatie van die projecten liet toe zich op eerdere schatting te beroepen.

6.2 Schattingstechniek: Delphi-methode

De tweede techniek grijpt terug naar het orakel van Delphi. De oude Grieken kwamen bij dat orakel raad vragen aan verschillende wijzen of goden. De Delphi-methode gebruikt op haar beurt de input van meerdere schatters. Hoewel meerdere personen dezelfde activiteiten inschatten, doen ze dat onafhankelijk van elkaar. Dat is een belangrijke randvoorwaarde. Het basisprincipe is dat we door terug te vallen op meerdere inschattingen de verschillen en de onzekerheid nog beter opvangen.

Een tweede belangrijke voorwaarde opdat die techniek goed zou werken, is dat vooraf duidelijke afspraken worden gemaakt. Deze rules of engagement stellen onder andere het volgende: hoeveel schatters er zullen aangesproken worden (in de praktijk minimaal drie);

– wat de termijnen zijn waaraan de schatters zich moeten houden; welke input elke schatter zal krijgen (altijd voor iedereen identiek);

– dat de schattingen onafhankelijk van elkaar dienen te gebeuren; wat de maximale afwijkingen zijn ten opzichte van de mediaan of gemiddelde schatting.

Verdeling van

- scope-informatie

- schattingsmodel

Individueel assessment

Publicatie Inschatting

Evaluatie ok

Consolidatie en evaluatie

Bovenstaande figuur toont de gehele oefening. Bovenstaande randvoorwaarden zijn vervat in het schema. Als na het verzamelen van de input blijkt dat de verschillende schattingen buiten de toegelaten grenzen liggen, dient de verantwoordelijke actie te ondernemen. Veelal worden alle schatters samengeroepen om de scope en input samen te doorlopen opdat iedereen hetzelfde begrip heeft van het project. Die cyclus wordt herhaald totdat de schattingen voldoen aan de gestelde voorwaarden.

6.3 Schattingstechniek: formules inschakelen

Voor veel projecten is het werk vergelijkbaar of op te splitsen in bijna identieke blokjes die zich herhalen. Die blokjes kun je dan eenvoudig in een formule steken. We spreken over een parameterinschatting.

Voorbeeld

Tijdens ons project moeten we drie groepen medewerkers opleiden. Elke groep dient drie opleidingen te doorlopen:

– deel 1 duurt een halve dag en omvat de nieuwe processen; deel 2 duurt 2 dagen en omvat de nieuwe schermen in de applicatie;

– deel 3 duurt een halve dag en bespreekt de impact voor de klant; elk deel vraagt een halve dag voorbereiding.

Om deze deliverable ‘training’ in te schatten, helpt een eenvoudige berekening:

Doorlooptijd = (voorbereidingstijd van alle delen samen) + (opleidingstijd x aantal groepen) = (3 delen x 0,5 dag voorbereiding) + (3 groepen x (0,5 + 2 + 0,5 opleidingstijd) = 1,5 dag + 9 dagen = 10,5 dagen

We schatten dat we voor de opleiding van de drie groepen binnen het project 10,5 dagen werk zullen presteren.

6.4 Schattingstechniek: T-shirt sizing

Als het kennisniveau in het team hoog is, wordt vaak gebruikgemaakt van de ‘T-shirt sizing’-techniek. Die techniek is nuttig als er een groot aantal soortgelijke deliverables moet worden ingeschat. Het wordt vaak toegepast bij de opmaak van offertes.

Nadat de lijst van deliverables is opgemaakt, doen we twee stappen:

1. het team gaat de deliverables indelen in 3 groepen: small, medium en large;

2. het team bepaalt de geschatte workload per groep.

VOORBEELD

Voor ons project moeten we 5 interfaces bouwen tussen het ERP-pakket en andere applicaties. We wensen de ‘T-shirt sizing’- techniek te gebruiken om snel een inzicht te krijgen in de workload. Voor een ‘small’ interface rekenen we 2 dagen, voor een ‘medium’ interface rekenen we 5 dagen en voor een ‘large’ interface voorzien we 12 dagen.

Via deze techniek leren we dat we in totaal 26 dagen werk voorzien voor de gevraagde 5 interfaces.

6.5 Schattingstechniek: planningspoker

Omdat de voorgaande technieken altijd vertrekken vanuit de details van een deliverable, noemen we ze bottom-up schattingen. Tegenwoordig wenst men vaak minder tijd te verliezen aan discussies over schattingen en vliegt men de schatting eerder top-down aan of op een hoger niveau (deliverable of groep van deliverables). Om het schattingsproces te versnellen, maakt men gebruik van puntenschattingen in plaats van tijdschattingen. Een gekende techniek luistert naar de naam planningspoker en wordt vaak toegepast in agile werkomgevingen.

Welke principes volgt men hier:

1. De product owner licht het team voldoende in over de gewenste features en functions.

2. Het team spreekt af hoeveel punten ze willen afwerken per sprint. Dat betekent ook dat ze onderling afspreken wat de echte betekenis van een punt is (bv.: complexiteit, technologie, programmeertaal, geschat aantal lijnen code, …).

3. Elk teamlid krijgt een beperkt aantal kaarten met punten op.

4. Voor elke deliverable wordt gevraagd individueel een kaart te leggen met punten.

5. Als er extreem lage of hoge punten gelegd worden door bepaalde teamleden, worden die besproken.

6. Het team streeft naar vergelijkbare puntenkaarten (m.a.w. elk teamlid schat de deliverable ongeveer even zwaar in) en probeert tot een overeenstemming te komen.

7. De persoon die de sessie leidt, houdt de globale score bij totdat het maximaal aantal sprintpunten is bereikt.

Deze techniek leunt sterk aan bij de Delphi-methode die we eerder bespraken. Het grootste onderscheid is dat we hier niet werken met een tijdsinschatting maar met een punteninschatting. Omdat we ook werken met een beperkt aantal kaarten, zal er in principe veel sneller overeenstemming worden bereikt. Op die manier kan het tempo van de uitvoering voldoende hoog worden gehouden. Net zoals bij de Delphi-methode wordt de kwaliteit van deze techniek erg bepaald door de ervaring van de deelnemers.

6.6 Inschatting afwerken: hoe zeker zijn we?

Het is belangrijk dat alle voorgaande schattingsstappen enkel leiden tot nettoinschattingen. Er dient dus duidelijk aan elke schatter meegegeven te worden dat hij enkel dient te kijken naar het effectieve werk dat er nodig is om een activiteit uit te voeren, zonder rekening te houden met de omgeving, de oplossing, onzekerheden enz.

Pas op het einde bekijkt de verantwoordelijke hoe bijkomende marge kan worden toegevoegd aan de schattingen. Er zal dan pas bekeken worden of die bijkomende tijd een plaats krijgt op het niveau van de activiteiten of op het niveau van het project in zijn geheel. De buffer die we in deze fase bijrekenen, noemen we contingency.

Er bestaan amper richtlijnen met betrekking tot het bepalen van de bijkomende marge. We kunnen echter wel oplijsten waarvoor we bijkomende tijd moeten voorzien.

Situatie- of klantfactoren: Elke sector is specifiek en dat kan een invloed hebben op de benodigde tijd om taken uit te voeren.

Voorbeelden

• Men moet weten dat in de financiële sector of in de chemische sector vanuit risicomanagementperspectief alles in detail getest moet worden. Die bijkomende testactiviteiten en die focus op volledigheid moeten in rekening gebracht worden.

• In de distributiesector telt elke euro dubbel. Daarom is het zeer moeilijk om bijkomende budgetten vrij te maken na de goedkeuring. Bijgevolg dient de initiële schatting zo correct mogelijk te zijn en voldoende ademruimte te voorzien.

• Tegenwoordig zijn digitale initiatieven vaak gebaseerd op ideeën en werken we vaak met pilootprojectjes (‘eerste snelle implementatie om te beoordelen’). Aangezien er in die context veelal weinig vooronderzoek gebeurt en er heel wat onbekenden zijn, is het raadzaam enige buffer te voorzien qua doorlooptijd en budget. De ‘piloot’ moet namelijk voldoende betrouwbaar en volledig zijn om er iets van te kunnen leren en de volgende stappen te bepalen.

– Oplossingsfactoren: twee parameters spelen daarbij een rol, namelijk de kennis van de te implementeren oplossing en de kennis van de op te leveren scope.

Voorbeelden

• Als men kiest voor een nieuwe technologie waarin men geen ervaring heeft, kan men ervoor opteren om een bijkomende buffer te voorzien om een realistische schatting te bereiken.

• Als de scope amper beschreven is, is de kans groot dat men door het project heen bijkomende vragen zal krijgen of dat gemaakte veronderstellingen niet meer overeind blijven. Bijgevolg kan men op basis van het detailniveau van de scope beslissen om bijkomende marge in te bouwen.

– Contingency:

• Op projectniveau dient zonder twijfel buffer voorzien te worden om de onzekerheid af te dekken waarin het project zal uitgevoerd worden. Het project zal geconfronteerd worden met risico’s die geaccepteerd moeten worden. Om die risico’s in te perken, spreken we de contingency aan op ons project. Die contingency moeten we in deze stap voorzien. Het is dan ook verstandig om daarvoor tijd, en dus budget, te voorzien. Die voorziening dekt wat we de known unknowns noemen af. Het extra budget valt onder de bevoegdheid van de projectmanager.

• Het management zal in principe ook marge willen voorzien voor echt onvoorziene gebeurtenissen. Dat beperkte budget valt buiten de bevoegdheid van de projectmanager en dekt de unknown unknowns af. In het geval van een commerciële relatie is dat bijvoorbeeld het onderhandelingsbudget waarmee de verkoper kan negotiëren. Die eventuele marge kan ook aangewend worden voor bijkomende vragen die de klant zou stellen en waar de partner een commerciële geste wil doen.

7 Stap 5: ontwikkel de projecttijdlijn

De laatste stap die we uitvoeren is het combineren van alle voorbereidingen en het tekenen van de projecttijdlijn. We baseren ons voor het bepalen van de projecttijdlijn op de critical path method (CPM) als techniek. We bepalen daarmee wat de minimale doorlooptijd van het project is.

De minimale doorlooptijd van het project wordt bepaald door kritieke activiteiten. Dat zijn activiteiten die niet kunnen verschuiven zonder de doorlooptijd van het project (negatief) te beïnvloeden. Al die kritieke activiteiten samen noemen we het kritieke pad (critical path) van het project.

In het deel ‘Projecten opleveren’ hebben we projectteamleden al vertrouwd gemaakt met dit principe. Er werd in het hoofdstuk ‘Hoe plannen we de verschillende activiteiten in? #planning’ een aanpak voorgesteld die kan toegepast worden op eenvoudige schema’s. Als projectmanager willen we echter een oplossing aanreiken die eveneens voor moeilijke diagrammen gehanteerd kan worden.

Om het kritieke pad van het project te vinden, dienen we enkele attributen van elke activiteit te bepalen. Onderstaande activity box toont die kenmerken.

De relevante Engelse termen zijn:

– earliest start (ES) = vroegste start; earliest finish (EF) = vroegste einde;

– latest start (LS) = laatste start; latest finish (LF) = laatste einde.

Het volstaat vervolgens om vier eenvoudige stappen te doorlopen zodra ons netwerkdiagram getekend is, namelijk:

1 We maken een forward pass door het netwerk en bepalen de vroegste start- en einddatum van elke activiteit. Daarbij vertrekken we van 0 en tellen altijd de doorlooptijd bij de vroegste startdatum. Als een activiteit meerdere voorgangers heeft (zie E), dient altijd de hoogste waarde genomen te worden als vroegste startdag (19 in dit voorbeeld).

2 We maken een backward pass door het netwerk en bepalen de laatste start- en einddatum voor elke activiteit. We doorlopen het diagram vertrekkende van het eindpunt. Als de activiteit meerdere opvolgers heeft (zie A), nemen we de laagste waarde als laatste einddag (5 in dit voorbeeld)