Costruire e Far Crescere Team di Project Management (con Brian Kessman di Lodestar Digital)

Leggi la Trascrizione:

Stiamo provando a trascrivere i nostri podcast utilizzando un programma software. Perdonate eventuali errori, il bot non è corretto al 100% del tempo.

Ben Aston:

Ciao, grazie per averci sintonizzato, sono Ben Aston e questo è il podcast del digital project manager. Oggi sono con Brian Kessman e parleremo dell’articolo che ha appena scritto per noi su come costruire e far crescere team di project management digitale all’interno di un’agenzia. Ma prima di parlare del tuo articolo Bryan, perché non ci racconti qualcosa di te?

Brian Kessman:

Certo, prima di tutto grazie per avermi nel tuo podcast e per l’invito a scrivere il post sul blog, mi è piaciuto farlo. Io sono a Chapel Hill, North Carolina, originario di New York, cresciuto a Long Island, poi vissuto per qualche anno a Manhattan ma ora siamo qui stabilmente e attualmente gestisco una società di consulenza, Lodestar Digital, questo è il mio lavoro.

Ben Aston:

Bene, allora parlaci un po’ di Lodestar, di cosa si occupa Lodestar?

Brian Kessman:

Certo. Lodestar è un gruppo di consulenza. L’obiettivo è aiutare le agenzie digitali e creative a costruire e migliorare i loro servizi digitali, il che significa che nel mio lavoro posso aiutare le agenzie con cose come cambiamenti nell’organizzazione o nella struttura del team, tutto al fine di offrire un lavoro digitale migliore. Creare magari nuove discipline digitali, come il project management digitale, e scalare o ottimizzare il workflow. A volte si tratta di implementare pratiche agile, ma più in versione modificata per il settore creativo. Queste sono in sintesi le aree di servizio.

Ben Aston:

Ottimo, quindi ora fai consulenza in questo campo, ma come sei entrato nel project management digitale e nell’aiutare le agenzie a fare questo? Qual è il tuo background?

Brian Kessman:

Ho iniziato a interessarmi di project management molti anni fa quando facevo consulenza tecnologica, dopo aver lavorato nel settore pubblicitario, ma mi sono preso una pausa per la consulenza tech ed è lì che sono stato introdotto al project management. Quando sono tornato nel mondo delle agenzie ho potuto applicare quelle competenze. Negli ultimi 17/18 anni ho lavorato principalmente in agenzie digitali o in ruoli digital in agenzie tradizionali.

Questa è la panoramica della mia esperienza, ma negli ultimi 10 anni mi sono concentrato su come migliorare processi e delivery nelle agenzie, sviluppo di siti web, app e simili. Ho visto principalmente problemi di crescita: le agenzie in cui ho lavorato erano sempre piccole o medie, e crescendo vedevo ricorrere schemi tipici che ero in grado di risolvere. Così ho scelto di aiutare altre agenzie oggi con quei problemi. Il lavoro digitale nelle agenzie è aumentato tantissimo e molti fanno ancora fatica, sia perché devono affrontare il digitale per la prima volta, sia perché stanno crescendo e hanno bisogno di rafforzarsi su quei temi.

Ben Aston:

Sì quindi aiuti soprattutto le agenzie tradizionali a diventare digitali e crescere. Quali sono le sfide più tipiche che incontri in questo processo? Sicuramente chi ci ascolta riconoscerà alcuni di questi problemi!

Brian Kessman:

Sì, penso che la causa principale di molte difficoltà all’interno di un’agenzia creativa sia ancora un approccio un po’ a compartimenti stagni tra discipline, dove il lavoro viene “passato di mano” da un team all’altro senza vera collaborazione. Non è più come una volta ma succede ancora, soprattutto nelle agenzie grandi e tradizionali. Quindi propongo il modello del team cross-disciplinare, sia fisso che temporaneo, dove si lavora insieme, c’è trasparenza, ognuno capisce meglio il ruolo degli altri, e questo fa crescere la consapevolezza e le skill digitali di tutti.

Un esempio: magari un designer lavora al sito ma non ha un approccio digitale, quindi dimentica aspetti come il responsive, così quando il lavoro passa allo sviluppatore serve rifare molte cose.

Ben Aston:

Sì, situazione familiare! Capita spesso che qualcuno non abbia mai fatto un sito prima e usa formati assurdi, e ci si ritrova a dire “ferma, così non si fanno i siti…” sono dettagli che spesso sfuggono.

Brian Kessman:

O tipo ti danno la creatività per un cartellone pubblicitario, ma non pensano a come sarà la landing page collegata.

Ben Aston:

Esatto: prendi il cartellone, buttalo su una landing con un bottone, no? Bene, parliamo ora del project management digitale: tu offri consulenza alle agenzie per migliorare. Quali sono gli strumenti principali della tua cassetta degli attrezzi? C’è qualcosa che hai scoperto di recente che consigli assolutamente?

Brian Kessman:

Ultimamente mi sono appassionato a Designbetter.co, un servizio lanciato da InVision. Aiuta le persone a migliorare le practice di design, non solo dal punto di vista digitale ma per risolvere problemi di business. Hanno podcast, blog post e corsi email, tutti da grandi leader del design: una risorsa fantastica per capire come costruire grandi prodotti e team. Lo consiglio, a prescindere dal ruolo, è un contenuto ricco. Questo per l’aggiornamento e la crescita personale; nel mio lavoro – che è consulenza più che project management operativo – gli strumenti principali sono workshop, interviste, sondaggi, mappature degli stakeholder per capire le relazioni interne, process mapping, skills gap analysis e la skills matrix di cui parlo nel blog post.

Ben Aston:

Ottimo. Tornando sugli strumenti, tutti amano i tool. Quando aiuti le agenzie a focalizzarsi sul digitale e lavorare insieme, ci sono strumenti che fanno davvero la differenza per superare la logica a silos e favorire la collaborazione?

Brian Kessman:

Certo. Si tratta soprattutto di software di gestione dei workflow. Ce ne sono tantissimi. Dipende da quello con cui l’agenzia si trova meglio. Per esempio JIRA è ottimo per lo sviluppo software, molte agenzie lo usano anche per il creativo. Ma la chiave è creare trasparenza e fluidità nel lavoro collaborativo.

Ben Aston:

Perfetto. Passiamo al tuo articolo: parla di come far crescere i team di project management digitale nel modo giusto. Se non l’avete ancora letto fatelo, è una guida passo-per-passo utile per tutti, anche se non state attualmente creando un team: molte cose sono utili comunque, basta applicarle alla propria scala. Brian parla delle cinque “P” per scalare un team PM: purpose (scopo), people (persone), partnerships (partnership), process (processi), performance (prestazioni).

Purpose è mettere insieme gli stakeholder per definire il perché della crescita, people trovare le persone giuste con le skill giuste e le retribuzioni adatte, partnerships riguarda le partnership interne e la struttura del team, process vuol dire avere strumenti e template per essere coerenti e creare valore, performance è monitorare e apportare continui miglioramenti. Ho fatto un riassunto, ma leggete l’articolo per approfondire.

Ora ci concentriamo sul primo di questi: lo scopo, cioè il perché esistono team di project management digitale. Spesso le persone si trovano a ricoprire questo ruolo senza che sia davvero stato definito il perché. Lo vediamo spesso nel nostro team Slack: “Mi hanno appena nominato project manager digitale, che devo fare?” Di solito capita dopo qualche problema. Quando i progetti digitali non funzionano, sforano il budget, sono sempre in ritardo, serve qualcuno a cui demandare – e così ti affibbiano il ruolo. Secondo te quali varianti ci possono essere sullo scopo del project management digitale in un’agenzia?

Brian Kessman:

Secondo me la variazione non sta tanto nello scopo, quanto in come viene espresso. Il nocciolo è lo stesso: spesso il problema è che nessuno si è preso il tempo di definirlo. Se vieni catapultato nel ruolo senza che sia chiara la missione nessuno sa cosa aspettarsi, e mancano supporto e risorse. Quindi non cambia il core, cambia la cura messa nel definirlo.

Ben Aston:

Io stesso ho creato team di PM digitali: il problema è bilanciare lo status quo precedente con la nuova cultura digitale e solitamente si parte piccoli e bisogna scalare. Come si evita di strafare e trovarsi sopraffatti? Come suggerisci di affrontare questa fase?

Brian Kessman:

Ogni step fa parte di un sistema: se definisci bene il purpose, diventa più facile il passo successivo, che è la specializzazione. Devi concentrarti su quale valore e quali risultati porti davvero nel ruolo, mantenendo il focus sulla tua specializzazione. Ad esempio, produrre progetti di successo riducendo rischi e criticità attraverso la pianificazione, questo è il purpose tipico di un PM. L’outcome è avere progetti di successo, il valore aggiunto è la riduzione del rischio, la specializzazione su cui restare focalizzati è proprio la pianificazione di progetto – restando in quell’ambito non si rischia di farsi carico di troppe cose.

Ben Aston:

Chiaro. Ora passi a parlare di persone, è cruciale avere la persona giusta a guidare il team. Come identifichi i leader? Chi ci ascolta potrebbe voler emergere come responsabile del PMO: quali competenze servono e come le si sviluppa?

Brian Kessman:

Serve un mix di competenze tecniche (hard skills) e soft skills. Serve esperienza “sul campo”, ma soprattutto servono abilità di leadership vera: saper ispirare e motivare il team. Devi comprendere i punti di vista e i ruoli degli altri, avere empatia e sostenere le persone nel loro percorso. È una leadership di servizio: non fai tu direttamente, ma aiuti gli altri a fare, rimuovendo ostacoli e offrendo supporto. Dargli gli strumenti e l’incoraggiamento per crescere è parte integrante dell’essere un grande leader.

Ben Aston:

Sono d’accordo. Dici che il leader deve passare anche il 50% del tempo a supportare e fare mentoring. Chi pensa “ma io non dedico tutto questo tempo a supportare il team”: in cosa consiste per te concretamente il mentoring a un team di PM?

Brian Kessman:

Credo sia soprattutto “esserci” e attraverso la conversazione cogliere dove sono le difficoltà (anche inconsapevoli). Questo può avvenire con one-to-one settimanali o mensili – magari un caffè o a pranzo – con ciascun PM. L’altro lato sono attività più tecniche: revisionare report di stato, forecast, stime, timeline e partecipare a incontri come kick-off per osservare il comportamento.

Osservare e dare feedback è fondamentale: serve anche la skills matrix menzionata nell’articolo. Così puoi mappare le competenze di ciascuno e dare riscontro pratico (“ecco perché su questa skill ti ho dato questo punteggio. Tra sei mesi dovresti essere qui, lavoriamoci insieme”). Questo rende il mentoring davvero efficace.

Ben Aston:

Fantastico. Parli anche di sviluppo professionale per i DPM: quali sono secondo te i percorsi di crescita più utili? PMP, Scrum Master, altre certificazioni... cosa vale davvero la pena?

Brian Kessman:

Risposta doppia: uno basato sull’esperienza personale, uno più generale. Personalmente ho studiato per il PMP ma non ho sostenuto l’esame: ho imparato ciò che serviva, la certificazione sarebbe stata solo un elemento in più sul CV. Ho invece seguito la formazione per Scrum Master e Product Owner e la trovo fondamentale: davvero tutti dovrebbero farla, perché l’approccio agile cambia radicalmente la prospettiva. È il futuro del settore. Anche altre competenze sono utili: conoscere le basi delle discipline collegate al PM (design, sviluppo...) aiuta a lavorare meglio e supportare efficacemente i colleghi. Quindi sporcatevi le mani con un po’ di coding oppure ascoltate i podcast di InVision: sono consigli ottimi per ampliare la propria comprensione dei team.

Ben Aston:

Giustissimo, più un PM comprende il lavoro dei propri team, meglio saprà anticipare problemi e guidare verso il risultato. È davvero utile anche solo saper porre le domande giuste grazie a un minimo di conoscenza delle discipline coinvolte.

Brian Kessman:

Sì, hai citato la strategia, grande tema. I PM spesso lavorano a stretto contatto con designer e sviluppatori e forse hanno già esperienza su quei fronti, ma molto meno spesso con chi si occupa di strategia. Se si riesce a interfacciarsi di più con quel team, si fa decisamente un salto di qualità nella gestione dei progetti, mantenendoli allineati allo scopo strategico. Molti PM non ci lavorano abbastanza, almeno per quanto ho visto finora.

Ben Aston:

Certe funzioni sono compartimentate: strategia magari è in mano all’account director prima che il progetto passi di mano al PM, ma per un PM è vitale capire la strategia sottostante e assicurare che si raggiungano gli obiettivi del cliente. Il lavoro strategico aiuta anche ad “aggiustare” dove serve, per avere risultati concreti.

Tornando alla skills matrix: è un ottimo template, ma come si decide per esempio cosa richiedere, tipo nella pianificazione di progetto, ai diversi livelli? Come suddividi le skill?

Brian Kessman:

Dipende dall’agenzia, dalla complessità e dal tipo di clienti. Alcune non hanno livelli entry-level, solo senior. Serve lavoro di squadra: non dovrebbe essere il director a imporre tutto, ma un lavoro condiviso per parlare del tipo di lavoro, delle aree critiche, delle opportunità, delle skill da coprire. Più si coinvolge il team, più c’è buy-in e tutti capiscono che non è una valutazione negativa ma uno strumento di crescita e miglioramento.

Ben Aston:

Molto utile, grazie. Parliamo anche di assunzioni: spesso HR dice “non abbiamo budget per un senior”, ma di solito un team leader vuole almeno una persona senior. Consigli su come assumere rientrando nel budget?

Brian Kessman:

Ecco perché la skills matrix è così importante: serve a creare una comprensione condivisa delle capacità di ogni livello. Così puoi motivare la richiesta di un senior in base alle competenze davvero necessarie per progetti o clienti particolari.

Se coinvolgi HR e anche il finance nella definizione della skills matrix, puoi definire i range salariali per ogni livello, confrontando le tariffe di mercato. Se si fa questo lavoro a monte il confronto sul budget sarà molto più facile e trasparente, ognuno sa già qual è la logica che guida la richiesta di un profilo senior e con quali costi.

In sostanza, quello strumento può fare davvero la differenza.

Ben Aston:

Sono d’accordo: spesso invece è più utile affiancare un junior a un senior, così il senior può dedicarsi alla parte più strategica lasciando al junior attività operative come l’aggiornamento degli status report e delle timeline. La terza P erano le partnership: tutto sulle relazioni in agenzia. Cosa è una RACI matrix e quanto vai nel dettaglio nella mappatura dei ruoli?

Brian Kessman:

Assolutamente: crea una RACI è molto impegnativo e va fatta con il coinvolgimento di tutte le discipline. Sostanzialmente si mappano le fasi o i passaggi chiave del processo agenziale, scegliendo il livello di dettaglio appropriato (meglio non esagerare). RACI sta per Responsible, Accountable, Consulted, Informed: ogni step vedi chi è responsabile (fa il lavoro), chi accountable (ne assicura la buona riuscita), poi consultati e informati sono chiaro. Per esempio, se il designer deve prendere una decisione che tocca scopo o tempi, deve consultare il PM. Va costruito passo a passo, aggiungendo dettaglio solo se necessario con il tempo.

Ben Aston:

Ottima spiegazione. Ma come si evita di dover coinvolgere troppe persone (consulted/informed) in ogni passo del processo? Come si ottimizza senza coinvolgere tutti a ogni meeting?

Brian Kessman:

In realtà è un ottimo problema: significa che tutti sono motivati e ci tengono. Ma bisogna semplificare: non si può avere 20 persone a ogni riunione! Qui tornano utili i tool di workflow management software: con questi si creano trasparenza e si manda un messaggio o una notifica quando una decisione viene presa o è in corso. Consultare o informare può avvenire tramite tool, automatizzando le notifiche (email ecc.). Questi strumenti risolvono molti di quei problemi strutturali e riducono la necessità di coinvolgimenti fisici continui.

Ben Aston:

Utile! Passiamo alla P preferita dei PM, il process: come si standardizza il processo in agenzia quando i progetti sono molto diversi, ad esempio la mattina si segue un progetto di service design e il pomeriggio un restyling sito web? Come trovare il giusto livello di personalizzazione e standardizzazione?

Brian Kessman:

In parte dipende dalla scelta strategica agenziale di specializzarsi su verticali chiari: se lo fai puoi davvero standardizzare processi su tipologie note. Ma anche senza questa scelta, dovresti comunque identificare pattern e raggruppare progetti simili, standardizzando quello che puoi. In pratica, anche chi non è “specialista” almeno qualche processo ripetitivo ce l’ha: da lì si parte per ottimizzare e rendere scalabile ciò che si ripete.

Ben Aston:

Concordo. Io di solito costruisco il processo standard partendo dal tipo di progetto più complesso, poi ricavo da lì tutto il resto, per i progetti più semplici prendo solo la parte che serve. Così quando si ripresenta qualcosa di nuovo nessuno si perde e si mantengono efficienza e controllo su tempi e costi.

Questa standardizzazione porta tanta efficienza, specie per le agenzie che non sono specialist ma gestiscono molti tipi di progetti: senza processi ricorrenti la confusione regna e i progetti sforano sempre. Un macro-processo da cui estrarre solo ciò che serve per le situazioni particolari è fondamentale.

Brian Kessman:

Assolutamente d’accordo.

Ben Aston:

Infine, performance: spesso trascurata. Ogni quanto si dovrebbe controllare le performance e come misurare efficacemente il miglioramento?

Brian Kessman:

Ancora una volta: partire in piccolo. Scegli uno o due indicatori chiave (KPI) su cui focalizzarsi: turnaround medio, project on-time rate, profittabilità... Quelli sono obiettivi “hard”, facili da monitorare. Per gli obiettivi “soft” invece, ti suggerisco survey interni (almeno trimestrali) per misurare il clima interno, la soddisfazione rispetto ai processi e all’esperienza. Dai risultati ogni trimestre, decidi cosa migliorare per il trimestre successivo. Anche le survey ai clienti sono potenti: il net promoter score (NPS) è uno strumento utilissimo (“ci raccomanderesti?” + campo per feedback qualitativo). Serve a misurare non solo la crescita interna ma anche il valore reale che dai al cliente – se il cliente resta, stai crescendo davvero.

Ben Aston:

Hai consigli pratici per ottenere risposte alle survey, specie sull’NPS? Le persone generalmente odiano le survey...

Brian Kessman:

Serve sempre la relazione: la survey è importante, ma ancora di più parlare direttamente col cliente, mostrare che ci tieni alla partnership, non solo ai dati. Se non rispondono al form, chiamali direttamente: una relazione solida lo permette. Strumenti mobile-friendly aiutano ovviamente, ma molto passa dal rapporto personale e dalla fiducia.

Ben Aston:

Perfetto! Brian, grazie mille per essere stato con noi, è stata una discussione molto importante su come costruire e far crescere team di PM. Grazie ancora!

Brian Kessman:

Piacere mio, grazie Ben!

Ben Aston:

Se volete commentare partecipate sul post o nella community del sito thedigitalprojectmanager.com, dove trovate tantissime discussioni interessanti, o per entrare nel nostro team Slack. Alla prossima e grazie per l’ascolto!