I progetti IT falliscono più spesso di qualsiasi altro tipo, solitamente a causa di un ambito poco chiaro, dipendenze trascurate o una comunicazione debole. Con Trupeer puoi risparmiare ore di pianificazione iniziando con un modello gratuito di piano di progetto IT, personalizzandolo con la tua brand identity e trasformando il piano in aggiornamenti video che mantengono allineati gli stakeholder tecnici e di business.

Cos'è un piano di progetto IT e perché i modelli generici falliscono

Un piano di progetto è il documento che stabilisce cosa verrà consegnato, entro quando, da chi e quali condizioni devono sussistere affinché ciò accada. Ogni modello che si posiziona per questa ricerca ti fornirà questi elementi, solitamente come un elenco di attività con date di inizio, date di fine, responsabili e un diagramma di Gantt.

L'elenco delle attività non è il problema. Il problema è l'ordine in cui lo compili.

I modelli generici partono dal tuo lavoro. Elenchi le attività, stimi le durate, le metti in sequenza, assegni i responsabili e la data di fine scaturisce in automatico in fondo. Le dipendenze vengono aggiunte dopo, in una colonna, come semplice nota.

I progetti IT raramente subiscono ritardi perché tali stime erano errate. Slittano perché si presenta qualcosa che non era mai stato previsto nel piano e con cui non si può discutere: un blocco delle modifiche (change freeze) nella settimana di rilascio, una revisione della sicurezza con sei settimane di coda, un fornitore i cui consulenti di implementazione sono al completo fino alla fine del trimestre, una licenza che si rinnova prima che la soluzione sostitutiva sia pronta, un audit che blocca l'ambiente per un mese.

Nessuno di questi è un rischio. Un rischio è qualcosa che potrebbe accadere. Questi fattori sono invece già reali il giorno in cui inizi a pianificare, e ognuno di essi è conoscibile fin dalla prima settimana, se qualcuno se ne informa.

Questo modello, quindi, inverte l'ordine. Per prima cosa definisci le date che non puoi spostare. Poi scopri quanto sia effettivamente ampia la finestra temporale rimanente. Infine pianifichi il lavoro al suo interno. L'elenco delle attività esiste ancora, ma smette semplicemente di essere la prima cosa che scrivi.

Come personalizzare questo modello in Trupeer

Passaggio 1: Apri la sezione Modelli

Vai alla sezione Modelli dal menu di navigazione principale.

Passaggio 2: Seleziona e apri un modello

Fai clic su un modello qualsiasi con cui desideri lavorare per aprirlo.

Passaggio 3: Espandi la visualizzazione del modello

Se necessario, espandi la visualizzazione del modello per vedere chiaramente il layout completo e i dettagli.

Passaggio 4: Modifica il modello

Fai clic su Modifica per iniziare a personalizzare il modello selezionato.

All'interno dell'editor puoi:

• Aggiungere nuove sezioni

• Definire o aggiornare le regole di formattazione

• Aggiungere un logo e regolarne la posizione e le impostazioni correlate

Passaggio 5: Salva il tuo modello personalizzato

Dopo aver apportato tutte le modifiche necessarie, fai clic su Salva per archiviare il modello aggiornato tra i tuoi.

Passaggio 6: Visualizza l'anteprima e perfeziona il modello

Quando vuoi vedere come appare il tuo modello personalizzato, apri l'Anteprima.

Dalla schermata di anteprima puoi continuare ad apportare modifiche direttamente se necessario, assicurandoti che il modello appaia esattamente come desideri.

Con un modello di piano di progetto IT puoi:

• Risparmiare ore di pianificazione: evita la pagina bianca grazie a una struttura creata appositamente per le iniziative IT.

• Gestire la complessità tecnica: sezioni integrate per architettura, dipendenze e rischi.

• Rispettare la brand identity: applica logo, font e colori aziendali utilizzando il brand kit di Trupeer.

• Allineare business e IT: converti i piani tecnici in aggiornamenti video facilmente comprensibili per gli stakeholder aziendali.

• Standardizzare tra i progetti: usa lo stesso modello per ogni iniziativa IT.

• Raggiungere team globali: traduci piani e aggiornamenti in oltre 65 lingue con un solo clic.

I punti fermi (immovables) e dove trovarli

Un punto fermo è qualsiasi data o durata stabilita da qualcuno che non risponde al progetto. Non puoi negoziarlo all'interno del progetto e scoprirlo in ritardo lo trasforma da vincolo in crisi.

Ecco l'inventario da effettuare nella prima settimana. Poni a ciascun responsabile due domande: qual è la tua data e qual è il tuo tempo di consegna (lead time).

Due di questi meritano particolare attenzione perché sono quelli che vengono trascurati più spesso. I periodi di preavviso sui contratti sono date fisse che precedono la data di rinnovo: questo significa che la scadenza reale è antecedente a quella segnata sul calendario. Inoltre, la qualità dei dati nel sistema di origine è l'unico punto fermo la cui entità non può essere semplicemente verificata su un documento. È necessario analizzarla e misurarla sul campo, motivo per cui la profilazione dei dati di origine va effettuata nella prima settimana anziché durante la fase di migrazione.

Traccia questi punti su un unico calendario prima di fare qualsiasi stima. L'obiettivo è individuare l'ampiezza dell'intervallo a disposizione. Molto spesso questo intervallo è decisamente più ridotto rispetto alla durata prevista del progetto, e la discussione trasparente sull'ambito avverrà così nella seconda settimana anziché al settimo mese.

Cosa includere nel piano

Una volta tracciati i punti fermi, il piano vero e proprio si articola in dodici sezioni. Copia i titoli e compilali in questo ordine.

1. Riepilogo. Una sola frase: cosa cambia, per chi e cosa cesserà di esistere in seguito.

2. Risultati e criteri di successo. Misurabili e con scadenze precise. Includi almeno un criterio relativo all'elemento sostituito, ad esempio che il sistema legacy sia privo di traffico e di costi di licenza entro una data stabilita. I piani che terminano con il go-live sono il motivo per cui le aziende finiscono per pagare due sistemi contemporaneamente.

3. Calendario dei vincoli. La tabella dei punti fermi sopra riportata, debitamente compilata, con la finestra di consegna risultante specificata a parole come intervallo di date.

4. Ambito (Scope). Tre elenchi: incluso, escluso e posticipato. L'elenco degli elementi posticipati è quello più utile, poiché raccoglie l'ambito tagliato ed evita che la stessa discussione si ripeta quattro volte.

5. Fasi e milestone. Le milestone sono eventi con un esito oggettivamente riscontrabile, ad esempio "revisione di sicurezza superata" o "primo punto vendita attivo", non "fase di progettazione completata".

6. Scomposizione del lavoro (Work Breakdown). Attività, responsabili, stime, sequenza. Questa è la parte da cui iniziano tutti gli altri modelli.

7. Dipendenze. Separa quelle interne da quelle esterne. A ogni dipendenza esterna deve corrispondere un referente nominativo nell'altra organizzazione e una data da quest'ultimo concordata, non una data da te presunta.

8. Ambienti e dati. Quali ambienti esistono, quali dati sono presenti in ciascuno di essi, come vengono protetti i dati di produzione durante i test e l'esito della profilazione dei dati di origine.

9. Rilascio (Cutover) e rollback. La sequenza ora per ora per il passaggio, il punto di decisione in cui fermarsi, chi ha la responsabilità di tale scelta e come ripristinare la situazione precedente. Redigi questa parte come una procedura operativa dettagliata, ed è qui che trova spazio un modello di metodo di procedura (MOP).

10. Rischi con trigger. Non una griglia di probabilità e impatto. A ciascun rischio deve essere associato un evento scatenante (trigger) osservabile e l'azione che si attiva al suo verificarsi. "Consulente del fornitore non confermato entro il 12 maggio" è un trigger. "Il fornitore potrebbe essere in ritardo" non lo è.

11. Comunicazione, formazione e adozione. A chi viene comunicato cosa e quando, e cosa ci si aspetta che gli utenti siano in grado di fare dal primo giorno.

12. Governance e chiusura. Chi decide, a chi fare escalation, come è fatto un verbale decisionale e le condizioni in base alle quali il progetto viene dichiarato completato e affidato all'operatività ordinaria.

Un esempio pratico e quanto è costato

Ashmore Retail, ottantaquattro punti vendita e tre centri di distribuzione (Ce.Di.), a febbraio ha avviato il progetto per sostituire il sistema di gestione del magazzino (WMS) in tutti e tre i centri. Nove mesi di lavoro, rilascio previsto a metà novembre, descritto nella presentazione di avvio (kickoff) come un traguardo che avrebbe preceduto agevolmente il periodo di picco.

Il giorno di quel kickoff esistevano due punti fermi. Entrambi erano stati pubblicati. Nessuno dei due compariva nel piano.

Il primo era il blocco delle modifiche. L'ufficio operativo retail lo pubblica ogni gennaio e va dal 1° novembre al 15 gennaio, a copertura dell'alta stagione delle vendite. Durante queste undici settimane non è consentita alcuna modifica di alcun tipo in ambiente di produzione.

Il secondo era il contratto del sistema legacy. Si rinnovava il 31 dicembre per altri dodici mesi al costo di centottantaseimila sterline, con un preavviso richiesto di novanta giorni: ciò fissava la scadenza effettiva al 2 ottobre.

Il progetto è proseguito secondo i piani per tutta la primavera. La revisione di sicurezza ha richiesto quattro settimane rispetto a un SLA dichiarato di due. I consulenti di implementazione del fornitore non erano disponibili prima di ottobre, poiché erano stati richiesti solo a luglio. Entrambi gli slittamenti sono stati assorbiti posticipando il go-live da metà novembre a fine novembre, circostanza che nessuno ha segnalato poiché nessuno consultava il calendario dei blocchi.

La questione del blocco è emersa durante una riunione del comitato consultivo per le modifiche (CAB) all'inizio di settembre. Il rilascio a novembre non era realizzabile e la successiva finestra utile si sarebbe aperta solo il 16 gennaio.

Ciò lasciava una sola decisione da prendere entro il 2 ottobre: dare disdetta del contratto legacy e lavorare dal 1° gennaio senza alcun supporto sul sistema da cui dipendeva l'intera azienda, oppure rinnovarlo e pagare un intero anno per un sistema che si prevedeva di dismettere a novembre.

Hanno optato per il rinnovo. Il nuovo sistema è entrato in funzione il 4 marzo. Il contratto legacy è stato effettivamente utilizzato solo per nove delle sue cinquantadue settimane di durata, pari a un valore di circa trentaduemila sterline a fronte di una spesa di centottantaseimila sterline. Circa centocinquantaquattromila sterline sono andate del tutto sprecate.

L'insegnamento fondamentale è che il progetto non è mai stato in ritardo nel senso comune del termine. Il lavoro è stato svolto con standard adeguati e a un ritmo ragionevole. L'errore è stato che la finestra temporale reale era più stretta di sei settimane rispetto a quanto pianificato, e le due date determinanti figuravano già in un calendario pubblico e in un contratto firmato prima ancora che il progetto iniziasse.

Se il calendario dei vincoli fosse stato redatto a febbraio, la sequenza temporale sarebbe apparsa evidente. Per andare live prima del 1° novembre, calcolando a ritroso le quattro settimane di revisione della sicurezza (che in realtà erano sei), le sei settimane per le procedure di acquisto e i consulenti che richiedevano un trimestre di preavviso, il contratto con il fornitore doveva essere firmato entro metà aprile. È stato firmato a luglio. Il progetto non doveva procedere più velocemente: doveva semplicemente avviare le sue dipendenze non negoziabili undici settimane prima.

Per i programmi ERP, lo stesso piano copre il rollout del modello globale per ciascun paese o filiale. Nei progetti SAP questo processo è spesso definito di "roll-in" e "roll-out": le modifiche vengono integrate nel modello globale (roll-in) e poi distribuite a ciascun nuovo paese (roll-out). È importante pianificare la formazione per il rollout globale per ogni ondata (wave), poiché ciascun paese andrà live in date differenti. Un piano di implementazione IT per un singolo sistema richiede meno sezioni, ma i punti fermi restano determinanti.

Cinque tipologie di progetti IT e quali sezioni sono fondamentali

Nelle ricerche online si trovano spesso elenchi di venti modelli di progetto IT diversi, che spaziano dall'implementazione ITSM agli upgrade infrastrutturali fino alla creazione di un PMO. In realtà, questi possono essere ricondotti a cinque tipologie principali, ciascuna delle quali determina quali sezioni sopra descritte richiedono maggiore dettaglio.

Sostituzione. Sostituzione di un sistema operativo con uno diverso. Include WMS, ERP, strumenti ITSM, piattaforme di help desk, sistemi HR. Le sezioni 3, 9 e 2 sono le più rilevanti, poiché le maggiori complessità risiedono nella finestra temporale, nel cutover e nell'accertarsi che la vecchia piattaforma sia realmente dismessa.

Implementazione. Introduzione di una nuova soluzione che non ha predecessori. Include gestione degli SLA, programmi di governance e conformità IT, asset management, knowledge management. Le sezioni 11 e 2 sono quelle determinanti: non essendoci nulla di preesistente, solo l'adozione da parte degli utenti rende concreto il risultato. La nostra guida all'implementazione dell'adozione digitale approfondisce questo tema.

Migrazione o upgrade in loco. Stesso sistema, ma con nuova versione, nuovo hosting o nuova regione. Include virtualizzazione, consolidamento, migrazione su cloud, aggiornamenti di database. Le sezioni 8 e 9 sono le più importanti, poiché la procedura di rollback è cruciale.

Sviluppo (Build). Sviluppo software e automazione dei processi. La sezione 4 è fondamentale, poiché l'ambito è la variabile soggetta a variazioni e i criteri di accettazione sono ciò che impedisce modifiche incontrollate.

Programma e assurance. Creazione di PMO, audit IT, gestione del portfolio, gestione del rischio, conformità della sicurezza. La sezione 12 è la più rilevante, poiché il deliverable consiste in attestazioni formali e approvazioni anziché in un sistema funzionante, e le milestone sono date di revisione fissate da terzi.

Se il tuo progetto non rientra chiaramente in una di queste categorie, solitamente significa che si tratta di due progetti distinti riuniti sotto un unico nome.

Costruire il piano in un giorno

Al mattino, definisci i punti fermi. Invia le due domande a ciascun referente indicato nella tabella, sollecitando per prime le risposte del fornitore e della sicurezza in quanto richiedono tempi più lunghi, e riporta ogni data ricevuta su un unico calendario. Esprimi la finestra risultante in una singola frase.

Al pomeriggio, redigi le sezioni 1, 2 e 4, quindi le milestone. Lascia la scomposizione dettagliata del lavoro al team di delivery, che la completerà durante la settimana. Un piano diventa utile nel momento stesso in cui la finestra temporale e l'ambito sono concordati, e non acquisisce maggior valore solo perché contiene quattrocento righe. Uno strumento per creare la struttura di scomposizione del lavoro (WBS) aiuta a trasformare tale ambito in deliverable prima che le righe si moltiplichino.

Verificalo rispetto alla finestra temporale stabilita a ogni riunione di governance. L'unica domanda da porsi non è "siamo in linea con i tempi?", ma "qualcuno dei punti fermi ha subito variazioni?". I periodi di blocco vengono estesi, gli audit vengono posticipati e i fornitori perdono risorse. Queste variazioni ridefiniscono la struttura del piano con un impatto ben maggiore rispetto al ritardo di una singola attività.

Cosa tralasciare

Un diagramma di Gantt con ogni singola attività non deve far parte del documento di piano. Deve risiedere nello strumento utilizzato per la pianificazione; duplicarlo in un documento creerebbe due versioni destinate a divergere nel giro di quindici giorni.

Nemmeno un registro completo dei rischi con punteggi dettagliati appartiene a questo documento. Mantieni solo i rischi che presentano trigger e date certe, e inserisci il resto nell'apposito registro dei rischi.

Le procedure dettagliate su come svolgere le attività devono essere inserite in una SOP IT, mentre la descrizione tecnica dell'infrastruttura realizzata appartiene alla documentazione IT, non al piano di progetto. Il passaggio di consegne al team operativo deve essere pianificato accuratamente: a questo scopo serve una SOP per il knowledge transfer.

Quando abbandonare il documento a favore di un software dedicato

Un documento rappresenta lo strumento ideale finché il piano è oggetto di discussione e definizione, ovvero per gran parte del primo mese. Cessa di essere adeguato quando si verificano contemporaneamente tre condizioni: vi sono più di circa trenta attività aperte, più di quattro persone aggiornano lo stato di avanzamento e le dipendenze reciproche tra le attività iniziano a mutare settimanalmente.

A quel punto sposta la scomposizione del lavoro in un software di pianificazione e mantieni il documento per le sezioni da 1 a 5 e la sezione 12, che sono le parti consultate da chi non accederà mai al software operativo. Il documento custodisce gli accordi. Lo strumento gestisce il calendario operativo.

Rendere il piano una guida realmente seguita dal team di delivery

Il piano viene letto durante il kickoff e nelle riunioni del comitato direttivo. Il runbook di cutover viene letto alle due del mattino da qualcuno che non era presente a nessuno dei due incontri.

Trupeer AI trasforma una registrazione dello schermo in un processo documentato: in questo modo i passaggi di cutover della sezione 9 e le attività del primo giorno della sezione 11 diventano guide pratiche sui tuoi sistemi reali anziché paragrafi descrittivi. Registra la procedura una sola volta per ottenere una guida dettagliata passo dopo passo, un video e un documento archiviato nella tua knowledge base, perfettamente in linea con il tuo brand.

Registralo. Personalizzalo con il tuo brand. Traducilo. Rendilo Trupeer.

Per l'adozione descritta nella sezione 11, il change management e i video di formazione supportano la fase di implementazione, mentre la documentazione raccoglie in un unico punto il piano, il runbook e i materiali per il passaggio di consegne. Le istruzioni di configurazione sono disponibili nella guida alla configurazione dei modelli di documento.

Domande frequenti

È disponibile un modello gratuito di piano di progetto IT in Excel?

Non come file fornito direttamente da noi, ed è utile essere chiari su questo punto. Excel è senza dubbio lo strumento migliore per la scomposizione del lavoro della sezione 6, poiché date, dipendenze e aggregazioni appartengono a una struttura a celle. Crea autonomamente questo foglio con colonne per attività, responsabile, inizio, fine, dipendenza, stato e indicatore di punto fermo. Mantieni invece le sezioni da 1 a 5, la 9 e la 12 in un documento di testo, poiché si basano su testo discorsivo e nessuno definisce l'ambito di un progetto in un foglio di calcolo.

È disponibile una versione per Word o un documento Word da scaricare gratuitamente?

La struttura in dodici sezioni sopra descritta è pensata per essere copiata e incollata direttamente in Word o Google Docs. Incolla le intestazioni, mantieni la numerazione e compila i campi nell'ordine fornito. Non vi sono download vincolati da registrazioni, il che significa che non c'è alcun modulo da compilare per accedere alla struttura.

È disponibile una versione in PDF?

Incolla le sezioni nel tuo editor di testo ed esporta in formato PDF una volta approvato il piano. È opportuno congelare un piano in formato PDF solo nel momento in cui viene formalmente approvato, mentre prima è preferibile mantenerlo modificabile: esportare la propria copia al momento opportuno è una soluzione migliore rispetto a partire da un file non editabile.

È disponibile una versione in PPT per la presentazione di kickoff?

La presentazione costituisce un documento distinto con una finalità differente. Sei slide sono solitamente sufficienti: l'obiettivo, la finestra temporale desunta dal calendario dei vincoli, l'ambito incluso ed escluso, le milestone, le dipendenze esterne con relativi responsabili e le competenze decisionali. Non inserire la scomposizione dettagliata del lavoro nella presentazione. Nessuno legge un diagramma di Gantt proiettato su uno schermo.

Posso scaricarlo gratuitamente?

La struttura, la tabella dei punti fermi e l'esempio pratico sono completamente gratuiti e senza vincoli d'uso. Puoi utilizzarli, modificarli e archiviarli nella libreria dei modelli della tua organizzazione a tuo nome.

Un piano di delivery del progetto coincide con un piano di progetto?

I concetti sono talmente affini che la distinzione raramente ha un valore concreto. Nelle realtà aziendali in cui vengono tenuti separati, il piano di progetto copre l'intero ciclo di vita dell'iniziativa, inclusi il business case e la chiusura, mentre il piano di delivery si concentra unicamente sulle fasi di sviluppo e rilascio. Se le tue linee guida di governance richiedono entrambi, adotta il piano sopra descritto e considera le sezioni da 5 a 9 come piano di delivery.

È necessario disporre anche di un modello separato per il report di project management?

Sì, ed è consigliabile mantenerlo molto più sintetico di quanto si immagini. Un report di avanzamento che si limita a ripetere i contenuti del piano viene ignorato nel giro di un mese. Riporta solo quattro informazioni: se un punto fermo ha subito variazioni, se la finestra temporale è ancora sufficientemente ampia, quale decisione è richiesta agli stakeholder presenti e quali rischi tra quelli censiti si sono attivati dall'ultimo incontro.

Quanto deve essere dettagliato un piano di progetto IT?

Deve essere dettagliato quanto basta affinché una nuova risorsa inserita nel team possa comprendere i passaggi successivi, e nulla di più. Nella pratica, il documento di piano conta dalle otto alle quindici pagine per un progetto di nove mesi, la maggior parte delle quali dedicate alle sezioni 8 e 9. Se il documento risulta più esteso del runbook di cutover, le proporzioni non sono adeguate.

Con quale frequenza va aggiornato il piano?

Le sezioni 6 e 7 variano con frequenza settimanale e devono essere gestite all'interno degli strumenti già operativi del team. Le sezioni da 1 a 5 dovrebbero cambiare di rado, e ogni variazione che le interessa rappresenta una decisione formale soggetta ad approvazione. Se la sezione relativa all'ambito viene modificata in modo informale ogni settimana, non si dispone di un piano, bensì di un diario.

Modelli correlati

• Modello gratuito di piano di progetto

• Modello gratuito di cronoprogramma di progetto

• Modello gratuito di piano di project management

• Modello gratuito di checklist di progetto