'De regierol in het ontwikkeltraject lag bij Capgemini en niet bij mij. Mijn medewerkers mochten niet eens contact opnemen met de Capgemini-ontwikkelaars in India. Dus hoezo lag de regievoering bij ons?'. Dat stelt Kenneth Berkleef, oud-eigenaar van het failliete softwarebedrijf Equihold, in een reactie op het standpunt van de automatiseerder dat Equihold de regierol had bedongen. Beide bedrijven zijn in conflict geraakt over het faliekant mislukken van een sportmanagementsysteem.
Berkleef heeft naar aanleiding van het mislukte project, waardoor zijn bedrijf failliet ging, bij Capgemini een claim neergelegd van 43 miljoen euro. In een reactie daarop liet de automatiseerder weten daarover verbaasd te zijn. Equihold had zelf de regierol opgeëist en had gedurende het traject nooit geklaagd over de kwaliteit van de door de Cap-Indiërs ingeklopte softwarecode, aldus Capgemini.
Volgens Berkleef lag de regie met betrekking tot de ontwikkelwerkzaamheden weldegelijk bij Capgemini. In een schriftelijke reactie laat hij weten dat Equihold zich beperkt heeft tot het bewaken van de ontwikkelrichting – voor welke sport moest een applicatie worden ontwikkeld – en het functioneel toetsen van de applicatie. ‘Capgemini hield zich bezig met de werving en selectie van het ‘ontwikkel’-personeel, het toezicht houden op dit personeel, het ter beschikking stellen van software, hardware en communicatiemiddelen aan dit personeel en het beoordelen van dit personeel. Capgemini hanteerde, op papier, de zogenaamde RUP-methode om tot productontwikkeling te komen en zou er derhalve op toegezien moeten hebben dat deze methode door het personeel ook daadwerkelijk werd toegepast.’
Verboden
De oud-directeur wijst er op dat directe communicatie tussen Equihold en Capgemini-medewerkers in India tot 1 januari 2007 verboden was. Communicatie bleek bovendien sowieso niet mogelijk omdat Capgemini in India niet beschikte over internetcommunicatiesoftware zoals Skype of Teamviewer en Equihold geen directe telefoonnummers van de India-medewerkers had. Communicatie met India vanaf 2007 was slechts mogelijk via de door Cap aangewezen ‘liason officers’. E-mailen met individuele programmeurs vond bij zeer hoge uitzondering plaats. ‘Van door Equihold gevoerde regie in deze kan dan ook geen sprake zijn’, concludeert Berkleef.
Niet werd gewaardeerd
Opmerkelijk is verder zijn opmerking dat het eigenlijk niet mogelijk was het ontwikkelwerk uit India kritisch te beoordelen. Berkleef kreeg, naar eigen zeggen, van Roel van Schaik, de toenmalige vice president Capgemini Nederland, te horen dat een lagere beoordeling dan 4.3 (op een schaal van 1- 5) niet werd gewaardeerd en mogelijk tot repercussies zou leiden voor de mensen in India. ‘De vervolgbeoordelingen mochten ook niet lager zijn dan de eerste beoordeling en gemakshalve werden deze door Capgemini-medewerkers zelf ingevuld. E-mails die deze gang van zaken bevestigen zijn ingebracht in de gerechtelijke procedure. Deze beoordelingen kunnen derhalve niet gelden als door Equihold in volledige onafhankelijkheid zelf gegeven uitingen van tevredenheid’, aldus Berkleef.
Verdraaiing
De constatering van Capgemini dat de door Equihold ingediende claim van 43 miljoen euro dertig keer hoger is dan de maximale schadevergoeding uit het contract, pareert Berkleef met de opmerking dat, indien er in de gerechtelijke procedure wordt vastgesteld dat er sprake is van grove schuld, opzet of onrechtmatig gedrag van Capgemini, de rechter de beperking van de aansprakelijkheid ter zijde kan schuiven.
Hij meent dat daarvoor zeer goede gronden aanwezig zijn en wil in de procedure aan de hand van de source code en de beschikbare documentatie aantonen dat er sprake was van spaghetticode, misleiding van de klant over de kwaliteit van programmeren en het verdraaien van de werkelijkheid binnen de Capgemini-organisatie op diverse niveaus, met name van de klantbeoordelingen en het standpunt van de automatiseerder dat Equihold pas voor het eerst klaagde over de software na het faillissement.
Rijkaard
Berkleef is tevens verbaasd over de opmerking van Capgemini dat het niets weet van de betrokkenheid van ex-profvoetballer Frank Rijkaard en/of zijn zaakwaarnemer bij de claim. ‘Frank Rijkaard heeft via zijn investeringsvennootschap een belang van 8 procent in Equihold BV. Hierdoor heeft hij uiteraard belang bij het verdere verloop van de procedure. Op 27 mei, de dag voordat de zaak bij de Rechtbank werd ingediend, is de zaakwaarnemer van Rijkaard door mij op de hoogte gebracht’, beweert Berkleef.
Als Zorgware BV heb ik, samen met mijn Oekraiens team, in 2007 een applicatie gebouwd voor het ministerie van Defensie, dat 6 jaar onafgebroken en zonder één enkele foutmelding heeft gefunctioneerd. Helaas moest het vervangen worden door een SAP applicatie. Ondanks alle bemoeienissen van de afdeling zelf is men nu al 2 jaar bezig om iets te bouwen waar men ook wel mee zou kunnen werken. Echter is volgens mijn info SAP absoluut ongeschikt om als webapp in een oorloggebied goed te functioneren. Recentelijk hebben we het bouwen van een applicatie gestart met een bedrijf in India. Dat gaat goed mits alle regie en kennis uit Nederland komt. Laat men daar dan maar de code kloppen en testen. Maar wel ontwikkelen op een dermate flexibele manier dat we daarna nog zelf kunnen instellen, afregelen en fijnslijpen zonder de noodzaak van kennis uit India. Het is dus een kwestie van een kleine organisatie met een voldoende kennis van zaken in Nederland houden en dan kan het klaarblijkelijk wel goed gaan.
Aan de Computable topics kan nu definitief het topic ‘Insourcing’ worden toegevoegd…. Nu de experts nog zien te vinden.
Eindverantwoordelijkheid kun je niet uitbesteden.
Zelfs als je een televisie koopt ben je zelf verantwoordelijk voor het vaststellen van de specificaties en het controleren of aan de specificaties wordt voldaan. Ook de plaatsing in een bepaalde ruimte, de stroomvoorziening en het onderhouden – schoonhouden, garantie afsluiten, e.d. – zul je zelf moeten regelen.
Voor software kun je een analogie schrijven (applicatielandschap, verantwoord gebruik, professioneel onderhoud, etc). Bij maatwerk software is het nog wat complexer dan bij een standaard off-the-shelf-product, omdat de opdrachtgever dan ook een verantwoordelijkheid TIJDENS de realisatie heeft (status-/kwaliteitscontrole, risico management, contract management, communicatie naar interne stakeholders, etc.).
Zeker als je software zo bedrijfskritisch is moet je een slimme(re?) contractvorm kiezen, waarbij je de opdrachtnemer (bijvoorbeeld in een joint venture) deelgenoot maakt van falen/succes. Waarschijnlijk kom je dan niet bij CapGemini uit: de schaalgrootte (en dus het risico) is simpelweg niet vergelijkbaar met die van de opdrachtgever.
Als je dat bij contractering goed doet, hoef je niet jaren later rechtszaken te voeren over het verdelen van de pijn.
Deze discussie (en rechtszaak) gaat dus over – gecontracteerde – verantwoordelijkheid en niet over regievoering.
Bizar nieuws.
Er zijn in India ook zeer goede programmeurs, dus laten we ze niet allemaal over 1 kam scheren. Als we Nederlandse programmeurs met weinig ervaring inzetten is de kans op slechte software net zo groot.
Wat wel vaak voorkomt, is dat het voordeel van de lagere kostprijs in India weer te niet wordt gedaan doordat meer mensen of meer uren nodig zijn dan dat het in Nederland zou worden gebouwd. Komt nog bij kosten voor vertalingen van specificaties van Nl naar Engels en weer terug, reiskosten, communicatiemiddelen en het oplossen van fouten door miscommunicatie. Dus je moet je wel goed afvragen of outsourcing een goede oplossing is voor jouw project. Kleine, co-located cross-functional Agile teams met face-to-face contact met de klant en eind-gebruikers kan zomaar veel meer opleveren.
@Els
Het probleem zit niet in de kwaliteit van de programmeurs, het probleem zit hem in de ingewikkelde communicatie en de extra management lagen die noodzakelijk zijn. Tel daarbij op de dat de ontwikkelaars geen enkele materie kennis hebben en de grote cultuur verschillen en het wordt duidelijk waarom al die geoutsourcde projecten mislukken.
Uiteraard begrijp ik dat Cap blijft volhouden dat jullie offshoring met Agile, co-locatie etcetera vanuit Utrecht echt voordelen hebben maar geef dan ook een paar geslaagde voorbeelden. Welk project heb jij afgelopen jaren succesvol afgerond waarbij alle partijen tevreden waren en jullie niet over budget gegaan zijn en ere achteraf niet allelei problemen de kop opstaken? Hoe kan jij goede programmeurs in India vinden met een lagere kostprijs dan ontwikkelaars in loondienst?
Het is bijzonder lastig van afstand over iets te oordelen als je de in’s en out’s niet kent. Assumption still is the mother of all fuck ups….. in the end.
Wat ik wel weet is dat het niet moeilijk is uiteindelijk uit te leggen waar en waarom het fout is gegaan. Dat heeft alles te maken dat bepaalde wetmatigheden in en rond IT niet werden gevolgd met alle gevolgen van dien.
http://bit.ly/1xaIhGP laat zien wat ik bedoel. Wanneer je gewoonweg niet goed signaleert en controleert, geen vinger aan de pols hebt, loop je al snel hopeloos achter de feiten aan. En dan loop je in discussies als deze.
Datzelfde geld voor de positie van Berkleef. Men had het kunnen weten. Sterker nog, wanneer de processen op orde waren had men het domweg moeten weten.
@Els
“Kleine, co-located cross-functional Agile teams met face-to-face contact met de klant en eind-gebruikers kan zomaar veel meer opleveren.”
Als het ‘zomaar’ veel meer ‘kan’ opleveren, kan het dus ook ‘zomaar’ veel minder opleveren. Tja.