Na het doornemen van in ieder geval een deel van het dossier, het volledige dossier is te omvangrijk, blijft er nog een laatste vraag over: Zijn hier lessen uit te trekken. Ongetwijfeld hebben Equihold en Capgemini los van elkaar hun eigen conclusies getrokken en zich voorgenomen om in de toekomst dingen anders te doen.
Belangrijk voor de uitkomst van deze rechtszaak is het gedrag van Capgemini als aannemer van de opdracht. In hoeverre heeft de dienstverlener juridisch verwijtbaar gedrag vertoond? Is er ook zoiets als moreel verwijtbaar gedrag?
1) Capgemini lijkt in ieder geval vrij lichtzinnig te zijn omgegaan met zijn zorgplicht. Capgemini heeft zeer ruime ervaring met ict-projecten en zou Equihold (beter?) moeten adviseren en daar waar Equihold steken laat vallen, hen hierop wijzen. Zo mist een projectplan, heeft er nooit een stuurgroepoverleg plaatsgevonden, ontbreken voortgangrapportages, et cetera. Kortom alle mogelijkheden om inzicht te houden en te sturen ontbraken en ook al was dat in de ogen van Capgemini de verantwoordelijkheid van Equihold, enig aandringen om hier invulling aan te geven mocht wel verwacht worden. Zaken als process-, en projectmanagement en quality assurance – Capgemini’s activiteiten en randvoorwaardelijk voor het succes – lijken ook te ontbreken. Wat heeft Capgemini gedaan en wat kon het doen om het project zo bij te sturen dat deze weer aansluit bij de verwachtingen van de klant. Welke positie heeft het klantbelang gehad op de prioriteitenlijst van Capgemini?
2) Op zijn minst is het dubieus dat er in tegenspraak met de afspraken er junior ontwikkelaars zaten op het bouwdeel van het project. Ook het functioneel ontbreken van de business layer, terwijl dit wel in het architectuur-document is aangegeven, is opmerkelijk.
3) Kwaliteit van de software is bij de rechtszaak een van de hoofdonderwerpen. Ondanks dat Capgemini aangeeft dat er wel fouten in zitten – deze zijn volgens hen minors en het systeem werkt – lijkt dit toch wel sterk af te wijken van de ervaring van Equihold en de diverse potentiële (pilot) klanten. Ook het eigen SIG-onderzoek waardeert de onderhoudbaarheid van de software als gemiddeld. Het lijkt me niet het ambitieniveau van een organisatie als Capgemini om gemiddelde software te maken. Daarbij gaat het hier om nieuwe software. Als deze bij oplevering al niet hoger komt dan gemiddeld (onderhoudbaarheid) dan is dat een slechte basis om hier nog enkele jaren ontwikkeling op te doen. De onderhoudbaarheid van software gaat tenslotte achteruit door het doen van onderhoud. En dit was nog een eigen onderzoek. Onderzoeken uitgevoerd door en namens Equihold maken volledig gehakt van de (technische) kwaliteit en kwalificeren de software als: ‘spaghetti code’. Echter concrete afspraken over mate van onderhoudbaarheid zijn niet vastgelegd.
Equihold/Kenneth Berkleef
Dan Equihold, zijn zij het slachtoffer van een bende gewetenloze ict-criminelen? Of is hen ook iets te verwijten. Hadden ze eerder moeten ingrijpen? Konden ze eerder ingrijpen en bijsturen en daarmee de schade beperken?
1) Equihold is een kleine (minder dan tien medewerkers) organisatie met (vrijwel?) geen ervaring op het gebied van grootschalig offshore software-ontwikkeling. Maar Kenneth Berkleef is wel ondernemer. Ondernemers lopen risico’s. Daar zijn het ondernemers voor, maar ze hebben wel de ‘verplichting’ om deze risico’s te analyseren, in te perken en aan risicobeheersing te doen. Tenslotte werd er op maandbasis wel honderdduizend euro aan Capgemini overgemaakt.
2) Capgemini is geselecteerd op reputatie, kwaliteit en ervaring, kortom een goed verhaal. Mag je daar als ondernemer blind op varen of was het beter geweest (om ook) een behoorlijke vinger in de pap te hebben/houden? Tenslotte is vertrouwen goed, maar controle beter! Als daar de kennis en/of tijd voor ontbrak is het inbrengen van een eigen projectleider (byop) natuurlijk een optie. Ook liep Capgemini in dit project geen enkel risico. Is in het selectieproces het meedelen in de risico’s een criterium geweest?
3) Zoals eerder genoemd, zijn in de projectaanpak meerdere middelen benoemd waarmee inzicht en sturing mogelijk was: Stuurgroep, rapportages, evaluaties werkopdrachten. Hier is geen invulling aan gegeven. Wellicht was dit de verantwoordelijkheid van Capgemini, doch als Capgemini niet rapporteert kan daar om gevraagd worden. Halen en brengen!
4) Gedurende het project zijn er diverse punten voorbij gekomen waarbij alarmbellen moeten zijn gaan rinkelen. In het Software Development Plan (SDP) ontbreekt de projectleider en ook ontbreekt een projectplan en testplan/testmethodiek. Het SDP is nooit formeel afgerond (versie 0.75 stamt uit mei 2006) terwijl de programmering al in januari 2006 was gestart? Allerlei rapportages die inzicht hadden moeten verschaffen in kwaliteit en voortgang zijn nooit (?) opgeleverd. Zijn er acceptatieafspraken gemaakt? Juniormedewerkers? Een raamovereenkomst die een inspanningsverplichting uitstraalt, et cetera. Mooie onderwerpen voor de (ontbrekende) stuurgroep.
5) Tenslotte, een deel van de rechtszaak zal gaan over de discussie resultaatsverplichting versus inspanningsverplichting. Ik ben benieuwd naar de definitie van Equihold en Capgemini.
Met de kennis van nu is het makkelijker oordelen over wat er fout is gegaan en waar had moeten worden ingegrepen. Ook moeten we de tijdsgeest van toen niet vergeten voor zover relevant.
Het lijkt erop dat beide partijen de basis (project) managementprincipes over boord hebben gezet. Geen inzicht, geen controle en dus ook niet bijsturen. Een recept voor mislukking.
Conclusie
Het feit blijft dat Equihold uiteindelijk failliet is gegaan en dat een in potentie mooi product nooit live is gegaan en dit momentum ook definitief weg is.
Ik laat het aan de lezer over om hier zelf zijn conclusies te trekken en indien relevant lessons learned uit te trekken.
Dank voor dit 6 luik – ben benieuwd waar het in de rechtzaak op gaat uitdraaien. In de praktijk zie ik nog zeer regelmatig contracten met “inspannings verplichting leverancier en project management klant” waarbij de laatste dat helemaal niet overziet (zeker met offshore delivery) maar ja, het lijkt zo goedkoop!
Verwacht dat de aansprakelijkheids limiet van Cap niet zo snel wordt opgeheven, dat doet een rechter toch echt alleen als de andere partij dat totaal niet kon overzien.
Lering? Ik vrees van niet, al meer dan 10 jaar wordt gewaarschuwd voor bewust of onbewust misleidend optreden van leveranciers, zie maar de hoge negatieve score bij ERP projecten. En Guus Krabbenborg zegt dat klanten meestal verantwoordelijk zijn door hun grenzeloze naïviteit. Komt nog daarbij dat gezwaaid wordt met termen, zoals bij ERP waar alleen zwaar marketing geweld aan bod komt, veel ervan zijn de benaming onwaardig. Nu met de app’s en smart-devices zal het er niet beter op worden, sommige zien dat al als de nieuwe ICT die alle problemen gaan oplossen.
Ik kom vaker bij klanten waar een ontwikkeltraject niet goed is afgelopen. Voor de meeste kleinere bedrijven is zoiets te ingewikkeld en zou er een soort zorgplicht vanuit de opdrachtnemer moeten zijn. Ik heb het gevoel dat goed advies voor de klant tegenwoordig achtergesteld is aan het schrijven van zoveel mogelijk uren…
In de regel komt een softwareleverancier er mee weg met een slecht uitgevoerd project. Er is namelijk geen directeur of manager die een mislukt project in de schijnwerpers zet.
Ook hier zie je dat een opdrachtgever een eigen directievoerder en architect moet inhuren om de aannemer te besturen. Net als in de woningbouw: eerst denken, dan doen.
Kurt dit was een mooie serie van artikelen.
Ter aanvulling van de discussie nog een paar opmerkingen.
Kurt je hebt gelijk als je stelt dat Kenneth Berkleef als ondernemer en eigenaar van Equihold (1-2Focus) verantwoordelijk is voor zijn eigen risicoanalyse. Maar hij en zijn team waren daarbij wel afhankelijk van de informatie en de betrouwbaarheid van die informatie. Die informatie moet in dit geval vooral door derden worden geleverd vanwege de vergaande outsourcing. Bovendien weet Capgemini natuurlijk veel beter welke informatie uitgewisseld moet worden, wie welke informatie zou moeten leveren en waaraan die informatie moet voldoen. Het zelfde geldt voor wie wanneer welke beslissingen moet nemen. Vandaar dat er een zorgplicht door de sterkere partij Capgemini verwacht mag worden (of willen ze geen service leveren?). Daarom ben ik het geheel eens met je opmerking. Capgemini “zou Equihold (beter?) moeten adviseren en daar waar Equihold steken laat vallen, hen hierop wijzen”
Ik vraag me af welke acties de engagement manager (account manager) van Capgemini heeft ondernomen toen hij zag dat het al snel structureel mis ging. Een engagement manager behoort ook proactief op te treden, want je wilt geen engagement managent in name only.
Ten aanzien van “tenslotte is vertrouwen goed, maar controle beter!” Eens, maar je behoort dan wel te weten wie wat behoort te controleren en hoe. Je moet in dit geval de gehanteerde methoden en ‘terminologie van de opdrachtnemer voldoende begrijpen. Er ontstaat gemakkelijk miscommunicatie als de ene partij niet gewend is om opdrachtgever te zijn van een toch wel complex conversieproject, samen te werken met een heel groot ICT-bedrijf, te outsourcen in combinatie met offshoring, et cetera.
Bij vergaande outsourcing, zoals in deze casus, ligt die controle natuurlijk meer bij de opdrachtnemer Capgemini. Deze heeft het team in India zelfs afgeschermd. Equihold was / achtte zich verantwoordelijk voor de regie van het totaal en de projectleiding van de eigen werkzaamheden. Capgemini spreekt van detachering, maar vanwege de wederzijdse informatieplicht van halen en brengen hadden ze dit dan ook helder moeten aangeven, wat ze duidelijk niet gedaan hebben.
Een overall projectleider wordt niet in de documenten genoemd maar Capgemini had wel een delivery manager, een project manager, een change manager en meerdere test managers in het project zitten. Je mag je afvragen wat ze (op kosten van Equihold) aan het managen waren.
Voor de documenten het hetzelfde. Er was geen klassiek projectplan, maar er was wel een Software Development Plan waarin het plan grotendeels omschreven stond. En Capgemini, die het meeste werk zou doen, kon blijkbaar met het plan kan werken.
Het SIG-onderzoek van Capgemini waardeert de onderhoudbaarheid van de software als gemiddeld. Die waarde is echter gebaseerd op de gemiddelde software, inclusief slecht onderhoudbare legacy. Daarmee devalueert Capgemini zichzelf als een b-team. Je levert als topbedrijf toch geen nieuwe software die al tot het gemiddelde is gezakt.
Alarmbellen wanneer de eerste, en in welke periode negeerde Capgemini de klachten van Equihold op zo’n wijze dat Equihold er van uit mocht gaan dat het niet meer goed kwam.
Hetzelfde geldt ook voor Capgemini’s interne onderzoek. Wanneer vonden zij de klachten van Equihold verontrustend en wanneer dachten zij dat ze niet konden leveren wat de klant van hen verwachte? En wanneer zijn de bazen hiervan op de hoogte gesteld?
Bij Capgemini dachten dat ze alleen konden winnen ongeacht wat ze deden. Mooi winst maken en een bonus voor de bazen. Maar Berkleef heeft de boel naar buiten gebracht en daar had Capgemini niet op gerekend. De imagoschade aan Capgemini is nu heel groot. En verder moeten ze er rekening mee houden dat ze een deel van de schade veroordeeld worden (ben geen aandeelhouder van Capclaim).
Dank J., graag gedaan.
Zoals gesteld zijn er meerdere onderzoeken geweest. Naar aanleiding van de eerste oplevering waarbij Equihold opmerkingen had over het geleverde, heeft Capgemini een intern onderzoek gedaan en de inhoud aan Equihold teruggekoppeld: ‘over het algemeen goed’, hoewel de kwaliteit niet consistent is. In datzelfde rapport wordt ook verwezen naar een ander intern rapport waarbij specifiek gelet is of de richtlijnen aangaande de programmering goed is gevolgd. Ondanks aandringen van Equihold is dit rapport niet gedeeld.
De vraag is dan natuurlijk of dit bewust is gedaan en dat de inhoud daarvoor aanleiding was. Het is natuurlijk giswerk doch het is mogelijk dat hier is geconstateerd dat het programmatechnisch onder de maat is. Als dat zo is dan brengt het achterhouden van deze informatie het geheel op een hellend vlak van fraude en misleiding.
Behalve Equihold zat Capgemini dan ook klem. Zij hadden de klant en de hogere leidinggevenden dan moeten informeren dat er zojuist voor een half miljoen euro door het putje is gegaan wat zeker carrieres had gekost. De vlucht naar voren is dan, hoewel niet goed te praten, wel logisch. Tegen Equihold aanhouden dat het goed komt, geen zorgen (Equihold wil dat maar al te graag geloven) en vervolgens hopen dat er toch nog een werkbaar geheel uitkomt. Wat je al eerder defineerde als ‘jaren van aanmodderen’, als ik het goed heb 🙂