Modello RAID Log Permalink

Usa questo modello per gestire un RAID log in Quire: tieni rischi, ipotesi, problemi e dipendenze in un unico posto, classificali per impatto nella Vista tabella e tieni una revisione settimanalmente che chiude davvero le cose.

Puoi visitare il progetto RAID Log e duplicarlo nel tuo spazio di lavoro, così non devi costruire tutto da zero.

Puoi anche esplorare altri modelli pronti all’uso per accelerare il tuo flusso di lavoro.

Comprendere i RAID Log

RAID è l’acronimo di Risks, Assumptions, Issues and Dependencies (Rischi, Ipotesi, Problemi e Dipendenze). Un RAID log è il registro continuo di tutti e quattro: cosa potrebbe andare storto, su cosa si sta scommettendo senza averlo verificato, cosa è già andato storto e cosa serve da persone esterne al team.

La maggior parte dei team traccia alcune di queste cose da qualche parte. Pochissimi le raccolgono tutte e quattro in un unico posto, ed è lì che risiede il valore. Un codice di budget mancante sembra un piccolo problema amministrativo finché non ci si accorge che è per questo che il fornitore non rilascia le credenziali, che è per questo che l’accordo della settimana di lancio è ancora non firmato. Una causa alla radice, tre liste separate, nessuno che le collega.

Il log è strutturato in cinque sezioni, con una milestone fissata in cima in modo che ogni data sottostante venga letta rispetto alla scadenza che conta.

Quattro sezioni contengono le categorie stesse. La quinta, la governance RAID, contiene la cadenza delle revisioni, che è la parte che decide se il log sopravvive oltre il secondo mese. Ventuno voci di esempio già compilate sono incluse, così puoi leggere la struttura di una buona scrittura prima di sostituirle con le tue.

RAID Log o registro dei rischi

Quire include entrambi, e rispondono a domande diverse. Un registro dei rischi è uno strumento approfondito per una categoria: una matrice 5x5, punteggi numerici del rischio, cinque strategie di risposta formali e una cadenza di governance, tutti puntati solo sul rischio. Un RAID log è uno strumento meno dettagliato per quattro categorie, valutando il rischio con solo probabilità e impatto, ma coprendo le ipotesi e le dipendenze per cui un registro non ha spazio.

Usa il log quando vuoi un unico posto per tutto ciò che potrebbe far deragliare il progetto. Usa il registro quando la gestione del rischio è l’intero lavoro e il punteggio deve essere difendibile. Usarli entrambi è comune, con il log come registro di lavoro e il registro come artefatto formale.

Il modello include un documento che copre la configurazione, le regole delle categorie e le modalità di fallimento da evitare.

Un secondo documento contiene l’agenda per la revisione settimanale, così chi conduce la riunione non deve inventare l’ordine del giorno la mattina stessa.

Distinguere le Quattro Categorie

Le categorie vengono confuse continuamente, e una discussione su dove inserire qualcosa è un ottimo modo per sprecare i primi dieci minuti di una revisione. Quattro test risolvono quasi tutto.

Tre regole risolvono il resto.

1. Un rischio che si materializza non è più un rischio. Spostalo in Problemi e chiudi il rischio con una nota che indica dove è andato, invece di lasciarlo aperto in entrambi i posti.
2. Un’ipotesi che risulta falsa non è semplicemente sbagliata: ha una conseguenza. Chiudi l’ipotesi e segnala quella conseguenza come rischio o problema.
3. Una dipendenza che hai terminato di sollecitare è un rischio. Rivalutala alla pulizia mensile.

La voce di esempio A-01 nel modello è l’esempio pratico della seconda regola, collegata al problema che ha prodotto.

Leggere il Log nella Vista Tabella

La Vista tabella è disponibile solo nei piani Professional, Premium ed Enterprise. Maggiori informazioni sono disponibili nella nostra pagina dei prezzi.

La Vista tabella è il RAID log vero e proprio. Affianca ogni campo personalizzato alla voce, e ordinando per Impatto la cima della lista diventa l’agenda della riunione.

Sette campi gestiscono il log.

“Creato il” e “Ultimo esame” sembrano solo dati contabili. Una voce creata a marzo, esaminata ad aprile e ancora aperta a settembre non è gestita, e quelle due date sono l’unico modo in cui questo fatto emerge senza che qualcuno se ne accorga per caso.

Nota: Se ti ritrovi a compilare Probabilità su un problema, probabilmente è un rischio che non è stato riclassificato. I problemi si sono già verificati, quindi la loro probabilità è cento per cento.

Otto etichette attraversano tutte e quattro le categorie: Budget, Pianifica, Tecnico, Ambito, Cliente, Fornitore, Persone e Conformità. Rispondono a una domanda diversa dal Tipo, ovvero da dove proviene la voce piuttosto che che tipo di cosa è.

Scrivere una Voce che Vale

La differenza tra un RAID log utile e un artefatto di conformità risiede quasi interamente nel modo in cui le voci sono scritte. Ogni voce di esempio nel modello segue la stessa struttura in quattro parti.

La descrizione si apre con una dichiarazione se X, poi Y, poi indica l’impatto se accade in unità che interessano a qualcuno, poi nomina la risposta, poi fornisce il trigger da monitorare. Il lavoro di mitigazione è collegato alla voce come attività secondarie, così il piano e il registro rimangono nello stesso posto.

Cinque regole fanno la differenza.

• Scrivi i rischi come causa ed effetto. “Ritardo del fornitore” è una preoccupazione. “Se il fornitore manca il 6 agosto, poi il test di autenticazione inizia senza credenziali di produzione e i test slittano di due settimane” è qualcosa su cui un team può agire.
• Dai a ogni rischio un trigger. Il punto osservabile in cui termina di essere ipotetico. Senza di esso, l’escalation avviene tardi e a intuito.
• Nomina la risposta. Evitare, mitigare, trasferire o accettare. “Monitorare” non è una risposta, è un modo per scrivere “non abbiamo ancora deciso”.
• Scrivi l’impatto in unità che interessano a qualcuno. Settimane, denaro, clienti, reputazione. “Alto impatto” non dice nulla a uno sponsor.
• Metti una data su tutto. Una voce senza data di scadenza non verrà mai lavorata.

Assegna una persona nominata a ogni voce. Un team non insegue mai nulla, perché nessuno al suo interno ritiene che farlo spetti specificamente a lui.

Tracciare il Flusso nella Vista Bacheca

La Vista bacheca raggruppata per Stato mostra il movimento piuttosto che l’inventario, un’immagine diversa e più onesta.

Sei stati gestiscono il log.

“In attesa di risposta” è quello che guadagna il suo posto. Senza di esso, “In corso” deve coprire sia “sto lavorando su questo” che “ho inviato un’email nove giorni fa”, e questi due richiedono follow-up completamente diversi.

Suggerimento: Osserva la colonna Escalato nel corso di alcune settimane invece di leggerla una volta sola. Se si riempie più velocemente di quanto si svuota, è un segnale di salute più affidabile di qualsiasi rapporto di stato.

Estrarre Viste Trasversali con le Sottoliste

Nel piano Free Subscription, puoi creare due sottoliste per ogni progetto, e questo modello ne include 4. Tieni le due che il tuo team apre più spesso dopo aver duplicato, oppure aggiorna il tuo piano di abbonamento per usarle tutte e quattro. Maggiori informazioni sono disponibili nella nostra pagina dei prezzi.

Le sezioni rispondono alla domanda “che tipo di cosa è questa”. Quattro sottoliste rispondono a domande che attraversano tutte e quattro le categorie contemporaneamente, ed è qui che mantenere un unico log invece di quattro inizia a dare i suoi frutti.

• Escalare ora raccoglie ogni voce con impatto critico ancora aperta, indipendentemente dalla categoria. Questo è il materiale per il comitato direttivo. Se supera circa sei elementi, il progetto è sotto osservazione piuttosto che gestito.
• In attesa di qualcun altro contiene tutto ciò la cui prossima mossa non è tua. Aprila prima di ogni chiamata di stato e sollecita i primi tre.
• Ipotesi non validate è la lista che nessuno legge finché non è troppo tardi. Leggila ad alta voce una volta al trimestre.
• La catena del fornitore è un esempio pratico piuttosto che un filtro.

Quest’ultimo vale la pena aprirlo per primo, perché mostra l’intero argomento a favore di un unico log in quattro voci.

Un ordine di acquisto non emesso è un problema. Blocca l’approvazione dell’ordine da parte della finanza, che è una dipendenza. Questo blocca la consegna delle credenziali di produzione da parte del fornitore, un’altra dipendenza. Ed è per questo che l’accordo della settimana di lancio è ancora non firmato, registrato come rischio. Tre categorie, una causa alla radice, visibile solo perché vivono nello stesso log. Le voci sono collegate con vere dipendenze tra attività, così la catena è applicata anziché semplicemente descritta.

Mantenere il Log Onesto

Un log senza revisione è un documento, non un processo. La sezione di governance contiene quattro attività ricorrenti in modo che il ritmo atterri sul Pianifica invece di dipendere dalla memoria di qualcuno.

Tre modalità di fallimento sono responsabili della maggior parte dei RAID log morti, e vale la pena nominarle perché arrivano in silenzio.

1. Diventa un cimitero. Cinquanta voci aperte, la maggior parte obsolete, così le persone terminano di aprirlo. Una voce che nessuno ha toccato in due mesi o non è reale o non è assegnata.
2. Tutto è ad alto impatto. Se l’intero log è rosso, ha terminato di classificare qualsiasi cosa. Quattro voci critiche su venti è un progetto plausibile. Quattordici è un progetto a cui nessuno ha pensato.
3. Viene aggiornato solo prima della riunione del comitato direttivo. A quel punto si è trasformato da strumento di gestione in strumento di reporting.

Tutti e tre hanno la stessa soluzione, per quanto poco esaltante: una breve revisione settimanalmente e chiudere le voci in modo deciso.

Per saperne di più leggi il nostro blog su come valutare i rischi e mantenere vivo un registro.

Domande frequenti

Cos’è un RAID log?

Un RAID log è un unico registro continuo di cosa potrebbe andare storto, su cosa si sta scommettendo senza averlo verificato, cosa è già andato storto e cosa serve da persone esterne al team. Tenere tutti e quattro in un unico posto è ciò che permette di vedere che problemi apparentemente separati condividono una causa alla radice.

Cosa significa l’acronimo RAID?

Risks, Assumptions, Issues and Dependencies (Rischi, Ipotesi, Problemi e Dipendenze). Lo si trova anche espanso come Risks, Actions, Issues and Decisions, più comune nel lavoro di programma. Il modello Quire usa la prima versione perché le ipotesi e le dipendenze sono le due categorie che i team hanno meno probabilità di tracciare altrove.

Qual è la differenza tra un rischio e un problema?

Tempo verbale e certezza. Un rischio è futuro e incerto, scritto come “se X, poi Y”. Un problema è presente e certo, perché è già accaduto. Quando un rischio si materializza termina di essere un rischio, quindi spostalo in Problemi e chiudi il rischio con una nota che indica dove è andato.

Qual è la differenza tra un RAID log e un registro dei rischi?

Un registro dei rischi è uno strumento approfondito per una categoria, con una matrice 5x5 e strategie di risposta formali. Un RAID log è uno strumento meno dettagliato per quattro, e copre le ipotesi e le dipendenze per cui un registro non ha spazio. Molti team li usano entrambi.

Chi è responsabile del RAID log?

Il responsabile di progetto gestisce il log stesso, ovvero la cadenza delle revisioni, la chiusura delle voci obsolete e le escalation. Ogni singola voce ha bisogno di una persona nominata, mai un team, perché un team non insegue mai nulla.

Con quale frequenza dovrebbe essere revisionato un RAID log?

settimanalmente per l’intero log, circa 30 minuti ordinati per impatto. mensilmente per chiudere le voci obsolete e rivalutare i rischi aperti. Trimestralmente per rivalidare le ipotesi. Il modello mantiene tutte e tre come attività ricorrenti in modo che atterrino sul Pianifica da soli.

Cosa dovrebbe contenere una voce del RAID log?

Un ID stabile come R-01, la categoria, una valutazione dell’impatto, un proprietario nominato, una data di scadenza e una risposta scritta. I rischi hanno inoltre bisogno di una probabilità e di un trigger, che è il punto osservabile in cui il rischio termina di essere ipotetico e qualcuno deve agire.

Perché i RAID log terminano di essere utili?

Tre modalità di fallimento: il log diventa un cimitero di voci obsolete, tutto viene contrassegnato come ad alto impatto così niente è classificato, oppure viene aggiornato solo prima della riunione del comitato direttivo. La soluzione per tutti e tre è una breve revisione settimanalmente e chiudere le voci in modo deciso.

Esiste un modello RAID log già pronto in Quire?

Sì. Visita il progetto RAID Log e duplicalo nel tuo spazio di lavoro per ottenere le quattro sezioni di categoria più quella di governance, sette campi personalizzati, sei stati, otto etichette, quattro sottoliste trasversali e ventuno voci di esempio già impostate.