Il project manager e il triatleta

Permettetemi questa pazza divagazione.
Sino a un paio di anni fà quando ancora impegni familiari e lavorativi lo permettevano, riuscivo con costanza a praticare il mio sport: il triathlon.
Sport articolato e per certi versi complesso, che richiede versatilità e resistenza.
Per carità, nulla che una qualsiasi persona che eserciti il nuoto, il ciclismo e la corsa non possa fare, ma certamente praticare tutti e tre gli sport non è comunque cosa usuale.

Ed è proprio durante uno degli ultimi allenamenti in piscina (che solitamente faccio in pausa pranzo) che i pensieri lavorativi hanno avuto il sopravvento sulla concentrazione e mi sono ritrovato a pensare, bracciata dopo bracciata, a quanti punti in comune esistano tra project manager e triathleta.
Battute a parte sul cloro e dei danni al cervello che può provocare, seguite il ragionamento.

Italiani Imperia

Poliedricità

Il triathleta deve conoscere e governare tre differenti dicipline: il nuoto, il ciclismo e la corsa e non deve assolutamente sottovalutare le due transizioni nuoto-ciclismo e ciclismo-corsa, pena la perdita di svariati secondi.
Il project manager deve avere grandi doti comunicative, una buona conoscenza tecnica applicata al settore lavorativo e ottime capacità manageriali, con una buona propensione al rischio che gli permetta di affrontare fiducioso le diverse sfide quotidiane.

Entrambi possiamo definirli poliedrici: hanno molteplici capacità, in campi diversi e si giovano di caratteristiche di agilità e versatilità.

Tecnica, strategia e resistenza

Parallelismi ulteriori possono essere trovati a carico delle differenti discipline.
Sul fronte del triathlon, il nuoto è la disciplina più complessa: si svolge in un elemento non sempre congeniale all’uomo, l’acqua appunto, e chi lo pratica deve conoscerne approfonditamente la tecnica.
Il ciclismo, richiede un mix di tecnica, intelligenza tattica e grosse doti di resistenza.
La corsa, infine, una dose sufficiente di tecnica, grossa resistenza e molto “cuore”.

Il project manager deve conoscere differenti tecniche nelle diverse aree della sua attività (brainstorming, WBS, SWOT, analogous/parametric estimating, earned value, ecc.) e anche essere un buon stratega o tattico nella conduzione del progetto, dove differenti personalità e interessi entrano in gioco.
Anche la resistenza fa parte del suo portafoglio di caratteristiche in quanto senza di essa e di fronte alle numerose difficoltà, potrebbe cedere e gettare la spugna.

Allenamento e passione

Punto fondamentale.
La tecnica non potrebbe progredire senza l’allenamento: la ripetizione del gesto nel tempo, con l’unico scopo di renderlo sempre più ottimizzato, armonico, perfetto.
La resistenza non potrebbe progredire senza l’allenamento: il corpo compensa e si adegua a ritmi e stimoli esterni modificando il proprio stato.
L’intelligenza tattica non potrebbe progredire senza l’allenamento: è solo allenandosi e ponendosi in situazioni simili alla gara che si possono raffinare quei processi mentali che ci permettono di fare deduzioni, collegamenti, parallelismi.

L’allenamento poi, unito alla passione, sublima la tecnica sino quasi a farne un’estensione del proprio io.
Concetto un pò zen, certo, ma tornando alla concreta realtà, ve lo ricordate il sorpasso all’ultima curva del gp di Barcellona di Valentino Rossi?

E dove la mettiamo la comunicazione? Quel 90% di tempo speso dal project manager?
La caratteristica fondamentale delle sue attività?
Il triathleta non comunica.
Ecco l’eccezione…che conferma la regola!

E’ vero, il triathleta non comunica, lo fa raramente; personalmente solo quando cerco di spiegare ai compagni della frazione in bici che mi imprecano contro, che non faccio il furbo, ma che non ne ho abbastanza per andare in testa a tirare.

Per finire,  ecco forse l’ultimo dei punti in comune tra le due figure: la solitudine della responsabilità.
Un proverbio sul project management dice: “Il project manager deve aiutarsi da solo. Nessun altro lo potrà fare”.
Vale anche per il triathleta.

Comprimiamo lo schedule

Lo so, le frasi “comprimiamo lo schedule” o “accorciamo i tempi di consegna” vi fanno venire i brividi; soprattutto negli ultimi tempi sembra essere diventata la frase più in voga e più nominata da clienti o commmittenti di progetto.

Anche da noi in Diesys capita spesso di fare improvvise accelerazioni e questa settimana, per esempio, ha visto impegnato una parte del team nel cercare di comprimere i tempi di rilascio di una deliverable di progetto.
Stiamo infatti sviluppando un’applicazione di trouble ticketing (TicketIT), inizialmente nata per uso interno, che però ci è stata chiesta a inizio settimana in visione da un cliente.

L’applicazione essendo nata per solo uso interno, navigava tranquilla con un rank low-priority, in mari calmi e poco increspati; l’interesse del cliente però ci ha dato lo spunto per metterci alla prova e soprattuto ha imposto una deadline (scade oggi) per la creazione di una demo funzionante.

Vediamo la teoria; quando si parla di compressione dello schedule tornano alla mente studi approfonditi sul PMBOK o letture “agili” fatte qua e là.
Il PMBOK terza edizione [1],  nomina due tecniche precise di compressione: crashing e fast tracking; mentre l’agile software developmente ce ne regala un’altra: lo sprint.

Crashing

Un tipo specifico di tecnica di compressione della schedulazione del progetto eseguita mediante la diminuzione della durata della schedulazione di progetto dopo l’analisi di un certo numero di alternative allo scopo di determinare come ottenere la massima compressione della durata della schedulazione al minor costo aggiuntivo. I sistemi adottati più comunemente per la compressione dei tempi di una schedulazione prevedono la riduzione delle durate delle attività schedulate e l’aumento delle risorse assegnate alle attività schedulate.   [1]

Fast Tracking

Tecnica specifica di compressione della schedulazione del progetto che consente di modificare la logica del reticolo per sovrapporre le fasi che verrebbero in genere svolte in sequenza, come la fase di progettazione e quella di costruzione, o per eseguire in parallelo le attività schedulate. [1]

Sprint

Le metodologie agili invece definiscono uno sprint come una normale iterazione di 2/4 settimane che porta allo sviluppo di una parte perfettamente funzionante di prodotto, poi rilasciata al cliente

Vantaggi e  Svantaggi

Tutte e tre le tecniche hanno ovviamente pregi e difetti.
Il crashing, spesso osteggiato da molti, può portare invece che a riduzioni, ad aumenti di tempi: pensate infatti ad un’attività mediamente complessa, in carico ad uno specifico membro del team, che poi verrà suddivisa su due o più persone. Ci dovrà essere un tempo minimo di passaggio di consegne e una inziale forte dipendenza delle risorse aggiunte dalla risorsa originale.

Il fast tracking da questo punto di vista sembrerebbe essere meno “scomodo”: le risorse aggiunte lavorano su attività diverse.
Aumentano però i rischi complessivi: dobbiamo eseguire parallelamente attività nate per essere svolte in sequenza.

Infine lo sprint è strettamente legato alle metodologie agili e quindi il team deve conoscere ed essere disciplinato nell’eseguire iterazioni che concorrono allo sviluppo di blocchi funzionanti di codice.

Il nostro approccio

In questi giorni abbiamo cercato di mettere insieme le tre tecniche dedicando quattro differenti risorse al progetto.
In primo luogo abbiamo diviso gli interventi in aree funzionali e assegnato ad ogni area una priorità (plan/feature backlog).
Ad ogni risorsa è stata assegnata un’area funzionale e la responsibilità di portare a compimento le specifiche funzionalità (task/backlog).
Tali risorse di fatto stavano mettendo in pratica la tecnica di fast-tracking.
Per ridurre i rischi derivanti dall’esecuzione di differenti attività in parallelo, abbiamo identificato un coordinatore (scrum master?) che funge da collante nel team.
Il coordinatore ha poi di fatto svolto indirettamente anche funzioni di crashing (o di pair-programming) perché spesso si è trovato a sviluppare parti di codice inerenti la stessa attività con altri team di progetto.

Il risultato effettivo finale lo attendiamo nel primo pomeriggio.
Un prima considerazione che può essere tratta riguarda il team che mette in pratica tali tecniche: è necessario che tutti i membri condividano l’obiettivo finale, siano motivati, pronti a mettersi in gioco e soprattutto che abbiano una buona competenza tecnica.

Fortunatamente il mio team ha dimostrato in pieno tali competenze….e voi là fuori, avete fatto esperienze simili?

[1] PMBOK Third Edition  – Project Management Institute

Il project manager e l’evoluzione della specie

De Qualitate è una rivista edita da Tecna che tratta temi inerenti la qualità e la sicurezza, con un giusto equilibrio tra teoria e tecnica.
Ospiterà sul numero di novembre un mio articolo che pone il focus sull’evoluzione della specie del project manager negli ultimi anni, dove riduzione costi, avanzamenti tecnologici e contrazione dei tempi stanno drasticamente cambiando l’approccio alla gestione del progetto.

Trovate qui l’anteprima dell’articolo gentilmente concessa da Tecna Editrice.

Alla prossima.
Have fun

Il viaggio verso la certificazione PMP

Un amico in cui mi chiede informazioni riguardo alla certificazione PMP (Project management Insitute). Ne parlo in questo spazio perché, sebbene non eccessivamente complesso, è piuttosto articolato e riassumerne qui i passi potrebbe essere d’aiuto in generale a tutte le persone interessate alla certificazione.

Innanzitutto è bene partire dal sito del PMI e più in dettaglio dal PMPHandBook che spiega dettagliatamente tutti i passi per l’ottenimento e mantenimento della certificazione: è la bibbia della certificazione PMP.

Pre-requisiti

Esistono alcuni pre-requisiti necessari che permettono alla persona di presentare domanda di candidatura.
Tali requisiti sono:

• background scolastico
• ore di formazione specifiche sul project management 
• esperienza effettiva di conduzione di progetti in almeno uno dei cinque gruppi di processo  (**)

Esistono due differenti categorie di requisiti che vengono pilotate dal background scolastico: diploma di scuola superiore o laurea. Nell’ambito di ognuna devono essere totalizzate un certo numero di esperienza diretta e di ore di formazione.
Le ore di esperienza devono essere maturate negli ultimi otto anni prima della presentazione della richiesta di candidatura.

Esperienza maturata

Chi è in possesso di un diploma di scuola superiore deve dimostrare di aver totalizzato almeno 5 anni/60 mesi, non sovrapposti, di esperienza nel project management, durante i quali almeno 7.500 ore sono state spese nella direzione/conduzione di attività di progetto.

Chi è in possesso di una laurea deve dimostrare di aver totalizzato almeno 3 anni/36 mesi, non sovrapposti, di esperienza nel project management, durante i quali almeno 4.500 ore sono state spese nella direzione/conduzione di attività di progetto.

Formazione

Per entrambe le categorie sopra sono necessarie 35 contact hours.
Una contact hour è equivalente ad un’ora di training o istruzione ricevuta nei modi e presso le strutture che potete trovare qui (*) o nell’Handbook sopraccitato (pag. 8).

L’esame

L’esame si può sostenere presso uno dei prometric center autorizzati e può essere svolto tramite l’utilizzo di un pc o in forma scritta.
L’esame si articola in 200 domande, 175 saranno valutate  e altre 25 no perché introdotte solo a scopo di survey (ma ovviamente non sappiamo quale esse siano e quindi dobbiamo rispondere esattamente a più domande possibile).
La risposta è selezionabile tra quattro possibili.
Il tempo a disposizione è di 4 ore e la percentuale di domande esatte per passare l’esame si articola intorno al 65/70%.
E’ interamente in inglese, ma è possibile richiedere una seconda lingua.
Il costo dell’esame si aggira tra i 350 e i 450 euro a seconda che si è già membri o meno del PMI.

Lettera di candidatura

Bene, questo è il momento più noioso: dobbiamo andare indietro di 8 anni, verificare le ns esperienze, tracciarne le ore di lavoro, verificare che non vi siano sovrapposizioni, in tal caso si possono solo riportare le ore di un singolo progetto, verificare che appartengano alemno ad uno dei cinque gruppi di processo PMI (**).
Ah, non dimentichiamo di riportare i dati relativi al conseguimento di diploma o laurea e all’ottenimento delle famose 35 di contact hours.

Studio

Giunti qui dovreste aver già svolto il corso di preparazione che non è obbligatorio ma, dal mio punto di vista è consigliato.
Consigliato perché solo persone che insegnano e trattano giornalmente questi temi sanno darti indicazioni, suggerimenti, punti di vista, chiavi di lettura che da solo difficilmente riusciresti a fare tuoi.

Da dove parto?

Ovviamente dal PMBOK!
E’ la pubblicazione principe del PMI; è arrivata alla quarta edizione ed è il riferimento su cui si basa l’intero esame.

Attenzione però: pensare di studiare soltanto il PMBOK e sostenere l’esame, potrebbe essere un errore.
L’esame infatti tiene conto del fatto che se tu sei arrivato a poterlo dare, vuole dire che hai dalle 4500 alle 7500 ore di esperienza e questa spazia in tutti i campi del project management; scopo, tempi, costi, qualità, risorse umane, comunicazione, rischi, approvigionamento.
E’ per questo che è consigliata la lettura di altri testi inerenti il project management (vi dice niente il Kerzner?).

Ispezione

Finisco con la ciliegina sulla torta: nel momento in cui avrete terminato il vostro percorso di studio e siete pronti per dare l’esame, all’atto dell’iscrizione, e solo dopo aver pagato, potreste essere estratti per un’ispezione.
La percentuale di probabilità che questo possa capitarvi (indovinate un pò a chi è capitato?) non è chiara alcuni dicono il 10 altri il 15 e altri ancora il 20%.
Se vi dovesse capitare, dovrete dimostrare spedendo tutti i documenti del caso, che quanto dichiarato in termini di background scolastico, formazione e esperienza maturata corrispondano al vero.

Conclusioni

Non vi scoraggiate, assolutamente non fatelo.
I vincoli e le restrizioni imposte, se ci pensate bene, vi tutelano: il valore di questa certificazione è dato anche da queste caratteristiche; il cliente che vi saprà certificato saprà implicitamente della vostra esperienza pregressa e della vostra professionalita.
Lo studio inoltre vi aprirà porte e conoscenze impensate: il valore della mia certificazione non sta nella spilletta con scritto sopra PMP, ma nell’esperienza che ho maturato durante lo studio.

Ovviamente è un viaggio, che può durare diversi mesi e come ogni viaggio c’è da imparare, studiare, lavorare ma alla fine ne sarà valsa la pena.

(*)
A. PMI Registered Education Providers (R.E.P.s)
B. PMI Component organizations
C. Employer/company-sponsored programs
D. Training companies or consultants
E. Distance-learning companies, including an end-of-course assessment
F. University/college academic and continuing education programs

(**)
Initiation
Planning
Executing
Monitoring and Controlling
Closing

La WBS (work breakdown structure)

Il PMBOK terza edizione, suggerisce la seguente definizione:
“Scomposizione gerarchica orientata verso i deliverable del lavoro che deve essere eseguito dal gruppo di progetto, per realizzare gli obiettivi del progetto e creare i deliverable richiesti. Organizza e definisce l’ambito complessivo del progetto. Ogni livello discendente rappresenta una definizione sempre più dettagliata del lavoro del progetto. La WBS viene scomposta in Work Package.”

In sostanza una sorta di scomposizione delle funzionalità previste, ma anche di tutte quelle parti non riconducibili a caratteristiche di prodotto ma che rappresentano attività di progetto vere e proprie (test, redazione help, meeting, rilasci, ecc.). Ciò appena descritto rappresenta la differenza principale tra WBS di progetto e WBS di prodotto.

 Una volta scoperto “l’arcano”, mi risollevai considerando che sino a quel momento avevo, involontariamente, sempre incluso una WBS nelle analisi di dettaglio e che semplicemente la chiamavo “scomposizione delle funzionalità”.

 Ad oggi ho utilizzato tre diversi layout per rappresentare una WBS: grafica, tabellare e di testo.

 

 In generale trovo più comodo utilizzare la WBS in formato grafico, quando mi rapporto con il team e sto conducendo una review: riesco meglio a comprendere a che punto siamo arrivati e quail rami stiamo sviluppando.
Quella tabellare, forse più elegante, la utilizzo nel project plan per garantire a me stesso e al cliente massima chiarezza nella suddivisione del lavoro attraverso la codifica chiara e strutturata, che poi porta all’identificazione univoca delle deliverable.
Quella più diretta in formato testo, tendo ad utilizzarla in documenti draft propedeutici alla formalizzazione del project plan finale.

Poi, procedendo negli studi e soprattutto grazie a mr Kerzner, e nella pratica grazie ai miei clienti, mi sono reso conto di quanto fosse centrale la WBS anche per le seguenti tematiche:

1. Assegnazione delle responsabilità
2. Totalizzazione dei costi per attività, work package, deliverable
3. Contabilizzazione dei costi per centri di costo (appunto)
4. Definizione di un roll-out plan per deliverable
5. Utilizzo delle attività scomposte per favorire le stime tempi/costi
6. Analisi degli stakeholders e loro influenza rispetto alla WBS
7. Risk analysis
8. Issue log communication

A breve fornirò maggiori indicazioni su come utilizzo la WBS come strumento base per procedere ai punti sopra esposti.

Have fun!

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.

Creatività e Talento

Oggi ho avuto il piacere di partecipare ad un workshop dal titolo “L’intelligenza Creativa” tenuto da Irene Bursese, organizzato dal PMI-NIC.
L’evento poneva al centro la creatività, definendone i tre pilastri portanti: talento, energia e metodo.
Il workshop è stato interessantissimo e nei prossimo giorni cercherò di raccontarne l’esperienza fatta e che mi sono portato a casa.
Oggi però vorrei riportare qualche appunto dedicato al talento.

Sul talento ci sarebbe da dire veramente tantissimo.
Solitamente pensiamo al talento come ad una caratteristica che hanno in pochi, che è in grado di liberarsi autonomamente e che una volta accaduto, verrà celabrata da tutti in quanto sinonimo di eccellenza.

Ma cos’è il talento? Ed è veramente una caratteristica “donata” a pochi?

Diversi libri (tra cui *1*) sostengono che il talento sia uno schema, un pattern ricorrente di pensieri, sentimenti, comportamenti che possono essere applicati produttivamente alla vita di tutti i giorni, lavorativa e non.
Questo pattern, chiamato anche filtro comportamentale, è presente in ognuno di noi, ovviamente con diversi gradi di “efficienza” e il fatto che si trasformi o meno in talento, è dovuto esclusivamente al fatto di riuscire a dare loro libero sfogo, riuscendo ad applicarli, per esempio, nella vita lavorativa quotidiana.

Riuscite ad immaginare Michael Jordan dietro ad una scrivania di una banca o Valentino Rossi impiegato in una catena di ristorazione?
E’ difficile ovviamente, ma in entrambi i casi, anche se con risultati probabilmente buoni, non eccellerebbero come riescono a fare nei rispettivi sport.

Il talento quindi lo possiamo definire come l’insieme di comportamenti che ti trovi a praticare più spesso nella vita di tutti i giorni. Quel filtro mentale che ti permette di notare cose o raccogliere stimoli che passano inosservati ad altri.
Per deduzione quindi, la chiave che porta a performance eccellenti è quella che trova una connessione diretta tra talento e ruolo lavorativo.

Questa definizione pone in serio imbarazzo alcuni manager, soprattutto quelli di vecchio stampo.
Per loro, il talento dei collaboratori, doveva passare obbligatoriamente attraverso una tendenza continua al miglioramento non solo dei tratti lavorativamente “più naturali” ma anche, e soprattutto, di quelli che denotavano maggiori debolezze.
Questo portava e porta tuttora molte persone a dedicare e sprecare energie alla disperata ricerca di migliorare quei tratti di sé meno nobili, invece di investire a piene mani su quelli realmente talentuosi.

Ogni manager, e di riflesso anche ogni subordinato, dovrebbe esercitarsi nello svolgimento della SWOT analysis. Rivolgendo questo strumento sia verso se stesso, sia verso gli altri.
Tale tecnica applicata ad un soggetto (persona o progetto che sia) mira al riconoscimento delle forze (Strenght) e debolezze (Weakness) del soggetto stesso, e a quali opportunità (Opportunities) o minacce  (threats) ci si possa esporre in caso di utilizzo dell’una o dell’altra.

In questo modo ognuno di noi, riconosciute le proprie forze, può agire costantemente al loro miglioramento, aprendo di fatto la strada per la scoperta del proprio talento, alla sua giusta applicazione produttiva e alla raccolta delle relative opportunità.

I manager, ahimé, hanno un compito assai più arduo: non solo sono chiamati a lavorare sulle proprie forze, ma questa analisi la devono svolgere anche nei confronti dei collaboratori, aiutandoli nella loro ricerca e incanalando i loro sforzi lavorativi nella giusta direzione, evitando di metterli inutilmente sotto pressione per le loro debolezze.

I manager, per rincarare la dose, dovrebbero avere inoltre, la capacità di dedicare attenzione anche alle loro debolezze, senza che questo diventi centrale nella loro attività di crescita costante, ma semplicemente per conoscere meglio se stessi e tentare, di tanto in tanto, di migliorare anche questi ultimi aspetti.

Il mantra dei grandi manager dice:

“Le persone tendono a non cambiare il proprio comportamento.
Non perdere il tuo tempo nel tentare di porre al loro interno ciò che all’origine è stato lasciato fuori.
Cerca invece di tirare fuori ciò che è rimasto ancora dentro…sappi che questo, di per sè, è già abbastanza arduo.”

Alla prossima.

bibliografia:
*1*
“First, break all the tules. What the world’s Greatest Managers do Differently”Marcus Buckingham and Curt Coffman

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