Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Prince2 alleen is niet voldoende

Leren en onthouden met Management Oversights and Risk Tree

 

Prince2 maakt de voortgang van projecten concreet. 'Ervaringen' worden opgetekend in een 'Lessons Learned' log- en report. Daar zijn belangrijke lessen uit te leren, maar de methodiek schiet tekort bij de analyse van oorzaken van deze 'leerpunten'. Daar kunnen wel methodieken als Management Oversights and Risk Tree (Mort) uitkomst bieden.

Met Prince2 wordt de voortgang van projecten concreet gemaakt; risico's verminderen door een opdeling in logische processen, hun besturing, componenten en op te leveren producten. Gaandeweg ontstaan ook ervaringen die, als ze interessant genoeg zijn, worden opgetekend in een 'Lessons Learned' log- en report. Dat er belangrijke lessen te trekken zijn uit afzonderlijke projecten, weet iedereen die weleens probeert een project tot een goed einde te brengen. Echter een gestructureerde analyse van de oorzaken van deze 'leerpunten' (vaak een eufemisme voor 'voortaan te vermijden situaties') is binnen Prince2 niet gedefinieerd en wordt dan ook vaak achterwege gelaten. En alleen opschrijven dat iets fout gegaan is, zegt nog niets over de oorzaken.

Deze beperkingen binnen Prince2 maken de methode ongeschikt om structureel te leren van fouten uit het verleden. De nadruk ligt op het operationele aspect van het project proces en de door William Edwards Deming ontwikkelde Plan-Do-Check-Act-cirkel wordt niet rondgemaakt; het stopt ergens halverwege tussen Do en Check. Daarom moet Prince2 aangevuld worden met een goede methode, die de Deming cirkel wél rond maakt. Management Oversights and Risk Tree (Mort) is zo'n methode. Het is public domain en stelt een team of organisatie in staat stapsgewijs en heel bewust te leren van ervaringen, door oorzaken van problemen gestructureerd op te sporen. Het gestructureerde karakter sluit goed aan bij Prince2.

Invloed van buitenaf

Mort stelt stakeholders in staat de kwaliteit van uitvoering en management te evalueren en niet alleen vast te stellen dát er sprake was van diverse typen risico's, maar ook hoe daar vervolgens mee omgegaan is. Een hele belangrijke extra dimensie die in Prince2 eveneens ontbreekt, is de invloed van van buitenaf komende factoren, zoals druk die door opdrachtgevers of andere belanghebbenden op een project wordt uitgeoefend. ‘Externe' druk kan niet altijd worden geneutraliseerd, evenmin als ieder risico dat een project kan bedreigen. Als verantwoording moet worden afgelegd over de resultaten van een project, is het wel goed om ook die factoren - waar niets aan kon worden gedaan, maar die wel van invloed zijn geweest op de uitvoering van een project - goed op een rijtje te hebben. En denk niet, dat daar tóch niet van kan worden geleerd.

Daarnaast is de manier waarop door alle betrokkenen ingespeeld is op de voortekenen van een probleem, voor het zich als zodanig kon ontwikkelen, een belangrijk aspect binnen Mort. Mort kijkt dus niet alleen naar de realisatie van de deliverables zoals Prince2, maar ook naar de kwaliteit van het proces. Een beter proces op zijn beurt leidt tot minder herstelacties, dus lagere kosten en kortere time to market.

Mort is behalve methode ook een schematechniek, die weer prima aansluit op technieken als Mind Mapping. Prince2 met Mort leidt tot een gesloten 'feedback loop', zodat opeenvolgende projecten in staat zijn fouten uit het verleden te vermijden en dus betere garanties voor toekomstig succes zijn af te geven.

Historisch

Mort bestaat nu bijna veertig jaar en heeft een stevig theoretisch fundament. Het is afkomstig uit de Amerikaanse raket industrie; kernwapens, raketten en installaties worden uiteraard met de grootste zorg vervaardigd en beheerd. Bij de heel grote aantallen waarover we het dan hebben is het echter prettig een gestructureerde incidenten analyse en administratie te hebben, zodat fouten snel, in samenhang en de volle breedte kunnen worden gecorrigeerd. Mort is overigens geen bij uitstek (informatie)technologische methode. Het is net als Prince2, toepasbaar binnen allerlei vormen van (projectmatig)samenwerken. Zo is de methode in het verleden gebruikt bij de analyse van rampen in het Heizel stadion en op het spoor, maakt de Nederlandse Politie in toenemende mate gebruik van Mort om de eigen inzet op diverse gebieden te analyseren en is de Nederlandse Marine kennelijk ook actief aan de slag met Mort.

Een 'nadeel' van Mort is, dat een genuanceerd beeld over oorzaak, gevolg en samenhang ontstaat; men komt echt te weten hoe het zit en zwartepieten, bedrijfspolitiek soms wel handig, wordt door de inzichtelijkheid van de methodiek bemoeilijkt. Deze tamelijke ongenaakbaarheid van Mort heeft er dan ook toe geleid dat men er hier en daar weer mee gestopt is, met name waar grote management fouten aan het licht kwamen.

Mort praktisch

Het aangrijpingspunt van een Mort-analyse is de vaststelling dat een relevante activiteit op een gegeven moment niet tot het juiste resultaat heeft geleid (Less Than Adequate (LTA)). Het euvel is al geschied en dit is dus aanvullend op de positivistische Prince2 aanpak, die er vanuit gaat dat alles op zijn pootjes terecht komt als de voorwaarden vervuld zijn.

Tijdens de Mort-analyse wordt dan gestructureerd onderzocht wat de oorzaken waren. Daarbij komt dus niet alleen de directe verantwoordelijkheid voor die specifieke activiteit langs. Ook of er teveel (al dan niet bekende) risico's zijn genomen die vervolgens niet goed zijn ingeschat en/of beheerst, de aansturing van de activiteit aan de norm heeft voldaan, dan wel de juiste middelen beschikbaar waren. Dit kan zich uitstrekken van beleidsvraagstukken tot bekendheid met uitvoeringsvoorschriften. Een analyse kan zich uiteraard ook op een beperkt gebied richten, waarin dan wel de afzonderlijke facetten (uitvoering, management, risico's en externe druk) aan de orde komen.

Voorbeeld: Als de norm is dat voorafgaand aan het in productie nemen van een systeem, de documentatie is opgeleverd of geactualiseerd en goedgekeurd, maar binnen het ontwikkelteam is die norm niet gecommuniceerd c.q. gecontroleerd op naleving (management), dan moet niemand verbaasd zijn dat het niet gebeurt (uitvoering). Een paar jaar later blijkt dat de software niet te onderhouden is, omdat niemand meer weet hoe het werkt (risico).

De omgeving van projecten, bijna niet in Prince2 te vangen, wordt steeds nadrukkelijk in de beschouwing betrokken, vanuit de gedachte dat nooit in een vacuüm wordt geopereerd en externe partijen dus van invloed zijn op de gang van het project. Men heeft te maken met opdrachtgevers, financiers, toeleveranciers, onderaannemers, gebruikers en anderen die soms ongewild of onvermijdbaar een enorm stempel op uitvoering en management kunnen drukken. Het is dan ook niet meer dan vanzelfsprekend om die invloeden te onderkennen en systematisch te betrekken in de analyse.

Hoewel dus uitgegaan wordt van incidenten, zaken die minder goed zijn verlopen, is het uiteraard niet verboden ook het leereffect van successen te benutten. In de praktijk blijkt dit het enthousiasme bij groepen aanzienlijk te vergroten om het eigen functioneren eens grondig te onderzoeken. Iedereen is mens en wil ook graag horen dat bepaalde zaken uitstekend zijn verlopen.
Evaluatie moet dus onderdeel van projectvoering zijn. Het doel van een tussenevaluatie, bijvoorbeeld bij het passeren van de tollgates naar een volgende projectfase, kan belangrijke stuurinformatie opleveren. Leren is ook bijsturen en anticiperen. Doordat Prince2 onvoldoende aanknopingspunten biedt, wordt te vaak, te oppervlakkig, te ongestructureerd en te laat geëvalueerd. Daar hebben we last van.

Mort in de it

Voor het einde van een project wordt in de it al warm gedraaid voor het volgende en niemand wil graag bij het sluiten van de markt 'exposed' worden als veroorzaker van problemen. Daarmee berooft men zich wel van een waardevolle kennisbron om te verbeteren. En dat verbeteren is hard nodig ook, want ondanks de wereldwijde inzet van projectmanagementmethoden zoals Prince2 hebben projecten met een budget van meer dan tien miljoen euro nog steeds een extreme faalkans. In de Verenigde Staten is het ontwikkelen volgens een 'grand design' nu zelfs formeel verboden binnen de overheid. Na eindeloze reeksen catastrofes kiest men voor pragmatisme, waarbij er in ieder geval nog íets gebeurt. Dus kennelijk is de controlled environement minder goed definieerbaar en beheersbaar dan Prince2 veronderstelt.

Deze problemen worden natuurlijk niet weggenomen met de introductie van een evaluatie methodiek. In een van de oudste Mort-documenten gaat het over problemen bij het gebruik van voetpedalen in auto's. Dat was 1973 en je mag aannemen dat autoproducenten ook evalueren op proceskwaliteit; toch worden ook nu miljoenen auto's teruggeroepen in verband met 'verborgen gebreken'. Dit onderstreept dat in alle projecten, ook die wél tot een goed einde komen, ruimte is voor kwaliteitsverbetering en het leren van fouten.

Jelte Verhoeff, senior project manager informatie management, Arbo Unie
Paul Minnebo, docent evaluatietechniek, Nederlandse Politieacademie

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

?


Lees meer over


 

Reacties

Ik ben het volledig eens met de analyse dat de PLAN-DO-CHECK-ACT cirkel van Deming vaak niet volledig wordt doorlopen. En dat de (dieper liggende) oorzaken van geleerde lessen vaak niet worden onderzocht en/of aangepakt.

Als alternatief voor MORT zou de techniek Current Reality Tree (CRT) uit de methodieken van Theory of Constraints (TOC) gebruikt kunnen worden. Wanneer in een projectevaluatie met deze techniek de dieper liggende oorzaken worden geidentificeerd en de cirkel van Deming volledig wordt doorlopen, kan het opnieuw optreden van problemen door het wegnemen van de daadwerkelijke oorzaken worden voorkomen.

In de praktijk is dit vaak lastig toe te passen omdat de nazorg teveel tijd en aandacht vergt en/of het volgende project zich alweer aandient. Bovendien zijn de dieper liggende oorzaken vaak gerelateerd aan beleid en cultuur in een organisatie en lastig aan te pakken.

Zeer interessant! Is het mogelijk een literatuurlijst te plaatsen?

Twee opmerkingen:
1. Weer een techniek erbij? Het is vrij gebruikelijk om in een situatie die niet bevredigend is, een nieuwe techniek te pakken. Maar: "A fool with a tool is stll a fool".
2. Ik heb het gevoel dat de schrijver praat over omgevingen die meer complex zijn dat PRINCE2 als aanname hanteert. Ik roep dan wel eens: PRINCE2 is een hamer en spijker maar je wilt een schilderij ophangen aan een hard betonnen muur. Je hebt dus een boor/plug/schroef nodig. Dit zou heel goed het "broertje" van PRINCE2 kunnen zijn: MSP. Programma management dus.


Overigens wordt PRINCE2, zeker in Nederland, vaak verkeerd begrepen en gebruikt dankzij de positionering van dominante IT parijen. Maar dat is een andere verhaal.

Dit artikel legt de vinger op de zere plek van Prince 2. Kijk ook eens hoe het steeds populairder wordende Scrum framework hier mee omgaat. Het leidende principe is daar 'inspect and adapt'. Dit zorgt nog tijdens de realisatie van het project voor aanpassingen op de processen en de projectomgeving. Maar ook hier kan niet worden voorkomen dat de initiële business case is gebaseerd op drijfzand.

Erg interessant stuk wat betreft de lacunes van Prince2. Mort zou hier inderdaad een effectief verlengstuk van kunnen worden. Zodoende Prince 2 blijft bestaan en louter wordt aangevuld. Ik denk dat dit dan ook de schrik weghaalt bij alle mensen die met Prince 2 werken omdat er wordt aangevuld en er niet een gehele verandering plaatsvindt.

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

×
×