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
@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 https://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.