Root Cause Analysis

La root cause analysis (RCA) è una tecnica di indagine che viene applicata ad eventi di particolare impatto, in particolare incidenti, ed è finalizzata ad esaminare quanto accaduto ricercandone le cause.

Rispetto alle indagini di tipo tradizionale, l’obiettivo è quindi focalizzato non tanto sulla ricerca delle responsabilità (chi è stato), quanto sulla identificazione degli interventi di miglioramento (in modo da evitare il ripetersi dell’accaduto).

La RCA è basata su un approccio metodologico che presenta l’incidente come l’evento finale non voluto di un percorso che parte dalle cosiddette latent condition (condizioni organizzative e di contesto di lavoro con lacune, inefficienze ed errori di tipo progettuale) e latent failure (condizioni concrete in cui gli individui si trovano ad operare), esamina le active failure, cioè azioni non sicure, errori umani e violazioni, che portano all’insorgere dell’incidente.

I responsabili di progetto hanno il compito a volte ingrato di gestire requisiti e risorse che spesso non sono sotto il loro diretto controllo, al fine di sviluppare un progetto entro i vincoli (in termini di ambito, tempi, costi e qualità) stringenti ai quale devono attenersi (copertura, nel tempo, qualità, ecc.).

Inoltre occorre ragionare sui possibili rischi che possono avere un impatto decisivo sul progetto e che non sempre possono essere rimossi, ma devono essere o trasferiti oppure gestiti in modo da mitigarne gli impatti.

In tal senso, le principali attività finalizzate a ridurre i rischi di progetto sono:

• in fase di pianificazione, l’analisi qualitativa e quantitativa dei rischi finalizzate a censire i rischi, valutarne la probabilità e impatto, individuare le strategie di risposta, i piani di azione e le responsabilità ad essi collegate, le riserve di contingency e di gestione;
• in fase di esecuzione, l’eventuale implementazione dei piani di azione, il monitoraggio dei piani di azione stabiliti e delle riserve adottate;
• in fase di chiusura del progetto, la stesura retrospettiva delle lessons learned che aiuterà ad evitare il rispetersi in futuro degli errori commessi nella gestione di tali rischi.

Tuttavia, per i problemi imprevisti che emergono in fase di esecuzione, dopo che l’analisi del rischio è già stata completata, non sempre è possibile ripetere il processo di risk management ed occorre individuare delle soluzioni ad-hoc.

Sfortunatamente, in queste situazioni spesso le azioni che vengono intraprese tendono ad affrontare il problema nel suo complesso e non le sue cause sottostanti. I sintomi possono essere individuati, così come le risorse da attivare; ma lavorare sui sintomi e non sulle cause potrebbe portare al ripetersi del problema.

Al fine di superare questa incertezza deve essere seguito il seguente processo di problem solving:

1. Definire il problema – Che cosa si è verificato, dove e quando è stato identificato, quando ha avuto inizio, e quanto è significativo?
2. Comprendere il processo – Quali sono state le fasi del processo attuate prima dell’insorgere del problema?
3. Identificare le possibili cause – Se le cose non sono andate come previsto, quale delle fasi del processo potrebbe avere causato il problema?
4. Raccogliere dati – Quali sono le informazioni che potrebbero indicare delle possibili cause?
5. Analizzare i dati – Cosa indicano i dati in termini di rapporti causa/effetto?
6. Individuare le possibili soluzioni – Quali cambiamenti ai processi di progettazione ed esecuzione potrebbero evitare il ripetersi di tali problemi in futuro?
7. Selezionare le soluzioni – Quale delle possibili soluzioni individuate sono le più vantaggiose?
8. Implementare le soluzioni – Pianificare e realizzare le soluzioni selezionate.
9. Valutare gli effetti – Le soluzioni implementate hanno funzionato? Quali sono i risultati ottenuti?
10. Consolidare il cambiamento – Aggiornare le linee guida di gestione dei progetti e gli strumenti per assicurare che i progetti futuri possano avvalersi dei miglioramenti ottenuti.

I passaggi da 1 a 5 sono in genere fatti in modo iterativo, fino a quando le cause sono state investigate ad una profondità sufficiente per prevenirne il ripetersi.

Naturalmente non è necessario svolgere tale livello di indagine per ogni problema che si genera durante il ciclo di vita di un progetto; e la decisione sul livello di profondità dell’indagine deve essere il frutto di una valutazione complessiva del rischio in questione.

Oltre ad una carenza nella leadership del progetto o nei processi di gestione del rischio, ci possono essere anche altre barriere ad una corretta individuazione ed applicazione di azioni correttive:

• La tendenza di un singolo individuo nel cercare di eseguire le indagini e risolvere il problema senza un aiuto. Un singolo individuo è improbabile che abbia sufficiente dimestichezza con tutti i processi coinvolti per essere in grado di valutare in modo efficace e senza pregiudizi. Pertanto, il project manager deve coinvolgere più componenti del team nella diagnosi di problemi complessi in modo da giovarsi dell’apporto di competenze da parte di ciascuno.
• Nella fretta di risolvere i problemi, le persone fanno ipotesi e saltano l’analisi delle cause o delle soluzioni, senza disporre di dati adeguati. Questo porta a manomettere i processi e ciò può causare ulteriori problemi. I responsabili di progetto devono pertanto essere certi che vengano raccolte informazioni adeguate prima di decidere quali azioni intraprendere.
• Le azioni correttive hanno spesso una connotazione negativa nelle organizzazioni e le persone non amano indagare i propri errori. Tuttavia, molti studi hanno dimostrato che gli esseri umani e le organizzazioni imparano di più dai loro fallimenti che dai loro successi e pertanto le azioni correttive devono essere viste semplicemente come parte di un processo di apprendimento. Quindi ogni Project Manager deve spendere la propria positività nel coinvolgere le persone nei processi di problem solving finalizzati al superamento dei problemi ed al miglioramento organizzativo.
• Le azioni correttive sono viste come qualcosa che si aggiunge al “lavoro regolare”, piuttosto che come parte della gestione aziendale efficace, come indicato dal ciclo Plan-Do-Check-Act che ogni Project Manager deve applicare come parte integrante della gestione della qualità di progetto.
• In generale le persone sono portate ad autoproteggersi e ad evitare di esporsi od essere coinvolte nella soluzione di problemi, in particolare quelli creati da altri, ed il Project Manager deve invece assicurare un commitment complessivo del team di progetto nella soluzione delle issues che possono emergere in ogni momento.