Sinds de Algemene Rekenkamer ict-projecten bij de overheid zeer kritisch onder de loep heeft genomen, gaat er bijna geen aanbesteding voor ICT-diensten de deur uit zonder dat er functiepunten in voorkomen. Daar zitten er nog heel wat tussen waaruit blijkt dat de achterliggende mechanismen niet bij iedereen even duidelijk zijn. Maar gelukkig zijn er ook aanbestedingen, zoals die van de Modernisering GBA door ICTU, waarin duidelijk rekening is gehouden met het effect van tijdsdruk en omvang. Hoewel er natuurlijk altijd ruimte is voor verbetering.
In het rapport 'Lessen uit ict-projecten bij de overheid' van de Algemene Rekenkamer uit november 2007 werd een aantal grote ICT-projecten bij de overheid tegen het licht gehouden en werd een aantal aanbevelingen gedaan om grote projecten in de toekomst beter te kunnen beheersen. Eén van die aanbevelingen was om projecten op basis van output aan te besteden met behulp van functiepunten. Sindsdien gaat er bijna geen aanbesteding voor ICT-diensten de deur uit zonder dat er functiepunten in voorkomen. Deze ontwikkeling juich ik zonder meer toe, omdat op deze manier wordt afgerekend op basis van wat de opdrachtgever krijgt en niet op basis van de inspanningen die een leverancier moet doen.
De manier waarop opdrachtgevers functiepunten inzetten laat jammer genoeg nog wel eens te wensen over. Zo wordt er aan leveranciers regelmatig gevraagd om één vaste prijs per functiepunt aan te bieden. Eltjo Poort heeft hier in november 2009 een bijdrage in Computable over geschreven met de titel 'De functiepunt bestaat niet'. In dat stuk wordt het niet functioneren van een dergelijke constructie gelegd bij de functiepunt. Het probleem zit hem niet in de functiepunt, maar in het gehanteerde prijsmechanisme. Bij een vaste prijs per functiepunt wordt voorbij gegaan aan twee belangrijke factoren die, naast de sourcingstrategie, de prijs per functiepunt voor een ICT-project bepalen: omvang en doorlooptijd. Als je die factoren niet meeneemt, kun je er inderdaad van overtuigd raken dat functiepunten eerder fictiepunten zijn.
Het effect van omvang
De omvang van een project heeft een effect op de inspanning per functiepunt. Zo bevat ieder project activiteiten die eigenlijk helemaal niet afhankelijk zijn van het aantal functiepunten. Ieder project moet opgestart worden en contact leggen met de omgeving waarin het project wordt uitgevoerd. Deze activiteiten hebben niets met de omvang van de te realiseren software te maken, maar worden in de regel wel omgeslagen in de prijs per functiepunt. Hierdoor zijn kleine projecten per functiepunt wat duurder dan de iets grotere projecten. Dit effect is duidelijk zichtbaar bij projecten tot circa driehonderd functiepunten.
De omvang van een project heeft een effect op de inspanning per functiepunt. Zo bevat ieder project activiteiten die eigenlijk helemaal niet afhankelijk zijn van het aantal functiepunten. Ieder project moet opgestart worden en contact leggen met de omgeving waarin het project wordt uitgevoerd. Deze activiteiten hebben niets met de omvang van de te realiseren software te maken, maar worden in de regel wel omgeslagen in de prijs per functiepunt. Hierdoor zijn kleine projecten per functiepunt wat duurder dan de iets grotere projecten. Dit effect is duidelijk zichtbaar bij projecten tot circa driehonderd functiepunten.
Als een project groter wordt, wordt ook het projectteam groter en is er meer tijd nodig om alle werkzaamheden op elkaar af te stemmen. Deze tijd is vooral afhankelijk van de omvang van het projectteam, maar wordt in de regel omgeslagen in de prijs per functiepunt. Dit effect is niet eindeloos. Vanaf ongeveer duizend functiepunten worden projectteams groot genoeg om deze afstemming efficiënt te organiseren. Hierdoor neemt de prijs per functiepunt weer langzaam af.
Hoe dit effect er uit kan zien wordt weergegeven in de grafiek hierboven, waarin de prijsindex per functiepunt is uitgezet tegen de omvang. De prijsindex is op 100% gezet voor een omvang van 250 functiepunten. Op de achtergrond van die keuze kom ik aan het eind van dit verhaal nog terug.
Ook dit effect is niet eindeloos. Hoe groter het project, hoe groter de kans dat een project mislukt doordat het overzicht ontbreekt. In de projectendatabase van de ISBSG, één van de weinige open databases met ICT-projectreferentiegegevens, komen maar heel weinig projecten voor met een omvang van meer dan vierduizend functiepunten. De belangrijkste reden daarvoor is dat in deze database alleen afgeronde projecten worden opgenomen.
Hoe dit effect er uit kan zien wordt weergegeven in de grafiek hierboven, waarin de prijsindex per functiepunt is uitgezet tegen de omvang. De prijsindex is op 100% gezet voor een omvang van 250 functiepunten. Op de achtergrond van die keuze kom ik aan het eind van dit verhaal nog terug.
Ook dit effect is niet eindeloos. Hoe groter het project, hoe groter de kans dat een project mislukt doordat het overzicht ontbreekt. In de projectendatabase van de ISBSG, één van de weinige open databases met ICT-projectreferentiegegevens, komen maar heel weinig projecten voor met een omvang van meer dan vierduizend functiepunten. De belangrijkste reden daarvoor is dat in deze database alleen afgeronde projecten worden opgenomen.
Het effect van doorlooptijd
Het effect van de doorlooptijd op de prijs per functiepunt is nog veel groter dan het effect van de omvang van een project. In een ICT-project werken verschillende vakinhoudelijke disciplines samen om te komen tot het eindproduct: werkende software die doet wat het moet doen binnen de omgeving waarin het moet functioneren. Om tot het eindproduct te komen moeten de verschillende teamleden met elkaar communiceren. De besturing hiervan kwamen we al tegen bij het effect van de omvang. De communicatie zelf is één van de belangrijkste aspecten van het effect van doorlooptijd.
De meest productieve teamgrootte, waarbij het meeste product per geïnvesteerde tijd wordt gerealiseerd, bestaat uit vier tot zes mensen. Intuïtief is dit wel te begrijpen. Een dergelijk team is groot genoeg om alle benodigde disciplinekennis te bevatten, maar klein genoeg om op één kamer te huisvesten zodat iedereen weet waar de anderen mee bezig zijn. Een team van deze grootte is echter vaak niet in staat om een project binnen de gewenste doorlooptijd te realiseren.
Om een project op de gewenste datum te kunnen opleveren moeten er dus meer mensen in het projectteam worden opgenomen dan de optimale teamgrootte van vier tot zes mensen. Meer mensen betekent meer communicatielijnen en minder functiepunten binnen een zelfde aantal uren. Bovendien betekent het dat er taken gesplitst moeten worden, waardoor er kans bestaat op overlap of juist slechte aansluiting van de afzonderlijke delen. Dit leidt tot meer fouten en bijbehorend rework. De impact van dit effect wordt weergegeven in de figuur hiernaast. Het goed kiezen van een realistische doorlooptijd kan een opdrachtgever veel geld schelen en levert bovendien een kwalitatief beter product op.
Een goede aanbesteding
De Europese aanbesteding van de Modernisering GBA door ICTU vind ik een mooi voorbeeld van hoe het zou kunnen. In de gunningscriteria heeft het Ictu een compleet mechanisme uitgewerkt waarin rekening wordt gehouden met zowel tijdsdruk als omvang. Alles in de aanbesteding wordt teruggerekend naar een project van 250 functiepunten zonder tijdsdruk. Vandaar dat ik de prijsindex hier ook naar heb teruggerekend.
Dit mechanisme is gebaseerd op onderzoek dat aan de Vrije Universiteit is gedaan op basis van projectenportfolio's van een aantal grote financiële instellingen. De formules die daar uit zijn gekomen zullen op portfolioniveau ongetwijfeld kloppen, alleen geven ze een ander beeld dan wat we in de dagelijkse praktijk van het begroten van individuele projecten terugzien. Zo wordt in het model de prijs per functiepunt altijd lager als het project kleiner wordt en altijd hoger als het project groter wordt. E
n dan is de gekozen referentieomvang een heel vervelende, vooral als er opdrachten worden verstrekt die kleiner zijn. In de bijgaande figuur heb ik het mechanisme dat ICTU gebruikt afgezet tegen het eerder aangehaalde praktijkmodel. Voor de leveranciers is het hopen op opdrachten van boven de duizend functiepunten. Maar die komen niet. Die les heeft ICTU wel geleerd.
Deze post is eerder geplaats op de website van Computable.
Dit mechanisme is gebaseerd op onderzoek dat aan de Vrije Universiteit is gedaan op basis van projectenportfolio's van een aantal grote financiële instellingen. De formules die daar uit zijn gekomen zullen op portfolioniveau ongetwijfeld kloppen, alleen geven ze een ander beeld dan wat we in de dagelijkse praktijk van het begroten van individuele projecten terugzien. Zo wordt in het model de prijs per functiepunt altijd lager als het project kleiner wordt en altijd hoger als het project groter wordt. E
n dan is de gekozen referentieomvang een heel vervelende, vooral als er opdrachten worden verstrekt die kleiner zijn. In de bijgaande figuur heb ik het mechanisme dat ICTU gebruikt afgezet tegen het eerder aangehaalde praktijkmodel. Voor de leveranciers is het hopen op opdrachten van boven de duizend functiepunten. Maar die komen niet. Die les heeft ICTU wel geleerd.Deze post is eerder geplaats op de website van Computable.
Geen opmerkingen:
Een reactie posten