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.
@KurtdeKoning Maar wat denk je er zelf van? Er worden vele vragen gesteld maar dat is waar ik benieuwd naar ben. Ik heb even snel teruggelezen en lees dan 2.4 miljoen kosten voor Equihold, minstens 35 manjaren besteed aan de conversie plus uitbreiding functionaliteit. Een een claim van 43 miljoen. Rente plus gederfde inkomsten. Dat is ook nogal wat voor iets wat jij omschrijft als een eenvoudige klus al vind ik dat lastig te beoordelen. Aan de getallen te zien niet. In 35 manjaar kan je heel wat doen. Conclusie van het verhaal vind ik wel, zorg bij het afsluiten van zo een uitbestedingscontract ervoor dat je de verantwoordelijkheden zo verdeelt dat je niet aanspreekbaar bent in geval van gedoe. Juridisch adviseurs zullen hier een hoop werk aan hebben. Tot slot ben ik wel benieuwd wat jij ervan denkt: is dit werk voor de Rijdende Rechter of Tros Opgelicht?
Kurt, aan wat voor een converteertool had je gedacht voor deze”eenvoudige klus”; VBUC? En zou dat wel de oplossing hebben gebracht. De basis van de nieuwe applicatie (architectuur en code) moest gedegen zijn vanwege het hoge ambitieniveau van Equihold (zoals ook beschreven door Capgemini) en de prominente positie van de eerste klanten van de VB versie. De eisen waren onder andere drie lagen structuur i.p.v. twee (all business logic should be part of the business layer), verdere ontwikkelen in een .Net omgeving voor de ondersteuning van verschillende platformen (online en offline), ontwikkeling van een lichte naast een zware versie, bruikbaar zijn bij meerdere soorten teamsporten op meerdere sportniveaus / organisatieniveaus in verschillende regio’s, gecombineerde rapportages, snelle respons, koppelingen met andere applicaties, meertaligheid, weinig beheerinspanning en goede onderhoudbaarheid. Ook Capgemini sprak van de noodzaak van een solide software architectuur en een hoge betrouwbaarheid.
Kurt, dat er (aan de kant van Capgemini) een overall projectmanager ontbreekt, is inderdaad een omissie. Het kleine Equihold kon die natuurlijk niet leveren; bovendien Capgemini schermde het Indiase ontwikkelteam af. De delivery manager van Capgemini stelde zich op als een deelprojectleider zonder projectleider van Equihold en zonder actieve stuurgroep. Dat is bepaald geen goed voorbeeld van goed projectmanagement en ook niet van rightsourcing door Capgemini.
Capgemini heeft een aantal projectdocumenten opgesteld. Maar Equihold heeft kennelijk rapportage, zoals de voortgangsrapportages, Q rapportages en de testrapporten, niet gekregen. En dat duidt er op dat Capgemini Equihold ook niet de projectleiding wilde geven.
Samengevat, Equihold had te weinig ervaring en expertise voor zo’n ingrijpend project en daarom huurde het Capgemini in. Door het gebrek aan ervaring en het te goeder trouw zijn, is Equihold steeds meer klem komen te zitten tussen Capgemini, geldgebrek en gebruikers. Equihold heeft wel vroeg aan de bel getrokken bij Capgemini, maar wist niet hoe de regie in handen te krijgen.
Capgemini had de benodigde expertise en de voornemens waren vast wel goed, maar de commerciële mensen daar zaten op twee gedachten te hinken, die van detacheerder en die van ontwikkelfabriek voor uitbesteding. Daarom is jaren aangemodderd. Capgemini leverde bluf (veel te hoge versienummers van de applicaties, een bijna lege bussines layer) in plaats van kwaliteit aan de eindgebruiker (too little too late). Ze hadden Equihold beter moeten informeren en vooral ook beter moeten begeleiden om hun regierol te kunnen vervullen.
Aangezien projecten een duidelijk begin en einde hebben, tenminste als je deze niet door Capgemini uit laat voeren, dan is het dus uitermate belangrijk om je uitgangspunten duidelijk te hebben. Projectmanagement is – net als RUP – tenslotte een vorm van governance, weliswaar sterk tijd- en doelgebonden maar dus in belangrijke mate bepalend voor eind- of deelresultaten. In hele analyse, welke zich eenzijdig richt op een gewenste SOLL, mis ik aantal essentiële activiteiten zoals bijvoorbeeld de risicoanalyse voor de IST alleen maar uit te gaan van een vermeend werkende (en onderhoudbare) applicatie is nogal dom. En natuurlijk moeten niet de organisatorische volwassenheid vergeten want meeste projecten mislukken als gevolg van de politiek en niet de techniek.
Suggestie dat het hier om een simpele conversie gaat hout wat mij betreft geen stand, eerder lijkt er sprake van reversed engineering en dat geldt wat mij ook betreffende de bedrijfsvoering van Equihold. We hebben het hier dus over hoe een bedrijf geëxploiteerd wordt, de manier dus waarop een bedrijf wordt bestuurd met inbegrip van de relaties met klanten en leveranciers. Als ik overweeg dat de omschreven bedrijfsactiviteit softwareontwikkeling was en alle activiteiten hierin, inclusief de sturing uitbesteed worden dan lijkt doel me tot middel gedegradeerd te zijn en komt bij mij vraag naar boven met welke doel dat dan precies gedaan is.
Achteraf de schade van je eigen incompetentie proberen te verhalen inclusief een riante bonus heeft namelijk nog maar weinig met ondernemen te maken. Uiteraard zijn er vragen te stellen over de merites van Capgemini in deze case maar uiteindelijk lijkt het me gewoon een schoolvoorbeeld van slecht opdrachtgegeversschap. Suggestieve opmerking van expert dat India de wereldkampioen van certificaten is lijkt me trouwens onjuist als ik kijk naar hele circus hier in Europa, vraag bepaald het aanbod en het zijn juist ondernemers als Kenneth Berkleef die deze markt voeden. Exact hetzelfde zie je ook met allerlei onnozele (milieu)keurmerken welke nietszeggend zijn maar wel een warm gevoel geven, net zoiets dus als een code keuring want kwaliteit is suggestief en dat geldt met name voor software waarvan gedacht wordt dat deze zich zelf schrijft. Softwareontwikkeling gaat om heel wat meer dan de code, projectmanagement om heel wat meer dan het projectplan en de bedrijfvoering om heel wat meer dan wat contracten.
@Louis. De claim van 43 miljoen bestaat voor het grootste deel (40 miljoen) aan derving van verwachte winsten. Dan blijft er om en nabij 3 miljoen over aan ontwikkelingskosten. Nog steeds een fors bedrag. Maar daarbij kan de taak nog steeds eenvoudig zijn. Tenslotte is het vegen van een straat eenvoudig maar kan tot hoge kosten leiden als de straat maar lang genoeg is, zeker als er delen overnieuw geveegd moeten worden.
Opgelicht is voor onwetende particulieren die door de grote boze buitenwereld gemangeld zijn.
Van een (rijdende) rechter verwacht ik dat deze in zijn toewijzing ook de rol van een Equihold zal meenemen. In hoeverre had deze de schade kunnen beperken door invulling te geven aan projectleiding en governance. Daar waar een rechter de particulier ontziet denk ik dat hij zeker kritische vragen zal hebben aan een ondernemer die misschien wel onwetend was maar kennis had kunnen inhuren.
Ik ben daarom zeer zeker benieuwd hoe een rechter dit gaat wegen en hoe dit terugkomt in de (hoogte) van de claim als deze wordt toegewezen.
Ik zie wat getallen voorbijkomen die heel lastig in perspectief zijn te plaatsen.
Enerzijds spreek je over een eenvoudige opdracht (VB6 applicatie omschrijven naar .net), maar hiervoor wordt vervolgens wel 8360 uur begroot, omgerekend ruim 4 manjaar.
Vervolgens wordt ook gesproken over 3 miljoen aan ontwikkelkosten. Gaat dit over die 8360 uur? Dat zou een uurtarief betekenen van bijna €360.
Ook 800 ClearQuest records zegt niet zoveel. Als een ontwikkelaar ieder foutje wat hij maakt/tegenkomt netjes vastlegt (ivm tracking/tracing/urenverantwoording), en de diverse testlagen dat ook doen, dan is 800 niet zo veel. Terugkijkend op de 8360 uur betekent dat 1 foutje maken per 10 uur, valt wel mee toch (alhoewel, als je €360 per uur betaalt verwacht je misschien foutloze programmeurs 🙂 )
In een eerder artikel praat je over 175 foute regels per 1000 regels code. Zijn al deze fouten ook in ClearQuest vastgelegd? Dan is 800 ineens heel weinig zelfs.
Misschien dat de auteur kans ziet de getallen wat meer vorm te geven zodat we ze op waarde weten te schatten?
Ik zie eindelijk een reactie van Kurt, even nietszeggend als zijn analyse maar het begin is er.
Resultaatverplichtingen zijn alleen gebruikelijk bij materiële goederen, software valt daar niet onder en verbintenissen om deze te produceren meestal ook niet. Alles valt en staat dus met het zaaien van de gedachte dat er een resultaatcomponent verwacht mag worden uit verbintenis door te stellen dat het een eenvoudige opdracht was. Opmerkelijk gezien feit dat verwachte winst hieruit op 40 miljoen geschat wordt, inspanning en resultaat lijken me niet in verhouding te staan en ongeacht de kwaliteit van de opgeleverde code toont de businesscase weinig realiteitsgevoel.
Ik hoop dat de rechter dat ook zo ziet want als ondernemen zo makkelijk is dan staat de ICT sector nog een zware tijd te wachten, iedereen gaat succes bestellen bij de afhaal-indiaan.
Er wordt in vijfluik uitvoerig ingegaan op processen en modellen, beide evenmin materiële producten dus kan daar ook niet echt een resultaatverplichting van verwacht worden. Enige materiële component is een stapel papier welke echter alleen maar als informatiedrager gezien mag worden en Capgemini is heel goed in het produceren van papierstromen maar daarin zijn ze helaas niet de enige. Aangaande de vermeende ongelijkheid tussen Equihold en Capgemini kunnen we kort zijn want het aantal beslissers is bij de overheid niet veel groter, hele case is te spiegelen doordat ‘bestuurders’ ervan uitgaan dat alles geregeld is als contracten getekend zijn terwijl spel dan juist pas begint.
Vraag of je leverancier verantwoordelijk kunt stellen voor het feit dat de spelers aan beide zijden niet gelijk zijn is interessant, dat cricketspelers uit Bangalore geen enkele kans hebben tegen voetballers van Barcelona zal namelijk niemand verbazen. Deze metafoor lijkt vergezocht maar Equihold heeft dus willens en wetens voor offshoring gekozen, de vorm van uitbesteding waar het draait om besparing op arbeidskosten in met name softewareontwikkeling. Voordeel van duale model van Rightshoring is te verwaarlozen als het werkelijk een eenvoudige conversie betrof.
Als idee goed is, 40 miljoen is tenslotte een heleboel geld, maar uitvoer slecht dan zal het intellectuele eigendom ervan vast wel vastgelegd zijn. Het zou namelijk ontzettend stom zijn als je de ‘kroonjuwelen’ van je bedrijf uit handen geeft want niet alleen kennis aangaande softwareontwikkeling leek te missen maar ook de sources van VB6 applicatie. Of was Capgemini werkelijk zo stom om te proberen het wiel opnieuw uit te vinden?
Kom er maar in Kurt want tot op heden vind ik het toevallig dat je in 2005 ‘independent ICT consultant’ geworden bent, ook je eerdere reactie aangaande het denkbeeld over de cultuur in India – en suggestieve opmerking over certificaten wereldkampioen – kan ik niet plaatsen met wat je in deze vijfluik schrijft. Je lijkt je hierdoor in allerlei bochten te wringen en komt daardoor niet echt objectief meer op mij over. En ik wil zeker niet recht praten wat Capgemini verbogen heeft maar als ik moet kiezen tussen twee kwaden dan neem ik de meest voorspelbare.
Er zijn namelijk maar twee zekerheden en dat zijn de dood en de belastingen, eerste is onvermijdbaar en tweede ontwijkbaar;-)
In Clearquest zijn alle bevindingen opgenomen die tijdens de acceptatietest door Equihold en de pilotklanten naar voren zijn gekomen. Deze worden dan door Capgemini opgepakt en indien terecht, verbeterd. Dit aantal is rijp en groen door elkaar, dus zowel meldingen die direct leiden tot een hotfix maar ook een verkeerde datumnotatie.
Equihold heeft in 2010 aan Software Quality Measurement and Improvement (SQMI) gevraagd om de opgeleverde code te onderzoeken. Dit hebben ze gedaan dmv een toetsing (geen test). SQMI hanteert hierbij een aanpak dat ze foutieve (defect) regels telt en deze in een 5-tal categorieën plaatst. Er wordt bijvoorbeeld ook geteld hoeveel regels disabled zijn. Dit leidt dan niet tot een fout in de uitvoering maar roept wel vraagtekens op waarom dit gedaan is (bij nieuwe software) en is minstens verwarrend bij toekomstig onderhoud. In de telling zit ook meegenomen hoe vaak grote stukken code (middels copy/paste) meerdere malen voorkomt in de software (in plaats dat gebruik is gemaakt van een subroutine). Ook dit hoeft niet te leiden tot tot fouten in de uitvoering maar het maakt het onderhoud gevoelig en duur.
In de bouwfase is een werkwijze gehanteerd waarbij meerdere werkopdrachten zijn verstrekt. Bij de documentatie zat een voorbeeld van een werkopdracht met een geaccordeerde tijd van 8360 uur. In deze werkopdrachten zaten ook uren om correctiewerk te doen. Dit maakt het moeilijk om de grote van het systeem te bepalen aan de hand van werkelijk bestede tijd. Indien first-time-right zal het aantal uren lager zijn uitgevallen.
Kurt,
Je hebt heel veel tijd gestoken in het verder ingraven in de oorzaken van het misluken van het project. Ik verwacht echter dat de rechtbank een hele andere probleemstelling heeft.
Ten aanzien van de 3 miljoen (onterecht betaalde facturen) zal de rechter zich afvragen of er een contract is en of dat contract door beide partijen is nagekomen.
Volgens mij was er een contract en is dat ook grotendeels nagekomen. Het feit dat er deelopdrachten waren en dat de facturen van deze deelopdrachten betaald zijn, suggereert dat de opdrachtgever akkoord is gegaan met het afronden van (een groot deel van) de contractverplichtingen door de opdrachtnemer. Oftewel: het merendeel van de contracten is nagekomen door CapGemini en de resultaten zijn door Equihold geaccepteerd en dus – impliciet – als voloende beschouwd.
Deze claim zal dus door de rechter slechts gegrond verklaard worden voor ten hoogste die (deel)contracten die niet nagekomen zijn. Ten hoogste, want ook Equihold is waarschijnlijk niet al zijn verplichtingen nagekomen en deze tekortkomingen zullen verdisconteerd worden met de tekortkomingen van CapGemini. Bij een mislukte samenwerking hebben er twee partijen schuld aan het mislukken.
Mijn inschatting is dat CapGemini zal aantonen dat dit project ook voor Cap vele malen meer gekost heeft dan dat het opgeleverd heeft (b.v. door de kostbare analyses door onafhankelijke bureaus en het wegwerken van geconstateerde niet-blokkerende maar wel vervelende fouten) en dat Cap dus al het mogelijke heeft gedaan om de klant tevreden te stellen en het verlies te delen.
P.s.
Je tekst bevat geen vermeldingen over garantiebepalingen in het contract. En als die er wel waren: heeft CapGemini voldoende gelegenheid gekregen om aan die garantiebepalingen te voldoen?
Ten aanzien van de 40 miljoen (gederfde winst) zal de rechter zich afvragen of hierover bepalingen in het contract staan. Dit kan ik uit je tekst niet opmaken, maar ik kan me niet voorstellen dat CapGemini akkoord is gegaan met een “gevolgschade bepaling” van 40 miljoen. En dan nog is gevolgschade van een niet functionerend IT component (bijvoorbeeld het niet kunnen produceren van een auto omdat een printer in de assemblage afdeling het niet doet) wat anders dan gemiste inkomsten/winst. In alle gevallen zal de rechter vragen om een bewijs dat de derving van winst een rechtstreeks gevolg was van het niet nakomen van bepaalde verplichtingen door CapGemini. En dat lijkt me heel moeilijk te bewijzen: lagen die contracten van 40 miljoen er al ten tijde van de bouw van de software? Had Equihold een plan-B en werd daar actief aan gewerkt (en zo ja: hoe actief en hoe succesvol)? Heeft Equihold er zelf alles aan gedaan om de slechte software te voorkomen? Had CapGemini directe invloed op de business processen (marketing, sales, etc.) van Equihold om zodoende het risico voor CapGemini te verkleinen?
Mijn voorzichtige inschatting is dat deze vier vragen allemaal met “nee” beantwoord zullen worden en dus is er onvoldoende grond voor deze claim tegen CapGemini. Als alle vier de vragen wel met ja beantwoord worden, dan kan de claim slechts bestaan uit de directe, aantoonbare schade die Equihold heeft geleden tijdens de looptijd van het contract en niet die in de periode daarna.
@Kurt
Jurdische versus technisch naar de zaak kijken lijken me beide twee vormen van een binaire focus, het gaat zoals ik al stelde met voorgaande reactie aangaande inspanningsverplicting vooral om mensenwerk. En om de vraag hoe die mensen gemanaged worden want de case is niet uniek of eenzijdig als we kijken naar het probleem van commodificatie, het proces waarin hele menselijk handelen teruggebracht wordt tot een geldwaarde.
Opmerking over de inzet van een ‘junior-team’ – en deze als ‘senior-team’ doorbelasten gaat om de marges. Weten wat een ‘indiaantje’ kost maar niet weten wat deze waard is deed me refereren naar eerdere reactie van je. Want certificaten zijn inderdaad nietszeggend als je toetsingskader niet kent, Titanic werd ook onzinkbaar geacht maar ging op haar eerste reis toch kopje onder.
https://www.computable.nl/artikel/opinie/outsourcing/5200305/1276946/managen-van-een-indiaas-team.html
Waar het allemaal om draait is marketing, toch vooral een discipline die zich richt op overschot en betreffende Rightsourcing model van Capgemini valt wel te raden waar teveel van is. Eerdere opmerking over duale model was trouwens cynisch bedoeld want dezelfde governance zie je ook bij de overheid. Het buzzword is ‘ontzorgen’ om terug te komen op het proces van commodificatie, mensen zijn lastig en cijfers masseerbaar als we kijken naar de ontmenselijking van de zorg.
Je verliest jezelf teveel in de details omdat je vraagstelling nog niet goed gedefinieerd hebt, alles begint tenslotte bij waarom. Bijvoorbeeld waarom jouw profiel afwijkt van de mijne om maar eens wat te noemen;-)
@Eddy. De deelopdrachten waren in feite formele accorderingen van te bestede uren. Hiermee werd een maandelijkse factuurcyclus opgestart waarbij op maandbasis voordat de werkzaamheden begonnen, de betaling (gemiddeld €100.000,- ex btw) binnen moest zijn bij Capgemini. Zo niet dan werden de werkzaamheden opgeschort. Een deelopdracht kon via meerdere facturen betaald worden zodat bij de eerste oplevering in juni al voor ongeveer een half jaar betaald was.
Ten aanzien van je PS: Er zijn geen garantiebepalingen in de raamovereenkomst opgenomen.
Wel is de aansprakelijkheid van Capgemini gelimiteerd tot 1,25 miljoen. Echter, er is jurisprudentie waarbij een rechter kan besluiten om een hogere vergoeding toe te kennen. Uiteraard alleen als er sprake is van een ernstige wanprestatie. Dit zal Equihold moeten aantonen evenals de waarschijnlijkheid van deze ‘schade’.