'Klanten houden geen toezicht op hun it-leveranciers.' 'Mislukt ict-project kost miljoenen.' 'Directeur onderschat rol leverancier.' 'Outsourcing mislukt door gebrek aan controle.' De gretige lezer van ict-media wordt met dit soort nieuwsberichten om de oren geslagen. Googelen op 'mislukt it-project' levert circa 21.200 hits in 0,13 seconden. Het is interessant de vraag te stellen hoe het komt dat de ict-markt als branche niet in controle lijkt te kunnen komen.
Geen controle over tijd, geld en kwaliteit. En dit terwijl 'QA' (Quality Audit of Assurance) een gebezigde term is in de wereld van projectbesturing. Degene die QA invult is echter vaak een persoon met de bekende 'meerdere petten'; een afgezant van de leverancier die, naast deze QA-rol, ook een operationele rol in het project bekleedt. Of er wordt een partij, die niet bij het project betrokken is, gevraagd een audit of second opinion uit te voeren. Deze partij is in de praktijk vaak een concurrent van de huisleverancier van deze klant. Het is vragen om problemen, want de belangenstrijd loert. Wat vaak ontbreekt in het speelveld is een heuse objectieve 'derde onafhankelijke partij'. Een partij die een podium creëert voor een dialoog die zich uitsluitend richt op kwaliteit en projectsucces voor alle betrokkenen.
Projectmethodieken genoeg, zoals Prince II en PMI. En dan is er ook nog ITIL, ASL/BISL, Scrum, CMMI, SLA's. Deze methodieken scheppen verwachtingen. Het zijn echter veelal methodes en modellen die ingrijpen op een proces. De ict-industrie is wellicht de enige technische industrie waar technische productcontroles niet of nauwelijks worden uitgevoerd. Let wel, er is veel aandacht voor functionele productcontroles. Acceptatietesten, eindgebruikerstesten. Noem ze maar op, en dan zijn er nog de performance-, security- en stress-testen. Deze laatste zouden zeker in de categorie 'technische productcontrole' kunnen vallen. Wat vaak ontbreekt is een controle van de techniek op het laagste detailniveau: de broncode. Programmeurs testen hun eigen werk: unit-testing. Dan worden er vaak ook peer-reviews gedaan. Maar technische controles uitvoeren om zo toezicht te houden op softwareproducten en de leveranciers die eraan werken komt niet of nauwelijks voor. De motorkap blijft dicht. De binnenkant van de black box hoeft het daglicht niet te zien. Dat is jammer, want een gemiste kans.
Code review
Een code review is namelijk een eenvoudig uit te voeren controle, is feitelijk én objectief te maken. Er zijn standaarden voor ontwikkeld, er is zelfs een ISO-standaard die gehanteerd kan worden en de meeste software developers kennen ook vaak de onderliggende softwaremetrieken. Als bekend voorbeeld van zo'n metriek geldt de McCabe-index, die aangeeft hoe complex een stuk software is. Té complex is niet goed, want leidt tot niet testbare code.
Veel leveranciers hebben echter hun eigen oplossingen om projecten 'in het gareel' te houden. Denk dan voornamelijk aan de Quality Assurance, Quality Officer soort van rollen en projectorganen. De dames en heren in dit type rollen kijken met kritische en frisse blik naar de issue en risicolijsten waarmee projectmanagers aan een stuurgroep rapporteren. Ze hebben doorgaans geen operationele projectverantwoordelijkheid en worden daarom geacht 'neutraal' te kunnen zijn.
Mocht het echt uit de hand lopen, wordt er door de klant ook nog wel eens een 'second opinion' gevraagd. Natuurlijk door een partij die verstand van de zaken heeft. Dus vaak betreft het hier een concurrent die gevraagd wordt het project door te lichten. Of de inspanningsinschatting van het project op juistheid en realiteit in te schatten.
Daarnaast is er nog een derde categorie van een vermeende 'derde onafhankelijke partij': de auditor. Veel ict-dienstverleners, vooral diegene die actief zijn in het bouwen en implementeren van software, hebben een dienst genaamd 'audit' op de prijslijst staan. Eén van hen was eens zo eerlijk op te biechten dat dat zijn beste acquisitiekanaal was. Je kwam namelijk binnen op het moment dat de relatie tussen de klant en zijn huisleverancier toch al niet zo goed was. Er is op ieder project en inschatting wel iets aan te merken et voilá: de oude leverancier mocht gaan en de auditerende partij was binnen. Opmerkelijk.
Om verschillende redenen is het raadzaam kritisch te bekijken of bovengenoemde 'derde onafhankelijke partijen' echt onafhankelijk kunnen (of willen) acteren. Er zijn altijd meerdere drijfveren aanwezig naast die van het uitvoeren van de quality control, second opinion of audit. Vaak gaat het om commerciële belangen.
Om nog een voorbeeld te geven. De leverancier bemant in het onderhavige project een aantal teams. Echter: het team dat de business requirements moet vastleggen wordt vooral door mensen van de klant bemand. Dat is logisch, zij hebben immers de noodzakelijke business kennis. Het bouwteam wacht op de output van dit klantteam. Het QA team, vaak bemand door klant en leverancier, stelt dat vast dat het bouwteam te lang op de business requirements moet wachten en stelt de stuurgroep voor een aantal keuzes. Ofwel de mensen van de klant moeten meer tijd aan het project gaan besteden: vaak niet mogelijk door hun taken in het primaire bedrijfsproces. Ofwel, er moeten mensen bij, natuurlijk van de klant. Of, zou de leverancier niet bij kunnen springen? Het moment om waakzaam te zijn. Het is lastig deze commerciële kans te laten liggen. Hoe integer de leverancier ook wil handelen, de tweede pet jeukt op zijn hoofd. Er wordt nog wat gemort 'dat zou kunnen maar dan alleen helpen bij het administreren, requirements uit de business halen of workshops begeleiden'. Het mag niet baten. Tegen beter QA-weten in is de man of vrouw in kwestie ineens degene die extra inspanning zit te verkopen. En daarbovenop: het feit dat het team groter wordt, wil in de praktijk niet per se betekenen dat de resultaten sneller komen.
Een ander belang dat vaak speelt is de dynamiek van enerzijds de klantrelatie en anderzijds de concurrentiestrijd. Veel duidelijker dan middels de volgende vraag is dit niet uit te leggen. Hoe makkelijk is het om te zeggen dat je concurrent het best goed aanpakt, maar de klant (voor de leverancier nog een prospect) het opdrachtgeverschap onvoldoende goed invulling geeft? Het druist wellicht minder hard tegen het ondernemersinstinct van de leverancier in zich kritisch uit te laten jegens een concurrent dan zich kritisch uit te laten jegens een eventuele nieuwe klant.
De derde partij
De derde onafhankelijke partij. Bestaat deze? Jawel. Deze partijen bestaan. Het zijn namelijk de partijen die geen producten, consultants, programmeurs, projectmanagers etcetera leveren, maar echt alleen ambiëren de derde partij te zijn die toezicht houdt. Daarnaast kunnen bedrijven, die in de regel wel andere diensten aanbieden naast audit diensten, daar vanaf zien voor de komende x aantal jaar. Zo worden zij ook onafhankelijk, neutraal en objectief. Zo scheidt je de belangen heel zuiver.
Van deze derde onafhankelijke partij, de toezichthouder, mag je verwachten dat zij alle neuzen (ongeacht klant of leverancier) dezelfde kant op zet: in de richting van projectsucces voor alle betrokkenen met eindproducten die van goede kwaliteit zijn. Een dergelijke partij kan lucht geven aan een gespannen situatie. Zal zich open en receptief op kunnen stellen voor zowel klant als leverancier. Kan werken als olie op de golven van een stormachtig project.
De kracht van de toezichthouder wordt alleen maar groter wanneer deze naast stuurgroeprapportages, SLA's, issue- en risico-overzichten zich ook laat voeden door resultaten van code-reviews. Niet alleen toezicht houden op de processen, maar ook op de technische kwaliteit van de eindproducten die van de band rollen. Simpel maar doeltreffend. 'Low-tech, high-value.'
Marischa van Zantvoort, sales executive bij de Software Improvement Group
