Stichting Capclaim strijdt onder leiding van Kenneth Berkleef van het failliete Equihold tegen ict-dienstverlener Capgemini. Inzet is het terugvorderen van 43 miljoen euro schade. Capclaim heeft de afgelopen maanden documentatie aan kenners uit de markt beschikbaar gesteld om hen over deze zaak te laten oordelen. Ook Computable-experts kregen inzage en zullen de komende tijd via deze website hun bevindingen delen. Deze vierde bijdrage uit het vijfluik van Kurt de Koning gaat over de aansturing van het gezamenlijke project van Capgemini en Equihold: de governance.
Een belangrijke voorwaarde om een project tot een succes te maken is invulling geven aan governance. Een begrip wat vrij breed is en daardoor verschillende definities kent. Terwijl een projectleider sturing geeft aan het project moet er een bestuurlijk adviserend orgaan zijn dat toezicht houdt op de werkzaamheden van de projectleider. Daar waar het project gaat afwijken van het oorspronkelijk plan, moet dit ‘gremium’ beslissingen nemen die consistent zijn, passen in het beleid, en daardoor zorgt dat er nog steeds samenhang is tussen de deliverables van het project en de organisatiedoelstellingen.
Stuurgroep
Een stuurgroep waarin de vertegenwoordiger(s) van de gebruikersorganisatie, opdrachtgever en opdrachtnemer in ieder geval in zitting in nemen, is prima geschikt om zo invulling te geven aan governance. Capgemini heeft voor het project van Equihold het Software Development Plan (SDP) (laatste versie 3 mei 2006, versie 0.75!?) opgesteld. Hierin is de stuurgroep gedefinieerd waar naast bovengenoemde personen ook de Capgemini engagement manager in plaats neemt. Deze engagement manager is volgens hetzelfde stuk verantwoordelijk voor het overall projectresultaat.
De stuurgroep zou tweewekelijks overleg hebben. In de praktijk is deze stuurgroep nooit bijeen gekomen. Dan komen er bij mij direct een aantal vragen naar boven. Wat als de stuurgroep ontbrak, kan er dan nog sprake zijn van governance? Is governance altijd nodig of kunnen projecten ook succesvol worden gestuurd zonder governance? Gezien de discussie over het soort contract, inspanning of resultaat, was/is het relevant om al dan niet een stuurgroep te hebben? Bij een inspanningsverplichting wel en bij een resultaatsverplichting niet? Natuurlijk wil ook ik weten waarom er nooit een stuurgroepbijeenkomst geweest. Was hier geen behoefte aan? Wie geeft normaal gesproken de kick-off van het project en hoe heeft dat nu plaatsgevonden? Wie had het initiatief moeten nemen tot de stuurgroepbijeenkomst? Als dit initiatief niet kwam had de partner in deze de ander hier niet op moeten wijzen? Had Capgemini als partner op basis van ervaring en het belang kennende van een stuurgroep hier Equihold op moeten wijzen?
Voortgangsrapportages
Zoals gezegd, er was geen functionerende stuurgroep, maar ook ontbraken andere documenten en rapportages waaruit de voortgang en kwaliteit kon worden opgemaakt. De meeste van deze documenten en rapportages staan wel genoemd als deliverables in het SDP. Aangezien Capgemini deze meeste activiteiten uitvoerde, mag het verwacht worden dat zij deze documenten en rapportages opstellen en conform een distributielijst rondsturen. Dit is niet gebeurd en er was ook geen stuurgroep die hierop aandrong zoals eerder geconstateerd.
Het betreft hier documenten en rapportages als het projectplan, voortgangsrapportages (valt ook weinig te rapporteren als er geen plan is waartegen gerapporteerd kan worden), een testplan van Capgemini en testverslagen, een overzicht van non-functional requirements, een wijzigingsoverzicht, de changeprocedure, per release de opgeleverde documents: end-user support material, release notes, bill of material, development case, quality reports, inclusief quality assurance reports en rapport non-conformiteiten, inventory project risk, iteration plans, requirement management plan, configuration plan, hierin moet het changeplan zitten, en een uitdraai van het defect management-systeem.
Niet verwonderlijk
Ik vraag me af of het onredelijk is om te veronderstellen dat genoemde documenten als deliverables gedurende de ontwikkeling moeten worden opgesteld. Samengevat, het project had geen enkele monitoring, controle en sturing op opdrachtgeverniveau en ook de middelen die nodig zijn om dit te doen ontbreken. Is het dan verwonderlijk dat het project niet heeft opgeleverd wat de opdrachtgever ervan had verwacht?
Equihold is een kleine organisatie met (vrijwel) zonder kennis van kennis projectuitvoering en het ging uit van een resultaatsverplichte afspraak. Mag van een dergelijke organisatie verwacht worden dat zij de invulling van governance, in de vorm van een stuurgroep, negeert of over het hoofd ziet? Of is het hier wel degelijk op aan te spreken? Ondanks dat in het SDP diverse documenten en rapportages zijn genoemd welke nodig zijn om de ontwikkeling tot een succes te maken, ontbreken deze tot op de dag van vandaag. Althans, tot op heden hebben ik ze niet gezien in het dossier waar ik toegang tot had.
Binnen Capgemini was een engagement manager aangesteld met als belangrijkste verantwoordelijkheid ‘zorg dragen voor het overall projectresultaat’. Had deze functionaris niet binnen zijn eigen organisatie moeten zorgen dat genoemde documenten worden opgesteld en gedeeld? Al was het maar om zijn eigen rol als resultaatverantwoordelijke in te kunnen vullen. Hoort dit bij de taken van een engagement manager?
Vertrouwen is goed
Equihold heeft steeds vertrouwd op de ervaring, kennis en kunde van Capgemini. Dit was een van de belangrijkste ‘buying points’ om in zee te gaan met Capgemini. Ook ging Equihold er vanuit dat gedane toezeggingen en correcties door Capgemini zouden worden nagekomen. Duidelijk is geworden dat dit niet het resultaat heeft opgeleverd wat Equihold voor ogen had. Is hier het adagium ‘vertrouwen is goed, controle is beter’ van toepassing? Zou dit niet altijd het uitgangspunt moeten zijn bij een project? Ongeacht of er op het project een resultaats- of inspanningsverplichting rust?
Als het antwoord op die vraag ‘ja’ is, hoe moet dit dan worden ingevuld? Is het meenemen van een eigen projectmanager, desnoods ingehuurd maar wel bij een andere organisatie (!), hierbij een mogelijke oplossing? Iemand die vaker met dit bijltje heeft gehakt en het klappen van de zweep kent, zal dit ongetwijfeld beamen.
Serie
In deze serie van zes artikelen van Kurt de Koning volgen nog twee delen. Het eerste deel ging over de aanbesteding, het tweede deel over de kwaliteit van de software en het derde over de inspannings- of resultaatsverplichting. Hierna volgt nog een bijdrage over hoe dit heeft kunnen gebeuren. Vervolgens zullen verschillende andere Computable-experts hun mening geven over de beschikbare documentatie.
Kurt, dit is een onthutsend verhaal.
Equihold had niet de ervaring en was daardoor niet ter zake deskundig, maar Capgemini heeft zich als ervaren bedrijf uiterst onprofessioneel opgesteld. Het heeft het engagementmanagement, projectmanagement, quality assurance en procesmanagement volstrekt onvoldoende tot geheel niet ingevuld.
De engagement manager van Capgemini had als professional Kenneth Berkleef moeten uitnodigen en aangeven dat de aansturing/governance moest veranderen om toch nog een positief resultaat te kunnen bereiken, en dat het anders beter was om te stoppen.
De projectmanager had de projectleden van Capgemini de strikte opdracht moeten geven dat ze de klant alle beloofde documenten en rapportages moesten leveren om hen inzicht te geven in de penibele situatie.
De engagement manager en de interne projectmanager van Capgemini hebben hun werkgever tijdelijk leuke winst opgeleverd, maar ze hebben het bedrijf uiteindelijk ook flink beschadigd. Beiden hadden al snel moeten zeggen, nu gaan we het anders doen of we stoppen. Capgemini is immers het bedrijf dat graag andere ICT-ers leert hoe het beter moet. De Capgemini Academy is in de Benelux het grootste trainingsinstituut zeggen ze zelf.
De situatie doet me denken aan de verhalen over malafide travellers; de naïeve klant van alles beloven, flink laten betalen totdat er geen geld over is, maar niets bruikbaars opleveren. Het verschil is dat Capgemini een topproduct had kunnen opleveren. Dit is slecht voor de gehele industrie.
Betreffende vermeende Calimerocomplex van: “Zij zijn groot en ik is klein en dat is niet eerlijk” moet ik erg lachen, het gaat hier niet om de organisatorische omvang maar het ‘rightsizen’ van je modellen. Wat ik herken in werkwijze van Capgemini is een (theoretisch) model leveren zonder aanpassingen te maken naar omvang en volwassenheid van organisatie, blauwdruk van Rightsourcing wordt gewoon gebruikt als verkooppraatje doordat er vooral processen in plaats van projecten mee geleverd worden. Dat is als PRINCE2 verkopen wat dus een papierstroom oplevert die even veelzeggend is als Rijks ICT-dashboard als er geen enkele sprake is van een ‘controlled environment’ en in eerdere opinie refereerde ik hier al eens aan met:
‘Men kan evenmin iets goeds voortbrengen door ’t volgen van modellen, als zich voeden met de spijs die ’n ander gegeten heeft.’ – Eduard Douwes Dekker
@Ewout, The World Is Flat en “maak eenzelfde product in .Net, zoals we hebben in VB6”? Nou, de uitgangssituatie en de opdracht aan Capgemini was toch wel complexer dan je schertsend omschrijft.
Voor Equihold moest tijdens de verbouwing de winkel open blijven, want zij hadden belangrijke veeleisende gebruikers/klanten die de basis waren voor verdere groei. Daarom moest de nieuwe .Net applicatie in eerste instantie dezelfde functionaliteit gaan bieden als de VB6 applicatie plus geplande extra’s en tijdelijk parallelle ontwikkeling. Technisch zou het om een meer toekomstbestendige modulaire .Net versie moeten gaan met een correcte drielagenstructuur voor een verbeterde onderhoudbaarheid, zodat er allerlei modulen aan de basissoftware toegevoegd konden worden om allerlei variant aan te kunnen bieden.
Dat is toch net even te veel voor eventjes een conversie met een tooltje en een RUP- en Prins In Name Only aanpak.