In echte projecten doet men aan risk management.
“Echte projecten”, uweetwel, die dingen die in aanbestedingen en dus ook offertes omschreven staan. Die mythische zaken waarover men cursussen kan volgen en boeken kan lezen, maar die in het wild helaas zeer weinig geobserveerd worden eens een project meer dan een week of twee, drie bezig is.
Maar goed, soms komt er nog wel eens een echt project voorbij, iets dat niet-triviaal is en waar dus enige introspectie en enig overleg voor noodzakelijk is.
En waar risk management gebeurt, één van de aspecten van project management die ik het liefste doe, en al helemaal in het begin, als de risicofactoren neergeschreven worden.
Want dat is een creatief gebeuren (“waar hebben we nog niet aan gedacht?”), gecombineerd met een zekere mate van cynisme en leedvermaak-op-voorhand (“wat zou er nóg allemaal kunnen verkeerd lopen?”), gecombineerd met een dosis werkelijkheidszin, én er is een zekere ervaring voor nodig om de dingen te kunnen inschatten.
Eenvoudig gezegd komt het hierop neer: stel een lijst op van wat er kan mis lopen, hoeveel kans er is dat het zal mis lopen, en hoe erg eht zou zijn als het mis loopt. Beslis dan aan de hand van de combinatie van die laatste twee hoeveel aandacht er moet aan gespendeerd worden, en eventueel wat er allemaal moet gedaan worden om het risico te vermijden of te beperken.
De extremen zijn gemakkelijk te behandelen, maar de twijfelgevallen niet echt.
Voorbeeld, met een softwareproject.
- Er is heel veel kans dat een ontwikkelaar ooit per abuis een stuk code verwijdert dat hij niet had mogen verwijderen. Dat kan potentieel ene groot probleem zijn. Dus is het de moeite om version control te doen.
- Er is een kleine kans dat de serverruimte in brand zal schieten. Maar als dat gebeurt, dan is dat wel enorm erg: alles is weg. Dus is het de moeite om een decentrale backup te doen.
- Er is enorm weinig kans dat programmeurs in Noorwegen malaria gaan opdoen. En zelfs met malaria zullen ze nog wel productief zijn, toch zeker in het begin. Dus het is niet de moeite om te investeren in muskietennetten.
Gemakkelijk.
Voor alles wat niet zo voor de hand ligt (en we moeten daar eerlijk in zijn, er moet altijd goeie backup, ook off-site, zijn, er moet altijd version control zijn, en in onze contrieen zijn muskietennetten niet aan de orde), is het handig om dit regeltje te gebruiken voor elk potentieel risico:
- hoeveel kans, in procent, is er dat dit zal gebeuren?
10% = praktisch geen kans
100% = zal zeker gebeuren - hoe erg, van 1 tot 10, is het als dit gebeurt?
1 = mbof. een beetje vervelend
10 = kaka - vermenigvuldig kans met ergheid om de risicograad te bekomen.
Merk op dat 0% kans en 0 erg per definitie niet voorkomen, anders zou het geen risico zijn.
Merk ook op dat alle risico’s uiteraard door dezelfde persoon/hetzelfde team moeten geëvalueerd worden, anders heeft het niet echt veel zin.
Kans dat iets zal gebeuren, da’s meestal gut feeling: door ervaring geïnformeerd nattevingerwerk.
Ergtegraad, dat kan bijvoorbeeld gemeten worden in geld, of in tijd, of in kwaliteit–de heilige drievuldigheid van priject management–of in een combinatie ervan.
…en dan wordt het gemakkelijk om te zien wat er moet gedaan worden qua risicobeperking. Maak een top vijf (of top tien, of top drie) van de grootste risico’s en houd die in het oog, zorg ervoor dat het risico ervan naar beneden gaat. Hoe? Door moeite te doen.
Hoeveel moeite? Dat leert de risicograad zelf u: iets dat 30% kans heeft om duizend euro schade te berokkenen, daar ga je geen zevenhonderd euro voor gaan uitgeven om het te proberen vermijden. Iets dat kans heeft om het hele project van pakweg twee miljoen euro te doen platvallen, daar mag je al wat geld tegenaan smijten, zelfs al heeft het maar 10% kans ooit te gebeuren.
Ach. Als het echt grote projecten zijn, dan kan dat allemaal in een proper dashboard komen, en periodieke vergaderingen, en watnog.
Maar helaas (of: gelukkig?) zijn dergelijke projecten zo zeldzaam als iets.
Reacties
9 reacties op “Risico’s”
Heel leuk als men over de truck-factor van het project begint: hoeveel mensen kunnen er onder een vrachtwagen lopen vooraleer het project in het water valt 😀 En het grappige is dat de meeste projecten een truck-factor van 1 hebben.
Nice. Goed management is inderdaad ook voorzien, een combinatie van ervaring en helderziendheid gekruid met een snuifje cynisme. Risico-analyse kan echter ook tot een ellenlange aanlooptijd leiden. Soms moet je gewoon starten en corrigeren ‘along the way’. De beruchte 20-80 regel toepassen. Heb vorige week zelf nog een samenwerking opgestart met Blake. Het resultaat van een kleine kans en een grote ‘ergtegraad’.
@Nicodemus: Ja, tot er over loon of dergelijke wordt onderhandeld. Dan is het meestal “niemand is onvervangbaar, ook niet X”. Of tot er in offertes gesproken wordt. Dan is het meestal “elk lid van ons team wordt nauw gevolgd door één of meer back-ups”.
Heh. 😀
Héhé, project management 101. Mijn dagelijks brood.
Risico’s identificeren is goed, ze categoriseren nog beter, je bent al heel ver als je ze kan quantificeren .. maar je bent er niets mee als je aankomt met risico’s zonder een “backup”plan te hebben.
Het niveau waarover M. spreekt hierboven met “trade offs” naar riskcost-vs-mitigationcost is inderdaad zeldzaam. Meestal wordt er bekeken wat de grote orde kosten zijn. De gedetailleerde berekening van het “backupplan” wordt ook enkel concreter naarmate het risico zich meer manifesteerd, meestal eindigend in een vraag van één of andere Project Board om de exacte prijs van die projectverandering te berekenen.
Over de onmisbaarheid van personen: tja, meestal zijn de skills van die personen wel vervangbaar, maar de attitude, de inzet en het inzicht dat je core team members hebben opgebouwd … dat is onvervangbaar.
Zucht. Als ik de keren in mijn “carrière” zou moeten bij elkaar tellen dat de klant eiste dat er een duidelijke project! managament! methodology! was, en dat er in de praktijk niemand nog maar zin had om een idee te krijgen van wat pm eigenlijk *is*…
Maar wel eisen dat er mooie gantt charts voorgelegd konden worden, natuurlijk. Liefst heel erg gedetailleerd, liefst nog vóór er ook maar vergaderd was met de verschillende samenwerkende teams. Gn.
Mja, zo’n risicobeheer is één van die dingen waar in het begin altijd met veel enthousiasme aan begonnen wordt, maar dat niet met evenveel enthousiasme wordt verder gezet, of zelfs dikwijls maar half wordt afgemaakt (ik pleit zelf ook schuldig).
Maar nog voor aan dat risicobeheer wordt begonnen, moet nog worden beslist of dat wel gedaan zal worden. En zoja, wie gaat dat betalen? Want ik kan me voorstellen dat daar wel vlug 2 mandagen voor nodig zijn (iemand van klant en iemand van de leverancier).
Hetzelfde met die periodieke projectvergaderingen. Als je heel het projectteam (en dus ook de projectleider van de leverancier) bij elkaar wilt roepen, dan kan die daar ook wel veel tijd insteken in totaal (stel dat je met een 10-tal lopende projecten zit) en als die klant nog eens niet bij de deur woont, steek je daar ook weer wel veel tijd in. Want de baas van de leverancier vindt het niet zo tof dat die projectleider in dat ene project zoveel tijd steekt die niet betaald worden en in dat andere, even grote, project maar een derde daarvan.
Een mooie theorie omzetten naar de praktijk is niet zo makkelijk.
Maar een goeie methodologie wordt wel dikwijls geapprecieerd! En die moet eigenlijk maar 1 keer gemaakt worden, indien goed gemaakt.
M., dont get me wrong.
Ik geloof wel in methodologie, maar niet om projecten mee te runnen. Waar methodologie een goeie manier is om kennis in de organisatie te brengen en te verspreiden, blijft het voor mij daarbij. Het praktische nut is eerder beperkt. Dat is enkel een raamwerk om de context te creëeren. Niet om “op het veld” projecten mee te draaien. Misschien is dit een indicatie van de kwaliteit van de methodologie waar ik momenteel “onder draai”.
Ach je, de waarheid ligt in het midden. Met één betrokken en geengageerde project manager met een beetje gezond verstand kom je al veel verder dan met 6 binders methodologie. Dat is mijn credo – en mijn projecten varen er wel bij.
Maar terug naar risico management …
Neeneenee, hoegenaamd niet tegen u gericht, mijn verzuchting.
Ik wou zeggen dat er al die mensen zijn die een methodologie eisen, gewoon omdat ze gehoord hebben dat het nodig is om zo’n methodologie te hebben. Maar die in de praktijk geen besef hebben van basisconcepten als “afspraken moeten gehouden worden” en “we gaan niet méér kunnen doen in minder tijd met een betere kwaliteit maar zonder extra middelen”.
Of mensen die misschien zo’n boekje gelezen hebben van pm, en plots allerlei buzzwords gaan eisen.
Of van die mensen die *eisen* dat er een Microsoft Project file *voortdurend* en permanent *compleet* up to date moet zijn, met interproject links, en al dan niet uitgevonden percentages van voltooidheid… aargh.
True. Ik krijg de krul dat soort mensen. Ik kan het volledig onderschrijven – meer nog, ik kom ze elke dag tegen. Zeker omdat ik niet echt het type “methodologie-minnaar” ben, eerder een “just-do-it-but-controlled-adept”.
De volgende keer dat ze dat vragen, laat ze als “required reading materials” even de PMBOK lezen, dan zijn ze rap van hun methodologitis af, LOL.
Dikke kans dat je dat contract misloopt, dat wel …