Perché i progetti finiscono sempre in ritardo?

Arduino,
i progetti che vanno in ritardo hanno tre caratteristiche:
a) sono venduti da commerciali che poco o nulla sanno della complessità del progetto stesso;
b) sono acquistati da clienti che, spesso volutamente, mantengono un’alea più o meno ampia negli obiettivi e nei requisiti, in modo da ‘farci rientrare’ quello che scoprono essere importante solo a progetto iniziato;
c) non sono portati avanti mediante una ‘practice’ consolidata, bensì inventandosi anche un po’ di acqua calda.
E’ possibile non andare in ritardo con un progetto? Sì. Seguendo un approccio che mi piace definire Danese/Scozzese. Consta di pochi, importanti, fattori, di cui il principale è: avere un enorme Capitale Intellettuale a disposizione. Partendo da questo, il flusso progettuale è molto lineare:
a) si cercano uno o più sponsor a livello molto alto nella organizzazione cliente e si condividono in modo formale e preciso gli obiettivi di progetto con costoro;
b) si enucleano dal Capitale Intellettuale gli schemi di Progetto, la documentazione a supporto e la lista di tutti i ‘deliverables’ (Documenti, Piani, etc.) previsti a progetto;
c) si valutano le risorse impegnate secondo ‘best practices’ già note all’interno dello stesso C.I., avendo cura di specificare, per ogni passo, quale dev’essere il coinvolgimento delle risorse del cliente.;
d) Si formula il ‘prezzo’ del progetto e lo si vende al Top Management suddetto, benedicendo infine il tutto in un Kick-off in cui si presenta il progetto in modo dettagliato in modo da ‘incassare’ la consapevolezza di tutti gli attori coinvolti;
e) si porta avanti, secondo la schedulazione, il progetto, di cui si hanno già in mano tutti i deliverables, e dovendo fare solo due cose:
a. riempire i contenuti con i dati del cliente
b. gestire le eccezioni
f) se persone del cliente tardano a fornire collaborazione si rende immediatamente noto all’Alta committenza che il progetto va in ritardo per colpa del cliente stesso;
g) se persone del cliente variano anche di poco i requisiti o vanno in disaccordo su alcuni passi del progetto, si riporta all’Alta committenza che in tal caso il progetto varierebbe fortemente in corso d’opera e si dovrebbe ricominciare a ripensare da capo tutto quanto, con nuova pianificazione e adeguamento dei tempi e dei costi.
Ho avuto modo di veder lavorare consulenti scozzesi/danesi in questo modo varie volte, con il risultato che:
I) i progetti non sono andati in ritardo neanche di un giorno
II) il 100% dei deliverables che erano stati promessi sono stati consegnati nei tempi previsti
III) i consulenti hanno passato il 90% del loro tempo fra di loro a lavorare ai documenti e il 10% ad interagire con il cliente
IV) il cliente si è ritrovato con un progetto fatto come voleva, ma del cui ‘output’ padroneggiava sì e no il 2%, per cui non è risultato autonomo ma ha dovuto continuare ad affidarsi a consulenti e/o portarne qualcuno nella propria organizzazione.
Io provengo da una scuola diversa. Ho sempre passato molto del mio tempo in cooperazione col cliente. Magari ‘sforando’ i tempi ma trasferendo più conoscenza.

Buona continuazione

In base alla mia lunga esperienza nel campo del Project Management direi che le cause principali dei ritardi nell’esecuzione dei progetti sono tre:

1) Scarsa pianificazione soprattutto in fase di offerta. Si pianificano le attività in maniera sommaria e senza approfondire troppo quelli che sono i potenziali rischi che si celano dietro ad ogni attività. E anche laddove questo sforzo viene fatto, normalmente si è molto, forse troppo, disponibili ad “andare incontro alle esigenze del cliente” (accorciando i tempi di consegna). Dimenticandosi forse che l’esigenza del cliente non è quella di farsi promettere una consegna in tempi stretti, ma di ricevere poi entro quei tempi i deliverable del progetto.

2) La non precisa definizione, o la presenza di “aree grige” nella definizione, dello scopo del progetto. Sono molto spesso queste aree grige che aprono la porta all’introduzione di nuovi requisiti nel progetto, che immancabilmente ne prolungano la durata.

3) La gestione sommaria e non formalizzata dei cambi di progetto. Mi è capitato molto spesso di veder introdurre nel progetto dei cambi dello scopo del progetto, con impatti spesso anche significativi in tempi e costi, senza che questi venissero neanche trattati come tali. E spesso, anche in presenza di una sua formalizzazione, il cambio identificava chiaramente gli impatti di costo, ma molto più raramente era altrettanto preciso nell’identificare gli impatti in termini di tempo.

Da quanto sopra, risulta evidente che le tre principali cause nel “ritardo di esecuzione” dei progetti … non risiedono nella fase di esecuzione ma in quella di “pianificazione” (o ri-pianificazione nel terzo caso).

Meditiamoci sopra …

Buonasera;
Io penso che Nella gestione di un progetto la causa principale
di ritardi o sforamenti di Budget e’ legata quasi
sempre alla organizzazione orizzontale che si tende
a dare alla gestione dello stesso .
In genere, sopratutto nei grandi progetti , si tende a dividere in pezzi le azioni da
compiere e le si da in pasto a gruppi di lavoro
differenti, in modo che ognuno abbia “il suo pezzetto” da svolgere ; questo per ottimizzare i tempi e tenere sotto controllo l’organico che ci lavora sopra.
Il risultato e’ che purtroppo spesso mancano poi i collegamenti
( passaggi di informazioni) tra un pezzo e l’altro.
Dovrebbe quindi esserci un coinvolgimento piu “miscelato”di tutti i partecipanti a quel progetto e ci dovrebbe essere un soggetto (al massimo 2) che seguano la cosa dall’inizio alla fine .
Le road-map sono una gran cosa, ma si deve camminare tutti nella stessa direzione e per un risultato che deve sempre essere molto chiaro per tutti .
Saluti.

Un altro paio di spunti oltre a quelli azzecatissimi sopra:

1. Le PREVISIONI hanno il brutto effetto di voler essere rispettate: la gente e’ piu’ motivata da quello che dal risultato oggettivo. Risultato netto ? I ritardi si accumulano, gli anticipi si sprecano.

2. Le VARIAZIONI dei tempi di piu’ progetti portano a disallocazioni delle risorse che vengon risolte da CHI URLA PIU’ FORTE. Risultato netto ? Risorse sprecate a girarsi i pollici invece che aiutare altro progetto limitrofo

3. Last but not least. RISCHIO e’ un concetto che capiscono 4 gatti. Nessuno di noi pensa di avere un incidente in macchina, un infarto o tumore, ma sappiamo bene che le probabilita’ sono alte. Ecco quindi che illuminati imbecilli pensano che il loro progetto possa navigare indenne tra i perigliosi scogli, finche’ come Schettino trovano il fondale alto. IBM e SHELL mettono per DEFAULT tra 7-8% di contingency: la maggiorparte delle aziende che gestisce a commessa pensa di cavarsela tra 0 e 4%…mal gliene viene :))

Secondo me gran parte delle osservazioni fatte finora derivano dalla mal riposta convinzione che hanno la stragrande maggiornza dei top, middle e low manager (specialmente in Italia) che stipulare un contratto con un fornitore sia come stipulare un contratto di assicurazione dove una volta strappato il prezzo più basso poi dopo non ti devi preoccupare di come andrà a finire tanto hai qualcuno su cui riversare le inefficcienze e gli stress aziendali propri. Caso di vita progetto di una grande compagni telefonica italiana che ha nel rosso il suo colore dominante (:-) ). Costo complessivo 70 Milioni di Euro. Risultato progetto andato a bagno per i motivi che volete voi. Doev’è ora il tpo, middle e low management che ha “speperato” 70 milioni di Euro della compagnia? Ma è ovvio tutti promossi.