Skip to content

Wij gebruiken cookies om interacties met onze websites en diensten te vereenvoudigen, betekenisvol te maken en om reclame te personaliseren. U kunt hier meer informatie vinden over hoe wij cookies gebruiken en uw cookie-instellingen. Door verder te surfen op deze website geeft u uw toestemming tot het gebruik van cookies.

 

Regelmatig duiken nieuwsberichten op over IT-projecten die het geplande budget flink overschrijden. De oorspronkelijke eisen worden niet, deels of veel te laat gerealiseerd. Is het dan echt zo moeilijk om vooraf een goede inschatting van een project te maken?

 

Net als het creëren van een kunstwerk is het maken van een goede projectinschatting voor veel mensen een intuïtief proces. Helaas is ‘een gevoel’ geen stevige basis voor de raming van een IT-project. Zeker niet als het om veel geld gaat en je een goede klantrelatie nastreeft. Toch is dat precies wat er nu vaak gebeurt. Het is al lastig om een sprint van twee weken goed te ramen, laat staan dat het lukt voor een complex project dat een jaar duurt. Een project kan echter niet zonder een goede raming. Al is het maar omdat een klant een budget moet aanvragen. Aan de andere kant wil de systems integrator ook betaald krijgen.

 

Veranderende eisen inschatten

 

Het vertrekpunt is eenvoudig: een klant wil bepaalde functionaliteit en de inkoopafdeling moet daar een prijs aan hangen om goedkeuring te kunnen geven. Je moet dus cijfers leveren die de investering onderbouwen. Een deel daarvan is wel duidelijk, bijvoorbeeld de licentiekosten. Dat geldt niet voor de kosten om de software in de lucht te krijgen en aan te passen aan de klanteisen. In de meeste gevallen weet een klant namelijk niet precies wat er nodig is. Bovendien veranderen eisen vaak nog tijdens het project.

 

Bottom up of top down

 

Om het project binnen te halen en een gezonde marge te halen, moet je dus hoe dan ook een projectinschatting maken. Hierbij is het de uitdaging om de risico’s voor de initiële levering zo klein mogelijk te houden en gaandeweg te ontdekken wat de klant precies nodig heeft. Dat kun je op twee manieren doen: bottom up of top down.

 

Bij de eerste variant probeer je de puzzelstukken van de benodigde technologie goed in kaart te brengen. Je hebt bijvoorbeeld een interface, databasetabellen en workflows nodig. Hier hang je een bedrag aan dat afhangt van de vraag of je de invulling van onderdelen eenvoudig of complex inschat. Vervolgens tel je alles op en je hebt een raming. In de praktijk is dit niet altijd zo makkelijk. Je moet namelijk vooraf een goed beeld van de eisen en het ontwerp hebben. Een nadeel is dat een kleine verandering door de gebruiker grote impact op de implementatiekosten kan hebben.

 

Bij een top down-aanpak tel je het aantal gebruikers, processen en interfaces en vergelijkt deze met eerdere projecten. Dit geeft houvast bij complexe processen, waarbij vaak nog veel details ontbreken. Daarom dwingt deze aanpak je eigenlijk om de toekomst te voorspellen op basis van beperkte informatie.

 

 

Drie opties

 

De belangrijkste vraag is: hoe ga je om met deze onzekerheden die blijkbaar bij een raming horen? Als je de magische cijfers moet leveren en je geen toverstaf hebt, zijn er drie opties.

 

Overdrijven

Met een ruime inschatting, creëer je een grote buffer. Vaak gebeurt dit met toestemming van de opdrachtgever. Zeker als er veel onzekerheden zijn, is het voor beide partijen prettig om een veilige marge te hebben. Bijvoorbeeld voor het overleg met de inkoopafdeling. Met deze aanpak dek je het onbekende enigszins af.

 

Heldere scope

Je kiest een duidelijk kader, bijvoorbeeld door alleen de standaard functionaliteit aan te bieden. Zo voorkom je maatwerk. In de Business to Consumer markt gebeurt dit veelvuldig; je downloadt een app die niet aan jouw specifieke wensen wordt aangepast.


Puur tijd en materiaal

Om te zorgen dat je klant flexibel blijft, beloof je hem geen functionaliteit, maar expertise. Je klant koopt zogezegd uren van jouw team. Deze aanpak is zeer gebruikelijk als je nauw samenwerkt en de klant de selectie van de eisen en testen voor zijn rekening neemt.

 

Minimaal risico?

 

De eerste methodes staan eigenlijk lijnrecht tegenover elkaar: je overdrijft of giet alles in beton. Het probleem is wel dat een gemiddeld IT-project verre van standaard is. Bedrijfsprocessen en technologie zijn vaak complex en het is lastig om grote groepen mensen binnen een organisatie op één lijn te krijgen. Daarom lijkt de derde variant, zeker voor een leverancier, een goede aanpak. Je neemt namelijk minimale risico’s. Tegelijkertijd is het ook niet risicoloos. Een succesvol project is de basis voor nieuwe projecten. Als je alleen uren verkoopt en de klant faalt of kiest ervoor de expertise ergens anders te halen, ben je uit beeld.

 

De enige zekerheid bij een raming lijkt onzekerheid. Toch is er zeker hoop. We kunnen inmiddels de toekomst al heel wat beter voorspellen. Met machine learning en neurale netwerken kunnen we al fantastische voorspellingen doen. Misschien wordt het ook tijd om die richting in te slaan bij het ramen van projecten.

 

Lees in mijn volgende blog meer over de mogelijkheden om met behulp van machine learning betere projectramingen te maken.