Technisch document: Track or Treat

Dit artikel maakt deel uit van onze reeks 'Uit de praktijk'. Het bevat een beschrijving van wat de voordelen zijn van het bijhouden van projectwerkzaamheden, de verschillende methoden die daarvoor beschikbaar zijn worden besproken en er wordt een uitleg gegeven van wat het verschil is tussen het bijhouden van tijd en het bijhouden van de voortgang.

Zie ook de andere artikelen uit de reeks Uit de praktijk.

Een griezelige verhaal

Hier in de VS is het Halloween, dus het leek me het juiste moment om het over iets griezeligs te hebben: het bijhouden van onze projecten. Wat? Hoor ik u daar zeggen dat daar niets griezeligs aan is? De gegevens uit het praktijk geven reden om dat te betwijfelen.

Plannen in plaats van managen is nog steeds heel gebruikelijk

In veel bedrijven en organisaties is het nog steeds verbazingwekkend normaal dat er weliswaar formele projectplanningen worden gemaakt, maar dat deze nooit het planningsstadium ontstijgen en nooit worden gebruikt om een project daadwerkelijk bij te houden. Oefen het plannen en als het moet plant u opnieuw. Nergens komt dat zo veel voor als bij softwareontwikkeling. Er is in de softwaresector veel vooruitgang geboekt op het gebied van projectmanagement en toch zijn er nog steeds enorm veel projecten die alleen worden gepland, maar niet worden bijgehouden vergeleken met het aantal projecten dat wordt gepland en vervolgens wel wordt bijgehouden. Behoort u tot de groep die alleen een planning maakt? Wees getroost, u bent niet de enige. En het slechte nieuws is: u bent niet de enige!

Er zijn veel redenen waarom het bijhouden van projecten in bepaalde bedrijfstakken niet populair is. In sommige bedrijfstakken is het bijvoorbeeld heel gewoon om gebruik te maken van medewerkers die zijn gespecialiseerd in het maken van offerten of in het bepalen van de prijs voor een project, of medewerkers die goed zijn in het binnenhalen van projecten of in het maken van ramingen om het basisplan voor het project samen te kunnen stellen. Dit gaat op voor veel verschillende sectoren, maar in de bouw, bij constructiebedrijven, in de ruimtevaart of defensie en bij omvangrijke ontwerp-, inkoop- en constructieprojecten (EPC) is het eerder regel dan uitzondering. Als een offerte is goedgekeurd en het project is binnengehaald, gaat een volledig nieuw team zich bezighouden met het bijhouden en leveren van het project. Bij grote projecten komt het vaak voor dat de mensen die de oorspronkelijke offerte hebben gemaakt zich allang weer bezighouden met andere offerten, omdat de tijd tussen het maken van de raming en het ondertekenen van het contract aanzienlijk kan zijn. Het is mogelijk dat het project dat op dit moment wordt gestart voor hen oud nieuws is. Dat betekent dat degenen die het project managen niet in staat om zijn om het bij te houden aan de hand van het oorspronkelijke plan, omdat de medewerkers die het plan hebben gemaakt evenals de structuur van het plan zelf niet beschikbaar zijn.

Maar de reden die het meest wordt gebruik om een project niet bij te houden, is dat het project zo dynamisch is dat het bijhouden ervan te ingewikkeld is. Sommige projecten veranderen zo snel dat alleen al het volgen van het plan een enorme onderneming is. Als u al uw tijd besteedt aan het bijwerken van het plan, blijft er weinig van uw kostbare tijd over om al het geplande bij te houden.

Dit kan een interessant effect, maar niet noodzakelijkerwijs gunstig effect opleveren. In een omgeving waar de projectmanager steeds maar weer het plan bijwerkt omdat de omstandigheden blijven veranderen, zal het project nooit echt veel te laat zijn, nooit echt het budget overschrijden en nooit echt misgaan. Dat kan ook niet anders, toch? We hebben het plan immers 20 minuten geleden bijgewerkt en we zitten precies op schema met de planning.

Als u in de softwaresector werkt en denkt 'dat klinkt een beetje als Agile', dan hebt u volkomen gelijk. Het idee achter Agile-projectmanagement was bouwen terwijl we ontwerpen en op gezette tijden steeds datgene leveren wat we hebben gemaakt. Onze plannen werden overeenkomstig bijgewerkt en we konden op elk moment zeggen: 'De klant meldt dat het goed genoeg is. Voorlopig kunnen we hier stoppen.'

Dat kan volledig toereikend zijn voor bepaalde vormen van ontwikkelwerk, maar voor ander werk zijn dat wensgedachten. De meeste softwareontwikkelomgevingen hebben met dezelfde beperkingen op het gebied van projectmanagement te maken als elke andere bedrijfstak. Er moeten deadlines worden gehaald, budgetten in acht genomen en overeengekomen lijsten met resultaten worden geleverd. Laten we dat traditioneel projectmanagement noemen. Zelfs in voornamelijk Agile-omgevingen heb ik ervaren dat Agile-management plaatsvindt onder een paraplu van traditioneel projectmanagement.

Ongeacht wat de aanleiding is om alleen maar te plannen, het bijhouden van een project biedt een potentieel aan enorme voordelen. Laten we eens kijken naar het volledige concept van bijhouden.

Wat betekent bijhouden eigenlijk?

U denkt misschien dat er een heel eenduidige definitie bestaat voor het bijhouden van projecten. Dan zit u er naast. Hoe een project moet worden bijgehouden, wordt bepaald door de doelstellingen. Hier volgen een aantal veelvoorkomende methoden voor het bijhouden van projecten:

Een percentage schatten

De teamleider zegt 'We zijn ongeveer op de helft' en we weten dat dit ongeveer 50 procent is van wat er was gepland. Hoewel dit een vorm van bijhouden is en dit veel beter is dan helemaal niet bijhouden, zijn dit geen kwalitatief hoogstaande gegevens. Als uw planning zegt dat u 10 dagen de tijd hebt voor een taak en u meldt dat u bijna 50 procent hebt voltooid, doen projectmanagementprogramma's zoals Microsoft Project en Project Server een aantal aannames voor u. Deze programma’s berekenen dan op basis van de beperkte gegevens die ze hebben dat u tot dusverre vijf dagen werk hebt verricht en nog vijf dagen werk hebt te gaan. Dat kan natuurlijk best zo zijn, maar het zou een verkeerde voorstelling van zaken zijn in een situatie waarin u ongeveer 50 procent werk hebt voltooid, maar het u 20 dagen heeft gekost om op dat punt te komen en dus waarschijnlijk nog 20 dagen werk hebt te gaan.

Meten wat er nog moet gebeuren

Jaren geleden draaide er een zwarte komedie 'The Money Pit' met Tom Hanks in dehoofdrol. In deze film figureerden een aantal aannemers die nooit klaar met hun werk leken te zijn. De grap die steeds terugkeerde in de film was dat het antwoord op de vraag "Wanneer zijn jullie klaar?" steeds "Nog drie weken" was.

Maar het bijhouden van de resterende duur levert kwalitatief veel betere gegevens op dan enkel het schatten van een percentage. Als we ons richten op de resterende duur blijven we scherp gefocust op wat er nog moet gebeuren voordat dit onderdeel klaar is en wanneer het volgende onderdeel, dat van dit onderdeel afhankelijk is, van start kan. Afhankelijk van hoe u uw taken hebt opgezet, kan de resterende duur op twee manieren worden benaderd. De eerste is om het te zien als de resterende duur van de volledige taak. Daar is niets op tegen als we ons niet hebben gefocust op het werk dat nog moet worden gedaan voordat de taak af is. De tweede manier is om ernaar te kijken als de resterende duur of het resterende werk voor elke taak. Dit is een geschikte manier wanneer de taken op basis van de hoeveelheid resources zijn opgesteld. Maar beide manieren zijn een grote sprong voorwaarts in vergelijking met het enkel schatten van een percentage.

Meten hoeveel we hebben besteed

'Ik heb er tot dusverre tien dagen aan besteed', is een manier om naar vooruitgang te kijken. Soms ook wel benodigde inspanning genoemd. Benodigd inspanning is een goede manier om naar de werkelijke burn rate te kijken. Het laat echter niet alles zien. Het goede aan deze methode is dat het ons een heel goed beeld geeft van hoeveel we tot nu toe aan deze taak hebben besteed. Maar de minder goede kant van deze methode is dat we niet goed kunnen beoordelen hoeveel er nog moet gebeuren. Omdat we vanuit ons werk veel met urenstaten werken, krijgen we vaak te maken met organisaties die deze methode willen gaan gebruiken. Ooit dachten onze medewerkers dat deze methode alleen geschikt was als ze samen werd gebruikt met andere, geavanceerdere technieken voor het bijhouden van projecten, maar inmiddels hebben we gezien dat het als opzichzelfstaande methode ook vaak een heel krachtige oplossing is. "Als we maar eens konden zien waar al die tijd naartoe gaat”, zei een klant ooit tegen me. "Dat zou een enorme stap voorwaarts beteken vergeleken met wat we tot nu toe hebben gedaan, we zouden dan bijna onmiddellijk efficiënter worden." En hij had nog gelijk ook. We hebben toen een urenstaat geïmplementeerd waarmee de tijd voor geplande taken kon worden bijgehouden, en alleen al daardoor werden de organisaties enorm veel efficiënter. Later konden ze zelf aanvullende methoden toevoegen voor het bijhouden van taken zodat ze nog beter gingen presteren.

We gaan de huidige margemethode gebruiken

De huidige margemethode is ongeveer 30 jaar geleden ontwikkeld als een manier om zeer complexe projecten te beheren, maar het fundamentele concept ervan is eigenlijk heel eenvoudig. Als we een budget voor een taak maken, kunnen we ongeacht hoeveel tijd we eraan besteden, niet meer dan 100% van het budget verdienen. Huidige margemethode richt zich op het bijhouden van het 'werkelijk' percentage voltooid en dat leent zich heel goed voor sommige typen projecten en minder voor andere. Als we bijvoorbeeld een weg van 100 kilometer moeten aanleggen, dan zijn we half klaar als we bij kilometerpaal 50 zijn aangekomen. Als er op dat punt al 75% van het geld is uitgegeven, hebt u een groot probleem en de huidige margemethode brengt dat duidelijk aan het licht. Dat betekent dat u waarschijnlijk het budget met 50% hebt overschreden op het moment dat de weg klaar is.

Als u onderzoek doet voor een nieuw medicijn of als u software ontwikkelt, levert het meten van het werkelijke voltooiingspercentage mogelijk veel minder exacte resultaten. De gebruikers van de huidige margemethode hebben een hele gereedschapskist vol met allerlei manieren om dit soort voortgang in kaart te brengen, en hiervan heeft de 'gewogen mijlpalenmethode' mijn voorkeur. In een projectmanagementomgeving waar wordt gewerkt met gewogen mijlpalen, definiëren we de belangrijkste mijlpalen van het werk. Als we dan een mijlpaal hebben bereikt, hebben we het percentage verdiend dat de waarde vertegenwoordigt die we van tevoren zijn overeengekomen. Het goede aan deze methode is dat er weinig discussie over hoeft te worden gevoerd. Heb je de mijlpaal bereikt? Ja of nee? Zo niet, dan heb je niets verdiend. Zo ja, dan heb je dat percentage verdiend.

Het project Ivoren sneeuw

Zelfs als u een van deze methoden gebruikt, moet u goed oppassen voor iets wat ik 'ivoren sneeuw'-projecten noem. Deze projecten gaan vrijwel direct naar een status van 99,97% voltooid en daar blijven ze de dan rest van de tijd op hangen.

Hoe worden al die dingen weergegeven?

Ongeacht welk hulpprogramma voor projectmanagement u gebruikt, het weergeven van de voortgang is een redelijk veelvoorkomend element van de projectweergave. Hier zien we een afbeelding van Microsoft Project met een balk die 50% voortgang laat zien:

Gantt-balk met voortgang van 50 procent

Als dat is alles is wat we bijhouden, hebben we ten minste een beetje een idee waar we staan, maar moderne programma’s zoals Project en Project Server hebben zo veel meer te bieden. Als we een basislijn voor het project instellen, kunnen we door te vergelijken niet alleen zien hoe ver een taak is gevorderd, maar kunnen we ook zien hoe de vergelijking uitvalt ten opzichte van de oorspronkelijke planning.

Gantt-balk met basislijn

Hier kunt u zien dat de taak als verwacht 50% gereed is, maar dat deze een week later is gestart. Rechts van de balk zien we dat we al 50% van de tijd hebben verbruikt en (rekening houdend met de weekenden) dat we 50% van de balk hebben opgevuld. Als we werk voor resources hadden ingevoerd, hadden we tot op de dag van vandaag 80 uur werk gehad en 40 uur verbruikt. Dat betekent dat deze taak precies op schema ligt als we er geïsoleerd naar kijken, maar zelfs als de taak vordert in het tempo en met de burn rate die we verwachtten, heeft deze nog steeds een negatief effect op alle eventuele taken verderop in de keten.

Oké, ik houd alles bij. En nu?

Een aantal basisbeginselen hebben we nu besproken. U behoort al tot de bovenste 20% van de vaardige projectmanagers. Echt waar. Dat is al een stuk beter dan de overige 80%. Nu gaan we het hebben over iets fundamenteels dat echter een heel grote invloed kan hebben.

Indien x dan y

Wat ik daarmee bedoel, is dat een resultaatformule nodig is om iets doeltreffend bij te houden: Als x gebeurt, moet actie y worden ondernomen.

Het is een eenvoudige formule, maar een van de moeilijkste om mensen aan te leren. Enkele jaren geleden had ik het voorrecht om met een team gediplomeerde strandwachten te werken. Dit waren getrainde professionals, die dan wel hadden geoefend, maar echt ervaring met iets opdoen konden ze pas op het moment dat iets zich echt voordeed: Hoe zouden de strandwachten reageren in een echte noodsituatie? Militairen in het leger zeggen met een soortgelijke uitdaging te maken te hebben. Je kunt trainen, trainen en nog eens trainen, maar je weet pas zeker hoe iemand reageert als je uit woede met een echt wapen op ze vuurt.

Bij projectmanagement gaat het doorgaans gelukkig niet over leven en dood, maar bij mensen die projecten bijhouden, hebben we te maken met een soortgelijk probleem. Weet de projectmanager wat hij moet doen wanneer het project niet precies volgens schema verloopt? Hier kunt u lang van tevoren al over nadenken. Hebt u een noodbudget voor tijd en/of geld beschikbaar? Is er een hiërarchische structuur zodat iedereen weet bij wie hij of zij moet zijn als ze de autoriteit nodig hebben om actie te ondernemen? Hebt u een communicatieplan zodat iedereen de juiste mensen kan bereiken als het project achterloopt op schema of helemaal niet loopt? En bij welke resultaten moet er actie worden ondernomen? Moet er al aan de bel worden getrokken als er één dag vertraging is? Of een week? En wat als het risico of het projectbereik toeneemt? Door voor dit soort situaties vooraf standaarden in te stellen, worden frustraties later in het project voorkomen.

Bijhouden of niet

Het is niet moeilijk uw organisatie of uw project zo op te zetten dat dingen kunnen worden bijgehouden. Vrijwel elk product voor het managen van projecten beschikt over een functie voor het vastleggen van de voortgang van een project. Deze functie werkt goed als er goed wordt gelet op een bepaald aspect dat in een bedrijfscultuur nog steeds bestaat rondom het bijhouden van projecten, namelijk dat je niet moet schieten op de boodschapper van slechts nieuws. Veel van de projectmanagers met wie ik door de jaren heen heb gesproken, vertelden me dat ze vaak het probleem hadden dat hun managers alleen goed nieuws in projectrapporten acceptabel vonden.

Een aantal jaar geleden was ik aanwezig bij een bespreking in een grote directiekamer van een grote multinational. We hadden het over de effecten van een door ons gepubliceerde urenstaat op een projectmanagementprogramma waarin ze werden ingevoerd.

"Ik begrijp niet goed”, zei een senior vicepresident, "waarom, als we de uren van de urenstaten krijgen, de voortgang van de taken niet wordt bijgewerkt".

'Als ik een taak van de 40 uur heb en 40 uur werk van de urenstaat op die taak boek, welk resultaat verwacht u dan?', vroeg ik hem.

Bij die vraag keek de vicepresident me verward aan.

"Ik zou dan verwachten dat de taak voltooid is", zei hij.

"En als dat niet zo is?", antwoordde ik.

"Ik begrijp het niet", zei de vicepresident enigszins geïrriteerd. "Als op een taak van 40 uur 40 uur werk wordt verricht, dan moet die taak af zijn."

Ik wist niet hoe ik daarop moest reageren, maar gelukkig schoot het hoofd van de projectgroep me te hulp. Hij nam de vicepresident even mee naar buiten en heeft hem daar waarschijnlijk uitgelegd dat het leven niet altijd volgens plan verloopt.

Het kan enorm veel voordelen opleveren als het management duidelijk kan worden gemaakt dat hun invloed de grootste impact heeft op momenten dat een project niet als gepland gaat, dat de dwang van het management om te melden dat alle projecten als gepland verlopen, verlammend kan werken.

Het bijhouden van uw project kan voordelen opleveren voor niet alleen degenen die het managen, maar voor de hele organisatie.

Over de auteur

Chris Vandersluis is president en oprichter van HMS Software, een in Montreal, Canada gevestigde Microsoft Certified Partner. Hij studeerde economie aan de McGill-universiteit en heeft ruim 30 jaar ervaring met het automatiseren van projectbeheersystemen. Hij is sinds lange tijd lid van het Project Management Institute (PMI) en was een van de oprichters van de afdelingen van de Microsoft Project-gebruikersgroepen (MPUG) in Montreal, Toronto en Quebec. Chris heeft geschreven voor Fortune, Heavy Construction News, het tijdschrift Computing Canada, PMNetwork van PMI en hij schrijft regelmatig een column voor Project Times. Hij doceert projectbeheer voor gevorderden aan de McGill-universiteit en geeft regelmatig lezingen op bijeenkomsten van verenigingen van projectbeheerders in Noord-Amerika en elders. HMS Software is uitgever van TimeControl, een project-georiënteerd systeem voor tijdregistratie en is een Microsoft Project Solution Partner sinds 1995.

U kunt via e-mail contact opnemen met Chris Vandersluis op chris.vandersluis@hms.ca

Als u meer artikelen van Chris Vandersluis over EPM wilt lezen, kunt u de EPM Guidance-site van HMS raadplegen op http://www.epmguidance.com/?page_id=39 (Engelstalig).

Uw vaardigheden uitbreiden
Training verkennen
Als eerste nieuwe functies krijgen
Deelnemen aan Office Insiders

Was deze informatie nuttig?

Bedankt voor uw feedback.

Hartelijk dank voor uw feedback! Het lijkt ons een goed idee om u in contact te brengen met een van onze Office-ondersteuningsagents.

×