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.

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.