zoeken binnen de website

ICT-contracten naar Deens ontwerp

Joost Visser

door: Joost Visser | 13 februari 2013

In Denemarken hebben ze er iets op gevonden. Net als in Nederland zijn daar in het recente verleden een aantal grote ICT-projecten bij de overheid op dusdanige wijze mislukt dat het breed uitgemeten werd in de pers. Terwijl wij wachten op de uitkomsten van een parlementair onderzoek naar de omvang van de schade, hebben de Denen K03 in stelling gebracht.

K03?

K03 is het koosnaampje van het nieuwe modelcontract voor levering van grote ICT-projecten aan de Deense overheid. Het bijzondere aan dit modelcontract is dat het leveranciers verplicht stelt mee te werken aan inspecties op technische kwaliteit, waarbij de ISO 25010 standaard voor software product kwaliteit als leidraad genomen wordt.

De ISO 25010 standaard definieert zaken zoals betrouwbaarheid, onderhoudbaarheid, veiligheid, en overdraagbaarheid. Met deze standaard als basis kan een meetsysteem worden ingericht dat het verschil aan het licht brengt tussen software die gebouwd is volgens de regelen der kunst (goede architectuur, netjes geprogrammeerd, gebruikmakend van moderne bouwstenen) en software die houtje-touwtje aan elkaar hangt. Een APK voor software systemen dus.

Ik hoor u denken: is het zo bijzonder dat er eisen rond technische productkwaliteit in een ICT-contract staan? Is dat niet de gewoonste zaak van de wereld?

Onzichtbaar

Het zou de gewoonste zaak van de wereld moeten zijn, maar de werkelijkheid is anders. De functionele kwaliteit van ICT-systemen en -diensten wordt door gebruikers direct ervaren en kan door de opdrachtgever beschreven en beoordeeld worden. Maar technische kwaliteit is niet direct zichtbaar. Dit verklaart waarom eisen rond technische kwaliteit vaak vergeten worden bij het uitvragen van dienstverlening en pas de kop op steekt wanneer ontwikkeling of uitrol hapert.

En dát gebrek aan technische kwaliteit de kop op steekt, hoeft dus ook niemand te verbazen. Wanneer tijd en budget worden vastgesteld, maar kwaliteit wordt losgelaten, zal dat de plek zijn waar dingen gaan schuiven. En op het moment dat technische kwaliteit té ver wegzakt volgen tijd en budget vervolgens dezelfde weg. Uitstel en budgetoverschrijding zijn dan ons deel, met als onderliggende oorzaak gebrekkige borging van kwaliteit.

De Deense aanpak

In Denemarken beheert de landsadvocaat een aantal modelcontracten die door overheidsdiensten worden gebruikt bij het inkopen van ICT-diensten. Door in het meest recent gepubliceerde modelcontract (K03 dus) clausules op te nemen die onafhankelijke inspecties op technische kwaliteit mogelijk maken, krijgen opdrachtgevers een instrument in handen om een belangrijke onderliggende oorzaak van falende ICT-projecten weg te nemen. Al tijdens de ontwikkeling kunnen dergelijke inspecties op basis van ISO 25010 worden uitgevoerd om vroegtijdig in te kunnen grijpen en kostbare ‘runaway’ projecten te vermijden.

Overigens kunnen ook de opdrachtnemers baat hebben bij dit nieuwe instrument. Ook zij kunnen onafhankelijke technische inspecties laten uitvoeren, bijvoorbeeld om te laten zien dat het project bij hen in goede handen is en om tegendruk te geven tegen al te wispelturige opdrachtgevers.

Goede ervaringen

De Denen hebben hoge verwachtingen bij deze nieuwe aanpak, mede omdat ze al goede ervaringen hiermee hebben opgedaan. Zou het het overwegen waard zijn om die Deense contractclausules eens naar het Nederlands te vertalen?

Prof. dr. ir. Joost Visser is hoogleraar ‘Large Scale Software Systems’ aan de Radboud Universiteit Nijmegen en Hoofd Research bij de Software Improvement Group

reacties: 3

tags: , , , ,

  • Rene Brozius (Lakeview Audit) #

    13 februari 2013, 16:45

    Bij mijn weten hebben ARVODI/ARBIT gebaseerde overeenkomsten nog nooit enige inspectie in de weg gestaan, gebaseerd op welke standaard of normenkader dan ook.

    Daarnaast zijn de uit de literatuur en praktijk bekende oorzaken voor projectfalen heel anders van aard: creeping scope, grand design ambities, fantasy deadlines, etc. Zie Chris Verhoef et al voor een meer gedetailleerde behandeling. Niet valt in te zien hoe dit K03 initiatief hierin verbetering zal gaan brengen.

    En verder gaat dit voorbij aan de ontwikkeling dat overheden (en bedrijfsleven) juist meer en meer diensten willen gaan afnemen i.p.v. zelf maatwerk systemen (laten) bouwen. Inspectie van (tussen)resultaten staat m.i. haaks op deze ontwikkeling.

    Kortom, gezien de naar mijn mening wel zeer beperkte toepasbaarheid van deze “oplossing” heb ik er geen al te hoge verwachtingen van dat een NL equivalent zal leiden tot minder ICT projecten die “op hun kant gaan”.

  • Peter Westerhof (zelfstandig) #

    14 februari 2013, 13:07

    Als ICT-projectmanager en van huis uit ICT-/bestuursjurist kan ik alleen maar aanbevelen de IT-contracten zoveel mogelijk faciliterend in te richten.
    Dwz. hoe meer het contract regelt hoe minder manouvreerruimte het project heeft. En uiteindelijk gaat het toch om het project.

    We zijn een heel eind gekomen sinds de BiZa-modelcontracten.
    Dat neemt niet weg dat elke pragmatische aanvulling is meegenomen.
    De huidige projectmanagement-methodieken faciliteren echter reeds kwaliteitssystemen en daarmee allerlei toetsen en controles. Zowel bij projectdefinitie, ontwerp, fase-overgangen en test/implementatie,
    Inmiddels is daar vanuit opdrachtgevers-optiek nog de Gateway-methodiek bij gekomen.

    Business Risk Management, Goed Opdrachtgeverschap en scope-management als voornaamste projectsuccesfactoren zijn vooral gebaat bij realisme en pragmatiek.

  • Ruud Leether #

    9 juli 2013, 01:12

    Inderdaad, Rene Brozius wijst daar hierboven al op, bevatten de ARBIT geen enkele belemmering voor dergelijke onafhankelijke inspecties op kwaliteit, Sterker nog, ze bevatten zelfs een expliciet daarvoor bedoelde bepaling nl. artikel 5 genaamd Kwaliteitsborging. Blijkens de toelichting op dat artikel is sprake van een kapstokbepaling die al naar gelang de omvang en het belang van een project kan worden uitgewerkt in de overeenkomst. Kortom we waren de Denen op dit specifieke onderwerp dus ruim voor….

Reactieformulier

De met een * gemarkeerde velden zijn verplicht. U ziet eerst een voorbeeld en daarna kunt u uw bijdrage definitief plaatsen. Uw e-mailadres wordt niet op de site getoond. Reacties zonder achternaam worden verwijderd. Anoniem reageren alleen in uitzonderlijke gevallen in overleg met de redactie. U kunt bij de vormgeving van uw reactie gebruik maken van textile en er is beperkt gebruik van html mogelijk.