rechterhamer beroepDe gerechtelijke procedure tussen de oud-Equihold-eigenaar Kenneth Berkleef en ict-dienstverlener Capgemini over het mislukte project 1-2Focus is in een ver gevorderd stadium. Inzet is het terugvorderen van 43 miljoen euro aan directe en gevolgschade. Het laatste weerwoord is thans aan Capgemini als gedaagde. Daarna moet de rechter in mei de ingediende argumenten gaan beoordelen en beslissen of er nog meer informatie aangeleverd moet worden of dat er voldoende informatie is om een oordeel te vellen.

De Stichting Capclaim van Berkleef heeft vorig jaar projectdocumentatie aan kenners uit de markt beschikbaar gesteld om hen over deze zaak te laten oordelen. Over deze ‘second opinion’-documenten is reeds gepubliceerd door Kurt de Koning en Leendert Hinds. Na het doorlezen van de documenten heb ik geadviseerd om het project nader te laten auditen. Eén van de redenen hiervoor is de exoneratieclausule. Succesvol geld terugvorderen na levering van een slecht product is normaal. Maar gevolgschade claimen, die hoger is dan het maximumbedrag in de exoneratieclausule, dat kan alleen bij toerekenbare onrechtmatige daad en laakbare grove onzorgvuldigheid naar de maatstaven van redelijkheid en billijkheid.

Ik heb een projectaudit voor de Stichting Capclaim uitgevoerd. Daarbij heb ik gebruik gemaakt van alle documenten die door Berkleef en Capgemini bij de rechtbank zijn ingediend. Verder kreeg ik van Berkleef de laatste rapporten, kopieën van e-mails, et cetera, tot mijn beschikking. Ik heb ook Capgemini om documenten/bewijs gevraagd, om zo tot een beter inzicht te komen, zodat dit inzicht gedeeld kon worden. Capgemini heeft ervoor gekozen om hangende de gerechtelijke procedure verder geen commentaar te geven op deze zaak en ook geen documenten met derden te delen.

De audit laat onder andere zien dat er tientallen belangrijke tot cruciale missers door Capgemini zijn gemaakt, die veelal structureel waren en te laat, onvoldoende of zelfs nooit zijn gecorrigeerd. Diverse conclusies van Kurt de Koning en Leendert Hinds worden ook in de audit onderschreven. Ze zijn soms nog wat scherper geformuleerd en steviger onderbouwd door nieuwe informatie. In dit artikel staan een aantal missers die vanuit Quality Assurance (QA)/Quality Control (QC) van Capgemini voorkomen hadden moeten worden dan wel gecorrigeerd. In een volgend artikel wordt ingegaan op het verweer van Capgemini.

Juridische grondslag

Het raamcontract tussen de partijen is qua vorm gericht op detachering en gaat vooral over de betaling via een prepaid-abonnement voor gemaakte uren en de arbeidsvoorwaarden. Het doel van de overeenkomst is op een nietszeggende wijze verwoord in het hoofddocument. De ondertekende bijlage C geeft echter de essentie van de overeenkomst aan: uitbesteding van Equiholds verdere 1-2Focus softwareontwikkeling aan Capgemini onder regie van Equihold. Het doel was een vernieuwde applicatie maken om de markt voor sport-erp te veroveren, met .Net C# als ontwikkeltechnologie en rational unified process (rup) als ontwikkelmethodiek.

Hier gaat QA/QC van Capgemini meteen de mist in, want Capgemini had moeten laten zien dat ze de opdracht goed begreep. Normaal gesproken was de raamovereenkomst dan in conceptfase gereviewd en waren de afspraken alsnog in heldere taal verwoord. Daarbij zouden alle belangrijke outsourcingbegrippen, zoals regie, nader gedefinieerd moeten zijn.

Outsourcing of niet

Volgens de getekende raamovereenkomst is er sprake van outsourcing, waarbij de capaciteit ingehuurd wordt. Capgemini levert mankracht en bouwt onder regie van Equihold de gewenste functionaliteit. Capgemini zegt (thans) niet verantwoordelijk te zijn voor de kwaliteit van zijn deliverables.  In november 2006 hebben partijen het contract kennelijk willen herzien. Maar bij de contractherziening wordt expliciet vermeld dat Capgemini ten aanzien van kwaliteit het vetorecht heeft en dus nadrukkelijk resultaatverantwoordelijk is.

Vreemd genoeg heeft Capgemini bij die contractherziening geschreven dat detachering wat anders is dan outsourcing, maar het heeft de outsourcing-constructie toen niet aangepast. Had de vice president van Capgemini die de contractherziening schriftelijk vastlegde wel door dat hij de resultaatsverplichting bevestigde? Achteraf  is niet duidelijk of het de Capgemini-leiding duidelijk was wat het verschil is tussen outsourcing en detachering, respectievelijk resultaatsverplichting en inspanningsverplichting. In ieder geval heeft QA/QC gefaald om de vereiste helderheid (op dat moment alsnog) te verschaffen.

Beheersing van de voortgang

Er is maar één definitief rup-document overhandigd (het vision-document) en enkele die nog niet af waren (software development plan, software architecture document). Andere expliciet toegezegde documenten zijn niet door Capgemini gemaakt of niet aangeleverd. Rup leek totaal niet op het beloofde rup & beyond at Capgemini. In het gezamenlijke rapport ‘Evaluation cooperation l-2Focus/Capgemini’ (14 augustus 2006) is dan ook geconcludeerd dat ‘rup is hardly used’. Daaraan werden weinig woorden vuil gemaakt in de maandelijkse Capgemini progress reports.

De progress reports geven vooral aan welke uren Equihold moest betalen en bevatte amper andere informatie. Die informatie bestaat deels uit iconen voor een soort project dashboard. De progressie met betrekking tot de deugdelijkheid van de software stond niet in de progress reports. Omdat de risk manager de progress reports kreeg, wist deze dat de controle op de vooruitgang niet goed mogelijk was en rup niet volgens de raamovereenkomst toegepast werd. Het is verbijsterend dat QA/QC deze omissies heeft laten voortduren.

Beheersing van de kwaliteit

Deze taak is in het begin impliciet belegd bij Capgemini. Na de contractaanpassing in november 2006 is nog eens expliciet gesteld dat Capgemini voor kwaliteit verantwoordelijk was. De kwaliteit van de documentatie was beneden peil. Zoals reeds aangegeven wist QA/QC dat rup slechts ‘rup in name only’ was geworden en dat het alleen nog slechter werd. En de .Net software kwaliteit? In het onvoltooide rup-document genaamd: ‘Software architectuur document’ staat expliciet aangegeven dat er een modulaire kwaliteitsapplicatie met ‘three tier’-architectuur moet worden opgeleverd, met een beschrijving die zo van de Microsoft-website is overgenomen.

In het onvoltooide ‘software development plan’ staat dat Capgemini high quality software moet opleveren en de releases steeds meer modulaire functionaliteit krijgen. Dat betekent dat de software al vanaf de eerste release moet functioneren, alleen steeds meer functionaliteit krijgt. Het software concept van 1-2Focus is volgens de professionele gebruikers geweldig, ze hebben er ook aan meegewerkt. Maar de eerste vier .Net software-releases waren van een dusdanige slechte kwaliteit dat Equihold zijn klanten alleen hun oude uit 2002 stammende VB6 applicatie wilde leveren.

De volgende .Net releases leken beter, maar zelfs de laatsten waren nog steeds zo slecht dat de (pilot)gebruikers één voor één afhaakten wegens blokkerende fouten. Ook werd Equihold overbelast door de extra beheerinspanning door deze fouten. Hoe kan Capgemini zeggen dat de software over het algemeen goed is? Is dit Capgemini Professional Solution for Software Quality Assurance? Vanuit QA/QC wist Capgemini natuurlijk dat dit tekortkomingen waren in het nakomen van de contractuele afspraken.

Beheersing van de financiën

Doordat Equihold de kosten moet betalen voor het oplossen van bugs en andere fouten, was er geen financiële prikkel, zoals bij een fixed price/fixe date, integendeel. En omdat ze de vorderingen niet goed konden volgen, wisten ze niet of de afgesproken software en documentatie binnen de verwachte tijd en budget opgeleverd werd. Daardoor liep Equihold achter de feiten aan en kreeg ze de benodigde revenuen later dan gepland en uiteindelijk niet meer. Desondanks stonden de budgetten volgens de ‘progress reports’ van Capgemini (in ieder geval) tot november 2008 op ‘Oké’. Toen was er al veel meer tijd en geld besteed dan begroot en nog steeds geen bruikbare software opgeleverd. De business case van 1-2Focus was daarmee achterhaald.

Equihold kreeg geen goede testinformatie. Het kon door een gebrek aan goede stuurinformatie niet bepalen of het qua rendement beter was om te stoppen en eventueel opnieuw te beginnen, dan wel om toch maar weer door te gaan. Equihold hoopte alsnog snel bruikbare software te krijgen, maar moest te lang wachten. Daardoor is Equihold failliet gegaan. Waarom heeft QA/QC dit niet opgelost voordat het zo uit de hand is gelopen.

Taken, verantwoordelijkheden en bevoegdheden

Equihold was contractueel verantwoordelijk voor de regie, informatieanalyse, het opstellen van technische en business-eisen en de acceptatietest. Capgemini was verantwoordelijk voor de rest. De formele rollen staan beschreven in het ‘software development plan’. Capgemini leverde daarom de diverse managers, ontwikkelaars, architecten, testers, et cetera. Desondanks was de taakverdeling voor Capgemini niet duidelijk.

In het rapport ‘Evaluation cooperation l‑2Focus/Capgemini’ (14 augustus 2006) staat “Reconsider contract: current contract – 1‑2Focus is managing; optional new contract = Capgemini is managing’. Capgemini concludeerde dus in augustus terecht dat er wat mis was met ‘managing’. Over de regie werd niets gezegd. En het beeld wie wat moest doen liep daarna nog verder uiteen. Waarom heeft Capgemini dit in vier jaar tijd niet weten op te lossen vanuit QA/QC?

Beheersing van de scope

De scope is in het ‘Vision-document’ beschreven. Er was een oude VB6 1-2 Focus sportmanagementapplicatie als voorbeeld. Die moest in .Net C# herschreven worden, modulair opgebouwd, met een three tier-architectuur. Verder waren er nog een paar kleine verbeteringen en extra’s nodig. Procesmatig zou er met rup gewerkt worden, waarbij Capgemini de projectleiding had. Het was dus duidelijk welke techniek en methoden gebruikt zouden worden, welke rup-documenten opgeleverd moesten worden en welke software functionaliteit op enkele nader te bepalen punten na.

Toch is Capgemini gaan klagen over vele extra’s in de werkopdrachten, die ze hadden geaccepteerd. Waarom heeft Capgemini vanuit QA/QC er niet voor gezorgd dat het projectteam het vision-document na elke iteratie ging bijwerken en dat de accountverantwoordelijke bij Capgemini controleerde of de  taken/werkopdrachten passend waren bij het rup iteratie-plan (dat dus niet opgeleverd is)?

Beheersing van de informatie

Alleen het vision-document is verder gekomen dan de concept fase. Toen andere rup-documenten niet afgerond werden en de rest, ondanks de toezeggingen, geheel niet werden geleverd, had QA/QC moeten ingrijpen. Maar bij Capgemini deed men alsof de (niet rup-specifieke) use cases, spaarzame testrapporten en andere documenten voldoende waren. Zoals aangegeven was de rup-documentatie vrijwel afwezig, op één document na nooit goedgekeurd, werden nooit geupdated en waren dus niet bruikbaar. Verder waren de Capgemini progress reports te summier en veel te positief geformuleerd, soms gewoon misleidend. Met uitzondering van een beperkt aantal documenten, was de resterende informatie niet of met veel moeite beschikbaar. Er was voor Equihold ook geen overzicht van de projectdocumentatie, als die er ooit al geweest is.

Vervelend en stuitend was dat een belangrijke software review door Capgemini van mei 2006 pas via de rechtszaak in juli 2014 (acht jaar na dato!) beschikbaar kwam, terwijl de uren van de betrokken medewerker (in ieder geval deels) wel doorbelast waren. In de achtergehouden review (van mei 2006) stond een groot deel van software problemen beschreven, die in latere releases (van december 2009) nog bestonden. Een wat latere, minder uitgebreide review met sterk afgezwakte conclusies, is wel met Equihold gedeeld. Waarom heeft QA/QC er niet voor gezorgd dat de eerste review met de opdrachtgever is besproken, zodat bijtijds bijgestuurd zou worden?

Beheersing van de hulpmiddelen

Er zou een ‘environment designed to support rup projects’ ingericht worden. Deze tools worden in het ‘software development plan genoemd. Met het juiste gebruik van ontwikkeltools kunnen de meeste ontwikkelfouten snel gevonden worden en vaak zelfs voorkomen of opgelost. In latere software inspecties zijn heel veel fouten gevonden in het verlengde van de eerdere software reviews en dat was niet nodig geweest als de tools beter waren ingezet.

Vooral de uitgebreide software reviews van 2014 zijn erg negatief over de software kwaliteit. Equihold had door de operationele problemen met de software behoefte aan toegang tot die tools of in ieder geval aan de informatie uit die tools, vooral over bugs en de afhandeling daarvan. Maar dat werd geweigerd vanuit QA/QC, terwijl Equihold er wel voor moest betalen. Vanuit QA/QC had Capgemini moeten inzien wat hiervan de impact was voor de kwaliteit van de software en dito op de informatievoorziening voor Equihold.

Beheersing van de bedreigingen

Capgemini wist dat als de afgesproken three tier-architectuur genegeerd werd of als de software kritieke fouten bevatte, het project in gevaar zou komen. In de raamovereenkomst staat bij artikel 3.2 de verplichting om elkaar op de hoogte te stellen van omstandigheden die een behoorlijke uitvoering van de werkopdrachten belemmeren. Toen Equihold vrij snel aangaf dat er geen echte three tier-architectuur geïmplementeerd werd en de software teveel fouten bevatte, had Capgemini vanuit QA/QC corrective actions moeten verordenen. Maar dat is niet gebeurd.

Sterker nog, er is geen ‘inventory project risk-document en geen ‘risk management plan opgeleverd, zoals Rrup dit voorschrijft. De Capgemini Progress Reports hadden dit kunnen vervangen, maar de QA/QC paragaaf was veel te summier en veel te optimistisch opgesteld. De Risk Manager van Capgemini wist daarvan, maar de QA/QC had daar kennelijk geen boodschap aan.

Regie

Equihold was eindverantwoordelijk in de zin dat zij als opdrachtgever de ‘regie’ had. Regie hield in het kunnen stellen van prioriteiten en het bedenken van nieuwe features, en niet meer dan dat. Andere vormen van regie werden ook niet mogelijk gemaakt door Capgemini. Om die (beperkte) regierol te kunnen vervullen moest Equihold de juiste rapportages krijgen en geholpen worden. Maar hier heeft Capgemini volstrekt onvoldoende aan meegewerkt door de stuurinformatie deels niet op te leveren, deels op te leuken, deels moeilijk toegankelijk te maken en zelfs deels achter te houden en door de stuurgroep niet bij elkaar te roepen bij structurele problemen. Capgemini is daarmee de zorgplicht onder leiding van drie betrokken vice presidents niet nagekomen.

Samenvatting

Equihold had te weinig ervaring en capaciteit. Equihold wilde ontzorgd worden door de outsourcing aan Capgemini, heeft daarvoor fors betaald en had het recht op die ontzorging. Equihold was afhankelijk van de stuurinformatie en de betrouwbaarheid van de informatie van Capgemini. Toen het project op alle gebieden de mist in ging, had Equihold te weinig mankracht om Capgemini adequaat te controleren en te weinig macht om bij te sturen en kwam het steeds meer klem te zitten. Equihold had tijdens de start achterafgezien te veel vertrouwen in Capgemini. Maar dat is geen verweer voor Capgemini.

Capgemini heeft voldoende goede mensen en had het project goed kunnen uitvoeren met een win-win resultaat. Ze heeft echter nooit grip op het project gehad en heeft daardoor geen goed werkende software gemaakt, geen software met de afgesproken architectuur opgeleverd en een rommeltje van de documentatie gemaakt. Om dat allemaal te maskeren heeft Capgemini ook nog eens te weinig en soms misleidende stuurinformatie geleverd.

Equihold is intussen failliet en Capgemini zit met een grote imagoschade en straks wellicht nog meer. QA/QC van Capgemini heeft gefaald. Maar dat heeft wellicht vooral te maken met de vreemde manier van communiceren en de gedachtekronkels die in de loop van het project zijn ontstaan. Daarover meer in het volgende artikel.

Jaap van Belkum, zzp’er

Read more: http://www.computable.nl/artikel/opinie/diensten/5236023/2380656/capgemini-12focus-falen-quality-assurance.html#ixzz3ThEGkUy1

Category: Product #: Regular price:$ (Sale ends ) Available from: Condition: Good ! Order now!