PMI Emea Global Congress – 2nd day

Anche ieri è stata una giornata completamente dedicata al congresso EMEA del PMI.

Nella giornata di ieri, ho seguito diverse presentazioni: una sulla negoziazione, una sul ruolo in sostanziale cambiamento del project manager, una sui diversi ruoli e responsabilità che ruotano attorno al programme management, quella che più mi ha colpito però, è stata quella dal titolo “Seven attributes of leadership for project managers“.

La sessione è stata condotta da Michel Operto, PMP senior project manager con esperienza decennale in aziende multinazionali nel campo IT e delle telecomunicazioni, nonché presidente del chapter PMI della Francia del sud.

Michel ha condotto la sessione, spogliandola di qualsiasi connotazione ufficiale o cerimoniosa, muovendosi tra il pubblico e coinvolgendolo sin dall’inizio; questo ha permesso, dal mio punto di vista, un mantenimento duraturo dell’attenzione da parte di buona parte della platea.

I lavori si sono aperti con una spiegazione dettagliata del valore della leadership e di quanto sia indispensabile per un progetto, avere a disposizione un leader forte, presente, caratterizzato da uno stile dinamico e sicuro.

Senza indugi ci ha subito elencato quali sono, secondo la sua esperienza, i sette attributi di una buona leadership:

1. Avere e comunicare una chiara visione
2. Mantenere un buon bilanciamento
3. Imparare ad avere fiducia del proprio istinto
4. Usare l’entusiasmo come driver per ispirare il team
5. Farsi portatori di rispetto
6. Avere coraggio nel perseverare di fronte alle avversità
7. Capire quando cambiare e addattarsi rapidamente

Sotto ve li espongo, cosi come da lui approfonditi, ma rivisitati anche attraverso le lenti della mia personale esperienza.

Avere e comunicare una chiara visione

Lo sappiamo, lo abbiamo letto dappertutto, un vero leader guarda al futuro, alle opportunità, alle occasioni, alle soluzioni,  in parole semplici identifica le mete da perseguire.

Il suo ruolo però non finisce lì: ingaggia gli altri membri del team, trova le giuste leve motivazionali, crea condivisione e organizza la squadra con la quale condividerà il viaggio per il raggiungimento della meta.

Per questo è necessario essere visionari e al tempo stesso buoni comunicatori: parlare agli altri della propria visione.

Mantenere un buon bilanciamento

Un project manager può essere certo equiparato ad un  ”equilibrista“, viene infatti sin dai primi momenti, chiamato ad allineare e bilanciare le aspettative degli stakeholder.

Ma il bilanciamento avviene in diverse aree:

• ostinata e ferrea disciplina e grossa capacità di ascolto
• realtà e desiderio
• sicurezza e accettazione del rischio
• necessità di dettaglio e capacità di astrazione verso una visione globale
• perseveranza e flessibilità

Imparare ad avere fiducia del proprio istinto

Prima o poi su un progetto comincia a piovere, spesso forte.

Si intravedono le prime nuvole quando comincia ad essere difficile tenere uniti tra loro i troppi interessi degli stakeholders coinvolti, oppure quando per tirare le fila di una situazione ingarbugliata abbiamo pochi dati o troppi dati.

Spesso i problemi iniziano quando ci sono troppo opzioni di scelta o più semplicemente perché si tratta di un progetto ad alta innovazione o che fa uso di tecnologia nuova.

In questi casi è necessario essere un ottimo decision maker, esser capaci di prendere decisioni veloci, può fare la differenza.

Affidarsi al proprio istinto senza troppe valutazioni o esercizi mentali, può fare la differenza.

Usare l’entusiasmo come driver per ispirare il team

Il leader  è il primo sponsor del progetto.

Il suo entusiasmo, il suo credere nel progetto deve essere palesato, sotto gli occhi di tutti. L’entusiasmo contagia.

In quest’ottica è necessario saper creare un forte senso di appartenenza attorno al progetto attraverso azioni di team building, essere se stessi senza finzioni o forzature, condurre il team con la forza dell’esempio.

Farsi portatori di rispetto

Buone doti di leadership non possono prescindere dal rispetto per l’altro.

Fondamentale è imparare ad ascoltare l’altro, non importa sia esso lo sponsor, un team member, uno stakeholder negativo;  porsi al loro servizio: dopottutto sei tu il pm del progetto, chi altri dovrebbe farlo?

Essere onesto ed equo e esercitarsi a mettersi nelle scarpe degli altri, per condividerne le motivazioni, i pensieri, le istanze.

Avere coraggio nel perseverare di fronte alle avversità

Su questo punto si sfiora la dimensione della “santità”, sembra quasi che l’aureola si sia decisa finalmente a spuntare.

Devo ammettere che di fronte al perseverare delle avversità ogni tanto si avrebbe voglia di fare le valigia e prendersi quelle famose ferie di un mese di cui si parlava da tempo.

Coraggio, perseveranza e avversità sono un trittico non sempre facile da coniugare, ma anche su questo, Michel, ha la sua ricetta.

Innanzitutto dobbiamo essere coscienti che non sempre è possibile accontentare tutti e che dobbiamo assolutamente imparare a dire di NO!

E comunque se di avversità si tratta, nulla o poco è nelle nostre mani e dobbiamo comunque essere positivi e costruttivi, tenere alto il proprio morale e quello della truppa.

Ricordate: nessuno, al di fuori di voi stessi, potrà aiutarvi!

Capire quando cambiare e addattarsi rapidamente

Infine, annusate il cambiamento nell’aria.

Ascoltate, imparate, guardatevi intorno e quando percepite i segnali di cambiamento, anche quelli più deboli, quello allora è il momento di adattarsi velocemente.

Planning a kick-off meeting

Un buon kick-off è garanzia di successo del progetto?

Un paio di giorni fà, ho condotto presso un cliente il kick-off di un nuovo progetto.

Progetto non particolarmente complesso nei suoi requisiti, che però nasconde diverse insidie in quanto obbliga un’interazione e integrazione molto forti con i sistemi del cliente, vede coinvolti diversi stakeholder, alcuni dei quali fuori dall’Italia e che, infine,  impone un adattamento a standard procedurali e di documentazione in uso presso il cliente.

La fase analitica inziale che ha dato vita alle stime e all’offerta, non è stata particolarmente dettagliata; diversi erano quindi i punti aperti e i dubbi circa alcune implementazioni.

Il kick-off sarebbe stato quindi momento fondamentale per cercare di chiarire al meglio quanto era ancora sfumato, privo di contorni nitidi.

Ho voluto affrontare il tema facendo uso di una mappa mentale in cui potessi raccogliere tutte, e dico proprio tutte, le tematiche che sarei andato a discutere nel meeting.

La prima cosa che ho fatto, è stata quella di fare una review completa di tutta la documentazione a mia disposizione suddividendo le tematiche nelle seguenti categorie:

• Open Points, in cui ho raccolto tutte le questioni non ancora chiare alle quali si sarebbe dovuto dare risposta nel kick-off
• Functionalities, categoria nella quale ho raccolto tutte le funzionalità del prodotto, implementando rami gerarchici a raggruppare funzionalità dello stesso tipo, in stile WBS
• References, tutti i documenti di riferimento (allegati alla mappa) che hanno dato luogo alla formalizzazione del plan di progetto
• Systems Involved, i diversi sistemi (hardware e software) esterni coinvolti, con i quali l’applicazione dovrà dialogare
• Application Roles, i diversi ruoli applicativi con relativi permessi
• Stakeholders, le persone coinvolte direttamente o indirettamente dal progetto
• Risks, la categoria che raccoglieva una prima analisi dei rischi

Grazie a questa prima iterazione, la mappa ha cominciato a prendere corpo.

Con l’aiuto di un membro del team che si occuperà dello sviluppo, si è proceduto alla scomposizione delle funzionalità in attività; questo ha permesso di delineare la WBS (allegata in formato excel alla mappa) e sulla quale è stato possibile procedere con stime di dettaglio (primo riscontro della mia stima draft fatta in fase di offerta).

Al kick-off ci siamo voluti presentare subito con i layout di esempio delle pagine dell’applicazione, per permettere a tutti di discuterle e di trovare da  subito condivisione sulle interfacce e sulla loro navigabilità.

Anche questa presentazione è stata allegata alla mappa.

Un altro passo è stato organizzare le funzionalità in deliverable del prodotto.

Questo punto è stato ispirato dalla metodologia agile:

• rilasci frequenti e temporalmente vicini
• inclusione già primi rilasci delle funzionalità più importanti (customer business value)

Sono state quindi identificate 4 deliverable, a rilasci distanziati di circa due settimane lavorative l’una dall’altra, includendo le funzionalità più importanti nelle prime due.

Quest’ultimo punto permetterà di:

• innalzare subito l’attenzione del cliente perché in grado di verificare subito le funzionalità più importanti
• garantirci una maggiore “probabilità” di feedback sulle deliverable
• fugare sin da subito dubbi o malintesi sulle funzionalità più importanti invece di scoprirlo alla fine con conseguenze dannosissime

Ho,infine, aggiunto:

• una categoria “Legenda” che riportava le descrizioni delle diverse icone o simboli grafici presenti
• una categoria “Agenda” che riassumeva i macro-punti che sarebbero stati discussi nel meeting
• Una categoria “Attendees” che elencava i partecipanti al kick-off

Il kick-off è andato benone.
Ho potuto mostrare la nostra idea di implementazione del progetto e raccogliere diversi suggerimenti, correzioni, aggiustamenti da parte del cliente.

I punti nella categoria “Open Point” sono stati tutti completamente evasi ed hanno ricevuto le risposte attese.

Gli stessi, a fronte delle risposte, sono stati inclusi nella categoria “Decisions”.

E’ stata prevista un’ulteriore categoria “Action Points” in cui sono state aggiunte le azioni immediate che si sarebbero dovute svolgere e a carico di chi.

Infine sono state aggiunte alcune segnalazioni nella categoria “Risks”.

La mia mappa alla fine conta le seguenti categorie:

• Legenda
• Agenda
• Attendees
• References
• Functionalities
• Stakeholders
• Systems Involved
• Applications Roles
• WBS
• Draft Layouts
• Deliverables
• Decisions (prima chiamata Open Points)
• Action Points
• Risks

Ora non mi rimane che utilizzare una delle funzionalità di cui sono più innamorato di MindJet MindManager: l’esportazione in word. Questo permetterà la redazione della meeting minutes in pochi minuti, la spedizione agli altri partecipante del kick-off e finalmente….possiamo cominciare a lavorare.

Un buon kick-off non garantisce certo la riuscita del progetto, ma sicuramente siamo riusciti a creare commitment, responsabilità e chiarezza su cosa e come dovrà essere fatto il lavoro e chi e quando dovrà essere svolto.

Risk Management Checklist

Riprendiamo un argomento fondamentale per favorire il successo del progetto: la gestione dei rischi. In un precedente post ho descritto un possibile approccio alla definzione dei rischi, in questo post cercherò di evidenziare aclune aree da indagare per abbatterli.

Questo post è disponibile ai soli utenti registrati. La registrazione è libera.
Per procedere alla registrazione cliccare sulla voce “Amministrazione/Registrati” nella side-bar di destra.
This post is available only to the registered users (free). Please register using the voice “Administration/Register” on the right side-bar.

Stakeholders Analysis

Questo post è disponibile ai soli utenti registrati. La registrazione è libera.
Per procedere alla registrazione cliccare sulla voce “Amministrazione/Registrati” nella side-bar di destra.
This post is available only to the registered users (free). Please register using the voice “Administration/Register” on the right side-bar.