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
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.