shutterstock_32191051De 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. Het laatste weerwoord is 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. In dit artikel wordt ingegaan op de falende communicatie bij het project.

Goede communicatie kan het verschil uitmaken tussen het slagen en mislukken van een project. Hieronder staan een paar opvallende voorbeelden van falen.

Wie zit aan het stuur

Wie de projectmedewerkers aanstuurde, is in het begin van het project redelijk gedetailleerd omschreven. Capgemini en Equihold tekenden voor een outsourcingsproject waarbij Capgemini alle ontwikkelactiviteiten uitvoert behalve het vaststellen van de requirements en het uitvoeren van de acceptatietests. Equihold had volgens de Capgemini rational unified proces (rup)-documentatie voor het outsourcing project twee contactpersonen/subject matter experts met betrekking tot het bepalen van de requirements en het goedkeuren van deliverables (naast Berkleef die ook de regie zou moeten krijgen). En ‘tijdens de uitvoering van de diensten rapporteren de medewerkers van Capgemini aan de projectleider of contactpersoon die Equihold aangesteld heeft.’ Die Capgemini medewerkers waren: vice presidents, delivery managers (voor front office Utrecht en voor back office Mumbai), project managers/engagement managers (voor front office en voor back office), change manager, quality manager, risk manager, test managers (voor front office en voor back office), software configuration managers (voor front office en voor back office) en later nog een onsite coördinator.

Dus je denkt: Capgemini zit aan het stuur in zowel Utrecht als in Mumbai (projectleiding) en Berkleef/Equihold vertelt waar ze heen moeten (regie), zoals afgesproken.

Capgemini stelt nu na het debacle: ‘Equihold was destijds als projectleider – nauw betrokken bij de ontwikkeling van de door Capgemini gebouwde software… De taak van Capgemini was beperkt tot het leveren van medewerkers die onder regie van Equihold werkzaamheden uitvoeren.’

Wat was dan de functie van die hiërarchische keten van managers van Capgemini? Bovendien  is er ook geen bewijs waaruit blijkt dat Equihold als projectleider de medewerkers van Capgemini heeft aangestuurd. Dus wanneer is Capgemini tot dat nieuwe uitgangspunt gekomen en waarom hebben ze daarover niet helder gecommuniceerd?

Verantwoordelijkheid

Capgemini had de opdracht om een .Net versie van de oude VB6 1-2Focus-applicatie te maken. Deze software was als voorbeeld op beide Capgemini locaties geïnstalleerd. Capgemini stelt ook ‘een project betekent: verantwoordelijkheid voor Capgemini. Aan de hand van helder geformuleerde acceptatiecriteria wordt bepaald of Capgemini zijn verplichtingen is nagekomen’. Er was een raamovereenkomst, een ‘vision, een software Ddevelopment plan, een software architecture-document en vele tientallen ‘use Cases’. Die documenten zijn door Capgemini opgesteld in overleg met Equihold. Dan zou je zeggen dat de opdracht toch wel behoorlijk helder moet zijn geweest.

Desondanks stelt Capgemini nu na vijf jaar werken aan het project: ‘Van een concrete ontwikkelopdracht met een gedefinieerd eindresultaat was geen sprake.’ Wanneer vond Capgemini de ontwikkelopdracht niet meer helder en waarom heeft zij gedurende de rest van het project daarover geen melding gedaan?

Kwaliteitsbesef

De gebruikers van 1-2Focus willen van de software functionaliteit kunnen gebruikmaken zonder blokkerende en hinderlijke bugs. Daarom schrijft Capgemini in het software development plan: ‘The team in Mumbai is responsible for delivery of high-quality software.’ Capgemini stelt dat ‘Indiase software-bouwers kunnen, mits goed aangestuurd, kwalitatief goede software leveren’ en daarvoor had Capgemini hele reeks van managers ingezet.

Afgesproken was ‘A complete and approved version of the first release should be available by 30-June-2006.’ Door problemen met bugs startte Equihold pas bij release 5 van 08-06-2007 met de eerste uitlevering aan klanten. Maar ruim drie jaar later waren er bij release 9 nog zoveel problemen, dat ook de laatste klanten wegliepen.

Capgemini stelt nu dat ‘Equihold er voor koos het product al te verkopen en te implementeren bij klanten, terwijl de ontwikkeling nog in volle gang was’. Dus hoeven de eerste 9 releases van Capgemini geen high-quality te bieden?

Maar het wordt nog gekker. Volgens het contract en de rup-documentatie zou Capgemini alle technische testen uitvoeren. Daar werd Capgemini ook voor betaald. Thans stelt Capgemini dat ‘…. telkenmale de code is opgeleverd en Equihold wel de technische kennis in huis had om daarover te kunnen oordelen.’ Gaat Capgemini er nu vanuit dat het testen door Capgemini los staat van kwaliteit en dat Equihold de softwarecode ook zelf technisch moet testen als ze kwaliteit willen?

Waarde van afspraken, contracten en documenten

Capgemini geeft aan ‘de uitkomsten van het inventarisatieproces zijn opgenomen in een software architecture document (sad), een vision document en een software development plan (sdp). Deze stukken zijn binnen rup standaard.’

In paragraaf 4.1.3 van het sdp ‘roles and responsibilities’ heeft Capgemini de verdeling van de verantwoordelijkheden tussen Equihold en Capgemini uitvoerig beschreven. Capgemini nu over deze beschrijving: ‘zij zeggen niets over de verdeling van de verantwoordelijkheden tussen klant en Capgemini’ en bovendien ‘het software architecture document en het software development plan zijn beide niet door Equihold goedgekeurd’.

Deze Capgemini documenten zijn niet geaccordeerd omdat deze niet afgerond waren. In de deels summier ingevulde conceptdocumenten staat op diverse plekken nog aan te vullen en dergelijke. De quality-paragraaf van de sad, die was bijvoorbeeld nog leeg. Capgemini is er niet in geslaagd om in de periode 2005 tot en met 2009 definitieve versies van het sad en sdp te maken.

Capgemini stelt nu door de niet ondertekende sad: ‘onjuist is de suggestie … dat de software architectuur  was confirmed by Capgemini in the form of a sad. Het was niet aan Capgemini de software architectuur goed te keuren. Dat was aan Equihold, als projectleider. Ook dat is een wezenlijk onderdeel van rup.’

Dat laatste klopt, maar helaas voor Capgemini zegt rup ook dat je niet verder moet gaan met de volgende stappen als je een voorafgaande fase zoals die van het opstellen van documenten niet hebt afgerond.

Capgemini gaat nog verder. Volgens Capgemini was er ‘… een overeenkomst met enkel algemene bepalingen die gelden bij het verrichten  van diensten door Capgemini ten behoeve van Equihold’. Het geeft daarmee aan dat het meest belangrijke onderdeel van het contract tussen Capgemini en Equihold te weten ‘bijlage C van de raamovereenkomst’ er niet toe doet. Dat deze bijlage met de essentie van de overeenkomst wel door Capgemini ondertekend is, dat wordt genegeerd. Waarop kan je je als klant van Capgemini nog baseren?

Tevredenheidsonderzoek

Equihold had niet alleen kritiek op de deliverables van Capgemini, maar ook op het personeel. Maar Capgemini zette Equihold onder druk bij de beoordeling van Capgemini-personeel in Mumbai. Ze schreven op 26 oktober 2006: ‘Nu is mijn ervaring met Indiërs, dat als we nu met veel kritiek komen, ze dichtslaan. Dan zijn het net schildpadjes die hun kop intrekken. Mijn voorstel is: de hemel in prijzen!’ Dus als Equihold die medewerkers niet flink de hemel in prijst, dan gaan ze hun werk minder goed doen. Daarbij werd van Equihold verwacht dat de beoordeling in de loop van de tijd eerder positiever werd, dan negatiever. Een vice president van Capgemini schreef: ‘Om het makkelijk te maken heb ik de waarden van de vorige keer alvast gekopieerd.’ De relatief hoge waardering in het tevredenheidsonderzoek was dus slechts bedoeld als stimulans van het personeel, niet als een echte beoordeling.

Nu stelt Capgemini: “In de periode 2007-2008, toen de meeste releases werden opgeleverd, stegen de klanttevredenheidscores van de door Capgemini geleverde diensten. Gemiddeld werd de dienstverlening gewaardeerd met 4,67 op een schaal van 0 tot en met 5. Capgemini verzet zich dan ook uitdrukkelijk tegen de veronderstelling dat de softwarecode ondeugdelijk was.’ Is dit trucje gewoon zwendel of het gevolg van extreem slechte alignment van Capgemini met Equihold door incompetentie?

Helaas zijn er bij dit project nog veel meer voorbeelden te geven van structureel falende communicatie door Capgemini waarbij zij zonder afstemming andere standpunten is gaan innemen. In zo’n situatie is er onduidelijkheid en onzekerheid over het doel en de inhoud van de opdracht, de relatie klant – leverancier, verantwoordelijkheden, acceptatiecriteria, et cetera. Dus weten ook de leden van de projectgroep niet wat van hen verwacht wordt en wordt degelijke project governance en it-alignment onuitvoerbaar gemaakt. De mislukking van het project 1-2Focus, komt dus mede door de falende communicatie, die hoofdzakelijk werd veroorzaakt door Capgemini. En aan die communicatiecultuur mag wat meer aandacht geschonken worden.

Jaap van Belkum, zzp’er

Category: Product #: Regular price:$ (Sale ends ) Available from: Condition: Good ! Order now!