Vakmanschap

"Jos Keetels heeft wel kritiek, maar geeft niet aan hoe het wel moet", schrijft Paul Teeuwen.

Prince II: kikker of prins? De methodiek voor projectmanagement Prince II kent voor- en tegenstanders. Gebruikers Ron Seegers en Brigit Hendriks-van Winden zijn tevreden, maar wezen in hun artikel Succesvol veranderen vereist structuur wel op de haken en ogen van de methodiek. Michiel van der Molen kan voor een groot deel met hun bevindingen en adviezen meegaan, maar vindt dat het belang van het lijnmanagement te laag wordt ingeschat.
Jos Keetels heeft een heel andere mening over Prince II. In zijn reactie in Computable (24 oktober 2003) op Elimineer het verrassingselement van John Roos, veegt hij de vloer aan met de methodiek. Dit is bij velen in het verkeerde keelgat geschoten. Hieronder de reacties:

Maar waar het om gaat is zijn stelling dat Prince II niet zou helpen om projectmanagement te verbeteren. Uit eigen ervaring weet ik dat de invoering van Prince II dwingt een aantal beslisstructuren neer te zetten en een aantal beslismomenten bewust te beleven. Of dit belangrijk is? Kennen we niet allemaal projecten zonder opdrachtgever, zonder kosten-batenanalyse en zonder voortgangscontrole?
Een eerste stap is ervoor zorgen dat elk project een opdrachtgever uit de organisatie heeft (op directieniveau vanaf een bepaalde grootte), dat er een business case gemaakt wordt (en deze op elk beslismoment verfijnd wordt), en dat elke drie maanden de projectportefeuille bekeken wordt op voortgang en actualiteit van die casus. Dit lijkt misschien triviaal, maar als je dit serieus doet, ben je al 90 procent van de ‘zwart gat’-projecten kwijt.
De fasering van Prince II met ‘project brief’ en ‘project initiation document’ dwingt bewuste beslissingen af. Dit kan overigens ook met andere projectmethodieken, maar degenen die zich druk maken over de ene of de andere methode zijn meestal degenen die er geen toepassen. Ervaren projectleiders kunnen wellicht wat soepeler omgaan met de regels en daarmee wat extra efficiëntie bereiken, maar in het beginstadium is het verstandig je gewoon aan de regels te houden.
Een van de redenen waarom veel projecten mislukken is dat de opdrachtgever te veel afstand neemt van het project. Hij delegeert aan een it-projectleider, die het verder maar moet regelen. Automatiseerders maken de fout dit te vaak te accepteren. Ze moeten de gebruikers veel strikter op hun verantwoordelijkheden wijzen en desnoods weigeren een project te doen. Het project is er immers voor de gebruiker, niet voor de automatiseringsafdeling. Een risico-analyse kan helpen zo’n situatie expliciet boven water te krijgen en bespreekbaar te maken.
Nadat de basisprincipes van Prince II zijn ingevoerd, kun je naar enkele andere aspecten kijken, zoals beveiliging en architectuur. Je kunt dan de timing van de ‘deliverables’ op deze gebieden synchroniseren met de Prince II-besluitvorming, zodat je voorkomt dat er tijdens het project gezegd wordt: ‘dit voldoet niet aan de beveiligingsinfrastructuur’ of ‘dit past niet in de architectuur’. Je kunt bijvoorbeeld aan de ‘project brief’ koppelen dat getoetst is aan de ‘globale (bedrijfs-) architectuur’, of dat een actualisering is gemaakt voor het architectuurgebied waarin het project veranderingen bewerkstelligt. Bij de ‘project brief’ kan dan een ‘project start architectuur’ gemaakt worden. Die heb je overigens ook nodig om het project te begroten.
Prince II is een – volgens mij goed – tool, maar net als alle tools kan je het verkeerd gebruiken. Vakmanschap blijft altijd nodig. Bureaucratisering kan een gevaar zijn. Dit kan je voorkomen door gefaseerd in te voeren. Overigens is ooit hetzelfde van Itil gezegd, maar zo langzamerhand hebben we daar nu door hoe het moet. Volgens mij staat Prince II voor een vergelijkbare opmars als Itil. Misschien kan Nederland daarbij opnieuw wereldwijd voortrekker zijn.