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.
Serie
Eerdere artikelen in deze serie van zes van Kurt de Koning gingen over de aanbesteding, de kwaliteit van de software, de inspannings- of resultaatsverplichting en de governance. Hierna volgen nog bijdragen van verschillende andere Computable-experts.
@Ewout. Ik heb geen juridische achtergrond en kan zodoende geen juridische onderbouwing geven over een verwachting aangaande de rechtszaak.
Doordat op dit moment ook niet alle informatie bekend is, we kunnen alleen uitgaan van de informatie die door Equihold verstrekt is, heeft elke poging om op basis hiervan de ‘waarheid’ te presenteren een zekere mate van giswerk. Hierdoor zou mijn ‘waarheid’ slechts een mening zijn. Weinig zinvol en geenszins mijn bedoeling.
Wat ik wel kan doen is de lezer meenemen door de verstrekte documenten heen en hieruit die zaken halen die relevant kunnen zijn voor de lezer om zelf een mening te vormen. Sommige gegevens zijn als feiten gepresenteerd, andere gegevens kennen meerdere gezichtspunten. Binnen deze vijfluik heb ik geprobeerd dat aan te geven en de gegevens op een enigszins overzichtelijke manier te presenteren. Dit betekent ook dat niet alle gegevens hierin zitten doch als er op bepaalde stukken verdieping nodig is, vraag daar dan gerust om zoals Pa Va Ke heeft gedaan mbt de Clearquest meldingen. Wil je echt alle beschikbare informatie inzien dan kan dat via een aanvraag bij Capclaim.
We kennen vele soortgelijke voorbeelden doch ’the devil is in the details’ waardoor elke case toch net weer anders is. Laat het je echter niet van weerhouden om je (de lezer) te verbazen en een mening te vormen en deze via het forum te delen zoals J. van Vooren ook heeft gedaan. Ook andere meningen over wat is gebeurd zijn welkom en net zo goed en deel ze gerust want de ‘echte waarheid’ zal waarschijnlijk nooit helemaal boven tafel komen. Dus is mijn waarheid net zo goed als de jouwe of die van iemand anders.
Tenslotte, ‘de expert’ dat zijn wij met z’n allen. Iedereen heeft zijn ervaringen over wat goed gaat en wat niet, wat zijn best practices in bepaalde situaties. Deel deze gerust op dit forum zodat we er allemaal beter van kunnen worden.
@Kurt
Je zegt een waar ding, het is jouw visie (opinie) op de zaak, geen expertverslag in die zin dat je vanuit een juridische achtergrond een oordeel geeft. En dus zit de duivel misschien in de details maar het gaat hier toch vooral om de grote lijn, lijntjes die achteraf in het zand getrokken worden dienen in de eerste plaats op haar eigen merites beoordeeld te worden. Aangezien de informatie vooral vanuit ontvangende kant komt dienen we uit te gaan van het Capability ImMaturity Model, een parodie op CMM welke de volgende levels heeft:
0 – Nalatig – organisatie betaalt lippendienst omdat simpelweg de wil ontbreekt om uitvoering te geven aan de processen
1 – Belemmerend – organisatie heeft haar eigen processen maar deze zijn volledig ongeschikt en totaal ondoeltreffend.
2 – Minachtend – ineffectiviteit van organisatie is duidelijk op de markt en men probeert de percepties te neutraliseren.
3 – Ondermijning – organisaties ondermijnen routinematig inspanningen van anderen, het concurreren om de schaarse middelen.
Ik laat in het midden welk level van toepassing is maar het lijkt erop dat naleving van het proces (al dan niet in de vorm van lippendienst) de maatstaf voor succes is. De kwaliteit werd niet beoordeeld, vermoedelijk in de veronderstelling dat indien de juiste procedures gevolgd worden een hoge kwaliteit gewaarborgd is. Ik stelde in voorgaande reactie dat het dus allemaal om marketing draait want kijkend naar je vijfluik zijn veel processen met producten ingevuld, de ‘fool-with-a-tool’ situatie die ik wel vaker zie bij Capgemini. Een proces met licenties is trouwens de aard van het beestje, wie out-the-box denkt kan namelijk best wel een paar betere uitgangspunten bedenken waarmee je Capgemini het vuur aan de schenen kunt leggen;-)
Juridisch gaat het om de volgende punten:
De eerste vraag is, wat was de kwaliteit van door Capgemini afgeleverde software en rapportages? Capgemini geeft op het haar website expliciet aan dat de door haar geleverde softwarecode voldeed.
De klanten van Equihold vonden de (te laat opgeleverde) software van Capgemini echter niet goed genoeg vanwege de vele irritante foutmeldingen en haakten volledig af. Volgens testrapporten zaten er veel fouten in de code, die de foutmeldingen kunnen verklaren. Ook was het drie lagen model in de programmatuur niet goed ingevuld.
Dus we kunnen er vanuit gaan dat de software niet voldeed; m.i. ook niet aan de normen van Capgemini wat de advocaten van Capgemini ook zeggen.
Volgende vraag. Mocht de opdrachtgever problemen van deze omvang verwachten? Was het is een gangbaar afbreukrisico voor beide partijen?
In dit geval kunnen we niet van een paar incidenten spreken, maar van een structurele reeks van incidenten gedurende meerdere jaren.
Heeft Equihold de problemen zich op de hals gehaald door een beunhaas in te huren? Nee, Capgemini is een vooraanstaand bedrijf. Verder zijn de afgesproken technieken en methoden ook algemeen erkend als passend bij zo’n project. In de beginfase leek het project ook professioneel opgepakt te worden. Desondanks is er ondeugdelijk werk afgeleverd
Wie is dus verantwoordelijk? De vraag is, werden de falende ontwikkelaars operationeel aangestuurd door de Equihold of door Capgemini?
Capgemini stelt op hun eigen website dat het in deze zaak slechts leverancier van menskracht was (sec detacheerder). Dus de Capgemini medewerkers zouden onder de verantwoordelijkheid van Equihold gewerkt hebben. Uit de formuleringen van hun eigen projectdocumenten blijkt dit niet, integendeel. En ze hadden een volledige verantwoordelijkheid voor het ontwikkelen van de software.
Daarbij heeft Capgemini niet aangegeven dat met de input van Equihold (bijvoorbeeld de use cases en functionele testrapporten) niet konden werken. Dat betekent dat Capgemini op z’n minst verantwoordelijk is voor een groot deel van de schade.
De volgende vraag is of de klant goed geïnformeerd werd over de problemen bij het ontwikkelteam (incl. dat in India). Je wilt geen situatie als met het rijksdashboard ICT dat voor projecten op groen bleef staan wanneer de gereserveerde tijd en het budget al uitgegeven is terwijl het project nog lang niet gereed was. Zoiets is fraude, en naar derden toe, ook een onrechtmatige daad.
Nu beperken bedrijven, zoals Capgemini, in de contracten hun aansprakelijkheid met betrekking tot gevolgschade. Hier was dat 1.25 miljoen Euro Maar dat plafond geld niet als Equihold een rad voor de ogen is gedraaid. Dit moet dus nader onderzocht worden.