Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

'Capgemini 1-2Focus: falen Quality Assurance'

 

De 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

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5236023). © Jaarbeurs IT Media.

?


Lees meer over



Lees ook


 

Reacties

Het is zeer jammer en spijtig dit soort uitgebreide, zij het zeer voorspelbare, zaken te lezen. Dit soort zaken gaan wij steeds vaker tegen komen. De redenen waarom worden hier in het artikel al breed uit opgesomd en snijden hout.

Zonder verder man en paard te noemen is dit scenario overigens niet alleen aan cap voorbehouden maar kom je genoemde problemen ook bij andere IT leveranciers tegen. De grondslag blijkt dan telkens toch een beetje dezelfde te zijn.

1. Geen materiekennis
Je kunt zeer bedreven, zelfs expert, zijn in een bepaalt IT vakgebied. Ik zeg dit overigens met alle Respect voor iedere lezeres, lezer. Maar ben je in de werking van de wetmatigheden van IT niet thuis of de IT keten, waarin je bezig bent, krijg je dit soort situaties en dat heeft op zich natuurlijk weer consequenties.

2. Gebrek aan IT keten ervaring/inzicht/overzicht
Steeds vaker komt dit gegeven voor wat dan weer kan en zal hebben verderop in de betreffende IT keten. Als je namelijk weinig inzicht hebt van hetgeen de opvolgende discipline doet en waar je op elkaar moet aansluiten, dan is dit vragen om misverstanden, proceshiaten en gaten in de overall communicatie.

Wanneer dan beiden nog eens in proces en productie elkaar tegenkomen werkt dit versterkend door in het hele proces. Voor je het dan nog kunt beheren en beheersen loop je zelf al snel achter de feiten aan met allerlei onverkwikkelijke gevolgen.

In dit geval een lang en schadelijk proces dat niet alleen verliezers opleverd maar wederom het aanzien van IT professioneel beschadigd. En dit alles kan zeker tot in voorkombare proportie worden teruggebracht.

Ik weet niet precies wat de relatie van de schrijver ten aanzien van de partijen is, maar als je zo betrokken bent in de beoordeling én één en ander nog onder de rechter is, moet je dan op deze wijze opening van zaken geven? Laten we nog even de uitspraak van de rechter afwachten en dan een publieksoordeel geven.
(Nee, ik werk niet bij Capgemini, maar ben wel mediator en dan let je op wat in welke fase verstandig is om naar buiten te brengen).

@Leen Blom, voorafgaande aan mediation, dient er bij beide partijen een fase bereikt te worden van niet meer willen vechten en elkaar wat te gunnen. En dat vergt soms veel tijd.

Mij bekruipen twee gevoelens bij het lezen van dit artikel:

1. QA'ers waren altijd al de lastpakken van een IT-organisatie, dus zijn ze wegbezuinigd (ook bij latere onderdelen van Capgemini)of worden hun adviezen niet serieus genomen. Of QA hier betrokken is geweest weet ik natuurlijk niet, maar ik heb (bij een andere organisatie) vaak meegemaakt dat de adviezen van QA in de wind werden geslagen omdat het project anders veel te duur zou worden.

2. Zo lang een zaak onder de rechter is is het niet verstandig te publiceren over de inhoud. Het zou best kunnen zijn dat Capgemini straks profijt trekt van deze publicatie omdat daardoor de rechtsgang beïnvloed zou kunnen worden.

Was dat de bedoeling misschien?

"Leen Blom.
Als je de 2e alinea van het artikel zouden lezen dat zou je zien wat de relatie van de schrijver met de partijen is.
Het is jou schijnbaar voorbij gegaan dat is maar de laatste is in een hele reeks artikelen over deze zaak allemaal geschreven door experts in dit soort materie.
De uitspraak van de rechter is wat betreft deze discussie weinig relevant. Wij zijn hier professioneel bezig en zijn vooral geïnteresseerd in wat er mis is gegaan met een oog op het voorkomen van dergelijke missers in de toekomst.
De rechter gaat een heel andere beoordeling geven nl of CapGemini juridisch iets te verwijten valt. Het kan zijn dat die beslist dat contractueel gezien CapGemini vrijuit gaat.
Dat heeft geen effect op deze discussie en vice-versa dus wachten heeft geen nut.
@Machteld Meijer.
Jij wacht te veel buitenlandse tv series. Beinvloeden van de rechtsgang door publicaties te doen is een angel-saksich en Belgisch begrip. Het zijn juryleden die worden geacht door publicaties te worden beinvloed. Nederlandse rechters worden geacht om ongevoelig voor publicaties te zijn. Als jij hieraan twijfelt kijk naar een willekeurig uitgave van de Telegraaf!

Het 'ontzorgen' kan alleen de overheid want bedrijven gaan gewoon failliet, ondernemen is tenslotte geen loterij zonder nieten en het is te hopen dat rechter dit ook zo ziet want voor je het weet heb je allemaal van dit soort opportunistische clowns.

Probleemm lijkt me dan ook eerder het verwachtingsmanagement - wens is hier de vader van de gedachte - dan het QA/QC proces. Hele idee van 'zorgplicht' bij innovatie is als succes op bestelling, ambtelijk ondernemen door zelf niets te doen maar er wel de vruchten van willen plukken.

Opmerkelijk hierbij is dat er steeds voor een 'olifant' proces bij een 'muis' organisatie gekozen wordt, Calimero argumentatie keert regelmatig terug terwijl het redelijk is om te verwachten dat iemand die de blauwe oceaan van ICT duikt wel zorgt dat hij kan zwemmen.

Dat pleit Capgemini nog niet vrij want deze lijkt door gehad te hebben dat beer nog niet beschreven was en beschrijving die ze gegeven hebben lijkt meer op de Grote beer aan het noordelijke firmanent dan een beest waarop ze konden gaan jagen.

Hele communicatie lijkt me namelijk van het type 'Mork calling Orson, come in Orson' als ik me door alle publicaties over deze zaak heen worstel.

@Ewout, ontzorgen door outsourcing, is normaal. Voor het MKB is het vaak min of meer onvermijdelijk, omdat ze de beperkte menskracht op hun core business moeten inzetten. Niet elk bedrijf kan gespecialiseerde afdelingen hebben voor ICT, HRM, communicatie, facilitaire zaken, et cetera, of nog meer specialistische afdelingen. De ING’s hebben het makkelijker dan de Calimero’s bij het outsourcen, omdat ze eigen specialisten kunnen inzetten voor begeleiding en controle.

Verwachtingsmanagement is inderdaad belangrijk bij outsourcing en dat heeft weer te maken met goede communicatie en QA/ QC, want kwaliteit is het voldoen aan expliciete afspraken en aan impliciete eisen en verwachtingen. De leverancier moet duidelijk maken wat deze aanbiedt, hoe het proces verloopt en die aantoonbaan afspraken nakomen. Bij het volgende artikel kom ik daarop terug.

Ik vind die laatste 2 reacties over "ontzorging" grappig in relatie tot het artikel. Projecten van 43 miljoen door Calimero's die geen eigen professionals kunnen inzetten om regie te voeren. Hoe moeilijk is dat nou ? Documentje maken waarin e.e.a. beloofd wordt tegen een bepaalde prijs. En dan periodiek checken in hoeverre daaraan voldaan is en actie ondernemen en bij discrepanties..

@Jan van Belkum
Mijn hond kan prachtig gecertificeerde drollen maken, als je echter in deze realiteit gaat staan dan wordt je niet erg blij. Er wordt namelijk telkens behoorlijk om de drol van paulianeus handelen heen gedraaid als ik in faillisementsverslagen lees dat primaire bedrijfsactiviteiten gingen om: "ontwikkelen van software voor sportclubs en sportbonden" waardoor het Calimero-argument veel weg krijgt van een kalispera-argument.

Het was namelijk de core activiteit die uitbesteed werd en het is opmerkelijk hoeveel moeite sommigen zich getroosten om de stok te vinden waarmee ze de hond kunnen slaan, ontwikkelen is tenslotte meer dan coderen. Voordat we over de zin en onzin van beschrijvende modellen gaan discusseren lijkt het me handig om eerst de afstand tussen expliciete afspraken en impliciete eisen te verkleinen omdat niks vermenigvuldigd met niks nu eenmaal niks blijft.

@Felix, je hebt gelijk; hoe is het mogelijk dat zo'n project stuk loopt. Een vaas kan je per ongeluk in één keer kapot stoten, maar hier moesten eerst heel veel ongelukjes gebeuren om het vele werk teniet te doen. En daar zat ook heel goed werk tussen.

Overigens het project heeft niet 43 miljoen gekost, maar 3-4 miljoen; de rest is een winstdervingsclaim. Maar het was nog steeds een groot project. Equihold had doorgaans 3 professionals ter beschikking voor de afgesproken taken binnen het project.

@Ewout Dekkinga, inderdaad ontwikkelen is meer dan coderen. Maar Equihold had niet de gehele software ontwikkeling uitbesteed. De technische software ontwikkeling was vrijwel geheel uitbesteed (use cases schrijven, technische ontwerp, code kloppen, testen en bijbehorend Q&A, proces- en project management en technische ontwikkelinfrastructuur). Voorheen huurde Equihold extra mensen in voor die technische ontwikkeling, die ze toen nog wel zelf manageden. De functionaliteit ontwikkelden ze samen met bekende sportprofessionals.

Dus de basis van je argumentatie, de core activiteit zou zijn uitbesteed, die klopt niet. Ik vrees dat je zelf moet gaan apporteren en wens je een kalispera (= goedenavond).

@Jaap
Je reactie doet me denken aan discussie te velde of sex nu werk of plezier was. Officieren beweerden dat het 100% werk was, de onderofficieren dat het 75% plezier en 25% werk was en soldaten dat het 100% plezier was met het ijzersterke argument dat officieren het anders wel door de manschappen hadden laten doen.

Als het lijkt op een eend, waggelt als een eend en kwaakt als een eend, dan is het meestal een eend want het lijkt me dus duidelijk dat meer dan alleen techniek uitbesteed werd bij het maken van software. Dat QA/QC betreffende kennisborging bij Equihold nog slechter was dan bij Capgemini had Kurt de Koning al duidelijk gemaakt want we kunnen om de drol heen blijven draaien maar ik heb het idee dat Capgemini de klant liet geloven dat er een 'ontwikkelfabriek' was, klant deze graag wou zien en uurtjes met een vork geschreven werden omdat offshoring vooral een managementspeeltje is.

Het is zoals ik eerder zei een 'duale bureaucratie' welke niet geschikt is voor innovatieve ontwikkeling omdat het meer een 'onderhoudsfabriek' is voor software die volgens de waterval methodiek ontwikkeld is als we naar achterliggende idee van QA/QC bekijken. Probleem met kwaliteitssystemen is dat deze vaak verkeerd ingezet worden als we kijken naar fenomeen van Titanic, opstellen van de specificaties waarop je gaat toetsen dient namelijk vooraf en met enige kennis van zaken gedaan te worden.

Betreffende idee van ERP heb ik als ingewijdde in specifieke sporten waar veel gebruik gemaakt wordt van analyses enige bedenkingen over de waarde hiervan bij tactische spelletjes, hetzelde geldt over idee dat sportbonden bepalen welke programmatuur gebruikt wordt. Vanuit de zwaar onbetaalde 'breedtesport' ben ik dus vooral bezig met hobbyisme van prototyping met Raspberry Pi, niet echt professioneel ontwikkelen omdat ik een pragmatische codeur ben met allerlei scripts maar wel heel innovatief.

Ik ben gecertificeerd in vele processen en producten maar blijf dus een kind welke telkens met de vervelende WAAROM vraag komt. En zodra een Zwakzinnige Zonder Pensioen met een antwoord komt dat stinkt als de drollen die mijn hond draait dan wordt ik heel vervelend omdat het mijn nieuwsgierigheid niet bevredigd. En dat is dus 75% plezier en 25% werk omdat wat ik leer voor een deel weer professioneel toepasbaar is terwijl investeringen veel lager zijn omdat ik falen incalculeer.

@Ewout, dat zijn vele woorden rond drollen en dat de wereld om je heen stinkt en iedereen is gek behalve jij. Maar wat is nu je punt?

Nee, het is niet gebruikelijk om zaken onder de rechter inhoudelijk de bediscussiëren. Zo alle informatie al beschikbaar zou zijn, hetgeen in dit forum niet het geval is.

Voor mij als projectmanager, IT-jurist, IT'er is dit in alle opzichten een smeuige casus. Reden waarom ik de discussie even heb afgewacht.
Ik ben zeer benieuwd of de rechter in staat zal zijn de volle omvang, verwevenheid en technische ins-and-outs van dit 'projectcontract' op hun merites te beoordelen. Ik hoop van wel. Ik hoop ook dat de diverse onderzoeken (audits, second opinions) daarvoor voldoende basis bieden.

Bovenstaande gaat hoofdzakelijk over 'outsourcing', software-project, RUP en QA.
Op basis van die informatie staat voor mij vast dat géén sprake is van pure outsourcing, maar van inhuur van deskundigen ('body shopping') binnen een inspanningsverantwoordelijke projectopdracht/-contract waarbinnen Equihold de regie had. Binnen die projectopdracht is een resultaatverantwoordelijk softwareontwikkelingstraject volgens RUP gedefinieerd waarover CG de QA/QC voerde.
Er is sprake van doorontwikkeling van 1-2Focus. Ik lees niets over onduidelijke specificaties of Test Driven Development (TDD).
Vanuit het projectcontract - niet vanuit het softwareontwikkelingstraject - zouden Gebruikers Acceptatie Test en Product Acceptatie Test echter nadrukkelijk gedefinieerd dienen te zijn.

Ik acht het dan ook waarschijnlijk dat de rechter de nadruk zal leggen op de wederzijdse invulling van de rollen van Equihold en CG als resp. opdrachtgever en opdrachtnemer.
En daarbinnen naar de invulling door CG van het resultaatverantwoordelijk softwareontwikkelingstraject.
En in het bijzonder daarbij de wederzijds haal- en brengplicht m.b.t. informatie, waaronder metrics en managementstuurinformatie. Vooral dat laatste is immers essentieel voor de sturing van zowel project als contract.

"Equihold had te weinig ervaring en capaciteit. Equihold wilde ontzorgd worden".
Daarvoor was naar mijn oordeel een andere opdrachtconstructie/contractinvuling passender geweest.
Ik heb een donkerbruin vermoeden over het uiteindelijk rechterlijk oordeel en vervolg.

Ik ben benieuwd naar het volgende artikel over het verweer van Capgemini.

@mr. P.J Westerhof, jammer genoeg was je er niet bij toen het raamcontract werd gesloten. Je was dan wellicht al snel tot de conclusie gekomen dat het ingevulde standaardcontractsjabloon van Capgemini over geld en de Bijlage C over het project, onvoldoende op elkaar aansloten. Je had aan de twee partijen kunnen vragen wat de bedoeling was en had daarmee wellicht ongelukken kunnen voorkomen of beperken door een beter geformuleerd contract op te stellen. Het contract had bij een goede uitvoering en samenwerking overigens best een win-win situatie kunnen opleveren.

Ben het niet met je eens dat het contract, incluis Bijlage C, over inspanningsverantwoordelijke 'body shopping' gaat. Niet alleen omdat o.a. de outsourcing van de softwareontwikkeling letterlijk in het contract genoemd wordt (stricti iures), maar ook door het gehele systeem van contract, de formele invulling van het project en de praktische uitvoering van het project (intentio partis). Afgesproken was “ dat Equihold een meerjarig commitment aangaat voor het uitbesteden van al haar software development activiteiten aan Capgemini” (uiteraard m.u.v. de functionele ontwikkeling, het acceptatie testen, enzovoorts, wat ook nader beschreven is in het contract en de RUP-documentatie). Die uitbesteding wordt onderschreven door de taakverdeling in de praktijk zoals in m’n tweede artikel is te lezen.
Die staat op http://www.computable.nl/artikel/opinie/diensten/5236138/2380656/capgemini-12focus-falen-in-communicatie.html. Misschien kan de redactie een verwijzing aanbrengen.

Wanneer de scheiding van de geesten is ontstaan, dat weet ik niet. Volgens het verweer van Capgemini ging het altijd al om een detacheringsovereenkomst. Maar dat kan niet, want er is in de praktijk nooit sprake van detachering geweest. Het lijkt me een noodsprong van hun advocaten, omdat een contract te goeder trouw moet worden uitgevoerd in overeenstemming met de toenmalige werkelijke bedoelingen van de contractanten. Omdat ik er vanuit ga dat Capgemini te goeder trouw aan het project is begonnen, neem ik ook aan dat de ondertekenaars van Capgemini de wil (voluntas) hadden om te outsourcen en dat ze snapten waarvoor ze tekenden en wat zij redelijkerwijs van elkaar mochten verwachten.

Over wat onder regie, kwaliteit, project management en andere zaken, verstaan moet worden, daarover is thans net zo veel juridische strijd. Capgemini verwijst daarbij in hun verweer vooral naar hun eigen opvattingen en hun interne communicatie.

De Product Acceptatie Test was formeel belegd bij Equihold. De Gebruikers Acceptatie Test was door Capgemini niet benoemd. Formeel had Equihold de contacten met de eindgebruikers. Capgemini had / wilde geen contact met de eindgebruikers. Dat is wel heel jammer, om meerdere redenen.

Zo te zien hebben de projectleiders van Capgemini grote fouten gemaakt. Dit is doormodderen. Hoe kan je daarover tevreden zijn. Dus geld terug! Was er niemand die echt de leiding had en het project weer op de rails kon zetten?
Heb nog een vraag. Het ging toch om de software en niet om Rup documenten. Hoe was die software dan?

Beste mensen,

Wat zie ik een taalgebruik in de reacties hier!
Maar waar ik echt over struikel:

@Ewout: Wat is een Kalispera argument? Het is grieks voor goede hoop en wordt in de middag vooravond gezegd, maar ik heb geen idee wat de argument variant is.

@Jaap van Belkum: Coderen is een volledig foutieve Anglicisme dat naar mijn idee door de politiek in leven is geroepen. Als we op deze term gaan voortborduren wat is een "Gecodeerd Bestand" dan? Een versleuteld of een geprogrammeerd bestand?

@Technicus, misschien is coderen een foutief Anglicisme. Ik ben geen taalpurist en probeer pragmatisch te zijn.
Coderen behoort wel tot onze officiële spelling, want het staat in de Woordenlijst Nederlandse Taal van de Taalunie, net als jouw “gecodeerd”; zie http://woordenlijst.org/zoek/?q=coderen&w=w. Een vakterm (terminus technicus) in de ICT is meestal een Anglicisme. Slechts een klein deel van het hedendaagse Nederlands komt voort uit het Nedersaksisch of Nederfrankisch.
Er zijn meerdere betekenissen aan coderen te geven; zie http://www.encyclo.nl/begrip/coderen, maar ik zie niks dat met politiek te maken heeft. Dat mag je me uitleggen.

@Martin, er was min of meer een algemeen projectmanager in Nederland voor het geheel. In het Investigation Report - een soort interne audit van Capgemini- staat: “Starting out in the First quarter 2006 Capgemini has overall project management responsebility” Die persoon is medio september 2006 zonder overleg met Equihold opeens weggegaan, zonder overdracht van schriftelijk informatie bleek bij navraag.
Hij is niet echt vervangen, maar een deel van de taken werd wel waargenomen door een Vice President Capgemini in de hoedanigheid van Delivery Manager. ”During the development phase the development teams were supervised by a number of Vice Presidents” (volgens het Investigation Report van Capgemini).

Martin, op de kwaliteit van software kom ik een andere keer nog terug. Kan wel alvast aangeven dat de code reviews matig tot behoorlijk negatief zijn over de kwaliteit van de code van Capgemini en dat er door Capgemini veel bugfixes opgeleverd moesten worden. Dat laatste zegt ook veel. De negatieve reacties van de professionele gebruikers heb ik al hierboven aangeduid en dat Equihold ook niet blij was, dat mag duidelijk zijn.

@ Machteld Meijer, ik heb wat literatuuronderzoek gedaan. Uit diverse onderzoeken blijkt dat de invloed van de media op civiele uitspraken nogal gering is. Met een debat in de media heeft de rechter geen problemen, zolang het niet van politici met onderbuikgevoelens is. Een argument of conclusie op de Computable website is bovendien vaak niet eens juridisch relevant, omdat de rechter vanuit de wetgeving moet werken. Media hebben soms invloed op de strafmaat doordat verdachten al door de media gestraft kunnen zijn (trial by media), maar dat is hier niet van toepassing.

QA/QC?, inderdaad oplossen van problemen kost geld en wellicht sommigen ook een bonus. Maar het niet oplossen kost vaak veel meer. Een klant wil een project dat oplevert wat ze ervan hadden verwacht. Daarvoor moet de projectmanager van de leverancier ook de ruimte krijgen van het eigen bedrijf. Immers zoals Capgemini het vroeger stelde “als een project fout loopt, dan is het de schuld van de projectmanager, zelfs al is het niet zijn schuld”. Door de eigen projectmanagers op een verkeerde wijze risicomijdend te laten werken (bijv. uurtje factuurtje) om te voorkomen dat er op het project verlies wordt geleid, ontstaan andere veel grotere risico’s voor zowel de opdrachtnemer en opdrachtgever. Met wat creativiteit lijkt het op papier alsof je de risico’s kan beheersen, de werkelijkheid haalt je in.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×