L’importanza del team

Se vuoi arrivare primo, corri da solo.
Se vuoi andare lontano, cammina insieme agli altri.
(proverbio del Kenya)

L’importanza del gruppo è risaputa e assodata.
E’ vero, il singolo è agile e risponde velocemente ai cambi di scenario, ma la fragilità dovuta a risorse limitate gli precludono molte delle strade percorribili.

La forza del gruppo deriva dal fatto che questo, nel suo complesso, ha risorse e conoscenze maggiori e, in teoria, nessun obiettivo gli è precluso.

La minore agilità potrebbe però pesare in situazioni che richiedono forte dinamicità.

Il team agile

La teoria agile ci insegna che se un team, comunque contenuto nei numeri, ha le caratteristiche che seguono, riesce ugualmente a fare fronte a situazioni di forti cambiamenti e flessibilità.

Caratteristiche principali di un team agile:

• Orientamento verso l’effettivo valore di business del cliente
• Competenze tecniche professionali elevate dei singoli
• Dimensione ridotta del team
• Auto-disciplina nella risoluzioni di conflitti
• Personalità dei membri orientata alla collaborazione
• Buone capacità di adattamento
• Disponibilità e apertura dei singoli, all’apprendimento

Un buon leader, quindi, deve essere in grado di scegliere le persone giuste e, dal mio punto di vista,  iniziarle alla disciplina agile, creando continui stimoli volti alla comunicazione e condivisione degli obiettivi.

In questo modo sarà per lui possibile puntare a mete difficilmente raggiungibili come singolo, ma più facilmente avvicinabili come gruppo.

Comunicare le responsabilità dei singoli

Altro fattore fondamentale nella gestione del team è la comunicazione.

Questa deve essere immediata, diretta (face-to-face), chiara, semplice (vedi post precedente ‘Comunicazione Agile’).

E’ necessario che ogni membro del team conosca in ogni istante le attività a lui assegnate e le relative responsabilità.

Per ottenere risultati certi è bene fare uso di strumenti di assegnazione delle responsabilità come i seguenti.

Diagrammi gerarchici:

• WBS: identificando il responsabile di ogni WorkPackage della WBS
• OBS: struttura gerarchica organizzata per funzioni, dipartimenti e persone che saranno coinvolte nel progetto
• RBS: struttura gerarchica organizzata per tipologia di risorsa, utile anche per tracciare i costi.

Diagrammi a matrice:

• RAM : usata per illustrare le connessioni tra il lavoro necessario e i membri del Team. Può essere vista come incrocio della WBS e della OBS.
• RACI (vedi post ‘Commitment e responsabilità’): particolare formato di RAM (Responsible, Accountable, Consult and Inform) che mostra anche il grado di  coinvolgimento ai vari livelli.

La delega

Il project manager ha un importante altro strumento per ottenere responsabilità e commitment dai membri del team e che, contemporaneamente, gli permette di “guadagnare” tempo sul progetto: la delega.

La delega è definita come il decentramento temporale di responsabilità senza modificare il ruolo del collaboratore perché è limitata nei contenuti e nel tempo.

Delegare significa quindi assegnare compiti e relative responsabilità ad altre persone, attribuendo loro gli strumenti di cui hanno bisogno per eseguirli, esigendo che rispondano dei risultati conseguiti.

Il processo di delega dovrebbe quindi tenere conto di:

• chi assegna la delega e chi la riceve
• a cosa è circoscritta la delega (contesto)
• quale responsabilità comprende la delega (raggiungimento obiettivi)
• quali gli strumenti forniti al delegato
• come misurare il risultato della delega

Crescita del team

Una volta responsabilizzato e allineato il team, è necessario poi procedere a svilupparne le competenze, sia in termini di technicalities sia di soft skills.

Questo è possibile dedicando l’opportuna attenzione alle seguenti tematiche:

• Fomazione: tutte le attività volte a migliorare le competenze del team.
• Team building: attività volte a migliorare la coesione tra i membri del team.
• Ground rules: stabiliscono regole chiare (ricordate la KISS rule?) per quanto riguarda l’approccio lavorativo dei  membri. Riducono conflitti e incomprensioni.
• Co-location: collocazione fisica dei membri del team nello stesso luogo per migliorare il lavoro di gruppo e favorire la comunicazione e la libera circolazione dell’informazione.
• Riconoscimenti: favorire i premi di tipo win-win (vince il gruppo) rispetto ai win-lose (vince uno e perdono gli altri). Devono essere chiari, espliciti e raggiungibili.

Mettendo in atto quanto sopra, si otterranno principalmente tre grossi vantaggi: miglioramento delle competenze dei singoli, aumento dell’efficacia complessiva del gruppo e sensibile diminuzione del turn-around tra i membri.

E secondo voi? Quanto è importante un team in un progetto?

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.

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

Il coltellino sWBSizzero (2^ parte)

Questa seconda parte del post sulla WBS si prefigge di affrontare la tematica della stima dei tempi e costi di un progetto.
Parleremo di scomposizione dei work package in attività, di scomposizione dell’attività in sotto attività e finalmente dell’utilizzo delle tre tecniche di stima più usate: analogous estimating, parametric estimating e three points estimation. 

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.

Il coltellino sWBSizzero

Nel precedente post ho parlato della WBS e delle sue molte applicazioni in ambito di project management.

Mi piace paragonare la WBS al famoso coltellino svizzero; quel coltellino, che nella sua versione originale è dotato di un classico manico rosso, con croce bianca ben in vista, composto da diverse lame e utensili richiudibili.
Spesso sono disponibili, lame a parte, delle piccole forbici, un cacciavite, una limetta, un cavatappi, una penna, un piccolo pettine.

Ecco quindi che potremmo presentare l’equazione: la WBS sta al project manager come il coltellino svizzero sta a MacGyver (ricordate il fantastico telefilm?).

Ecco gli utensili che la WBS ci mette a disposizione:

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

Il processo di ottenimento della WBS è un processo, tutto sommato, abbastanza naturale.

Avendo come base di partenza la risoluzione di un problema, questo viene prima scomposto in parti più piccole, successivamente per ogni sotto-problema si passa alla definizione delle ipotetiche/possibili soluzioni o approcci (brainstorming), tali spunti vengono poi categorizzati e valutati in una visione di pura fattibilità.

Questo processo, spesso iterativo, porta alla realizzazione di un elenco, molte volte strutturato su più livelli, che possiamo definire WBS.

Partendo da quanto ottenuto sopra, si passerà poi alla ulteriore scomposizione dei singoli work package (rami foglia della WBS) in singole attività.

Volendo fare un esempio, nell’ambito della definizione dell’interfaccia amministrativa di un’applicazione software, i work package potrebbero essere i seguenti:

• Gestione delle tabelle anagrafiche
• Gestione dei parametri di sistema
• Gestione degli utenti

Prendendo l’ultimo work package (Gestione degli utenti), l’ottenimento delle attività si ottiene con una successiva iteazione di  scomposizione:

• Ricerca utenti
• Inserimento utente
• Modifica utente
• Cancellazione utente
• Definizione dei permessi e visibilità

Partendo da qui, possiamo finalmente cominciare ad utilizzare i vari utensili anticipati sopra.
In questo post presento il primo: assegnazione delle responsabilità.

Assegnazione delle responsabilità

Spesso la responsabilità di esecuzione del lavoro, si assegna ad ogni singolo work package.

Qualora, però, il carico di lavoro fosse troppo oneroso è ovviamente possibile assegnarlo a più persone, ponendo il focus sulle singole attività.
Ogni persona deve sapere, con certezza e senza alcun dubbio, quale lavoro deve portare a termine, con quali caratteristiche e livello di qualità e in quali tempi.
In questo ci aiuta molto il classico gatt in cui ogni attività è descritta graficamente su un asse temporale e per ognuna viene eseguita l’assegnazione della/e risorsa/e, assegnando in alcuni casi anche il grado di coinvolgimento in percentuale di tempo.

In campo di assegnazione delle responsabilità, l’uso della WBS, è la base per la definizione della matrice delle responsabilità (RACI Matrix). Questa particolare matrice permette di assegnare per ogni singola voce della WBS, una responsabilità di tipo:

• R – Responsible, chi deve svolgere il lavoro e portarlo a termine.
• A – Accountable, chi è in ultima analisi effettivamente responsabile del raggiungimento dell’obiettivo di quella attività. Chi deve validare in ultima istanza, il lavoro svolto dal responsabile sopra descritto.
• C – Consulted, persona che deve essere consultata e con la quale ci deve essere uno scambio di opinioni rispetto a quel task, in quanto particolarmente interessata o qualificata in quell’area.
• I – Informed, coloro i quali devono essere informati sull’esecuzione delle attività correlate (spesso lo sponsor, il line manager o il management)

Nei prossimi post approfondiremo l’uso del pettine e del cavatappi….emmmhh scusate, dell’uso della WBS a fini di stima e totalizzazione dei costi.

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!