Waarom niks beloven meer oplevert!

Verwachtingen scheppen, beloven wanneer iets af is, beloven welke functionaliteit wanneer wordt opgeleverd, deadlines die nooit gehaald worden, Welke producten, diensten of functionaliteit krijg ik op een bepaalde datum?

Allemaal vragen die vanuit de opdrachtgever worden gesteld om grip en controle te hebben op de voortgang en of sturing van een project. Fascinerend is altijd om te zien dat dit gevoel van controle en grip willen hebben nog steeds wordt gezien als een behoefte van de opdrachtgever. Als men deze behoefte heeft dan kun je je ook gelijk afvragen of er vertrouwen is in je project delivery organisatie. Waar komt de behoefte aan controle en grip vandaan, en hoe goed en op waarheid gebaseerd worden deze vragen beantwoord?

Is het niet veel beter om niets te beloven. Als men echt eerlijk is dan kan men niets beloven. Men kan vaak wel uitspreken dat men een uitspraak doet in de vorm “potentieel”. Is deze informatie dan niet voldoende om de opdrachtgever te voorzien van voldoende informatie?

Er zijn kortom veel factoren die een rol spelen die onzekerheid veroorzaken.

We beloven heel veel in traditionele project en proces organisaties. In meer dan 80% van deze projecten worden deze beloftes vaak niet nagekomen en kom je wederom in situaties terecht waarbij het management weer gaat sturen op inhoud, verwachtingen, deadlines etc.  In een Agile organisatie wil je juist dat het management gaat bewegen in een faciliterende rol. Hoe kan het management helpen om de delivery teams beter te laten presteren, te groeien, etc.

Hoe ver kun je vooruit plannen zonder dat er een verandering van inzicht is of nieuwe suggesties worden gedaan omtrent functionaliteit? Wat ook verandert is de prioriteit gedurende een bepaalde planningshorizon. Iets wat bleek aan het begin van het project nog hoge prioriteit te hebben blijkt een paar weken later ineens veel minder hoge prioriteit te hebben. Soms komt het zelfs voor dat sommige vraagstukken helemaal niet meer belangrijk worden gevonden en zelfs kunnen worden geschrapt omdat blijkt dat deze uiteindelijk geen waarde toevoegen.

Wat is dan de ideale tijd om iets te kunnen beloven? In veel projectorganisaties is uit rapportages gebleken dat men steeds meer onzekerheid ervaart naarmate de planningshorizon groter wordt. Ook is er onderzocht dat 2 weken (sprint duur in de Agile Scrum methodiek) de ideale planningshorizon is waarbij nog enige mate van zekerheid kan worden gegeven. Na 2 weken zie je deze onzekerheid exponentieel toenemen. Een goed voorbeeld is de weersverwachting. 1 week is vaak wel goed te voorspellen en men kan een redelijk beeld geven van de verwachtingen over een periode van 2 weken. Maar wordt deze periode nog langer dan neemt de onzekerheid toe en zul je zien dat deze voorspellingen in de regelmaat nooit kloppen. Sommige organisaties durven het wel aan om een sprintduur van 3 weken of langer te kiezen. Wanneer men daarvoor kiest zie je dat de planning sessies langer duren en dat uiteindelijk het percentage van deliverables afneemt ten aanzien van kortere iteraties. Wat kan men nu echt beloven wat men gaat opleveren. Het is beter om potentieel iets te beloven want nieuwe inzichten gedurende en veranderingen zullen plaats vinden ook in deze korte periode.