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. 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
Opmerkelijk dat altijd geroepen wordt dat ICT-ers niet kunnen communiceren maar als ik door verhaal heen ga krijg ik toch heel sterk de indruk dat het de managers waren die voor Babylonische spraakverwarring zorgden als we kijken naar de defintie voor regie:
“Men spreekt van regie als werkzaamheden worden opgedragen voor een vast bedrag per uur. De eindprijzen staan dus niet van tevoren vast.”
Als er sprake is van zwendel dan toch vooral bij eisende kant als ik kijk naar absurde winstdervingsclaim, dat is geen schrijven met een vork maar de hele bestekbak. Let wel dat de gekunstelde uitbesteding gedaan werd omdat Equihold zelf niet in staat was om de kwaliteit van VB6 applicatie te verbeteren. Aangaande al het andere gezam verwijs ik naar Eduard Douwes Dekker (Multatuli) die hier lang geleden over schreef:
“Men kan evenmin iets goeds voortbrengen door ’t volgen van modellen, als zich voeden met de spijs die ’n ander gegeten heeft.”
De literature parallel voor Anglo-Amerikaanse managementboeken lezende publiek is dat je niet van een ander moet verwachten wat jezelf niet kan want we hebben het vooral over sturen op de prijs van arbeid, niet op de kwaliteit met het ‘indiaantje-koekoek’ spelen. In de communicatie via ‘koelies’ heb ik al zoveel tegenstrijdigheden gehoord dat ik me afvraag hoeveel ICT-ers er eigenlijk nog bij betrokken waren als ik even kijk naar de enige terzake doende kwaliteitseisen van ISO-25010 omdat niemand geïntereseerd is hoe de worsten gemaakt worden.
Let vooral op de later (2011) toegevoegde eisen betreffende gebruik, best lastig in te vullen als je bedrijf eigenlijk niet meer is dan een doorgeefluik. In de vertaling van definities gaat dan ook veel mis als ik betreffende communicatie even de buzzwords afvink tegen de op dat moment populaire Anglo-Amerikaanse managementboeken. Natuurlijk zijn er de nodige verwijten te maken naar Capgemini maar Equihold was technisch al failliet toen ze gingen voor de offshoring van kennis.
De schaalbaarheid van de business wordt namelijk niet bepaald door de techniek maar de flexibiteit van je regie welke dus niet in de begroting maar de resultatenrekening zit. Het was dan ook niet het gemis aan communicatie dat ten grondslag ligt aan falen maar het korte termijn denken op schaakbord, analyse van de schaakmat achteraf laat alleen maar zien dat Equihold geen grootmeester was in het vooruit denken. Durf te wedden dat er ook ZZP-ers waren die een goed onderbouwd negatief advies gaven maar als het om communicatie van ICT-ers gaat dan wil bussiness geen NEE horen.
@Ewout, bedankt voor je esoterische bijdrage. Maar vind jij als gedreven medewerker van een groot bedrijf als Unisys ook niet dat je afspraken met een kleine klant moet nakomen en afspraken bijtijds moet verhelderen als deze verschillend uitgelegd worden?
N.b. Outsourcing is niet zo vreemd; jullie bieden zelf diverse vormen van Outsourcing diensten aan. Dat gebeurt overal; een ziekhuisdirecteur zal een ziekenhuis ook niet zelf bouwen, maar de bouw uitbesteden aan een aannemer.
@Jaap
Betreffende idee van regie heb ik een duidelijke definitie gegeven waar je nu weer om heen draait. Dat je choreografie van bedrijfsvoering kwijt raakt als je regie uit handen geeft mag niemand verbazen.
Je vergelijk met een ziekenhuis gaat dan ook compleet scheef als we kijken naar idee van ‘ontzorgen’ en opvatting dat een directeur van een worstenfabriek ook een ziekenhuis kan leiden. Let even op de literaire verwijzing naar Multatuli als we het over verschil van leiden en lijden gaan hebben.
Al met al concludeer ik dat er vooral veel ‘communicatiedeskundigen’ van hetzelfde bedrijf ingehuurd waren om probleem met communicatie op te lossen.
@Ewout, aangegeven is dat partijen verschillende definities zijn gaan gebruiken en dat dit problemen heeft opgeleverd. Door Capgemini is bijvoorbeeld de regiefunctie van Equihold (achteraf neem ik aan) gelijkgesteld werd aan projectmanagement van de geoutsourcde werkzaamheden door Capgemini.
De door jou aangehaalde definitie van regie is voor Capgemini net zo onaanvaardbaar als de omschrijving van regie in de raamovereenkomst waarvoor getekend is.
Dat ontkennen met behulp van worstvormige objecten als skeuomorphism, levert niet meer inzicht op.
Een beetje teruggaan naar Jip-en-janneketaal lijkt me beter. En voor zover dat niet kan, is het aan te bevelen om als leverancier een definitielijst te gebruiken voor je zelf en voor de klant. Dat is in deze casus helaas amper gedaan.
In het Raamcontract zijn slechts enkele definities beschreven, maar te weinig. In de RUP documentatie is het nog slechter gesteld. In de Vision wordt verwezen naar een apart Glossery document dat niet bestaat of niet is opgeleverd. In het Software Development Plan staan in de paragraaf Definitions, Acronyms, and Abbreviations geen definities. In het Software Architecture Document is de paragraaf Definitions, Acronyms, and Abbreviations zelfs geheel weggelaten.
Wat een gedraai om gek van te worden. Wij hebben ook wel eens cappers over de vloer met van die pakken maar meestal gewoon techneuten. Je moet wel heel goed vertellen wat ze moeten doen en waarom. En ze in de gaten houden anders gaat het niet goed. Henk, waarom structureel falende communicatie? Zijn toch de projectleiders die afspraken niet nakomen. En wat is het verschil tussen regie en projectmanagement.
@Martin, regie is het op afstand aansturen van een organisatie om de eigen bedrijfsdoelen te bereiken. Projectmanagement is het aansturen van mensen om een aangenomen project te laten slagen. Zeker bij een startup zoals Equihold, moet met elkaar goed afgestemd worden waar de knip ligt tussen regie en uitvoering. Zoals beschreven, verliep die afstemming het in het begin van het project redelijk en hoefden de afspraken alleen maar verder verduidelijkt en aangescherpt te worden. Dat laatste is uiteindelijk faliekant misgegaan.
Naar eigen zeggen hadden vier Vice Presidents van Capgemini de supervisie op de ontwikkelteams. Dat betekent dat Capgemini de informatie had van alle niveaus om deze te delen en te bespreken voor een win-win situatie met Equihold. Vice President is het bijna hoogste niveaus binnen Capgemini Nederland. Als vrijwel alle managementlagen langdurig betrokken zijn bij herhaalde miscommunicatie, dan noem ik dit structureel falende communicatie.