I progetti non sono eventi che accadono e basta, ma vengono pianificati. L’intero team di progetto infatti dovrebbe sviluppare il piano, non dovrebbe essere soltanto il project manager a farlo. Questo assicura che l’esperienza del team venga presa in considerazione e che ognuno sia completamente coinvolto nel progetto ed abbia padronanza del piano. Un buon progetto fornirà i seguenti elementi:

• una roadmap che ogni membro del team possa seguire e che sia formata da milestones chiare e ben definite;
• una scala temporale di progetto realistica;
• i dettagli dei requisiti delle risorse;
• la validazione della stima dei costi;
• l’identificazione dei possibili ritardi dei task;
• avvisi preventivi sui problemi.

E’ senz’altro di aiuto utilizzare le esperienze precedenti, ovvero i dati storici, acquisite durante i progetti precedenti:

• quanto tempo è stato necessario per completarlo?
• quanto è costato?
• quali sono state le aree problematiche?
• quali sono state le aree di successo?

Condurre un progetto senza una pianificazione è letteralmente una follia. Lavorare senza sapere dove si sta andando è il presupposto per il sorgere dei problemi e del fallimento. Condurre un progetto senza un piano è praticamente come cercare di trovare la strada giusta in una città che non abbiamo mai visitato e non avere a portata di mano una mappa. "Se sbagli a pianificare, stai pianificando il fallimento" è uno dei detti più noti nel project management.

Work Breakdown Structure (WBS)

Per poter identificare i task individuali in un progetto è molto utile creare una Work Breakdown Structure. La WBS è il fondamento per una pianificazione di progetto dettagliata. Il primo passo è di riunire il team e creare un brainstorming per tirar fuori tutti i "Deliverables"del progetto, ovvero, tuttile componenti, i rilasci che dovranno essere consegnati al per completare il progetto. I deliverable vengono chiamati anche WBE, Work breakdown Element ( vedi figura in alto) .A questo punto vanno individuate tutte le attività che sono necessarie per la costituzione del deliverable. Dovrete individuare cioè i task ed i sotto task di progetto, senza un ordine particolare. Scriveteli su dei post-it ed attaccateli su una lavagna. Una volta che ciascuno ha pensato tutti i task possibili, suddividete i task in gruppi sotto le aree principali di attività. Aggiungete, modificate, rimuovete e riordinate i post-it fino a che la WBS non è accurata, completa e logica. Lo scopo di una WBS è quella di decomporre il progetto in passi.

L’importanza del piano di Risk Management

 
Il rischio per un progetto rappresenta la forza di gravità del mondo intorno a noi. Il Rischio è inerente al processo di gestione dei progetti, sia che scegliamo di riconoscerlo oppure no. Come la gravità, il rischio può essere sia un beneficio ché un danno per i nostri progetti. Uno sciatore infatti utilizza la gravità per spingersi giù su una discesa, avendo ben chiaro il fatto che la stessa forza di propulsione potrebbe anche danneggiarlo se all’improvviso dovesse cadere. Come lo sciatore, i project managers devono capire che il rischio esiste e che può avere delle conseguenze buone oppure cattive su ciascun progetto.

 
Rischio: pianificazione ed identificazione

 
Quali sono i migliori approcci per un project manager che vuole gestire la paura delle forze sconosciute che circondano il progetto stesso? La prima cosa che dobbiamo considerare è la pianificazione del rischio, in maniera tale da creare un approccio consistente alla gestione del rischio di progetto. Come tutte le pianificazioni di progetti, anche la pianificazione del rischio viene fatta in maniera iterativa, e mai una sola volta.

 
Per i project manager abbastanza fortunati da aver accesso ad un Project Management Office (PMO) efficiente, il risk planning può essere portato a termine seguendo una metodologia di risk management. In assenza di tali risorse, un project manager dovrebbe documentare il piano di risk management con un approccio standardizzato. Questo comprende sia come vengono identificati i rischi e qual è il loro punteggio, oltre agli imprevisti e coloro che se ne occuperanno.

Dopo di ché l’altro approccio è l’identificazione del rischio. Tralasciare questo punto sarebbe come tralasciare del tutto il risk management. Se i project manager non mettono in atto nessun’altra procedura riguardante il rischio, dovrebbero almeno considerare di mettere in atto una procedura di identificazione del rischio.

La procedura di identificazione del rischio non deve essere ingombrante, formale o noiosa. Infatti un buon project manager userà tale procedura per trarne degli ulteriori benefici per il team di progetto. Ad esempio, utilizzando una tavola rotonda come procedura di identificazione del rischio, si possono creare le fondamenta per una coesione tra i membri del team di progetto.
Dal momento che le idee ed i suggerimenti vengono direttamente sollecitate da coloro che contribuiscono attivamente al progetto, essi accrescono la propria sensazione di dare un contributo sostanziale al progetto.

[....continua....]
 

L’ARTE DELLA PIANIFICAZIONE

Nella fase di pianificazione, dovrete essere in grado di fare molto di più di quanto il mero progetto mette a portata di mano. Sarete anche in grado di designare il quadro generale del lavoro del vostro team, scegliendo e assegnado alle risorse i vari tipi di attività.

Chi ne sa di più?

Chiedi al tuo team. I membri del tuo tem dovrebbero essere coinvolti nella pianificazione del progetto anche ai livelli più bassi della work breakdown structure. In questa maniera non si sentiranno solo una fonte di idee e informazioni, ma vere e proprie risorse coinvolte nella pianificazione.

Questo non significa che i vostri progetti dovrebbe essere pianificati da un comitato, piuttosto che voi, in qualità di manager, dovreste pianificare il progetto sulla base di tutte le esperienze e le idee creativedisponibili . Come approccio iniziale, potreste provare con il primo livello della work breakdown structure, buona occasione anche per comunicare il progetto alla squadra, chiedendo poi i loro commenti. Questi potrebbero successivamente essere perfezionati estendendo le informazioni al resto del team fino a livelli più bassi.

Pericoli nel riesame

Ci sono due errori da evitare nel riesame dei progetti:

• Possono essere troppo frequenti
  
• Possono essere troppo drastici
  
  

La revisione costante di nuove informazioni può portare a un circolo vizioso di pianificazione e  revisione che può minare alla fiducia della squadra in qualsiasi versione particolare del progetto e che può sgretolare la stabilità che la struttura generale dovrebbe far trasaprire. Dovrete scegliere un punto di equilibrio. Scegliere un punto all’orizzonte e camminare con fiducia verso di esso. Decidere obiettivamente, e capire preventivamente quando le fasi di revisione sono necessarie, rappresentando una milestone da inserire a calendario.

Anche se la situazione potrebbe essere cambiata dopo l’ultima revisione, è importante riconoscere il lavoro che è stato compiuto durante il periodo interinale. Quest’ultimo non dovrà essere abbandonato in quanto la squadra si sentirà demotivata, avendo la sensazione di non aver ottenuto niente. In secondo luogo, il vecchio lavoro farà parte della nuova situazione: è stato fatto, dovrebbe fornire una base per il prossimo passo, o almeno la base di una lezione ben imparata. Cerca sempre di costruire su quanto già realizzato della vostra squadra.

Testing and Quality

Nessuna pianificazione è completa senza un’esplicita disposizione per i testing e per la qualità. In quanto project manager saggi, dovreste essere a conocenza che questo dovrebbe essere parte di ogni singola fase del progetto. Ciò significa che nessuna attività è completata fino a che non ha superato i criteri definiti che stabiliscono la sua qualità, e questi sono definiti in maniera migliore fin dal principio come parte della pianificazione.

Nel momento di definire il calendario per tanto, si dovrà includere per ogni attività la stima del tempo. Quindi la tua domanda non è solo: "quanto tempo ci vorrà", ma anche: "Quanto tempo occorrerà per la fase di testing". Chiedendosi entrambe le domande insieme, sorgerà spontaneo il problema nella fase iniziale di "come facciamo a sapere che abbiamo fatto bene" . quindi sarebbe preferibile svolgere la fase di test in parallelo con l’implementazione. Si stabilirà questa filosofia nella la tua squadra includendo il testing come un costo preventivato e giustificato.

Snellire per raggiungere lo scopo

Un altro motivo per fissare preventivamente i criteri per le fasi di testing è la possibilità di evitare futili accorgimenti per raggiungere la perfezione. Se hai ben motivato la tua squadra essi saranno fieri del loro lavoro e vorranno svolgerlo nel miglior modo possibile. Spesso questo significa preoccuparsi del proprio compito prestando attenzione anche ai dettagli. E’ pur vero ch ciò si traduce spesso in una perdita di tempo. Se tuttavia facciamo chiarezza sul cosa serve nel momento specifico, allora è più probabile riuscire a fermarsi quando il mini-obiettivo (spesso una milestone) è stato  raggiunto. È necessario quindi evitare generalizzazioni e di stabilire i confini! La cosa non è facile, ma indispensabile.

Lo stesso vale anche per la scelta degli strumenti o la costruzione dei blocchi del vostro progetto. Sebbene potrebbe essere bello utilizzare le versioni più moderne dei tools in commercio, per avere un’esatta corrispondenza alle vostre esigenze, spesso sarà sufficiente una versione un po’ più vecchia di ciò che vi serve, ma che ricoprirà altrettanto bene i vostri bisogni permettendo di raggiungiure ugualmento lo scopo. In molti casi la differenza non è vale il tempo che avrete bisogno di investire per sviluppare la nuova soluzione. Utilizzare quello che è disponibile, ove possibile a meno che la differenza nella nuova versione valga il tempo e il denaro richiesto.

In collegamento a tutto ciò inoltre, si dovrebbe scoraggiare l’eccessivo sforzo su alcuni aspetti del progetto che sono poco peculiari a quelli del lavoro. Nella fase specifica, si potrebbe cercare di eliminare questi attraverso la negoziazione con il cliente. Nella fase di implementazione si potrebbero tralasciare queste parti fino alla fine. La ragione di questo consiglio è che una parte generale del lavoro può essere adattata a molti casi particolari, in tal modo, se il lavoro è in una forma generale, si sarà in grado di riadattarlo rapidamente per altri progetti. D’altra parte, se si produce un progetto tagliato per adattarsi esattamente ad un caso specifico, potrebbe essere necessario ripetere l’opera integralmente, anche se il prossimo progetto fosse abbastanza simile. Nella fase di pianificazione , un manager dovrebbe tenere in mente il futuro interessandosi dello sviluppo a lungo termine del suo team, al pari dei requisiti del progetto corrente.

La lotta contro il tempo

In quanto project manager, è necessario che regoliate la pressione e il carico di lavoro imposto al team, è necessario proteggerli dalle richieste irragionevoli dal resto della società. Una volta arrivati a quello che riterrete essere uno scheduling realistico, combattete per esso. Non permettere mai che il mondo esterno devi da ciò che sappiamo essere pratico. Se imporranno su di voi scadenze e compiti impossibili, dovrete prendere la situazione in pugno  e spiegare le vostre ragioni. Tuttavia, avrete bisogno di scendere a dei compromessi,  dal momento che un secco NO sarà visto come un tentativo di ostruzione. Visto che vogliamo aiutare e consigliare la società, si dovrebbero cercare soluzioni alternative.

In una data antecedente alla scadenza, potreste anche rilasciare un "prototipo" del prodotto/servizio. Questo potrebbe, in alcuni casi, essere sufficiente al cliente per iniziare la prossima fase del suo progetto, fermo restando che il progetto sarà completato in una data successiva e la versione finale andrà poi a sostituire il prototipo.

La complessità del prodotto, o il numero totale di unità, potrebbe essere ridotta. Questo potrebbe, in alcuni casi, essere sufficiente per sopperire alle esigenze immediate del cliente. Ulteriori miglioramenti o più unità potrebbero essere oggetto di un negoziamento successivo. La probabilità di successo di questultimo sarebbe sicuramente avvertita in maniera più forte in quanto avreste già dimostrato la vostra capacità di consegnare in tempo.

È possibile infine mostrare in uno scheduling supplementare, come il progetto potrebbe essere consegnato entro la scadenza, solo se verrano fornite alcune specifiche risorse o se altri progetti verranno riprogrammati ad hoc. Così, si fornirà un quadro chiaro della situazione ed una possibile soluzione. Sarà poi compito della dirigenza scegliere come procedere.

Pianificare gli errori

L’errore più comune nella pianificazione è quello di ritenere che non ci sarà nessun errore in fase di attuazione: in effetti, il calendario è derivata, sulla base di "se non va male, ci vorrà …". Naturalmente, riconoscendo che gli errori sicuramente si verificheranno, è indispensabile l’attuazione di una strategia di monitoraggio sul progetto. Così, quando l’inevitabile accade, potrete reagire adattando il piano di indennizzo. Tuttavia, valutando accuratamente gli errori in anticipo è possibile apportare modifiche al progetto originario di incrementare, se necessario, la tolleranza. Molto semplicemente, la pianificazione dovrebbe comprendere il tempo in cui, stando alle spalle del progetto ci si chiede: "che cosa può andare storto?".  Questo è anche un ottimo sistema per chiedere al tuo team di fornire una loro analisi del piano.

Si potrebbe cercare di prevedere dove gli errori hanno più alta probabilità di verificarsi. Esaminando l’elenco delle attività di solito si ossono individuare alcune attività a maggior rischio (per esempio, quelli che coinvolgono nuove attrezzature) e quelle abbastanza sicure (per esempio, quelle già fatta in passato dal tuo team). Alle aree a rischio quindi, potrebbero essere assegnate tempistiche più larghe e meno rigorose, per essere in grado di rimediare in tempo agli errori. Un’altra possibilità invece è quella di applicare a tali attività una strategia diversa, o un numero superiore di risorse, allo scopo di ridurre al minimo le interruzioni. Per esempio, si potrebbero includere un addestramento o una consulenza per le nuove attrezzature, o si potrebbe parallelizzare il lavoro con risorse umane alternative.

Post-mortem

Alla fine di ogni progetto, si dovrebbe assegnare il tempo di riesaminare le sezioni e le informazioni sia del lavoro svolto che della gestione dello stesso: un meeting comune, con una discussione aperta che coinvolgerà il team, tutti i clienti e i fornitori. Se pensate che sia considerato tempo sprecato, pensate all’effetto questo avrà in futuro sulla comunicazione con i vostri clienti e fornitori.

PIANIFICARE IN VISIONE DEL FUTURO

Con tutte queste considerazioni limitate solamente alla fase di pianificazione, è forse sorprendente che i progetti in fin dei conti vengano effettivamente svolti. I progetti infatti, vengono sì svolti, ma spesso non nel modo corretto, con l’utilizzo di forzature da parte della dirigenza,  raramente con l’utilizzo di un’attenta pianificazione. La questione, tuttavia, è che questo metodo non è quello ottimale. I clienti si sentono delusi dalla consegna tardiva, il personale è demotivato dalla pressione costante per obiettivi impossibili, la vostra reputazione ne perderà.

Con la pianificazione, i progetti possono essere sviluppati in tempo e facendo inoltre interagire efficacemente clienti e fornitori. Tutti i soggetti coinvolti capiscono ciò che si vuole ed i problemi che emergeranno saranno sono viste e trattati molto tempo prima che possano causare danni. Se desiderate che i vostri progetti seguano questa strada, dovrete investire tempo nella Project Planning!.

Articolo basato sul libro "Starting to Manage: the essential skill" di Gerard M Blair. G.M. Blair , Senior Lecturer in VLSI Design at the Department of Electrical Engineering,  University of Edinburgh.