Ik heb op verzoek getracht het project management deel van de Capclaim te evalueren op basis van de documenten die aan mij verstrekt zijn. Ik heb voornamelijk het Software Development Plan (SDP) document geraadpleegd voor mijn bevindingen.
Ik wijs er met nadruk op dat ik geen waardeoordeel uitspreek over de Project Management-aanpak bij dit project, maar alleen toets aan de algemeen geldende en aanvaardbare principes die bij Project Management gelden, zoals daar zijn: toepassen van een project methodologie zoals Prince2, toepassen van de grondslagen van de Administratieve Organisatie (AO) en toepassen van Project Management Key Performance Indicators (KPI)
Status Software Development Plan
De status van het Software Development Plan (SDP) is niet duidelijk. Is het SDP een Business Requirement Document (BRD), een Globaal Functioneel Ontwerp (GFO), een Functioneel ontwerp (FO) of is het een Globaal Technisch Ontwerp (GTO).
Persoonlijk is het bijna niet mogelijk om met deze SDP de bouwfase in te gaan, aangezien de business wensen van de gebruikers nog omgezet moeten worden in functionele specificaties. De kans op mis interpretaties voor wat betreft de te leveren businessproducten is hierbij nog te groot in termen van tijd en budget.
Verantwoordelijkheden. De geconstateerde rollen zijn niet zuiver en helder gedefinieerd. Tevens vervullen dezelfde personen tegelijkertijd diverse rollen die met elkaar in conflict kunnen zijn. Soms geen duidelijke functiescheiding bij de taken. Sommige personen vervullen meerdere taken, soms wel drie, waarbij de taken zowel uitvoerend als coördinerend kunnen zijn. De slager mag dus zijn eigen vlees keuren.
– Opmerkelijke zin: The customers, including the end-users, of the product Sports Management Solutions are not actively involved in the project. The customers will execute their role as stakeholder through 1-2Focus;
– 1-2Focus vervult teveel rollen: Klant, end-users, deployment and maintenance. De rollen klant en end-user kunnen niet door 1 instantie (persoon) vervuld worden;
– Niet duidelijk is, wie de algehele Project Manager is;
– Cap Gemini heeft een beperkte rol, namelijk leverancier van software dat te summier beschreven staat in de SDP. Klant- opdrachtgever relatie is niet geheel duidelijk; ‘Who is the customer?’;
– Is 1-2Focus the customer or is 1-2Focus the customer of the customer? From Cap Gemini point of view, 1-2Focus is the customer.
Deliverables.
De deliverables worden niet in detail beschreven. Tevens is de deliverable ‘vision’ vaag omschreven en zou geen deliverable moeten zijn die door Cap Gemini geleverd zou moeten worden.
Use-cases zijn gebruikerswensen en kunnen niet altijd één op één vertaald worden naar functionele specificaties. De vertaling van use-cases naar functionele specificaties worden niet beschreven. De gebruikerswensen, c.q. use-cases zouden door 1-2Focus als klant zijnde geleverd moeten worden, gebaseerd op het Business Requirement Document.
Budget
Het is niet gebruikelijk dat een budget fixed is als de functionaliteit niet duidelijk is. Er is geen Detail Functioneel Ontwerp (DFO), waardoor de kans op mis interpretaties aanwezig is. Hierdoor wordt de kans groter dat het project niet binnen tijd en budget geleverd wordt.
Bij onderstaande zin, waargenomen in de SDP, wordt een ‘Blind check’ afgegeven. Cap Gemini krijgt hierdoor een vaste omzet per periode, ongeacht het hoeveelheid werk dat hiervoor verzet wordt; The development capacity in man hours is fixed in advance each quarter of a year. This budget cannot be exceeded. 1-2Focus specifies the budget and in mutual agreement the functionality to be built is specified. There is a fixed budget of hours per quarter.
Aanname van een fte van 1760 is vrij hoog. Daarnaast worden deze uren met een minimum van drie FTE gefactureerd ongeacht of er activiteiten hebben plaatsgevonden of niet. Dit is een vorm van omzetgarantie.
Kwaliteit
Quality Control (QC) wordt eenzijdig beschreven als het voldoen aan de QA criteria van Cap Gemini. Gebruikelijk is dat QC gezamenlijk bepaald wordt tussen opdrachtgever en uitvoerder op basis van het functioneel ontwerp. Daarnaast is het eindoordeel van de klant zwaarwegend. Heeft de klant gekregen wat beschreven stond en ook wat de perceptie van de klant was, ervan uitgaande dat de perceptie constant getoetst is.
– De conditie dat Cap Gemini projectleden moet leveren met adequate ‘knowledge and experience’ is heel vaag, vooral omdat de kwaliteit (aantal jaren ict-ervaring) van de projectleden in India niet direct inzichtelijk worden gemaakt.
– De planning van de ‘milestones and deliveries’ zijn zeer compact en rechtlijnig. Er is geen opvang ruimte voor calamiteiten.
– De condities van acceptatie van de producten zijn eenzijdig geformuleerd vanuit Cap Gemini. De klant heeft weinig speelruimte voor verweer.
Samenvatting
Algemeen constateer ik dat bij de partijen 1-2Focus en Cap Gemini een verschil in ict-kennis en ervaring aanwezig was, waarbij de opdrachtgever te weinig algemene ict-kennis en ervaring bezat. De opdrachtgever ging er vermoedelijk vanuit dat bij het verstrekken van de opdracht de opdrachtnemer op het Project Management deel corrigerend zou optreden.
Ik stel mijzelf de vraag in hoeverre ik in de positie van opdrachtverstrekker ingestemd zou hebben met het eenzijdig opgestelde contract en bijbehorende Software Development Plan.
Om een lang verhaal kort te maken, de klant besteld een kilo rundergehakt en krijgt een pond paardenvlees omdat deze het verschil niet kan zien of wegen. Oftewel kennis is macht want Equihold en andere vennootschappen (1-2 Focus Holding en 1-2 Focus Automation) hadden de ballen verstand van softwareontwikkeling of projectmanagement.
Of ze dat krijgen met deze analyse is bedenkelijk als ik kijk naar de beroepsdeformatie door het gebruik van allerlei nietzeggende afkoringen en begrippen. Want een ander punt dat ik aan wil halen is de beoordeling van de kwaliteit op basis van een toetsingskader dat om processen gaat daarvoor juist RUP methodiek verkocht was. RUP of PRINCE2 in name only of gewoon een gevalletje “If you can’t convince them, confuse them.”
Want wederom wordt de suggestie gewekt dat Capgemini ‘des broeders hoeders’ moet zijn, een zorgplicht had aangaande kennis hiaat van de klant. En dat is een interessante gedachte als ik overweeg dat met uitbesteding juist kind van de kennis weggegooid wordt met het badwater van de kostenverlagingen. Er lijkt me namelijk sprake van twee partijen die GEEN verstand hadden van softwareontwikkeling als ik overweeg dat dus alles over de schutting gegooid werd naar India.
Wederom is hier geen sprake van olifanten doen het met olifanten maar verkopers doen het met verkopers. En iedereen weet dat dit dus net politici zijn, ze zijn altijd bezig met de volgende verkiezingen en leveren nooit wat ze beloofd hebben. Of om woorden van voormalig minister Piet Hein Donner te gebruiken: Softwareontwikkeling is als een worstenfabriek, een vleeshandel waar je nu indiaantjes als kiloknaller krijgt.
Leendert, een mooie analyse. Je beschrijft heel veel punten waar het procesmatig mis is gegaan.
Zo zijn onderdelen van het Software Development Plan niet volgens de Rational Unified Process standaard ingevuld. Dat is jammer, want RUP past heel goed bij het component based incrementeel ontwikkelen van software waarbij een deel van de requirements nog in te vullen zijn. Het SDP moet volgens RUP aangevuld worden met onder andere een Business Case, Risk List, Risk Management List, statusrapportage, Iteration Plan en Iteration Burndown Chart. Zijn die documenten wel door gemaakt Capgemini (samen met Equihold) zoals we mogen verwachten?
Het Software Development Plan beschrijft de ontwikkelaanpak. Het is geen volwaardig Plan van Aanpak, omdat bijvoorbeeld het management van resources ontbreekt. Bij het SDP horen een aantal documenten, bijvoorbeeld het genoemde Business Requirement Document, Globaal Functioneel Ontwerp, Functioneel ontwerp en Globaal Technisch Ontwerp. Daarin worden aspecten nader uitgewerkt. Een Product Acceptance Plan is in deze casus ook wel zo handig om achteraf de discussie rond goedkeuren van de deliverables te beperken. Natuurlijk hoef je niet altijd al die genoemde documenten in te vullen en zeker ook niet altijd in z’n geheel. Maar een SDP maken zonder bijbehorende documenten en dus de bijbehorende afstemming, dat is RUP In Name Only. Pas als dit kader goed ingevuld is, dan kan je de use cases verwerken om daarmee software modules voor de transitiefase te maken.
Leendert, het Vision document beschrijft normatief het gezamenlijk perspectief van opdrachtgever en opdrachtnemer met betrekking tot het project. Dit lijkt me in deze casus wel relevant. Helaas had Capgemini weinig behoefte aan communicatie. Zo moest Equihold wegblijven bij de Indiase medewerkers en wilde Capgemini geen direct contact hebben met eindgebruikers, oftewel Black boxes die via RUP In Name Only interfaces met elkaar moesten communiceren? Dat lijkt mij vanuit mijn ervaring een recept voor mislukkingen.
Zoals beschreven heeft Capgemini een vaste omzet per periode bedongen, ongeacht de hoeveelheid werk, is de QC die van Capgemini, worden de condities van acceptatie gedicteerd door Capgemini, et cetera. Zo heeft Capgemini vrijwel alle risico’s bij zichzelf afgedekt / doorgeschoven naar Equihold. Capgemini lijkt Equihold (1-2Focus) als muppet te hebben gezien, zoals veel banken dat met hun klanten gedaan hebben bij de verkoop van derivaten die door de klant moeilijk te doorgronden zijn. De vaste winst is voor de verkoper, maar de klant moet maar hopen er ook bij te winnen of zelfs hopen niet meer verliezen dan de investering sec. Nu is dat op zich niet verboden, maar de zelfs rechtsliberalen vinden dat bij een financieel product een goede financiële bijsluiten moet zijn. Ik wil het contract wel eens zien.
Nu de rapen gaar zijn, probeert Capgemini zich (nog steeds) achter de regierol van de opdrachtgever te scharen. Maar indien je als klant met de taxi gaat, dan heb je ook de regie zonder dat je daarvoor een taxivergunning of zelfs een rijbewijs voor hoeft te hebben. De klant mag de prioriteiten bepalen, of er een tussenstop moet worden gemaakt, enzovoorts. Rijdt de taxi ergens tegenaan, dan is de taxichauffeur hiervoor verantwoordelijk ondanks de regie van de klant. Vraagt de klant expliciet om te parkeren op een daarvoor verboden plek en dit is door de chauffeur aangegeven, ja dan pas moet de klant extra gaan dokken.
Leendert, het laatste antwoord is nee, neem ik aan.
Eens met Ewout hier.
De beroepsdeformatie is een klassieker overigens. Wanneer je namelijk als IT professional steeds perfecter in je materie gaat zitten, dan is het een wetmatigheid dat je in gaat boeten in je externe communicatie.
De tweede valkuil, alsof men na zoveel jaar IT het nog steeds niet door heeft, is heel voorspelaar. Er gewoon nog steeds niet voor zorgen dat je klant en jij op hetzelfde niveau zitten. Dat zaken inhoudeijk nog steeds niet goed op elkaar afgestemd blijken.
Locktight
Wat je stelselmatig de grotere IT dienstverleners dan ook ziet doen is trajecten opstarten waar op een bepaald punt, ook een beetje doortrapt, sprake is van een LockTight. Namelijk er voor zorgen dat de klant tot jou is ‘veroordeeld’ en ontmantelen vele malen meer kost dan op de ingeslagen weg in gaan.
Dit laatste is overigens allesbehalve nieuw. Miljarden en miljarden gaan namelijk op deze wijze volkoemn verloren en klaarblijkelijk beseffen de IT diensten leveranciers nog steeds niet hoe schadelijk dergelijke zaken zijn voor de naam en reputatie van IT in zijn algemeen.
Als je telkens negatief in het nieuws komt, je dan vervolgens zelf met een ‘deftige’ analyse komt, dan wordt ook dat niet echt geloofwaardig. Jammer. Het probleem zit hem namelijk niet in wat het artikel beschrijft.
De angel zit hem namelijk dat je niet in staat blijkt je klant te managen en er zelf voor te zorgen dat je op welk gewenst deeltraject, een pas op de plaats te kunnen maken zonder dat de boel omvalt of stagneert.
Dan kun je iets roepen over PM, QA of KPI. Als laatste niet goed op je netvlies staat, begrijp je niet veel van de IT keten. Jammer.
Minstens zo opmerkelijk als de inhoud van het SDP, is dat het SDP niet verder is gekomen dan de conceptstatus. Deze versie 0.75 is daarom nooit ondertekend en heeft als datum 3 mei 2006, wat nog maar een maand was voor de eerste oplevering.