Hoe kon Equihold toch kopje onder gaan?

Stichting Capclaim strijdt onder leiding van Kenneth Berkleef van het failliete Equihold tegen ict-dienstverlener Capgemini. Inzet is het terugvorderen van 43 miljoen euro schade. Capclaim heeft de afgelopen maanden documentatie aan kenners uit de markt beschikbaar gesteld om hen over deze zaak te laten oordelen. Ook Computable-experts kregen inzage en zullen de komende tijd via deze website hun bevindingen delen. In deze laatste bijdrage uit zijn vijfluik gaat Kurt de Koning in hoe dit alles heeft kunnen gebeuren.

Het conversieproject waarbij Capgemini door Equihold gevraagd is om een bestaande applicatie, 1-2Focus, om te zetten van VB6 naar .Net, heeft voor Equihold niet gebracht wat het ervan verwacht had. In voorgaande artikelen ben ik dieper ingegaan op de beschuldigingen: Equihold verwijt Capgemini software te hebben opgeleverd wat ondeugdelijk en onwerkbaar is. In een reactie wijst Capgemini de beschuldigingen met klem van de hand, maar geeft geen inhoudelijk weerwoord. Uiteindelijk zal de rechtbank hier een definitief oordeel over vellen.

Eenvoudig project

Een vraag die ik hier wil proberen te beantwoorden is, hoe dit heeft kunnen gebeuren. Tenslotte is de opdracht naar mijn mening een van de meest eenvoudige. Een bestaande en werkende applicatie geschreven in VB6 moest worden omgezet in .Net. Technisch moest het zo zijn opgezet dat het een basis was voor verdere ontwikkelingen. Denk daarbij aan verschillende platformen, modulaire opzet, meertaligheid, maar ook diverse sporten moesten parametergestuurd in worden ondergebracht. Anno 2014 zou ik zeker geprobeerd hebben om via een converteertool deze omzetting te laten plaatsvinden. Wellicht was dat in 2005 niet mogelijk of waren er andere redenen waarom gekozen is om de software van scratch af aan opnieuw te schrijven.

Hoewel de beschikbare documenten die ik heb kunnen doornemen gericht zijn op de claim en niet zozeer op de projectaanpak, ga ik toch een poging wagen om te achterhalen wat er tijdens de realisatiefase heeft afgespeeld met daarbij de vraag of hier fouten zijn gemaakt en met de kennis van nu, hadden andere besluiten geleid tot andere resultaten?

Rightshore software developement

In dit geval hebben Equihold en Capgemini gekozen voor een rightsourcing-aanpak waarbij een team in Nederland de inventarisatie en andere punten oppakt en een offshoreteam gevestigd in India die onder andere de programmering en het testen voor zijn rekening neemt. Het Indiase team zou de RUP-methodiek gebruiken wat borg moest staan voor kwaliteit en structuur.

Verder is afgesproken dat met werkopdrachten zou worden gewerkt. In de werkopdracht, die een start en einddatum heeft, is dan naast een aantal andere voornamelijk financiële zaken, de opdrachtomschrijving opgenomen. Capgemini zou dan conform de omschrijving in de werkopdracht, de werkzaamheden uitvoeren. Elke werkopdracht wordt geëvalueerd en er wordt gerapporteerd aan de Equihold-projectleider of -contactpersoon zodat deze toezicht kan houden (verplicht) op uitvoering en voortgang.

Werkopdrachten en overige documenten

Deze werkopdrachten vormen zo de basis voor de realisatiefase. Naast deze periodiek opgestelde werkopdrachten zijn er nog meer documenten, waarin informatie over technische en functionele specificaties voor iedereen eenduidig is vastgelegd. Dit alles is in het Engels.

• Visiedocument: Een algemene beschrijving van doelstellingen van de sportapplicatie 1-2Focus. Hier staan ook diverse requirements in zoals Help-functies, user manual en diverse non-functional requirements.

• Software architectuur document met voornamelijk technische requirements, waaronder de verdeling in drie lagen (layers): Presentation, Business en Data. Deze versie (0.9) wacht nog op definitieve afstemming met Equihold…

• Use cases: Beschrijving van de functional requirements inclusief screenprints uit de VB6-versie. Basis is de bestaande VB6-applicatie. Echter, er zijn op die manier wel twee versies van de ‘waarheid’ ontstaan, de use case en de VB6-applicatie. Welke is leidend bij inconsistentie?

• Software developement plan (SDP) waarin de doelstelling, aanpak, deliverables, milestones, planning, etc. is opgenomen. Misschien omdat dit ‘slechts’ versie 0.75 is, het is opmerkelijk dat in het overzicht van rollen er alleen een backoffice (India) projectmanager is, een overall projectmanager ontbreekt.

Wie stuurt, wie is verantwoordelijk?

In de stukken die ik heb kunnen inzien zit een voorbeeld van een werkopdracht. Deze beslaat concreet één A4’tje. In dit voorbeeld beslaat de werkopdracht voornamelijk financiële afspraken over tarieven en afname van de ingehuurde capaciteit in aantal uren (8360) voor de genoemde periode. De opdrachtomschrijving bestaat uit één regel, samengevat als ‘Voer activiteiten uit’.

Ik heb geen evaluatierapporten gezien noch rapportage over voortgang aan de Equihold-projectleider en/of –contactpersoon, die verder in de documentatie ook niet nader wordt genoemd. Zoals in eerdere artikelen genoemd, ontbrak ook een functionerende stuurgroep.

Een stuurgroep die ontbreekt, geen overall projectleider, geen voortgangsrapportage en daarmee ook geen toezicht op uitvoering en voortgang. Dit zijn essentiële voorwaarden om een project onder controle te houden. Is door het ontbreken hiervan het project op voorhand niet volledig kansloos? Wie had dit moeten opmerken en ter tafel brengen? De Capgemini delivery manager, de Capgemini engagement manager of had Equihold gewoon beter moeten opletten en aan de bel moeten trekken?

Quality assurance

Eén van de activiteiten die bij Capgemini is belegd is quality control. Quality control bestaat uit diverse activiteiten. Naast de unit- en systeemtest valt daar ook onder de code review waarbij de code tegen diverse aspecten getoetst is zoals programming guidelines, inclusief een peer review.

Wederom is ook hier geen rapportage van, dus luidt de vraag: heeft dit plaatsgevonden? Gezien de beschuldiging van Equihold dat het spaghetticode is, had hier vroegtijdig veel informatie uitgehaald kunnen worden. Wederom rijst bij mij de vraag wie aan de bel had moeten trekken: de Capgemini delivery manager, de engagement manager of Equihold? Uit een eerder door Capgemini uitgevoerd onderzoek naar de kwaliteit van de software is een aantal aanbevelingen gekomen. Maar is quality assurance de plek om deze aanbevelingen te borgen?

RUP of RUP in name only?

RUP is een interactieve wijze van softwareontwikkeling en is bedoeld om complexe projecten te doen waarbij de requirements tijdens de realisatiefase wijzigen als gevolg van voortschrijdend inzicht of andere redenen. Capgemini had al eerder aangegeven dat het team in India bekend was met deze werkwijze en ook conform de richtlijnen hiervan werkt.

Een eerste vraag is natuurlijk of deze manier van werken de meest geschikte vorm is voor dit project. Het project behelst een één-op-één overzetting, waarbij het eindresultaat heel duidelijk is en wijzigen van requirements beperkt zijn. Was in dat geval bijvoorbeeld een watervalmethode niet passender? Als dat zo is, waarom en door wie, is dan toch gekozen voor RUP? Is een RUP-aanpak in deze case bepalend geweest voor het slagen/mislukken van het project? Met andere woorden, is toepassen van RUP in deze case een succesfactor of juist een faalfactor geweest? Als het om een resultaatsverplichtingscontract gaat, is de gekozen methodiek dan relevant?

Testresultaten

Natuurlijk kun je je afvragen of een RUP-aanpak past bij de Indiase hiërarchische cultuur van werken. Is hier ervaring mee? Zijn daar weleens studies naar gedaan? We weten dat India ‘wereldkampioen certificaten’ is, maar hoe werkt het in de praktijk? Om beter inzicht te hebben in de ontwikkeling en kwaliteit van het werk had ik dan graag een overzicht gezien van de testresultaten die tijdens de diverse iteratiestappen zijn vastgelegd.

Voor degene die wat minder bekend zijn met RUP: testen is een essentieel onderdeel die na elke iteratieve stap binnen de ontwikkeling moet worden uitgevoerd. Het zal inmiddels geen verrassing zijn dat hier geen vastlegging van is of in ieder geval is dit niet overgedragen. In het laatste geval is dat jammer, want de functionele acceptatietest valt onder de verantwoordelijkheid van Equihold en unit, systeem-, en andere testresultaten zijn welkome input voor het opstellen en uitvoeren van een testplan.

Capgemini-medewerkers

Een andere cultuur, tijdverschil en communicatie zijn toch wel de uitdagingen bij offshoring van werk naar India. Hoewel offshoring zeker succesvol kan zijn, vergt het enige ervaring om hier een succes van te maken. Als je deze ervaring (nog) niet hebt, is het onverstandig om zelf een projectteam in India aan te sturen. Equihold verwijt Capgemini dat ze geen rechtstreeks contact met India mocht of kon hebben. Gezien de uitdagingen die daarbij horen, moet je dat wel willen?

Conform de raamovereenkomst zijn partijen verplicht elkaar onverwijld te informeren wanneer er gerede twijfel is over de verwachten resultaat van de arbeid. Echter, Indiërs zullen problemen nooit melden. Dit zit niet in hun cultuur omdat ze het een belediging vinden voor de klant die dan teleurgesteld is. Ook onduidelijkheden in de opdracht zullen ze om die reden dan ook nooit melden. Ze verzinnen liever zelf een (slechte) oplossing dan in overleg te treden. Dit moet je wel weten als je met Indiërs werkt, dus managen. Omdat ik geen risicoanalyse heb gezien kan ik niet oordelen of dit als een risico is gezien en wat dan eventuele risicobeperkende maatregelen zijn. Ik vraag met af wat in deze de gebruikelijke risicobeperkende maatregelen zijn.

Liaison van het Indiase team

Om de communicatie met India op gang te houden, heeft geruime tijd een Indiër op locatie in Almere gezeten, zodat hij zich een beter beeld kon vormen van bijvoorbeeld voetbal. Voetbal blijkt anders te zijn dan cricket. Deze medewerker fungeerde later als liaison richting het Indiase team. Waarom Capgemini aan Equihold vraagt om het Indiase team te beoordelen en waarom Equihold daar dan weer gehoor aan gaf, is voor mij een raadsel.

Waar geen discussie over is, is de verantwoordelijk die Capgemini heeft om medewerkers met de juiste expertise neer te zetten. Bij toeval kwam Equihold er achter dat er junior medewerkers zaten in India. Dit was niet afgesproken noch is hier vooraf melding over gemaakt. Het leidde tot een creditnota. Had dit incident niet moeten leiden tot het veel strakker aantrekken van de teugels, dus een stuurgroep, voortgangrapportages en een projectleider, aan de kant van Equihold?

Functionele acceptatietesten

In een eerder artikel is aandacht besteed aan onderzoeken naar de kwaliteit van de software door de code te onderwerpen aan een inspectie. Daarmee haal je nog niet de functionele afwijkingen naar boven. Dit kan alleen door het uitvoeren van functionele testen.

Deze activiteit was belegd bij Equihold. Ze hebben daarbij geen specifieke methodiek gebruikt zoals TMap Next en ook een testplan ontbreekt. Testscripts ben ik ook niet tegengekomen, evenals niet in- en exit-criteria of acceptatiecriteria. Vooral dat laatste is jammer, omdat we nu niet weten wanneer het project ‘klaar’ is en formeel kan worden afgerond. Wel zijn sommige klanten betrokken als pilot en is veel met ze samengewerkt om fouten uit het systeem te halen.

800 ClearQuest-meldingen

De eerste versie (1.0) van het systeem is in juni 2006 opgeleverd, maar Equihold wilde deze niet uitleveren aan de klanten in verband met het aantal defecten. Pas versie 5.0, die in juni 2007, een jaar (!) later, is uitgeleverd aan de eerste klanten (pilots) kende nog steeds veel storende defecten. De ClearQuest-teller is daarbij opgelopen tot meer dan achthonderd. In ClearQuest worden fouten, klachten, etc. vastgelegd waarbij Capgemini die dan oppakt. Nu is achthonderd ook maar een getal, maar geeft wel aan dat er een flinke hoeveelheid correctiewerk lag. Daarbij doet een aantal van achthonderd vrezen voor regressie voor de delen die wel correct waren.

Versie 6.0 en 7.0 (2007/2008) kenmerkte zich ook doordat er enkele tientallen hotfixes hier in verwerkt waren om blokkerende fouten weg te nemen. Aan de stabiliteit van het systeem viel daarmee wel het een en ander op te merken. Daarnaast zijn bevindingen vastgelegd in een apart FAT-document. Ze zijn duidelijk omschreven en met voorbeelden en/of schermprintjes vastgelegd. Helaas is daarbij niet de zwaarte van de fout aangegeven, zodat op basis van dit overzicht geen direct inzicht te verkrijgen is van de totale kwaliteit en risico’s van het systeem.

Opvragen testrapporten

Afrondend vind ik dat het geheel aanleiding is om de testrapporten de unit-, en systeemtesten van Capgemini op te vragen, evenals de bevindingen van quality control en de testbevindingen die impliciet onderdeel zijn van de RUP-methodiek. Hopelijk komen deze documenten nog boven water, al is het maar in de rechtszaak die in 2015 gaat spelen.