Questo sito utilizza cookie per raccogliere informazioni sull'utilizzo. Cliccando su questo banner o navigando il sito, acconsenti all'uso dei cookie. Leggi la nostra cookie policy.OK

Direttore responsabile Alessandro Longo

PIANO TRIENNALE

Cambiare la PA, ecco un primo (insufficiente) esempio di project management

di Nello Iacono, Stati Generali dell'innovazione

06 Lug 2017

6 luglio 2017

Il Piano Triennale contiene una declinazione semplice delle tecniche di project management nei progetti “digitali” delle PA. Un passo importante, naturalmente non sufficiente: per cambiare concretamente l’approccio ai progetti di innovazione occorre un programma organico e coerente di sviluppo delle competenze

Tra le novità positive del recente Piano Triennale per l’Informatica nella PA mi sembra sia da inserire la presenza della sezione dedicata ai “Principi per lo sviluppo di progetti digitali”, non soltanto per l’utile sintesi di punti di attenzione (quasi una checklist per la definizione di un piano di progetto), ma soprattutto perché rientra in quegli “strumenti metodologici di accompagnamento” al cambiamento che sono necessari tanto quanto le indicazioni architetturali e normative presenti nel Piano.

La sezione fornisce indicazioni per la predisposizione di un progetto digitale (finalizzato alla realizzazione di un nuovo sistema o all’evoluzione di un sistema esistente), e si sofferma su alcuni punti specifici necessari:

  • un chiaro disegno di cosa si vuole ottenere (design);
  • un piano di come costruirlo (realizzazione);
  • una strategia per portarlo all’adozione degli utenti finali (lancio);
  • un piano per mantenere il sistema aggiornato, sicuro, e utile nel tempo, oltre che per assicurarne il continuo funzionamento anche in caso di malfunzionamenti o disastri (evoluzione e manutenzione).

In particolare, la sezione è rilevante perché si preoccupa di porre in primo piano il tema della gestione di un progetto “digitale” caratterizzandolo come progetto di innovazione, di cambiamento, e non come progetto di mera digitalizzazione.

Da questo punto di vista è significativa l’enfasi costante che viene posta sul coinvolgimento dei cittadini (al momento della progettazione del servizio) e sull’importanza della comunicazione (nella fase di “lancio” per “l’adozione” da parte degli utenti finali), proprio perché il basso utilizzo dei servizi pubblici digitali (sceso in un anno dal 19% al 16% di utilizzo da parte degli utenti Internet, secondo il DESI – Digital Economy and Society Index) non è tanto legato alla loro disponibilità quanto alla combinazione (perversa, ma coerente) di scarsa usabilità dei servizi digitali e basse competenze digitali della popolazione (56% di livello non sufficiente, sempre secondo il DESI). Una enfasi che trova la base di riferimento nelle “Strategie per il design dei servizi”, forse uno dei documenti più chiari e visionari prodotti negli ultimi anni a livello governativo nell’ambito della trasformazione digitale della PA. Strategie non a caso richiamate più volte nella descrizione dei principi per lo sviluppo dei progetti.

Rimandando alla lettura (molto utile) del Piano Triennale e delle Strategie per il design dei servizi, credo si possano sottolineare alcuni tra gli elementi significativi che emergono dall’analisi della checklist proposta dall’AgID e dal team per la Trasformazione Digitale:

  • la progettazione va sempre effettuata con il coinvolgimento strutturato ed efficace dei futuri utenti;
  • la realizzazione va costruita sul modello di interoperabilità (e quindi a partire dai dati, per microservizi, fornendo le API per richiamarli, ..), sulla collaborazione tra le PA (e quindi anche enfasi su codice aperto, condivisibile, riusabile), e in modo incrementale (secondo il modello Agile) così da permettere un graduale ma rapido utilizzo delle funzionalità sviluppate;
  • il lancio del servizio va pianificato (identificando quindi attività, responsabilità, tempi e risorse) e questa fase è del tutto all’interno del piano complessivo di progetto. La responsabilità progettuale si chiude con l’utilizzo effettivo del servizio realizzato, e non con il suo rilascio in esercizio;
  • ogni progetto deve avere un project manager nominato formalmente. Banale, ma non troppo, se si pensa ai tanti progetti che nelle amministrazioni pubbliche sono tagliati a fette tra le diverse strutture coinvolte, ciascuna con il proprio responsabile, ma senza assicurare una responsabilità trasversale e quindi l’esistenza di un progetto per l’obiettivo complessivo;
  • l’evoluzione del prodotto/servizio va pianificata e quindi è necessario “stabilire o avere una strategia per migliorare il prodotto dopo il lancio, aggiungere funzionalità, correggere problematiche e, più in generale, consentirne l’aggiornamento”.

Insomma, siamo ad una declinazione semplice e concreta, per punti, delle tecniche di project management nei progetti “digitali” per le amministrazioni pubbliche. Un passo positivo e importante, naturalmente non sufficiente per cambiare effettivamente l’approccio ai progetti di innovazione.

Tra gli altri, due aspetti credo vadano posti in primo piano:

  • la normativa deve favorire la definizione di progetti incrementali e agili e allo stesso tempo vincolare al rispetto dei principi minimi di project management riportati nel Piano;
  • lo sviluppo di competenze adeguate ad una piena comprensione e attuazione dei principi e delle linee guida per lo sviluppo dei progetti è da considerarsi urgente e necessario. E quindi a sua volta ha bisogno di una pianificazione, che ancora manca e non ha una regia definita.

Questo secondo aspetto è il più preoccupante perché richiede interventi capillari e differenziati. Ci vorrebbe un progetto nazionale strategico da inserire nel Piano, con responsabilità centrali e delle singole amministrazioni, con un approccio incrementale e agile. Perché il cambiamento cammina sulle gambe delle persone e si misura con i comportamenti.

  • Federico

    Mi sembra un primo passo, anche se da qui al project management completamente attuato, ce ne vuole…
    Molte Amministrazioni (almeno Centrali) sono già molto avanti rispetto a questi requisiti minimi, avendo inserito nella loro organizzazione dei PMO (project/program managment office) particolarmente efficaci.
    Cito ad esempio (come elementi mancanti): la valutazione pre-durante-post dei benefici per gli stakeholder, il risk management (non è che con il modello agile spariscono), la raccolta di “alberi” di indicatori di successo o matrici del tipo “balanced score card” con valori obiettivo predefiniti e verificati a-posteriori.
    Sarei lieto di vedere qualche esempio di contratti con società di software (impensabile che non ci sia un outsourcing) che applicano il modello agile.
    Il nuovo Codice degli Appalti parla di progettazione di massima, di dettaglio, esecutiva, prima della messa a gara!
    Approccio non coerente con il modello agile: o si lavora in deroga o si torna al classico modello dei FP (o peggio, dei gg-persona) su grandi contratti-quadro.
    Ma vorrei essere smentito!

  • Giulia De Bortoli

    Partire sempre dall’analisi del contesto attuale https://www.youtube.com/watch?v=WbFFalBZsQM

Articoli correlati