Premortem di progetto: agenda della riunione ed esempio compilato

Un premortem è una riunione in cui il gruppo immagina che un progetto sia già fallito e cerca di spiegare cosa abbia prodotto il risultato. Usa l'inversione: partire dal fallimento per indagare le condizioni che potrebbero produrlo prima di eseguire il piano.

Un'azienda immaginaria sta cambiando piattaforma di assistenza. La dimostrazione ha funzionato, la formazione è avvenuta e la data è stata comunicata. Resta da verificare se le richieste aperte conserveranno cronologia, responsabile e azione successiva dopo il cambiamento.

Scegli un fallimento che si possa esaminare

L'AHRQ descrive il premortem come risorsa per anticipare ostacoli all'implementazione. Le cause proposte sono ipotesi da verificare.

Definisci il risultato indesiderato che stai esaminando. Nel cambio di piattaforma, potrebbe essere perdere la continuità delle richieste aperte. Dire soltanto che il cambiamento è stato un disastro lascia spazio a timori relativi a problemi diversi.

Concorda anche il periodo. Un'interruzione il primo giorno richiede domande diverse da una difficoltà che emerge dopo mesi d'uso. Se contano entrambe, tieni registrazioni separate per non confondere cause e misure.

Agenda suggerita per una riunione di 45 minuti

Invita chi assiste i clienti, configura il sistema e decide sulla transizione. Invia prima il piano e il criterio di fallimento. Questa distribuzione del tempo è una proposta di facilitazione per il caso, non una durata richiesta dalla tecnica.

Se emerge che nessuno sa descrivere il percorso di una richiesta, interrompi la selezione dei rischi e ricostruisci quel percorso. Votare su un elenco poco compreso organizza soltanto il dubbio.

Scrivere individualmente prima della discussione può dare spazio a un'osservazione che non emergerebbe dopo aver ascoltato la direzione. Perché funzioni, chi conduce deve accogliere dubbi senza pretendere che il partecipante dimostri subito l'intera ipotesi.

Sostituisci timori generici con meccanismi

“Il gruppo opporrà resistenza” attribuisce una disposizione generale alle persone. Una formulazione più utile sarebbe: chi riceve una richiesta non saprà in quale sistema aggiornarla perché le regole di transizione non sono state definite.

Chiedi quale condizione colleghi la causa proposta al fallimento. Esiste un limite dello strumento? Manca una decisione? Il problema dipende da un caso eccezionale o può verificarsi nell'uso normale? Cerca registrazioni, dimostrazioni e persone che aiutino a verificare la relazione.

Un lungo elenco di rischi non informa sulla loro frequenza o gravità. Distingui evidenza e possibilità e annota le incertezze. La tecnica può rendere un timore più visibile senza renderlo più probabile.

Scegli verifiche che cambino il piano

L'azienda potrebbe migrare un insieme di richieste aperte e verificare cronologia, responsabile e azione successiva. Potrebbe anche simulare un messaggio ricevuto durante la transizione e seguirne il percorso fino all'assistenza.

Ogni verifica richiede un responsabile e una conseguenza per il piano. Se la cronologia essenziale non viene conservata, potrebbe essere necessario rinviare il cambiamento o mantenere una consultazione sicura del vecchio sistema. L'esito dipende da ciò che emerge.

Confronta il costo di queste misure con le alternative. Mantenere due sistemi può preservare l'accesso e generare aggiornamenti discordanti. Come nella scelta degli strumenti, segui l'intero processo e l'impegno necessario per uscire da ogni opzione.

Scheda compilata per il cambio di piattaforma

L'ultimo rischio distingue la presenza dei dati dalla capacità di continuare il lavoro. Un file esportato può esistere e richiedere ancora una ricerca manuale che l'operatività non riesce a sostenere.

Per stabilire le priorità, parti dai guasti che impediscono di gestire una richiesta essenziale e non hanno un recupero dimostrato. Esamina poi conseguenze rilevanti verificabili prima del cambiamento con poco impegno. I disagi reversibili possono restare sotto osservazione, con un responsabile definito. Quest'ordine è un criterio operativo dell'esempio, non una scala di probabilità validata.

Quando copi la scheda per il tuo progetto, conserva quattro campi: fallimento osservabile; verifica mancante; responsabile e scadenza; decisione se la prova fallisce. La scheda d'indagine può raccogliere le osservazioni e separare fatti e interpretazioni.

Registra ciò che l'esercizio non ha risolto

Un premortem dipende dalle conoscenze e dalla disponibilità dei partecipanti. Può trascurare problemi, ripetere convinzioni del gruppo o concentrare l'attenzione su una storia memorabile. Invita qualcuno a cercare una spiegazione diversa dello stesso risultato.

Dopo aver corretto un punto debole, esamina ciò che la correzione ha aggiunto. Un'approvazione ulteriore può ridurre un errore e creare ritardo. Anche il piano rivisto richiede responsabili, limiti e condizioni di monitoraggio.

Alla fine della riunione, ogni elemento che blocca la transizione deve avere una verifica programmata. Se la risposta non arriva prima del cambiamento, qualcuno dovrà decidere esplicitamente se rinviare o accettare l'esposizione residua. Un elenco di timori senza questa conseguenza non offre un criterio per autorizzare il passaggio.