Imprevisti di progetto: il problem solving non basta

La volta scorsa abbiamo visto come le nostre vite professionali e personali siano permeate di progetti. Non in senso figurato ma strettamente tecnico, in base ad una definizione di progetto rigorosa e conforme agli standard: insieme di attività coordinate con uno specifico obiettivo e una collocazione temporale determinata.

Questo ha due conseguenze. La prima è che tutti noi, volenti o nolenti, dobbiamo spesso interpretare il ruolo del Project Manager anche se non siamo pagati per farlo come professionisti. La seconda è che il Project Management non è una disciplina esoterica per soli iniziati, ma una materia pervasiva le cui tecniche e pratiche possono tornare utili in qualsiasi contesto.

Ad esempio, un’attenta pianificazione è uno dei fattori più importanti di successo di un progetto. Tuttavia, per quanti sforzi facciamo non possiamo prevedere tutto. L’inaspettato è dietro l’angolo e per definizione non può essere pianificato. Ma è davvero sempre così? La scheda di oggi presenta gli esercizi di base su come affrontare gli imprevisti sui nostri progetti, con lo scopo non tanto di allenare la vostra capacità di risolvere problemi, quanto piuttosto quella di evitarli.

Warm up

Tutti gli annunci di lavoro pubblicati sui quotidiani prima dell’avvento di Linkedin chiedevano ai candidati un requisito irrinunciabile: la “capacità di problem solving”. Non importa quale fosse la posizione offerta o il profilo da selezionare. Così tutti inserivano nel loro CV la formula di rito “spiccata capacità di problem solving”. Non “buona”, “ottima” o “comprovata”. Spiccata. Si usava così. Quanto poi questo requisito fosse davvero verificato dai recruiter non ho gli elementi per dirlo.

E voi, sui vostri progetti, quanto fate affidamento sulla capacità di problem solving, vostra e del vostro team? Alcuni pensano che il Project Manager ideale debba essere un po’ come il Mister Wolf di Pulp Fiction (“I’m Winston Wolfe. I solve problems” cit.). Un problem fixer, un cleaner che sistema situazioni critiche sotto pressione con classe ed efficienza.

Credo invece che il bravo Project Manager, più che a Mister Wolf, dovrebbe ispirarsi a Sun Tzu che nel suo celebre “L’arte della guerra” – in origine trattato di strategia militare, di recente riferimento motivazionale di culto per manager e dirigenti d’azienda – afferma che “in guerra vince chi sa pianificare” e che la suprema abilità militare consiste nel “vincere senza combattere”.

Cosa accade se il vostro avversario è il problema, l’imprevisto?

Mister Wolf suggerisce un approccio di problem solving “reattivo”, basato sulla capacità di mitigare l’effetto del problema, anche con workaround temporanei in attesa di una soluzione definitiva.

Sun Tzu suggerisce invece un approccio “proattivo”, idealmente addirittura “predittivo”, dove lo scopo è anticipare il problema o intercettarlo il prima possibile per poterlo disinnescare al meglio.

Quante volte avete sentito manager, imprenditori o persone con responsabilità dire “Perché preoccuparcene adesso? Se poi il problema dovesse verificarsi, lo gestiamo…”. Dietro quel “lo gestiamo” c’è spesso un mix di pigrizia, di voglia di sentirsi il Mister Wolf della situazione e di sopravvalutazione della propria “spiccata” capacità di problem solving, che rischiano di trasformare un’ipotesi di imprevisto in un problema manifesto, da combattere poi necessariamente a viso aperto.

Per cominciare, vediamo qualche esercizio per allenare il problem solving reattivo, che dovete comunque conoscere perché nella realtà, per quanto accuratamente possiate pianificare, non tutti i problemi possono essere disinnescati in anticipo. Accenneremo poi al problem solving proattivo, ampiamente preferibile, che sarà oggetto di una prossima scheda dedicata.

Esercizi

Anche se non avete il talento innato di Mr Wolf, la vostra capacità di risolvere problemi può essere allenata. Di seguito alcuni di esercizi di base, da eseguirsi nell’ordine in cui ve li presento con l’ausilio di carta e penna o, meglio ancora, del vostro foglio elettronico preferito.

Esercizio N. 1, identificazione e logging: sembra ovvio, ma la registrazione e tracciatura del problema è un passo fondamentale. Alimentare un registro dei problemi migliora la vostra capacità di risposta futura a situazioni analoghe. Potete impostare una semplice tabella con 7 colonne di partenza:

1. numero progressivo (identificativo del problema),
2. codice del problema (mnemonico),
3. breve descrizione,
4. indicazione dell’ambito in cui si è manifestato,
5. data di rilevazione
6. soggetto che lo ha rilevato
7. note (eventuali altre informazioni)

Esercizio N. 2, Classificazione: una volta identificati e tracciati, i problemi dovrebbero essere classificati in base a caratteristiche di similitudine (es. problemi di usabilità di una app, problemi di rendimento di una caldaia da riscaldamento, etc.). La classificazione arricchisce le informazioni migliorando la capacità di risposta preventiva. Aggiungerete quindi alla tabellina di prima una ulteriore ottava colonna, che indichi la categoria/classe di errore scelta da una lista concordata.

Esercizio N. 3, Prioritizzazione: spesso i problemi non vengono da soli e dovete individuare quelli più critici, da affrontare per primi. Il criterio di priorità è associato di solito al danno in termini di valore (non necessariamente economico, o non solo) causato dal problema. Ad esempio, un danno di immagine derivante da un epic fail di comunicazione.

Basta aggiungere una ulteriore nona colonna alla tabella, con un valore convenzionale di severità/criticità (es. alto-medio-basso, rating da 1 a 5, etc.). Usando una codifica numerica, il foglio elettronico vi consentirà di ordinare facilmente la tabella per valori di priorità decrescente.

Esercizio N. 4, Investigazione e diagnosi: per venire a capo del problema dovete individuarne le cause. Questa è la parte più intrigante ma anche quella più difficile.

L’investigazione potete farla con un’analisi di Pareto, che vi permette di identificare le cause che consentono di risolvere la maggior parte dei problemi. Quella di Pareto è nota come “regola dell’80-20”, secondo cui un ristretto numero di cause (20%) è responsabile della maggior parte dei problemi (80%). Si tratta naturalmente di una regola convenzionale, che non va considerata in termini assoluti.

Immaginate di essere proprietari di un albergo e di avere avviato un progetto per il miglioramento del livello di servizio, sulla base dei reclami della clientela raggruppati per tipologia. La figura seguente mostra il diagramma di Pareto, costituito da un istogramma a barre verticali che rappresentano il numero di reclami per ciascuna tipologia. Sullo stesso diagramma si costruisce la curva della percentuale cumulativa (curva di Lorenz).

L’analisi evidenzia che per risolvere la maggior parte dei problemi (soglia dell’80%) dovete concentrarvi su 3 tipologie di lamentela: reception, colazione e rumorosità delle camere.

A questo punto, dopo l’investigazione è il momento della diagnosi. Prendiamo il “problema reception” (le considerazioni che sto per fare potete ripeterle analogamente anche per il “problema colazione” e per il “problema rumorosità”).

Una tecnica popolare di diagnosi guidata è quella di Ishikawa o del “diagramma a lisca di pesce”. Perché la reception è insoddisfacente? Cominciate col dividere lo spazio di lavoro in due aree: a destra l’effetto (il problema da risolvere), a sinistra le cause. Poi disegnate la “spina dorsale della lisca” che punta al problema (in arancione nel diagramma seguente).

A questo punto dovete definire le categorie di riferimento per la root-cause analysis (le spine principali della lisca, in verde nel diagramma). In uno scenario di servizio come questo potete usare People, Material, Procedures, Environment, Policies (ndr. in ambito manufacturing probabilmente sostituireste Policies e Procedures con Machine e Method). Ora, tramite brainstorming o in base a dati raccolti sul campo, individuerete le cause potenziali come sotto-categorie di quelle principali (spine secondarie in nero nel diagramma), sino ad un soddisfacente livello di dettaglio.

Tra tutte le potenziali cause individuate, potete poi ricavare quelle su cui effettivamente agire per risolvere il problema – in rosso nello schema – dall’analisi di dati raccolti attraverso ulteriori survey somministrati ai clienti o da correlazioni ottenute da analisi di regressione.

Esercizio N. 5, Risoluzione: determinate le cause del problema, potete procedere alla sua risoluzione rimuovendole o annullandone gli effetti. Aggiungerete quindi alla vostra tabella altre 2 colonne:

• Responsabile Risoluzione (persona o unità organizzativa incaricata della risoluzione del problema).
• Data Risoluzione.

Esercizio N. 6, Chiusura: una volta affrontato e risolto il problema, è importante formalizzarne la chiusura. Non dovete mai cancellare dal registro la riga di un problema risolto e chiuso, ma mantenerla come memoria storica per problematiche simili che dovessero ripresentarsi in futuro. Quindi, è sufficiente aggiungere una ultima colonna dove indicherete eventualmente la “Data di chiusura” del problema.

Riepilogando, la vostra tabella dei problemi appare come di seguito.

Le colonne proposte sono indicative. Potete aggiungerne altre che abbiano senso nel vostro contesto progettuale. Cominciate ad allenarvi utilizzando la tabella/registro su progetti semplici (es. l’organizzazione di un evento familiare) e, man mano, provate ad applicarla a contesti di business di complessità crescente.

Come dicevamo prima, però, ancora più importanti sono gli esercizi per sviluppare il problem solving proattivo, cercando di applicare il precetto di Sun Tzu: vincere senza combattere provando per quanto possibile ad anticipare i problemi, a prevenirli, intervenire sulle cause scatenanti o, se non ci riusciamo fuori dal nostro controllo, predisporre misure per tentare di limitare almeno i danni.

Per guadagnare il prima possibile questo mindset, il consiglio è di cominciare oggi stesso da qualcosa di semplice, facendo il maggior numero possibile di ripetizioni. Se ad esempio uscite a fare una passeggiata, portatevi l’ombrello. Se arriva un acquazzone (il problema) non potrete agire sulle cause scatenanti (perturbazione più o meno improvvisa) ma almeno ne mitigherete l’impatto evitando di inzupparvi.

Nella gestione di progetto, agire d’anticipo vi darà sempre due fondamentali vantaggi:

1 – Avrete più chance di risolvere problemi e imprevisti o di limitarne gli effetti negativi. Non ci sono garanzie di riuscire a gestire un problema quando questo si manifesta in modo conclamato. Se non avete portato l’ombrello, potreste non trovare un riparo nelle vicinanze quando arriva l’acquazzone.

2- Vi farà spendere di meno. In qualsiasi progetto, piccolo o grande, semplice o complesso, il costo di prevenzione di un problema è sempre molto minore del costo di risoluzione. Un paio di settimane di test in più sull’applicazione software che state realizzando vi costerà molto meno che dover risolvere un malfunzionamento dopo che l’avrete rilasciata ai vostri clienti.

Defaticamento e Stretching

Saper risolvere problemi è utile, ma il successo di un progetto passa più dalla capacità di disinnescarli in anticipo, spendendo qualche ora o giornata di pianificazione in più – a seconda della dimensione e complessità del progetto – per mettersi a tavolino e cercare di individuare potenziali criticità e minacce, valutarne gli impatti e le priorità e predisporre per ciascuno una strategia di risposta, un piano B e se necessario anche un Piano C.

Così facendo, si può pensare con calma alla migliore soluzione da adottare, senza dover prendere decisioni sotto la pressione dell’emergenza. C’è un insieme di processi, tecniche e pratiche per fare tutto ciò in maniera organizzata e strutturata. Si chiama Risk Management e sarà il tema della prossima scheda di allenamento progettuale.

Nel frattempo, utilizzate la tabella/registro e applicate le tecniche di Pareto e Ishikawa per gestire i problemi che ormai si sono manifestati, esercitatandovi ad individuare gli altri per intercettarli il prima possibile. In fondo, come diceva un altro grande pensatore cinese, Lao Tzu, anche il più grande dei problemi poteva essere risolto facilmente quando era ancora piccolo…