Als we het hebben over projectrisico’s bespreken we vaak de financiële risico’s en de functionele risico’s. In de bekende project driehoek blijft het derde risicotype, gereserveerd voor de tijdgebonden risico’s, vaak steken bij een deadline.

Als er al sprake is Van Het sturen op tijd wordt dat gedaan door in te perken op functionaliteit of door meer mensen in te zetten. Deze aanpassingen vinden plaats zodat we de deadline toch kunnen halen. Er zijn echter een aantal factoren die bij het starten van een project al een rol spelen die een enorme impact hebben op de duur van het project.

In dit artikel 5 tijdgebonden risicovoorbeelden om rekening mee te houden, de Time Bandits die tijd van ons stelen maar waar we ook op kunnen sturen.

Time Bandit 1: De projectrisico’s van externe afhankelijkheid

We kunnen het allemaal nog zo gemakkelijk bedenken en plannen maar er zijn altijd externe factoren die we niet in de hand hebben. De tijdige levering van apparatuur, materialen en menskracht laat vaak te wensen over. Niet in de laatste plaats wanneer leveranciers hun resources voor een hogere prijs aan anderen kunnen verkopen.

Vergadering met alleen externen.

Jaren geleden was ik als programmamanager betrokken bij een project waarbij we 4 overheids-datacentra moesten samenvoegen. De kickoffvergadering van de 4 partijen verliep bijzonder vlot, iedereen sprak dezelfde taal ook technisch. Beslissingen lagen voor de hand en werden snel genomen, taken werden automatisch verdeeld en opgepakt. Het liep zo vlot dat ik argwaan kreeg, dit was ik niet gewend bij de overheid. Wat bleek, er zaten alleen maar ingehuurde, externe mensen aan tafel, inclusief ik zelf. Er was niemand bij van een van de datacentra zelf.

Daar schrok ik van, want wie vertegenwoordigde dan het echte belang van de opdrachtgevers? De externe vertegenwoordigt misschien zijn opdrachtgever, maar zijn echte belang is om zoveel mogelijk uren in rekening te kunnen brengen. Met elkaar hadden we iets kunnen bedenken waar op dat onopgemerkt kon. Het project was immers te technisch voor de opdrachtgever. Dat is niet gebeurd, maar een zeker tijdgebonden risico was aanwezig.

Maatregelen tijdgebonden risico’s 1

1. Zorg als opdrachtgever voor voldoende kennis binnen je eigen team om het project te kunnen overzien.
2. Het is van belang om gebruik te maken van goede contracten waarin de tijdgebonden projectrisico’s zijn afgedekt.
3. Er moeten altijd “eigen” mensen bij belangrijke projectvergaderingen aanwezig zijn.

Time Bandit 2: De projectrisico’s van verkeerde tijdschattingen

Schattingen zijn een vaak onvermijdelijk onderdeel van IT projecten. Ze worden gemaakt onder druk van opdrachtgevers die een ​​prijs of een planning willen krijgen. Schattingen leveren echter projectrisico’s op als ze verwachtingen wekken die men niet kan waarmaken.

Onnauwkeurige schattingen ontstaan ​​wanneer het projectteam de lengte van een project of iteratie  onderschat. Software-inschattingen kunnen problemen veroorzaken tussen ontwikkelaars en klanten, omdat ze leiden tot langere doorlooptijden en dus hogere projectkosten.

Aanbesteding gewonnen maar… te kort ingeschat

Bekende voorbeelden van de gevolgen van verkeerde inschattingen zien we vaak bij aanbestedingen waarbij de prijs de doorslaggevende factor is. Leveranciers rekenen in die gevallen meestal met te weinig uren om zo de aanbesteding te winnen. In de loop van het project blijkt dan dat het toch meer tijd kost dan gedacht. Er ontstaat een conflict tussen de opdrachtgever en de leverancier over de volledigheid van de opdracht en wat daar impliciet bij hoort. Uiteindelijk gaat de opdrachtgever overstag want het project moet toch worden afgerond.

Maatregelen tijdgebonden problemen 2

Bij een aanbesteding is de vraag meestal: “Ik wil dit en wat gaat me dat kosten?”. Draai het eens om en vraag: “Ik wil ongeveer dit binnen een jaar en heb dat als budget, Wat kunnen jullie met dat bedrag voor mij maken?”. De winnaar is dan niet de goedkoopste, maar diegene die het meeste functionaliteit biedt.

Hoe schatten we IT projecten nauwkeurig in? Er zijn een aantal strategieën waarmee we dit projectrisico kunnen minimaliseren:

1. Werk alleen uit wat onmiddellijke prioriteit heeft.
2. Neem onderzoektijd mee in de schattingen (een toewijzing van tijd voor ontwikkelaars om een ​​bijzonder complex of onbekend onderdeel van het project te onderzoeken en de tijdgebonden projectrisico’s in kaart te brengen).
3. Voeg een allocatiefactor toe aan de schatting (een berekende tijdsfactor die een ontwikkelteam tijdens de werkweek besteedt aan taken buiten het project).
4. Houd bij het schatten rekening dat de onzekerheid afneemt naarmate het project vordert.

Time Bandit 3: De projectrisico’s van nieuwe requirements

Naarmate een project vordert, komen er steeds meer requirements naar voren die aan het begin van het project niet geïdentificeerd waren maar schattingen en planningen bedreigen. Gevolg hiervan is dat het project uitloopt en duurder wordt. Ervaren projectmanagers hebben geleerd om hier paal en perk aan te stellen. Voor ieder project geldt echter dat uitloop vrijwel niet is te voorkomen.

Project zonder einde: Na 60 miljoen de stekker eruit

Bij overheden en banken zijn in het verleden projecten geweest die geen einde kende. Het management wilde successen zien of een groot probleem integraal oplossen. De overtuigingen waren zo groot dat ze er maar geld in bleven pompen. Waardoor de functionaliteit ook steeds verder kon groeien. Daardoor werden de belangen ook steeds groter en het beëindigen van het project steeds lastiger. Een ware goudmijn voor freelancers en andere externe aannemers.
Op een gegeven moment klapt zo’n ballon natuurlijk.

Maatregelen tijdgebonden risico’s 3

1. Zorg voor een constante betrokkenheid van klanten en ontwikkelaars.
2. Stel een Change Control Board voor het project in.
3. Schuif kleine requirements door naar de onderhoudsfase.
4. Werk volgens Agile Scrum.

Bij Agile/Scrum projecten maken we bij iedere Sprint opnieuw een afweging. Met de Backlog in de hand bepalen we wat voor de volgende Sprint belangrijk is en hoeveel tijd het gaan kosten. Veranderingen en inflatie van requirements worden geaccepteerd als normaal tijdens IT-projecten. In plaats van gebruik te maken van mechanismen voor het onderdrukken van veranderingen, worden er prioriteringssessies gepland waarmee we waardevolle wijzigingen kunnen doorvoeren. We kunnen aanvankelijk beoogde functies vervangen als de klant hiervoor toestemming geeft.

Time Bandit 4: De projectrisico’s door gebrek aan urgentie

Gezien de lange projecttijdlijnen, is het gevoel van urgentie vaak afwezig, wat leidt tot tijdverlies in vroege projectfasen die we nooit meer kunnen terugwinnen.  De wet van Parkinson en het studentensyndroom zijn van toepassing op softwareprojecten. De Wet van Parkinson zegt: “Werk breidt zich uit om de beschikbare tijd te vullen” en Studentensyndroom: “Mensen hebben de neiging om te wachten tot vlak voor de deadline voordat ze aan het werk gaan.”

“Een beslissing wordt geen betere beslissing door er nog langer over na te denken.”

Bij mijn tweede werkgever heb ik dit helaas aan den lijve ondervonden. Ze hadden een project op zich genomen van anderhalf jaar en het eerste jaar daarvan bezig geweest met onderzoeken en analyseren. Toen ik werd aangenomen hadden we nog een half jaar om de software te progammeren. Uiteindelijk hebben we alle analyses overboord gegooid en het project iteratief aangepakt.

De uitspraak: “Een beslissing wordt geen betere beslissing door er nog langer over na te denken”. Is van mijn derde werkgever. Die hakte wel knoppen door bij lastige projecten.

Maatregelen tijdgebonden risico’s 4

“Haast je als je tijd hebt, dan heb je tijd als je haast hebt.”

Als scholier werkte ik in de vakanties bij bloemen- en plantentuinders. Zij wisten van de seizoenen en hoelang een teelt duurde. Daardoor waren ook de exacte tijdstippen bekend waarop je acties moest uitvoeren. Deze uitspraak is dus van hen. De maatregelen:

1. Door korte iteraties plaatsen we het werk in een timebox van 1 tot 4 weken. Dan is er altijd een gevoel van urgentie. 
2. We richten ons op het krijgen van de juiste mensen in ons team die de “Sense of Urgency” aanvoelen.
3. Door agile projecten in kleine stapjes te werken komt het ware tempo van het team snel naar voren en is zichtbaar voor alle stakeholders die nu nauwer bij het project betrokken zijn.
4. Huur mij in als projectmanager, ik zet al snel druk op de ketel.

Time Bandit 5: De projectrisico’s door personeelsproblemen

Het laatste praktijkvoorbeeld in dit artikel. Toen we eenmaal groenlicht hadden voor het project bleek dat de gekozen technologie nog niet bekend was bij de ontwikkelaars en het datacenter. De gevolgen waren ingrijpend:

• Iedereen moest eerst nog naar een training.
• We moesten externen (daar heb je ze weer) inhuren om het project te starten.
• Er was vertraging door trainingen.
• Er was personeelsverloop van medewerkers die liever met de oude tools bleven werken.

De managers van de betreffende afdelingen wisten dit wel maar verzwegen het omdat ze er een kans in zagen om hun medewerkers naar een hoger plan te brengen. Als we echter sleutelpersoneel moeten missen dat ook nog eens kritische informatie meeneemt, kan het project aanzienlijk vertragen ​​of ontsporen.

Maatregelen tijdgebonden risico’s 5

1. Zorg ervoor dat de medewerkers opgeleid zijn voor de huidige en toekomstige IT-stack.
2. Organiseer dagelijkse stand-ups.
3. Hou rekening met de “busfactor”. De “busfactor” is de impact op het project wanneer een sleutellid wordt aangereden door een bus.
4. Deel aanwezige informatie met het team en verbeter de samenwerking. Informatie delen met meerdere teamleden verkleint het risico als gevolg van personeelsverloop.
5. Zorg voor een boeiende, lonende, krachtige, collaboratieve omgeving zoals agile projecten. Mensen zullen veel minder snel ergens anders willen werken, waardoor we dit projectrisico vermijden en verminderen.

Discussieer mee op ITpedia LinkedIn of op Financial Executives LinkedIn.