Cosa si richiede a un progetto per decretarne il successo? Fondamentalmente che i suoi benefici siano assicurati e che rispetti budget e tempi definiti. Purtroppo sono pochi a rispettare tutti i requisiti e diversi falliscono sotto tutti i punti. Perchè? Non esiste certo un unico fattore alla base del fallimento bensì molti elementi che possono concorrere a un cattivo risultato. Secondo studi e ricerche, vediamo i principali.
Se il committente (cliente o membro interno all’azienda) non è coinvolto nella realizzazione di un progetto rischia di perdere interesse o, peggio, di non riuscire a esprimere adeguatamente le proprie aspettative. Addirittura, può capitare che gli venga impedito di farlo. Questo può generare inconscia ostilità, soprattutto per i progetti IT (ad esempio, per un software sviluppato in autonomia dal fornitore).
Perché un progetto risulti utile sono necessari i proverbiali tempo e voglia che, in un ambiente di lavoro impegnativo, sono difficili da trovare, col rischio di scarso coinvolgimento. Per incrementarlo, è altresì fondamentale concordare i contenuti del progetto, gli obiettivi e i benefici. Anche in questo caso è calzante l’esempio di progetti IT (contenuti = requisiti), dove incomprensioni e cambi di rotta in corso d’opera possono portare a conseguenze disastrose.
Economiche (budget), umane (personale o professionisti qualificati), tecniche (pc, software, database) o logistiche (spazi adeguati, mezzi) che siano, le risorse destinate al raggiungimento degli obiettivi di progetto vanno identificate la loro disponibilità assicurata. Pena risultati discutibili, nonché costi maggiori dovuti a una scarsa produttività.
Poiché il contesto di riferimento delle aziende cambia con grande rapidità, progetti di lunga durata potrebbero andare incontro a rischio di obsolescenza, non solo tecnica ma anche di mercato o gestionale. Di certo, è meno rischioso se un progetto di dimensioni importanti viene scorporato in progetti più piccoli e di durata limitata, per consentire un aggiustamento progressivo dei contenuti e dei requisiti.
Parimenti, rappresenta una difficoltà la realizzazione di progetti con deadline troppo stringenti o addirittura irrealistiche, che non tengono in adeguata considerazione la mole di lavoro che richiedono. Questa criticità va gestita attraverso il coinvolgimento attivo dell’intero project team nel raccogliere le eventuali perplessità sulla possibilità di realizzare il progetto in tempi stabiliti.
I contenuti del progetto, per via dei mutamenti di contesto o a causa delle mutevoli necessità del cliente, tendono a crescere nel corso del suo svolgimento (sviscerandone le potenzialità, vengono individuati nuovi elementi da aggiungere a progetto iniziale), influenzando carico di lavoro, tempi e costi. Se è vero che si tratta di un problema di change management del project manager, è anche vero che il cliente deve essere realistico rispetto agli obiettivi prefissati inizialmente e rimanervi coerente.
La pianificazione effettuata in fase di avvio del progetto non è sufficiente; va modificata e aggiornata nel suo svolgersi, scendendo nel dettaglio per essere sufficientemente accurata e prevedendo margini per le modifiche in corso d’opera. Vanno inoltre studiati casi analoghi da cui trarre insegnamento per le criticità simili, per evitare di incappare negli stessi errori.
La mancanza della pianificazione in corso d’opera è quasi sempre diretta conseguenza dell’assenza di un monitoraggio adeguato, che dovrebbe determinare se il planning iniziale è ancora coerente e identificare le eventuali azioni correttive.
In ultimo devono essere definiti, oltre a ruoli e responsabilità, anche i possibili rischi condivisi con il project team perchè il project management non è un certo processo lineare ma interattivo e soggetto a continue modifiche.
Grazie è un’utile di sintesi del più articolato piano qualità progetto delle ISO 9001.
Ottimo memo non dico quotidiano ma quasi.
Non so se vi possa essere utile ma avendo letto troubleshooting tra i punti che suggerite di tener presente avevo pensato che fosse un errore perché avevo in mente il troublesoothing (risoluzione, mitigazione dei problemi) che si trova in qualche manuale d’istruzioni. Invece esistono entrambi (verificato su Wikipedia…) con troubleshooting (sparare il problema…?) nell’accezione più comune e forse più aggressiva d’ individuazione, ed “eliminazione” del problema…. Forse tutt’e due possono essere utili..
Saluti comunque e buon lavoro
Uranio