Product owners maken projectmanagers overbodig

Tegelijkertijd wordt zowel in- als extern juist meer en meer gevraagd om resultaten. En stukje bij beetje ontstaat een nieuwe norm voor IT die hierop inspeelt en volgens welke zowel een voorspelbaar resultaat als een voorstelbare doorlooptijd gehaald moet worden. Bewust spreek ik hier over resultaat en niet over kwaliteit. Voor een resultaat geldt, dat het moet werken zoals het bedoeld is en dat het klaar moet zijn voor gebruik. In termen van kwaliteit: de klant verwacht ‘fitness for use’. Projectmanagers echter bewijzen al decennia lang, dat zij niet verder komen dan ‘conform to specifications’. Het moet dus anders. (Zie ook ‘Product owner zijn is een vak’.) Om dit te realiseren, moeten wel enkele gangbare aannames over boord.

Aanname 1: De klant weet precies wat hij wil

Traditionele klant-leveranciersrelaties gaan ervan uit dat de opdrachtgever de expert is, die precies weet wat hij wil hebben. De leverancier levert exact datgene op wat de klant vraagt: u vraagt, wij draaien. Dit was zo in IT, maar ook in andere sectoren.
Zo’n traditionele relatie gaat echter voorbij aan het feit dat een leverancier in de regel heel veel kennis heeft van zijn vak, ongeacht of dat vak nu wegenbouwen is of software ontwikkelen. Ze gaat ook voorbij aan het feit dat het product dat wordt opgeleverd na de oplevering voor langere tijd onderhouden moet worden. Soms door een andere partij, maar vaak door dezelfde leverancier. En daarbij is het vaak zo, dat hoe slechter het product is dat een leverancier oplevert, hoe meer hij verdient aan het onderhoud dat daarna moet plaatsvinden.
In de nieuw ontstane norm past dit niet meer. Niemand weet alles, ook de klant niet. In de nieuwe wereld heeft de klant ofwel de product owner een goed beeld van de doelen die worden nagestreefd en de leverancier van de mogelijkheden die er beschikbaar zijn, zodat ze samen de beste oplossing kunnen bedenken en ontwikkelen.

Aanname 2: De goedkoopste oplossing is altijd de beste

Rijkswaterstaat (RWS) was één van de eerste organisaties die inzag dat ze de alom aanwezige marktkennis veel beter kon gebruiken in projecten. RWS is één van de eerste Nederlandse organisaties die is gaan inkopen volgens een nieuwe methode, genaamd Best Value Procurement (BVP), een methode  die veel verder kijkt dan de prijs alleen. BVP is een aanpak die aanbieders de kans geeft om hun expertise maximaal te laten zien en gebaseerd op de volgende principes:

• Creëer de meeste waarde voor de laagste prijs.
• Verminder risico’s door transparantie en gebruik van expertise.
• Vervang management, controle en inspectie door luisteren, begrijpen en stroomlijnen.
• Laat de leveranciers financieel (mee)profiteren van de voordelen die zij realiseren.

Waar wegenbouwers, bruggenbouwers en andere partijen voorheen konden inschrijven op een gedetailleerd bestek, geeft RWS nu de specificaties van een project aan. Leverancier en klant dragen samen het risico en nemen samen de verantwoordelijkheid voor de bouw, maar ook voor de gehele levenscyclus van een project. De leveranciers geven een prijs en een kwaliteitsgarantie af, en kunnen binnen de genoemde specificaties zelf bepalen hoe ze daar invulling aan geven. Dit heeft in korte tijd geleid tot een beduidend hogere mate van innovatie bij de leveranciers, hetgeen voor RWS resulteert in meerwaarde voor een lagere prijs. Terwijl tegelijkertijd de leveranciers meer ruimte hebben om een goede boterham te verdienen. Maar daarvoor moeten zij wél wat doen, namelijk meedenken over kostenverlaging en procesverbetering, innovatief zijn en uiteraard afspraken nakomen en deadlines halen.
Best Value Procurement mag dan een nieuw model zijn dat de inkoopwereld op zijn kop zet, het is tegelijkertijd geen rocket science. Het is een manier van werken die eigenlijk heel vanzelfsprekend zou moeten zijn, omdat deze is gebaseerd op eerlijkheid, openheid en het beste met elkaar voor hebben. Leveranciers die hun klanten oprecht willen helpen en die open en transparant zijn over hun inspanningen en resultaten werken vaak al op deze manier, zonder dat ze het zelf zo noemen. Ook in de ICT zien we steeds vaker inkoopafdelingen die geloven in Best Value Procurement, al is dat niet altijd even gemakkelijk. Maar daar waar het lukt, zien we succesvollere projecten (op tijd en binnen budget) die leveren wat de business verwacht. 

Aanname 3: Functionaliteit is bepalend voor de oplossing

Gezamenlijk een begrip ontwikkelen van de doelen die met de oplossing moeten worden bereikt en het beste met elkaar voor hebben zijn echter niet genoeg om een IT-project te laten slagen en de beste oplossing te leveren. Want wat is dat eigenlijk: de beste oplossing? Simpel: dat is de oplossing die met minimale functionaliteit (en dus zo laag mogelijke kosten) het achterliggende probleem oplost. Een IT-project moet altijd als doel hebben een probleem op te lossen. Functionaliteit in een IT-oplossing is een middel, geen doel. Echter gaat het daar veelal al mis. Maar al te vaak mogen de gebruikers specificeren wat ze allemaal aan functionaliteiten eisen en wensen. Dit geheel aan specificaties bepaalt het projectresultaat, zonder dat getoetst is of deze specs ook daadwerkelijk bijdragen aan de oplossing van het probleem. Hier zou de product owner dus een beslissende rol moeten vervullen. Want de veelheid aan eisen en wensen is een kolfje naar de hand van leveranciers die leveren op basis van ‘conform to specifications’. Ze bouwen exact datgene wat de klant vraagt, zonder zich bezig te houden met het daadwerkelijke probleem, met de vraag achter de vraag. Ze vinden het probleem dat de software moet oplossen ook helemaal niet belangrijk. Sterker, de leverancier heeft er eerder baat bij functionaliteit te ontwikkelen, die het probleem net niet helemaal oplost, want dat leidt tot meerwerk en uiteindelijk tot meer onderhoud. Kassa!
De kernvraag zou moeten zijn: wat is de beperkende factor die je in de weg staat om beter te presteren? Deze vraag is vaak veel helderder voor stakeholders en de gebruikers van de oplossing. Hier zullen ze gemakkelijker overeenstemming over krijgen dan over ‘de oplossing’ die gebouwd moet worden. En de product owner moet de stakeholders en gebruikers op deze manier bij de les houden.

Aanname 4: Nu effe geen voortschrijdend inzicht

Is de vooraf bepaalde scope van een project altijd heilig? Nee, natuurlijk niet. Organisaties opereren in een dynamische omgeving: morgen kan de concurrentie ineens uit een heel andere hoek komen of kan de wetgeving zijn veranderd. Het moet altijd mogelijk zijn het project gedurende de looptijd aan te passen aan wijzigende omstandigheden. Daarnaast heeft ieder project te maken met voortschrijdend inzicht. Je leert nu eenmaal met zijn allen, waardoor de kijk op de situatie soms verandert. Wat is er nu mooier dan dit voortschrijdend inzicht optimaal te benutten? (Zie ook ‘De klant had last van voortschrijdend inzicht’.) Hierbij speelt de product owner een belangrijke rol. Hij heeft de bevoegdheid om nieuwe eisen in te brengen en hieraan een prioriteit toe te kennen. Dat hierdoor een aantal specificaties met een lagere prioriteit sneuvelen, dat is zijn keuze. Uitgangspunt hierbij is dat de nieuwe eis meer gewenst is dan de wens die geschrapt wordt, zodat de klant per saldo meer krijgt dan vooraf was afgesproken. Dat de product owner hierover goed moet communiceren met zijn achterban, is vanzelfsprekend.

Aanname 5: Door aanbesteden houd je als klant grip op je leverancier

Gezien het voorgaande is evident, dat klanten eigenlijk ICT-projecten niet moeten willen aanbesteden. Dit kan bijvoorbeeld wel als je een server wil kopen. Want deze is volledig te specificeren. Maar zodra je iets wilt kopen, dat de oplossing voor een probleem moet zijn, moet je niet de arrogantie hebben om te denken dat je zelf de oplossing al kent en dat je die kunt specificeren.
Want daarmee bied je de leverancier een leunstoel aan, waarin hij achterover kan hangen. Hij hoeft alleen maar te maken wat gespecificeerd is en hij hoeft zich totaal niet meer druk te maken over de effectiviteit en efficiency van het projectresultaat. Kortom, bij aanbesteden heb je de zekerheid van de kosten, waarbij je maar moet afwachten of je krijgt wat je bedoelde. Je hebt dus totaal geen grip meer op de leverancier en je hebt de mogelijkheden uit handen gegeven om tussentijds bij te sturen.

Hijs de product owner op de bok

Het is dus duidelijk, dat een project van tegenwoordig een product owner nodig heeft. Dat geldt niet alleen voor software ontwikkeling, maar voor alle projecten. Want laten we wel wezen, vrijwel alle software die functies voor een organisatie vervult, bestaat al. Het gaat in hoofdzaak om de assemblage. Het idee om met allerlei ontwikkelaars in teamverband software te ontwikkelen is zelden nog de beste oplossing.
Daarom is het beter om uit te gaan van doelstellingen en van de context waarin de oplossing gebruikt moet worden. Slim inkopen van de componenten en dus zorgen, dat een deskundige partij die fitness for use levert hoofdaannemer wordt, is dan veel belangrijker dan het bewaken van tijd en geld. Bewaken van tijd en geld mogen de onderaannemers doen, die uiteraard fixed price moeten leveren. Het gaat om de regiefunctie en daarin speelt de product owner een cruciale rol. Hij is in staat zelf keuzes te maken eventueel na ruggespraak met de opdrachtgever en dat kost sowieso minder tijd en geld dan stroperige mechanismen als stuurgroepen en wijzigingsprocedures. In ons e-book gingen we ook al in op deze problematiek. Misschien moeten we zelfs wel zeggen dat deze projectmanager 2.0 niemand anders is dan de product owner.

Het ligt voor de hand om intern een product owner te zoeken. Misschien is een interne projectmanager bij te scholen tot product owner ofwel een projectmanager 2.0. Als u dergelijke interne kandidaten niet heeft, dan zult u ze van buiten moeten halen. Dat zelfde geldt voor organisaties, waar de besluitvorming bijna volledig een spel van politiek is. Daar is een interne product owner doorgaans kansloos, want de belangrijkste eigenschap van een product owner is, dat hij pragmatisch is en gaat voor oplossingen die werken in de praktijk.

De rol van product owner

Vaak wordt verondersteld dat de ideeën en de visie van de product owner er gewoon ‘zijn’ en dat al zijn ideeën bovendien wonderbaarlijk automatisch geordend zijn. Daarnaast gaat men er veelal van uit dat de product owner alle ruimte krijgt om moeilijke keuzes te maken en dat alle belanghebbenden hier altijd instemmend en eensgezind in meegaan. Helaas is de realiteit anders. Doen alsof de product owner een alleskunner is, getuigt niet van realiteitszin. Het managen van belanghebbenden, het inspirerend overdragen van een visie, het helpen bij technische keuzes, er zijn maar weinig product owners die dat allemaal beheersen. Product owner zijn is moeilijk. Het is dan ook niet vreemd dat velen in de valkuilen stappen die bij deze rol horen.
Wat in de praktijk extra lastig blijkt te zijn, is het creëren van een gedeelde visie en die vertalen naar een roadmap en product-backlog-items. Er is geen product owner die hier niet mee worstelt. Immers, je kunt niet in de toekomst kijken. Tegelijkertijd wordt van de product owner wel verwacht, dat hij perfecte oplossingen bedenkt voor nog onontdekte problemen. Scrum stelt dat er een product owner moet zijn en dat hij verantwoordelijk is voor de totstandkoming van een product-backlog, maar geeft niet aan hoe dat moet. Tja, dat mag de product owner zelf uitzoeken. Maar als de richting niet klopt, dan kun je nog zo geweldig Scrum gebruiken, dan ben je nog steeds met het verkeerde bezig. Scrum laat het maken van een visie en product-backlog dus helemaal aan de product owner over, maar gaat er vervolgens wél vanuit dat deze visie en backlog perfect zijn. Als dat geen dode hoek is?

Werkwijze van de product owner

Gelukkig zijn er manieren om dit gat te dichten. Belanghebbenden en teamleden betrekken bij het vormen van een visie en product-backlog staat daarin centraal. Het is van het grootste belang dat teamleden en belanghebbenden betrokken zijn en in workshops gezamenlijk een visie ontwikkelen en omzetten in een product-backlog. Door het gezamenlijk ontwikkelen van een visie in een interactieve en gefocuste workshop, creëer je draagvlak en interactie. Zo benut je alle kennis en ervaring van betrokkenen.
De kern is zo snel mogelijk feedback halen bij echte klanten en echte belanghebbenden. Feedback zorgt er namelijk voor dat de visie steeds beter en sneller vorm begint te krijgen. Vroege feedback geeft mogelijkheid tot bijsturen en leren. De volgende drie vragen moeten altijd worden gesteld:

• Heeft de opdrachtgever de oplossing nodig? Zo ja, wat is dan zijn probleem?
• Wil de opdrachtgever voor de oplossing betalen? Zo ja, hoeveel?
• Wil de opdrachtgever mij als product owner hebben en blijven steunen?

Tot het moment dat er een bewezen ‘ja’ ligt op deze vragen, is het aannemen van de rol van product owner te risicovol. Een toekomst van stress en ondankbaarheid zal volgen.
Maar ook bij een ‘ja’ blijft de vraag waar je al de technieken en vaardigheden leert die nodig zijn? Waar zit de beroepsopleiding tot product owner? Of wordt van een product owner gevraagd, dat hij naast alleskunner ook nog autodidact is?
Het belang van product ownership als vizier op de agile-organisaties van de toekomst, zal de komende jaren steeds meer toenemen. Het hebben van een scherp en zuiver vizier vraagt om investeringen in de vaardigheden van product owners. Een opleidingstraject waarin kennis en vaardigheden worden geleerd om met belanghebbenden aan de business kant tot een gedeelde visie te komen, is cruciaal.

Valkuilen voor de product owner

Misschien is wel de meest eessentiële vaardigheid van de product owner, dat hij weet wat zijn valkuilen zijn en hoe hij die in de praktijk kan vermijden. We zullen de belangrijkste op een rijtje zetten.

Alles zelf willen doen

De meest effectieve product owner bereikt zijn doelen samen met zijn teams en belanghebbenden. Dat betekent: faciliteren en niet te veel alleen doen. De product owner is geen business analist in een nieuwe verpakking, die zeer gedetailleerde hapjes werk aan de teams voert. Dus moet men eraan denken om belanghebbenden en teams bij elkaar te zetten, workshops te faciliteren en gezamenlijk te komen tot consensus over de koers die wordt ingezet. De product owner verwoordt het probleem,  de doelstellingen en de context waarin het projectresultaat gebruikt wordt. Verder maakt hij keuzes en stelt prioriteiten. Het team verzint echter de oplossingen en werkt deze nader uit om tot een geschatte effort te komen.

Geen product-backlog hebben

Een veel terugkerend probleem is dat maar heel weinig product owners daadwerkelijk visie hebben en een backlog voor het totale projectplan. Meestal is die backlog niet verder dan twee sprints vooruit ingevuld. De product owner is dan niet in control. Hij kan geen inschattingen doen, niet vooruitkijken op een iets langere termijn en heeft geen zicht op zaken die afvallen bij voortschrijdend inzicht. Dat betekent dat hij stuurt in het donker. Maak daarom als product owner de visie en product-backlog transparant. Heb je een muur vrij in de projectruimte? Gebruik deze om alle platen en briefjes op te hangen en bespreek de visie herhaaldelijk met de teams en belanghebbenden in dezelfde ruimte.

De product owner-rol erbij doen

De rol van product owner is meestal een fulltime job. Van projectmanagers vonden we dat normaal. Zou dat dan niet normaal zijn voor de product owner, als zijn rol eigenlijk meer omvat dan die van de projectmanager? Maak als product owner niet de fout te denken dat dit maximaal een uurtje per dag werk is. Backlog Refinement en het organiseren van workshops is serieus werk en niet iets om erbij te doen. Leid de refinement met belanghebbenden en de teams, en ga naar de Scrum-events. Vooral de Sprint Review is voor de product owner cruciaal.

Waarde van het resultaat vergeten

Veel product owners verdrinken in het proces en vergeten dan verantwoordelijkheid te nemen voor de waarde die hun product uiteindelijk levert aan de organisatie. Het risico is: operatie geslaagd, patiënt overleden. De missie van de product owner is ervoor te zorgen dat het eindresultaat beantwoordt aan de doelstellingen en dat dit resultaat bruikbaar is voor de doelorganisatie.

Mandaat veronderstellen

De impact van de product owner staat of valt met de ruimte om daadwerkelijk beslissingen te nemen. Dit is randvoorwaardelijk aan de rol. Mandaat is geen vanzelfsprekendheid en dat zal de product owner zelf moeten afdwingen. Hij zal vooral geloofwaardig moeten zijn. Draagvlak creëren is niet moeilijk, wanneer je komt met oplossingen die werken voor de betrokkenen.

Op alles ‘ja’ zeggen

Een product owner moet belanghebbenden uitdagen: alles wat ze vragen op de product-backlog gooien, is niet goed. De vraag die gesteld moet worden is: ‘Welke eisen en wensen kunnen vervallen als ik deze nieuwe eis honoreer?’ Het maximaliseren van het werk dat de teams niet gaan doen, dat is de uitdaging van elke product owner. ‘Ja’ zeggen is makkelijk, maar daarmee bombardeer je jezelf alleen tot probleemeigenaar. Want het probleem over de schutting te gooien naar het team is geen optie. Het team zal zich dan gaan verdedigen en daarmee ondermijn je de essentie van Agile.

Groeien product owners aan de boom?

Agile is een uitstekende denkwijze als het gaat om het uitvoeren van projecten, die veel breder toepasbaar is dan alleen voor het ontwikkelen van software. Blind varen op bijvoorbeeld Scrum als een soort van routeplanner, leidt vaak tot mislukkingen. Het is de product owner die continu moet blijven letten op de werkelijkheid buiten het project. Want daar moet het resultaat gebruikt kunnen worden. En die werkelijkheid verandert continu.

En juist daarin ligt het verschil met de traditionele projectmanager. Die moest natuurlijk wel zorgen voor een tevreden opdrachtgever, maar het projectresultaat stond vooraf vast. En als de werkelijkheid betekende, dat het projectresultaat minder bruikbaar was voor de opdrachtgever, dan was dat niet het probleem van de projectmanager. Wil een projectmanager kunnen optreden als product owner, dan zal hij zijn focus moeten verleggen en leren welke zaken in zijn rol als product owner ook van belang zijn. Hij moet zeg maar doorgroeien naar de rol van projectmanager 2.0. We beschrijven hier als centrale casus, dat de opdrachtgever een geweldige vakantie in Italië wil hebben. Voor projectmanager 2.0 en voor de product owner is het dan niet voldoende, de opdrachtgever naar zijn bestemming te brengen, waarbij hij het verder zelf uit mag zoeken. De product owner zorgt in overleg met de betrokkenen dat voor het hele gezelschap de randvoorwaarden worden ingevuld, dat iedereen inderdaad de vakantie als geweldig ervaart.
Product owner zijn is een vak dat je moet leren. Product owners groeien nu eenmaal niet vanzelf aan de boom.