Descrivi un progetto e Joy conduce un pre-mortem: immagina che il lancio sia già fallito, lavora a ritroso per far emergere le probabili modalità di fallimento, le classifica per probabilità e impatto e ti fornisce un segnale d'allarme precoce e una soluzione concreta per ciascuna, così colmi le lacune prima di costruire.
Conduci un pre-mortem sul nostro [rollout della nuova formazione compliance in lancio nel Q3] e segnala i rischi maggiori.
Un esempio illustrativo: il tuo risultato dipenderà dalle tue fonti, dai tuoi dati e dalle tue richieste.
Ho assunto che il rollout fosse già fallito e ho lavorato a ritroso, usando il tuo piano di progetto e la retro del rollout dell'anno scorso nel Knowledge Center per ancorare ogni rischio. Ecco la lettura classificata, con i due che spiccano già segnalati.
Ho immaginato che sia la fine del Q3 e che il rollout sia andato male, poi ho lavorato a ritroso a partire da quel fallimento usando il tuo piano di progetto, la retro del rollout dell'anno scorso e la mappa degli stakeholder nel Knowledge Center. Sei modalità di fallimento spiegano la maggior parte dei modi in cui potrebbe andare storto. Ho valutato ciascuna come probabilità × impatto su una scala da 1 a 5, quindi il punteggio di rischio va da 1 a 25. Due sono ben davanti agli altri: basso completamento prima della scadenza (20) e contenuto obsoleto rispetto alla normativa attuale (16). È lì che concentrerei prima la tua attenzione.
Punteggio di rischio per modalità di fallimento (probabilità × impatto, 1–25)
Basso completamento prima della scadenza — punteggio 20. Probabilità alta (5), impatto alto (4). La retro dell'anno scorso mostra il completamento fermarsi intorno al 61% a due settimane dalla scadenza, e questa coorte è più numerosa. Se il dato della seconda settimana è sotto circa il 50%, trattalo come il fallimento già in corso. La soluzione è scaglionare l'assegnazione per team con un checkpoint rigido a metà trimestre e dare a ogni manager un elenco settimanale dei completamenti dei propri collaboratori.
Contenuto obsoleto rispetto alla normativa attuale — punteggio 16. Probabilità alta (4), impatto alto (4). La policy di origine è stata rivista l'ultima volta prima dell'ultima modifica normativa, quindi il corso potrebbe insegnare un requisito superato. Il segnale da tenere d'occhio è l'assenza di un via libera compliance sullo script finale; la soluzione è una revisione legale e di compliance datata prima del build freeze, non dopo il lancio.
La classifica completa, con un segnale d'allarme precoce e una mitigazione concreta per ciascuno, è qui sotto.
| Rischio | Probabilità | Impatto | Segnale d'allarme precoce | Mitigazione |
|---|---|---|---|---|
| Basso completamento prima della scadenza | Alta | Alto | Completamento alla seconda settimana sotto circa il 50% | Scaglionare l'assegnazione per team con un checkpoint rigido a metà trimestre e dare ai manager un elenco settimanale dei completamenti dei propri collaboratori |
| Contenuto obsoleto vs la normativa attuale | Alta | Alto | Nessun via libera compliance sullo script finale | Ottenere una revisione legale e di compliance datata del contenuto prima del build freeze, non dopo il lancio |
| Manca il buy-in dei manager | Alta | Medio | I manager non inoltrano la nota di kickoff ai loro team | Fare prima un briefing ai manager e consegnare a ciascuno uno script di due righe più l'elenco del proprio team |
| Ritardi di traduzione e localizzazione | Alta | Medio | File localizzati non pronti entro il build freeze | Bloccare presto il testo di origine ed eseguire la localizzazione in parallelo con la build, non dopo |
| Problemi di accesso a LMS e SSO | Medio | Medio | Errori di login per il gruppo di test in staging | Eseguire uno smoke test SSO con un piccolo gruppo pilota due settimane prima |
| La stanchezza da survey distorce il feedback | Medio | Basso | Tasso di risposta alla survey post-corso sotto circa il 20% | Mantenere la survey a tre domande e inserirla alla fine dell'ultimo modulo |
Se rafforzi due cose prima di costruire, che siano il piano di completamento e il via libera compliance: insieme portano i due punteggi più alti. Gli altri quattro (buy-in dei manager a 15, ritardi di localizzazione a 12, accesso a LMS e SSO a 9 e stanchezza da survey a 6) meritano ciascuno una mitigazione ma non dovrebbero bloccare il lancio.
Vuoi che trasformi il rischio principale in una checklist di responsabili e azioni, o che rediga il piano di mitigazione completo per uno di questi rischi?
Pre-Mortem Progetto ribalta il post-mortem. Tu descrivi il progetto e Joy assume che sia già fallito, poi lavora a ritroso per nominare i modi specifici in cui potrebbe accadere. Classifica ogni modalità di fallimento per probabilità e impatto, segnala il segnale d'allarme precoce da tenere d'occhio e lo abbina a una mitigazione concreta, così le lacune sono visibili mentre puoi ancora agire.
Di' a Joy cosa stai lanciando, quando e per chi. Indicale il piano di progetto, le retro passate e la mappa degli stakeholder nel tuo Knowledge Center, così i rischi sono ancorati al tuo contesto reale.
Chiedi a Joy di assumere che il progetto sia fallito e di lavorare a ritroso. Usa il comando /analyze o descrivi semplicemente cosa ti serve. Fa emergere le probabili modalità di fallimento e assegna a ciascuna un punteggio per probabilità e impatto.
Joy restituisce una tabella di rischi classificati con un segnale d'allarme precoce e una mitigazione per ciascuno, più un grafico dei punteggi di rischio così i primi due saltano all'occhio. Contesta o aggiungi contesto e riclassifica.
Copia la tabella dei rischi e le mitigazioni nel tuo documento di progetto, deck di kickoff o RAID log. Joy fa emergere i rischi; tu decidi per quali costruire delle protezioni.
Salva questa richiesta come comando personalizzato sull'assistente che il tuo team già utilizza, così chiunque può eseguirla in un solo passaggio.
Invece di una checklist di rischi generica, Joy assume che il progetto sia fallito e ragiona a ritroso sui modi specifici in cui potrebbe esserlo, così l'elenco riguarda il tuo progetto, non un progetto qualsiasi.
Ogni rischio ottiene una valutazione di probabilità e impatto e un punteggio da 1 a 25, così la priorità è ovvia a colpo d'occhio invece di un elenco piatto su cui discutere.
Ogni rischio arriva con il segnale concreto da tenere d'occhio, così capisci quando un rischio si sta trasformando nel fallimento mentre c'è ancora tempo per agire.
Joy abbina a ogni rischio una mitigazione specifica che puoi inserire direttamente nel piano, non un vago "monitorare da vicino".
Eseguilo su una nuova policy o un cambiamento di processo per far emergere i rischi di adozione e comunicazione prima di annunciarlo.
Puntalo su una migrazione di LMS o piattaforma per intercettare i rischi di accesso, dati e tempistiche prima del cutover.
Metti alla prova il piano L&D dell'anno prossimo prima che il budget sia impegnato, così le assunzioni traballanti emergono presto.
Metti sotto stress una scadenza di certificazione o compliance per vedere dove si concentrano i rischi di completamento e contenuto.
Un pre-mortem è un esercizio di pianificazione in cui immagini che un progetto sia già fallito e lavori a ritroso per nominare i motivi. Fa emergere i rischi prima di una normale revisione dei rischi perché assumere il fallimento rende più facili da vedere i punti deboli. Joy esegue l'esercizio sul tuo progetto e restituisce un elenco classificato di modalità di fallimento con segnali d'allarme e soluzioni.
Un post-mortem avviene dopo la fine di un progetto e spiega cosa è andato storto. Un pre-mortem avviene prima di costruire, mentre puoi ancora cambiare il piano. Questa ricetta esegue il pre-mortem, così le lacune emergono abbastanza presto da poter essere colmate.
No. È un'analisi on demand. La esegui quando serve (prima del kickoff, prima del build freeze, prima del lancio) e Joy legge il piano attuale e restituisce una lettura aggiornata. Non c'è nessuna bacheca permanente da tenere aggiornata.
Joy valuta ogni rischio per probabilità e impatto e li moltiplica in un punteggio da 1 a 25, poi classifica l'elenco in base a quel punteggio. Il grafico e la tabella mostrano le valutazioni così puoi vedere il ragionamento, aggiustare le assunzioni e chiedere a Joy di riclassificare.
Sì. Joy può redigere una checklist di responsabili e azioni per il rischio principale, o un piano di mitigazione più completo per un singolo rischio, come testo nella chat. Tu lo copi nel tuo documento di progetto, RAID log o deck di kickoff. Joy redige il piano; non assegna responsabili né traccia il lavoro al posto tuo.
Iscriviti alla lista d'attesa e sii tra i primi a provare questo workflow quando JoySuite sarà lanciato.