Colorare i Contorni del Progetto (Con Maik Stettner di EA Games)

Leggi la trascrizione:

Stiamo sperimentando la trascrizione dei nostri podcast con un programma automatico. Perdonate eventuali errori poiché il bot non è sempre preciso al 100%.

Ben Aston

Benvenuti al podcast DPM, dove andiamo oltre la teoria per offrire consigli esperti di project management per guidare migliori progetti digitali. Grazie per essere sintonizzati, io sono Ben Aston, il fondatore di The Digital Project Manager. Allora, diciamo la verità, sei pronto a consegnare i tuoi progetti rispettando il budget? E nei tempi previsti? Sei sicuro di riuscire a consegnare anche il perimetro che hai promesso? O non sei sicuro? Beh, come lo capisci e come lo fai? Ed è proprio di questo che parla il podcast di oggi. I controlli di progetto.

Sono davvero solo le linee che tracciamo attorno ai nostri progetti per aiutarci a conoscere i parametri del progetto. Dove dovremmo colorare. E ci aiutano a capire quando stiamo colorando fuori dai bordi del nostro progetto.

Questo episodio è sponsorizzato da Resource Guru, lo strumento di pianificazione delle risorse utilizzato da team di aziende come Apple, Ogilvy, Deloitte e Publicis. Gli ascoltatori DPM possono ottenere il 20% di sconto per tutta la durata del loro account con il codice coupon DPM2018.

Scopri di più su Resource Guru

Oggi parlo con Maik Stettner. Maik è stato appena nominato direttore dello sviluppo per EA Games, in precedenza in FCV, dove gestiva il team. È anche uno dei nostri esperti residenti DMP alla scuola The Digital Project Manager. Quando gestisci un team di PM, una cosa che ti appassiona particolarmente sono i project controls. E Maik ha molta esperienza in questo. Vuoi davvero che il tuo team rispetti i tempi e i budget. Vuoi che colpiscano quelle milestone altrimenti le cose iniziano a sfaldarsi e devi intervenire. Quindi oggi parleremo di come possiamo gestire meglio i nostri progetti e i controlli che potremmo mettere in atto. Quindi, innanzitutto, come sapere se siamo sulla strada giusta. E in secondo luogo, ci offre davvero delle opzioni per quando iniziamo a uscire dai binari.

Spero che l’argomento vi piaccia. Maik, ciao e benvenuto allo show.

Maik Stettner:

Ciao Ben. Grazie per avermi invitato.

Ben Aston:

Bentornato. Quindi, Maik, raccontaci un po’... Ora ti stai spostando o cambiando ruolo da FCV dove guidavi un team di PM a direttore sviluppo in EA games. Sai già cosa significa?

Maik Stettner:

Beh, lo scoprirò molto presto. Mi occuperò ancora di project management. Ovviamente, passando da un’agenzia ai videogame con Electronic Arts, nella mia carriera ho già lavorato in diversi settori, quindi il mondo games non è del tutto nuovo per me. Sono entusiasta di tornarci dentro. È piuttosto complesso da una prospettiva di project management. Quindi stimolante, dinamico e probabilmente dovrò usare questi controlli di progetto anche lì.

Ben Aston:

Ottimo. E hai... Pensando a cambiare ruolo e imparare nuovi strumenti e metodi di lavoro, c’è qualcosa che hai scoperto o usato di recente che dici: “Sì. Lo voglio portare nel mio nuovo ruolo.” Nuovi strumenti o approcci che hai utilizzato?

Maik Stettner:

Ho imparato che in ogni posizione in cui sono stato, ho sempre imparato nuovi aspetti e prospettive su come affrontare i problemi. Perché soprattutto quando lavori nel software o nella gestione di progetti digitali, incontri problemi simili ma ci possono essere modi alternativi per risolverli. Può essere con strumenti come issue tracker, che migliorano nel tempo, oppure strumenti che generano le analytics di cui hai bisogno per prendere decisioni rapide. Non credo di poter davvero nominare uno strumento nello specifico. Oltre ai soliti noti. Ma è interessante da notare dal mio punto di vista... Ti rendi conto che molti problemi, che tu stia costruendo una app, software desktop, sito web o gioco, sono simili. E anche l’approccio per risolverli di solito è simile.

Ben Aston:

Sì, una cosa interessante che ho scoperto ora che faccio anche consulenza, è che persino quando… Pensi di sapere il modo corretto di fare le cose e che, sia qualcosa come la gestione risorse, puoi usare un tool come Resource Guru, oppure altri strumenti come, Harvest, che ha Forecast. E pensi di sapere come gestire la nave e come tutto dovrebbe funzionare, poi provi un nuovo tool, oppure provi a usarne uno nello stesso modo in cui lo usa un’altra agenzia, e scopri che in realtà è tutta un’altra storia. Lo stesso strumento può essere usato in modi così diversi, a volte è davvero complicato.

Ma quello che dici su dati e analytics credo sia fondamentale. Una delle cose che conduce all’articolo che hai scritto riguarda proprio i project controls. Quando guidiamo un team di project manager o collaboriamo con dei PM, vogliamo essere sicuri di non basarci solo sull’intuizione o sulla sensazione che tutto sia sotto controllo. I dati sono fondamentali, vero?

Maik Stettner:

Sì, assolutamente. Soprattutto come responsabile PM, non ho sempre tutta la visibilità sul dettaglio come il PM incaricato del progetto. Quindi, mi affido molto a quei dati, vedendo come va il budget, il burn rate ecc. Questi dati mi permettono di prendere decisioni insieme ai project manager o al team sul progetto.

Ben Aston:

Esatto, questi sono essenzialmente i nostri controlli di progetto. Quando pensiamo alla gestione programmi, alla gestione di un team PM, questi sono i dati da guardare. Sono gli artefatti che i nostri PM producono. Quindi spiegaci: cos’è un project control? E cosa potrebbe essere?

Maik Stettner:

È un termine un po’ pesante. Ma per me project control descrive in pratica tutti gli strumenti necessari per ottenere le informazioni giuste e poter prendere decisioni informate. Quindi qualsiasi dato tu possa raccogliere per decidere su costi, tempi, perimetro e così via. Ovviamente è legato anche alle interazioni col cliente e a tutte quelle decisioni dinamiche che devi affrontare nel progetto. Ad esempio: il team è abbastanza grande? Mi serve qualcun altro? Siamo nei tempi? Nel budget? È insomma un quadro di alto livello per gestire i progetti e decidere consapevolmente.

Ben Aston:

Quali documenti secondo te sono i più utili per fare questo? Ci sono tanti documenti diversi che possiamo produrre. Se riduciamo ai minimi termini, quali sono i tuoi indispensabili come PM? E magari anche da program manager o delivery director?

Maik Stettner:

Il più standard che consiglio a tutti è creare un rapporto di stato onesto. Un report che contiene tutte le metriche rilevanti del progetto in corso: costi totali, budget rimanente, burn rate, traguardi raggiunti negli ultimi mesi, azioni, rischi, blocchi, decisioni. Nei casi in cui ho lavorato, produciamo report settimanali e li condividiamo sempre con il cliente. Così può prendere decisioni con piena trasparenza. È uno strumento essenziale e semplice anche per il PM per...

In pratica anche per autocontrollo, per esempio, a inizio settimana compili il report, vedi le metriche, come va il budget, dove siamo nella timeline. E da un punto di vista generale, raccogli tutto e lo condividi col cliente, magari con riunioni ricorrenti che spesso durano meno di mezz’ora. Ma che servono da check-in regolari e aiutano a costruire relazione col cliente. Può essere in remoto o di persona, che è sempre utile. Così crei fiducia e trasparenza e discutete di opportunità, problemi e blocchi nelle riunioni periodiche.

Ben Aston:

Quindi crei la documentazione e poi cerchi questi check-in regolari con il cliente. In questi meeting produci il report di stato. Ma cos’altro condividi? Da una parte cerchi di controllare il progetto internamente, dall’altra condividi quei dati con il cliente. Oltre al report di stato, quali sono i fondamentali per te nel gestire il progetto con il cliente?

Maik Stettner:

Uno strumento essenziale per mantenere il controllo complessivo sul progetto è... Può essere anche una change request, ovvero il processo di richiesta di cambiamento con appositi moduli. Ogni volta che lo scope definito esce dai binari e serve più lavoro, o il team deve adattarsi a nuove tempistiche, bisogna documentarlo. Spesso la change request fa paura perché pensi che il cliente si arrabbi, ma in realtà è normale.

Le change request non devono avere per forza impatti onerosi, a volte servono solo per documentare qualcosa, magari restando comunque nei limiti di budget e tempo. Ma è importante abituare il cliente all’idea che esiste una procedura di change: se a un certo punto ci saranno impatti di budget, è bene documentarli e avere l’approvazione di tutti su una change request.

Ben Aston:

Un altro documento che citi, sempre un project control, è il RAID log. Un aspetto importante per il controllo. Ma se dovessi scegliere un solo documento per controllare i progetti, quale sarebbe?

Maik Stettner:

Quello fondamentale è un buon rapporto di stato. Il RAID log entra più nel dettaglio e forse serve solo per progetti complessi. Ma il report di stato dovrebbe contenere già questi elementi: rischi, blocchi, ecc. Basta avere spazio per queste voci e che tutti restino aggiornati. Ma la cosa più importante sono meeting regolari e mostrare KPI e metriche chiave al cliente, illustrando lo stato attuale: quello è il mio indicatore numero uno.

Ben Aston:

Quindi è questione di equilibrio, no? Quanto controllo possiamo davvero crearci generando questa documentazione? Si torna un po’ a questo dibattito agile, o almeno come viene percepito. Non vogliamo bloccarci nella burocrazia, rischiando di limitare il progetto. Ma come trovi l’equilibrio tra il controllo e il non spendere tutto il tempo solo per monitorare il budget, aggiornare il report di stato e fare meeting? Come bilanci il troppo e il giusto?

Maik Stettner:

Da parte mia, quando mi approccio a un nuovo progetto, parto egoisticamente: parto con un aggiornamento di stato del progetto, che sia facile da produrre per me. Magari usando il software che già ho, come Resource Guru o software ore/uomo. In questo modo raccolgo le metriche di base. A seconda del cliente potrebbe servire qualcosa di più sofisticato, ma per il PM avere una panoramica interna e poter presentare qualcosa di semplice al cliente è già un buon inizio. Non ci vuole tanto tempo se lo fai regolarmente.

Non vuoi crearti troppo lavoro, perché poi rischi di non farlo proprio, soprattutto quando il progetto diventa intenso e devi dedicarti tutto alla delivery, così il reporting rischia di saltare.

Ben Aston:

Corretto, il punto è anche fare abbastanza per avere controllo senza sovraccaricarsi. Ciò che conta di più è la cadenza con cui lo fai, perché puoi avere anche il report più completo del mondo ma se poi ci metti ore a estrarre tutti i dati necessari per quel report, alla fine smetterai di produrlo e perderai il controllo sui progetti.

Maik Stettner:

Esattamente, e bisogna tenere conto che il reporting serve sia a te che al cliente. Anche il team interno ha diritto di sapere. Non ho mai fatto leggere al team il rapporto di stato così com’è, ma ho sempre trovato altri modi per trasmettere limiti di budget, tempistiche ecc. al gruppo. L’importante è avere abbastanza metriche da tenere il team allineato sul progetto.

Ben Aston:

Ottimo punto. Non è solo per il cliente, ma anche per il team. Così anche loro capiscono i vincoli. Se il progetto va di fretta, dobbiamo trovare nuove soluzioni come gruppo. Avere dati serve anche per dire: “Ragazzi, quest’anno saremo più stretti, forse non arriveremo con le stesse risorse di prima. Quindi stringiamoci e adattiamoci.”

Avere questi dati non è solo rompiscatole o da project manager: è mostrare che “Questo è il report di stato, mostra che siamo in difficoltà. Abbiamo speso troppo tempo su UX di nuovo! Su design di nuovo! Non avremo abbastanza budget per fare QA se non chiudiamo in fretta.” Qualcosa di concreto.

Nell’articolo hai parlato di come iniziare coi project controls e come usarli per controllare i progetti. Hai parlato di valutare, pianificare, reagire e connettere. Ci racconti questo processo?

Maik Stettner:

Certo. Un PM deve sempre essere informato per decidere. Quindi, inizi col valutare: dove siamo nel piano di progetto? Siamo in linea per l’output previsto? Arriveremo al nostro obiettivo? E non solo in ottica KPI: il PM deve “sporcarsi le mani”, fare domande e capire cosa fa il proprio team. Devi conoscere in superficie tutti coloro con cui lavori: UX, design, sviluppo, QA. Così puoi decidere se tagliare su certe aree o meno. Questo lo capisci solo parlando con le persone e andando in dettaglio.

La seconda fase è pianificare. Spesso bisogna cambiare, le tempistiche slittano, lo scope cambia. Sta a te pianificare i prossimi passi col team sulla base di ciò che sai. Come PM hai sempre due punti di vista: quello cliente e quello team interno, quindi devi creare quel piano maestro per portare il progetto a termine.

La terza fase è reagire: implementa i cambiamenti secondo il piano. Questo include avvisare il cliente, aggiornare la documentazione, i sistemi di issue tracking tipo Jira, aggiornare le timeline e assicurarti che le variazioni siano gestite.

L’ultima fase che ho mappato è connettere. Il PM è il collante che tiene unito il team. Tutti devono sapere quello che sai tu da una prospettiva più ampia. Quindi condividi le informazioni in modo che tutti abbiano il quadro. Il cliente deve essere al corrente, il team anche. E poi gestisci quei cambiamenti per essere sicuro che vengano davvero implementati.

Ben Aston:

Quello che sento dalle tue parole è che ci sono due aspetti. Uno è che i dati sono fondamentali: ci permettono di valutare a che punto siamo nei progetti e di prioritizzare risorse e progetti per portarli a termine. I dati ci danno quella visione generale.

Ma mi piace anche il lato umano dei controlli di progetto: cioè non sono solo numeri, ma sono il motore per iniziare conversazioni e coinvolgere il team nella discussione su come controllare il progetto, sul modo migliore per consegnarlo e adottare un approccio più agile, adattandosi in corsa. Non si tratta solo di bloccare tutto, compilare qualche report e vedere che sforiamo il budget, ma di rendere la cosa un dialogo.

Per chi non ha mai prodotto report di stato per il cliente o per i progetti, hai appena descritto il processo. Ma quale dovrebbe essere il primo passo per portare sotto controllo i propri progetti? Anche senza arrivare subito a un report strutturato, quale consiglio daresti ai PM per cominciare?

Maik Stettner:

Per me è farsi un’idea chiara di cosa serve per consegnare. Dal lato cliente—e a volte sono cose logistiche molto semplici—quali sono le aspettative del cliente? Ci sono driver particolari? Una data fissata per finire? Per una campagna? Una presentazione? E anche internamente, avere chiaro il team necessario e come funzionerà. Da una visione di alto livello capirai come mettere tutto insieme. L’esperienza aiuta, come project manager ti abitui a individuare il piano generale e i checkpoint da tenere d’occhio.

In definitiva, il report di stato serve soprattutto a tenerti sulla buona strada, a non dimenticare quei checkpoint. È questo il punto chiave: una combinazione di KPI, competenze relazionali e una visione sempre lucida sul progetto. Così sai sempre dove ti trovi, anche se il progetto è complicato. Poi puoi decidere quali strumenti usare per aiutarti nelle scelte.

Ben Aston:

Hai ragione, i dati da soli non servono se non li confronti con qualcosa. Se tiri fuori report senza avere un piano da cui partire, quei numeri sono privi di significato. Quindi, avere un piano prima di tutto, poi puoi misurarti su quello. Quello che noto spesso parlando con PM di altre agenzie è che spesso mancano i timesheet, e non si tiene traccia del tempo sulle varie attività di progetto. Anche se il time tracking è forse l’attività più odiosa, introdurlo se non c’è ti permette di collegare il lavoro al piano progetto. E poi ti dà un po’ di controllo sul progetto. Ottimo consiglio, grazie Maik, è stato un piacere averti con noi.

Maik Stettner:

Grazie a te, Ben.

Ben Aston:

Come uno dei nostri esperti DPM, Maik parteciperà al nostro prossimo corso che parte a settembre. Si chiama Mastering Digital Project Management. È un corso intensivo di sette settimane sulla gestione di progetti digitali complessi. Imparerai a gestire progetti digitali in modo efficace. Il corso include video, compiti, discussioni di gruppo e opzionalmente sessioni di coaching. Vai su thedpmschool.com e iscriviti, ci sono ancora pochi posti. Il corso inizia il 10 settembre. Ma se vuoi contribuire anche tu alla discussione sui project controls, come possiamo controllare meglio i nostri progetti? Che tipo di documentazione usi? Vai nella sezione risorse di thedigitalprojectmanager.com per entrare nel nostro team Slack, dove troverai tante discussioni interessanti. Commenta il post, partecipa su Slack e confrontiamoci su come controllare meglio i nostri progetti.

Ma fino alla prossima volta, grazie per l’ascolto.