Je zou zeggen dat de hoeveelheid mislukte projecten aanleiding is voor drastische ingrepen in de projectmethodiek, oppert Jan Takke. “Net zoals de gemiddelde vergadering zich niets aantrekt van de door iedereen ondergane cursus ‘discussie- en vergadertechniek’ gaan projecten ondanks methodieken nog steeds de mist in.”
Het opinieartikel ‘Zekerheid en Pavlov in de ict’ (Computable, 8 juli 2005) van Michèl Stijlen, directeur van de Ceasar Groep, heeft mijn volledige sympathie, al was het maar omdat hij de moeite nam zijn artikel uit het Het Financieele Dagblad van een dag of tien eerder opnieuw te schrijven. Na lezing van titel, ondertitel en inleidende alinea was het me echter nog niet erg duidelijk waar het naartoe zou gaan. Als de veronderstelde Pavlov-reactie (welke, wat is de trigger) gericht is op maximale zekerheid, hoe kan die dan (blijven) bestaan als die wens kennelijk niet of nauwelijks (71 procent van de gevallen) gerealiseerd wordt?
Verder beantwoordt het artikel de ondertitel “Waarom projecten mislukken” niet echt. Misschien is de exotische voornaam die Stijlen in de kop krijgt toegemeten al een vingerwijzing. Hier is hij kennelijk niet zelf aan het werk geweest.
Zwarte Piet
Projecten mislukken omdat het werk over veel schijven loopt, altijd wel iemand zijn eigen ding doet, de controle op het afgeleverde niet gebeurt door degene die er het beste zicht op heeft, kortom, er niemand is die alles kan overzien, en die de integrale verantwoordelijkheid heeft en ook kan waarmaken. Elke betrokkene heeft wel weer iemand om de Zwarte Piet toe te spelen.
Ik sta achter de essentie van Stijlens artikel. Richt je niet op technische kunstjes en hoogstandjes, maar laat je voortdurend sturen door wat de opbrengst van het project moet zijn. Wie wordt daar dan op afgerekend? De projectleider? Meestal wordt de echte waarde van het project pas gerealiseerd als de projectleider allang weer met een andere klus bezig is. Dan pas groeit de datakwaliteit naar een acceptabel niveau, komen er voldoende gebruikers om de nieuwe functionaliteit uit te buiten en wordt het oude systeem echt uitgezet en afgevoerd. Ook wordt vaak pas later duidelijk wat de samenhang van het nieuwe systeem met omringende systemen in de praktijk nou eigenlijk betekent.
“Stel dat de waardebepaling van een ict-project verplicht zou zijn”, schildert Stijlen een kennelijk aantrekkelijk scenario. Wat dan? Steeds meer is het wel degelijk gebruikelijk dat het project start op basis van een zakelijke rechtvaardiging ofwel ‘business case’. Helaas is het gebruikelijk dat de beoogde projectleider de zakelijke rechtvaardiging opstelt. Ooit een projectleider gezien die graag wil dat zijn project niet doorgaat?
Dan maar de stuurgroep, of de sponsor? Die hebben wel wat anders aan hun hoofd, en bovendien allang weer een nieuw, grootser idee om achteraan te hollen. Mijn ervaring is dat na de start van het project niemand zo erg meer bezig is met de zakelijke rechtvaardiging en na de afsluiting van het project (oplevering van de af te leveren producten) al helemaal niet. Dat terwijl het echte oogstwerk dan pas begint.
Profijtbeheer
Je zou toch zeggen dat de – inmiddels normaal gevonden – situatie van mislukte projecten aanleiding is voor drastische ingrepen in de projectmethodiek. Echter, net zoals de gemiddelde vergadering zich niets aantrekt van de door iedereen ondergane cursus ‘discussie- en vergadertechniek’ gaan projecten ondanks PMI en Prince 2 nog steeds de mist in.
Is het geen goed idee om, naast alle andere managementinvalshoeken als project-, kwaliteits- en risicomanagement ook eindelijk eens het label ‘project profijt management’ serieus te beproeven? En daarvoor dan iemand buiten het eigenlijke project, dat wil zeggen rapporterend aan stuurgroep, sponsor of managementteam, in te huren? Iemand die geen andere agenda heeft dan het helpen waarmaken van de beoogde opbrengst van het project en die vrij is om zonodig die keurige ‘dressing’ van de diverse ‘windows’ te rukken? Het lijkt me zeker het proberen waard – wat denkt u?
Jan Takke, Cadvice Management Consulting
