Comunicazione agile

In questo post cercheremo di valutare come rendere agile la comunicazione all’interno del progetto.

Come già discusso in altri post precedenti, la comunicazione è colonna portante dell’intera disciplina del project management.

Si sa, il 90% del tempo di un project manager è occupato da problematiche inerenti la comunicazione: riunioni, documenti, telefonate; tutte queste occasioni sono direttamente proporzionali al numero degli stakeholders coinvolti.

Anche il rapido aumento della complessità dei progetti stessi è un fattore che complica non poco la faccenda: l’insorgere di problemi legati a cambi di specifiche, accorciamento nei tempi, revisioni al ribasso di budget, bilanciamento delle aspettative dei numerosi stakeholders che hanno spesso interessi contrastanti, obbliga il project manager ad esercitarsi giornalmente attraverso la negoziazione e il compromesso.

Infine, al suo interno deve saper interpretare due differenti ruoli con stili comunicativi piuttosto differenti: quello del leader che, fissata la meta, deve saper coinvolgere e motivare il team al suo raggiungimento e quello del manager in grado di gestire budget, costi, contratti, diagrammi e gantt.

E allora come fare?
Personalmente ho tratto suggerimenti sia dal PMBOK sia da alcuni libri che parlano di agile project management e che trattano in dettaglio il tema della comunicazione.

Disponibilità informazioni

Innanzitutto dobbiamo rendere disponibili le informazioni a tutto il team e dobbiamo fare in modo che queste siano facilmente raggiungibili.

Dotiamoci quindi di un sistema di gestione documentale, o simile, che sia in grado di centralizzare le informazioni, indicizzarle per chiavi e renderle disponibili ai team dei singoli progetti senza troppe limitazioni o complicazioni nel poterne fruire, pena il fallimento dell’operazione.

Mezzi

Distribuite negli uffici una serie di lavagne, di pennarelli e cancellini, utilizzabili da tutti ed in qualsiasi momento per chiarire concetti, annotare appunti, liste, flussi di lavoro.

Dotate tutti i pc del team di un’applicazione di instant messaging tipo skype, msn, icq: alcune domande o questioni possono essere risolte in chat senza dovervi alzare o interrompere ciò che state facendo.

Se avete questioni urgenti o importanti da discutere e la persona con la quale dovete parlare non è nella vostra stessa stanza, alzate il telefono e chiamatela; non aspettate di incontrarla, non scrivete email se non siete certi di riuscire a chiarire a dovere la cosa: impieghereste di sicuro più tempo a scriverla che a spiegarla direttamente  a voce.

Infine, per tutto il resto, utilizzate le email ma fate buon uso delle notifiche di consegna e lettura se la questione è particolarmente importante ed imparate a taggare le email più importanti, cosi da poter eseguire azioni di follow-up nei giorni successivi qualora tardino ad arrivare delle risposte.

Modalità

Una delle prime regole della comunicazione agile parla di comunicazione Face-to-Face.

Parlate direttamente alle persone. La comunicazione faccia a faccia è la più funzionale e offre diversi vantaggi:

• Comunicazione sincrona, permette di capire immediatamente se il nostro messaggio è stato recepito correttamente
• Non dobbiamo aspettare per avere risposte alle nostre domande: le avremo subito e subito potremo verificare se le abbiamo percepite correttamente
• Potremo captare anche i messaggi non verbali; quei messaggi cioè fatti di postura del corpo, tono della voce, sguardo, movimenti delle mani, che caratterizzeranno ancor di più il messaggio ricevuto

Contenete il numero di membri del team. Team troppo grossi potrebbero essere dispersivi, aperti a maggiori problemi di conflitti e terra fertile di malintesi.

Collocate nello stesso ufficio (war-room) tutti gli appartenenti al team, questo agevolerà non poco le comunicazioni, permettendo ad ognuno di usufruire della presenza dell’altro istantaneamente: un consiglio, un chiarimento, un suggerimento arriveranno subito.

Portate, almeno una volta alla settimana nella war-room con il vostro team, un rappresentate del cliente.

Fate in modo che il cliente accetti di far partecipare ai lavori una persona esperta dei processi di business che state implementando; nel caso invece che l’esperienza di tale persona non sia approfondita in quel campo, lasciatela nei suoi uffici, porterebbe solo dispersione e poca concretezza.

Se dovete parlare con l’estero prediligete una video conference call.

Parlare in lingua straniera senza poter vedere l’interlocutore è un supplizio: difetti di pronuncia, rumori di fondo della linea, impossibilità di aiutarsi con la lettura del labiale, oltre che della mancanza dei già citati nessaggi non verbali, sarebbero un ostacolo alla corretta comprensione di quanto detto durante il meeting.

Governo delle comunicazioni

Limitate i canali di  comunicazione.

Guardate questa formula: n * (n-1) / 2 >> canali bidirezionali.

Dove n è il numero di stakeholder del progetto. Significa che se in un progetto avete identificato 10 persone coinvolte, vuole dire che ipoteticamente vi saranno 45 canali di comunicazione bidirezionali che si possono apripre tra i vari stakeholders.

Semplificate!

I membri del team parlano esternamente attraverso la voce del project manager o attraverso uno solo, il più anziano solitamente, dei suoi membri.

Siate voi, in quanto pm, i principali interlocutori e quando si scende troppo in dettagli delegate ad un membro del project management team (uno dei vostri assistenti) che vi farà un riassunto corredato da meeting minutes.

Limitate l’entropia: cercate sempre la sintensi in voi e nei vostri interlocutori, puntate alla concretezza e al pragmatico: l’eccesso di dettaglio non è mai un bene.

Infine, se il troppo commitment verso il progetto sembra aver reso troppo teso l’ambiente, organizzate un bella pizzata: anche questo serve al vostro progetto…ricordate le parole “team building”?

Successfull Projects

In questo post cercherò di identificare le principali cause fallimento dei progetti cercando di trovarne un denominatore comune.

Questo post è disponibile ai soli utenti registrati.

Per procedere alla registrazione cliccare sulla voce “Amministrazione/Registrati” nella side-bar di destra.

This post is available only to the registered users. Please register using the side-bar on the right.

Negoziazione, networking e compromesso

Voi, in quanto project manager negoziate continuamente.
Negoziate le risorse migliori, tempi di consegna più lunghi, budget più consistenti, maggiore visibilità vostra e del vostro progetto.

Continuamente dovreste fare networking.
La vostra influenza sulle decisioni di progetto deve essere quanto più possibile pubblica, forte, esplicita.
Quando questo non è possibile, può però passare attraverso canali indiretti, percorrere via di comunicazione confidenziali, mirare all’appoggio degli stakeholder più importanti, trovare cioè percorsi per influenzare, di riflesso, le decisioni più critiche.
Superfluo sottolineare che quanto sopra non dovrebbe ledere alcun principio etico.

Continuamente, ahimé, scenderete a compromessi.
Quando la risorsa che vi aspettate venga assegnata al progetto non vi viene concessa, cercate di ottenere un allungamento dei tempi di consegna; quando il ritocco tanto atteso al  budget non è arrivato cercate un maggior coinvolgimento del management, aumentando la visibilità del progetto e indirettamente delle difficoltà in cui vi trovate.

Esiste però un limite per il compromesso.
L’asticella la dovrete fissare voi e non illudetevi: gli altri stakeholder faranno finta di non vederla.
Spesso troppo presi dalle loro problematiche lavorative o eccessivamente coinvolti dai loro interessi, non tarderanno a chiedervi più di quanto potrete concedere e, in alcuni casi, potrebbero addirittura cercare di convincervi che quanto stai per accettare sia un giusto prezzo.

Personalmente sono una persona guidata dall’entusiasmo e molto portata a condividere i miei progetti, partecipare pienamente a quelli degli altri e ad accettare e fare mie le loro sfide.
Faccio però uso del bisturi della critica (nella sua accezione più positiva): lo rivolgo, in primo luogo, verso me stesso, alla ricerca di quelle imperfezioni da asportare chirurgicamente nella speranza di un miglioramento personale sostanziale.
Lo rivolgo con altrettanta precisione verso il mondo esterno.
Non accetto situazioni congeniali solo ad altri, forzature, compromessi in perdita, imposizioni che snaturino me, il mio team o il mio progetto.

Quando mi capitano situazioni come quelle, suona qualcosa. Avverto una dissonanza, qualcosa non torna.
Prendo tempo, ragiono, valuto le possibilità, le convenienze mie e degli altri, i doveri miei e degli altri.

Una volta un cliente, piuttosto importante, per risposta al mio ennesimo no ad una forzatura su un progetto, sorrise e con sarcasmo e voce un pò alterata mi disse che là fuori il mondo è fatto di squali (ndr leggi concorrenti) pronti a sbranarmi in pochi istanti.
Lo so perfettamente.
Quel cliente, come diversi altri, nonostante forti ed espliciti scambi di opinioni e chiarimenti, si serve ancora della nostra consulenza e dei nostri servizi.

M torna in mente uno dei tanti proverbi sui project manager.
La parola più preziosa e meno utilizzata dai project manager è NO.

Il project manager creativo

Martedì scorso ho partecipato ad un seminario sull‘intelligenza creativita.
Ero particolarmente interessato in quanto non mi sono mai ritenuto una persona particolarmente creativa e mi piaceva l’idea di mettermi alla prova in quel campo.

Solitamente quando pensiamo ad un “creativo” ci viene subito in mente una persona con strani capelli colorati, tenuti in piedi da spessi strati di gel e che ami vestire in modo appunto creativo, con strani accostamenti cromatici, o pantaloni strappati nei punti più impensabili.
Poi lo vediamo all’opera, magari nella creazione di strane pubblicità o alle prese con immagini e composizioni grafiche rocambolesche e, ahimé, è proprio lì che il nostro senso di inferiorità esplode in tutta la sua potenza e l’unica nostra consolazione è rinchiuderci in frasi del tipo: “Beh, ma un project manager non è necessario sia un creativo!”.

Niente di più sbagliato: un project manager deve essere creativo!
Partiamo da alcune definizioni che ci suggerisce Irene Bursese, docente del corso.

• Creare, è realizzare qualcosa di nuovo ed utile, partendo da elementi pre-esistenti.
• Creatività è l’attitudine a fare del nuovo-utile.

 Prendiamo poi in prestito la definizione di progetto dal PMBOK: il progetto è uno sforzo temporaneo che utilizza risorse, intrapreso allo scopo di creare un prodotto, servizio o risultato unici.

Di conseguenza, la creazione di un risultato nuovo e utile, attraverso elementi già esistenti come le risorse, porta noi project manager a far parte della categoria dei creativi!

Questo è ancor più vero se pensate alle differenti tecniche di creatività come il brainstorming e il lateral thinking  che lo stesso PMBOK cita quando parla dello scope definition, quality planning, risk identifying; tecniche che permettono di lasciare libertà alle idee per la ricerca di soluzioni, alternative, migliorie.

Creatività che poi deve essere, per forza di cose, incanalata e concretizzata.
Allo scopo, per esempio, ci vengono in aiuto le famigerate mappe mentali  che permettono di organizzarle e categorizzarle in nodi, rami, e foglie e che spesso sono il punto di partenza per la creazione di WBS di prodotto o progetto e dei conseguenti reticoli delle attività.

Tutto questo mi porta a pensare che creatività e organizzazione, fantasia e concretezza, genialità e metodo siano, tutto sommato, facce della stessa medaglia: l’una non esisterebbe senza l’altra.

Project Meeting

Ogni progetto durante il suo ciclo di vita, dovrebbe giovarsi di riunioni periodiche più o meno approfondite, a seconda dei momenti specifici e con la partecipazione degli opportuni stakeholders (http://it.wikipedia.org/wiki/Stakeholder).
L’esperienza di questi anni mi ha permesso di identificare alcune tipologie di riunioni che, bene o male, vengono condotte per quasi tutti i progetti, con differenti gradi di dettaglio a seconda della loro dimensione.

Queste sono le tipologie individuate:
- Gathering Requirements
- Project Proposal
- Kick-off
- Daily meeting
- Team building
- Review
- Phase out
- Project closing

Gathering Requirements
Quando nasce da parte del committente la necessità di lanciare un progetto, la prima fase che deve essere svolta è quella di raccolta delle necessità e bisogni che il progetto stesso deve soddisfare.
Vengono condotte delle riunioni interne in cui spesso sono coinvolte anche le parti che dovranno stimarne l’impegno, per racogliere e documentare tali requirements.
Sulla base di queste indicazioni il management interno all’azienda sarà in grado di fare le sue valutazioni in termini di ROI e i possibili fornitori effettueranno le stime tempi/costi del caso, per poter procedere alla fase di proposta e offerta.
Questa fase ha un costo, sebbene non alto, sia per l’azienda committente sia per i fornitori perchè entrambi dovranno bruciare risorse non avendo ancora alcuna certezza sull’accettazione del progetto.

Project Proposal
Questa tipologia di meeting scaturisce immediatamente dopo la raccolta inziale dei requisiti e solitamente è condotta interamente dall’azienda fornitrice in quanto essa dovrò dimostrare attrvarso Strumenti quali documenti, stime, valutazioni e presentazioni, la soluzione che intende adottare per portare a compimento il progetto.
La fase che culmina con un Project Proposal meeting, a livello dei costi, è completamente a carico del fornitore che deve impiegare risorse per la produzione della documentazione opportuna e tempo per presentarla.

Kick-off
Finalmente è arrivato l’OK a procedere, il progetto e la relativa proposta sono accettati.
Solitamente, soprattutto per progetti di medie/grosse dimensioni, si dovrebbe procedere con l’organizzazione di un kick-off meeting in cui dovrebbero essere TASSATIVAMENTE invitati tutti gli stakeholder.
Questo punto è fondamentale in quanto la condivisione di modalità, scopi e tempi di progetto sono centrali rispetto alla buona riuscita del progetto stesso.
Non è possibile credere di avere l’ok su un progetto, prendere la propria bella cartellina e l’ordine firmato e poi sparire per 6 mesi sino al termine e alla consegna del prodotto/servizio.
E’ l’anticamera del fallimento!.

Daily meeting
Bene, ora comincia il bello.
Hai le risorse (umane e monetarie), il tuo bel gantt che ti guarda fiero e una pacca sulle spalle da parte del tuo cliente, devi solo cominciare a lavorarci sopra.
I membri del team non aspettavano altro e come maratoneti fermi sulla linea di partenza, scalpitano per lo start.
Una volta assegnate le attività e le responsabilità tu, come project manager, hai l’obbligo di capire giornalmente come si sta muovendo il progetto e lo puoi fare solo interessandoti giornalmente sull’avanzamento dei tuoi work package direttamente con la persona responsabile che lo sta portando avanti.

Tali meeting, derivati da tecniche di agile software development detti anche stand-up meetings, puntano a fornire risposte a tre domande fondamentali:
1. Cosa è stato fatto ieri?
2. Cosa farai oggi?
3. Quali problemi abbiamo riscontrato?

Tali meeting non dovrebbero durare più di 15 minuti e puntare al pragmatismo più assoluto.

Team building
Questi meeting, spesso anche non ufficiali e fuori dagli spazi ufficiali, puntano a rafforzare il rapporto tra i membri del team.
Spesso anche semplicemente facendo il punto della situazione rimarcando i risultati ottenuti e dando ad ognuno il merito e nuove attività da seguire, si può procedere a rafforzare il senso di coesione e di appartenenza al team/azienda.
E’ auspicabile che il project manager preveda anche sessioni di training interno su tematiche sia tecniche, gestionali o organizzative; queste non solo rafforzano il senso di unione ma indirettamente anche le competenze dei membri stessi.

Review
Questo meeting, a mio parere, è uno dei più importanti.
E’ una riunione ad ampio respiro a cui partecipano principalmente: mebri del team responsabili dei propri work-package e una rappresentanza operativa del committente.
Punta a fare il riepilogo di quanto fatto sino a quel momento, ponendo il focus soprattuto su eventuali problemi e su come possano essere superati.
Spesso in questi meeting si fanno largo uso di tecniche di brain-storming e lateral thinking al fine di trovare soluzioni e nuovi approcci.
La riunione dovrebbe terminare con una serie di action points che indicano le azioni da intraprendere nel futuro più immediato.

Phase out
Prima o poi si arriva alla chiusura di una fase di progetto che spesso coincide con la consegna di una deliverable e la sua relativa accettazione.Queste riunioni sono principalmente focalizzate sul cliente e tendono a dare visibilità della parte di progetto rilasciata.
Fondamentali sono i suoi feedback e la sua accettazione, seppure con riserve (si spera minori) che verranno documentate in apposite meeting minutes.
Queste riunioni devono formalizzare l’ok sulla fase appena terminata e danno l’ok a cominciare alla fase successiva.

Project closing
Ce l’abbiamo fatta, il progetto è terminato, il relativo prodotto/servizio consegnato.
Questa riunione deve formalizzarne definitivamente il raggiungimento degli obiettivi fissati e dare l’ok ufficiale alla sua chiusura.

Dalla lista di riunioni riportate, mi piace evidenziare due concetti:

1. Comunicazione…ancora??! Certo! Con una serie di riunioni cosi diverse nella loro modalità, nei contenuti e nella presenza di cosi tanti e diversi stakeholders, saper ben comunicare è fondamentale.
2. Impariamo a scrivere delle belle meeting minutes…solo cosi evitiamo a noi stessi di stressare oltremodo la nostra memoria e agli altri di condividere quanto è stato deciso al fine di utilizzare tali documenti come base di partenza per le prossime proficue riunioni.

Quel 90% fatto di comunicazione

Una delle prime cose che ti insegnano quando studi da “Project Manager” è che il tuo tempo dovrà per forza di cose, essere composto per un buon 90% da attività inerenti la comunicazione.

Mi sono sempre chiesto, approcciando al project management come sviluppatore, come sarebbe stato possibile cambiare così radicalmente considerando che fino ad allora il mio tempo lavorativo era dedicato quasi esclusivamente a progettare e scrivere codice e così poco alla comunicazione.

I primi cambiamenti ho iniziato a percepirli quando da singolo programmatore, ho cominciato ad avere bisogno di aiuto: in quel momento ho fatto la scelta di rendere più possibile generalizzato e astratto il mio modello di programmazione, per fare in modo che fosse facilmente replicabile e spiegabile a collaboratori.

Ho cominciato quindi ad avere contatti sempre più frequenti con consulenti ai quali dovevo non solo spiegare cosa doveva essere fatto, ma anche in che modo e con quali strumenti. Questo perché il software doveva essere scritto con le mie stesse logiche per permettermi una facile manutenzione a posteriori.

In qualche modo stavo evolvendo; il team via-via si allargava ed ero obbligato ad affrontare giornalmente situazioni di negoziazione, networking, team building, con stili di leadership differenti che variavano dall’autoritario, al collaborativo sino al delegativo. Collante dell’intero sistema cominciava a diventare la comunicazione…appunto.

Poi sono arrivati i primi clienti importanti, internazionali…e la learning curve si impennava sempre più.
Era necessario cominciare ad allenare, oltre all’inglese, anche quelle doti, sino ad allora quasi dormienti, legate al marketing, alla negoziazione e a tematiche più prettamente commerciali.

Poi gli ultimi anni hanno visto la creazione di un polo di aziende (http://www.alberologico.it) in cui si intrecciano le idee, necessità e interessi di molteplici interlocutori e per finire l’aumento del team di sviluppo sino a contare oggi otto unità; il numero di stakeholder e le complessità ad essi legati sono aumentate quasi esponenzialmente.

Il risultato l’ho provato oggi sulla mia pelle: non scrivo, ahimé, una riga di codice da parecchi mesi e nonostante due presentazioni importantissime da preparare, oggi ho passato TUTTO il mio tempo partecipando ad almeno 4 meeting, tutti ovviamente interessanti e necessari….ma non si era detto che era solo il 90% del tempo da dedicare alla comunicazione?!?