Managed hosting door True

Fluitend aan het werk

"Sinds kort mag ik mijzelf Prince II Practitioner noemen. Na kennismaking met de methode heb ik me er met plezier in verdiept en heb ik met plezier geprobeerd hem op allerlei plaatsen toe te passen", schrijft K. van Zanten.

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:

 
Op het gebied van werkorders (work packages) leverde dit in een groot project zoveel duidelijkheid op dat mensen plotseling wisten wat er van ze verwacht werd en fluitend hun werk deden, beter en sneller dan voorheen. Het vergde wel de nodige uren (mijn uren) voor de eerste, tweede en derde werkorder op papier stonden. Het scheelde dus ook uren (hun uren) en de resultaten waren beter (hoe meet je dat?). Ik heb ook een project zien sneuvelen op een onvoldoende sterke 'business case'.
Had ik dit alleen bij gebruik van Prince II kunnen meemaken? Nee, ook met gezond verstand zouden deze resultaten te behalen geweest zijn. Prince II duwde de mensen wel in de richting van het goede doen: werkorders gebruiken, de 'business case' opstellen en beoordelen (afschieten).

Zwarte Piet

Een methode heeft drie onderdelen: een denkwijze, een werkwijze en een schrijfwijze. Later is daar als vierde nog bijgekomen: hulpmiddelen (tools). De denkwijze van een methode is het belangrijkst. Bij Prince II is die ruwweg: projecten zijn duur en moeten iets opleveren dat die kosten rechtvaardigt. De werkwijze is ongeveer: eerst denken (plannen), dan doen. Een en ander resulteert via de schrijfwijze in een 'business case' en een hiërarchie van plannen en werkorders. Dat zijn de tastbare resultaten.
Als er problemen zijn (en waar zijn die niet), haalt men die uit de kast om de eigen carrièreperspectieven te redden. Dat is het cya-gebruik van de methodiek (cover your ass). Cya is verstandig als je wordt meegesleurd in een heilloos avontuur. Degene die er het minst goed in is, blijft met de zwarte piet zitten. Dat is niet specifiek voor Prince II.
Keetels geeft voorbeelden van hoe partijen onderdelen van de methode aangrijpen om er zelf beter van te worden. Ik geloof het graag. Is dat inherent aan het toepassen van Prince II? Dat betwijfel ik. In een onderhandelingssituatie zal elke partij zijn positie willen versterken: eerst de koek vergroten, daarna een zo groot mogelijk deel ervan claimen.
Jaap van Rees heeft eind jaren zeventig in ons wereldje opschudding veroorzaakt met het artikel 'De methode doet het niet'. Dit was zijn bijdrage aan de reeks artikelen in het maandblad Informatie over methoden voor systeemontwikkeling. Hij stelde, uit mijn hoofd weergegeven, dat de bekwaamheid van de bouwers belangrijker was voor succes dan het gebruik van een of andere methode.

Mensenwerk

Ik heb een projectmanager bij een grote organisatie die Prince II heeft omarmd horen verzuchten dat hij van de 'business executive' (opdrachtgever) telefonisch de opdracht kreeg om een pid 'project initiation document' te schrijven. Zo'n document vergt nogal wat discussie. Daarvoor had de opdrachtgever geen tijd. De denkwijze werd hier genegeerd. Het grote Prince II-boek noemt dit Pino (Prince in name only).
Ik heb hetzelfde verschijnsel gezien bij het testen van een systeem: van de methode TMap werd alleen de schrijfwijze voor het 'mastertestplan' toegepast. Dat was dus los zand en bood geen enkel houvast voor het testen. Zelfs op het niveau van programmeren heb ik het gezien: Cobol-programma's die geheel volgens de schrijfwijze waren opgesteld (veldnamen, paragraaf- en sectionnamen, lay-out enzovoort), maar die een laag dieper zo onhandig waren geschreven dat onderhoud vrijwel onmogelijk was.
Het voordeel van een methode is dat je kunt aanwijzen waar het fout is gegaan. Daar kun je als betrokkene rekening mee houden en van leren. Een manier om toepassing van de methode op een hoger plan te krijgen is, de producten te inspecteren (Fagan-inspectie, weer een methode) - op die manier komen tegenstrijdigheden, omissies en onduidelijkheden boven tafel en kan daar wat aan gedaan worden. Of dat ook gebeurt is soms een projectpolitieke beslissing.
Daarmee komen we bij het kernpunt: het blijft allemaal mensenwerk. De leiding heeft grote invloed op hoe de methode wordt toegepast. Goed voorbeeld doet goed volgen. Ik ben het dan ook niet eens met de stelling dat Prince II totaal ongeschikt zou zijn om een project te besturen.
Prince II gaat ervan uit dat verantwoordelijken hun verantwoordelijkheid nemen. Dat past niet in het Nederlandse poldermodel. Succes heeft vele vaders, een mislukking - die heeft iedereen zien aankomen en daar heeft iedereen voor gewaarschuwd, maar 'ze' wilden het niet horen. De methode is alleen handig voor opdrachtgevers met lef (dus: die een lopend project de nek durven omdraaien). Ik vrees dat de methode in Nederland daarom niet zal blijven bestaan.< BR>
 
Ir. K.E. van Zanten

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/1289604). © Jaarbeurs IT Media.
?

 
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×