Caratteristiche di un progetto software di successo

La nostra quotidiana attività di progettazione e sviluppo di soluzioni software a progetto ci porta continuamente a confrontarci e a farci delle domande a proposito di cosa significhi realizzare un progetto software di successo.

Guardando alla nostra esperienza, prima che a quanto teorizzano i manuali di project management, abbiamo sintetizzato la nostra -provvisoria- migliore risposta a questa domanda attraverso la seguente riflessione.

Al centro di tutto c’è l’adeguatezza del valore prodotto per il cliente: se il progetto dovesse riuscire tecnicamente perfetto ma il valore d’uso, l’efficienza prodotta nei processi del cliente o più in generale il “ritorno di valore”, in alcuni casi non immediatamente traducibile in mera efficienza economica, non dovesse essere adeguato (e riconosciuto tale!)  rispetto a quanto è costato il progetto al cliente, il progetto non può dirsi di successo.

Così come vale per ogni investimento, la prima domanda da farsi prima di avviare un’esperienza progettuale deve dunque riguardare il potenziale -misurabile-  in termini di ritorno dell’investimento (R.O.I.); nel valutare il potenziale di ritorno di investimento, non bisogna mai sottovalutare i rischi di mancata o parziale accettazione dell’innovazione portata dal progetto all’interno dell’organizzazione nella quale viene implementato.

Un’altro fattore non trascurabile riguarda la sostenibilità economica del progetto stesso da parte del cliente. Ci è capitato talvolta di doverci confrontare con clienti con grandi ambizioni progettuali, corrispondenti a grandi opportunità di miglioramento in termini di efficienza, ma del tutto spropositate rispetto alla loro capacità strutturale di investimento.

In queste situazioni, presto o tardi, ci si trova a dover portare avanti progetti che il cliente non è più capace di sostenere nei  loro costi di manutenzione o aggiornamento e che, per questi motivi, non riescono ad arrivare ad esprimere in modo sufficiente il loro potenziale di valore per l’azienda. Noi in questi casi suggeriamo obiettivi più limitati o, meglio obiettivi realizzabili in step successivi; talvolta sconsigliamo addirittura di procedere al progetto: meglio guadagnarsi la fiducia e la stima di un potenziale futuro cliente che guadagnare un progetto oggi che creerà problemi a noi e al cliente nel medio termine.

Ultima ma non ultima, la qualità tecnica della soluzione software realizzata. Questa non deve soltanto garantire un risultato usabile, veloce e privo di errori funzionali rilevanti. Il progetto e il software che ne deriva deve essere tale da garantire il fatto che le fisiologiche evoluzioni dei processi aziendali, o la parzialità con la quale la prima analisi è stata fatta, possano essere gestite e assorbite da evoluzioni del prodotto applicativo che non richiedono impegni di spesa “incoerenti”.

Da non trascurare il fatto che un software ben costruito deve anche garantire una qualche forma di indipendenza dal fornitore o, quantomeno, dallo specifico programmatore: se a poterci mettere le mani sopra per manutenerlo e farlo evolvere ci si trova costretti a dipendere in modo radicale da un solo fornitore o, peggio, da un solo programmatore, l’insuccesso del progetto è solo rimandato!

La domanda che immediatamente deriva da queste prime considerazioni riguarda la distribuzione dei ruoli e delle responsabilità che in un progetto competono nel garantire questi obiettivi.  Quanta parte è in carico al cliente/committente e quanta al project manager/fornitore?

Vi rimandiamo ad un prossimo post per una nostra riflessione sul tema. Nel frattempo ci interessa raccogliere la vostra opinione in merito … commentate!