Un buon passaggio di consegne del progetto protegge tutto ciò che hai costruito. Con Trupeer, puoi risparmiare ore sulla documentazione di handover partendo da un modello di passaggio di consegne gratuito, personalizzandolo con le tue linee guida del brand e trasformando i passaggi di consegne in video-guide dettagliate che inseriscono rapidamente il team ricevente.

Che cos'è un modello di passaggio di consegne di un progetto e cosa contiene?

Un documento di passaggio di consegne (handover) del progetto è ciò che il team che ha costruito qualcosa fornisce al team che lo gestirà. Indica cos'è l'elemento, chi ne è il proprietario ora, in quale stato si trova, cosa rimane in sospeso e chi contattare.

Un modello ti fornisce le sezioni. La maggior parte delle versioni offre all'incirca lo stesso insieme: panoramica, stato, deliverable, contatti, attività in sospeso, documentazione, note e approvazione.

Questo insieme è ragionevole. Ciò che quasi tutti i passaggi di consegne sbagliano non sono le sezioni, ma il volume, e in particolare la mancata separazione di due tipi di contenuti che si comportano in modo completamente diverso.

Se stai cercando le condizioni che devono essere soddisfatte prima che possa avvenire un passaggio di consegne e chi ha il diritto di rifiutarlo, questo è un documento diverso e il nostro modello di checklist per il passaggio di consegne del progetto lo copre. Questa pagina tratta ciò che effettivamente viene consegnato.

Un documento di passaggio di consegne è scritto per diventare obsoleto

Ecco la proprietà che distingue un documento di passaggio di consegne da ogni altro documento prodotto da un progetto.

Il suo compito è far sì che il team ricevente passi dal non sapere nulla al gestire le attività con competenza. Una volta accaduto questo, di solito entro poche settimane, il documento ha esaurito il suo compito e non verrà più aperto. La comprensione stessa del team, i loro runbook e le loro note personali lo sostituiranno.

Questo non è un fallimento. È l'immagine del successo.

L'errore è scriverlo come riferimento permanente, perché un riferimento permanente deve essere completo, e la completezza è esattamente ciò che ne impedisce la lettura nella prima settimana, quando invece è fondamentale. Un pacchetto di centottantasette pagine non viene letto da quattro persone nella loro prima quindicina di giorni mentre tengono anche in funzione un sistema. Viene archiviato.

Pertanto, il documento di passaggio delle consegne dovrebbe essere ottimizzato per le prime quarantotto ore e le prime tre settimane, e tutto ciò che è permanente dovrebbe risiedere altrove ed essere collegato tramite link.

Come personalizzare questo modello in Trupeer

Passaggio 1: Apri la sezione Modelli

Vai alla sezione Modelli dalla navigazione principale.

Passaggio 2: Seleziona e apri un modello

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

Passaggio 3: Espandi la vista del modello

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

Passaggio 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

Passaggio 5: Salva il tuo modello personalizzato

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

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 passaggio di consegne del progetto puoi:

• Risparmiare ore sui passaggi di consegne: Salta la pagina bianca con una struttura creata appositamente per le transizioni.

• Coprire ogni elemento: Le sezioni integrate assicurano che nessun deliverable, documento o approvazione venga dimenticato.

• Rimanere in linea con il brand: Applica il tuo logo, font e colori utilizzando il brand kit di Trupeer.

• Inserire i team riceventi più velocemente: Associa al passaggio di consegne una video-guida dettagliata.

• Standardizzare tra i vari progetti: Utilizza lo stesso modello per ogni transizione di progetto.

• Raggiungere team globali: Traduci la documentazione di passaggio delle consegne in oltre 65 lingue con un solo clic.

I contenuti di bootstrap e i contenuti di riferimento sono cose diverse

Suddividi ogni potenziale elemento in una di queste due categorie e il pacchetto si ristrutturerà da solo.

Contenuto di bootstrap. Necessario immediatamente, inutile in seguito. Cos'è questo elemento in due frasi. Chi ne è il proprietario ora. Cosa è fragile. Chi chiamare per cosa. Cosa è in sospeso. Cosa non deve essere modificato senza chiedere. Dove si trova tutto il resto.

Contenuto di riferimento. Necessario occasionalmente, necessario per anni. Architettura. Configurazione as-built. Runbook. Risultati dei test. Tracciabilità dei requisiti. Guide utente. Contratti.

Il contenuto di bootstrap appartiene al documento di passaggio di consegne, che dovrebbe essere di due pagine.

Il contenuto di riferimento appartiene alla documentazione operativa, dove il team ricevente conserva già le informazioni e le cercherà, con link che rimandano dal documento di passaggio di consegne. Non appartiene al pacchetto, perché raggrupparlo è ciò che rende il pacchetto illeggibile e fa sì che venga archiviato come un blocco unico anziché essere assorbito nel sistema del team.

Il nostro modello di documentazione di progetto copre quali documenti di riferimento vale la pena conservare, e il nostro modello di documentazione IT copre dove dovrebbe risiedere in seguito il materiale as-built.

Cosa si rompe per primo: il campo che nessun modello ha

La cosa di maggior valore in assoluto che un team uscente può scrivere è un elenco di ciò che è fragile, e nessun modello di passaggio consegne lo richiede.

Il team di progetto lo sa. Sanno quale integrazione è tenuta insieme da un riprovatatore pianificato, quale configurazione dipende dal comportamento coerente di un sistema a monte, quale processo fallisce se il file arriva in ritardo e di quale parte della build non sono mai stati del tutto soddisfatti. Questa conoscenza è completa il giorno del passaggio di consegne e svanisce entro un mese.

Scompare perché nessuno la richiede. I risultati dei test registrano ciò che è andato a buon fine. I registri dei rischi registrano ciò di cui le persone si preoccupavano in precedenza. Nessuno dei due cattura la valutazione privata dell'ingegnere su quali siano i punti deboli.

Chiedi cinque elementi. Cosa si romperà prima, perché, come si presenta quando succede e cosa fare. Scritto dalle persone che lo hanno costruito piuttosto che dal project manager, perché il project manager non lo sa.

Due cose fanno funzionare questo processo nella pratica. Rendilo esplicitamente privo di colpe: questa non è un'ammissione di un lavoro scadente, è la cosa più utile che possano consegnare, e inquadrarlo come un elenco di difetti garantisce una sezione vuota. E chiedilo due settimane prima del passaggio di consegne piuttosto che il giorno stesso, quando la risposta sarà "nulla che io sappia".

Il documento di due pagine per la prima settimana

Copia da qui. Due facciate, e resisti all'espansione.

Cos'è questo. Due frasi che descrivono l'elemento e cosa fa per il business.

Chi lo possiede ora. Il proprietario ricevente per nome, il livello di escalation superiore e la data in cui è stata trasferita la proprietà.

Cosa si rompe per primo. Cinque elementi, come sopra, con sintomo e prima azione.

Chi chiamare per cosa. Un breve elenco di instradamento. Il team interno, l'integratore di sistemi, la linea di supporto di ciascun fornitore con riferimento al contratto e orari, e le singole persone del progetto che rimangono disponibili durante la fase di assistenza post-rilascio (hypercare). Gli elenchi di contatti che indicano solo l'integratore sono un'omissione ricorrente e costosa.

Cosa è in sospeso. Difetti aperti per gravità con proprietari e date, elementi differiti registrati come decisioni e qualsiasi cosa il progetto abbia concordato di fare dopo il passaggio di consegne.

Cosa non cambiare senza chiedere. Configurazione, processi o impostazioni in cui una modifica ha conseguenze non ovvie. Breve, specifico e una delle poche sezioni realmente preventive disponibili.

Dove si trova tutto il resto. Link al materiale di riferimento, per nome, nella posizione che il team ricevente già utilizza.

Copia fino a qui. Se supera le due facciate, qualcosa al suo interno è un contenuto di riferimento.

Modello gratuito di passaggio consegne del progetto: la struttura da copiare

Il passaggio di consegne completo consiste nel documento di due pagine di cui sopra più un insieme definito di materiale referenziato. Il pacchetto è l'unione dei due, non un unico blocco.

Il documento di due pagine della prima settimana, come sopra.

Materiale di riferimento referenziato, ciascuno esistente nella sua sede permanente anziché nel pacchetto:

Descrizione as-built, verificata da qualcuno che esegue compiti reali a partire da essa. Runbook per ogni attività programmata, automatizzata o ricorrente. Record di architettura o di asset. Limitazioni note e soluzioni alternative attuali. Record di accesso e di account, trasferiti ad account basati su ruoli. Contratti, licenze e accordi di supporto con date di rinnovo. Requisiti finali ed evidenza di accettazione, conservati laddove richiesto da uno standard. Configurazione di monitoraggio e allerta.

Registro del passaggio di consegne. Data, parti coinvolte, cosa è stato trasferito, condizioni associate all'accettazione, termini di hypercare e firme. Una pagina, archiviata.

Due regole evitano che questo si riduca nuovamente a un unico blocco. Ogni documento referenziato deve esistere nel sistema del team ricevente prima del passaggio di consegne, non essere promesso. E il documento di due pagine deve essere leggibile senza aprirne nessuno, che è la prova del fatto che il contenuto di bootstrap sia realmente separato.

L'emittente televisiva che ha letto 22 di 187 pagine

Sedgewick Media, un editore ed emittente radiotelevisiva di circa ottocento persone, ha preso in consegna un nuovo sistema di gestione delle risorse digitali.

Il pacchetto arrivava a centottantasette pagine suddivise in quattordici documenti, più una presentazione di quarantuno diapositive. Panoramica del progetto, otto pagine. Architettura, ventidue. Tracciabilità dei requisiti, trentaquattro. Risultati dei test, quarantasei. Configurazione as-built, trentuno. Guide utente, ventotto. Elenco contatti, due. Elementi in sospeso, tre. Approvazione, una.

Il team ricevente era composto da quattro persone nelle operazioni digitali.

Nella prima settimana, un processo di caricamento (ingest) è fallito. Non c'era un runbook. Lo hanno risolto leggendo la configurazione as-built per circa tre ore.

Nella seconda settimana, un'eliminazione pianificata ha rimosso risorse che avrebbero dovuto essere conservate. Il team di progetto sapeva che questo elemento era fragile: la regola di conservazione dipendeva da un campo di metadati popolato da un sistema a monte che lo popolava in modo incoerente. Quel fatto appariva a pagina centodiciotto, all'interno del risultato di un test, descritto come comportamento noto. Sessantuno risorse hanno dovuto essere recuperate dall'archivio, con un costo di circa quattordicimila sterline in termini di tempo del personale e tariffe dei fornitori.

Nella terza settimana hanno chiamato due volte il fornitore sbagliato, perché l'elenco dei contatti indicava l'integratore di sistemi e non la linea di supporto del fornitore di gestione delle risorse.

Interrogato successivamente su cosa sarebbe stato d'aiuto, la risposta del team ricevente è stata di due pagine: cosa si rompe, chi chiamare, cosa è in sospeso e cosa non toccare.

Delle centottantasette pagine, ne avevano lette ventidue nel primo mese.

Il passaggio di consegne successivo, un sistema di gestione dei diritti, ha utilizzato un documento di due pagine per la prima settimana e novantaquattro pagine di materiale di riferimento conservato nella documentazione del team operativo e collegato tramite link anziché raggruppato. L'elenco "cosa si rompe prima" contava cinque elementi, scritti dai due ingegneri che lo avevano costruito.

Nel primo mese si è verificato un incidente. Era il secondo elemento di quell'elenco. È stato risolto in quaranta minuti.

Cosa dovrebbe includere un documento di passaggio delle consegne del progetto?

Il contenuto di bootstrap di cui sopra, e nello specifico cinque cose che la maggior parte dei pacchetti omette o seppellisce.

Cosa si rompe per primo, scritto dai costruttori.

Linee di supporto dei fornitori, non solo l'integratore, con riferimenti ai contratti e orari.

Cosa non cambiare, che è breve e preventivo.

Elementi in sospeso con proprietari e date, poiché un difetto aperto senza data diventa permanente.

Dove risiede il materiale di riferimento, nel sistema del team ricevente anziché nel pacchetto.

Cosa escludere dal documento, pur consegnandolo: diagrammi di architettura, risultati dei test, tracciabilità dei requisiti, guide utente ed esportazioni di configurazione. Tutti sono utili, ma nessuno appartiene a ciò che qualcuno legge nella prima settimana.

Come scrivere un documento di passaggio di consegne del progetto

Inizia due settimane prima del passaggio di consegne, non il giorno stesso. L'elenco di ciò che si rompe per primo ha bisogno di tempo per essere pensato e richiede il contributo degli ingegneri, che si staranno disperdendo.

Scrivi prima il documento di due pagine, prima di assemblare qualsiasi altra cosa. Procedere in questo ordine forza la separazione tra bootstrap e riferimento.

Chiedi ai costruttori individualmente piuttosto che in una riunione gli elementi fragili. In gruppo, con la presenza del project manager, la risposta sarà che va tutto bene.

Verifica che ogni link di riferimento funzioni e che il documento a cui punta si trovi nel sistema del team ricevente, non in quello del progetto. Un link che rimanda a un SharePoint di progetto che verrà archiviato è un link interrotto che causerà ritardi.

Fai in modo che qualcuno del team ricevente legga le due pagine e provi a eseguire un compito reale utilizzando solo ciò a cui il documento rimanda. Ogni domanda che pongono rappresenta una lacuna.

Quindi concorda i termini di hypercare e firma, cosa di cui si occupa il nostro modello di checklist per il passaggio delle consegne del progetto.

Varianti del rapporto di passaggio delle consegne e chi legge ciascuna

Il termine copre un'ampia famiglia e i documenti sono realmente diversi, il che è utile da sapere se si stanno cercando librerie di modelli.

Due di queste hanno un trattamento a parte. Il passaggio di consegne in edilizia si concentra sulla documentazione operativa, e il nostro modello di manuale d'uso e manutenzione copre il motivo per cui tale documento viene solitamente accettato anziché controllato. Il passaggio di consegne del ruolo riguarda la conoscenza piuttosto che gli elementi fisici, e il nostro modello di SOP per il trasferimento di conoscenza copre un metodo che fa emergere ciò che un elenco scritto non farebbe.

Best practice ed errori ricorrenti

Scrivi il documento, non il pacchetto. Due pagine più i link battono sempre un blocco unico.

Chiedi cosa è fragile, senza colpevolizzare, in anticipo. La sezione a più alto valore in assoluto e quella che nessuno richiede.

Nomina i fornitori, non solo l'integratore. Un costo ricorrente e facilmente evitabile nel primo mese.

Inserisci una data per ogni elemento in sospeso. Senza data significa permanente.

Inserisci il materiale di riferimento nel sistema del ricevente prima del passaggio consegne. Non in quello del progetto, che viene archiviato.

Non effettuare il passaggio di consegne e la chiusura nello stesso giorno. La chiusura rimuove il budget e le persone da cui dipende l'hypercare.

Fai testare il documento al ricevente anziché farglielo leggere. Leggere un pacchetto di passaggio consegne non ti dice nulla sul fatto che funzioni o meno.

Documento di passaggio consegne del progetto o checklist di passaggio consegne?

Sono le due metà dello stesso evento e sono documenti separati.

La checklist stabilisce se il passaggio di consegne può avvenire: i criteri di accettazione, chi li verifica e chi ha l'autorità di rifiutare. Viene completata prima e durante il passaggio di consegne, e il suo valore termina una volta accettato il passaggio. Il nostro modello di checklist per il passaggio di consegne del progetto se ne occupa, spiegando anche perché i criteri dovrebbero essere scritti dal team ricevente in fase di pianificazione anziché dal team di progetto in fase di chiusura.

Il documento di passaggio delle consegne è ciò che viene effettivamente trasferito: il contenuto di bootstrap di cui il team ricevente ha bisogno per operare. Il suo valore inizia quando il passaggio di consegne viene accettato.

La maggior parte delle organizzazioni dispone di una versione del primo elemento e di un blocco disordinato al posto del secondo. La checklist senza il documento produce un passaggio di consegne conforme a un team che non sa gestire l'oggetto. Il documento senza la checklist produce un buon briefing che nessuno aveva il diritto di rifiutare.

Posso ottenere un modello di passaggio consegne del progetto in Excel o Word?

Word o Google Docs per il documento di due pagine, poiché si tratta di testo discorsivo e viene letto piuttosto che ordinato. Limitati a due facciate ed esportalo come PDF per l'archivio.

Excel per i due elenchi che necessitano di colonne. Elementi in sospeso con gravità, proprietario e data target. E l'elenco dei contatti con sistema, fornitore, riferimento del contratto, orari e numero di telefono. Entrambi cambiano durante i primi mesi ed entrambi vengono consultati piuttosto che letti.

PDF per il registro del passaggio di consegne firmato e archiviato con il progetto. Poiché questo è il documento a cui si torna quando qualcosa va storto un anno dopo, congelarlo e datarlo è importante.

Ciò che non funziona è un singolo documento raggruppato contenente tutto, in qualsiasi formato. Questo è il fallimento descritto in tutta la pagina, e il formato non cambia le cose.

Come scrivere rapidamente l'elenco "cosa si rompe per primo"

Le due sezioni con il valore più alto in questo caso, gli elementi fragili e i runbook a cui puntano, sono le due con maggiore probabilità di mancare, e per lo stesso motivo. Entrambe richiedono che qualcuno descriva in dettaglio qualcosa costruito mesi prima, nella settimana in cui il progetto ha meno tempo a disposizione.

L'IA di Trupeer elimina la maggior parte di quel costo. L'ingegnere che ha creato l'attività si registra mentre la esegue, descrivendo anche come si presenta quando fallisce e cosa fare al riguardo, e l'output è un runbook scritto con i passaggi e le schermate già catturati. L'elemento fragile e la sua prima azione emergono dalla stessa registrazione.

Registralo. Brandizzalo. Traducilo. Rendilo un Trupeer.

Ciò rende anche il passaggio di consegne verificabile anziché semplicemente asserito, poiché il team ricevente può eseguire l'attività basandosi sulla guida derivata dalla registrazione invece di leggere una descrizione sperando di capire. Lo strumento di creazione di SOP copre le procedure, il nostro modello di SOP IT copre quali vale la pena mantenere in seguito, e il materiale risiede nella tua knowledge base con un branding coerente, che è dove dovrebbero puntare i link di riferimento. Le istruzioni di configurazione si trovano nella guida di configurazione del modello di documento.

Domande Frequenti

Esiste un modello gratuito di passaggio consegne del progetto in Excel?

Excel è adatto ai due elenchi piuttosto che al documento: elementi in sospeso con gravità, proprietario e data, e l'elenco dei contatti. Non c'è alcun download protetto né modulo. Conserva la parte descrittiva di due pagine in un documento, poiché viene letta una volta in fretta e le celle sono il contenitore sbagliato per questo scopo.

Esiste un modello gratuito di passaggio consegne del progetto in Word?

La struttura di due pagine sopra descritta si incolla direttamente in Word o Google Docs. La disciplina sta nella lunghezza piuttosto che nel formato: se supera le due facciate, parte del contenuto è di riferimento e appartiene alla documentazione del team ricevente tramite un link.

Esiste un modello gratuito di passaggio consegne del progetto in PDF?

Esporta il documento di due pagine e il registro del passaggio di consegne firmato in PDF per l'archivio. Non includere il materiale di riferimento nello stesso PDF, che è esattamente il modello che produce un documento che nessuno legge.

Dove posso trovare un documento di passaggio delle consegne del progetto in PDF?

Diverse università ed enti pubblici pubblicano i propri e sono utili per l'elenco degli elementi. Leggili notando ciò che manca: quasi nessuno ha una sezione dedicata agli elementi fragili e quasi tutti inseriscono il materiale di riferimento nel pacchetto, che sono le due cose contro cui questa pagina si batte.

Quanto deve essere lungo un documento di passaggio consegne di un progetto?

Due facciate per il documento che le persone leggono, più tutto il materiale di riferimento di cui l'elemento ha realmente bisogno, conservato separatamente. L'esempio pratico sopra riportato ne è la prova: un pacchetto di centottantasette pagine di cui solo ventidue sono state lette nel primo mese.

Chi dovrebbe scrivere il documento di passaggio delle consegne del progetto?

Il project manager scrive il documento di due pagine e gli ingegneri che hanno costruito l'elemento scrivono i punti fragili. Questa suddivisione è importante, perché il project manager non sa cosa sia fragile e gli ingegneri non scriveranno l'elenco dei contatti.

Che cos'è un rapporto di passaggio delle consegne (handover report)?

Una famiglia più ampia rispetto al passaggio consegne di progetto, che copre passaggi di consegne dei turni, passaggi di consegne del ruolo, trasferimenti di asset e accettazione da parte del cliente. Le librerie di modelli elencano decine di varianti, comprese quelle specifiche per settori come l'infermieristica, la logistica e la gestione di impianti. La tabella sopra riportata definisce chi consegna a chi in ciascun caso, poiché il contenuto critico differisce notevolmente.

Quando dovrebbe essere scritto il documento di passaggio consegne?

Inizia due settimane prima del passaggio di consegne. Gli elementi fragili richiedono tempo per essere pensati e richiedono la presenza di persone che stanno per disperdersi. Se scritta il giorno stesso, la sezione rimarrà vuota, che è il modo più comune in cui si perde la parte di maggior valore di un passaggio di consegne.