Quando l’analisi di fattibilità è solo un ricordo sbiadito

Chiunque abbia studiato project management conosce l’analisi di fattibilità come quella fase in cui si verifica se un’idea può tradursi in realtà. Dovrebbe essere il momento in cui si esaminano vincoli tecnici, budget disponibili, competenze necessarie e tempistiche realistiche. Una sorta di checkpoint razionale prima di impegnare risorse significative in un’avventura che potrebbe rivelarsi disastrosa.

Nella teoria accademica, questa analisi rappresenta uno strumento essenziale per ridurre i rischi e aumentare le probabilità di successo. Nella pratica quotidiana delle organizzazioni, però, questa fase spesso si rivela essere un miraggio nel deserto della gestione progettuale.

La decisione che precede l’analisi

Il problema fondamentale emerge quando le decisioni strategiche vengono prese molto prima che qualcuno si preoccupi di verificarne la fattibilità. In molte organizzazioni, esiste una figura decisionale che stabilisce gli obiettivi basandosi su intuizioni personali, presentazioni accattivanti o semplicemente perché “quella tecnologia sembra interessante”.

Il risultato? Un progetto viene considerato automaticamente realizzabile non perché qualcuno abbia analizzato tecnologie, risorse e vincoli, ma semplicemente perché chi ha potere decisionale ritiene che debba esserlo. È una forma di pensiero magico applicato al mondo IT, dove la volontà sostituisce la valutazione oggettiva.

Questa dinamica crea un cortocircuito logico: invece di decidere dopo aver analizzato, si analizza dopo aver deciso. O meglio, si fa finta di analizzare, perché il verdetto è già stato emesso in partenza.

La retrospettiva preventiva come metodologia

Quando le decisioni precedono le analisi, nasce quella che potremmo definire “retrospettiva preventiva”. Invece di chiedersi “questo progetto si può fare?”, la domanda diventa “come facciamo a realizzare questo progetto che dobbiamo assolutamente fare?”.

Il team tecnico si ritrova così a lavorare all’indietro, cercando disperatamente di trovare una strada per rendere possibile ciò che è già stato promesso a clienti, stakeholder o investitori. È come dover costruire un ponte mentre si è già a metà del fiume, con l’acqua che sale e qualcuno sulla riva che urla di sbrigarsi.

Le decisioni tecnologiche vengono prese con una metodologia che ricorda più la scelta casuale che l’ingegneria del software. Un articolo letto online, una demo impressionante vista a una conferenza, il suggerimento di un consulente particolarmente eloquente diventano le basi per scelte tecnologiche che dovrebbero sostenere anni di operatività.

Il mito delle risorse illimitate

Uno degli aspetti più problematici di questa mentalità riguarda la gestione delle risorse umane. Quando un progetto incontra difficoltà, la soluzione proposta è quasi sempre la stessa: assumere più persone. Come se la complessità di un sistema software fosse una questione puramente numerica.

Questa visione ignora completamente la realtà dello sviluppo software. Aggiungere sviluppatori a un progetto già avviato significa affrontare curve di apprendimento, rallentamenti nella comunicazione, necessità di coordinamento e perdita di coesione nel team. In molti casi, aumentare il numero di persone coinvolte rallenta il progetto invece di accelerarlo.

La sinergia tra membri di un team, la comprensione condivisa dell’architettura, la capacità di comunicare in modo efficiente sono elementi che richiedono tempo per svilupparsi. Non si possono comprare o installare come se fossero software preconfezionati.

La selezione dei fornitori e le tempistiche magiche

Un altro sintomo di questo approccio disfunzionale emerge nella selezione dei partner esterni. I fornitori vengono spesso scelti non per competenza tecnica o track record comprovato, ma per relazioni personali, capacità di creare presentazioni spettacolari o semplicemente perché “li conosciamo già”.

La competenza tecnica diventa un aspetto secondario rispetto alla capacità di produrre slide colorate e grafici impressionanti. Il risultato sono partnership basate su promesse e aspettative irrealistiche piuttosto che su valutazioni oggettive delle capacità.

Le tempistiche seguono una logica simile. Le date di consegna vengono stabilite sulla base di necessità di business, scadenze imposte dal mercato o semplici desideri, senza alcuna correlazione con la complessità reale del lavoro da svolgere. Un progetto che richiederebbe razionalmente diciotto mesi viene compresso in sei perché “dobbiamo lanciare prima dei competitor”.

Il costo della certezza prematura

Questa certezza preventiva ha conseguenze concrete e misurabili. I team tecnici si trovano a lavorare in condizioni impossibili, cercando di rispettare promesse che non avrebbero mai dovuto essere fatte. La qualità del codice si deteriora per rispettare scadenze irrealistiche. Le architetture vengono compromesse da decisioni tecnologiche sbagliate prese troppo presto.

Ma forse l’aspetto più dannoso è l’erosione della fiducia all’interno dell’organizzazione. Quando i tecnici sanno che le loro valutazioni verranno ignorate, quando i project manager comprendono che le pianificazioni sono esercizi di fantasia, quando tutti capiscono che il processo decisionale è performativo piuttosto che sostanziale, si instaura un clima di cinismo che avvelena la cultura aziendale.

Come dovrebbe essere

Un’analisi di fattibilità autentica richiederebbe coinvolgimento reale del team tecnico, apertura a scoprire che alcune idee non sono praticabili nei tempi o con i budget previsti, disponibilità a modificare gli obiettivi sulla base di evidenze concrete.

Significherebbe accettare che dire “questo non è fattibile” non è un fallimento, ma un risparmio di risorse che potrebbero essere investite in iniziative più realistiche. Richiederebbe umiltà decisionale e la capacità di distinguere tra visione strategica e wishful thinking.

Ma soprattutto, un processo decisionale sano dovrebbe riconoscere che la complessità tecnologica non si piega alla volontà manageriale. Le leggi della fisica, i limiti delle tecnologie attuali e la natura intrinsecamente complessa dello sviluppo software non cambiano perché qualcuno in sala riunioni ha deciso che dovrebbero farlo.

La strada verso progetti sostenibili

Trasformare questo scenario richiede un cambio culturale profondo. Serve creare spazi in cui il dissenso tecnico sia non solo tollerato ma valorizzato. Dove dire “aspetta, dobbiamo pensarci meglio” sia visto come segno di professionalità e non come ostacolo burocratico.

Le organizzazioni più mature hanno imparato che investire tempo nell’analisi iniziale significa risparmiare mesi di rework successivo. Che ascoltare chi ha competenza tecnica non significa abdicare alle decisioni strategiche, ma arricchirle con la prospettiva della fattibilità concreta.

Forse il primo passo è riconoscere che l’analisi di fattibilità non è un ostacolo alla velocità decisionale, ma la fondamenta su cui costruire progetti che abbiano reali possibilità di successo. Senza questa base, ogni progetto IT diventa una scommessa in cui le probabilità di vincita sono drammaticamente basse.

Questo articolo è tratto da “Non funziona niente! – I progetti IT in crisi”, il primo libro della collana Nothing Works! — una tragicommedia aziendale per chi ha visto troppi Gantt chart trasformarsi in fiction.

Scopri la collana completa, gli altri libri e le prossime uscite su nothingworks.it

Vuoi il libro subito? Compralo su Amazon

Potrebbe interessarti anche

• Sistemista IT in una PMI: mansioni e competenze
• DIRETTORE ACQUISTI
• Perché documentare gli interventi IT potenzia la posizione del Sistemista?
• Da sistemista IT a IT Manager: un, possibile, percorso di carriera nell’ambito manifatturiero
• I problemi quotidiani di un Sistemista IT e come risolverli
• SISTEMISTA
• Quanto guadagna un Sistemista a Torino?
• SISTEMISTA IT
• Cosa fa un Sistemista in un Managed Service Provider: ruolo e giornata tipo
• Dieci clienti, un solo Sistemista: come si gestiscono le priorità in un Managed Service Provider