‹‹Projects are often implemented as a means of achieving an organisation’s strategic plan››
(PMBOK, 2000 edition, p. 4)

In vari manuali e guide di istituti di ricerca che cercano di stabilire degli standard internazionali sulla gestione dei progetti si possono rintracciare varie definizioni di progetto.
Una delle più usate è quella avanzata dal Project Management Institute nel PMBOK (A Guide to the Project Management Body Of Knowledge – PMBOK), che definisce un progetto ‹‹uno sforzo temporaneo intrapreso per creare un prodotto o un servizio unico›› (v. p. 4 dell’edizione del 2000 del PMBOK).

Come ho cercato di argomentare nel post del 20 luglio scorso – Alla ricerca delle caratteristiche distintive dei progetti di sviluppo locale – la definizione di progetto adottata dal PMBOK mal si presta ad essere applicata ai progetti di sviluppo socio-economico.
Questo per almeno tre ordini di motivi:
1. Una siffatta definizione è chiaramente riferita a un progetto collocato all’interno di una ‘organizzazione’. Non è un caso che nel PMBOK e in altre guide ispirate al Total Quality Management (TQM) la questione della efficiente gestione dei progetti viene intimamente connessa alla questione dell’efficiente gestione complessiva di una ‘organizzazione’ (in misura crescente viene promosso un approccio ancora più complesso alla gestione della qualità in azienda, che non investirebbe solo i singoli progetti, ma l’intera azienda, tant’è che si parla ormai diffusamente di ‘company-wide project management’).

A mio modesto avviso, nel momento in cui si lavora alla formulazione di progetti di sviluppo socio-economico andrebbe cambiato radicalmente l’approccio all’individuazione delle reali caratteristiche distintive dei progetti. Se la definizione di progetto del PMBOK concerne un progetto ‘aziendale’, perché applicarla tout court a un progetto che si colloca all’interno di una comunità – più o meno ampia – di cittadini/utenti?
La definizione di progetto e, soprattutto, l’individuazione delle caratteristiche distintive di progetto nel momento in cui si ragiona su un progetto di sviluppo socio-economico che – quali che siano l’ente finanziatore e quello che realizza il progetto – interessa un gruppo target ben diverso dai ‘clienti’ di un’azienda, devono necessariamente avere delle fondamenta analitiche diverse. Proporrò una riflessione in merito nel prossimo post del 20 agosto.

2. La definizione del PMI è volta a distinguere nitidamente le caratteristiche di un ‘progetto’ da quelle delle ‘funzioni organizzative’. Nella definizione del PMBOK, infatti, un progetto è ‘unico’ non tanto in quanto tutti i progetti sono unici per definizione, ma in quanto un progetto non è caratterizzato dalla ripetitività delle funzioni – operazioni – aziendali quotidiane (v. p. 4 dell’edizione del 2000 del PMBOK);
Questa impostazione del PMBOK muove dalla considerazione triviale che tutte le organizzazioni – siano esse pubbliche, private orientate al profitto o private senza scopo di lucro – devono eseguire del lavoro (attività produttive) per creare valore. [1]

Seguendo il PMBOK, lo possono fare realizzando:
• Funzioni operative (con riferimento alle imprese si parla di ‘funzioni aziendali’).
• Progetti.

In estrema sintesi, il PMBOK rimarca che le ‘funzioni aziendali’ si caratterizzano come attività (operazioni) continuative e ripetitive, mentre i progetti si caratterizzano per le caratteristiche di essere temporanee (‘uno sforzo temporaneo’) e finalizzate a produrre dei prodotti e servizi che, in qualche modo, costituiscono un unicum in confronto a quelli ottenuti con le operazioni ‘ordinarie’ di una organizzazione.
3. L’approccio complessivo del PMI alla formulazione e gestione dei progetti è nitidamente sbilanciato verso la c.d. progettazione ‘per attività’, quando, invece, almeno dalla fine degli anni Novanta si va diffondendo sempre di più un approccio alla formulazione dei progetti ‘per obiettivi’ (‘planning for results‘), sia presso le organizzazioni, sia presso la comunità degli esperti di sviluppo locale. [2]

Le differenze principali fra progettazione ‘per attività’ e progettazione per ‘obiettivi’ sono evidenziati nel grafico che segue.

Il forte orientamento della Guida del PMI alla progettazione ‘per attività’ è chiaramente testimoniato dai seguenti elementi:
• la mancanza di riferimenti all’analisi cruciale dei problemi dei ‘clienti’ (l’analisi dei problemi dei destinatari dei progetti, invece, è cruciale per ogni progetto di sviluppo socio-economico ben formulato);
• i riferimenti insoddisfacenti alla generazione di soluzioni e di obiettivi dei progetti, come risposta ad una analisi approfondita dei problemi dei clienti;
• l’attenzione maniacale per la decomposizione dei progetti in unità elementari (Work Breakdown Structure – WBS) che costituisce un elemento cardine per la elaborazione di un piano di progetto definitivo (‘project scope statement‘ nel linguaggio del PMBOK). Il piano del progetto, come emerge nell’impostazione del PMBOK, trascura, sovente, l’analisi dei problemi e delle esigenze dei clienti e si caratterizza in primo luogo come una autentica ‘to-do-list’. [3] La disponibilità della ‘to-do-list’ nell’approccio del PMI è fondamentale non tanto per creare ‘valore aggiunto’ per i clienti, quanto per poter gestire i processi di controllo di qualità, per contenere i costi progettuali e per ottenere la massima efficienza possibile. Tutti i progetti andrebbero predisposti con grande rigore analitico e metodologico, ma nel caso dei progetti di sviluppo socio-economico andrebbero parimenti pensati come dei ‘processi’. In altri termini, vale il monito di Massimo Rossi: ‹‹rigore analitico non significa rigidità progettuale›› (Rossi 2004, p. 153). Per quanto le fasi di analisi e di identificazione/formulazione possano essere state condotte con rigore e prudenza, infatti, l’attuazione dei progetti può sempre riservare delle criticità inattese. Tuttavia, se si concepisce dei progetti di sviluppo come “processi” (e non come delle ‘to-do-list’ o ‘cianografie’) e si è pronti ad apprendere dalle esperienze concrete, quelle criticità possono anche portare ad escogitare delle soluzioni innovative che amplificano i risultati finali del progetto; [4]

• la fase ‘controllo’ del ‘ciclo del progetto’, de facto, è circoscritto al solo progetto interno e verte su procedure e metriche interne al progetto. Viene completamente trascurata l’analisi dei risultati/impatti generati per i destinatari e l’analisi di efficacia. [5]

******

[1] ‹‹Organisations perform work. Work generally involves either operations or projects, although the two overlap. […]. Projects are often implemented as a means of achieving an organisation’s strategic plan. Operations and projects differ primarily in that operations are ingoing and repetitive, while projects are temporary and unique […]. Temporary means that every project has a definite beginning and a definite end. Unique means that the product or service is different in some distinguishing way from all other products or services ›› (PMBOK, 200 edition, p. 4)

[2] Sin dagli anni Settanta l’approccio alla formulazione, alla gestione e alla valutazione dei progetti viene informato ai c.d. ‘logic models’, che si possono rappresentare graficamente in vari modi, ma si fondano tutti sull’idea che si possa definire una ‘catena di risultati’ (‘results chain’) che lega le risorse investite in un progetto ai suoi effetti finali.
Un aspetto chiave di ogni logic model è la corretta verifica della validità logica dei nessi causali in cui si sostanzia la logica di intervento del progetto. In altri termini, si deve attentamente ponderare come la realizzazione di determinate azioni si traduce negli obiettivi intermedi (spesso indicati come ‘risultati attesi’) e negli obiettivi finali del progetto, nel presupposto che ogni azione o evento avrà sempre un effetto causale su altri eventi e sui risultati del progetto.
In estrema sintesi, i logic models sviluppati negli anni Settanta erano fortemente ancorati a una logica mezzi-fini (‘If … then’).
Nei decenni successivi, invece, sono andati affermandosi approcci volti a ribaltare questa logica “ingegneristica” molto legata al ciclo PDCA (Plan Do Check Act) e a focalizzare l’attenzione, almeno per i progetti di sviluppo socio-economico, su problemi e desiderata dei destinatari finali (end users) e delle comunità locali. Tra questi si afferma, nella seconda metà degli anni Novanta, l’approccio, Results-Based Management (RBM approach).
Il RBM approach si può considerare una applicazione dei logic models in cui la ‘results chain’ (catena dei nessi causali) viene definita a partire da problemi/desiderata dei destinatari finali e dai conseguenti obiettivi del progetto e non da risorse disponibili e azioni fattibili dato il vincolo delle risorse.
Il RBM approach, più in particolare, si discosta dai logic models tradizionali per i seguenti motivi:

• si fonda sulla logica di progettare ‘per obiettivi’ e non ‘per attività’. In pratica, applicando il RBM approach si capovolge il percorso di lettura delle ‘catene di risultati’.
Il percorso di lettura tradizionale è ancorato alla logica ‘mezzi-fini’. Il percorso del RBM approach, invece, una volta definiti gli obiettivi, impone di valutare, a partire da quegli obiettivi, quali siano le azioni più opportune da implementare per raggiungerli;
• privilegia una valutazione di impatto sin dalla fase di ideazione/formulazione degli interventi, rispetto alla tradizionale valutazione ex ante. In altri termini, si privilegia una logica ‘expected results’ rispetto alla logica tradizionale ‘planned results’;
• sostiene un approccio fortemente incentrato su problemi e desiderata dei destinatari (gli utenti dei servizi del progetto), proprio per il fatto che viene sempre più enfatizzata l’efficacia degli interventi e la loro capacità di “fare la differenza” per le condizioni di vita dei destinatari finali.

[3] La Work Breakdown Structure (WBS) consente di schematizzare le procedure per la realizzazione dei progetti (o, più in generale, dei vari processi produttivi) e realizzare una struttura gerarchica a più livelli di attività operative (viene anche indicata come Activity Breakdown Structure). In questo modo, ogni problema complesso, e/o ogni processo complesso, possono essere articolati su più livelli di operatività (difficoltà) e in unità elementari. La WBS, in sostanza, non fa altro che ‘decomporre’ in termini molto dettagliati le macro-attività indicate nella ‘proposta di progetto’ (indicata sovente come ‘statement of work’ nei principali contributi sul project management).

[4] Un approccio ‘blueprint’ alla formulazione dei progetti è tipico di quei progetti pensati come ‘to-do-list’ (cianografie). 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››.
ROSSI M. (2004), I progetti di sviluppo. Metodologie ed esperienze di progettazione partecipativa per obiettivi, Franco Angeli, Milano.

[5] Questo contributo è un ‘work in progress’ elaborato nell’ambito del progetto di ricerca del Centro Studi Funds for Reforms Lab ‘Theory of Change e valutazione di impatto dei progetti‘.