Selecteren van een "foute" Product owner
De Product owner: een essentiële rol in de heilige graal van agile projectontwkkeling. Wat gaat er fout?
Wie is de Product owner?
In de afgelopen deskundigenonderzoeken werd het project volgens een agile projectwijze aangepakt: functionaliteiten zijn vooraf niet in beton gegoten, er wordt in korte cycli (sprints) gewerkt, prioriteiten worden steeds weer opnieuw bepaald, de functionaliteiten met de hoogste prioriteiten worden gerealiseerd. Op weg naar een succesvol eindresultaat?
Allemaal volgens het boekje. Lijkt het.
Is het dan zo makkelijk?
Maar toch, maar toch. Wie beslist er over de prioriteiten? De rechtgeaarde agile IT'er zal zeggen: de Product owner! Die heeft een duidelijk beeld van wat de business verwacht en heeft de controle over het budget. Klopt!
En waar komt die Product owner dan vandaan? De rechtgeaarde agile IT'er zal zeggen: de gebruikersorganisatie! Klopt ook!
En dan begint het probleem
In wat kleinere gebruikersorganisaties wordt één van de managers of de directeur als Product Owner aangewezen. En heeft die tijd daarvoor? Wat denkt u? Ja, in het begin van het project vaak wel, maar na enige sprints gaan de dagelijkse zaken (categorie belangrijk en urgent) de overhand nemen en komt de rol van Product Owner (belangrijk maar niet urgent) in het gedrang.
In grote organisaties wordt een manager die wat tjd over heeft, als Product owner aangesteld. Voor belangrijke keuzes moet een stuurgroep worden geraadpleegd die eens per maand bij elkaar komt. Intussen wordt er door het projectteam lekker doorgewerkt, want "agile is flexibel werken, niet alles hoeft bekend te zijn".
Ik kan nog meer voorbeelden van foute oplossingen noemen
Een oplossing die ik aantrof in een project was een extern ingehuurde persoon als Product owner, of iemand van de werkvloer in de rol als Product owner en in een enkel geval trof ik zelfs een medewerker van de IT leverancier aan die als Product Owner werd benoemd. Allemaal met goede bedoelingen, maar dat is niet voldoende voor succes. Sterker: dat is de garantie voor een probleem.
U raadt het al?
De basis voor een IT project dat volledig uit de hand loopt is gelegd: te veel tijd met onvoldoende of verkeerd resultaat dat ook nog eens te laat beschikbaar komt. En daarna een juridische procedure die nog meer geld kost en heel veel negatieve energie.
Hoe voorkom je een "foute" Product Owner?
Voor de IT leverancier: eenvoudig. Accepteer alleen een persoon in rol van Product owner die uit de gebruikersorganisatie komt en voldoende beslissingsbevoegd is. Leg de benodigde tijd vooraf vast. Communiceer de verantwoordelijkheden van de Product owner met de opdrachtgever. En last but not least: leg het project stil als er niet aan de voorwaarden wordt voldaan. Neem de verantwoordelijkheid daarvoor.
Herken uzelf in het spreekwoord: "Beter ten halve gekeerd dan ten hele gedwaald".
Voor de opdrachtgever: eenvoudig, besef dat u aan het stuur zit en beslist over budget, functionaliteit en prioriteit. Besef ook dat het project wat ingewikkelder is dan het beeld dat u in het offertetraject hebt gevormd. Maak keuzes om functionalteiten naar een volgende versie door te schuiven. De enige persoon die die keuzes kan maken is een persoon uit uw eigen organisatie met inzicht, daadkracht, voldoende beslissingsbevoegdheid en beschikbare tijd.
Herken uzelf in het spreekwoord: "Een goed begin is het halve werk".