Come Usare gli OKR Nel Tuo Progetto Per Amplificare l’Impatto sul Business

Leggi la Trascrizione:

Stiamo provando a trascrivere i nostri podcast utilizzando un programma software. Ci scusiamo per eventuali errori di battitura poiché il bot non è corretto al 100% delle volte.

Galen Low: È stata una lunga giornata, e sembra che il progetto su cui stai lavorando sia lontano dal raggiungere il suo obiettivo. Il team ha la sensazione che la missione sia semplicemente quella di creare un'app solo per il gusto di crearne una, senza altri spunti. Sei pronto a spegnere il laptop per oggi, ma pensi che forse dovresti tornare agli output della pianificazione strategica per trovare un po' di ispirazione.

Forse il problema è che tu e il tuo team siete troppo coinvolti e non riuscite più a vedere il quadro generale. Così, con l’ultima energia rimasta, tiri fuori alcuni dei documenti strategici che ti sono stati consegnati — solo per rinfrescarti la memoria sulla visione e sugli obiettivi del progetto. Ed eccolo lì, nero su bianco. Il grande obiettivo strategico dell'anno era... "costruire un'app".

Se fai fatica a collegare gli obiettivi del tuo progetto a quelli strategici di business e viceversa, continua ad ascoltare. Esploreremo come gli OKR — Obiettivi e Risultati Chiave — possano offrire ai tuoi progetti un framework per guidare l’allineamento, misurare l’impatto e motivare i team verso la strategia aziendale più ampia.

Ciao a tutti, grazie per essere qui. Mi chiamo Galen Low del Digital Project Manager. Siamo una comunità di professionisti digitali impegnati ad aiutarci a vicenda a diventare più competenti, sicuri e connessi per valorizzare il project management nel mondo digitale. Se vuoi saperne di più, visita thedpm.com/membership. E se ti interessano conversazioni all’avanguardia e spunti pratici sulla leadership nei progetti digitali, valuta di iscriverti al nostro show per episodi settimanali.

Oggi parliamo di come collegare l’esecuzione dei progetti agli obiettivi organizzativi più ampi, integrando gli Obiettivi e Risultati Chiave — detti anche, con affetto, OKR — nella pratica di project management.

Con me oggi c’è Carsten Ley — consulente di project management, coach OKR e co-fondatore di Asia PMO e OKR Asia.

Carsten, grazie per essere qui con me oggi.

Carsten Ley: Grazie a te, Galen, per avermi invitato alla trasmissione.

Galen Low: Sono davvero felice di approfondire questo argomento perché ammetto che è un'area che non conosco benissimo, quindi imparerò anch’io insieme ad alcuni dei miei ascoltatori. Penso che sia un tema interessante. Nella mia community si discute spesso di come essere più strategici, collegarsi agli obiettivi di business più ampi, essere più trasversali e non solo limitarsi a consegnare progetti a compartimenti stagni. E gli OKR continuano a saltare fuori.

Quindi pensavo potremmo iniziare da una domanda centrale: puoi dirci cosa sono gli OKR e perché dovrebbero interessare a project manager e responsabili della delivery? Di solito sono argomenti di altri, e riguardano la strategia aziendale a cui non sempre partecipiamo. Ma qual è il “perché” per i project manager? Perché dovremmo preoccuparci degli OKR?

Carsten Ley: Sì. Quando le aziende vogliono implementare gli OKR, devono necessariamente diventare più trasversali. Gli OKR sono infatti un ottimo punto di partenza per iniziare a parlare di project management. Sfortunatamente, molte aziende non lo fanno, e poi ti dirò il motivo. In azienda, di solito, abbiamo la strategia, stabilita come obiettivo annuale, e prima avevamo, sotto questi obiettivi annuali, delle sotto-metriche chiamate KPI, giusto?

Magari qualcuno dei deliverable di progetto, milestone o incrementi era connesso proprio a questi KPI annuali. Più o meno, e venivi valutato su quello. Io stesso, come project manager di PMO, venivo semplicemente valutato su quanti progetti consegnavo in un anno – ma non sempre su come andavano, e certo, sulla classica triplice restrizione del project management: ambito, tempi, budget. Ma non davvero sull’obiettivo, sul cliente, sul rendere l’azienda soddisfatta. Spesso si misura unicamente come performance il progetto, senza guardare se e come genera un risultato per il business. Ed è questo che vogliamo cambiare: ogni azienda ha obiettivi strategici annuali, ma con gli OKR molte vogliono accelerare e pianificare su finestre temporali più brevi di tre o sei mesi.

Prima del Covid lavoravamo soprattutto con aziende tech perché l’OKR è nato in Google e Intel, è molto famoso nella community tech. Di base, si adatta bene alla gestione agile dei progetti, più rapida nelle iterazioni e più focalizzata sul cliente e sul risultato. Da dopo il Covid ci contattano anche molte aziende tradizionali interessate agli OKR: clienti nel settore farmaceutico, enti pubblici, ONG. Tutte, perché il mondo è diventato più volatile. Ormai, sia che si lavori in modo agile che tradizionale, non si riesce più a pianificare a 12 mesi.

Quindi si vuole ridurre l’orizzonte a tre o sei mesi: è la prima cosa che fanno gli OKR. Non pianifichi più a un anno, ma su 3-6 mesi, e dopo pianifichi il ciclo successivo, per misurare risultati a breve termine e migliorare la pianificazione successiva.

La seconda cosa che fanno gli OKR: dalla strategia e dagli obiettivi annuali si sviluppano obiettivi specifici che idealmente sono temi di business. Gli obiettivi possono essere aumentare le vendite, migliorare l’efficienza, lanciare un prodotto, fare qualcosa di concreto. La strategia sono obiettivi, normalmente questi temi. Non devono per forza essere subito suddivisi in vendite, marketing, operations. In realtà, sconsigliamo di fare OKR “di reparto” (tipo OKR marketing, OKR vendite, OKR operations): molte aziende vorrebbero, ma non riteniamo sia produttivo, perché la forza degli OKR sta proprio nella struttura: a un obiettivo possono collegarsi più risultati chiave.

Quindi, se rendo l’obiettivo un po’ più ampio (“doppiare il successo sul mercato quest’anno”), allora marketing avrà un risultato chiave, vendite un altro, prodotto un altro, delivery un altro, devono lavorare tutti insieme, e i loro risultati vengono misurati insieme sull’obiettivo comune.

E qui torna il project management, perché i progetti hanno già degli obiettivi. È quasi scontato: tutto ciò che si studia nel PMI/PMP, come definire obiettivi SMART, eccetera, sono già le basi degli OKR. Se hai un buon obiettivo di progetto, puoi inserirlo negli OKR. L’unica cosa che ti chiedo è di accorciare l’orizzonte a 3 o 6 mesi: non voglio conoscere l’obiettivo tra 2 anni nei progetti a lungo termine (“lanciare il prodotto”). Ok, ma qual è l’obiettivo nei prossimi 6 mesi? C’è qualche lavoro preparatorio? Qualche rilascio parziale? Presentazione al cliente? Qualsiasi segnale intermedio? L’obiettivo va scomposto su base semestrale.

A volte i progetti sono divisi in fasi: prendiamo la Fase 1 o la Fase 2 e dentro questi 3 o 6 mesi voglio metriche misurabili.

E qui arriva un po’ la magia (e la difficoltà) per chi lavora nei progetti: siamo abituati a misurare task e deliverable, milestone con decine di attività: una volta svolte, abbiamo il nostro deliverable o milestone, e possiamo misurare. In OKR, quello è un risultato chiave di input/lavoro: indichiamo cosa viene realizzato come output di lavoro. Ma negli OKR servono anche risultati chiave di output/risultato: vogliamo sapere, anche nella primissima fase del progetto, quale impatto porta all’azienda. Aiuta già l’azienda?

Oggi non bisogna più aspettare due anni per vedere qualcosa. I progetti devono portare risultati più rapidi, anche intermedi: feature update, release di prodotto, lanci ogni 3-6 mesi. Quindi si misura non solo cosa fa il progetto, ma il suo impatto: ad esempio, tante volte mi è capitato di lavorare su progetti di prodotto (in banca), tipo una nuova carta di credito. Il team di progetto pensa solo allo sviluppo, dicendo “il mio compito è costruire il prodotto” e dopo non mi interessa più (va al marketing o vendite). Ed è proprio questo che con gli OKR vogliamo evitare.

Si chiede quindi al team di progetto: costruite le prime funzionalità del prodotto, le lanciate a clienti test o direttamente su mercato, a seconda delle regole (banca tradizionale o FinTech). Almeno un feedback dai clienti test si deve ottenere e misurare: piace? È fattibile? Si vende? Magari bisogna rivederlo nella fase successiva. Ecco perché la pianificazione del progetto la vogliamo a 3-6 mesi, perché ogni volta che c’è un output bisogna testarne la commerciabilità e l’impatto sul business. Se non c’è, si rifà la fase.

Galen Low: È davvero interessante il discorso sulla misurazione: siamo abituati ai classici KPI semplici e immediati (“il progetto è stato nei tempi? è andato in budget?”), come dicevi prima per il PMO: “ho consegnato il numero di progetti previsti?”. Sono metriche facili, istantanee, senza dipendenze. Tu invece parli di customer focus e cross-funzionalità: per raggiungere un risultato chiave, il team progetto deve completare una fase, passare il test a marketing/vendite che poi raccolgono i pareri dei clienti e tornano con l’esito, da cui si decide se il risultato è raggiunto. Non basta solo completare il lavoro.

Carsten Ley: Sì, andrei anche oltre: l’obiettivo di progetto può avere risultati chiave del progetto ma anche di vendite e marketing. Non serve nemmeno il passaggio di consegne: ormai lavoriamo tutti insieme, come parte di un unico obiettivo. Ti faccio un esempio: avevamo come cliente una startup che prima del Covid aveva realizzato una app fantastica per eventi. Ad ogni evento raccoglieva migliaia di foto, all’inizio si scattava o scansionava il volto dei partecipanti, e a fine evento l’app mandava automaticamente tutte le foto in cui apparivi direttamente a te. Geniale: tutti odiamo perdere ore tra le centinaia di foto di un evento cercando se ci siamo… magari scopri il tuo gemello perso! Divertente. Ma il problema era che avevano sviluppato l’app per i fotografi: il team prodotto aveva passato mesi a realizzare funzioni complicate di elaborazione immagini. Quando siamo intervenuti noi (facciamo anche CX e UI/UX), hanno chiesto di aiutarli a proporlo ai fotografi. Grazie alla nostra community di fotografi, scopriamo che nessuno voleva pagare per un’app così: “Ho già i miei programmi, io vengo pagato per fare foto, non per distribuirle, quello è compito dell’organizzatore evento!”. Sentendo invece organizzatori di eventi e sposi, abbiamo ricevuto entusiasmo. Abbiamo riferito al cliente che il target era sbagliato: andava completamente ridefinito, rendendo l’app semplice per caricare e distribuire le foto, senza mille funzioni incomprensibili ai non tecnici. In sintesi: se sviluppi senza fare ricerca di mercato, senza chiedere alla clientela, rischi di sprecare mesi di lavoro. È responsabilità anche del team progetto (non solo del boss che ordina): dove sono UX/UI? Dove i test a metà progetto con il target reale? Almeno due funzionalità testate. Ecco cosa può prevenire l’OKR: fare in modo che gli obiettivi siano di business, non solo milestones di progetto.

Galen Low: Hai detto che gli OKR si integrano benissimo con l’Agile: alcuni potrebbero pensare che con un team Agile cross-funzionale, centrato sul cliente, iterativo, che rilascia incrementi e riceve feedback costanti, non servano gli OKR. Cosa aggiungono? Se raccolgono già input cliente e sono trasversali, sentono di essere allineati... servono davvero?

Carsten Ley: Se a livello operativo lavorano bene, non posso che fare i complimenti. Ma come va sull’allineamento strategico, in alto? Il primo scopo degli OKR è proprio quello: collegare team che si muovono di sprint in sprint. Ho visto molti team development che pianificano 2-3 sprint avanti, quindi in realtà anche Agile copre 1,5-3 mesi. Sfatiamo il mito che i team Agile pianifichino solo 2 settimane: hanno comunque un planning horizon. Si può quindi integrare il planning degli sprint su 6 settimane-3 mesi con gli OKR, allineando tutto agli obiettivi strategici. Non voglio mai sovraccaricare i team con nuove metodologie: l’OKR ha un tracking settimanale o bisettimanale dove si misurano i risultati (esattamente come il review di sprint). Usa i dati di sprint review per l’OKR, senza duplicare attività. Spesso le review non sono basate sui dati, sono solo “blabla”. Aiutiamo a crearli con gli OKR. Così il planning a 3 mesi trova corrispondenza nei 3 mesi dell’obiettivo aziendale. Se già c’è, OK; ma l’OKR dà proprio struttura: dalla strategia annuale, al trimestrale, al planning di sprint, fino alle singole iterazioni. Aiuta a dimostrare che i piccoli sprint contribuiscono davvero alla strategia aziendale.

Galen Low: È molto interessante, perché spesso i team sono chiamati a costruire qualcosa e... “Ma non è quello che serve!” oppure “Non è allineato alla strategia!”. E così, a) poca motivazione (“stiamo solo producendo feature”), b) magari non costruiscono quello giusto, perché decidono loro le priorità ogni 2-4 settimane senza connettersi alle strategie più ampie.

Carsten Ley: Una cosa da dire sulla motivazione: abbiamo avuto un cliente nel climate tech, che sviluppava un’app per misurare la carbon footprint delle aziende, quindi ad alto impatto sociale. Ma prima di introdurre gli OKR, ai developer veniva solo detto “nei primi sei mesi sviluppiamo l’app”, che è noioso: ogni startup chiede ai developer di “creare un’app”, ma non è motivante. Se, invece, spieghi: “noi vogliamo aiutare le aziende a misurare l’impronta di carbonio”, e il tuo lavoro abilita questo, è ben altro. L’obiettivo diventa fonte di ispirazione, parte dal purpose aziendale, dalla North Star.

Galen Low: È interessante: nelle grandi aziende magari vedi dichiarazioni di missione molto “alte”, e chi lavora sul progetto le considera solo “parole da consiglio di amministrazione”. Ma quello che dici è che se ben sintetizzato, l’obiettivo può ispirare e diventare concreto, non solo parole vuote, se davvero rappresenta la mission aziendale.

Carsten Ley: Non è solo ispirazione, ma anche una protezione per chi lavora. Se ti dico “facciamo un’app per il clima” e poi ti chiedo di sviluppare un gioco, puoi chiedere “perché devo farlo?”. Si può essere parte attiva, non solo meri esecutori di task. Si sa perché si scrive codice, per chi: puoi anche confrontare il tuo responsabile se l’obiettivo cambia drasticamente, come un’app di coupon non eco-friendly. Ti dà potere di domandare.

Galen Low: Mi piacerebbe sapere qualcosa sul processo, perché mi piace l’idea in teoria, ma nella pratica molti project manager o PMO non partecipano alla strategia business. Puoi fare esempi di OKR e come si costruiscono in modo trasversale? O vengono sempre “calati dall’alto”?

Carsten Ley: Prendiamo il climate tech: startup finanziata, un anno per realizzare l’app, e nel frattempo programmare, trovare partner, raccogliere fondi, inserire persone: i classici obiettivi del primo anno. Strategie di 1-2 anni, perché non sai quanto dura la fase seed. Si passa poi all’obiettivo annuale, concordato tra leader/founder. Dal piano annuale si stendono poi i target a 3 mesi: il Q1 potrebbe essere realizzare il prototipo. Questo obiettivo nasce tra founder e team leader (non ancora team intero), poi, per il prototipo, costruisco un team trasversale: dev, mercato, sales, beta-tester. Chiedo al mio team — in workshop anche con un consulente esterno — quali potrebbero essere i risultati chiave misurabili nei 3 mesi. Non è solo top down: come nel planning Agile, coinvolgi le persone. Una volta deciso “vogliamo prototipo”, si stabilisce come misurare il successo: una KR sarà tecnicamente lo sviluppo (wireframe), un altro testare con N utenti, raccogliere feedback, individuare feature mancanti, tutto misurabile, così da preparare il lavoro successivo. L’OKR diventa backlog degli obiettivi e da lì si pianificano gli sprint. Non aggiunge molto carico se non sui team lead, coinvolti almeno nella pianificazione annuale, magari anche nei reparti delle grandi aziende. Must: leader di dipartimento e progetto a tavolo.

Galen Low: Da quanto dici, suggerisci di coinvolgere attivamente i team leader annualmente. Se trovi un’organizzazione in cui non lo fanno, il tuo ruolo è portarli al tavolo?

Carsten Ley: Sì. Negli OKR, soprattutto in alcune aziende tradizionali, servono più livelli: OKR aziendali, poi di reparto (anche se non siamo fan), poi di team. In ogni livello ci sono sempre almeno due layer a contatto: azienda+reparti, reparti+team leader, team leader+team. C’è trasparenza e anche input bottom up. Non significa chiedere al personale operativo input di strategia, ma aprire almeno al livello immediatamente sotto. Ad esempio, presso un nostro cliente SaaS/FinTech in USA, top management stendeva strategia e obiettivi annuali e poi si mandava un sondaggio a tutti i 150 developer worldwide chiedendo feedback: non tutti rispondono, ma chi lo fa aggiunge valore. Un feedback ricevuto riguardava il linguaggio troppo “bellico” (“schiacciare i competitor”), non condiviso: così si è smorzato il tono, favorendo identificazione. In generale, a ogni OKR si coinvolge il layer immediatamente sottostante: per gli OKR del PMO, devono esserci anche i project manager, e per quelli di progetto, tutto il project team.

Galen Low: È quasi una questione di cultura/educazione: molte aziende chiedono feedback ma poi rispondono che “la gente non capisce la strategia”. Se io fossi un team leader che coinvolge il team nella definizione dei risultati chiave, ma quei risultati non sembrano allineati o misurabili... Come formi l’organizzazione sugli OKR, sia operativamente che a livello di feedback valido?

Carsten Ley: Normalmente, quando iniziamo un progetto OKR, forniamo formazione a diversi livelli. Anche perché la formazione implica buy-in: spesso i project manager o PMO pensano di coprire già tutto con Agile, ma spesso si vede nella formazione che ci sono 2-3 aree da migliorare, soprattutto sul lato “outcome” e business oriented.

Forniamo una struttura chiara: come scrivere un obiettivo d’ispirazione, sempre legato alla strategia (“perché lo facciamo?”). Il risultato chiave può essere una KPI (“quanti progetti sviluppati?” “quante feature?”), ma i risultati chiave migliori descrivono l’impatto (“ai clienti piace la nuova funzionalità?” “quanti progetti hanno generato fatturato?”). Il tema centrale non è solo il setup, ma il mindset: non essere responsabile solo del proprio ambito (“ho fatto 400 righe di codice!”), ma anche dell’impatto sul prodotto e la sua vendibilità. Qui si trova a volte resistenza; è normale, è change management. Ma è proprio lo spirito del progetto moderno: unire sviluppo, UX/UI, sales, in un tutto unico. Non più “io faccio la mia parte e del resto non mi interessa”.

Galen Low: I silos sono sicuri, perché dentro al silo si crea fiducia. Ma appena esci, nasce insicurezza verso gli altri team. Immagino che il cambio culturale verso il cross-functional, se parti da una cultura a silos, inizialmente possa creare conflitto...

Carsten Ley: Si vedono conflitti solo a livello di reparto, soprattutto dove alcuni leader vogliono “difendere il proprio orticello”: middle management, che tende a dominare, vuole la proprietà esclusiva delle KPI del proprio dept. Invece nei team funzionali i problemi sono minimi, specie perché nel sistema OKR i dati di ogni team sono accessibili apertamente (ci sono tantissimi tool OKR integrati in Jira, Microsoft, etc). Basterà un check-in ogni due settimane (post-sprint review o riunione) per aggiornare lo stato dei lavori e l’impatto prodotto. Il timore più diffuso riguarda la dipendenza da altri team, ma qui gli OKR non sono “numeri di performance” come le KPI tradizionali: si parla di risultati “stretch”, anche raggiungere solo il 70% è considerato un successo. Rifiutiamo sempre sistemi “bonus performance” legati agli OKR: si disincentiverebbe la collaborazione trasversale e la voglia di innovare. Premi, sì, ma spesso e su risultati concreti, senza penalizzazioni lunghe. Per cultura aziendale è fondamentale: chiamiamo sempre “OKR Pilot” la prima fase di tre mesi, così si può presentare come test (pur sapendo che spesso resterà, ma permette di abbassare le difese iniziali). Si inizia sempre con pilota: viene percepito come “rivedibile”, “senza severità”, e aiuta l’accettazione del cambiamento.

Galen Low: Mi piace: anche se a volte è solo apparenza, almeno ascoltano i feedback e coinvolgono le persone su come implementare il metodo. Un po’ da “avvocato del diavolo”: alcuni dicono che gli OKR sono già passati di moda, una tendenza che ora viene abbandonata. Ma, come hai detto, tanti ancora non li adottano. Se un team vuole spingere per introdurli ma i manager non sono convinti, può partire dal basso?

Carsten Ley: Si possono implementare OKR anche solo a livello di team, in via pilota, magari su un team Agile/prodotto, dove funzionano meglio. In fondo, ogni team già oggi misura qualcosa: KPI, risultati, tutti lavorano con tools digitali (Microsoft Planner, Monday.com, anche Excel...), e devono comunque riferire periodicamente cosa fanno e con quali numeri. Basta utilizzare tali dati come risultati chiave, aggiungendo qualche indicatore più “impattante” sul business esteso, oltre il team. Si tratta solo di porsi la domanda corretta: perché stiamo facendo questo progetto? Perché lanciamo questo prodotto? Il project management classico vuole solo consegnare e scaricare a vendite/operation, ma il pensiero OKR è “Perché lo lanciamo? Qual è il target di vendita? Collaboriamo con sales dopo il rilascio e mettiamo insieme le metriche post-live (es. 10.000 euro/mese nei primi due mesi).” Certo, risultati non dipendono solo da noi, ma lavorando insieme si ha subito feedback (es. sales che riporta problemi funzionali che si possono correggere subito). Questo rafforza anche l’engagement personale e la soddisfazione: vedi davvero l’impatto dei tuoi progetti sull’azienda o sulla società, come nei climate tech. Se anche in un team operativo/funzionale, il leader conosce le strategie, può costruire l’obiettivo e le misurazioni; in mancanza ne può chiedere accountability al proprio responsabile. Non dico che tutti debbano usare OKR, non in tutte le aziende serve; dove si preferisce lavorare per progetti “a compartimenti” va bene, ma vale sempre la pena provare e vedere le reazioni.

Galen Low: Mi piace l’approccio bottom up, coinvolgendo sales sui risultati veri, anche post rilascio: in fondo il progetto continuerà a vivere, imparerai e migliorerai nel tempo. C’è continuità e missione più ampia, non solo “sprint e via”.

Carsten Ley: Sì, e di solito, dove c’è continuità anche dopo una fase di progetto, si migliora tanto sulla collaborazione. A volerlo tagliare di netto (PMI style: faccio il progetto, consegno, ciao), può capitare che un input sbagliato all’inizio rovini tutto, o cambi il referente commerciale tra inizio e fine: magari il nuovo sales dopo due mesi va dal capo a “scatenare l’inferno” perché mica era coinvolto durante. Collaborando fin da subito col team sales, invece, il rischio di conflitti a fine progetto cala moltissimo.

Galen Low: Interessante angolazione.

Carsten Ley: Perché non prevenire con più collaborazione? Rende il lavoro molto più sereno per tutti, anche in futuro.

Galen Low: Bellissimo. Parlando di top-down e bottom-up: hai nominato i PMO, una grossa via di mezzo. Anche da ex PMO, dicevi che i tuoi numeri erano sempre tipo “quanti progetti hai consegnato”, ma sembra che gli OKR possano essere una grande occasione per i PMO per essere più strategici e non solo una “fabbrica di progetti”. Hai qualche spunto su come i PMO possano usare gli OKR per legarsi al business?

Carsten Ley: I PMO dovrebbero sempre essere coinvolti nella pianificazione strategica o almeno annuale. Poi, anche i PMO possono avere i propri OKR, POSSONO essere sia di business che di progetto: non solo centrare sul numero e quantità dei progetti o dei PM da reclutare. Già nelle fasi di pianificazione annuale, il PMO può proporre progetti bottom-up per contributi ai target di lancio prodotto, espansione mercato, efficienza. Soprattutto nei temi efficienza, i suggerimenti migliori vengono spesso dai team o dai project manager. Il PMO, per natura cross-funzionale e anche “neutro”, può fare molto anche come collettore di suggerimenti e input dalle squadre (es. survey per raccogliere idee, anche con premi o budget interno per chi suggerisce progetti riusciti). I team si fidano dei PMO: nessuna politica, piena trasparenza, coordinamento degli OKR a tutti i livelli.

Galen Low: Mi piace moltissimo, dobbiamo assolutamente dedicarci un’altra puntata dedicata agli OKR per PMO. Sembra davvero molto interessante.

Carsten Ley: Sarebbe fantastico.

Galen Low: Carsten, grazie di cuore per il tempo che mi hai dedicato oggi. Mi sono divertito e ho imparato tantissimo. Grazie di cuore.

Carsten Ley: È stato un piacere. Grazie mille a te, Galen.

Galen Low: Bene, eccoci al finale. Come sempre, se vuoi unirti alla discussione con oltre mille appassionati di project management, entra a far parte della nostra community! Visita thedpm.com/membership per saperne di più. E se quello che hai ascoltato ti è piaciuto, iscriviti e resta in contatto su thedigitalprojectmanager.com. Alla prossima puntata, grazie per l’ascolto.