I progetti IT falliscono più spesso di qualsiasi altro tipo, solitamente a causa di un ambito poco chiaro, dipendenze non considerate o una comunicazione debole. Con Trupeer, puoi risparmiare ore di pianificazione partendo da un modello di piano di progetto IT gratuito, personalizzandolo con la tua identità di marca e trasformando il piano in aggiornamenti video che mantengono allineati gli stakeholder tecnici e commerciali.

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 cosa deve essere vero affinché ciò avvenga. Ogni modello che si posiziona per questa ricerca ti fornirà questo, solitamente sotto forma di un elenco di attività con date di inizio, date di fine, responsabili e una barra di Gantt.

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

I modelli generici iniziano con il tuo lavoro. Elenchi le attività, ne stimi la durata, le sequenzi, aggiungi i responsabili e la data di fine viene fuori alla fine. Le dipendenze vengono aggiunte in seguito, in una colonna, come nota.

I progetti IT raramente subiscono ritardi perché quelle stime erano errate. Subiscono ritardi perché si presenta qualcosa che non era mai stato previsto nel piano e con cui non si poteva discutere: un blocco delle modifiche che copre la settimana di go-live, una revisione della sicurezza con una coda di sei settimane, un fornitore i cui consulenti di implementazione sono prenotati fino alla fine del trimestre, una licenza che si rinnova prima che il sostituto sia pronto, un audit che blocca l'ambiente per un mese.

Nessuno di questi è un rischio. Un rischio è qualcosa che potrebbe accadere. Questi sono già reali il giorno in cui inizi a pianificare, e ognuno di essi è conoscibile nella prima settimana se qualcuno lo chiede.

Quindi questo modello inverte l'ordine. Disegni prima le date che non puoi spostare. Poi scopri quanto è effettivamente ampia la finestra temporale rimanente. Infine pianifichi il lavoro all'interno di essa. L'elenco delle attività esiste ancora, semplicemente non è più la prima cosa che scrivi.

Come personalizzare questo modello in Trupeer

Passo 1: Apri la sezione Modelli

Vai alla sezione Modelli dalla navigazione principale.

Passo 2: Seleziona e apri un modello

Clicca su qualsiasi modello con cui desideri lavorare per aprirlo.

Passo 3: Espandi la vista del modello

Se necessario, espandi la vista del modello per vedere chiaramente l'intero layout e i dettagli.

Passo 4: Modifica il modello

Clicca su Modifica per iniziare a modificare 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 relative impostazioni

Passo 5: Salva il tuo modello personalizzato

Dopo aver apportato tutte le modifiche necessarie, clicca su Salva per memorizzare il modello aggiornato come tuo.

Passo 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: Salta la pagina bianca con una struttura creata appositamente per le iniziative IT.

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

• Rimanere in linea con il brand: Applica il tuo logo, i tuoi caratteri e i tuoi colori utilizzando il kit del brand di Trupeer.

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

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

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

Gli inamovibili e dove trovarli

Un inamovibile è qualsiasi data o durata stabilita da qualcuno che non risponde al progetto. Non puoi negoziarla all'interno del progetto, e scoprirla in ritardo la trasforma da un vincolo a una crisi.

Ecco l'inventario da eseguire nella prima settimana. Fai a ciascun proprietario due domande: qual è la tua data e qual è il tuo tempo di lead time.

Due di questi meritano una particolare attenzione perché sono quelli che più spesso vengono dimenticati. I periodi di preavviso sui contratti sono date inamovibili che si collocano prima della data di rinnovo, il che significa che la scadenza reale è anticipata rispetto a quella sul calendario. E la qualità dei dati nel sistema sorgente è l'unico elemento inamovibile la cui entità non può essere cercata in un documento. Devi andare a misurarla, motivo per cui la profilazione dei dati sorgente appartiene alla prima settimana piuttosto che alla fase di migrazione.

Disegna questi elementi su un unico calendario prima di stimare qualsiasi cosa. Quello che stai cercando è la forma dello spazio vuoto. Molto spesso questo spazio è molto più stretto della durata del progetto, e l'onesta conversazione sull'ambito avviene nella seconda settimana anziché nel settimo mese.

Cosa includere nel piano

Una volta tracciati gli inamovibili, il piano stesso si compone di dodici sezioni. Copia le intestazioni e compilale in questo ordine.

1. Sintesi. Una sola frase: cosa cambia, per chi e cosa smette di essere vero dopo.

2. Risultato e criteri di successo. Misurabili e datati. Includi almeno un criterio riguardante l'elemento da sostituire, ad esempio che il sistema legacy non abbia traffico e nessun costo di licenza entro una data stabilita. I piani che terminano al go-live sono il motivo per cui le aziende finiscono per pagare per due sistemi.

3. Calendario dei vincoli. La tabella degli inamovibili sopra compilata, con la finestra di consegna risultante indicata come intervallo di date in parole semplici.

4. Ambito (Scope). Tre elenchi: incluso, escluso e posticipato. L'elenco delle attività posticipate è quello utile, perché è lì che finisce l'ambito quando viene ridotto, evitando che la stessa conversazione si ripeta quattro volte.

5. Fasi e pietre miliari (Milestones). Le pietre miliari sono eventi con una risposta osservabile, ad esempio "revisione di sicurezza superata" o "primo negozio attivo", non "fase di progettazione completata".

6. Scomposizione del lavoro (WBS). Attività, responsabili, stime, sequenza. Questa è la parte da cui inizia ogni altro modello.

7. Dipendenze. Separa quelle interne da quelle esterne. Ogni dipendenza esterna deve avere una persona di riferimento indicata per nome presso l'altra organizzazione e una data concordata, non una data ipotizzata da te.

8. Ambienti e dati. Quali ambienti esistono, quali dati si trovano in ciascuno, come vengono protetti i dati di produzione nei test e il risultato della profilazione dei dati sorgente.

9. Transizione e ripristino (Cutover e rollback). La sequenza ora per ora per il passaggio, il punto decisionale in cui fermarsi, chi prende tale decisione e come tornare indietro. Scrivilo come una procedura eseguibile, che è dove si colloca un modello di metodo di procedura.

10. Rischi con trigger. Non una griglia di probabilità e impatto. Ogni rischio riceve un trigger osservabile e l'azione che si attiva quando il trigger si manifesta. "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 detto cosa e quando, e cosa ci si aspetta che gli utenti siano in grado di fare il primo giorno.

12. Governance e chiusura. Chi decide, chi escala, come appare un record decisionale e le condizioni in base alle quali il progetto viene dichiarato terminato e consegnato alla gestione operativa.

Un esempio pratico e quanto è costato

Ashmore Retail, ottantaquattro negozi e tre centri di distribuzione, ha avviato a febbraio la sostituzione del sistema di gestione del magazzino (WMS) in tutti e tre i centri. Nove mesi di lavoro, go-live pianificato per metà novembre, descritto nella presentazione di avvio come un atterraggio comodo ben prima del picco stagionale.

Esistevano due elementi inamovibili il giorno dell'avvio. Entrambi erano stati pubblicati. Nessuno dei due era presente nel piano.

Il primo era il blocco delle modifiche (change freeze). Le operazioni di vendita al dettaglio lo pubblicano ogni gennaio e va dal 1° novembre al 15 gennaio, coprendo il periodo di picco delle vendite. In quelle undici settimane non viene introdotta alcuna modifica di produzione di alcun tipo.

Il secondo era il contratto legacy. Si rinnovava il 31 dicembre per ulteriori dodici mesi al costo di centottantaseimila sterline, con preavviso richiesto di novanta giorni, il che fissava la scadenza reale al 2 ottobre.

Il progetto è proseguito come da piano durante la primavera. La revisione di sicurezza ha richiesto quattro settimane a fronte di uno SLA dichiarato di due. I consulenti di implementazione del fornitore non sono stati disponibili fino a ottobre, perché erano stati richiesti a luglio. Entrambi i ritardi sono stati assorbiti spostando il go-live da metà novembre a fine novembre, cosa che nessuno ha segnalato perché nessuno guardava il calendario dei blocchi.

Il blocco delle modifiche è emerso in una riunione del comitato consultivo per le modifiche all'inizio di settembre. Il go-live a novembre non era possibile e la successiva finestra utile si sarebbe aperta il 16 gennaio.

Ciò lasciava una sola scelta da fare entro il 2 ottobre. Dare il preavviso di disdetta sul contratto legacy e operare dal 1° gennaio senza alcun supporto sul sistema da cui dipendeva l'intera azienda, oppure lasciarlo rinnovare e pagare per un anno un sistema che avevano pianificato di spegnere a novembre.

Hanno lasciato che si rinnovasse. Il nuovo sistema è andato live il 4 marzo. Il contratto legacy è stato utilizzato per nove settimane del suo termine di cinquantadue settimane, il che equivale a circa trentaduemila sterline di valore a fronte di una fattura di centottantaseimila sterline. Circa centocinquantaquattromila sterline non hanno acquistato nulla.

La parte istruttiva è che il progetto non è mai stato in ritardo nel senso comune che le persone attribuiscono a questo termine. Il lavoro è stato svolto secondo uno standard ragionevole e a un ritmo ragionevole. Ciò che è andato storto è che la finestra temporale era più stretta di sei settimane rispetto a quanto pianificato, e le due date che la definivano erano presenti in un calendario pubblicato e in un contratto firmato prima ancora che il progetto esistesse.

Se il calendario dei vincoli fosse stato disegnato a febbraio, la sequenza sarebbe stata ovvia. Go-live prima del 1° novembre, procedendo a ritroso attraverso una revisione di sicurezza di quattro settimane (che in realtà erano sei), un percorso di acquisto di sei settimane e consulenti che necessitavano di un trimestre di preavviso; ciò significava che il contratto con il fornitore doveva essere firmato entro metà aprile. È stato firmato a luglio. Il progetto non aveva bisogno di andare più veloce. Aveva bisogno di avviare le sue dipendenze inamovibili undici settimane prima.

Cinque tipologie di progetti IT e quali sezioni sono cruciali

In questa ricerca sono comuni gli elenchi di venti modelli di progetti IT, che coprono tutto, dall'implementazione ITSM agli aggiornamenti dell'infrastruttura fino alla creazione del PMO. In pratica si riducono a cinque tipologie, e la tipologia ti dice quali delle sezioni sopra descritte meritano maggiore dettaglio.

Sostituzione. Sostituire un sistema funzionante con uno diverso. Include WMS, ERP, strumenti ITSM, piattaforme di help desk, sistemi HR. Le sezioni 3, 9 e 2 sono le più importanti, perché le parti difficili sono la finestra temporale, la transizione e la prova che il vecchio sistema sia effettivamente spento.

Implementazione. Qualcosa di nuovo senza un predecessore. Include la gestione degli SLA, i programmi di IT governance e conformità, la gestione degli asset, la gestione della conoscenza. Le sezioni 11 and 2 sono cruciali, perché prima non c'era nulla di rotto, quindi l'adozione è l'unica cosa che rende reale il progetto. La nostra guida all'implementazione dell'adozione digitale approfondisce questo aspetto.

Migrazione o aggiornamento in loco. Stesso sistema, nuova versione, nuovo host o nuova area geografica. Include virtualizzazione, consolidamento, migrazione al cloud, aggiornamenti di database. Le sezioni 8 e 9 sono le più importanti, perché il rollback è l'intero gioco.

Sviluppo (Build). Sviluppo software e automazione dei processi. La sezione 4 è quella cruciale, perché l'ambito è la variabile che si muove e i criteri di accettazione sono ciò che impedisce che si muova in silenzio.

Programma e garanzia (Assurance). Creazione di PMO, audit IT, gestione del portafoglio, gestione del rischio, conformità di sicurezza. La sezione 12 è fondamentale, perché l'elemento finale da consegnare è costituito da prove e approvazioni piuttosto che da un sistema funzionante, e le tappe fondamentali sono date di revisione stabilite da qualcun altro.

Se il tuo progetto non rientra chiaramente in uno di questi, di solito si tratta di due progetti a cui è stato dato un unico nome.

Costruire il piano in un giorno

Mattina, disegna gli inamovibili. Invia le due domande a ciascun proprietario indicato nella tabella, sollecita prima le risposte del fornitore e della sicurezza perché sono quelle che richiedono più tempo, e inserisci ogni data che ricevi su un unico calendario. Esprimi la finestra risultante in una frase.

Pomeriggio, scrivi le sezioni 1, 2 e 4, poi le pietre miliari. Lascia che sia il team di sviluppo a compilare la scomposizione dettagliata delle attività durante la settimana. Un piano è utile nel momento stesso in cui vengono concordati la finestra temporale e l'ambito, e non è più utile solo perché contiene quattrocento righe.

Verificalo rispetto alla finestra temporale ad ogni riunione di governance. L'unica domanda che vale la pena porsi non è "siamo in linea con i tempi" ma "si è spostato qualche elemento inamovibile". I blocchi vengono estesi, gli audit riprogrammati e i fornitori perdono consulenti. Tali cambiamenti ridisegnano il piano in un modo in cui un'attività ritardata non farà mai.

Cosa escludere

Un diagramma di Gantt di ogni singola attività non appartiene al documento del piano. Appartiene a qualunque strumento tu utilizzi per la pianificazione, e duplicarlo in un documento crea due versioni che saranno in disaccordo nel giro di due settimane.

Nemmeno un registro dei rischi completo con i relativi punteggi appartiene a questo documento. Conserva i rischi che hanno trigger e date, e inserisci il resto nel registro.

Le procedure dettagliate su come viene svolto il lavoro appartengono a una SOP IT, e la descrizione di ciò che hai costruito appartiene alla documentazione IT piuttosto che al piano. Il passaggio di consegne al team operativo merita di essere pianificato correttamente, ed è a questo che serve una SOP per il trasferimento di conoscenza.

Quando smettere di usare un documento e usare un software

Un documento è lo strumento giusto mentre si discute del piano, il che occupa gran parte del primo mese. Smette di essere lo strumento giusto quando si verificano contemporaneamente tre condizioni: più di trenta attività circa sono attive, più di quattro persone aggiornano lo stato e le dipendenze tra le attività iniziano a cambiare settimanalmente.

A quel punto sposta la scomposizione del lavoro in un software di pianificazione e conserva il documento per le sezioni da 1 a 5 e la 12, che sono le parti lette dalle persone che non apriranno mai lo strumento. Il documento contiene l'accordo. Lo strumento contiene la pianificazione.

Trasformare il piano in qualcosa che il team di sviluppo segua davvero

Il piano viene letto all'avvio e alla riunione del comitato di controllo. La guida per la transizione (cutover runbook) viene letta alle due di notte da qualcuno che non era presente a nessuna delle due riunioni.

Trupeer AI trasforma una registrazione dello schermo in un processo documentato, in modo che i passaggi di transizione nella sezione 9 e le attività del primo giorno nella sezione 11 diventino procedure guidate dei tuoi sistemi reali piuttosto che paragrafi che li descrivono. Registra la sequenza una volta e otterrai una guida passo-passo, un video e un documento nella tua base di conoscenza, con il tuo brand aziendale.

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

Per il lavoro sull'adozione nella sezione 11, la gestione del cambiamento e i video di formazione coprono la parte del lancio, e la documentazione tiene insieme il piano, la guida operativa e il materiale di passaggio consegne. Le istruzioni di configurazione si trovano nella guida alla configurazione del modello di documento.

Domande frequenti

Esiste un modello gratuito di piano di progetto IT in Excel?

Non come file fornito da noi, e vale la pena essere onesti sul compromesso. Excel è oggettivamente lo strumento migliore per la scomposizione del lavoro nella sezione 6, perché date, dipendenze e aggregazioni appartengono alle celle. Costruisci tu stesso quel foglio con colonne per attività, responsabile, inizio, fine, dipendenza, stato e flag di inamovibile. Conserva le sezioni da 1 a 5, 9 e 12 come documento, perché vengono discusse in prosa e nessuno negozia l'ambito di un progetto all'interno di un foglio di calcolo.

Esiste una versione in Word o un download gratuito in formato Word?

La struttura in dodici sezioni descritta sopra è scritta per essere copiata direttamente in Word o Google Docs. Incolla le intestazioni, mantieni la numerazione e compilale nell'ordine indicato. Non c'è un download con registrazione richiesta, il che significa anche che non ci sono moduli tra te e la struttura del documento.

Esiste una versione in PDF?

Incolla le sezioni nel tuo editor ed esporta in PDF quando il piano viene approvato. Vale la pena congelare un piano in formato PDF al momento della firma, mantenendolo invece modificabile prima di allora, quindi esportare la propria copia al momento giusto è meglio che partire da un file fisso.

Esiste una versione in PPT per la presentazione di avvio (kickoff)?

La presentazione è un documento diverso con un compito diverso. Sei diapositive sono solitamente sufficienti: il risultato, la finestra di consegna dal tuo calendario dei vincoli, l'ambito incluso ed escluso, le pietre miliari, le dipendenze esterne indicate con nome e cognome e chi decide cosa. Non inserire la scomposizione del lavoro nella presentazione. Nessuno legge una barra di Gantt proiettata su uno schermo.

Posso scaricarlo gratuitamente?

La struttura, la tabella degli inamovibili e l'esempio pratico sono gratuiti e senza limitazioni. Utilizzali, modificali, inseriscili nella tua libreria di modelli con il tuo nome.

Un piano di consegna del progetto (delivery plan) è uguale a un piano di progetto?

La differenza è talmente minima che la distinzione raramente ne giustifica lo sforzo. Laddove le organizzazioni li separino, il piano di progetto copre l'intera vita del progetto, inclusi il business case e la chiusura, mentre il piano di consegna copre solo la parte di sviluppo e rilascio. Se la tua governance richiede entrambi, scrivi il piano sopra descritto e tratta le sezioni da 5 a 9 come piano di consegna.

Ho bisogno anche di un modello di report per la gestione del progetto separato?

Sì, e mantienilo molto più breve di quanto ti aspetti. Un report sullo stato di avanzamento che ripete il piano viene ignorato nel giro di un mese. Riporta quattro cose: se si è spostato qualche elemento inamovibile, se la finestra temporale è ancora sufficientemente ampia, quale decisione hai bisogno da questo gruppo oggi e cosa si è attivato dall'elenco dei rischi dall'ultima volta.

Quanto deve essere dettagliato un piano di progetto IT?

Abbastanza dettagliato da consentire a un nuovo arrivato di capire cosa succederà dopo, e nulla di più. In pratica, il documento del piano è composto da circa otto-quindici pagine per un progetto di nove mesi, la maggior parte delle quali dedicate alle sezioni 8 e 9. Se il documento è più lungo del runbook di transizione, l'equilibrio è errato.

Ogni quanto tempo deve essere aggiornato il piano?

Le sezioni 6 e 7 cambiano settimanalmente e appartengono a qualunque strumento il tuo team utilizzi già per lavorare. Le sezioni da 1 a 5 dovrebbero cambiare raramente e ogni modifica ad esse è una decisione che qualcuno deve approvare. Se la tua sezione sull'ambito viene modificata in silenzio ogni settimana, non hai un piano, hai un diario.