La gestione dei progetti informatici si riferisce all’insieme delle attività che consentono di trasformare un bisogno aziendale in un deliverable tecnico, all’interno di un quadro di costi, tempi e qualità definiti in anticipo. Gestire un progetto informatico in azienda implica padroneggiare sia il perimetro funzionale, che le dipendenze tecniche e il coordinamento dei team. Tre dimensioni che, se mal articolate, sono sufficienti a far deragliare un progetto ben prima della prima riga di codice.
Cybersecurity e conformità NIS2: un rischio progetto da integrare fin dalla fase di definizione
La maggior parte delle guide di gestione dei progetti informatici affronta i rischi dal punto di vista del budget o del calendario. La direttiva europea NIS2 aggiunge una vincolo normativo diretto: le organizzazioni interessate devono tenere conto della sicurezza dei loro fornitori e prestatori di servizi, comprese le loro vulnerabilità specifiche.
In pratica, ciò significa che un progetto IT che coinvolge un fornitore SaaS, un hosting o un integratore deve mappare queste dipendenze fin dalla fase di definizione. I requisiti di sicurezza devono quindi figurare nei contratti, e la verifica delle prove di conformità diventa un traguardo del progetto, non un audit occasionale effettuato successivamente.
Il calendario francese di trasposizione di NIS2 non è ancora completamente stabilizzato, ma le organizzazioni che potrebbero essere interessate hanno interesse ad anticipare. Determinare lo stato dell’entità, documentare i rischi e testare la rilevazione e la notifica di incidenti costituiscono un progetto a sé stante nella gestione di un progetto informatico. Risorse specializzate consentono di approfondire queste questioni di gestione: https://www.projets-informatiques.fr/ centralizza in particolare dei feedback sull’esecuzione di progetti IT.
Un punto spesso sottovalutato: NIS2 può combinarsi con altri quadri come DORA o il Cyber Resilience Act. Un singolo incidente può quindi comportare più notifiche, con scadenze e criteri diversi. Il progetto deve definire in anticipo chi qualifica l’incidente e chi decide di notificare, pena confusione operativa nel momento peggiore.
Gestione del perimetro del progetto: la deriva silenziosa che costa di più
Il perimetro di un progetto informatico si riferisce all’insieme delle funzionalità, deliverable e vincoli accettati da tutte le parti interessate all’avvio. Qualsiasi modifica non formalizzata di questo perimetro costituisce ciò che chiamiamo scope creep.
Lo scope creep non si manifesta con una richiesta spettacolare. Prende la forma di micro-aggiunte: un campo aggiuntivo in un modulo, un’integrazione con uno strumento di terze parti “che richiederà solo due giorni”, un rapporto richiesto in una riunione di follow-up. Presi singolarmente, ognuno sembra innocuo. Accumulati nel corso di diversi mesi, spostano il piano di diverse settimane e mobilitano risorse non previste.
Formalizzare il processo di richiesta di cambiamento
Per contenere questa deriva, ogni modifica del perimetro deve passare attraverso un processo esplicito. Questo processo comprende tre elementi concreti:
- Un modulo di richiesta di cambiamento (change request) redatto dal richiedente, che descrive il bisogno, l’impatto stimato sul piano e sul budget, e la giustificazione aziendale.
- Un comitato di pilotaggio o un responsabile designato che valida o rifiuta la richiesta sulla base di criteri oggettivi, non durante una discussione informale.
- Un aggiornamento del riferimento del progetto (piano, budget, documentazione funzionale) ad ogni cambiamento accettato, affinché il team lavori sempre su una versione aggiornata del perimetro.
Senzo questo meccanismo, il project manager assorbe le richieste per default, e il perimetro reale diverge da quello contrattuale. La tracciabilità dei cambiamenti protegge sia il team tecnico che il committente.
Comunicazione tra team tecnici e aziendali: strutturare gli scambi
La comunicazione in un progetto informatico non si limita a inviare un resoconto settimanale. Il problema ricorrente risiede nell’asimmetria del linguaggio tra i team tecnici e le parti interessate aziendali. Un sviluppatore parla di API, di debito tecnico e di sprint. Un direttore commerciale vuole sapere se la funzionalità sarà disponibile per il prossimo trimestre.
Questa asimmetria genera due tipi di disfunzioni. Il primo: i team aziendali convalidano specifiche che non hanno compreso, il che produce deliverable conformi al capitolato ma inutilizzabili. Il secondo: i team tecnici sottovalutano l’importanza di un bisogno aziendale perché è stato formulato in modo vago.
Rituali di sincronizzazione adattati al contesto
La frequenza e il formato degli scambi devono variare a seconda della fase del progetto. Nella fase di definizione, workshop di co-progettazione con supporti visivi (mockup, percorsi utente) riducono i malintesi. Nella fase di esecuzione, un breve incontro quotidiano o bisettimanale tra il project manager e i referenti aziendali è sufficiente per rilevare le discrepanze prima che diventino blocchi.
Un cruscotto condiviso, aggiornato in tempo reale tramite uno strumento di gestione delle attività, sostituisce utilmente le lunghe email di reporting. L’obiettivo non è moltiplicare le riunioni, ma rendere l’informazione accessibile al giusto livello di dettaglio per ogni interlocutore.
Indicatori di gestione del progetto informatico: misurare ciò che conta
Gestire un progetto senza indicatori equivale a guidare senza cruscotto. Due categorie di indicatori meritano di essere seguite in parallelo: gli indicatori di avanzamento e gli indicatori di salute.
Gli indicatori di avanzamento misurano il progresso rispetto al piano: percentuale di attività completate, rispetto delle scadenze, consumo del budget. Rispondono alla domanda “siamo nei tempi?”.
Gli indicatori di salute misurano la qualità del processo stesso: numero di bug aperti, tasso di copertura dei test, tempo medio di risoluzione delle anomalie, tasso di partecipazione ai rituali di comunicazione. Un progetto può essere “nei tempi” accumulando un debito tecnico che esploderà dopo la messa in produzione.
- Il monitoraggio della velocità (in metodologia agile) o della deviazione pianificata/reale (in metodologia sequenziale) consente di aggiustare le risorse prima che il ritardo diventi irrimediabile.
- Il numero di richieste di cambiamento accettate per sprint o per fase fornisce una misura oggettiva della stabilità del perimetro.
- Il tasso di disponibilità degli ambienti di test segnala i colli di bottiglia tecnici spesso invisibili nei report classici.
Monitorare questi indicatori richiede rigore, ma anche discernimento. Un cruscotto sovraccarico di metriche perde la sua funzione di allerta. Tre a cinque indicatori ben scelti, riesaminati ad ogni comitato di pilotaggio, apportano più valore di una ventina di curve che nessuno legge.
Il successo di un progetto informatico dipende meno dalla scelta di una metodologia agile o sequenziale che dalla capacità del team di mantenere un perimetro stabile, scambi leggibili tra business e tecnica, e indicatori che attivano l’azione prima della crisi. La conformità normativa, in particolare con NIS2, aggiunge ora una quarta dimensione che la gestione del progetto non può più trattare come un margine.
