Alternativa ad Asana per la gestione dei rischi di progetto: un registro che non è una lista

Un registro dei rischi che è una lista di task

Asana ha un modello pronto di registro dei rischi e un modello di matrice. La loro logica è valida: descrivi la minaccia, valuti probabilità e impatto, nomini un responsabile e aggiungi un piano di risposta. Con un progetto e una dozzina di rischi basta. Batte anche un foglio di calcolo, perché il registro sta dove avviene il lavoro, e un confronto funzione per funzione tra FlexiProject e Asana traccia il quadro più ampio.

Il limite è nella costruzione. Qui un rischio non è un oggetto a sé, solo un task con campi in più. Tutto ciò che deriva dal fatto che un rischio non è lavoro da fare va organizzato fuori dallo strumento.

Cosa dà il modello e cosa non può

Il modello ordina le informazioni, ed è questo il suo vero valore. Tre cose non te le dà.

Un rischio non può puntare a un altro task, perché è esso stesso un task. Quindi non puoi registrare che una data minaccia riguarda una consegna precisa del cronoprogramma. I rischi non possono nemmeno essere confrontati tra progetti, perché i campi personalizzati funzionano solo dentro un progetto. E non c’è un livello sopra il progetto. Ogni registro è completo in sé e cieco a ciò che gli sta accanto. Tre team possono gestire lo stesso rischio fornitore e nessuno di loro lo scoprirà.

Tre segnali che il registro ha smesso di funzionare

Un registro aggiornato appena prima del comitato guida anziché mano a mano con il lavoro. Se aggiornare è un’attività a sé, avviene quando qualcuno lo chiede. Di solito troppo tardi per cambiare qualcosa.

Rischi ridigitati a mano nel charter di progetto e nel report mensile. Quel lavoro non crea alcuna informazione nuova, e in azienda finiscono col circolare tre versioni della stessa lista.

La domanda «se ne sta già occupando qualcuno» senza nessuno a cui chiedere. Senza un livello dove i rischi di progetti diversi si incontrano, ciascuno viene risolto da zero. Vediamo anche cosa cercare quando si valutano app come Asana.

Cosa pretendere da un registro dei rischi

La differenza tra una lista e un modulo si riduce a sette cose. Ciascuna è gestita dal sistema o fatta a mano.

Insieme descrivono ciò che un software per la gestione dei rischi deve offrire. Di seguito passo i requisiti uno per uno e mostro come FlexiProject li gestisce.

Una matrice nelle dimensioni che già usi

Configurare la matrice dei rischi sembra un dettaglio. È uno dei motivi più comuni per cui un modulo dei rischi in un sistema PPM resta vuoto. Un’azienda ha passato anni a sviluppare una matrice tre per tre, e il sistema in implementazione ha cinque per cinque cablato. Nessuno riqualificherà trenta project manager su una nuova scala perché un fornitore ha deciso così. Il risultato è prevedibile: il modulo resta inutilizzato e il rischio torna su una slide.

In FlexiProject le dimensioni della matrice si impostano durante l’implementazione, senza programmazione. L’azienda porta la scala che la sua gente conosce, insieme all’abitudine che una data valutazione richiede una data risposta. Lo standard che hai sviluppato sopravvive così al cambio di strumento.

Una scheda di rischio invece di una riga in una tabella

Nel sistema di project management FlexiProject il registro dei rischi è un modulo a sé del progetto. Ogni rischio ha un nome, uno stato, un responsabile, un legame con un task del cronoprogramma, una categoria, un impatto, una probabilità e una data di identificazione. L’impatto sul cronoprogramma e l’impatto sul budget si valutano separatamente. Conta nella pratica: un rischio che ritarda l’accettazione di un mese e un rischio che aggiunge centomila al costo richiedono risposte diverse. Una valutazione comune di «impatto alto» non li distinguerà.

Sopra il registro c’è una scheda di rischio. Oltre ai dati del registro contiene allegati, il piano di gestione di quella minaccia e un messenger dove il team discute proprio quel rischio. Sembra una piccola cosa, ma risolve un problema reale. Una discussione in un canale di team sparisce in due giorni. Una conversazione registrata sul rischio resta con esso. Quando qualcuno chiede sei mesi dopo perché è stata scelta quella risposta, la risposta è nello stesso posto della decisione.

Rischio agganciato a un task del cronoprogramma

I registri dei rischi sono di solito piatti. Trattano un rischio che riguarda tutto il progetto, per esempio una carenza di risorse, allo stesso modo di un rischio che riguarda un singolo task, come una consegna di un subappaltatore. Sono due situazioni diverse e si gestiscono diversamente.

In FlexiProject ogni rischio può essere collegato a un task specifico del modulo di cronoprogramma del progetto. Assegni un rischio fornitore al task che dipende dalla consegna, e un rischio regolatorio al task di approvazione. Da quel momento il cronoprogramma porta informazioni sulle minacce. Sulla riga del task compare un triangolo con un punto esclamativo, con accanto un cerchio: rosso quando il rischio è attivo, grigio quando non lo è. Il project manager vede i punti che richiedono attenzione senza aprire il registro.

Aiuta soprattutto quando il piano cambia. Quando il cronoprogramma si sposta, sai subito quali rischi sono diventati più pressanti. Riguardano task che si sono avvicinati a una scadenza rigida o sono passati sul percorso critico. Questa informazione esiste anche in un registro piatto, ma devi ricavarla tu confrontando due liste. Quindi di solito nessuno lo fa. A parte spieghiamo come affrontare la pianificazione dei progetti che il sistema mantiene da sé.

Il rischio come conoscenza dell’organizzazione, non di un singolo progetto

Nella maggior parte delle aziende il modo in cui i team identificano e valutano i rischi di progetto si riduce a una riunione di avvio in cui qualcuno immagina cosa potrebbe andare storto. Il metodo è inaffidabile. Le persone sottovalutano le minacce che non hanno incontrato prima. L’azienda nel suo complesso di solito le ha già viste, solo su un altro progetto.

Modelli con una lista di rischi tipici

Una lista di rischi potenziali per un dato tipo di progetto può essere integrata nel modello. Un team che avvia un’implementazione per cliente, un progetto di ricerca o un investimento parte con una base pronta e la adatta al proprio caso. Questo cambia la natura della riunione. Invece di inventare minacce, il team passa in rassegna quelle note e decide quali si applicano. È più rapido e più efficace, soprattutto nei team meno esperti.

La scheda di chiusura e i report dei rischi

L’altro lato di questo meccanismo è registrare ciò che è realmente accaduto. La scheda di chiusura del progetto può elencare i rischi verificatisi e come sono stati risolti. I team che pianificano progetti successivi hanno accesso alle schede di chiusura storiche.

Il terzo elemento sono i report. Nel modulo report puoi costruire una vista dei rischi per i progetti di una categoria o di un’area dell’organizzazione. Un nuovo team ottiene una risposta concreta: queste sono le minacce verificatesi in progetti simili. Insieme, questi tre meccanismi fanno sì che la gestione dei rischi non dipenda più dalla competenza di un singolo responsabile.

Categorie di rischio e la vista per le funzioni

Il rischio raramente riguarda solo il project manager. Il legale vuole sapere quali obblighi e contenziosi sono nel portfolio. La produzione chiede delle sfide tecnologiche, gli acquisti delle minacce dal lato fornitori. Con un registro chiuso dentro un progetto, nessuno di loro può porre la propria domanda.

Nelle impostazioni di FlexiProject definisci la tua lista di categorie di rischio, allineata a come è ripartita la responsabilità in azienda. È qui che una struttura di scomposizione dei rischi (RBS) smette di essere un diagramma e diventa qualcosa su cui il sistema può filtrare. Su questo si costruiscono i report tra progetti. Il legale vede i rischi legali di tutti i progetti, la produzione i suoi, gli acquisti i loro. Il rischio smette di essere l’affare privato del project manager. A parte analizziamo che cos’è un vero controllo del budget di progetto.

Livello di portfolio, ovvero la fine del gestire lo stesso rischio tre volte

Con diverse decine di progetti, alcune minacce si ripetono per loro natura. Lo stesso fornitore, la stessa modifica normativa, la stessa tecnologia immatura. Se i registri sono chiusi dentro i progetti, ogni responsabile tiene la propria versione di quel rischio e arriva a conclusioni leggermente diverse.

Il software per il portfolio di progetti lo risolve in modo diverso. Ogni portfolio in FlexiProject ha una scheda rischi a sé. Raccoglie le minacce di tutti i progetti di quel portfolio. Il coordinatore vede la ripetizione e può risolvere il rischio in modo centralizzato, usando tutta la conoscenza disponibile invece di una sola prospettiva. Il triplo sforzo diventa un responsabile e una risposta. Elimina anche la situazione in cui tre progetti applicano tre strategie diverse allo stesso fornitore. A parte spieghiamo che cosa deve offrire un’alternativa ad Asana per un PMO.

Fine della ridigitazione: il charter e il report di stato

Il risparmio più evidente riguarda la ridigitazione, non l’analisi. In molte aziende la procedura richiede che i rischi più significativi arrivino al charter di progetto e, una volta al mese, al report per la direzione. Con un registro a sé, qualcuno sposta le stesse voci in due punti e verifica che le versioni coincidano.

In FlexiProject il modulo del charter di progetto preleva i rischi dal registro automaticamente. Entrambi i documenti sono coerenti per progettazione, non per la diligenza di qualcuno. La reportistica di stato ciclica funziona allo stesso modo. Se il report contiene una sezione rischi, si compila da sé dal registro, e al responsabile resta un commento su come quelle minacce vengono gestite. Un’attività che non creava alcuna informazione nuova sparisce, ed è sparita dalla settimana peggiore del mese.

Quando un modello basta

Gestisci un progetto, lo segui tu, hai una dozzina di rischi e nessuno richiede reportistica formale? Un modello di registro in uno strumento di task basta. Un modulo a sé aggiungerà formalità, non controllo, perché i problemi descritti sopra compaiono a scala maggiore. Se vuoi uno sguardo più ampio alle opzioni, abbiamo confrontato a parte il miglior software per la gestione dei rischi.

I segnali che questa scala è arrivata sono concreti. Compaiono un secondo e un terzo progetto, e i rischi vanno confrontati tra loro. Qualcuno fuori dal progetto chiede delle minacce in un dato taglio. La procedura richiede rischi nel charter e nel report. Da quel punto una lista con campi personalizzati costa più lavoro di quanto ne faccia risparmiare.

Come provarlo sul tuo registro in due settimane

I confronti di funzionalità decidono poco, perché la pagina di ogni fornitore risponde sì a tutto. Un test sui tuoi dati dice di più. Prendi il registro di un progetto in corso e trasferiscilo per intero, insieme alla tua scala di valutazione. Questo primo passo mostra se la tua matrice entra nello strumento senza cambiare le abitudini del team.

Poi quattro test. Collega tre rischi a task del cronoprogramma e verifica di vederli sul diagramma di Gantt. Sposta uno di quei task di due settimane e osserva se il quadro delle minacce cambia. Costruisci un report dei rischi per una categoria, i fornitori per esempio, che copra più progetti. Apri la scheda rischi del portfolio e controlla se una minaccia si ripete in più punti. Quest’ultimo test di solito giustifica il cambio da solo.

Domande frequenti

Asana ha un registro dei rischi?

Asana offre un modello di registro dei rischi e un modello di matrice. Producono una lista con campi come probabilità, impatto, responsabile e piano di risposta. Non è un modulo a sé, solo un progetto fatto di task. Quindi non puoi collegare un rischio a un task del cronoprogramma, confrontarlo tra progetti né vederlo a livello di portfolio.

Che differenza c’è tra un registro dei rischi e una lista di task con campi personalizzati?

La stessa differenza che c’è tra un rischio e un lavoro da fare. Un registro tratta il rischio come un oggetto a sé con un proprio ciclo di vita, valutazione, responsabile, piano di risposta e legami con cronoprogramma e budget. Una lista di task ti lascia registrare quelle informazioni ma non usarle fuori da un progetto.

Cosa si ottiene collegando un rischio a un task del cronoprogramma?

Mostra dove nel piano si trova la minaccia. In FlexiProject un task con un rischio collegato porta un’icona di avviso sul diagramma di Gantt, e il colore accanto dice se il rischio è attivo. Dopo ogni cambio del cronoprogramma vedi quali minacce sono diventate più pressanti.

Possiamo tenere la nostra matrice dei rischi?

Sì. Le dimensioni della matrice si impostano durante l’implementazione, così un’azienda che lavora con una scala tre per tre non deve passare a cinque per cinque. È una delle condizioni più importanti perché un modulo dei rischi venga usato invece che evitato.

Come iniziamo se il nostro registro dei rischi è oggi in Excel?

Trasferendo un progetto in corso, insieme alla sua scala di valutazione e alle sue categorie attuali. Il foglio di calcolo di solito contiene tutte le informazioni necessarie. Ciò che gli manca sono i legami: ai task, agli altri progetti e ai documenti che comunque compili a mano. Quei legami sono il motivo per cambiare, non il semplice fatto di tenere un registro.

Si cerca un’alternativa ad Asana per la gestione dei rischi di progetto non perché non ci sia dove registrare una minaccia. Il motivo è un altro: una minaccia registrata poi non fa nulla. Un registro che è una lista finisce alla documentazione. L’informazione esiste, ma non si collega al cronoprogramma, non si somma tra progetti, non torna all’azienda al progetto successivo e va ridigitata in ogni documento separatamente. Un registro che è un modulo fa queste quattro cose da sé. Lascia al responsabile l’unica cosa che nessun sistema farà al posto suo: decidere come rispondere. Se il tuo registro oggi si aggiorna soprattutto prima del comitato guida, il modo più economico per verificarlo è trasferire un progetto e collegare tre rischi a task del cronoprogramma.