De strekking van ‘Zekerheid en Pavlov in de ict’ van Michèl Stijlen (Computable, 8 juli 2005) is correct, maar er zijn twee zaken die door elkaar lopen, stelt Ton Dekkers. Een project moet inderdaad meer opleveren dan het kost. maar het vaststellen daarvan is een taak voor de organisatie, en niet voor de ict-afdeling.
In principe moet er een zakelijke rechtvaardiging ofwel ‘business case’ zijn die de investering in hardware, software, kennis en capaciteit rechtvaardigt. Op basis van ipo (input-proces-output) moet de ‘output’ meer opleveren (return) dan de ‘input’ kost (investment). Zolang dat het geval is, is het alleen nog een kwestie van discussiëren over de omvang van de roi; is die groot genoeg? De revenuen vaststellen is echter geen zaak van ict, maar van de organisatie. De organisatie zal op grond daarvan moeten bepalen wat de investering in software kan en mag zijn, wil de zakelijke rechtvaardiging tot een goed resultaat leiden. Het is aan ict om aan te tonen of dat mogelijk is.
In de bouwwereld is dat een heel normaal principe. Een architect zal zich niet gauw laten verleiden tot een ontwerp voor een riante villa als het budget niet meer toestaat dan een kleine vakantiewoning. De architect baseert zich ook op ipo. De woning (output) wordt gerealiseerd volgens een bepaalde bouwwijze (proces) met bekende materialen (input). Op basis van ervaring is bekend wat de kosten zijn. Op die manier zijn ook verschillende aanbieders goed met elkaar vergelijkbaar en kan je twee richtingen uit redeneren.
Hoofdrol
Ipo gaat ook op voor ict. Het resultaat van het ict-project (output) komt tot stand (proces) door inbreng van tijd en materiaal (input). De kosten voor hardware zijn eenvoudig vast te stellen op basis van catalogi of prijslijsten. De softwarecomponent is wat lastiger, want hierbij speelt de menselijke inspanning de hoofdrol. Wanneer de software wordt uitgedrukt in eenheden, valt met inachtneming van het softwareontwikkelproces achteraf een tijd-prijs per eenheid vast te stellen. Die ervaring is te gebruiken om een volgende keer een kwantitatief onderbouwde begroting te maken. De omvang is tegelijk een basis voor beheersing en controle. Bij het ontwerpen van software is die ervaring te gebruiken om te voorkomen dat de programmatuur meer op een riante villa gaat kijken dan op een binnen het budget passend vakantiehuisje. Wanneer zelfs het kleinste vakantiehuisje niet binnen het budget past, moet je een andere oplossing kiezen.
Voor het voor- en achteraf meten van software zijn verschillende internationaal geaccepteerde en ISO-gecertificeerde methoden beschikbaar. De bekendste zijn fpa (functie punt analyse) en ‘cosmic full function points’. Ervaringscijfers in de vorm van uren per eenheid zijn beschikbaar bij de International Software Benchmarking Standards Group.
Realistisch
De kracht van die methoden is dat bij meting vooraf al valt vast te stellen welke risico’s worden gelopen bij het realiseren van de software. Wanneer het niet goed te meten is – er wordt een soort bestek gemaakt – zijn de specificaties niet helder en zullen er veel stelposten en discussiepunten zijn tijdens de realisatie. Het is evident dat het lastiger wordt binnen het budget te blijven en de kans op falen groeit. Het bestek is ook een basis voor het vaststellen van de prioriteiten en biedt voor zowel aan- als afnemer houvast.
Met de omvang als uitgangspunt valt te toetsen of een begroting realistisch is, een leverancier meer of minder productief is en het uitbesteden (lokaal, nearshore of offshore) rendabel is. Met deze achtergrond is duidelijk waarom kwaliteitsmodellen voor softwareontwikkeling als CMM(I) en Six Sigma aan meten en analyse een prominente plaats hebben gegeven.
Terugkomend op de 29 procent van de ict-projecten waar het beter gaat: de planning en het beheer van die projecten zijn vrijwel altijd gebaseerd op objectieve en kwantitatief gemaakte ervaring.
Ton Dekkers, senior project consultant bij Sogeti Nederland
