Hoe je OKR’s in je project gebruikt om de bedrijfsimpact ervan te vergroten

Lees het transcript:

We proberen onze podcasts te transcriberen met behulp van een softwareprogramma. Vergeef ons eventuele typfouten, want de bot is niet altijd 100% correct.

Galen Low: Het is een lange dag geweest en het voelt alsof het project waaraan je werkt nog lang niet bij zijn doelstelling in de buurt komt. Het team heeft het gevoel dat de missie simpelweg bestaat uit het bouwen van een app om een app te bouwen, zonder veel meer houvast. Je staat op het punt je laptop voor vandaag dicht te klappen, maar bedenkt dat je misschien nog eens naar de resultaten van de strategische planning moet kijken om inspiratie op te doen.

Misschien staan jij en je team er gewoon te dicht op en zien jullie door de bomen het bos niet meer. Dus met het laatste beetje energie dat je nog hebt, open je enkele strategische documenten die je hebt gekregen — gewoon om je geheugen op te frissen over de visie en doelstelling van het project. En daar staat het, zo duidelijk als wat. De grote strategische doelstelling voor het jaar was... "een app bouwen".

Als je moeite hebt om je projectdoelen te verbinden met strategische bedrijfsdoelstellingen, en andersom, blijf dan luisteren. We gaan onderzoeken hoe OKR's — doelstellingen en belangrijkste resultaten — je projecten een kader kunnen geven om afstemming te bevorderen, impact te meten en je teams te motiveren om toe te werken naar de bredere bedrijfsstrategie.

Hallo allemaal, bedankt voor het luisteren. Mijn naam is Galen Low van The Digital Project Manager. Wij zijn een gemeenschap van digitale professionals met als missie elkaar te helpen vaardigheden en vertrouwen op te bouwen en met elkaar in contact te komen, zodat we de waarde van projectmanagement in een digitale wereld kunnen vergroten. Als je daar meer over wilt horen, ga dan naar thedpm.com/membership. En als je geïnteresseerd bent in toekomstgerichte gesprekken en praktische inzichten over digitaal projectleiderschap, overweeg dan om je op deze show te abonneren voor wekelijkse afleveringen.

Vandaag bespreken we hoe je projectoplevering kunt verbinden met bredere organisatiedoelen door doelstellingen en belangrijkste resultaten — ook wel liefkozend OKR's genoemd — toe te passen in je projectmanagementpraktijk.

Vandaag is Carsten Ley bij me — projectmanagementconsultant, OKR-coach en medeoprichter van zowel Asia PMO als OKR Asia.

Carsten, bedankt dat je vandaag bij me bent.

Carsten Ley: Dank je wel, Galen, dat je me in de show hebt uitgenodigd.

Galen Low: Ik heb hier zoveel zin in, want ik geef toe dat dit een onderwerp is waar ik nog niet veel over weet. Ik ga dus samen met een aantal van mijn luisteraars leren. Ik vind het een enorm interessant onderwerp. In mijn gemeenschap praten we veel over hoe je strategischer kunt werken, hoe je aansluiting vindt bij bredere bedrijfsdoelen en hoe je meer crossfunctioneel kunt werken in plaats van alleen geïsoleerd projecten op te leveren. En OKR's blijven steeds terugkomen.

Misschien kunnen we beginnen met een centrale vraag: kun je ons vertellen wat OKR's zijn en waarom projectmanagers en leiders van projectoplevering zich erom zouden moeten bekommeren? Normaal gesproken is dit het probleem van iemand anders om te definiëren. Het is de bedrijfsstrategie waar we niet altijd bij betrokken zijn. Maar ik vraag me af: wat is het nut hiervan voor projectmanagers, en waarom zouden we om OKR's geven?

Carsten Ley: Ja. Wanneer bedrijven met OKR's willen werken, moeten ze automatisch meer crossfunctioneel worden. OKR's zijn dus een heel goed aangrijpingspunt om over projectmanagement te beginnen. Helaas doen veel bedrijven dat niet, en ik zal je vertellen waarom. In bedrijven hebben we normaal gesproken een strategie en een jaardoelstelling. Daaronder hadden we vroeger submetingen die we KPI's noemden, toch?

Misschien waren sommige van je projectopleveringen, mijlpalen of incrementen verbonden met die jaarlijkse KPI's. Op de een of andere manier werd je daarop beoordeeld. Heel direct gezegd: ik was ook projectmanager bij een PMO. Soms werd ik simpelweg beoordeeld op het aantal projecten dat ik in een jaar opleverde, maar niet echt op de manier waarop het project — en natuurlijk de magische projectmanagementdriehoek van scope, tijd en budget — presteerde.

Maar niet op de doelstelling, de klant of het tevredenstellen van het bedrijf. Vaak meten we in projecten alleen hoe het project presteert, zonder echt te kijken naar de uitkomst van het project. Dat willen we hier veranderen. Elke onderneming heeft strategische jaardoelstellingen, en met OKR's willen veel bedrijven een beetje versnellen en uitsluitend een planning voor drie of zes maanden maken.

Voor Covid hadden we veel technologiebedrijven als klant, omdat OKR's afkomstig zijn van Google en Intel en erg bekend zijn in de technologie- en techgemeenschap. Hoe dan ook: ze passen goed bij wat we agile projectmanagement noemen, dat sneller werkt met sprints, versnelde oplevering van resultaten en meer klantgerichtheid.

Het past dus heel goed bij Agile. Sinds Covid worden we benaderd door veel traditionele bedrijven die met OKR's werken. We hadden farmaceutische klanten, overheidsklanten en ngo-klanten. Zij zeggen: omdat de wereld volatieler is geworden, kunnen organisaties — ongeacht of ze Agile werken — niet langer twaalf maanden vooruit plannen.

Daarom willen ze hun planning met OKR's opsplitsen in periodes van drie of zes maanden. Dat is het eerste wat OKR's doen. Je plant niet voor twaalf maanden, maar voor drie of zes maanden. Daarna plan je de volgende cyclus van drie of zes maanden, omdat je kortere resultaten wilt meten om de volgende planning te verbeteren.

Het tweede wat OKR's doen, is dat we vanuit de strategie en de jaarlijkse doelstellingen doelstellingen ontwikkelen. Idealiter zijn deze doelstellingen bedrijfsthema's. Een doelstelling kan zijn: de verkoop verhogen, de efficiëntie verbeteren, een product lanceren of iets dergelijks. Strategieën en doelstellingen zijn geen afdelingsgebonden thema's.

Ze hoeven dus niet onmiddellijk te worden opgesplitst in verkoop, marketing en operations. We raden sterk af om OKR's op te stellen als onze verkoop-OKR's, onze marketing-OKR's en onze operationele OKR's. Veel bedrijven willen dat wel, maar wij vinden het geen goed idee. Want wat OKR's doen — en nu komen we bij de structuur — is dat we één doelstelling hebben met daaronder meerdere belangrijkste resultaten.

Dat betekent dat als ik een doelstelling iets breder formuleer en zeg: we willen dit jaar succesvol zijn op de markt of ons succes op de markt verdubbelen, marketing een belangrijk resultaat krijgt, verkoop een belangrijk resultaat, product een belangrijk resultaat en delivery een belangrijk resultaat. Ze moeten allemaal samenwerken en hun belangrijkste resultaten worden gezamenlijk afgezet tegen de doelstelling.

Zo voorkom je verkokering. Je maakt vier of vijf afdelingen, of de belangrijkste mensen die hun resultaten leiden, gezamenlijk verantwoordelijk voor de doelstelling. En daar komt projectmanagement natuurlijk om de hoek kijken, want projecten hebben al doelstellingen. Dat spreekt voor zich. Alles wat we binnen PMI/PMP hebben geleerd over het formuleren van slimme doelstellingen, enzovoort, ken je uit de PMP-wereld.

Dat is precies wat we nodig hebben voor OKR's. Als je een goede projectdoelstelling hebt, neem die dan op in de OKR's. Het enige wat ik je vraag, is om die terug te brengen naar drie of zes maanden. Ik wil je projectdoelstelling niet pas na twee jaar kennen, zoals bij langlopende projecten waarin je zegt: we willen het product lanceren. Dan zeg ik: prima.

Maar wat is je doelstelling voor de komende zes maanden? Heb je voorbereidend werk? Lanceer je al iets kleins? Laat je iets aan de klant zien? Krijg je goedkeuringen? Ik weet het niet. Je kunt de doelstelling opsplitsen in een periode van zes maanden, wat haalbaar is. Kleiner. Soms hebben we projectfasen. Dan nemen we gewoon fase één of fase twee. Binnen die drie of zes maanden wil ik meetbare resultaten.

En nu komt een beetje de magie en het probleem voor projectmensen. Wij zijn erg gewend om onze taken en werkzaamheden te meten. We hebben opleveringen en mijlpalen die uit twintig taken bestaan. Wanneer die twintig taken zijn afgerond, hebben we onze oplevering of mijlpaal en kunnen we die meten in een OKR. Dat noemen we een input- of werkresultaat.

Dat is wat je als werkinput creëert. Het probleem is dat we in OKR's ook resultaatgerichte belangrijkste resultaten nodig hebben. We willen weten: zelfs in de eerste fase van het project, de eerste drie tot zes maanden, hoe helpt dit het bedrijf? Helpt het bedrijf er al mee? Tegenwoordig vind ik niet dat we ons twee jaar moeten vastleggen om daarna iets voor het bedrijf op te leveren.

Projecten moeten sneller opleveren en ook tussentijdse resultaten bieden, zoals functie-updates, productreleases of lanceringen na drie of zes maanden. Vanuit die gedachte meten we niet alleen wat het project doet. Stel bijvoorbeeld dat ik veel productprojecten heb gedaan.

Ik heb eerder voor banken gewerkt. Je maakt dus een nieuw product, bijvoorbeeld een creditcardproduct of een kredietproduct. Het projectteam zegt dan altijd: ik ben verantwoordelijk voor het bouwen van het product. Maar wat gebeurt er daarna met het product? Dat interesseert me niet. Ik geef het aan marketing en verkoop. Precies dat willen we met OKR's voorkomen.

We zeggen tegen het projectteam: jullie hebben de eerste functies van het product gebouwd. We lanceren die met testklanten of live, afhankelijk van het soort organisatie. Als je een fintechbedrijf of bank bent, begrijp ik dat een traditionele bank geen kleinere pakketten live kan lanceren. Bij een fintechbedrijf kan dat bijvoorbeeld wel. Je kunt in ieder geval lanceren bij testklanten, waarna het projectteam feedback van hen moet verzamelen.

Meet of ze het goed vinden, of het haalbaar is en of het verkoopbaar is. Daarna moeten ze het waarschijnlijk in de volgende fase aanpassen. Daarom kan de projectplanning ook slechts drie of zes maanden beslaan: zodra je een resultaat hebt, moet je dat met iemand in de markt testen op verkoopbaarheid of bedrijfsimpact.

Als dat niet goed genoeg is, moet je de fase misschien opnieuw uitvoeren.

Galen Low: Dat is echt interessant. Je punt over meten — we zijn gewend aan KPI's die we onmiddellijk en zelfstandig kunnen meten. We vragen ons af: is het project binnen budget gebleven? Hebben we het op tijd afgerond? En over het PMO: heb ik het aantal projecten uitgevoerd dat ik moest uitvoeren?

We meten dat, het is gemakkelijk en onmiddellijk, en er zijn geen afhankelijkheden. Maar wat jij beschrijft, spreekt me aan: enerzijds de klantgerichtheid, maar ook de crossfunctionaliteit. Om in dat scenario een belangrijk resultaat te behalen, zou het projectteam de sprint of productincrementen moeten afronden, die vervolgens overdragen en daarna marketing en verkoop bijvoorbeeld een testgroep van klanten laten benaderen, onderzoek laten doen en met de uitkomst daarvan terugkomen. Dat bepaalt dan of we het belangrijkste resultaat hebben behaald, niet het feit dat we de oplevering hebben afgerond.

Carsten Ley: Ja, we zouden zelfs nog een stap verder gaan. De projectdoelstelling kan projectresultaten bevatten, maar ook resultaten voor verkoop en marketing.

We hoeven het zelfs niet over te dragen. Tegenwoordig zeggen we dat iedereen binnen het project of als onderdeel van de overkoepelende doelstelling samenwerkt. Ik geef je een voorbeeld van een klant die we hadden. Ze waren een start-up en hadden vóór Covid een fantastische app voor evenementen gemaakt.

Bij elk evenement krijg je waarschijnlijk duizend, tweeduizend of drieduizend foto's van een bruiloft of zakelijk evenement. Aan het begin van het evenement krijgt elke deelnemer een foto of wordt het gezicht van elke deelnemer gescand. Vervolgens stuurt de app aan het einde van het evenement automatisch de foto's waarop jij staat naar jou.

Dat is geweldig, toch? Je kent dat vervelende gevoel wanneer je naar een evenement gaat en een link met achthonderd foto's krijgt. Je moet erdoorheen scrollen en denken: waar is mijn foto? Hebben ze echt een foto van mij gemaakt? Waar sta ik? Misschien vind je er zelfs je verloren tweeling mee.

Dat is ook een grappige functie. Misschien lijkt iemand precies op jou, want plotseling krijg je andere foto's te zien. Je begrijpt wat ik bedoel. Het probleem van deze klant voordat wij erbij kwamen, was dat ze een app voor fotografen hadden gemaakt. Hun productteam had drie tot zes maanden gewerkt aan een app voor fotografen met zeer ingewikkelde functies om foto's te bewerken.

Toen kwamen wij erbij, omdat we ook wat klantbeleving en UI/UX-advies geven. Ze zeiden: we hebben nu deze app. Kunnen jullie contact opnemen met fotografen om te vragen hoe we die kunnen vermarkten? We hadden veel fotografen in onze gemeenschap omdat we ook evenementen organiseerden. De reactie was: ik ben fotograaf. Ik betaal niets voor een app waarmee mensen zichzelf kunnen terugvinden, en ik heb mijn eigen programma's op mijn computer.

Ik bedoel: ik heb geen app nodig die me helpt foto's te bewerken. Dat heb ik al. Ik word betaald om foto's te maken, niet om foto's te verspreiden. Dat is de verantwoordelijkheid van de organisator van het evenement.

We gingen terug naar de klant. Ik zei: ik weet niet wat er in de drie tot zes maanden vóór onze komst is gebeurd, maar jullie marktonderzoek zat volledig verkeerd. We hebben een enquête gehouden onder tien of twintig fotografen. Niemand wilde dit kopen. Tegelijkertijd spraken we met veel organisatoren van evenementen, zoals bruidsparen en bedrijven, en zij zeiden: ja, dit willen we waarschijnlijk wel kopen.

We gingen terug naar het ontwikkelingsteam en de eigenaar van het bedrijf en zeiden: misschien waren de afgelopen drie of vier maanden voor de ontwikkeling een beetje verspild, maar we moeten dit programma nu vereenvoudigen. Alle ingewikkelde functies voor fotografen moeten eruit, want organisatoren van evenementen begrijpen die niet en het interesseert hen niet.

Zij hoeven foto's niet mooier te maken. We moeten nu een app maken voor organisatoren van evenementen, zodat ze foto's kunnen uploaden, foto's van deelnemers kunnen ontvangen of gezichten kunnen scannen, en die foto's vervolgens kunnen verspreiden. Ik weet niet hoeveel geld ze aan de ontwikkeling hadden uitgegeven, maar ze waren gewoon aan het ontwikkelen zonder marktonderzoek en zonder echt te weten wat de markt nodig had.

Je moet het team verantwoordelijk maken. Een ontwikkelaar kan zeggen: mijn baas zei dat ik een app voor fotografen moest ontwikkelen. Maar dan vraag ik: wat voor projectteam hebben jullie? Waar is de UI/UX-specialist? Waar is de test na twee of drie sprints met gebruikers? Je hebt nog geen volledig uitgewerkte app nodig.

Test het gewoon en zeg: we hebben twee gratis functies. Heb je met fotografen gesproken? Nee, dat hadden we niet. Dat is wat OKR's kunnen voorkomen als je het projectdoel vanuit het bedrijf formuleert, niet vanuit projectmijlpalen.

Galen Low: Je zei dat OKR's goed aansluiten bij Agile. Sommige luisteraars denken misschien: maar Carsten, we hebben geen OKR's nodig. Als we een crossfunctioneel Agile-team hebben, klantgericht zijn, iteratief werken, incrementen bouwen en die altijd aan de klant voorleggen, wat voegen OKR's dan toe? Als ze al voortdurend klantinput krijgen en crossfunctioneel zijn, voelen ze alsof ze gedeelde doelen hebben. Hebben ze dan OKR's nodig?

Carsten Ley: Onderaan doen ze het dan heel goed, dat geef ik toe. Maar hoe zit het bovenaan met de strategische afstemming? De eerste functie van OKR's — misschien ging ik iets te snel naar het voorbeeld van de app — is dat teams van sprint naar sprint gaan.

Uit mijn eigen ervaring weet ik dat veel ontwikkelingsteams een sprintplanning hebben voor twee of drie sprints vooruit. Agile teams plannen dus ongeveer drie tot zes maanden vooruit, afhankelijk van de lengte van de sprint. Er bestaat een mythe dat een Agile-team slechts twee weken vooruit plant. Dat klopt niet, want ze hebben een functie die sprintplanning heet.

Je kunt die sprintplanning combineren en voor zes weken tot drie maanden afstemmen met de OKR's en met de strategische input uit de doelstellingen van de OKR's. Ik wil voorkomen dat mensen meer werk krijgen door een nieuwe methode. OKR's hebben een wekelijkse of tweewekelijkse voortgangscontrole. Waarschijnlijk hebben jullie al elke twee weken een sprintreview. Begin die sprintreview dus met de OKR's en start met gegevens.

Als je al gegevens in de sprintreview hebt, gebruik die dan voor de OKR. Doe niets extra's. Helaas zien we dat sommige sprintreviews niet op gegevens zijn gericht. Het is dan vooral wat algemeen gepraat. We willen hen helpen de gegevens met OKR's te creëren. Als je sprintplanning zes weken tot drie maanden vooruitgaat, moet die aansluiten bij de driemaandelijkse doelstelling van het bedrijf.

Als ze dat al doen, hebben ze dan OKR's nodig? Dat weet ik niet. Maar OKR's geven structuur: van strategie naar jaarplanning, naar drie maanden, naar sprintplanning en naar sprints. Zo heb je duidelijk bewijs dat je met je sprints van twee weken daadwerkelijk aan de strategie werkt.

Galen Low: Dat spreekt me erg aan. Ik hoor over zoveel teams die gevraagd zijn iets te bouwen. Ze bouwen het, en daarna zegt iemand: weet je wat, dit is niet wat we nodig hebben. Of het sluit niet aan bij de bedrijfsstrategie. Dat is niet erg motiverend, want het team heeft het gevoel dat het alleen maar dingen bouwt.

We zijn dan een soort productfabriek voor functies. En misschien bouwen we ook niet het juiste, omdat we onze eigen doelen stellen in stappen van twee tot vier weken zonder echt aandacht te besteden aan de bredere strategische doelen.

Carsten Ley: Ik wil iets zeggen over motivatie.

We hadden een klant in klimaattechnologie. Een geweldige klant. Ze bouwden een app om de CO2-voetafdruk van bedrijven te meten. Dat is heel betekenisvol. Maar voordat wij met OKR's kwamen, vertelden ze hun ontwikkelaars: de eerste zes maanden bouwen we een app. Dat is saai.

Elke start-up vertelt zijn ontwikkelaars dat ze de eerste zes maanden een app bouwen. Waarom zou je dan gemotiveerd zijn om voor een specifieke start-up te werken? Als ik een techneut was en een bedrijf zei: we gaan weer een app bouwen nadat we er al tien of twintig hebben gemaakt, dan zou ik niet enthousiast worden.

Maar als je tegen mensen in de klimaattechnologie zegt: we zijn milieubewust en willen dat jullie helpen een app te bouwen waarmee bedrijven hun CO2-voetafdruk kunnen meten, dan is dat veel inspirerender. Daar komt de doelstelling om de hoek kijken. Die loopt bijna vanaf het bestaansdoel of de North Star van het bedrijf naar beneden door.

Galen Low: Grappig, want daarmee verbind je alles echt met elkaar. Je ziet beursgenoteerde bedrijven hun jaarverslag publiceren of een verheven missie en waarden formuleren. Veel mensen in de praktijk die het project uitvoeren, denken: dat is wat je aandeelhouders vertelt.

Maar wat ik mooi vind aan wat je zegt, is dat de doelstelling die algemene missie en strategie verbindt met het werk dat wordt uitgevoerd. Ze kan worden gebruikt om mensen te inspireren. Het is een tastbare visie, niet alleen woorden op een pagina om aandeelhouders tevreden te stellen of meer klanten te krijgen.

Carsten Ley: Het is niet alleen inspirerend; het kan zelfs bescherming bieden aan de mensen in de praktijk. Als ik zeg dat we een klimaatgebaseerde app maken en vervolgens op een dag zeg dat je nu een spel moet ontwikkelen, kan iemand vragen waarom dat nodig is.

Mensen staan dan niet alleen op een lager niveau opdrachten uit te voeren. Als je honderd regels code moet schrijven zonder te weten waarom, is dat niet erg inspirerend. Als ik weet dat ik code schrijf of functies programmeer voor klimaatrapportage, kan ik mijn leidinggevenden ook een beetje uitdagen. Als zij zeggen dat ik een app moet ontwikkelen om kortingsbonnen van McDonald's te krijgen, wat misschien niet erg klimaatvriendelijk is, kan dat zich tegen hen keren.

Galen Low: Ik vraag me af of je iets kunt vertellen over het proces. In theorie ben ik enthousiast. Het voegt niet noodzakelijk meer werk toe, maar biedt vooral meer structuur. Veel projectmanagers en soms zelfs PMO's zijn niet echt betrokken bij de bedrijfsstrategie. Wat zijn voorbeelden van OKR's en hoe kunnen die op een crossfunctionele manier worden opgesteld? Worden ze altijd van bovenaf opgelegd?

Carsten Ley: Laten we bij de klimaattechnologie blijven. Het bedrijf had financiering gekregen en zei: binnen één jaar moet deze app voor de CO2-voetafdruk klaar zijn. Ondertussen moeten we de app programmeren, partners vinden, financiering regelen en mensen aan boord halen. Dat zijn allemaal doelstellingen.

Start-ups hebben in hun eerste jaar al een strategie van één of twee jaar, omdat je niet weet hoe lang je bestaat. Je hoeft geen vijf jaar te plannen als je net financiering hebt gekregen. Dat is je strategie. Die wordt vervolgens vertaald naar een jaarlijkse doelstelling die de teamleider misschien kent. De teamleider en de oprichters moeten ten minste samen bepalen wat ze het volgende jaar willen bereiken, als concept of schatting. Daarna plannen ze doelstellingen voor drie maanden.

In het eerste kwartaal willen we bijvoorbeeld een prototype van de app hebben. Die doelstelling wordt waarschijnlijk opgesteld door de oprichters en teamleiders, nog niet door het hele team. Vervolgens ga ik naar het prototypeproject, dat niet alleen uit het ontwikkelteam bestaat.

Idealiter richt ik het in als een project met mensen uit de markt en verkoop, waarbij potentiële klanten of partners het prototype kunnen testen. Daarna organiseer ik als teamleider, eventueel samen met een externe consultant, een workshop over de meetbare belangrijkste resultaten voor de komende drie maanden. Het is dus geen top-downproces.

Dat is het mooie eraan en het sluit aan bij wat ze in Agile en sprintplanning al doen: het team betrekken. We weten dat we een prototype willen bouwen. Hoe meten we of we dat succesvol hebben gedaan? Zo kom je tot verschillende belangrijkste resultaten.

Het eerste resultaat gaat waarschijnlijk over het programmeren en ontwikkelen van een wireframeprototype. Een ander resultaat gaat over het testen van het prototype met een bepaald aantal gebruikers en het verkrijgen van specifieke feedback. Je kunt ook meten welke functies na de eerste drie maanden nog ontbreken en waaraan je de volgende drie maanden kunt werken.

Dat kunnen allemaal belangrijkste resultaten zijn. Het team heeft dan een inspirerende doelstelling voor drie maanden — een prototype voor klimaattechnologie — plus resultaten om die te meten. Vanuit daar kunnen ze de sprintplanning starten. De OKR is dan als het ware je achterstandslijst, je overkoepelende lijst met doelen.

Daaruit bepaal je wat je in de eerste twee of drie sprints opneemt. Zo werkt het proces. Ik denk niet dat we veel extra werk toevoegen. We leggen iets meer verantwoordelijkheid bij de teamleiders, omdat we willen dat de teamleiders van ieder team, of de projectleiders, op zijn minst bij de jaarlijkse planning betrokken zijn.

We hoeven hen niet bij de strategie te betrekken, maar wel bij de jaarlijkse planning. Ook in grotere bedrijven zorgen we ervoor dat afdelingsleiders, projectleiders en PMO-leiders deelnemen aan de bespreking van de jaarplanning.

Galen Low: Als ik je goed begrijp, zou je bij een organisatie die teamleiders niet betrekt aanraden om hen aan tafel te brengen voor de jaarlijkse planning.

Carsten Ley: Ja. In het OKR-proces willen we altijd meerdere lagen betrekken. Sommige bedrijven werken met OKR's op twee of drie niveaus: bedrijfs-OKR's en vervolgens helaas ook verkokerde afdelings-OKR's. Daar zijn wij geen voorstander van, maar we kunnen het voor hen opzetten als ze dat willen.

Als ze afdelings-OKR's maken, is het gemakkelijker om verantwoordelijkheid toe te wijzen volgens het organogram. Dat is niet erg Agile, maar zo werken bedrijven nu eenmaal. In sommige bedrijven hebben we bedrijfs-, afdelings- en team-OKR's. Dan willen we altijd twee lagen samenbrengen.

Bij bedrijfs-OKR's zitten de mensen aan de top samen met de afdelingsleiders. Bij afdelings-OKR's werken afdelingsleiders samen met teamleiders. Bij team-OKR's werken teamleiders samen met het team. Dat zorgt voor transparantie, een belangrijk woord bij afstemming rond belangrijkste resultaten, en ook voor input van onderaf.

Van onderaf betekent niet dat je bij een strategische bespreking aan de top van het bedrijf iedereen om input vraagt. Het betekent dat je ten minste de volgende laag erbij betrekt.

Galen Low: Ik vind dat een goed idee. Waar ik aan denk, is bijna educatie. Ik heb in veel organisaties gewerkt die om feedback vragen, maar wanneer de feedback binnenkomt, zeggen ze: deze mensen begrijpen het niet.

Als ik iemand was die op een enquête reageerde, of teamlid of teamleider was en mijn team moest helpen belangrijkste resultaten op te stellen, maar ze begrepen het niet goed, hoe zorg je er dan voor dat mensen binnen de organisatie begrijpen wat een goed belangrijkste resultaat is?

En hoe zorg je ervoor dat leiders begrijpen dat feedback van hun team niet zomaar willekeurige informatie is die ze kunnen negeren, maar dat iedereen het kader en de structuur begrijpt en voldoende opleiding of training krijgt om zinvolle input te leveren? Train je mensen over OKR's of moeten ze het intuïtief begrijpen?

Carsten Ley: Wanneer we beginnen met een bedrijf dat nog niet met OKR's heeft gewerkt, bieden we training op verschillende niveaus. We doen dat ook op het niveau van de oplevering, omdat OKR-training tevens helpt om draagvlak te creëren.

Sommige projectmanagers en PMO's willen geen OKR's invoeren omdat ze denken dat Agile alles al volledig afdekt. In de training kunnen we aantonen dat dit niet helemaal zo is. Ze hoeven hun hele proces niet te veranderen, maar kunnen vooral aan de resultaatgerichte en bedrijfsgerichte kant een aantal dingen verbeteren.

Wij en andere aanbieders van OKR's hebben een duidelijke structuur voor het formuleren van een inspirerende doelstelling die verbonden is met de strategie. Er moet altijd een reden zijn waarom je het doet. Waarom bouwen we een app? Niet alleen omdat we een start-up zijn en een app bouwen, maar omdat er een doel achter zit — idealiter een goed doel dat mensen inspireert.

Bij de belangrijkste resultaten kun je werk meten, bijna zoals bij een KPI: hoeveel projecten heb je gedaan, hoeveel functies heb je ontwikkeld? Maar dat zijn niet de echt goede belangrijkste resultaten. Het echte goede resultaat is: wat is de impact van ons werk? Vinden testklanten de functies goed?

Zijn er projecten die we dit jaar hebben uitgevoerd daadwerkelijk gelanceerd en hebben ze geld voor het bedrijf opgeleverd? Dat is misschien de juiste vraag. Dat zouden we moeten meten.

Naast structuur en opzet leren we mensen vooral een bepaalde mentaliteit aan: ik ben niet alleen verantwoordelijk voor mijn kleine onderdeel of voor de regels code die ik schrijf. Ik ben ook verantwoordelijk voor de manier waarop die code het product beïnvloedt en voor de vraag of het product verkoopt.

Daar kan weerstand tegen ontstaan. Dat is verandermanagement. Je krijgt altijd weerstand wanneer mensen zeggen: ik ben maar ontwikkelaar, ik ben niet verantwoordelijk voor hoe het product presteert.

Dat is de mentaliteit die we in het bedrijf moeten creëren. Daarom willen we verkoop, marketing en product niet verkokeren. Dat is juist de kern van projecten: mensen samenbrengen, een ontwikkelaar, een UI/UX-specialist en een verkoper samenbrengen en zeggen: we doen dit samen.

Galen Low: Het interessante aan silo's is dat ze veilig zijn. Je kent de mensen in je eigen silo en bouwt vertrouwen op rond het gezamenlijk behalen van een doel. Maar zodra je uit die silo stapt, denk je: ik weet niet of ik deze mensen kan vertrouwen.

Je noemt verandermanagement. Ik vraag me af of deze cultuurverandering meer conflicten veroorzaakt wanneer je uit een meer verkokerde teamcultuur komt en naar een crossfunctioneel model tussen afdelingen gaat.

Carsten Ley: We zien eigenlijk alleen conflicten op afdelingsniveau wanneer sommige leiders willen domineren. Middenmanagement kan dan een probleem vormen. Zij willen hun kleine koninkrijkjes bouwen en zeggen: ik wil niet dat product iets doet met mijn verkoop-KPI's. Dat zijn alleen mijn cijfers.

Ze willen het succes van hun cijfers niet delen op teamniveau. Op teamniveau zien we niet veel problemen, omdat we in een OKR-structuur werken met een systeem waarin iedereen de cijfers van verschillende teams kan zien.

Er bestaan duizenden OKR-hulpmiddelen. Wij hebben er geen eigen, omdat er zo veel zijn. Er zijn hulpmiddelen voor Jira, Microsoft en allerlei andere systemen. Alles heeft tegenwoordig wel een integratie met OKR's. Als iedereen na een sprintreview elke twee weken incheckt en de cijfers over de voortgang en de bedrijfsimpact invoert, kunnen we dat zeer transparant meten en weergeven.

Ik denk dus niet dat er veel conflict ontstaat. Mensen kunnen wel bang zijn dat ze geen invloed hebben, en dat klopt soms. Maar er is nog iets belangrijks: OKR's zijn geen prestatiecijfers zoals KPI's. We hebben ook zoiets als een ambitieus belangrijk resultaat, waarbij een score tussen 70 en 100 procent acceptabel kan zijn.

Er is ruimte. Als je geen honderd procent haalt, word je niet onmiddellijk op je bonus gekort. Als je dat wel doet, durven mensen niet crossfunctioneel samen te werken en geen gewaagde dingen uit te proberen.

Dat willen we juist bij OKR's en Agile: dat mensen dingen proberen en ideeën aandragen in een project. Je maakt dat volledig onmogelijk als je er een bonus- of prestatiemeting aan koppelt. Cultureel is het belangrijk dat je mensen ruimte geeft.

De eerste drie maanden met OKR's in een bedrijf noemen we altijd een OKR-pilot. We doen dat op leiderschapsniveau om draagvlak te creëren of in één team om het te testen. Als je het een pilot noemt, blijven mensen hopen dat het weer verdwijnt. Dat gebeurt meestal niet, maar zo klinkt het wel.

Een pilot klinkt ook alsof je nog invloed hebt en dat de zaken nog niet zo definitief zijn. Laten we ermee experimenteren. We zeggen dus tegen klanten: waarom beginnen we niet met een OKR-pilot? Zeg tegen je medewerkers dat we OKR's eerst gaan uitproberen. De meeste bedrijven hebben al besloten ermee door te gaan, maar je kunt de invoering in het begin wat soepeler laten verlopen.

Galen Low: Dat vind ik goed. Soms gebruiken mensen het ook om input te verzamelen. Misschien hebben ze al besloten ervoor te kiezen, maar ze verzamelen in ieder geval feedback over hoe ze het moeten invoeren.

Sommige mensen zeggen dat OKR's uit de mode raken en slechts een trend waren. Tegelijkertijd zijn er veel organisaties die ze nog niet gebruiken. Hoe kunnen projectmanagers of teams pleiten voor het gebruik van OKR's als de leiding nog niet overtuigd is of de invoering steeds uitstelt?

Kan een team op teamniveau deze verandering bepleiten?

Carsten Ley: Soms kun je OKR's alleen op teamniveau gebruiken als pilot. Wanneer het leiderschapsteam de pilot niet begeleidt, beginnen we met één team. We zoeken dan bij voorkeur een meer Agile team, bijvoorbeeld een productteam waar het goed werkt.

Als je een projectteam of functioneel team hebt, is het belangrijkste dat ze al KPI's of belangrijkste resultaten hebben die ze meten. Het is dus geen volledig nieuw concept. Tegenwoordig is er altijd wel een gegevensblad of systeem, zoals Microsoft Planner of Monday.com. Als dat niet zo is, gebruiken ze Excel.

Maar je moet elke week, elke twee weken of ten minste één keer per maand rapporteren wat je doet, of het goed gaat en welke cijfers erbij horen. Dat is geen raketwetenschap. Gebruik die cijfers als belangrijkste resultaten en voeg, zoals ik zei, enkele meer bedrijfsgerichte resultaten toe die verder gaan dan het team of die de impact na afronding van het project meten.

Daarbij moet je jezelf de juiste vraag stellen: waarom doen we dit project? Waarom lanceren we dit product? Als projectmanager en projectteam worden we natuurlijk betaald om het product te lanceren en het daarna aan operations en verkoop over te dragen. Maar als je volgens OKR's wilt werken, vraag je: waarom lanceren we dit product?

Je vraagt het aan verkoop en die zegt: we verwachten de eerste maanden minstens 10.000 dollar te verdienen. Dan neem ik dat op in mijn projectstart en plan ik een fase na de implementatie. Ik zeg: laten we samen met verkoop gedurende de eerste twee maanden verantwoordelijk blijven in de fase na de implementatie. We willen minimaal 10.000 dollar per maand behalen.

Het projectteam zegt dan natuurlijk: dat hangt niet alleen van ons af, maar ook van verkoop. Daarom werken we samen met verkoop. We betrekken hen bij het project, wat ook leuk is, omdat je van verkoop leert. Verkoop kan in de eerste weken al feedback geven: de klant vindt deze functionaliteit niet goed.

Dat is precies wat je wilt. Je wilt je project niet zomaar afronden. Als je betrokken wilt blijven als langdurige medewerker en spreekt over medewerkersbetrokkenheid, wil je zien dat je projecten impact hebben op het bedrijf.

Of, in het geval van klimaattechnologie, zelfs op de samenleving. In elk team, ook in een operationeel of functioneel team, kun je hiermee beginnen. Je teamleider zou de doelstellingen en langetermijnplanning moeten kennen. Als dat niet zo is, moet je als teamleider moedig genoeg zijn om naar je leidinggevenden te stappen en deze vragen te stellen.

De projectdoelstelling is niet alleen een product lanceren. Je vraagt: waarom moeten we dit product lanceren en hoe sluit het aan op de strategie? Hopelijk krijg je te horen dat het aansluit op de strategie. Met die informatie van bovenaf kun je heel gemakkelijk je doelstelling formuleren. Met de zaken die je al meet, heb je je eerste belangrijkste resultaten.

Daarna meet je ook de bedrijfsimpact en zie je of je team dit wil doen. Niet elk bedrijf hoeft met OKR's te werken. Sommige bedrijven vinden het prima om projecten gewoon uit te voeren en ze daarna aan verkoop en operations over te dragen.

Dat is voor mij volledig acceptabel. Probeer het echter eens met een team en kijk hoe mensen reageren.

Galen Low: Interessant. Ik vind die bottom-upbenadering van samenwerking goed. Praat met verkoop, ontdek hun doelstellingen en meet die. Ook als ons project, onze sprint, increment of release technisch is afgerond, blijven we geïnteresseerd in wat het buiten ons team doet.

We zullen hier waarschijnlijk aan blijven werken. Er ontstaat continuïteit en een lange levensduur van de missie die verbonden is met het bedrijf, niet alleen met één project of sprint.

Carsten Ley: Wanneer we dat doen, ontstaan verbeteringen na een projectfase meestal op een prettige, collaboratieve manier.

Wat er normaal gebeurt, vooral in een PMI-omgeving, is dat het project hard wordt afgesloten en overgedragen. Toen ik voor banken werkte, waren we alleen het projectteam. We voldeden aan alle mijlpalen en opleveringen en droegen het resultaat over. Maar misschien had iemand ons aan het begin van het project verkeerde input gegeven.

Of misschien was de verkoopdirecteur tijdens het project vervangen. Je draagt het dan over aan de nieuwe verkoopdirecteur. Twee maanden later stappen ze naar je leidinggevenden, escaleren ze de problemen en begint er veel strijd. Dat is geen prettige manier om samen te werken. Als het projectresultaat niet succesvol is, komt dat vroeg of laat toch terug bij het projectteam.

Galen Low: Dat is een interessante manier om ernaar te kijken.

Carsten Ley: Waarom voorkom je dat niet proactiever door tijdens het project al met de juiste mensen samen te werken en ervoor te zorgen dat het succesvol wordt?

Galen Low: Dat vind ik goed.

Je noemde nog één laatste punt. We hebben gesproken over top-down op leiderschapsniveau en over bottom-up. Een projectteam kan dit misschien gewoon proberen als team-pilot. Je noemde PMO's als het belangrijke midden. Toen je zelf een PMO leidde, werden je cijfers soms alleen gebaseerd op het aantal projecten dat je uitvoerde. Het lijkt erop dat OKR's een geweldige kans zijn voor PMO's die nog niet aan tafel zitten om strategischer te worden en niet alleen een projectfabriek te zijn.

Carsten Ley: PMO's zouden deel moeten uitmaken van de strategische bespreking, of ten minste van de jaarlijkse planning.

Dat is het eerste wat we moeten garanderen. Net als afdelingen kunnen PMO's OKR's hebben die aansluiten bij de bedrijfs-OKR's. Praat niet alleen over het aantal projecten, hoeveel projectmanagers je moet aannemen of hoeveel projecten je moet opzetten.

Stel dat een jaarlijkse doelstelling een productlancering is, een andere een marktintroductie en een derde efficiëntie. Dan kan het PMO brainstormen en bottom-up of vanuit het midden voorstellen doen over welke projecten de producten kunnen lanceren, de markt kunnen veroveren en het bedrijf efficiënter kunnen maken.

Vooral bij efficiëntieonderwerpen komen de beste voorstellen vaak uit de teams of van projectmanagers. Ze komen niet altijd van bovenaf, omdat leidinggevenden vaak niet precies weten wat er onder hen gebeurt.

Een PMO is een zeer crossfunctionele afdeling en heeft ook een governancefunctie. Toen ik later na de bank een PMO bij een fintechbedrijf leidde, gebruikten we het PMO vaak voor enquêtes. We vroegen teamleden uit verschillende teams naar hun behoeften en naar wat ze van projecten of lanceringen nodig hadden.

We vroegen niet alleen de voor de hand liggende teamleiders om input, maar ook andere mensen. Soms kan een PMO meer doen. We hadden bijvoorbeeld een ideeënbus. Het PMO beheerde de digitale ideeënbus van het bedrijf. Iedereen kon ergens vandaan komen en zeggen: ik heb een idee voor een project, want dit werkt niet goed.

We hadden een klein budget om een beloning te geven als de suggestie werd opgepakt en we er een succesvol project van maakten. Een PMO kan met deze crossfunctionele invloed veel doen. Mensen vertrouwen het PMO. We zijn niet politiek gekleurd en zijn neutraal. Deel uitmaken van de strategische jaarbespreking, voorstellen doen en het proces uiteindelijk coördineren is fantastisch.

Galen Low: Ik vind dat een geweldig idee en wil daar zeker dieper op ingaan. We maken nog een aflevering over OKR's voor PMO's. Dat lijkt me erg interessant.

Carsten Ley: Dat zou geweldig zijn.

Galen Low: Geweldig. Carsten, hartelijk dank dat je vandaag tijd met me hebt doorgebracht. Ik heb het erg leuk gevonden en veel geleerd.

Carsten Ley: Heel erg bedankt. Het was een genoegen om hier te zijn. Dank je wel, Galen.

Galen Low: Goed, mensen, daar hebben jullie het. Zoals altijd: als je wilt deelnemen aan het gesprek met meer dan duizend gelijkgestemde projectmanagementliefhebbers, sluit je dan aan bij onze gemeenschap. Ga naar thedpm.com/membership voor meer informatie. En als je het leuk vond wat je vandaag hoorde, abonneer je dan en blijf in contact via thedigitalprojectmanager.com. Tot de volgende keer, bedankt voor het luisteren.