Overheidsorganisaties, financiële instellingen en andere bedrijven hebben de afgelopen jaren veel tijd en geld gestoken in verbetering van hun projectmanagement. Vooral bij ICT afdelingen is veel geïnvesteerd. Heeft het geholpen?
ICT-projecten van de overheid hebben een slechte reputatie. Natuurlijk komen alleen de extreem falende projecten doorgaans in het nieuws. Een gewoon, ordelijk verlopend project heeft geen nieuwswaarde. En het is natuurlijk ook zo dat buiten de overheid ook veel projecten niet naar tevredenheid verlopen.
Het is echter wel een feit dat ik in mijn werkomgeving (ik geef cursussen PRINCE2, een Engelse gestructureerde methode voor projectmanagement) vaak geconfronteerd wordt met cynische en ongemotiveerde mensen die klagen over slecht gemanagede projecten, zowel bij de overheid als bij het bedrijfsleven. En op de cursus, is de verwachting, wordt ze een manier van werken bijgebracht die niet veel helpt, misschien eerder bijdraagt aan de ineffectiviteit.
Na jarenlang vooral in Engeland en Duitsland dergelijke trainingen te hebben gegeven, ben ik sinds twee jaar weer actief in Nederland. In trainingen kom ik vaak ict-medewerkers van banken, verzekeraars en vooral van overheden tegen. Wanneer ik vooraf vraag wat ze van PRINCE2 (PRojects IN Controlled Environments), weten, is de reactie vrijwel altijd: erg veel papierwerk, bureaucratisch. Wanneer ik vraag of de methode helpt, is de reactie erg zuinig en onzeker.
Onlangs was er in een cursus weer een consultant die in het dagelijks leven werkzaam was bij een overheidsinstantie als projectencontroller, natuurlijk in de it-hoek met PRINCE2. Het ijs was al gebroken en ik kon tijdens de introductie al wat boude uitspraken doen om mensen aan het denken te krijgen. Zoals tegen de projectcontroller: “Aha! Jij werkt dus in de projecten sabotage club!” De consultant reageerde in alle openheid: zo werd de bijdrage van het projectbureau, waar de projectcontroller werkte, wel vaak ervaren door de projecten.
Wat is hier aan de hand? Waarom kon ik zonder veel risico dit soort uitspraken doen? Waarom reageerde de consultant bevestigend? Het antwoord is: ervaring met de meest gemaakte fouten.
Privé projecten
Stel je voor, je gaat met een kind naar een speelgoedwinkel. Het kind gaat natuurlijk direct naar de hoek waar het favoriete speelgoed staat. Terwijl het kind zich staat te verlekkeren, is de ouder overwegingen aan het maken. Is dit speelgoed de moeite waard? Kwaliteit, leerzaam, duurzaam, passend, etc. Heb ik er het geld voor over? Kan ik het mij veroorloven?
Het kan natuurlijk zo zijn dat je als ouder beslist dat je niet tot aankoop overgaat. Misschien volgt er discussie met het kind en met de verkoper. Maar wie betaalt, bepaalt. Als ouder maak je de afweging en beslis je. Het komt ook wel eens voor dat een kind een cadeau krijgt van een familielid afkomstig uit een totaal andere belevingswereld. Het kind toont beleefd dankbaarheid en vervolgens verdwijnt het cadeau zonder dan er ooit iets mee wordt gedaan.
Als wij zo in het normale leven denken en doen, waarom zou het dan in ons professionele leven anders zijn? Waarom krijgen gebruikers van ict- producten vaak speelgoed opgedrongen waarover beslist wordt door een familielid uit een andere belevingswereld: de ict-afdeling? Of zelfs door de verkoper van de speelgoedwinkel; de externe ict-leverancier?
Waarom mag de ouder niet beslissen maar wordt een externe partij met veel macht maar weinig verantwoordelijkheid ingeschakeld om naar de regel, maar niet naar de inhoud te “sturen”? Want zo functioneert menig projectenbureau of projectcontroller: bureaucratisch en ineffectief. Het projectenbureau is een projectsaboteur.
Het antwoord is vaak: “Zo is onze standaard. Wij werken met PRINCE2”. Maar is dat wel zo? In de praktijk wordt zelden met deze methode gewerkt. PINO (PRINCE In Name Only) komt veel vaker voor en verklaart de ineffectieve realiteit en gaat daarmee hand in hand. Hoe is toepassing van beide methodes te herkennen? Daar heeft PRINCE2 zeven principes voor gedefinieerd.
1. Continue rechtvaardiging (Business Case)
Gek genoeg vinden zowel de ICT afdeling als de externe ICT leverancier dat zij volgens PRINCE2 werken. Het is alleen zo dat het belangrijkste principe van de methode zegt dat een project een investering is waar een zakelijke rechtvaardiging aan vooraf moet gaan: de Business Case. En die kan nu eenmaal niet gemaakt worden door een interne leverancier (IT afdeling) of een externe leverancier. Want die organisaties hebben per definitie andere, tegengestelde belangen. De externe leverancier wil meer omzet en winst, de interne leverancier wil meer macht. PRINCE2 is hier heel expliciet over: er zijn twee Business Cases binnen een project. De Business Case van de klant stuurt het project, de Business Case van de leverancier kan (en zal) conflicteren. Dit geldt ook voor interne leveranciers. PRINCE2 richt zich dus op de beheersing door de klant van een project, niet op het werk van de (interne) leverancier. Toch zijn het vooral de (interne) leveranciers waar de methode meestal wordt “toegepast”.
Vaak is ook de praktijk dat door een (financiële) toezichthouder een Business Case wordt geëist voordat er ook maar iets wordt gedaan aan het project. Dat is een goed idee en zo schrijft onze aanpak PRINCE2 het voor. Ook hier gaat het op verschillende niveaus fout. Een toezichthouder, zoals de afdeling Financiën, is niet de opdrachtgever en neemt geen verantwoordelijkheid. Van deze stafafdelingen kan hooguit advies worden ingewonnen over de financiële haalbaarheid (is er geld beschikbaar, is het plaatje goed doorgerekend?) maar de bevoegdheid over de investering is vele bruggen te ver. Zij hebben daar niet de kennis voor. De ouder zal toch ook niet de bank laten beslissing over de aankoop van speelgoed?
Daarnaast is het een misvatting dat een Business Case aan het begin van het werk kan worden opgesteld. Een Business Case is in essentie een analyse van de te verwachten baten en kosten. Niet alleen de kosten van het project maar ook van de operationele kosten die na het project nodig zullen zijn om het resultaat te onderhouden. Deze analyse, inclusief de resultaten en consequenties van de planning van het project, wordt gedurende de start van het project verzorgd. Een Business Case wordt daarmee in de voorbereiding en in de eerste fase van het project (Initiatie) opgesteld en niet voordat het project begint. Dat is logisch gezien niet mogelijk; eerst moet veel werk, waaronder de planning, gedaan zijn.
Verder wordt er gesproken over de continue rechtvaardiging. Dat houdt dus in dat een Business Case een levend document is dat gedurende het project bijgehouden dient te worden zodat ook gedurende het project onderbouwd beoordeeld kan worden of het project nog zinnig is.
Het opstellen van een Business Case gaat dus verder dan het invullen van verplichte kopjes in een sjabloon (template) voor een controlerende stafafdeling. Een Business Case is een onderbouwing van de zin van een project. Niet eenmalig, maar continue.
2. Rollen en verantwoordelijkheden
Een ander principe gaat over rollen en verantwoordelijkheden. Ook dit is gebaseerd op de klant/leverancier verhouding. In een Project Board (Stuurgroep) zijn de drie belangen vertegenwoordigd op de manier die hierboven is beschreven. De klant (ouder en kind) is vertegenwoordigd in de stuurgroep als Executive en Senior User. De leverancier kent vertegenwoordiging als Senior Supplier. En omdat de klant het management delegeert, is een logisch gevolg dat de projectmanager ook van de klant moet komen. Goed projectmanagement gaat immers veel meer om de focus op een klantenwens en de business case dan om de focus op de techniek. Hoe vaak mislukt een project omdat de techniek niet goed werkend gemaakt kan worden? In deze visie is een projectmanager van de (interne) leverancier een onverantwoord risico want welke Business Case wordt gediend door een projectmanager van de leverancier? Wat zal de focus zijn van een projectmanager vanuit de techniek? PRINCE2 is hier duidelijk over: de projectmanager dient van de klant te komen, niet van de (interne) leverancier.
In de realiteit van veel organisaties, en zeker bij de overheid, wordt alleen in vorm een Business Case gemaakt. De inhoud laat ernstig te wensen over. Logisch, want deze Business Case wordt gemaakt door mensen van de (interne) leverancier. Vaak speelt het Hoofd Automatisering of CIO hierbij een rol. Laten wij privé ook onze leverancier voor ons opschrijven wat de kosten, baten en risico’s zijn? Ik denk het niet want dan verwachten wij een te positief verhaal, waar wij ons ook door een verkeerde focus en jargon niet in zullen herkennen. Privé beseffen wij dat de leverancier andere belangen heeft. Maar zakelijk is vooral bij onze interne leveranciers dat besef er niet en als consequentie worden projecten veel te positief geschat of gestart omdat de interne leverancier wel zal weten wat goed is voor de gebruiker of organisatie. Zo mislukt dus het gemiddelde ERP project. Zo mislukte dus op zeer kostbare wijze een ICT integratie project bij de UWV. Het middel (ICT) wordt doel en de (interne) leverancier stuurt. Tot de wal het schip keert, met zeer kostbare gevolgen.
Een ander veel voorkomend verschijnsel is dat er meerdere stuurgroepen worden benoemd om vanuit verschillende kanten naar een project te kijken. Zo heb ik een project meegemaakt waarin vijf (!) verschillende stuurgroepen waren aangesteld. Al snel bleek dat dit volstrekt ineffectief was; het waren doelloze praatgroepen. Helemaal absurd was natuurlijk dat de kern van de verschillende stuurgroepen uit dezelfde personen bestond.
3. Focus op Business producten
Het succes van een project wordt in grote mate bepaald door de kwaliteit van het geleverde. Kwaliteit moet daarmee meetbaar zijn. In veel projecten wordt gestuurd op activiteiten. Een natuurlijke aanpak voor een leverancier maar niet meetbaar voor de klant. PRINCE2 heeft het daarom over producten. Business producten, geen technisch producten. Producten die herkend worden door een toekomstige gebruiker. Kwaliteit wordt immers door de klant en niet door de leverancier bepaald. ICT levert technische producten. ICT is geen doel maar een middel. En dan nooit zelfstandig maar als onderdeel van een werkwijze. Denk daarbij dus ook aan training, procedures en organisatie. Wanneer ICT wordt gezien als doel, is ICT niet meer te rechtvaardigen. Tenzij je een ICT leverancier bent natuurlijk: een tegenstrijdige Business Case.
In discussies met ICT-ers wordt erg vaak gesproken over kwaliteit in termen van het gebruikte proces. Termen als RUP, Agile, CMMi, etc. roepen vervolgens enorme discussies op waarbij het opvalt dat ICT-ers hierin de heilige graal zien. Wanneer hun favoriete aanpak wordt gebruikt, zal het met de kwaliteit allemaal wel goed komen. Helaas zien zij hierbij het belangrijkste over het hoofd. Met een goed proces kan nog steeds een betonnen zwemvest worden gemaakt. Vanuit het oogpunt van de leverancier goede kwaliteit, maar de gebruiker zal er niet blij van worden. Er is blijkbaar meer nodig. De klant moet het initiatief nemen en de leverancier kan vervolgens aan de slag gaan met de productie.
4. Management stages (Fases)
Een logisch gevolg van het vorige punt. Wanneer niet het toekomstige gebruik, maar het maken van het speelgoed wordt gezien als het doel van een project, kan de klant ook geen beslissingen nemen. De expertise is immers niet aanwezig. Fasering wordt voor de klant nutteloos en onbegrijpelijk, want gebaseerd op technisch specialisme. Tussentijdse evaluatie en bijsturing worden, anders dan op technische gronden, onmogelijk. Een belangrijke reden voor veel te laat ingrijpen omdat de werkelijke status en rechtvaardiging te laat begrepen worden.
Er is dus veel voor te zeggen om een project op te delen in voor de klant logische stukken. Het faseren wordt gebaseerd op risico’s en business producten en heeft daarmee een sterke relatie met de vorige principes. Wederom is de klant leidend met de zakelijke rechtvaardiging (Business Case) en zakelijke producten in de hand. Faseren is de belangrijkste vorm van risicobeheersing en gaat ervan uit dat een substantieel project niet volledig in detail te plannen is; er is sprake van een “planningshorizon”.
Het principe van beheersing door fasering wordt helaas ook vaak met voeten getreden, met negatieve gevolgen voor besturing en effectiviteit. Denk eens aan aanbestedingen. Vaak wordt een project volledig aanbesteed terwijl eisen en wensen onvoldoende bekend (kunnen) zijn. De uiterst kostbare gevolgen van deze praktijk kunnen aanzienlijk beperkt worden door fasering en aanbesteding per fase op zakelijk gronden, op basis van onzekerheid/risico. Het is cynisch dat de kostbare verspilling die ontstaat uit het onrealistische detailplannen van een volledig project, vaak voortkomt uit denken in budgetten, gericht op financiële beheersing. Zoals zo vaak zijn traditionele financiële structuren (budgetten) erg ineffectief en daardoor verspillend.
5. Management by Exception
Het is toch merkwaardig. Er wordt een goed opgeleide, goed betaalde projectmanager aangesteld. Die persoon moet de klus klaren want het lijnmanagement heeft het daar te druk voor. Maar toch wordt de projectmanager behandeld als incompetent en vol wantrouwen. Ondanks alle drukte wil het lijnmanagement precies weten wat er binnen het project speelt. Iedereen klaagt over de hoeveelheid vergaderingen maar toch wordt eens per week urenlang met de projectmanager gegaan om tafel om allerlei details te bespreken. Is dit zinnig of is dit gewoontegedrag? Ook volgens PRINCE2 zijn vergaderingen niet nuttig.
Wanneer er vanaf het begin duidelijkheid is gecreëerd over rechtvaardiging, organisatie (rollen) en producten (kwaliteit), zal er ook duidelijk zijn wat er niet duidelijk is te maken: de risico’s. De opdracht en de risico’s zijn geanalyseerd. In deze situatie zal echte delegatie mogelijk zijn. Zonder lange vergaderingen zal de projectmanager vorderingen ten opzichte van plan rapporteren op hoofdlijnen. Escalaties zullen tijdig in openheid plaatsvinden. De ellenlange en ineffectieve vergaderingen zullen niet langer meer hoeven plaats te vinden. Echte beheersing zal in een relatieve kalmte bestaan.
Natuurlijk stelt PRINCE2 niet dat de projectmanager na goedkeuring van plannen ongecontroleerd zijn of haar gang moet kunnen gaan. Maar de houding van de Project Board zou moeten zijn: vertrouw, maar verifieer. En voor de verificatie is voor de leden van de Project Board de functie van Project Assurance gedefinieerd. Zo zou de Executive bijvoorbeeld een financieel specialist naar rapportages kunnen laten kijken. Overigens is een veel gemaakte fout dat een persoon de “rol” van Project Assurance inneemt. Project Assurance kan, maar hoeft niet gedelegeerd te worden. Daarnaast is Project Assurance een containerbegrip dat onmogelijk door een persoon kan worden uitgevoerd. Als de verschillende leden van de Project Board verschillende belangen hebben, hoe kan dan een persoon die verschillende belangen verifiëren en beoordelen?
6. Leren van ervaringen
Projecten hebben een slechte reputatie. En als je er goed naar kijkt, worden eigenlijk elke keer weer dezelfde fouten gemaakt. Eigenlijk hebben vrijwel alle fouten direct te maken met de eerste drie hierboven beschreven principes: rechtvaardiging, organisatie en focus op producten en kwaliteit. Maar Johan Cruijff zei het al: “je ziet het pas als je het door hebt”. Met andere woorden: door goed naar de organisatie en individuele deelnemers van projecten te kijken, valt al veel te voorspellen over het succes wanneer veel begrip aanwezig is van de principes en lering is getrokken van de praktijk. Maar wanneer dat begrip er niet (voldoende) is, zullen fouten keer op keer gemaakt worden.
PRINCE2 is een Best Practice waarmee wordt bedoeld dat de theorie niet op zichzelf staat maar is ontstaan door evaluatie en door lering trekken uit wat er fout ging en goed ging in projecten. Maar dat wil nog niet zeggen dat de methode na een cursus volledig en eenvoudig toepasbaar is. De omstandigheden rond elk project zijn anders en daarmee zullen uit elk project weer lessen getrokken kunnen worden waarmee anderen hun voordeel kunnen doen. Een ezel stoot zich in het gemeen geen twee maal aan dezelfde steen. En wij mensen?
7. Tailoring – aanpassen aan de omstandigheden
Jaren geleden kwam ik bij een ministerie de volgende standaard tegen: wanneer een project meer dan een bepaald bedrag zou kosten en langer dan een bepaalde periode zou duren, moest het officiële handboek gebruikt worden. Wanneer tijd en geld onder de grenzen zouden blijven, moest het boekje De Kleine PRINCE gebruikt worden. Het boekje De Kleine PRINCE was niet meer of minder dan een uittreksel van het officiële handboek. Hoe handig sommigen dit uitreksel ook vonden, het voegde niets toe. De kwaliteitsbeheerder van het betrekken ministerie had dus geen flauw idee waar het om ging maar was helaas wel in staat om rigide en zinloze standaarden op te leggen.
Een project is altijd een middel om tot verandering te komen. En daarmee is een project altijd uniek en moet unieke en nog niet eerder voorgekomen omstandigheden het hoofd bieden. Dan zou het toch vreemd zijn om het project met rigide regels en procedures te controleren. Er werd altijd al expliciet in het officiële handboek gesteld dat bij toepassing van PRINCE2 per project nagedacht moest worden hoe uitgebreid de processen toegepast dienden te worden. De methode is dus nooit bedoeld als brede eenduidige detaillistische standaard maar als een flexibel kader, een aantal principes met daaromheen een aantal handige lessen en ideeën.
Helaas werd PRINCE2 al jaren geleden door de ICT sector gekaapt. ICT kan eigenlijk niets met de principes die hierboven zijn beschreven (maar tot de 2009 versie van PRINCE2 impliciet waren). De aanpak werd hierdoor uiteindelijk in de markt gezet als een procedurele aanpak voor ICT-ers door ICT-ers die eenvoudig kon worden geïmplementeerd door een aantal eenvoudige cursussen en de rigide invoering van een aantal sjablonen. Vorm dus boven inhoud, met als gevolg dat de mensen die echt wat aan de aanpak zouden kunnen hebben, lijnmanagement van de “business”, zich afwendden van een rigide ICT aanpak.
Een geoefend oog kan in een zeer vroeg stadium falen van een project voorspellen. Zo heb ik ooit voor de start van een project dat 18 maanden zou gaan duren, voorspeld wanneer en op welke punten het project in grote problemen zou komen. Al na drie maanden bleken mijn voorspellingen akelig accuraat; na afloop werd mijn rapportage gebruik als kapstok voor de projectevaluatie.
Het gaat er vanzelfsprekend niet om dat PRINCE2 goed wordt toegepast; het gaat erom dat projecten meer opleveren tegen minder kosten. Maar elke keer blijkt weer dat problemen in projecten samenhangen met de afwezigheid van de PRINCE2 principes.
Maar op papier is het allemaal zo gemakkelijk en toch lukt het niet om te komen tot verbetering van onze praktijk. Wat is er nog meer nodig?
PRINCE2 is in vele organisaties ingevoerd bij de verkeerde afdelingen (ICT) door de verkeerde mensen (ICT-ers) met de verkeerde achtergrond. Dezelfde ICT-ers die zich in het verleden hebben gespecialiseerd in een IT-beheer aanpak (ITIL), verzorgen helaas vaak de expertise (of wat daar voor door moet gaan). Niet alleen schuiven deze mensen een aantal principes terzijde als niet pragmatisch (lees: wij begrijpen het niet en het komt ons niet goed uit). Ook vereist beheer een volstrekt andere cultuur dan verandering. Beheer zoekt naar efficiëntie en stabiliteit. Projecten zoeken naar effectiviteit, verbetering en verandering. Vooral door de macht van ITIL consultants is PRINCE2 in veel organisaties verworden tot een ineffectief, bureaucratisch en procedureel trucje op een veel te laag niveau.
Echte invoering van PRINCE2 vereist moed. Het gaat dan om een culturele verandering waarbij niet moet worden geschuwd om heilige huisjes aan te pakken. Dit is alleen geloofwaardig door groot begrip en kennis. In een zeer vroeg stadium moeten de gevolgen (zoals gedrag) die als standaard worden gezien, maar ineffectief zijn, worden herkend. Aangezien projectmanagement binnen veel organisaties geen core competentie is, zal coaching door een externe specialist van groot belang zijn. Maar dan wel een externe specialist die onafhankelijk is van de leveranciers. Uit eigen ervaring weet ik echter dat vele organisaties snakken naar een andere aanpak waarin duidelijkheid, duidelijke rollen en doelgerichtheid worden aangemoedigd.
Met de principes van PRINCE2 kan een enorme verbetering van projecten en motivatie van mensen binnen die projecten worden bewerkstelligd. Nogmaals: het vereist moed; van de organisatie en maar ook van de begeleiding door coaches en opleiders. Maar dan wel de capabele coaches en opleiders graag.
Dit Podium-artikel is geschreven door Nico Viergever, trainer in PRINCE2
