Salva il tuo progetto con un Documento di Avvio Progetto (con Maik Stettner di FCV Interactive)

Leggi la trascrizione:

Stiamo provando a trascrivere i nostri podcast usando un programma software. Per favore perdona eventuali errori di battitura poiché il bot non è sempre preciso al 100%.

Ben Aston:

Grazie per l'ascolto. Sono Ben Aston e questo è il podcast Digital Project Manager. Questo podcast è sponsorizzato da Clarizen, il leader nei software di gestione di progetti, portfolio ed enterprise. Visita clarizen.com per saperne di più.

Se c’è una cosa che si può garantire su un progetto, è che non andrà mai secondo i piani, ma perché i progetti deragliano? A volte, semplicemente perché iniziamo troppo in fretta e vediamo la scadenza avvicinarsi sempre di più, quindi finiamo per avviare il progetto un po’ in preda al panico; poi, quando qualcosa inizia ad andare storto, ci chiediamo il perché.

Di solito abbiamo in testa il background di progetto, la strategia, i dettagli, i requisiti, le metriche di successo, nascosti in un angolino della nostra mente, e spesso diamo per scontato che anche tutti gli altri ne siano a conoscenza, ma la realtà è che, se non è documentato, probabilmente il nostro team non lo sa affatto.

Oggi parliamo quindi di uno strumento che possiamo usare per mettere tutti sulla stessa pagina all’inizio del progetto. È il Documento di Avvio Progetto, o più comunemente chiamato nel nostro settore, il Brief di Progetto. Oggi vi daremo una panoramica su come potete creare un PID e utilizzarlo per rendere i vostri progetti più efficaci.

Oggi sono con Maik Stettner. Uno dei miei amici e colleghi. Maik è uno dei nostri esperti DPM residenti in The Digital Project Manager. Benvenuto, Maik.

Maik Stettner:

Ciao. Come va?

Ben Aston:

Bene, è un piacere averti con noi. Quindi, Maik, parliamo un po’ di te e raccontiamo a tutti qualcosa del tuo percorso perché ovviamente lavoriamo insieme ormai da, sono cinque anni?

Maik Stettner:

Sì, ormai sono quattro o cinque anni.

Ben Aston:

Già. Quando ho assunto Maik ricordo di aver pensato: “Ah, non so se questo ragazzo ce la farà.” Perché tu vieni da un background leggermente diverso. Non una classica agenzia. Raccontaci la tua esperienza. Come sei diventato PM in un’agenzia digitale?

Maik Stettner:

Allora, in totale ho circa 10 anni di esperienza in diversi ambiti. Ho iniziato originariamente nel gaming e nell’editoria, gestendo lanci di giochi in Europa e Nord America, poi mi sono spostato in altri settori come i database medici ma sempre nello sviluppo software e tutto ciò che riguarda il project management, team diversi e così via; nella mia carriera ho avuto anche esperienze in agenzia con sviluppo app e un po’ di sviluppo web iniziale. Sì, quando abbiamo avuto la prima conversazione riguardo lavorare insieme, ho fatto il passaggio definitivo allo sviluppo web e agenzia.

Ben Aston:

Già.

Maik Stettner:

E sì, lavoro con la mia attuale azienda, FCV, da circa quattro anni e ora guido il team di Project Management dell’agenzia e sono sostanzialmente responsabile della delivery generale dei progetti e di garantire che i clienti siano soddisfatti dei risultati che offriamo.

Ben Aston:

Perfetto. Per chi ci ascolta e pensa… forse si trova in una situazione simile… spesso ci scrivono project manager con esperienza nel software ma che stanno pensando di passare in agenzia per diventare Digital Project Manager. Per te, come è stata questa transizione dal mondo software a quello della gestione progetti digitali in agenzia? Quali sono state le differenze più rilevanti nel modo di gestire persone o progetti? Mi interessa capire il contrasto e gli aspetti da considerare per prepararsi a tale cambiamento.

Maik Stettner:

All’inizio ci sono molte somiglianze. Le situazioni che affronti in altre agenzie di sviluppo software o settori legati al project management, le ritrovi anche in agenzia. Avrai team eterogenei, progetti che deragliano per vari motivi e puoi applicare gli stessi metodi per gestirli.

Per me una delle differenze è stata capire e applicare il concetto di grande attenzione a tempi e materiali e a piccoli incrementi di lavoro rispetto a grandi consegne; i clienti, soprattutto nel mio settore, vogliono più trasparenza e più controllo su piccoli blocchi di lavoro. Quindi bisogna essere più trasparenti, preparare report più precisi e spiegare con chiarezza cosa si sta facendo, per generare fiducia. Richiede più impegno anche dal mio lato, rispetto a quando lavori in product company e punti solo al lancio interno.

Questa è stata la vera differenza, ma è stato interessante notare che, anche in campi diversi, non importa che tu lavori su database, giochi o siti web, incontrerai problemi simili e le soluzioni possono essere trasferite da un settore all’altro. Se applichi le lezioni e le best practice standard del project manager che hai appreso, probabilmente avrai successo indipendentemente da cosa realizzi.

Ben Aston:

Bene. Quindi… hai citato sfide simili. Puoi condividere com’è ora il tuo ruolo? Gestisci sia progetti sia team: per esempio il team di project management. Nella gestione di un portfolio di progetti, con diverse richieste di risorse, quali sono le sfide tipiche che affronti guidando il team PMO?

Maik Stettner:

Il mio ruolo adesso è più olistico, mi assicuro che tutto proceda e il mio focus principale è, come dicevi, il resourcing, ovvero assicurarmi che abbiamo le persone giuste nel posto giusto per il tempo giusto.

Ben Aston:

Giusto.

Maik Stettner:

Spesso bisogna scendere a compromessi quando le cose richiedono più tempo ma ci sono altri progetti in coda, e quindi mitigare gli aggiustamenti e garantire ai clienti una comunicazione aperta. Il rischio in un ruolo più alto è di diventare solo la persona a cui si rivolgono per le escalation – cosa che non vuoi perché ricevi solo chiamate di reclamo!

Ben Aston:

Giusto.

Maik Stettner:

Ma è sempre utile mantenere un ruolo attivo nei progetti per creare rapporti di fiducia e allo stesso tempo assicurarsi che nell'organizzazione tutto sia configurato correttamente, che sia per risorse, operations o collaborazione tra uffici (noi ne abbiamo più di uno).

È importante che, ad esempio, chi lavora nell’ufficio di Toronto possa collaborare bene con chi sta a Victoria. Questo è il focus principale. Ciò detto, continuo comunque a gestire alcuni clienti in prima persona, perché la mia passione resta il project management e mi piace lavorare con le persone.

Ben Aston:

A proposito della sfida del resource management, come ti regoli quando due project manager hanno deadline simili e bisogno delle stesse risorse? Come triaggi le priorità e gestisci il portfolio per decidere chi ha la priorità? Molti PM lamentano carenza di risorse… sarei curioso di sapere il tuo punto di vista e il tuo processo decisionale su cosa va avanti e cosa viene posticipato.

Maik Stettner:

Prima di tutto, guardo la priorità del progetto. Ci sono scadenze imminenti? Abbiamo promesso qualcosa al cliente? Deve essere live per una data fissa? Guardo se ci sono margini sul timing.

Conto anche se il contratto è già finalizzato e, di conseguenza, se bisogna avanzare per fare un favore al cliente, lo si fa solo se c’è tempo. Ma se l’altro progetto deve andare live tra tre giorni, nessuno può essere distolto da lì.

Queste sono le basi. Idealmente non si verifica questa situazione, perché il PM dovrebbe prevedere margini di sicurezza. E mi aspetto anche dal mio team che lotti per le proprie risorse!

Ben Aston:

Certo.

Maik Stettner:

Spesso sono troppo gentili: “Ok, puoi avere questa persona per un giorno…” e così finiscono tutti per vedere i loro progetti slittare. Non amo che si “rubino” risorse – assolutamente no – ma nelle riunioni di resourcing mi aspetto che qualcuno difenda il proprio tempo e rimetta la questione nelle mani del responsabile del resourcing per trovare un supporto o un bilanciamento.

Ben Aston:

Forse è un problema tipicamente canadese nel resource management.

Maik Stettner:

Sì, quell’indecisione tipica del Canada!

Ben Aston:

I canadesi sono troppo gentili, come europei possiamo dirlo. O forse solo i canadesi possono scherzare sui propri difetti?

Maik Stettner:

Esattamente. Li vedo in modo diverso, anche in Europa.

Ben Aston:

A proposito di strumenti, hai scoperto tool che ultimamente ti hanno entusiasmato o che avresti voluto adottare prima? Qual è la tua cassetta degli attrezzi ideale?

Maik Stettner:

Per la gestione delle risorse?

Ben Aston:

Sì, o per la gestione progetti in generale .

Maik Stettner:

Usiamo strumenti abbastanza standard per la gestione del tempo e MS Project spesso risulta pesante per il cliente. Stiamo sperimentando molti prodotti cloud ora, c’è la versione Office 365 di Project ad esempio. Ma stiamo cercando anche soluzioni per il time management e la gestione risorse. Un processo purtroppo ancora parzialmente manuale e molto su misura.

Penso che lo strumento perfetto per noi non esista. Mi piacerebbe svilupparne o acquistarne uno personalizzato.

Ben Aston:

Dato che ci ascoltano anche sviluppatori di strumenti, cosa pensi dovrebbe avere un tool ideale che ad oggi manca? È la complessità del processo a non essere soddisfatta dai tool?

Maik Stettner:

Non necessariamente. È tutto abbastanza lineare. Io cerco uno strumento che colleghi dalla gestione semplice del tempo e dei timesheet di ognuno, alla pianificazione delle risorse, tipo Resource Guru o altri strumenti per il mapping delle necessità – e poi l’aspetto finanziario. Soprattutto quando lavori a tempo e materiali il calcolo è ore*tariffa. Poi ci vuole tutto il reporting conseguente.

Sembra facile ma ci sono tante variabili – cambi di progetto, come i sistemi rispondono – e bastano questi per stravolgere i report e introdurre altro lavoro manuale. Non ho ancora trovato la soluzione perfetta.

Ben Aston:

Bene. Parliamo dell’articolo che hai scritto sui Documenti di Avvio Progetto (PID): come dicevo all’inizio, spesso i progetti falliscono perché non vengono avviati bene. Diamo per scontato che il team sia allineato o gli diamo tanti documenti – “Cerca tutto sulla cartella condivisa” – e pensiamo che si aggiorneranno, ma se falliscono non capiamo perché. In realtà il team non “conosce” il progetto.

Come possiamo creare brief/project initiation document migliori? Se ci dai uno scenario: qual è il tuo processo per avviare i progetti e dove si inserisce il documento di avvio o brief? Quando lo crei e qual è il punto giusto per scriverlo?

Maik Stettner:

Di solito, supponendo di avere un nuovo cliente e un contratto quadro firmato, cerco di arrivare a passi più concreti.

Normalmente, si parte con uno Statement of Work. All’inizio però tutto è molto generico e approssimativo rispetto a dove si andrà davvero. Il documento di avvio e la riunione di kick-off servono a “sentire” il cliente e capire se ci sono altri motivatori non emersi nel brief e nei primi scambi.

Spesso, dopo la redazione iniziale dello Statement of Work (anche in bozza), all’interno dell’agenzia si fa un kick-off interno per chiarirsi le idee, poi uno esterno più ad alto livello col cliente. Si spiega chi è il team, come si lavora insieme e quale è lo scope definito.

Per me, il documento di avvio o brief è il passo successivo per essere più concreti – sebbene resti un documento “vivente”, che si evolve rispetto alla chiarezza che si avrà col tempo – ed è uno strumento prezioso per fornire contesto di business e chiarire subito i parametri basilari del progetto non solo al cliente ma anche al team interno.

Ben Aston:

Quindi, dopo lo Statement of Work oppure dopo un accordo legale, c’è la base formale e il documento di avvio si affianca – o si sovrappone – per definire e dettagliare meglio alcuni aspetti.

Nell’articolo indichi cosa deve includere: fornire contesto, dettagli dei parametri, struttura analitica di progetto, chi fa cosa e la gestione del rischio. Partiamo dal contesto: come decidi cosa inserire come contesto senza confondere o sovraccaricare di info? Cosa aiuterebbe davvero il team?

Maik Stettner:

È questione di capire perché il cliente vuole questo progetto, quali problemi si devono risolvere, ci sono spinte di business? Vogliono aumentare le vendite o informare il proprio pubblico? C’è un rebranding? La domanda chiave è: come si misura il successo, anche se a livello alto?

Potrebbe essere semplicemente migliorare le conversazioni di vendita o, ad esempio, su un sito di self-service che raccoglie contenuti in un CMS. Serve dare al team una panoramica di dove si vuole arrivare, anche se i passi non sono già dettagliati.

Se il progetto è un rebranding, e alla fine qualcuno chiede “perché le vendite non sono cresciute?”, puoi rispondere che non era l’obiettivo di quel progetto. È importante avere traccia di cosa viene concordato e confrontarsi sugli obiettivi con il cliente.

Ben Aston:

È molto utile pensare al contesto: spesso, a meno che non si tratti di manutenzione, comprendere perché si fa il progetto, quali obiettivi di business e che aspetto abbia il successo è fondamentale. Dandolo già nel documento di avvio aiuta il team a orientarsi. Passando ai parametri: cosa intendi per parametri all’interno di questo documento? In che modo limiti la squadra? Quando è utile “restringere” il campo?

Maik Stettner:

Non vuoi mettere paletti agli esperti, ma se dai totale libertà potrebbero andare fuori strada. Bisogna dare dei confini: budget, tempi, pianificazione. Meglio se stimati col team; tutti devono sapere quale budget c’è e che non è una restrizione, ma cosa è stato concordato col cliente. Quando cambiano le condizioni, il team deve trovare il modo di raggiungere comunque gli obiettivi, potenzialmente con più risorse o informando il cliente sui rischi anche in questa fase iniziale.

Il team deve avere fiducia nella delivery ed essere motivato tanto quanto il cliente, perché anche loro vogliono ottenere risultati.

Ben Aston:

Parli anche di inserire breakdown, WBS e un piano risorse. Ma a inizio progetto, con le cose poco definite, come si fa una pianificazione? Come costruisci il piano “di massima” all’inizio, anche se poi cambierà?

Maik Stettner:

Sinceramente, all’inizio è un’ipotesi realistica. Parti dallo Statement of Work o da quanto già stimato dal team. Ci sono sempre variabili: la reattività del cliente, il numero di revisioni… Il primo piano può essere molto diverso dal definitivo.

Però, come dicevo prima, anche solo un piano ‘di massima’ aiuta: serve per assicurarsi le risorse giuste e la stabilità del team. Anche se poi il cliente dirà che i tempi sono troppo stringenti, serve per mappare la complessità e attivare le domande giuste già dalle prime discussioni.

Magari ti accorgi che serve un designer che avevi sottovalutato! Se il team discute di questi aspetti prima, il PM capisce meglio le sfide e può porre le domande giuste o “indirizzare” il cliente. Un piano, anche abbozzato, è meglio che nessuno: almeno innesca il confronto e può essere raffinato col tempo.

Ben Aston:

Concordo: meglio un piano imperfetto che nessun piano, perché col tempo si può aggiornare. Se al kick-off non c’è nulla su come si lavorerà, manca la spinta iniziale. Invece andare con un piano, anche se “folle”, stimola il confronto. L’importante è avere almeno una base da cui partire.

Abbiamo parlato di brief/project initiation document – che sembra un documento impegnativo ma in realtà può assumere molte forme. Tu che altri formati hai visto, e come vedi evolve il suo ruolo durante il ciclo di vita di progetto?

Maik Stettner:

La guida che ho scritto è solo un esempio di cosa includere. C’è una soglia minima di informazioni che non deve mancare, poi si può adattare: magari parte della gestione rischi va in altro documento, oppure una raci chart alimenta i report di avanzamento.

Non serve sempre formalizzare troppo. L’importante è che tutti siano d’accordo. Può essere postato su SharePoint, BaseCamp, oppure modificato col tempo… se ci si rende conto che manca un pezzo (tipo la parte commerciale), basta integrarla. Lo scopo è che sia un documento condiviso e accettato; non per forza firmato, ma quantomeno riconosciuto da tutti – è su quello che si lavora e si misura il progresso.

Ben Aston:

Bene, se dopo questa puntata pensate “da dove si inizia?”, la buona notizia è che Maik ha creato un ottimo template scaricabile per il vostro brief/documento di avvio. Trovate tutto nell’articolo. Maik, grazie di essere stato con noi oggi!

Maik Stettner:

Grazie a voi per avermi invitato.

Ben Aston:

Prego. Come esperto DPM, se vi è piaciuto ciò che Maik ha condiviso, sappiate che sarà tra i docenti del nostro prossimo corso, a settembre, Mastering Digital Project Management. Se pensate di voler approfondire il PM, guardate il corso: 7 settimane di lezioni video, compiti settimanali, discussioni di gruppo ed opzione coaching. Andate su digitalprojectmanagerschool.com e iscrivetevi prima che si esauriscano i posti.

Se volete contribuire alla discussione su documenti di avvio/brief, andate nella sezione risorse di digitalprojectmanager.com per entrare nel nostro team Slack – troverete molte discussioni interessanti. E ricordate di commentare l’articolo e di condividerlo. Alla prossima, grazie per l’ascolto.