Verbeter het opdrachtgeverschap

Grote en innovatieve IT-projecten bieden vaak niet wat de opdrachtgever ervan verwacht. In een eerder artikel (Ga verder dan Gateway) hebben we hiervoor diverse overheidsspecifieke faalfactoren en een oplossingsrichting aangegeven. In dit artikel presenteren we 10 principes voor goed opdrachtgeverschap waarmee opdrachtgevers de slaagkans van hun IT-projecten aanzienlijk kunnen verhogen.

Iedereen weet het: grote IT-projecten voldoen zelden of nooit aan de verwachtingen van de opdrachtgever. Systemen blijken onbruikbaar te zijn of zitten vol fouten, budgetten en planningen worden overschreden, projecten worden stopgezet. Het ministerie van BZK heeft recent maatregelen aangekondigd die ervoor moeten zorgen dat er minder overheidsgeld verspild wordt aan IT-projecten. Eén van de maatregelen betreft het verbeteren van het informatiemanagement binnen de departementen, waaronder het opdrachtgeverschap voor projecten. Wat er onder ‘verbeterd opdrachtgeverschap’ wordt verstaan, wordt echter niet uiteengezet.

We kunnen vanuit onze ervaring beamen dat falend opdrachtgeverschap een belangrijke factor is bij het mislukken van IT-projecten. Enerzijds zie je vaak dat opdrachtgevers bij de opdrachtformulering steken laten vallen: ze maken de opdracht te groot en te complex, ze durven geen keuzes te maken, ze sluiten onvoldoende aan bij de bestaande werkelijkheid. Anderzijds valt op dat leveranciers vaak ineffectief worden aangestuurd: de opdrachtgever verstrekt onvoldoende informatie, hij geeft de regie te veel uit handen, hij stuurt alleen op geld en tijd (en niet op kwaliteit en resultaat) en hij sluit de ogen voor technische beperkingen en risico’s die de leverancier aandraagt.

In dit artikel formuleren we 10 principes voor het verbeteren van opdrachtgeverschap binnen de overheid. Hiermee beogen we een bijdrage te leveren aan het professionaliseren van het opdrachtgeverschap binnen de overheid. We zijn van mening dat een breed gedragen begrip van ‘goed opdrachtgeverschap’ cruciaal is om de slaagkans van projecten te verhogen.

Het CMMI model for Acquisition (zie kader) maakt duidelijk dat het takenpakket van de opdrachtgever breed en divers is.

CMMI model for Acquisition
Het Britse Software Engineering Institute heeft een volwassenheidsmodel voor opdrachtgeverschap ontwikkeld: CMMI for Acquisition. Deze variant op het bekende CMMI model maakt duidelijk welke taken de opdrachtgever zoal heeft. Een aantal voorbeelden hieruit die de breedte en de diversiteit van het takenpakket aangeven:

- Taken van opdrachtgever in voortraject.

- Gewenste veranderingen vormgeven en motiveren (business case, PID).

- Requirements aan de IT-producten opstellen.

- Aanbesteden, leverancier selecteren.

- Projectorganisatie en stuurprocessen inrichten.

- Taken van opdrachtgever tijdens project

- Afstemmen met alle belanghebbenden.

- Leveranciersmanagement voeren.

- (Deel)producten valideren en verifiëren.

- Voortgang bewaken en bijsturen.

- Risicomanagement.

- Acceptatietesten verzorgen.

- Implementatie binnen de organisatie verzorgen.

Deze taken zijn meestal niet aan één persoon te koppelen. Overheidsprojecten verlopen vaak binnen een context waarin een groot aantal partijen haar belangen inbrengt: diverse directoraten, staven, andere ministeries, decentrale overheden, ketenpartners, beleidsmakers, de CIO, architecten, portfoliomanagers en beheerders. Veel projecten kennen een hiërarchie van (gedelegeerde) opdrachtgevers. Multi-departementale projecten kennen zelfs meerdere hiërarchieën. Onderstaande principes richten zich niet selectief op die ene persoon die formeel de opdrachtgever is maar op de hele opdrachtketen.

Principe 1: weet wat je écht nodig hebt
Het is verbazingwekkend hoe vaak we meemaken dat het aan de leverancier wordt overgelaten om de eisen aan het systeem vast te stellen. De gevolgen laten zich raden: veel overbodige functionaliteit, er wordt voorbijgegaan aan eisen t.a.v. beheer en betrouwbaarheid, de leverancier dekt zich in tegen wijzigingen. Beter is het om:

- zelf de regie te houden bij het opstellen van de requirements;

- de business case op zo’n niveau uit te werken dat duidelijk is welke functies de meeste toegevoegde waarde hebben;

- bij elk op te leveren (deel)product aan te geven aan welke kwaliteitseisen het moet voldoen;

- vóóraf aan de leverancier te vragen naar de kosten van een aantal verwachte wijzigingen op het systeem.

Principe 2: verbind belanghebbende partijen
We hebben projecten meegemaakt waarbij de leverancier de enige verbindende factor was tussen de betrokken afdelingen en departementen. De wensen van gebruikers, beheer, bedrijfsarchitecten en ketenpartijen werden door de leverancier gewogen, pas bij oplevering bleek welke keuzes hij had gemaakt. Beter is het om:

- zelf prioriteiten te stellen tussen de eisen ten aanzien van functionaliteit, betrouwbaarheid, beheerbaarheid, performance etcetera;

- de eisen te vertalen naar acceptatiecriteria die door alle belanghebbenden worden onderschreven;

- zelf te bewaken dat ketenpartijen hun processen en interfaces afstemmen op het nieuwe systeem.

Principe 3: beperk en bevries de scope
Bij de overheid zie je regelmatig pogingen om enorme systemen in één keer te specificeren, waarna een leverancier er jarenlang aan mag bouwen. Zo’n ‘big design up front’ in combinatie met een watervalmethode is bewezen onsuccesvol, het houdt geen rekening met wijzigende inzichten. Beter is het om:

- iteratief te werken. Ontwikkel binnen een beperkte tijd (b.v. 3 maanden) een overzichtelijke hoeveelheid functionaliteit. Begin hierbij met de meest risicovolle functies en onderdelen. Breidt vervolgens het systeem uit in volgende iteraties, totdat je tevreden bent;

- baselining en change control toe te passen: bevries opgeleverde (tussen)producten voor de duur van de iteratie, gewenste wijzigingen worden doorgeschoven naar een volgende iteratie.

Principe 4: vraag garanties ten aanzien van bemensing
Aan offertes worden altijd indrukwekkende cv’s toegevoegd, maar na gunning van de opdracht blijken er vaak nieuwe personen op te duiken. Projectsucces is voor een substantieel deel afhankelijk van de kwaliteit van de mensen. Stel daarom eisen ten aanzien van:

- de ervaring en continuïteit van sleutelspelers bij de leverancier (projectleider, architect, testmanager). Voer gesprekken met deze personen voordat je met ze in zee gaat. Ga, in geval van de India-route, na of ze ervaring hebben met het aansturen van overzeese ontwikkelingen;

- de ervaring en continuïteit van het eigen personeel. Zorg dat alleen de beste mensen, met voldoende relevante IT-kennis, in het project participeren. Dit geldt zowel voor het projectteam zelf als voor klankbordgroepen en stuurgroepen.

Principe 5: stem processen en tooling af
Grote IT-leveranciers nemen tegenwoordig een standaard werkwijze en standaard tooling mee waar ze aan gewend zijn. Er ontstaan grote communicatieproblemen wanneer dit niet matcht met de werkwijze bij de opdrachtgever. Stem processen en tooling af op de volgende punten:

- de manier waarop requirements en specificaties worden uitgewerkt (use cases hebben de voorkeur boven traditionele functioneel ontwerpen);

- architectuur- en ontwerpdocumentatie dient aan de standaards en richtlijnen van de toekomstige beheerpartij te voldoen;

- zorg dat testdocumentatie wederzijds hetzelfde is vormgegeven, zorg dat je dezelfde testtools (testmanagement, testaansturing en –analyse, bevindingenregistratie) hanteert.

Principe 6: wees alert op hergebruik
Het gebruik van generieke componenten en open source oplossingen klinkt altijd prachtig: je kunt veel kosten besparen door services één keer te bouwen en meerdere keren te gebruiken. Foutief hergebruik heeft projecten echter al vaak in de problemen gebracht: denk aan de vele mislukte multi-departementale initiatieven. De volgende regels helpen problemen te voorkomen:

- ontwikkel eerst specifieke diensten. Pas indien twee of meer vergelijkbare diensten langere tijd succesvol hebben gedraaid is het zinvol om een generieke (multi-departementale) oplossing te onderzoeken;

- laat het niet aan de leverancier over om open source producten in te zetten. Ga ook zelf na of de continuïteit van zo’n component afdoende gewaarborgd is;

- ga na of de baten van hergebruik niet alleen in de zak van de leverancier verdwijnen, profiteer zelf mee.

Principe 7: vraag QA-rapportages op
Leveranciers verantwoorden zich meestal goed waar het de urenbesteding en de voortgang betreft. Veel opdrachtgevers nemen hier genoegen mee, ze sturen primair op tijd en geld. Het loont om ook eens kwaliteitsrapportages op te vragen:

- verslagen van reviews die de leverancier intern heeft uitgevoerd bevatten nuttige informatie;

- kwaliteitsmetrieken, zoals inspanning per geleverd functiepunt, aantallen bugs per functiepunt, de reuse rate, complexiteitsmaten van de code, test coverage en change rate geven veel inzicht in de prestaties van de leverancier. Historische trendanalyses en benchmarks met andere projecten worden hierdoor mogelijk.

Principe 8: controleer ook zelf op inhoud
Mijlpalen worden steevast gehaald: op de afgesproken dag worden beloofde documenten en releases om 18:00 uur opgeleverd. Vaak blijken er echter zaken te ontbreken: alleen de ‘happy flow’ is gerealiseerd, unittesten zijn nauwelijks uitgevoerd, gemaakte ontwerpkeuzes frustreren de lange termijndoelen. Blind vertrouwen in de leverancier is onvoldoende, houdt hem scherp:

- laat je eigen specialisten opgeleverde producten reviewen. Neem hun opmerkingen serieus, durf bij te sturen als de kwaliteit te wensen over laat;

- stel vooraf kwaliteitscriteria op waaraan de leverancier zich moet houden en stem die af;

- kijk eens in de code. Onder tijdsdruk buigen de programmeurs het eerst, met grote regelmaat zien we constructies die uit oogpunt van performance, betrouwbaarheid of onderhoudbaarheid ongewenst zijn.

Principe 9: evalueer bij elke faseovergang
Projectmanagers hebben vaak prima door hoe hun project er voorstaat, maar zolang ze hun gevoel niet kunnen onderbouwen grijpen ze niet in. Door regelmatig te evalueren kunnen vage onrustgevoelens worden onderbouwd:

- organiseer evaluatiesessies met alle betrokken partijen (gebruikers, leveranciers, beheerders, architecten). Kijk hierbij niet alleen terug (wat ging er mis) maar ook vooruit (wat moet anders, welke risico’s zien we);

- heroverweeg/ herbereken de business case. Dit is een prima manier om op basis van waardevrije argumenten te bepalen of het project nog op koers zit of niet.

Principe 10: werk samen met de leverancier
Sommige opdrachtgevers zijn van mening dat de leverancier de volledige regie kan voeren over het IT-deel van hun project. Andere opdrachtgevers hebben juist de neiging om de leverancier tot op detailniveau aan te sturen waardoor die geen manouvreerruimte meer heeft. Beide uitersten zijn niet effectief. Alleen door samen op te trekken kan de leverancier voldoende toegevoegde waarde leveren:

- stel geen onnodige technische eisen aan de leverancier. Biedt hem de ruimte om optimalisaties door te voeren. Laat hem wel rapporteren welke keuzes hij heeft gemaakt en waarom;

- luister naar de leverancier. Zijn technische blik op de materie kan tot relevante beperkingen en tot verfrissende verbeteringen leiden;

- trust but verify. Vertrouw erop dat de leverancier professioneel werk levert. Maar laat wel één van je eigen specialisten controleren of dat ook daadwerkelijk zo is.

George Leih is senior adviseur bij DNV-CIBIT. Het artikel is een geactualiseerde en op de overheid toegespitste versie van een eerder gepubliceerd artikel op www.goedopdrachtgeverschap.nl.