info

rmat

ie /

apr

il 20

12

8

iover

heid

De onvoorspelbaarheid van het ontwikkelen van

geautomatiseerde systemenEen

kwantitatief beeld

van de situatie bij

de Nederlandse

rijksoverheid

In de publieke opinie bestaat ontevredenheid over de toepassing

van ICT door de overheid, met name over de ontwikkeling van

geautomatiseerde systemen: te veel mislukkingen, te laat en veel

te duur opgeleverd en met tegenvallende functionaliteit. Dit artikel

geeft eerst een kwantitatief beeld (in systeemomvang en kosten)

van het ontwikkelen van systemen bij de Nederlandse rijksoverheid,

een beeld dat de ontevredenheid objectiveert. Daarna wordt op zoek

gegaan naar de veroorzakers van variatie en onvoorspelbaarheid.

Afgesloten wordt met de vraag of organisaties adequate ‘counter­

vailing powers’ kunnen organiseren tegen de veroorzakers van de

onvoorspelbaarheid.

Lauran Matthijssen

Een groot en toenemend aantal processen bij de overheid kan niet meer worden uitgevoerd zonder geautomatiseerde systemen. Dat betekent dat gewenste nieuwe diensten en processen of aan­passingen in lopende diensten en processen pas kunnen worden ingevoerd als de software voor de systemen werkend is. En met de ontwikkeling van die systemen is bij de overheid het een en ander mis:

•Een behoorlijk aantal grote projecten mislukt voor aanzienlijke bedragen. De Tweede Kamer discussieerde daar in 2007 en 2008 over (Oos­terhout, 2007) en zal in de loop van 2012 een parlementair onderzoek starten.

•Ook bij systemen die wel worden opgeleverd en ingevoerd zijn regelmatig te hoge kosten gemaakt. Dit artikel geeft enig inzicht in de omvang daarvan.

•Het is waarschijnlijk dat de suboptimale pro­ductiviteit bij de ontwikkeling van systemen zich doorzet naar het onderhoud en het beheer van die systemen in de verdere levenscyclus.

Dit betekent dat een groot deel van de jaarlijkse ICT­uitgaven van de centrale overheid in Neder­land, zo’n 8 tot 10 miljard euro (Dekker, 2008), sterk beïnvloed wordt door de productiviteit bij de ontwikkeling van systemen. En een verbeter­potentieel van misschien wel enkele miljarden per jaar moet in dit tijdsgewricht van financiële schaarste aanspreken.Er wordt op veel plaatsen gesproken over de productiviteit bij het ontwikkelen van geauto­matiseerde systemen. Dat gebeurt zeker bij het management van ICT­afdelingen en van ICT­

info

rmat

ie /

apr

il 20

12

9

bedrijven. Dat gebeurt, tamelijk indringend, aan de vergadertafel van de stuurgroep van het project wanneer er over een verhoging van het budget en een uitstel van de opleverdatum gesproken wordt. En dat gebeurt nu ook in de vergaderzaal van de Tweede Kamer, omdat het functioneren van de overheid lijdt onder mislukkende projecten en te laat opgeleverde systemen. Verrassend genoeg ligt de vraag vrijwel nooit op de vergadertafel van het topmanagement van overheidsorganisaties. Ver­rassend, omdat de kwestie daar ook van invloed is op het totale functioneren van de organisatie. En omdat alleen daar de maatregelen getroffen kunnen worden om de ontwikkeling van syste­men goedkoper, sneller en meer voorspelbaar te maken.

Beschikbaarheid van gegevens over systeemontwikkelingDe planning van de ontwikkeling van een systeem gebeurt in twee stappen. In de eerste stap wordt een raming gemaakt van de omvang van het te realiseren systeem. Vervolgens worden op basis daarvan de inspanning en doorlooptijd geraamd. Voor de omvang van systemen is het aantal func­tiepunten de (wereldwijd) meest gebruikte maat. Het aantal functiepunten wordt bepaald door de gebruikersfuncties en (logische) gegevensverza­melingen van een systeem te vermenigvuldigen met normgetallen (op basis van complexiteit) en te tellen. Met onafhankelijke, goed opgeleide tellers is de bepaling ervan in hoge mate betrouw­baar (Kemerer, 1993).Voor het bepalen van de inspanning is een goede definitie nodig om goed en eerlijk te kunnen vergelijken: is dit alleen de inspanning van de ICT’ers of ook die van de materiedeskundigen, is dit inclusief het voortraject en inclusief de accep­tatietest? In dit artikel is de inspanning gedefini­eerd als de inspanning van de ICT’ers in de fasen systeemontwerp en bouw (inclusief systeemtest).

Niet in de hier gehanteerde definitie van inspan­ning zijn opgenomen de inspanningen in het voortraject, de inspanning van de acceptatietest en de verdere inspanningen van de lijnorganisatie. Gegevens van de auteur leren dat de inspanning ongeveer het dubbele bedraagt als deze onder­delen ook worden meegenomen. De inspanning is dus: uren feitelijke systeemontwikkeling per functiepunt. Waar gesproken wordt over door­looptijden zijn deze ook tot de aangegeven fasen beperkt.Gegevens over systeemomvang, kosten en door­looptijden, nodig voor de planning van de ontwik­keling van een systeem, zijn zowel overvloedig beschikbaar als niet beschikbaar:

•Overvloedig beschikbaar. Er is een zeer grote hoeveelheid boeken, artikelen en data over systeemomvang, kosten en doorlooptijden gepu­bliceerd. In 2007 waren wereldwijd van meer dan 25.000 voltooide projecten de gegevens in combinatie met een functiepunttelling publiek bekend. De resultaten zijn ‘verpakt’ in de advies­producten van bijvoorbeeld Gartner en QSM. Of in de vorm van analyses beschikbaar in de boeken van bijvoorbeeld Capers Jones en Larry Putnam. Of in de vorm van beschikbare databanken zoals de repository van de International Software Benchmarking Standards Group (ISBSG). Deze bronnen leveren een algemeen beeld op van de kosten voor het ontwikkelen van een softwarepro­duct. Dit algemene beeld heeft een aanzienlijke bandbreedte.

•Niet beschikbaar. Voor een nadere precisering zijn gegevens nodig van de organisatie waarin het project zal worden uitgevoerd. In veruit de meeste gevallen ontbreken deze gegevens. Amerikaans onderzoek wees uit dat maar van 10 procent van de uitgevoerde projecten accuraat de gegevens werden bijgehouden, en dat gebeurde in maar 5 procent van de opdrachtgevende organisaties. De Nederlandse overheid lijkt het niet veel beter te

Samenvatting

Er zijn organisaties waar systemen volgens planning worden ontwikkeld. Daar wordt

bovendien goedkoper en sneller ontwikkeld. Dit zou de nieuwsgierigheid van het

topmanagement van overheidsorganisaties moeten wekken. Het topmanagement

zou binnen de eigen organisatie een ‘meet- en regelsysteem’ voor ICT-toepassingen

moeten eisen. Op basis van dit kwantitatieve beeld zou men zich moeten vergelijken

met de organisaties die ‘best in class’ opereren.

info

rmat

ie /

apr

il 20

12

iover

heid

10

doen. Dat moest ook de Rekenkamer constateren toen zij in 2007 een kwantitatief beeld probeerde op te bouwen van het slagen en falen van ICT­projecten.

Gegevens Nederlandse overheid in perspectiefWaar in dit artikel een kwantitatief beeld wordt geschetst voor de Nederlandse overheid, gebeurt dat door de systemen (in omvang en inspanning) weer te geven tegen een achtergrond van gereali­seerde systemen uit een internationale benchmark over alle marktsectoren:

•De ISBSG­repository levert de verzameling van referentieprojecten. De ISBSG­repository is een wereldwijde dataverzameling van voltooide soft­wareprojecten, die met name gevuld wordt door nationale organisaties op het gebied van functie­punttellingen. Hieruit zijn de voltooide nieuw­bouwprojecten genomen, dit betreft een aantal van 460 systemen, met een gezamenlijke omvang van circa 340.000 functiepunten, waarvan de rea­lisatie ruim 3,5 miljoen mensuren heeft gekost.

•De gegevens van de Nederlandse overheid betreffen circa 120 voltooide systemen. Het materiaal is afkomstig uit de praktijk van de auteur, vanuit een projectverantwoordelijkheid of vanuit beoordelingen en evaluaties op project­ of organisatieniveau. Deze groep van circa 120 sys­temen heeft een gezamenlijke omvang van ruim 100.000 functiepunten en werd gerealiseerd met een gesommeerde inspanning van ruim 2,1 mil­joen mensuren. De systemen werden ontwikkeld binnen 17 overheidsorganisaties, van een aantal organisaties komen meer dan 5 voltooide systemen voor.

In figuur 1 is van de beide groepen voltooide pro­jecten de combinatie van omvang in functiepunten en de gerealiseerde inspanning weergegeven.De wereldwijde benchmark van ISBSG en de systemen van de Nederlandse overheid geven in verdeling en bandbreedte in grote lijnen het­zelfde beeld te zien (de resultaten van projecten van de Nederlandse overheid zijn iets in ‘minder productieve’ richting doorgeschoven). Opvallend is de enorme spreiding van de productiviteit in beide groepen. Het duurste (of minst productieve) project is ruim een factor 30 duurder dan het goedkoopste project. Bandbreedtes van deze orde van grootte worden ook door andere auteurs vanuit andere repository’s gemeld (Jones, 2000; Maxwell & Forselius, 2000).

inspanning[u]

omvang [functiepunten] ISBSGoverheid

00 1000500 20001500 30002500 40003500

1000

2000

3000

4000

5000

6000

7000

8000

9000

10.000

Figuur 1. Systemen van de Nederlandse overheid tegen een internationale benchmark

info

rmat

ie /

apr

il 20

12

11

Wat maakt de ontwikkeling van software zo onvoorspelbaar?Er zijn meerdere signalen die aangeven dat het ontwikkelen van software voor bedrijfstoepassingen in (overheids)organisaties een moeilijk proces is:

•Het kent een hoog percentage mislukkende pro­jecten. Dat percentage is de afgelopen twee decen­nia nauwelijks verbeterd (Oosterhout, 2007),

•Ondanks het feit dat het een onmisbare produc­tiefactor is en er veel druk staat op snelle en goed­kope levering, is de productiviteit in de afgelopen decennia nauwelijks gestegen,

•Over organisaties heen is een enorme spreiding in kosten per eenheid waar te nemen van een factor 10 (1000 procent!) of meer.

Blijkbaar zijn er sterke en divergerende krachten van invloed op het proces van het ontwikkelen van systemen. De belangrijkste van deze krachten worden hierna beschreven. Twee ambachten die tot elkaar veroordeeld zijnIn figuur 2 wordt het proces van de ontwikkeling van software voor maatwerkapplicaties ontleed. Deze ontleding is conceptueel, in de verschil­lende methodieken is de naamgeving anders, en dat geldt vaak ook voor de grenzen van een fase. Conceptueel is ook het volgtijdelijke verloop van de fasen, die in evolutionaire methoden gelijktijdig worden uitgevoerd. Het proces bestaat uit een combinatie van twee ambachten:

•Het specificeren. Dat is het optimaliseren van de bedrijfsprocessen, zoals ze met geautomatiseerde ondersteuning moeten gaan verlopen. Specificeren levert de beschrijving op van die geoptimaliseerde processen en een beschrijving van de daarbij benodigde geautomatiseerde ondersteuning. Een belangrijke noot hierbij is dat deze beschrijvingen niet een absolute waarheid zijn, maar de keuze van de organisatie om ‘het zo te gaan doen’.

Corrigeren voor technische en methodische factorenBij verschillen tussen softwareprojecten is de eer­ste reactie om deze verschillen te verklaren aan de hand van technische factoren, zoals de software­hulpmiddelen waarmee het systeem ontwikkeld wordt, de gehanteerde ontwikkelmethodiek en het computerplatform waarvoor het systeem ontwik­keld wordt. Historische vakliteratuur vermeldde destijds grote verbeteringen door nieuwe ontwik­kelhulpmiddelen of nieuwe methodieken. We hebben dat gezien met de 4GL­tools (literatuur: factor 3 tot factor 20 productiever), met RAD (literatuur: factor 3 tot 12 productiever). Deze tools en methodieken zijn op grote schaal in de praktijk ingevoerd, met aanzienlijke investeringen. Echter, uit onderzoek blijkt dat de productiviteit bij het ontwikkelen van systemen in diezelfde peri­ode ongeveer gelijk is gebleven (Jones, 2000). De technische en methodische kenmerken verklaren maar een deel van de enorme variatie; onderzoek naar de Finse Laturi­repository gaf aan dat ieder van de geregistreerde technische en methodische factoren maar 3 tot 15 procent van de variatie verklaart (Maxwell, 1998).Dat betekent dat er nog een grote bandbreedte overblijft, ook na correctie voor technische en methodische kenmerken. De ISBSG­repository kent een tool waarmee de realiteitswaarde van een planning kan worden gecheckt tegen de aanwezige data. Als voorbeeld een systeem van 1000 func­tiepunten, lineair te ontwikkelen in 4 GL op een midrange computer:

•optimistisch: 2080 uur inspanning in een door­looptijd van 5 maanden;

•pessimistisch: 20.500 uur inspanning en een doorlooptijd van ruim 22 maanden. Deze variatie is nog beperkt gebleven door de betrouwbaarheid van de raming op 80 procent te houden.Zonder nadere informatie vanuit de organisatie waar wordt ontwikkeld, zou in een af te geven planning met deze bandbreedte moeten worden volstaan. In meer dan 90 procent van de Neder­landse overheidsorganisaties zou dus bij ‘kosten en doorlooptijden’ in het projectplan van een verge­lijkbaar systeem moeten staan: ‘de kosten zullen liggen tussen de 2 en de 20 miljoen, de opleverda­tum is tussen de 4 en de 22 maanden na de start’. Een dergelijke eerlijkheid over de onzekerheid van de planning komt men echter bij niet­registreren­de organisaties zelden in de startdocumenten van projecten tegen.

informatieanalyse

systeemontwerp

realisatie

specificeren

realiseren

Figuur 2. De twee ambachten in de systeemontwikkeling

info

rmat

ie /

apr

il 20

12

iover

heid

12

De ‘marktwerking’ in beide ambachten draagt niet bij tot efficiëntie in de prestatie en tot kwaliteit van het resultaat. Allereerst het specificeren, het ontwerpen en beschrijven van nieuwe bedrijfspro­cessen. Door de aard van het ambacht (modelleren van bedrijfsprocessen om bedrijfsmatige voordelen te genereren met eigenaarschap bij de organisa­tie) is het eigenlijk alleen geschikt voor goede en ervaren informatieanalisten. Maar wie heeft er last van als een minder gekwalificeerd persoon een kwalitatief minder resultaat oplevert? Die last valt, nauwelijks te onderscheiden van onvermij­delijk veranderende specificaties, bij het volgende ambacht, de realisatie.En het ambacht van de realisatie wordt veelal beoefend door commerciële ICT­bedrijven, recht­streeks of via inhuur. En voor het commerciële bedrijf betekent efficiëntie minder uren werk en dus minder omzet. Als er verder geen prikkels zijn, zullen ze dat niet nastreven. En zal de commercië­le drive naar meer omzet overheersen. Voor interne ontwikkelafdelingen geldt een vergelijkbare pro­ductiviteitsparadox.

Waarbij de realisatie extreem reageert op te grote tijdsdrukSinds de competities tussen programmeurs die DeMarco organiseerde, is bekend dat er grote verschillen in productiviteit bestaan tussen indi­viduele programmeurs. Ook tussen teams van programmeurs bestaan dergelijke verschillen. In een recent onderzoek naar ruim 4000 voltooide projecten werden verschillen van een factor 13 waargenomen tussen efficiënte en niet­efficiënte teams (Comstock, Jiang & Naudé, 2008). De verschillen in productiviteit tussen teams maken het moeilijk om aan te geven op welk moment het effect van een te hoge tijdsdruk optreedt.De grondlegger van het kwantificeren van het verband tussen tijdsdruk en de productiviteit van bij de ontwikkeling van software is Larry Putnam. Vanuit de QSM­repository met voltooide projecten ontwikkelde hij al in het begin van de jaren negen­tig de wiskundige verbanden tussen het verkor­ten van doorlooptijden en de daardoor stijgende omvang van de ontwikkelteams. Hij neemt daarbij ook de toenemende kans op fouten bij het wer­ken met grotere ontwikkelteams in beschouwing. In 1991 is Putnam in Nederland en geeft in zijn college een gestileerd praktijkvoorbeeld waarbij de effecten op doorlooptijd, teamgroottes en defecten zijn gebaseerd op zijn wiskundige modellen (zie kader).

•Het realiseren. In deze fase wordt de functionele beschrijving omgezet naar de technische beschrij­ving, de database, de schermen en de koppelingen worden ontworpen en gerealiseerd.

Beide ambachten overlappen elkaar in een fase waarin het beschrijven van de gewenste ondersteu­ning van de bedrijfsprocessen al wel plaatsvindt in een vorm die de mogelijkheden van realisatie beïn­vloedt. Of andersom, waar de technische vorm van de functionaliteit de inhoudelijke kwaliteit van de ondersteuning kan verbeteren.Deze fase waarin er een overlap is in ambachten, lijkt een belangrijke ‘kraamkamer’ voor verande­rende specificaties (los van wijzigingen die ‘van buiten’ komen):

•Niet een van beide ambachten heeft automa­tisch de leiding. In de praktijk komt zowel aan­sturing vanuit de opdrachtgevende organisatie als aansturing vanuit de ICT voor.

•Vanuit de specificatie is niet altijd voldoende vastgelegd welke functionaliteit er moet komen (en waartoe men zich moet beperken).

•Binnen de opdrachtgevende organisatie ver­schuift de betrokkenheid: van management (inrichting van processen) naar eindgebruikers (ontwerp schermen). En de doelen van het management (efficiëntie, korte doorlooptijd) zijn niet altijd dezelfde als die van eindgebruikers (gebruikersgemak en behoud baan).

Moeilijke ambachten, met ook nog de wer-king van de markt als tegenwindHet specificeren en het realiseren van software zijn in de uitvoering moeilijke ambachten die veel discipline en vakmanschap vragen. Goed program­meren vereist een goede opleiding, ervaring en discipline (zowel van de programmeur als van de organisatie of het team). En dan hebben we het nog niet gehad over de kunst van de gebruikersin­teractie. Goed herontwerpen van bedrijfsproces­sen, zodanig dat zij straks inderdaad sneller en met minder kosten gaan verlopen, is ook een moeilijk ambacht. Zeker als het resultaat van het ontwerp niet alleen een rapport maar ook het ‘doorleefde’ eigendom door de organisatie moet zijn.

info

rmat

ie /

apr

il 20

12

13

Bij grotere systemen wordt in de praktijk naar ver­houding minder doorlooptijd beschikbaar gesteld en moet daarom met veel grotere teams gewerkt worden. De grotere teams zijn minder efficiënt. De verhoging van de tijdsdruk leidt dus door mid­del van grotere teams tot hogere kosten per func­tiepunt. Bij productieve organisaties is het effect veel minder sterk.

Veranderende specificaties en tijdsdrukHet is in de praktijk zo goed als uitgesloten dat de tevoren opgestelde specificaties in de realisatie voor honderd procent correct blijken te zijn. Er is altijd wel een scherm waarop een data­element vergeten is. Of één scherm blijkt bij nader inzien te ingewikkeld, men heeft toch liever twee wat rustiger schermen. Als het bij enkele en voorna­

Bij de grote ICT­projecten van de Nederlandse overheid (vaak ICT­projecten voor de invulling van grote politieke ambities) wordt de opleverdatum vaak al vastgesteld op 1 januari van het derde zittingsjaar van een kabinet, voordat de feitelijke inhoud van het systeem bekend is (Verhoef, 2006). Het is niet ondenkbaar dat in een aantal van deze gevallen het door Putnam beschreven scenario voorkomt, maar dan desastreuzer.

Systeemomvang en tijdsdrukGrotere systemen blijken in de meeste studies duurder per functiepunt. Nadere studie geeft echter aan dat grotere systemen ook worden ontwikkeld met grotere teams (Jones, 2000). Doorlooptijden worden in de praktijk op een andere basis gekozen dan vanuit het oogpunt van budgetoptimalisatie! Sommige stelselwijzigingen kunnen bijvoorbeeld alleen op 1 januari worden ingevoerd, politieke ambities kunnen een snelle oplevering vragen. Figuur 3 geeft een beeld van de teamgrootte en doorlooptijd die in de praktijk ontstaan bij oplopende systeemomvang. Dit beeld is uitgesplitst naar het meest productieve kwart en het gemiddelde van de organisaties.

Praktijkvoorbeeld van Putnam (1991)Het voorbeeld betreft de ontwikkeling van een adminis-tratief systeem in COBOL ter grootte van 75.000 Lines of Code (ruim 700 functiepunten), door een organisatie met een gemiddelde systeemontwikkelingsproductivi-teit. Het verloop van de discussie tussen de lijnmanager en de externe systeemontwikkelaar:

•De systeemontwikkelaar maakt een optimale planning voor de ontwikkeling, waarin met een doorlooptijd van 13,6 maanden en een maximale omvang van het ontwikkelteam van 6 personen, het systeem voor $ 416.000 ontwikkeld zal worden. Bij een dergelijke aanpak is een Mean Time To Defect te verwachten van 4,8 dagen.

•De opdrachtgever heeft echter grote haast met het systeem en geeft opdracht een planning op te stel-len met minimale doorlooptijd. Deze komt uit op een doorlooptijd van 8,3 maanden. Om deze tijd te halen is een team nodig dat tijdens de realisatie bestaat uit 66 personen. De kosten stijgen daardoor naar $ 3.000.000.

•Gezien de potentiële revenuen van het systeem gaat de opdrachtgever met deze begroting akkoord.

•Wat men hem echter niet had verteld is dat er bij een dergelijke teamgrootte een veel grotere kans op fou-ten is. Dat blijkt bij de oplevering: de Mean Time To Defect is 0,4 dagen. Dat is natuurlijk niet acceptabel, een systeem dat gemiddeld meer dan 2 keer per dag ‘plat’ gaat.

•Voor de werkzaamheden om het systeem de oor-spronkelijk gedachte betrouwbaarheid te geven (een MTTD van 4,8 dagen), blijkt een extra doorlooptijd van 4 maanden nodig, en de kosten daarvan bedragen $ 1.600.000.

Het resultaat is dat het systeem ruim 11 keer zo duur is geworden, terwijl de bespaarde tijd 1,3 maanden bedraagt ten opzichte van de oorspronkelijk begrootte 13,6 maanden.

teamgrootte

product 100 functie-punten

1000 functie-punten

gemiddeld‘best in class’

11

74

6744

••doorlooptijd [mnd]

gemiddeld‘best in class’

5,84,0

15,910,5

43,733,1

••

10.000 functie-punten

Figuur 3. Teamgrootte en doorlooptijd bij toenemende systeemomvang

info

rmat

ie /

apr

il 20

12

iover

heid

14

Bij de uitbesteding van ICT­projecten in de han­del, industrie en overheid (in Finland) werd daar veel minder ruimte aan geboden. Dit betekent (als de softwareontwikkeling op zich in beide groepen even productief is) dat de hoeveelheid werk in omgevingen met meer wijzigingen in de speci­ficaties gemiddeld het dubbele bedraagt dan in omgevingen met weinig wijzigingen in de specifi­caties. Hierdoor wordt de tijdsdruk dus aanzienlijk opgevoerd. Sommige organisaties weten de divergerende krachten te beteugelenEen groot aantal factoren is van invloed op de productiviteit van de ontwikkeling van software. De literatuur geeft meer dan 250 factoren waar­van is vastgesteld dat zij de productiviteit van systeemontwikkeling beïnvloeden (Jones, 2007). Dit betreft factoren van technische en methodi­sche aard, maar vooral ook een aantal factoren van menselijke en organisatorische aard. Wanneer alle beïnvloedende factoren ‘vrij spel’ hebben, zijn de kosten van systeemontwikkeling zo goed als

melijk cosmetische wijzigingen blijft, is er niets aan de hand. Maar er zijn ook projecten met veel wijzigingen en uitbreidingen. Deze wijzigingen en uitbreidingen resulteren maar voor een deel in een uitbreiding van de omvang in functiepunten, met dat deel beïnvloeden ze de productiviteit dus niet. Maar voor een belangrijk deel komen de wijzigin­gen in de plaats van al gemaakte functionaliteit. Dan is er dus een inspanning nodig zonder dat er omvang aan het systeem wordt toegevoegd. Goede registraties van de hoeveelheid wijzigingen en van de bijbehorende inspanning vinden zelden plaats.Hoewel het effect van veranderende specificaties dus niet direct gemeten is, zijn er wel waarne­mingen die aannemelijk maken dat dit effect aanzienlijk is. In Finland werd een verschil van een factor 2 in productiviteit waargenomen tussen het bank­ en verzekeringswezen enerzijds en de sectoren handel, industrie en overheid anderzijds. Het bank­ en verzekeringswezen kwam tot twee keer hogere kosten voor systeemontwikkeling doordat er in de intern uitgevoerde projecten meer mogelijkheden waren om specificaties te wijzigen.

inspanning[u]

omvang [functiepunten] ISBSGoverheidorganisatie 1organisatie 2

00 1000500 20001500 30002500

10.000

20.000

30.000

40.000

50.000

60.000

70.000

80.000

90.000

100.000

Figuur 4. De voltooide systemen van twee Nederlandse overheidsorganisaties verbijzonderd

info

rmat

ie /

apr

il 20

12

15

Conclusies en aanbevelingHet voorgaande leidt tot de volgende conclusies:

a. Er is een enorme variatie van een factor 10 tot 15 in de kosten per eenheid waar te nemen bij voltooide systemen. Het beeld bij de Neder­landse overheid komt grotendeels overeen met het beeld van de systemen in andere sectoren en landen (mogelijk licht ongunstiger voor de Nederlandse overheid). Daarbij dient wel te worden aangetekend dat het materiaal geen van ‘de grote ICT­projecten’ bevatte.

b. De kosten van softwareontwikkeling worden beïnvloed door een groep factoren die onderling afhankelijk zijn en elkaar kunnen versterken. Productiviteit en omvang van het ontwikkel­team, verkorting van de doorlooptijd en veran­derende specificaties vormen interacterende en niet afzonderlijk te kwantificeren ‘drivers’ voor toenemende kosten en doorlooptijden.

c. In de meeste overheidsorganisaties leiden deze factoren tot een grote variatie in kosten en doorlooptijden bij de ontwikkeling van sys­temen. In deze organisaties zouden eigenlijk geen planningen meer afgegeven mogen wor­den, maar alleen bandbreedtes in kosten en doorlooptijd die gebaseerd zijn op beschikbare kennis.

d. Het goede nieuws is dat in de portfolio van systemen van de Nederlandse overheid enkele organisaties voorkomen die de divergerende factoren bij de voorspelbaarheid van kosten en doorlooptijden hebben weten buiten te sluiten.

e. De directe kosten van deze suboptimaal dure systeemontwikkeling zijn voor de Nederlandse overheid fors. In de paragraaf ‘Sommige organi­

onvoorspelbaar (een factor 10 tussen optimistisch en pessimistisch).Het is de vraag of het mogelijk is om door het uitschakelen van divergerende factoren toch tot beperking van de variatie en daarmee tot voorspel­bare systeemontwikkeling te komen. Dat uitscha­kelen zou kunnen door een betere inhoudelijke kwaliteit van specificaties. Of door technisch uniform te werken, met steeds een vaste aanpak. Of door te werken met teams van een optimale grootte en een bekende vaste productiviteit. In het overheidsmateriaal van voltooide projecten komen enkele organisaties voor met meer dan vijf voltooi­de projecten. Twee van deze organisaties komen in hoge mate overeen: vrijwel dezelfde technische basis (database en ontwikkeltools) en zij ontwikke­len beide hetzelfde type administratieve systemen. In figuur 4 worden de voltooide projecten van deze twee organisaties uitgelicht.In figuur 4 is al te zien dat de variatie in produc­tiviteit (uren per functiepunt) bij organisatie 2 aanzienlijk groter is dan bij organisatie 1. Figuur 5 geeft deze variatie voor beide organisaties weer. Bij organisatie 1 worden de projecten voltooid met een inspanning die ligt tussen de 3 en de 8 uur per functiepunt. Bij organisatie 2 ligt de productiviteit van voltooide projecten tussen de 8 en de 38 uur per functiepunt. In het materiaal van voltooide projecten is ook nog een tweede organisatie te zien waar de voltooide projecten eenzelfde voor­spelbaar beeld te zien geven als de in de figuur getoonde organisatie 1. Daarmee lijkt de conclusie gerechtvaardigd dat het sommige organisaties lukt om ‘regie te krijgen’ op de factoren die in andere organisaties voor veel variatie in de productiviteit zorgen.

uren perfunctiepunt

0

organisatie 1 organisatie 2

5

10

15

20

25

30

35

40

Figuur 5. Uren per functiepunt in de twee overheidsorganisaties

info

rmat

ie /

apr

il 20

12

iover

heid

16

LiteratuurComstock, C., Z. Jiang & P. Naudé (2008). Risk analysis in

software development. Proceedings of the 8th conference on Applied Informatics and Communications, AI’C08, Stevens Point, Wisconsin.

Dekker, V. (2008). ICT is bij de overheid één groot zwart gat. Trouw, 12 maart 2008.

ISBSG (2000). The Benchmark, release 6: an analysis of factors that affect the productivity, delivery, time, quality and cost of software projects. International Software Benchmarking Standards Group.

Jones, C. (2000). Software Assessment, Benchmarks and Best Practices. Addison Wesley Longman.

Jones, C. (2007). Estimating Software Costs, Bringing Realism To Estimating (2nd ed.). McGraw­Hill Osborne.

Kemerer, C.F. (1993). Reliability of Function Points Measurement, a field experiment. Communications of the ACM, Volume 36, Issue 2.

Maxwell, K.D. (1998). Benchmarking software development productivity: statistical analysis by business sector. Project Control for 2000 and Beyond. Maastricht: Shaker Publishing.

Maxwell, K.D. & P. Forselius (2000). Benchmarking Software Development Productivity, IEEE Software, Volume 17, Issue 1.

Oosterhout, B. van (2007). Het ICT­drama: hoe de overheid miljarden verspilt. Intermediair, 12 december 2007.

Putnam, L.H. (1991). Measuring Software Process Improvement and Controlling Development. NOVI­conferentie Productiviteitsverbetering in softwareontwikke­ling, Amsterdam, december 1991.

Verhoef, C. (2006). Explosief mengsel. Digitaal Bestuur, april 2006.

Ir. Lauran Matthijssenis senior adviseur bij Het Expertise Centrum. E­mail: l.matthijssen@hec.nl.

saties weten de divergerende krachten te beteugelen’ werden de projecten getoond van een overheidsorganisatie die de verstorende factoren wel wist uit te slui­ten. Als de gehele portfolio van 120 systemen van de Nederlandse overheid met deze ‘best in class’ productiviteit zou zijn uitgevoerd, dan was maar 30 procent van het nu gespendeerde bedrag van 260 miljoen euro nodig geweest.

Dit leidt tot de volgende aanbeveling:

Er zijn organisaties waar systemen volgens plan­ning worden ontwikkeld. Bij die organisaties zijn, op basis van de steekproef uit dit artikel, de kosten maar een derde van het gemiddelde bij overheids­organisaties. Dit gegeven zou moeten leiden tot grote nieuwsgierigheid bij het topmanagement van overheidsorganisaties, zeker bij de organisaties waar de processen en diensten afhankelijk zijn van ICT. De eerste stap voor dat nieuwsgierige top­management zou moeten zijn om binnen de eigen organisatie een ‘meet­ en regelsysteem’ voor ICT­toepassingen te eisen. Een tweede stap zou moe­ten zijn om de kenmerken te bestuderen van de organisaties die ‘best in class’ opereren, en de wijze waarop het management daar met ICT omgaat.

Reviewer Wijnand Westerveld

»Bij de organisaties waar systemen volgens planning worden ontwikkeld, zijn de kosten maar een derde van het gemiddelde bij overheids organisaties«