L’andamento dei progetti software è un tema cruciale nell’attuale panorama IT. In questo articolo esploriamo assieme qual è la percentuale di fallimento dei progetti, quali sono le cause principali di fallimento di un progetto IT, e cosa possiamo fare per essere più preparati.

Quanti progetti falliscono? Mastichiamo un po’ di numeri!

Ma davvero sono così tanti i progetti software che falliscono? E su che basi possiamo ragionare? Di seguito vedremo un po’ di numeri, derivanti da alcune indagini sulle quali forniremo fonte, tipologia e data. Ecco qualche statistica.

McKinsey & Company

Da uno studio su progetti di larga scala in ambito IT (budget superiore a 15 milioni di dollari) svolto da McKinsey & Company in collaborazione con l’Università di Oxford e pubblicato nel 2012, risulta che Il 17% dei progetti IT su larga scala è così fallimentare da mettere a rischio l’esistenza della ditta software. In media i progetti di grandi dimensioni vanno il 45% fuori budget e il 7% oltre la deadline. Inoltre consegnano il 56% in meno del valore atteso.

Geneca

Geneca ha condotto per gli anni 2010-2011 uno studio dei progetti software basato su interviste, dalle quali risulta che il 75% dei partecipanti a progetti software non ha molta fiduia che il loro progetto avrà successo. Il 78% dichiara che il business non è allineato con i requisiti di progetto.

PMG

Nel 2010, PMG New Zealand ha condotto un sondaggio riguardante 100 aziende software di varia tipologia ottenendo i seguenti risultati: il 70% delle organizzazioni aveva avuto almeno un progetto IT fallito nei 12 mesi precedenti. Inoltre, il 50% del campione ha indicato che il loro progetto ha fallito nell’ottenere quello che era stato richiesto.

IBM

Interessanti anche i dati ottenuti da IBM, seppur in un sondaggio più datato (2008) riguardante 1500 dirigenti che si occupavano di gestione del cambiamento. Ebbene, Solo il 40% dei progetti aveva rispettato la pianificazione, il budget e i parametri di qualità attesa. Chi era organizzato meglio aveva avuto 10 volte più successo di chi era organizzato in maniera disfunzionale.

Inoltre, si è riscontrato che i più grandi ostacoli al successo del progetto sono legati alle persone:

• 58% dovuto all’instabilità attitudinale e motivazionale;
• 49% dovuto a un’impostazione culturale “corporate”;
• 32% dovuto alla mancanza di supporto manageriale esperto.

La sottovalutazione della complessità dei progetti è elencata come causa primaria di fallimento nel 35% dei progetti.

The Standish Group

Pochi, ma significativi dati: nel 2007 il 39% dei progetti con budget superiore a  10 milioni di dollari… è fallito.

Le cause di fallimento

Per i non addetti ai lavori potrà sembrare strano che tanti progetti software non vadano a buon fine. In fin dei conti quando compro un’automobile, generalmente funziona; e lo stesso vale per un frigorifero o un orologio. E allora perchè, quando acquisto un nuovo sito di eCommerce, posso correre il rischio di essere parte di un progetto fallimentare?

Sulla base delle mie esperienze e delle mie opinioni, ho stilato una lista di quattro principali cause di fallimento, che sono peraltro suffragate dai riferimenti che trovate in fondo all’articolo:

• portata del progetto non chiara;
• pianificazione inadeguata;
• scarso coinvolgimento degli stakeholder;
• management inesperto.

Con questo elenco delle quattro cause, vogliamo brevemente invitare a fare mente locale su situazioni e comportamenti tanto comuni quanto impattanti sulla riuscita di un progetto.

Causa 1: Scope del progetto non chiaro

Molti progetti software partono senza aver bene riflettuto seriamente su diversi aspetti, tra cui:

• cosa ci proponiamo di ottenere dal progetto?
• come capiremo che il progetto ha centrato il suo obiettivo?
• quali attività saranno necessarie per portare il progetto a compimento?
• esiste una chiara roadmap?

Nel caso il progetto punti a realizzare un prodotto, occorre ulteriormente specificare questo aspetto:

• esiste una visione di prodotto? [6]
• esiste già sul mercato lo stesso prodotto o uno simile?
• se il prodotto esiste già, in cosa il nostro sarà unico/migliore?
• quale sarà il modello di business?
• in quanto tempo intendiamo recuperare l’investimento?
• noi lo compreremmo?

Quando non esiste una risposta chiara e analitica alle domande di cui sopra, il progetto ha una buona probabilità di fallire e lo si avverte subito nelle prime fasi.

Figura 1 – La direzione non è molto chiara…

Qualche soluzione

E allora, cosa fare per non incappare in questo tipo di problema?

Parlare con il cliente e capire da lui (o aiutarlo a capire) cosa vuole ottenere dal progetto e dal suo investimento economico.

Potrebbe anche succedere che, dopo un’analisi approfondita, ci rendiamo conto che quanto stavamo per realizzare non ha valore di business sul mercato. In tal caso è meglio fermarsi: se c’è una cosa che nel mondo non manca è il software inutile…

Nel caso di metodologie iterative la situazione può essere più semplice: non è necessario fare grandi (e costose) analisi di mercato, ma cercare di realizzare alla prima iterazione (di solito non più lunga di un mese) qualcosa di usabile. Sarà il feedback del cliente a dirci se siamo sulla buona strada.

Nel caso del framework Scrum esiste un ruolo apposito, il product owner, che è deputato a creare una visione di prodotto e a coinvolgere il team in scelte di valore di business delle funzionalità rilasciate. È bene assicurarsi che una figura così cruciale abbia la giusta preparazione e il giusto appoggio per poter fare al meglio il proprio lavoro.

Causa 2: Pianificazione inadeguata

In molti casi i progetti durano più di quanto pianificato e vanno fuori budget, talvolta anche del 50%. Perchè? Ci sono molti fattori che contribuiscono a una pianificazione non efficace: di seguito ne vedremo alcuni.

Figura 2 – Il rischio Titanic c’è sempre…

Stime inverosimili

Uno dei problemi classici riguarda le stime non verosimili: se è la prima volta che il team del progetto realizza qualcosa del genere, le stime sono con alta probabilità poco attendibili. Talvolta, inoltre, le stime sono tirate per esigenze del business, che deve soddisfare certe scadenze per non vedere sfumare l’opportunità. Questa è una esigenza da non sottovalutare, ma attenzione: talvolta andare a una velocità non sostenibile può costare caro.

Team inadeguato: capacità produttiva, competenze, compresenza contemporanea

Altro problema ricorrente è presenza di un team non adeguato: capita di imbarcarsi in un progetto senza prima aver verificato la reale capacità prodottiva del team. È utile porsi alcune domande relative alla reale capacità produttiva del team, alla presenza delle adeguate competenze per quel tipo di progetto, alla contemporanea presenza nello stesso luogo di tutti i membri del team (gruppo di lavoro “distributed” vs team “co-located”). Vediamo meglio questi aspetti.

Semplificando al massimo, la reale capacità produttiva del team potrebbe essere individuata nella somma di ore che ogni componente del team dedica effettivamente allo sviluppo. Una volta calcolata la capacità, bisogna effettivamente verificare che la deadline promessa sia sostenibile. Attenzione: non è facile come sembra recuperare un ritardo accumulato. Infatti il lavoro erogato non è proporzionale al numero di sviluppatori presenti nel team. Un po’ come con il classico esempio delle “nove donne incinte” che sono in grado di partorire il bambino in un solo mese…

L’aspetto delle giuste competenze per affrontare il progetto è cruciale. In caso ci siano molte persone alle prime armi, occore prevedere anche un corrispondente numero di senior che possa supportarli. Training e consulenti esterni sono sicuramente una possibilità, ma è un’opzione difficilmente spendibile una volta iniziato il progetto, dati i tempi solitamente serrati che questo impone.

Infine non va sottovalutato l’impatto rappresentato dal modo in cui il team è organizzato “territorialmente”: le persone lavorano insieme nello stesso luogo in contemporanea (co-located), oppure il team è “distribuito” su più sedi? In questo secondo caso bisogna tenere in considerazione il fatto che c’è uno sforzo maggiore di comunicazione che può ridurre la produttività del team.

Vincoli esterni

Se sono presenti vincoli esterni, la pianificazione diventa molto più complicata. Talvolta infatti parti del progetto (sviluppo, grafica, testi, traduzioni etc.) sono prese in carico da altri team/altri fornitori e risultiamo quindi dipendenti da fattori che non sono sotto il nostro controllo. Il consiglio è di avere team multifunzionali in modo da ridurre il più possibile le dipendenze; laddove non si possano evitare, occorre tenerne ampiamente conto nelle pianificazioni.

Progetti molto lunghi

Progetti molto lunghi (in stile waterfall) rischiano di implicare una pianificazione che espone a incertezze molto alte sui tempi di delivery. Meglio prevedere diverse tranche, ciascuna più facile da stimare. O meglio ancora utilizzare una metodologia di sviluppo iterativa, quale Scrum [5]

Causa 3: Scarso coinvolgimento degli stakeholder

Sembra essere una diffusa modalità quella di pensare che lo sviluppo software sia una attività altamente industriale: si dice al team a grandi linee quello che si vuole e dopo qualche mese si riceve il software richiesto, esattamente come lo volevamo.

La realtà è molto lontana da questo scenario: un progetto software richiede l’input continuo di tutti i suoi stakeholder, incluso il committente principale.

È necessario verificare periodicamente che quanto sviluppato sia in linea con le aspettative e fornire feedback in modo da assicurarsi che il progetto stia andando nella direzione voluta. Tutte le fasi del ciclo di vita di un software, dalla raccolta dei requisiti, alla stesura dell’analisi, allo sviluppo e così via implicano attività a forte componente creativa, che richiedono forti dosi di comunicazione di alta qualità.

Figura 3 – Se i primi a non essere interessati sono proprio i committenti, il rischio che il progetto fallisca diviene molto concreto.

Il mio consiglio è quello di pensare a un progetto software come se fosse un avventuroso viaggio di apprendimento che si intraprende insieme.

Causa 4: Management inesperto

Nell’immaginario collettivo il manager è quello che tiene il “Gantt in una mano e la frusta nell’altra”. Per di più, spesso non ha particolare preparazione per fare il suo mestiere: è lo sviluppatore/analista funzionale più senior, che negli anni ha guadagnato la fiducia della direzione. È l’uomo di fiducia a cui viene chiesto di “tenere un occhio sul team”.Ebbene il management è ben più di questo. E richiede un’ampia esperienza e preparazione.

Team disfunzionali

Molti dei team sono disfunzionali, a seguito delle normali dinamiche di gruppo e talvolta di seri problemi organizzativi strutturali. Nei team ci possono essere conflitti (i più pericolosi sono quelli latenti), insoddisfazione, demotivazione, mentalità non collaborative etc. Questi fattori possono causare più danni di un’architettura non ottimale; possono addirittura mettere a repentaglio l’intero progetto. Gestire questi problemi è compito del manager o, se pensiamo in mentalità agile, del “facilitatore”, che deve aiutare il team a riconoscere e affrontare questi problemi.

Figura 4 – Un buon management non nasconde la testa sotto la sabbia, ma affronta con atteggiamento di facilitazione le diverse difficoltà, non necessariamente tecniche, che possono emergere in un team.

In questo caso il mio consiglio è quello riconoscere l’importanza di una figura di coordinamento, investire nella sua formazione e dargli il tempo, gli strumenti e il supporto che gli serve per ottenere un esito positivo del progetto.

Conclusioni

In questo articolo abbiamo elencato brevemente alcune delle classiche cause di fallimento di un progetto IT. Come visto all’inizio, quella del fallimento è un’eventualità tutt’altro che remota. E i nostri lettori consa ne pensano? Riconoscono le loro situazioni nell’elenco che abbiamo presentato? O, secondo la loro esperienza, riscontrano altri fattori determinanti da evidenziare? Con questi interrogativi vi lascio per ora. Alla prossima.

Riferimenti

[1] Uladzislau Shauchenka, “Why projects Fail”, 2013

http://www.amazon.com/Why-Projects-Fail-Uladzislau-Shauchenka-ebook/dp/B0057G4M4C

[2] Cynthia K. West, “Four Common Reasons Why Projects Fail”

http://www.projectinsight.net/white-papers/four-common-reasons-why-projects-fail

[3] The Long, Dismal History of Software Project Failure (2006)

http://blog.codinghorror.com/the-long-dismal-history-of-software-project-failure/

[4] Ron Ashkenas – Lisa Bodell, “Nice Managers Embrace Conflict, Too”

http://blogs.hbr.org/2013/10/nice-managers-embrace-conflict-too/

[5] “What is Scrum?”

https://www.scrum.org/Resources/What-is-Scrum

[6] Roman Pichler, “The Product Vision”

https://www.scrumalliance.org/community/articles/2009/january/the-product-vision