Avvia i Tuoi Progetti nel Modo Giusto (con Suze Haworth)

Leggi la Trascrizione:

Stiamo sperimentando la trascrizione dei nostri podcast tramite un programma software. Perdona eventuali errori: il bot non è sempre preciso al 100%.

Ben Aston:

Benvenuti al podcast DPM dove andiamo oltre la teoria per offrire consigli PM esperti per gestire meglio i progetti digitali. Grazie per esservi sintonizzati. Sono Ben Aston, fondatore di The Digital Project Manager.

Come sappiamo, l'inizio di un progetto è davvero cruciale per il suo successo, ma può anche essere un momento molto delicato. C'è tanta ambiguità. C'è confusione. Ci sono disaccordi e molta incertezza. Come PM, è il nostro compito far partire il progetto e mantenerlo in movimento, con un valore aggiunto se riusciamo effettivamente a indirizzare subito il progetto nel verso giusto. Ma cosa possiamo fare concretamente per assicurarci di procedere nella giusta direzione? Per partire col piede giusto? È proprio di questo che parleremo oggi. Continua ad ascoltare per scoprire come puoi fare in modo che i tuoi progetti partano bene.

Oggi sono con Suze Haworth. Ciao, Suze.

Suze Haworth:

Ciao.

Ben Aston:

Suze è una delle nostre esperte residenti di DPM su The Digital Project Manager. Lavora come project manager digitale senior freelance a Londra. Suze, vuoi raccontarci qualcosa di alcuni dei progetti su cui hai lavorato recentemente?

Suze Haworth:

Sì, sono una PM freelance. Recentemente, alcune settimane fa, ho concluso un contratto, ma è stato un contratto a lungo termine in agenzia. Ho ricoperto due ruoli chiave: uno più da direttore di programma su un account, per la Specsavers, grande marchio retail di occhiali nel Regno Unito, presente anche nei Paesi Nordici e in Australia. Gestivo un PM senior per tutto l’aspetto creativo e UX di Specsavers digitale: quindi un programma di lavoro piuttosto esteso. E inoltre ho lavorato su un progetto per Ikea: era un progetto di design e realizzazione di un prototipo per un design system per il brand.

Ben Aston:

Interessante. Su Specsavers, era più un progetto di e-commerce e ottimizzazione della conversione?

Suze Haworth:

Sì, dipendeva molto dal mercato, ma in realtà tendono a non vendere occhiali online, solo per alcune normative. Gran parte del lavoro era finalizzato a portare le persone a prenotare appuntamenti e andare nei negozi fisici. Ma sì, è tanta ottimizzazione della conversione, proprio come dici.

Ben Aston:

Cosa c'era di difficile in quei progetti? Quali sono state alcune delle sfide affrontate, sul progetto stesso, col cliente o col team? Penso sia sempre interessante sentire che anche altri hanno problemi simili. Quindi, cosa ti ha messo alla prova?

Suze Haworth:

Sul programma Specsavers, era un momento veramente interessante perché ho iniziato a marzo, l’inizio dell’anno nuovo, e abbiamo cambiato completamente modalità di lavoro. In precedenza collaboravamo come agenzia di design con la loro agenzia di sviluppo e partecipavamo ai loro team scrum: c’era un abbinamento designer e UX in ciascun team scrum per ogni workstream. Abbiamo poi deciso di togliere designer e UX da questi team scrum, di riunirli in un unico team interno. Siamo poi passati a un processo dual-track: gestivamo una discovery track quasi sopra la delivery track, che era la parte più scrum di sviluppo.

Così potevamo dedicarci a test con utenti, esplorazioni, ipotesi e verifiche, e fare più ricerca e raccolta dati. Avevamo più margine di manovra per fornire risultati davvero utili agli utenti. Introdurre questa nuova modalità e attivarla è stata una bella sfida, ma anche entusiasmante.

Ben Aston:

Quindi il tuo ruolo era… di chi era la responsabilità? Il product owner? Avevate due workstream paralleli, uno per strategia, UX e design, penso quelli impegnati nei test utente per identificare i bisogni, poi prioritizzati e portati a UX/design, e infine in sviluppo. Funzionava così?

Suze Haworth:

Sì, ciò che succedeva è che designer e UX inseriti nello scrum faticavano: in due settimane era difficile rispettare le scadenze e si finiva spesso a seguire aspetti tecnici, riunioni di pianificazione sprint, bug, ecc., anziché pensare ai bisogni reali dei clienti. Spostarli su una track a parte ci dava tempo per analizzare dati, ipotizzare soluzioni alle criticità dei clienti, prototipare e testare rapidamente. Solo le soluzioni validate entravano in delivery. Così si snelliva la produzione e non si creavano funzionalità che i clienti non vogliono. Coinvolgevamo comunque persone tecniche nella discovery, per controllare fattibilità tecnica, ma sempre dopo aver validato i desideri dei clienti. Insomma, l’obiettivo era ottimizzare processo e concentrare lo sforzo su quello che davvero serviva.

Ben Aston:

Credo che questo sia un problema comune a molte agenzie che provano a fare scrum. Scrum non è l’unico approccio a un progetto agile, ma spesso è visto come unica via. Una delle grandi sfide è capire cosa dovrebbero fare UX e designer nello sprint. O stanno due sprint avanti agli sviluppatori e allora non si conclude nulla; oppure si tenta di finire una funzione nell’arco di due settimane – e risulta quasi impossibile passare da strategia a design e sviluppo così rapidamente.

Quindi mi piace l’idea di gestire due workstream paralleli e validare certe soluzioni che poi entrano nello sprint di sviluppo. Così hai due backlog: uno strategico – stiamo facendo la cosa giusta? – e uno di sviluppo – ora sappiamo cosa dobbiamo fare, costruiamolo. Risolve molte problematiche davvero.

Suze Haworth:

Esatto. Così realizzi solo funzionalità che i clienti hanno validato e riduci gli sprechi. Il processo è molto più snello, il che è un gran vantaggio.

Ben Aston:

Bene. Parliamo dell’avvio dei progetti. Sono curioso di sapere per Ikea o Specsavers: sei stata coinvolta dall’inizio?

Suze Haworth:

Per Specsavers, abbiamo definito questa nuova modalità di lavoro col team assegnato per l’anno. Sono arrivata dopo che il modello di lavoro era stato abbozzato e lo scope scritto. Una delle sfide – come dico nel mio articolo – è subentrare in un progetto già avviato o con lo scope scritto da altri. In questo caso sono arrivata poco dopo la stesura dello scope e del modello di lavoro, che avevano bisogno di adattamenti: infatti il modo di lavorare è poi cambiato abbastanza rispetto all’idea iniziale, perché emergono sempre aspetti da sistemare lavorando realmente sul campo.

Per il progetto Ikea, invece, ho iniziato dalla seconda fase e quindi ero subentrata a progetto già partito.

Ben Aston:

E spesso, come PM, ereditiamo progetti già avviati – aumenta confusione e incertezza, perché prendi in mano qualcosa già pianificato da altri, magari non in modo dettagliato. In questo contesto, avviare il progetto equivale anche a prendere il timone in un momento qualsiasi. Parliamo quindi delle cose da gestire: persone, processi, prodotto e come ottenere chiarezza e allineamento su questi fronti – cioè su chi, come e cosa. Quando entri su un progetto, da dove parti dal punto di vista delle persone?

Suze Haworth:

Ci sono alcuni gruppi principali a cui pensare in un progetto. Innanzitutto il team: chi lavorerà sul progetto? In questa fase si definiscono e prenotano le persone, valutando disponibilità ma anche competenze, abitudini di lavoro, tipologia del progetto e del cliente.

Se si conoscono i membri del team, meglio ancora capire chi può andare d’accordo e collaborare al meglio. Non sempre si ha questa libertà, a volte si prende chi è disponibile, ma già sapere come lavorano aiuta a evitare problemi in futuro.

Fondamentale è coinvolgere le persone fin dall’inizio. Dalla mia esperienza, la cosa che designer, sviluppatori o QA detestano di più è essere coinvolti a progetto già definito e sentirsi dire semplicemente “disegna questo” o “costruisci quello”, senza partecipare alle decisioni. Questo porta a problemi futuri.

Quando tempo e budget lo consentono, è bene coinvolgerli anche solo marginalmente fin dai primi momenti: dopo la riunione di kickoff interna, confrontarsi sulle aspettative, raccogliere idee e dubbi.

Ben Aston:

Sì, coinvolgerli fin dall’inizio è importante: per gestire le risorse serve selezionare chi si vuole nel team e motivarli subito, così sentono il progetto come loro. Le persone sono più coinvolte e si ottengono risultati migliori se sentono di possedere il progetto, non se devono lavorare su idee non proprie.

Suze Haworth:

Esattamente.

Ben Aston:

Passiamo al processo. Una volta che hai formato il team, come lo usi per realizzare il progetto? Capita spesso che il team sia in disaccordo sul processo, sulla metodologia, sugli strumenti. Come ottieni l’allineamento necessario?

Suze Haworth:

Non troverai mai un processo ideale per tutti. Capitano sempre delle tensioni. Talvolta il processo ti viene imposto dall’agenzia o dal cliente; altre volte puoi definirlo tu. In ogni caso, è utile spiegarlo e motivarlo nella riunione di kickoff interna, ottenendo l’adesione del team.

Ma altrettanto importante è adattare il processo strada facendo: se qualcosa non funziona, bisogna avere la capacità di intervenire, ascoltare il team, accogliere suggerimenti e apportare i cambiamenti necessari.

Ben Aston:

Flessibilità è la chiave. Spesso i PM o i team sono rigidi: “così non si fa scrum”, “troppo agile”, “troppo a cascata”. Conta poco l’etichetta: occorre scegliere ciò che funziona meglio per team, progetto e cliente. Con progetti diversi è praticamente impossibile standardizzare tutto, a meno che non si tratti di semplice manutenzione.

Abbiamo dunque parlato di chi (team e stakeholder), del come (processo e flessibilità). All’inizio del progetto, spesso il cosa – ovvero cosa si sta facendo/consegnando – è la parte più ambigua, specie se erediti un scope o dei requisiti poco chiari. Come affronti questa situazione?

Suze Haworth:

Dipende dal tipo di progetto. Idealmente, uno scope non troppo rigido lascia spazio ai cambiamenti futuri. Ma per chiarire occorrono conversazioni frequenti con il cliente per raccogliere esigenze degli utenti e obiettivi business, capendo il contesto.

Poi occorre coinvolgere il team per affinare i requisiti e definire i parametri del progetto, anche solo con i responsabili di disciplina se il team non è ancora costituito.

Ben Aston:

In quei primi incontri cerco di riunire tutti in una stanza e, con post-it e lavagna, abbozziamo ad alto livello la soluzione. Serve per ottenere una comprensione condivisa: spesso ognuno pensa a cose diverse! Visualizzare serve a far emergere dubbi e ambiguità e a chiarire le idee da portare poi al cliente.

La panoramica d’insieme (“questo è il progetto”) scattata sulla lavagna viene poi richiesta e utilizzata nei mesi, per ricordare visivamente il quadro generale.

Formalizzare un’architettura anche solo ipotetica aiuta a delimitare il campo e ad allineare le aspettative, soprattutto dove c’è incertezza sulla portata del lavoro. Bloccare la “tela” iniziale aiuta molto nel discovery successivo.

Suze Haworth:

Assolutamente. Workshop di questo tipo sono molto utili, anche con il cliente: così si chiariscono reciprocamente le idee e si inizia il progetto nel modo giusto. Fare una sessione interna e poi una col cliente, magari da mezza giornata, è molto efficace.

Ben Aston:

Quindi abbiamo visto i fronti da gestire: il chi, il come e il cosa. E, parallelamente, possiamo iniziare a delineare budget, tempistiche, metriche di successo. Mettere tutto su una lavagna, anche se cambierà, aiuta enormemente.

A volte però la fase di avvio può iniziare prima che il progetto venga ufficialmente approvato: quanto è giusto spingersi avanti? Sei prudente o preferisci rischiare per recuperare tempo? Come gestisci questa tensione tra avanti tutta o attesa?

Suze Haworth:

Tendo a essere più cauta e a essere trasparente: se il cliente ritarda a firmare o a confermare lo scope, lo informo dei rischi sugli slittamenti. È importante che il cliente sia consapevole delle conseguenze delle indecisioni.

Comunque, anche con cautela, è bene mantenere un po’ di avanzamento: basta poco per non perdere slancio; coinvolgere il team, lavorare sulle idee, mantenere l’entusiasmo è fondamentale. Se ci si blocca, le persone rischiano di perdere interesse. Quindi è bene non fermarsi del tutto.

Ben Aston:

Una delle tipiche sfide è la mancanza di slancio iniziale: se il progetto stagna, cosa fai?

Suze Haworth:

È difficile, specialmente se le persone sono già bloccate sul progetto ma manca l’approvazione ufficiale. Se c’è comunque un po’ di tempo a disposizione, conviene usarlo per iniziare a raccogliere dati, studiare i competitor, fare ricerche preliminari: serve a mantenere un coinvolgimento, anche minimo, fino al via ufficiale.

Ben Aston:

Anche solo una riunione rapida aggiorna il team (“non partiamo questa settimana ma questa è la situazione!”): evita che il progetto cada nell’oblio.

Suze Haworth:

Peggio di tutto è restare in silenzio e, dopo settimane, ricomparire chiedendo di partire. Tenere il team informato sui retroscena o le cause del ritardo è sempre utile: aiuta a mantenere vivo l’interesse.

Ben Aston:

Parliamo ora del subentrare a progetto già avviato – un problema comune per molti project manager: erediti un piano fatto da altri ma poi la responsabilità passa a te. Come affronti questo scenario?

Suze Haworth:

Questa è forse la sfida maggiore perché raramente si segue un progetto dal pitch in avanti: di solito si subentra dopo la stesura dello scope e delle prime decisioni. Spesso capiterà di avere un budget fissato e uno scope vago, e dover farli quadrare. Quindi il primo punto è valutare dove c’è margine per adattare deliverable, tempistiche o budget, spiegando subito se qualcosa non è realistico rispetto alle premesse fatte da altri.

Se erediti un progetto già avviato da un altro PM, ci sono due cose fondamentali: raccogliere tutte le informazioni possibili (su ciò che è già stato fatto, sul cliente, ecc.) e fare quasi un azzeramento, un mini-kickoff, anche se il progetto è a metà. Coinvolgere il team e il cliente in un nuovo incontro di partenza aiuta a chiarire dubbi, vedere cosa ha funzionato e cosa va cambiato. Non serve che duri troppo: l’importante è segnare il passaggio di consegne e trasmettere un nuovo slancio.

Ben Aston:

Il reset – avere il coraggio di azzerare e fare domande anche banali – spesso smuove problemi latenti. Più un progetto va avanti, più aumentano le assunzioni non documentate e le incomprensioni. Fare domande, anche ingenue, spesso fa uscire punti oscuri e potenziali problemi che altri ignoravano. Può davvero essere utile.

Suze Haworth:

Mai avere paura di fare tante domande: lo dico spesso ai nuovi PM. Meglio chiedere subito, anche a costo di sembrare poco preparati, che tacere e trovarsi sorprese dopo!

Ben Aston:

Questo è forse il consiglio più importante per l’avvio dei progetti: la comunicazione apertissima. Fare anche le domande difficili e fastidiose che però portano chiarezza e permettono di far girare il progetto più fluidamente e senza sprechi. Grazie mille, Suze, per essere stata con noi.

Suze Haworth:

Grazie a voi, è stato un piacere.

Ben Aston:

Come esperta DPM, Suze sarà presente anche nel nostro prossimo corso – parte a febbraio: si chiama “Mastering Digital Project Management” ed è un corso intensivo di sette settimane con lezioni video interattive, panel di discussione e la possibilità di sessioni di coaching. Se vuoi capire meglio come avviare un progetto in modo efficace, vai su DPMSchool.com e iscriviti prima che si riempia! Se vuoi unirti alla discussione sull’avvio dei progetti, commenta questo post e visita anche la sezione risorse di DigitalProjectManager.com per entrare nel nostro team Slack. Troverai tante conversazioni su come avviare i progetti e sulla loro gestione. Alla prossima, grazie per l’ascolto.