I passaggi di consegne dei progetti (project handover) sono il momento in cui si perde lo slancio, a meno che non si disponga di una checklist chiara. Con Trupeer, puoi risparmiare ore sulla documentazione di handover iniziando con un modello di checklist di handover del progetto gratuito, personalizzandolo con le tue linee guida del brand e trasformando la checklist in una video presentazione che il team ricevente può utilizzare per integrarsi rapidamente.

Cos'è un modello di checklist di handover del progetto?

Una checklist di handover del progetto è l'elenco delle condizioni che devono essere soddisfatte prima che i risultati di un progetto passino dal team che lo ha realizzato al team che lo gestirà.

Copre la documentazione, la formazione, gli accessi, le modalità di supporto, i difetti in sospeso, la proprietà e l'approvazione formale. Un modello fornisce gli elementi e il blocco di approvazione.

La distinzione che vale la pena fare fin dall'inizio è che non si tratta di un passaggio di consegne personale. Quando una persona lascia un ruolo e lo passa a un successore, il problema è il trasferimento delle conoscenze tra individui, e il nostro modello SOP di trasferimento delle conoscenze copre proprio questo.

Un handover di progetto avviene tra organizzazioni piuttosto che tra persone. Un progetto finisce; qualcosa continua. Il team ricevente conviverà con esso per anni, e lo farà alle condizioni stabilite dal progetto.

Un handover è un'accettazione, non una notifica

Quasi tutte le checklist di handover hanno la stessa struttura e lo stesso difetto fatale. Vengono compilate dal team di progetto, voce per voce, e poi firmate dal team ricevente alla fine.

Questa sequenza rende la firma del ricevente una formalità. Nel momento in cui viene richiesta, il progetto si sta chiudendo, lo sponsor è presente, il budget viene sbloccato e la data di consegna è stata annunciata. Rifiutare in quel momento significa essere la persona che ha bloccato un progetto completato all'ultimo passaggio.

Così la firma viene apposta, e il team ricevente trascorre i due anni successivi a gestire ciò che ha accettato con la firma.

Un'accettazione si differenzia da una notifica esattamente per un aspetto: il diritto di rifiuto deve essere reale. Ciò richiede due cose, nessuna delle quali compare in una checklist di handover standard. I criteri devono essere scritti dal ricevente anziché dal team di progetto. E devono essere concordati abbastanza presto affinché un eventuale rifiuto successivo sia pre-autorizzato, anziché politicamente costoso.

Come personalizzare questo modello in Trupeer

Passo 1: Apri la sezione Modelli

Vai alla sezione Modelli dal menu di navigazione principale.

Passo 2: Seleziona e apri un modello

Fai clic 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 il layout completo e i dettagli.

Passo 4: Modifica il modello

Fai clic 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, fai clic su Salva per memorizzare il modello aggiornato come tuo.

Passo 6: Visualizza l'anteprima e perfeziona il modello

Quando vuoi vedere l'aspetto del 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 checklist di handover del progetto puoi:

• Risparmiare ore sui passaggi di consegne: Evita la pagina bianca grazie a una struttura pensata per le transizioni di progetto.

• Coprire ogni elemento: Le sezioni integrate assicurano che non venga tralasciato nulla di importante.

• Mantenere la coerenza del brand: Applica il tuo logo, font e colori utilizzando il brand kit di Trupeer.

• Inserire più velocemente il team ricevente: Associa alla checklist una video presentazione.

• Standardizzare gli handover: Utilizza lo stesso modello per ogni transizione di progetto.

• Raggiungere team globali: Traduci le checklist di handover in oltre 65 lingue con un solo clic.

Il team ricevente non ha avuto voce in capitolo nel design

Vale la pena evidenziare l'asimmetria di fondo, perché spiega il comportamento anziché incolpare qualcuno.

Un progetto viene commissionato da uno sponsor, definito da un project manager e realizzato da un team riunito per l'occasione. Le persone che in seguito gestiranno il risultato vengono di solito consultate sui requisiti, a volte, e quasi mai sulla manutenibilità.

Di conseguenza, ereditano le conseguenze: il carico delle reperibilità, le soluzioni manuali provvisorie, il debito tecnico, i difetti rimandati, il fornitore il cui contratto di assistenza copre solo l'orario d'ufficio e i reclami dei clienti.

Nessuna di queste cose è visibile in un documento dei requisiti, e nessuna di esse è colpa di qualcuno in particolare. Gli incentivi del progetto spingono verso la consegna. Gli incentivi del team operativo spingono verso i tre anni successivi. L'handover è l'unico punto in cui questi due insiemi di incentivi si incontrano, e avviene l'ultimo giorno, in una stanza in cui una delle parti ha tutto lo slancio dalla sua parte.

La soluzione è spostare il confronto a un punto in cui entrambe le parti hanno ancora qualcosa da guadagnare.

Criteri di accettazione scritti dal ricevente in fase di pianificazione

L'intervento è minimo ma cambia completamente la dinamica.

In fase di pianificazione, prima che inizi la consegna, il team che gestirà i risultati scrive le condizioni alle quali li accetterà. Non il team di progetto. Loro.

Un insieme pratico comprende dieci o dodici criteri. Esistono runbook per ogni attività programmata o automatizzata. Nessun difetto superiore a una gravità concordata rimane aperto. Il supporto reperibile e fuori orario è concordato e contrattualizzato, con costi noti. L'help desk è stato formato, con una percentuale di superamento documentata. La documentazione as-built è stata verificata dal team operativo eseguendo un piccolo numero di attività reali utilizzando esclusivamente tale documentazione. Gli accessi e i permessi sono trasferiti ad account basati sui ruoli. Le modalità di supporto del fornitore sono attive e testate. Il monitoraggio e gli avvisi esistono e sono stati provati.

Sia lo sponsor del progetto che il manager ricevente firmano quell'elenco in fase di pianificazione.

Ne conseguono due cose. Il progetto può pianificare e preventivare il soddisfacimento dei criteri anziché scoprirli alla fine, il che è più economico per tutti. E il rifiuto alla chiusura diventa l'applicazione di un accordo precedente anziché un atto di ostruzionismo, che è la differenza tra un diritto che esiste sulla carta e uno che qualcuno può effettivamente esercitare.

L'Hypercare, e perché il team di progetto non deve andarsene al go-live

Il secondo meccanismo allinea gli incentivi dopo la firma, anziché prima.

Un progetto che effettua l'handover al momento del go-live e si scioglie non ha alcun interesse per ciò che accadrà in seguito. Ogni difetto rimandato, ogni attività non documentata e ogni runbook mancante diventa un problema di qualcun altro il lunedì successivo.

Un periodo di hypercare cambia questo scenario. Per un periodo definito dopo l'handover, in genere da trenta a novanta giorni a seconda della scala del progetto, il team di progetto rimane responsabile. Le persone designate rimangono disponibili, il budget rimane aperto e i difetti che emergono in quella finestra temporale vengono risolti dal progetto anziché essere gestiti come nuove attività.

Il valore non sta principalmente nel supporto. Sta nell'effetto che produce sul comportamento durante la consegna. Un team che sa che risponderà al telefono nel primo mese documenta in modo diverso nel dodicesimo mese.

Tre dettagli lo fanno funzionare. Indica i nomi delle persone, perché "il team di progetto" si disperde. Mantieni esplicitamente aperto il budget, poiché un impegno di hypercare senza fondi è una promessa che nessuno può mantenere. E definisci cosa copre l'hypercare, ovvero difetti e lacune di conoscenza, a differenza delle nuove richieste, altrimenti il periodo diventa una finestra di miglioramenti gratuiti e il progetto non si chiuderà mai.

Modello gratuito di checklist di handover del progetto: voci da copiare

Copia da qui. I due blocchi contrassegnati da un asterisco sono le aggiunte.

Intestazione. Progetto, output consegnato, team che consegna, team ricevente, data prevista per l'handover, data di fine hypercare.

Criteri di accettazione, scritti dal ricevente in fase di pianificazione. Le dieci o dodici condizioni, ciascuna con uno strumento di verifica e un sì o un no. Questa sezione viene compilata dal team ricevente, non dal team di progetto.

Documentazione. Descrizione as-built verificata rispetto alla realtà. Runbook per ogni attività programmata. Limitazioni note e soluzioni temporanee attuali. Record dell'architettura o degli asset. Il nostro modello di documentazione di progetto descrive quali di questi vale la pena conservare.

Prontezza operativa. Monitoraggio attivo e testato. Avvisi indirizzati a una destinazione reale. Backup e ripristino testati, non solo configurati. Capacità massima dichiarata. Percorso di escalation definito con copertura fuori orario.

Difetti e debito. Elenco dei difetti aperti per gravità, con responsabili e date previste. Tutto ciò che è stato deliberatamente rimandato, registrato come decisione anziché come omissione.

Formazione e persone. Chi è stato formato, su cosa, con prove. Responsabile designato sul lato ricevente. Prontezza dell'help desk di supporto.

Accesso e amministrazione. Account trasferiti a profili basati sui ruoli anziché nominativi. Licenze e contratti assegnati. Accordi di supporto del fornitore testati.

Commerciale. Costi correnti confermati e previsti a budget. Termini di garanzia e scadenza. Contratti trasferiti dove necessario.

Termini di hypercare. Durata, persone designate, cosa è coperto e cosa no, e modalità di conclusione.

Approvazione (Sign-off). Parte che consegna, parte ricevente e sponsor. Con data ed eventuali condizioni allegate.

Copia fino a qui.

L'azienda il cui responsabile operativo ha firmato sotto pressione

Bramfield Group, un'azienda di servizi professionali di circa duemila duecento persone, ha sostituito il proprio sistema di gestione dello studio. Sedici mesi, circa quattro milioni e seicentomila sterline, consegnato in tempo.

Il passaggio di consegne alle operazioni IT è avvenuto al momento del go-live. La checklist conteneva trentaquattro voci, tutte completate dal team di progetto, ed è stata firmata dal responsabile delle operazioni IT il giorno della chiusura del progetto.

Ciò che le operazioni hanno effettivamente ricevuto era meno incoraggiante di quanto i trentaquattro segni di spunta lasciassero intendere. Undici documenti, di cui quattro descrivevano il sistema come progettato e non come effettivamente realizzato (as-built). Nessun runbook per nessuna delle sei attività notturne programmate. Quarantasette difetti aperti, nove dei quali classificati come gravi. Nessun accordo per la reperibilità, poiché il contratto di supporto del fornitore copriva solo l'orario d'ufficio. E nessuna formazione per il service desk, perché si era dato per scontato che l'avrebbe fornita il fornitore.

Il responsabile operativo ha firmato comunque. Interpellato in seguito, ha dichiarato che il progetto si sarebbe chiuso quel venerdì, lo sponsor era presente e un rifiuto avrebbe significato essere la persona che bloccava un progetto da quattro milioni e mezzo di sterline all'ultimo ostacolo.

Nei sei mesi successivi si sono verificati tre malfunzionamenti delle attività notturne che hanno richiesto l'escalation a un collaboratore esterno che aveva già lasciato l'azienda. La risoluzione al primo contatto del service desk sul nuovo sistema si è attestata al ventidue percento contro il settantuno percento del sistema sostituito. I nove difetti ad alta gravità hanno richiesto una media di quattordici settimane per essere risolti, perché il budget del progetto era chiuso e ognuno richiedeva un proprio caso aziendale specifico. Le operazioni IT hanno registrato trecentoquaranta ore di straordinario aggiuntivo, pari a circa diciannovemila sterline.

Il costo totale non pianificato nei sei mesi, inclusa la risoluzione dei difetti, è stato di quasi duecentoquarantamila sterline.

Il programma successivo ha gestito due cose in modo diverso.

Le operazioni IT hanno scritto dodici criteri di accettazione in fase di pianificazione, tra cui runbook per ogni attività programmata, zero difetti ad alta gravità all'handover, un accordo di reperibilità contrattualizzato, un service desk formato con una percentuale di successo documentata e documentazione as-built verificata dalle operazioni eseguendo tre attività reali utilizzando solo la documentazione. Sia lo sponsor che il responsabile operativo hanno firmato quell'elenco prima dell'inizio della consegna.

Inoltre, è stato concordato un periodo di hypercare di novanta giorni, con due membri del personale di progetto dedicati e il budget mantenuto aperto.

Il primo tentativo di handover è fallito su due criteri ed è stato risolto in tre settimane. La risoluzione al primo contatto del service desk è stata del sessantaquattro percento nel primo mese. Non ci sono state escalation all'ex personale di progetto. L'hypercare ha consumato circa centocinquanta ore del budget riservato.

Componenti generali di una checklist di handover del progetto

La prima riga è quella che predetermina la maggior parte delle altre. Se i criteri di accettazione provengono dal ricevente in fase di pianificazione, le restanti righe tendono ad essere soddisfatte, poiché il progetto ha avuto dodici mesi per pianificarle.

I passaggi per un handover di progetto di successo

In fase di pianificazione. Il team ricevente scrive i criteri di accettazione. Sia lo sponsor che il ricevente firmano. La data di handover e i termini di hypercare vengono inseriti nel piano, e il nostro modello di piano di progetto IT mostra come rendere reali quelle date anziché semplici aspirazioni.

Durante la consegna. La documentazione e i runbook vengono accumulati anziché essere prodotti alla fine. Il responsabile designato del team ricevente partecipa alle revisioni del design per tutto ciò che influisce sull'operatività.

Da quattro a sei settimane prima dell'handover. Una simulazione rispetto ai criteri di accettazione, in modo da individuare i fallimenti mentre c'è ancora tempo. Questo è il passaggio che trasforma un rifiuto in una risoluzione.

All'handover. Verifica formale rispetto ai criteri, con il ricevente che esegue la verifica anziché limitarsi a leggere un report. Approvazione con registrazione di eventuali condizioni.

Durante l'hypercare. Difetti e lacune conoscitive gestiti dal progetto. Un controllo settimanale tra le parti.

Al termine dell'hypercare. Una breve revisione, la chiusura del progetto e il trasferimento dei restanti elementi nel normale lavoro del team ricevente con i rispettivi responsabili.

Sfide comuni negli handover di progetto e le soluzioni

Il ricevente non può rifiutare. Criteri di accettazione concordati in fase di pianificazione, firmati dallo sponsor, che rappresenta l'argomento centrale di questa pagina.

La documentazione descrive il progetto teorico anziché quello effettivo (build). Verificala facendo eseguire al team operativo compiti reali basandosi su di essa, che è l'unico test davvero efficace.

Runbook mancanti per le attività automatizzate. Questi sono invisibili durante la consegna perché funzionano, e sono la causa più comune di un'escalation alle tre del mattino verso qualcuno che ha lasciato l'azienda.

I difetti rimandati diventano permanenti. Elencali con responsabili e date prima dell'approvazione finale, e considera qualsiasi elemento senza data come un mancato rispetto del criterio.

Nessun accordo di reperibilità. Economico da concordare in fase di approvvigionamento e costoso da aggiungere in seguito, motivo per cui appartiene ai criteri di accettazione e al contratto.

Accesso posseduto da singoli individui. Trasferisci ad account basati sui ruoli prima dell'handover, non dopo che qualcuno se n'è andato.

Il team di progetto si scioglie al go-live. Hypercare, con persone designate e budget riservato.

Nessuno possiede il risultato finale. Nomina il responsabile ricevente in fase di pianificazione, non alla chiusura, e coinvolgilo nelle revisioni del design.

Handover nell'edilizia e nell'IT, e dove differiscono

La struttura è comune, ma due cose differiscono sostanzialmente.

L'handover nell'edilizia e nelle infrastrutture presenta un livello legale e contrattuale. Completamento pratico, periodo di responsabilità per i difetti, trattenute, approvazioni dei regolamenti edilizi e il fascicolo di salute e sicurezza richiesto dalle normative edilizie, che è un deliverable separato dalla documentazione operativa. Il manuale d'uso e manutenzione è l'elemento centrale dell'handover e merita una trattazione a sé, offerta dal nostro modello di manuale d'uso e manutenzione, che spiega anche perché di solito viene accettato anziché verificato.

L'handover IT e software non ha un equivalente legale nella maggior parte dei casi, il che significa che la disciplina deve derivare dai criteri di accettazione anziché da un contratto. I suoi elementi distintivi sono il monitoraggio, i test di ripristino, la reperibilità, le soglie di gravità dei difetti e il trasferimento degli accessi, e il suo rischio peculiare è che tutto sembri a posto fino al primo guasto fuori orario.

Laddove il cambiamento vada in produzione in una finestra temporale con opzione di ripristino (rollback), il nostro modello di metodo di procedura copre il cutover vero e proprio, che è un documento diverso dall'handover.

Handover di progetto o handover personale quando si lascia un lavoro?

Due documenti, entrambi chiamati handover (passaggio di consegne), con problemi diversi.

Un handover di progetto trasferisce un output da un team di consegna a un team operativo. Il problema riguarda l'accettazione, l'operatività e i costi correnti, ed è in gran parte una questione commerciale e organizzativa.

Un handover personale trasferisce un ruolo da un individuo al suo successore. Il problema è la conoscenza tacita, ed è in gran parte una questione legata a ciò che la persona uscente non sa di sapere. Il nostro modello SOP di trasferimento delle conoscenze lo copre, spiegando anche perché chiedere a qualcuno di scrivere ciò che sa produce la descrizione del suo lavoro piuttosto che la sua conoscenza reale.

Se stai lasciando un lavoro, hai bisogno del secondo. Una checklist di handover di progetto adattata per uso personale produce un elenco di sistemi e password, che è la parte facile, tralasciando tutto ciò che conta davvero.

Posso ottenere un modello di checklist di handover del progetto in Excel?

Excel è la scelta giusta per un motivo specifico: i criteri di accettazione hanno bisogno di una colonna di verifica e di uno stato, e l'elenco dei difetti ha bisogno di gravità, responsabile e data. Entrambe sono tabelle che vengono filtrate e riviste anziché lette come testo continuo.

Costruiscilo su due fogli. I criteri di accettazione con colonne per il criterio, la modalità di verifica, chi esegue la verifica, lo stato e la data. E il registro dei difetti con gravità, responsabile, data target e se è accettato come rimandato.

Usa Word o Google Docs per l'accordo di contorno: termini di hypercare, blocco delle firme e qualsiasi condizione allegata all'accettazione. Questa è la parte che viene firmata.

Usa il formato PDF per l'handover firmato, archiviato con il record del progetto. Dato che l'handover è il documento a cui si torna quando qualcosa va storto diciotto mesi dopo, congelare e datare la versione firmata è qui più importante che per la maggior parte dei documenti.

Come produrre runbook che il team ricevente accetterà

I runbook sono l'elemento che più spesso manca all'handover e quello che causa i danni maggiori, perché un'attività programmata che è stata eseguita senza problemi per sei mesi di test non avvisa del fatto che nessuno sa come ripristinarla in caso di guasto.

Mancano per un motivo banale. Scrivere un runbook significa che qualcuno deve documentare in dettaglio un processo configurato mesi prima, proprio nel momento del progetto in cui c'è meno tempo e meno voglia.

L'IA di Trupeer elimina la maggior parte di questo costo. Chiunque abbia creato o gestisca l'attività può registrarsi mentre la esegue, includendo il percorso di errore e di ripristino; l'output sarà un runbook scritto con i passaggi e le schermate già acquisiti. Sei attività notturne diventano il lavoro di un pomeriggio anziché un compito che viene spuntato senza essere fatto davvero.

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

Questo rende anche la documentazione verificabile, che è ciò che richiedono i criteri di accettazione: il team operativo può eseguire l'attività partendo dal runbook anziché leggerlo sperando che funzioni. Il creatore di SOP copre le procedure, il nostro modello di SOP IT aiuta a decidere quali vale la pena mantenere, e il materiale risiede nella tua knowledge base con un branding coerente. Le istruzioni di configurazione si trovano nella guida alla configurazione dei modelli di documento.

Domande frequenti

Esiste un modello gratuito di checklist di handover del progetto in Excel?

Excel è il formato corretto, con i criteri di accettazione e il registro dei difetti come fogli separati, entrambi dotati di colonne per la verifica e lo stato. Non ci sono download protetti o moduli da compilare. La modifica utile da apportare a qualsiasi strumento tu stia già utilizzando consiste nel far compilare al team ricevente il foglio dei criteri in fase di pianificazione, anziché farlo compilare al team di progetto al momento della chiusura.

Esiste un modello gratuito di checklist di handover del progetto in Word?

Word è adatto per l'accordo formale intorno alla checklist: termini di hypercare, firme e condizioni associate all'accettazione. Mantieni le tabelle dei criteri e dei difetti in un foglio di calcolo, poiché entrambe necessitano di filtri e nessuna delle due va letta come prosa.

Dove posso trovare un documento di handover di progetto in PDF?

Diverse università ed enti pubblici pubblicano i propri documenti, che meritano di essere letti per l'elenco delle voci. Leggili per i contenuti piuttosto che per la struttura, e nota se qualcuno di essi presenta criteri di accettazione redatti dalla parte ricevente; la maggior parte non li ha, ed è proprio questa la differenza di cui parla questa pagina.

Esiste un modello di handover per quando si lascia un lavoro?

Si tratta di un handover personale piuttosto che di un handover di progetto, e richiede un approccio del tutto diverso, poiché la parte difficile è la conoscenza di cui non ti rendi conto di disporre. Il nostro modello SOP di trasferimento delle conoscenze lo copre, includendo un metodo che fa emergere ciò che un semplice elenco non farebbe.

Chi firma l'approvazione di un handover di progetto?

Tre parti: il team che consegna, il team ricevente e lo sponsor. La firma dello sponsor è fondamentale perché rende legittimo e non ostruzionistico il rifiuto del ricevente, ed è questo il motivo per cui i criteri dovrebbero essere firmati sia in fase di pianificazione che di handover.

Quanto dovrebbe durare un periodo di hypercare?

Trenta giorni per qualcosa di piccolo, da sessanta a novanta per un sistema sostanzioso, e più a lungo laddove debba passare un intero ciclo aziendale prima che emergano problemi, come la chiusura del primo mese o del primo anno. Ciò che conta più della durata è che dietro vi siano persone designate e un budget riservato.

Cosa succede se il team ricevente rifiuta l'handover?

Se i criteri sono stati concordati in fase di pianificazione, la risposta è semplice: il progetto risolve i criteri non soddisfatti e si ripresenta. Nell'esempio precedente, il primo tentativo è fallito su due criteri ed è stato risolto in tre settimane. Un rifiuto senza criteri stabiliti in precedenza si trasforma invece in una trattativa, motivo per cui i criteri contano più del diritto di rifiuto stesso.

Qual è la differenza tra handover e chiusura?

L'handover trasferisce l'output a chi lo gestirà. La chiusura termina il progetto: costi finali, contratti, rilascio delle risorse, archiviazione dei record. Spesso vengono eseguiti lo stesso giorno, il che è un errore, perché la chiusura elimina il budget e le persone da cui dipende l'hypercare. Effettua l'handover, esegui l'hypercare e poi chiudi.