La logica di intervento di un progetto può essere rappresentata attraverso i “logic models” (si veda il mio precedente post sulla formulazione dei progetti secondo l’approccio Results-Based Management del 10 settembre scorso).

I logic models, tradizionalmente, sono ancorati a una ratio chiaramente “mezzi-fini” come si evince dalla Figura 1). [1]

In pratica, si impostava una “catena logica” per cui si definivano delle azioni che avrebbero dovuto produrre dei risultati attesi positivi per i destinatari e le aree locali servite dal progetto.
La “catena logica” opposta, in genere, non veniva considerata.

Tale approccio alla formulazione dei progetti è stato praticamente “ribaltato” a partire dagli anni Ottanta, grazie all’affermazione dell’approccio Goal Oriented Project Planning (GOPP) prima e di quello Results-Based Management (RBM) dopo.

I due prospetti grafici riportati nelle Figure 2 (sopra) e 3  evidenziano chiaramente quanto sia marcato il cambiamento nell’approccio concettuale alla preparazione dei progetti di sviluppo.

In questo post vorrei rimarcare quanto sia rilevante per la sostenibilità nel corso del tempo della concezione del progetto come di un “processo”. Questo significa che esso non deve essere pensato come una “cianografia”, ma come un “percorso” per raggiungere degli impatti durevoli nel tempo, percorso che si consolida a seguito di una pianificazione progressiva che si adatta al cambiamento delle condizioni esterne [2]. Il progetto, inoltre, dovrebbe essere considerato un processo di apprendimento da parte di finanziatori, stakeholders ed esperti.

In relazione al secondo aspetto, hanno un rilievo metodologico di un certo peso alcune considerazioni che già avevo sviluppato nel post del 15 agosto 2014, sulla scia di ben più autorevoli pareri (Hirschman 1968, Rossi 2004) sulla “serendipity”, ossia sulla capacità di apprendere da eventi inattesi e/o non adeguatamente ponderati in sede di identificazione/formulazione.

In sintesi, riconoscere l’importanza della “serendipity” significa accettare che, sovente, idee nuove e soluzioni innovative possono emergere solo al momento della concreta implementazione di un progetto di sviluppo.

Questo implica che oltre ad approcciare la formulazione dei progetti come “un esercizio di modestia”, come suggerito da Massimo Rossi, si dovrebbe anche acquisire una maggiore consapevolezza, riprendendo i suggerimenti di Hirschman [3], del fatto che le difficoltà che possono emergere in corso d’opera e la conseguente ricerca e sperimentazione di soluzioni innovative possono conferire a quei progetti che sembrano più critici una forza di cambiamento sociale e di apprendimento del tutto particolare.

Inoltre, formulare i progetti come “processi” (percorsi di apprendimento che possono trarre grande vantaggio dalla “serendipity”) e ancorarli a problemi e aspettative dei destinatari finali fa sorgere delle significative analogie con il metodo innovativo di gestione dei progetti, sviluppato soprattutto nel settore informatico, denominato “Agile Project Management”.

 ************

[1] Lo schema della Figura 1 è ripreso, con degli adattamenti, da:
MEIER W. (2003), Results-Based Management. Towards a common understanding among development cooperationa agencies (prepared for the Canadian International Development Agency); Ottawa.
UNDP (2009), Handbook on Planning, Monitoring and Evaluating for Development Results, New York.

[2] Un progetto non andrebbe mai formulato secondo l’approccio “blueprint”, ossia come una “to-do-list“. Come scrive Rossi nella nota 1 a p. 19 del suo manuale, ‹‹blueprint significa cianografia, procedimento grafico usato per la riproduzione su carta sensibilizzata con sostanze chimiche. Sviluppando in acqua, i tratti appaiono bianchi su sfondo azzurro, di qui il riferimento all’azzurro, in italiano come in inglese […]. Il termine viene usato, da tempo, per indicare la concezione di un progetto completa di ogni dettaglio esecutivo. Per questo tipo di progetto viene richiesta una esecuzione intesa come ‘riproduzione’ senza modifiche, fedele nel tempo alla copia originale››. Cfr. ROSSI M. (2004), I progetti di sviluppo. Metodologie ed esperienze di progettazione partecipativa per obiettivi, F. Angeli, Milano, p. 19 Nota 1.
[3] Cfr. HIRSCHMAN A. O. (1975), I progetti di sviluppo, F. Angeli, Milano (edizione originale 1968).