Commitment e responsabilità

Nel post corrente parleremo di due temi sui quali si arenano parecchi progetti e sono la responsabilità e l’impegno rispetto a qualisiasi attività di progetto.

Il tema della responsabilità sui task di progetto viene spesso sottovalutato.

Quando si pensa al termine attività di progetto si crede che queste siano delle occupazioni a carico del solo project team, mentre il concetto di task di progetto deve essere espanso  a tutte quelle attività di esecuzione, certo, ma anche di recupero delle informazioni, risoluzione di problemi o punti aperti, attività di networking tra gli stakeholder o di promozione del progetto stesso.

Insomma, qualsiasi azione che porti ad un avanzamento incessante del progetto verso la meta.

L’esperienza mi insegna che nella maggior parte dei casi le attività di esecuzione dal team sono quelle con una effettiva alta probabilità di esecuzione nei tempi prestabiliti.

Al contrario, le altre attività spesso in carico agli altri stakeholders, sono sistematicamente sottovalutate. Peggio ancora, vengono ripetutatemente istanziate e reiterate nei meeting che si susseguno durante il ciclo di vita del progetto, annotate come open points nelle relative meeting minutes e poi regolarmente disattese.

Affianco al concetto di responsabilità di un task, troviamo il concetto di commitment.

Ho cercato la traduzione esatta del termine in diversi dizionari e ho trovato le seguenti traduzioni: impegno, dedizione, promessa, affidamento, coinvolgimento; tutti hanno molto a che fare con la parola fiducia.

Prendersi in carico qualcosa e permettere agli altri interlocutori di affidarsi a noi. Un vero e proprio vincolo tra le persone in cui ci si impegna a portare a termine un’attività.

Il commitment ha molto a che fare quindi con la sfera “emozionale” legata anche all’entusiamo che si viene a creare all’interno degli stakeholders di progetto nel portarlo a termine; entusiasmo messo a rischio quando il progetto incontra i primi ostacoli che l fanno ritardare o bloccare.

Le figure di project manager e sponsor in questi casi sono vitali e importantissime.

Il primo ha il dovere di monitorare constantemente lo svolgimento delle attività, la raccolta delle informazioni e il clima che caratterizza il progetto e le persone coinvolte.

Deve rivitalizzare l’interesse quando è in calo, rivedere le assegnazioni, richiedere solleciti feedback, porre le persone incaricate di fronte alle responsabilità di eventuali ritardi sulle loro attività.

Dall’altra parte, proprio per non eccedere in facili entusiasmi, deve cercare di regolamentare l’eccesso di entusiasmo facendo rimanere molto focalizzate le persone sulle loro attività, rimandando qualsiasi festeggiamento o entusiamo al momento dell’effettivo raggiungimento del singolo obiettivo.

Lo sponsor è vitale nell’alimentare continuamente l’interesse, che calerà di sicuo nei mesi a venire, nei confronti del management e degli utenti aziendali chiave coinvolti.

Parallelamente ad un lavoro incessante di comunicazione, per questi scopi viene i aiuto la RACI matrix.

Esistono altri due sinonimi RAM (Responsibility Assignment Matrix) o LRC (Linear Responsibility Chart) che fondamentalmente riconducono allo stesso strumento.

RACI Matrix. Fonte PMBOK 3rd Edition

• Responsible, indica a chi è in carico il task per la sua esecuzione; è la persona che è responsabile del suo completamento
• Accountable, termine che si sovrappone al precedente perchè indica sempre una responsabilità ma questa è sicuramente più forte della precedente. Potremmo riassumerla con questo esempio: un task è stato delegato da una persona ad un’altra. Chi ha preso la delega del task è il responsabile e chi l’ha fornita è in ultima analisi il vero e ultimo responsabile (accountable). Il project manager, per intenderci,  è l’unico vero accountable del progetto; il successo o il fallimento dello stesso ricadrà, in ultima analisi, sulle sue spalle
• Consult, la persona indicata da questo attributo deve essere assolutamente consultata durante l’attivazione, l’esecuzione e la fine del task in oggetto
• Inform, vincolo molto più leggero rispetto al precedente. Indica che deve avvenire un’azione di inormazione verso la persona indicata in quel task

 Spesso quando si ha a che fare con questi strumenti si effettua l’errore, io in prima linea, di sottovalutarne la forza: tutto sommato è solo una matrice che dice chi deve fare che cosa!

Invece la formalizzazione delle decisioni prese in termini di responsabilità e commitment e la sua ufficializzazione attraverso tali strumenti e un vincolo forte di fronte a tutti gli stakeholders di progetto.

Ricordate? Ha molto a che fare con la fiducia!

E, in una aggregato sociale o comunità, la comunità di progetto appunto, la fiducia è uno dei valori più importanti.

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”?

Assemblea Generale PMI-NIC

Permettetmi un piccolo slancio di orgoglio.

Venerdi ho partecipato all’assemblea generale del PMI-NIC dove oltre a rinnovare alcune cariche societarie, è stato presentato il programma del 2010 e il risultato delle attività dell’associazione nel 2009.

Con mia soddisfazione in una delle slide presentate, è stato citato il lavoro di formazione svolto presso l’ITIS Badoni di Lecco già raccontato nei miei precedenti post (istruire,comunicare, imparare e scuola e project management).

Slide PMI-NIC

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.

Scuola e Project Management

In un precedente post, raccontavo della mia docenza di Project Managemen, presso una scuola superiore di Lecco (ITIS Badoni).

L’esperienza ha avuto un buon riscontro sia da parte degli studenti sia dei docenti.

Aluni giornali locali hanno scritto di questa inziativa e, qualora interessati, questi sono i link agli articoli: Giornale di Lecco, Giornale di Merate e La Provincia di Lecco.

Gestione integrata dei progetti

Ricordate di quando abbiamo parlato di centralizzazione delle informazioni di progetto?

Bene, con questo post voglio mostrare come in Diesys gestiamo le informazioni di progetto. Per lo scopo abbiamo sviluppato un’applicazione dedicata (Project Guard) che ci aiuta a gestire info generiche, WBS, team members, issues, documenti e statistiche correlate.

La teoria agile pone il focus sulla comunicazione e le informazioni e su quanto esse debbano essere facilmente fruibili, immediate e centralizzate per l team.

Questi i principali punti interessati:

• Utilizzo di information radiators: fare largo uso di lavagne, cartelli e post-it per favorire il circolo e la condivisione delle informazioni
• Informazione centralizzata: le informazioni devono essere centralizzate in repository comuni
• Informazione accessibile: le informazioni di progetto devono essere direattamente accessibili a tutto il team

Il primo punto non necessita di alcuno strumento informatico, cosa però che si rende necessaria per il secondo ed il terzo elemento.

In questi casi è indispensabile un tool che centralizzi le informazioni per singolo progetto, che permetta di identificare le informazioni per categoria e che ne dia accesso libero ai membri del team.

Procedendo oltre, vi sono altri punti di notevole importanza quando si parla di gestione integrata del progetto e sono:

• gestione della WBS
• gestione dei membri del team
• tracciamento del lavoro eseguito
• gestione di comunicazioni, lesson learned o in generale di issue
• gestione di un glossario di progetto
• disponibilità di statistiche per la consuntivazione

Dashboard progetti

Ogni membro del team dovrebbe avere a disposizione una visualizzazione generale di tutti i progetti di cui fa parte.

Questa deve fornire informazioni raggruppate, grafici e la possibilità di accedere facilmente alla principali funzionalità di gestione del progetto.

PrjGuard - Dashboard

Informazioni di progetto

Il progetto viene gestito come singola entità, sulla quale memorizzare tutte le informazioni relative.

PrjGuard - Generali e Team Member

L’immagine mostra a sinistra le informazioni di base del progetto e tramite il pannello a sinistra è possibile gestire gli appartenenti al team: questo di fatto da loro visibilità e accesso alle info di progetto e permetterà il tracciamento del lavoro eseguito.

WBS Statistiche ore lavorate

La WBS, fulcro del progetto stesso, prevede funzioni dedicate per la sua creazione e manutenzione e per il suo utilizzo in ambito di definizione del lavoro eseguito e per la conseguente consuntivazione.

PrjGuard - WBS e Totali Lavoro

 Ogni membro può tracciare il lavoro eseguito ed il tempo impiegato, attraverso l’interfaccia seguente.

PrjGuard - Tracciamento Attività

Documento di progetto

Pannello tra i più usati è ovviamente quello dei documenti.

Questi vengono suddivisi per categoria e riportano nome dell’utente e momento di upload.

Staistiche di progetto

Ovviamente non possiamo farci mancare le statistiche, pronti per quando il nostro cliente o capo ci chiederà il classico report.

Gestione delle issues

Capitolo deliicato e particolarmente “coccolato” è quello delle issue. Qui vengono centralizzate tutte le informazioni a carico di un progetto.

Queste vengono schedata per tipologia, creatore, date e riportano descrizione generale, eventuale descrizione di chiusura e status relativo.

Noi utilizziamo questo strumento per segnalare:

• Nuove richieste
• Richieste di cambio specifica
• Lesson Learned
• Segnalazione di bug
• Comunicazioni generiche
• Risultati di debug

PrjGuard - Issues

Revisione dei processi di project management

Come possiamo migliorare la qualità dei nostri processi di project management?

Qualche giorno fà ho partecipato ad una sessione di brain-storming organizzata da un cliente, che aveva come unico scopo: quello di focalizzare l’attenzione sui processi di project management utilizzati nell’anno appena passato.

Inzialmente fui piuttosto sorpreso, credevo infatti che la riunione fosse stata organizzata per mettere in risalto eventuali nostri difetti come fornitori e avevo preparato armatura, scudo e…scuse.

Nella sessione, invece, si sono analizzati i problemi riscontrati nella gestione dei progetti passati, indifferentemente dalla parte in causa.

A questo incontro hanno fatto seguito: una mappa mentale dell’incontro con le segnalazioni suddivise tra cliente e fornitore e un documento in cui si invitava ogni partecipante a fornire almeno tre possibili soluzioni/migliorie alle singole tematiche.

In un post precedente, parlando di qualità, ho citato l’importanza del continuo miglioramento dei processi di project management e attività di questo tipo sono portatrici di grande valore.

Va però tenuta in grossa considerazione il fatto che approcci di questi tipo possono vedere la luce solo in presenza di questi due fattori:

• buona cultura di project management del cliente
• buona continuità di progetti con il cliente

Riguardo al primo punto, noi siamo caduti in piedi in quanto il collega e amico Bruno, vestiva in quell’occasione i panni di cliente e non di mio co-relatore ad un seminario sul project management.

Anche il secondo punto era soddisfatto in quanto con l’azienda cliente che lui rappresentava, esiste una continuità di lavoro piuttosto intensa.

Questa esperienza affianca e completa momenti simili che viviamo in azienda abbastanza regolarmente e che coinvolgono tutto il team.

Con buona cadenza, infatti, organizziamo meeting in cui ognuno porta idee, critiche costruttive, proposte, revisioni riguardanti uno di questi temi:

• framework di sviluppo applicativo proprietario
• metodologia di analisi del progetto e relativa documentazione
• strumenti di lavoro a supporto del team
• strumenti di comunicazione e condivisione delle informazioni
• qualità nel rapporto con il cliente
• crescita dei membri di progetto

Gli outcomes di questi meeting danno vita ad una serie di issues che vengono raccolte, catalogate e prioritizzate.

Poi, però, arriva la vera nota dolente.

Prendere la decisione di quando queste migliorie dovranno essere apportate.
Oggi ho sul mio tavolo, almeno due documenti di alcune pagine, riportanti segnalazioni di quel tipo e che aspettano da alcuni mesi di essere evase. Come spesso accade, le pressione del lavoro, le consegne e le relative scadenze, non permettono di implementare tali migliorie tutte in una sola soluzione.

Però per lo scopo, possiamo prendere in prestito la tecnica degli sprint dallo sviluppo agile.

• Si definisce un tempo in giorni: 2/3 gg massimo.
• Una volta prioritizzate le issues, insieme al team, si scelgono quali siano le più importanti.
• Queste poi vengono assegnate ai membri del team e si procede all’implementazione e alla messa in produzione dei risultati.

Questo approccio ha due vantaggi.

Il primo risiede nel fatto che un ritardo di due o tre giorni sui progetti running a causa dello sprint sopra, è facilmente recuperabile.

Il secondo si basa sul principio di Pareto che cita:

“La maggior parte degli effetti è dovuta ad un numero ristretto di cause.”

o ancora

“l’80% dei problemi è dovuto al 20% delle cause”

Quindi, avendo a monte prioritizzato le problematiche e scelto per prime quelle in assoluto più importanti, dovremmo aver sensibilmente ridotto i problemi a carico di strumenti, metodologie e approcci.