Bij dubbele onzekerheid: wachten tot het tij gekeerd is

In mijn eerdere blogs schreef ik dat het hebben van een helder vertrekpunt van belang is voor het succesvol behalen van een vooraf gesteld resultaat en dat het grip houden op een project alle aandacht vraagt. In dit blog wil ik dit graag concreter maken aan de hand van de onzekerheden die in de projectomgeving van kracht kunnen zijn. Hierbij maak ik een onderscheid tussen twee soorten onzekerheden. De eerste onzekerheid heeft te maken met het vertrekpunt, de tweede onzekerheid heeft vooral te maken met het te bereiken resultaat. Ondanks populaire methoden als Scrum of Agile, blijven deze onzekerheden menig projectmanager een (kop)zorg.

In mijn eerdere blogs schreef ik dat het hebben van een helder vertrekpunt van belang is voor het succesvol behalen van een vooraf gesteld resultaat en dat het grip houden op een project alle aandacht vraagt. In dit blog wil ik dit graag concreter maken aan de hand van de onzekerheden die in de projectomgeving van kracht kunnen zijn. Hierbij maak ik een onderscheid tussen twee soorten onzekerheden. De eerste onzekerheid heeft te maken met het vertrekpunt, de tweede onzekerheid heeft vooral te maken met het te bereiken resultaat. Ondanks populaire methoden als Scrum of Agile, blijven deze onzekerheden menig projectmanager een (kop)zorg.

Het hebben van een helder vertrekpunt is nodig om vooraf vast te stellen wat de huidige condities en mogelijkheden zijn en wat het kennisniveau is. Dat als het ware alles in gereedheid is om zonder verrassingen de trossen los te kunnen gooien of een project te kunnen accepteren. Er is dan een helder beeld van de zogenaamde ‘IST’ situatie. Het kan gebeuren dat gedurende de opstart van een project veel meer bewustzijn van de omgeving ontstaat. Dit wordt vaak in een politiek of technisch complexe omgeving pas duidelijk als binnen het projectteam collectief bewustzijn ontstaat, al dan niet ingefluisterd door de (verschillende) stakeholders. Niet zelden blijkt dat de inschattingen die vooraf zijn gemaakt in eerste instantie wel duidelijk zijn, maar naarmate meer kennis wordt opgedaan, blijkt gedurende de eerste fase van een project de onzekerheid alleen maar toe te nemen. Daarmee wordt het project een soort ‘dropping’ waarbij pas na het daadwerkelijke starten een beeld van de omgeving wordt opgebouwd. Op zich is er niets mis met een dropping, als je er maar van bewust bent dat je zoekende bent en nog een ‘Ist’ plaatje op te bouwen. Dit kost vaak echt even tijd.

Het hebben van een helder resultaat is nodig om het project überhaupt van start te laten gaan. Dit heeft veelal te maken met goedkeuringsprocessen en vrijgave van middelen. Maar wat geldt voor het vertrekpunt, dat pas gaande weg een begrip hiervan wordt opgebouwd, geldt in dezelfde mate ook voor het te bereiken resultaat. Dit houdt in dat ook gedurende het concreet maken en helder specificeren (operationeel, technisch, procesmatig) van het te bereiken resultaat met de verschillende betrokken partijen vaak verwachtingen of onzekerheden worden onderkend die vooraf nog niet waren voorzien. Dit getuige ook de vele issues, changes, exceptions, etc. die gedurende een project aan de orde komen. Kortom, de beschrijving van het te bereiken resultaat bij aanvang van het project is vaak ogenschijnlijk helder en wordt gaande weg vaak pas helemaal helder. Daarmee wordt het project als het waren een Avontuur om te ontdekken waar het uiteindelijk concreet zal uitkomen. Wat menig zeiler zal herkennen is dat een deel van de voorbereidingen later overbodig bleken te zijn, of anders om dat er ondanks de voorbereidingen altijd nog iets kan gebeuren waarop je niet was voorbereid. Met aanpassingen van de scope tot gevolg.  

Doordat bovenstaande situaties met regelmaat voor komen, en elkaar vooral niet uitsluiten, zien we ze vaak beide in hetzelfde project. Dit is vaak niet helemaal te voorkomen. Wat wel zaak is, is de mate van onzekerheid en de tijdsduur van beide situaties te beheersen en liefst te minimaliseren. Wat we zien is dat projecten waarbij de beide type onzekerheden tegelijkertijd optreden, worden ervaren als ware het een ’survival’, waarbij de stakeholders (of projectsaboteurs?) buiten het project hun kansen schoon zien en projecten hier niet altijd ongeschonden uitkomen.

In mijn zeil ervaring vergelijk ik dit wel eens met de wind en het getij. Waarbij het kiezen is tussen twee kwaden en wanneer de stroming tegen de windrichting in staat heftige situaties kunnen ontstaan. Een oplossing hiervoor is, los van het minimaliseren van de beide onzekerheden, deze stappen waar mogelijk in de tijd uit elkaar te trekken zodat ze niet met elkaar interfereren. In het geval van het getijde kan dit betekenen dat je af en toe even moet wachten tot het tij gekeerd is. Voor projecten is dit in mijn ogen vaak niet anders, of toch wel?.

Wanneer met methoden als Scrum of Agile wordt gewerkt moet men zich er van bewust zijn dat dit verschijnsel zich min of meer in iedere “sprint” kan voltrekken. Hiermee wil ik niet suggereren dat deze methode daardoor minder bruikbaar wordt, maar wel dat het onderkennen van dit fenomeen belangrijker wordt om te onderkennen. Dit vraagt in mijn ogen om daadwerkelijk alle stakeholders bij de resultaten van de sprints te betrekken om de juiste koers te kunnen behouden.

endum.

Wilt u meer informatie?

Neem direct contact met ons op Contact Opnemen