Secondo articolo della serie e mi getto subito in un argomento complicato e controverso: la gestione dei progetti (o project management, per gli anglofili).
Siamo partiti nell’articolo precedente dalla constatazione che viviamo nell‘epoca del caos, cioè in quell’epoca in cui – dopo aver affrontato con successo i problemi semplici – abbiamo deciso di affrontare con gli stessi strumenti i problemi caotici (tecnicamente caotici). Così facendo però ci siamo complicati la vita. Oggi parliamo della gestione progetti che è ciò su cui, forse più di ogni altra cosa, si incastra l’organizzazione aziendale.
La gestione dei processi, in azienda, è di solito sotto un ragionevole controllo. Abbiamo mappature, flow chart, indicatori, process owner e altri strumenti di gestione e monitoraggio. Ma quegli stessi strumenti falliscono, spesso, applicati ai progetti. Perché?
Cominciamo con una metafora che mi sta molto a cuore: il processo è come un viaggio da Udine a Milano. Un navigatore mi sa dire con ragionevole precisione quanto tempo impiegherò ad arrivare e che strada devo fare, aggiorna la stima in tempo reale e, se è bravo, mi segnala anche i problemi e le code che incontrerò. Questo perché milioni di persone hanno fatto questa stessa strada prima di me.
Un progetto, invece, è come il reggimento di Custer che deve scovare i Sioux sulle Black Hills. Non è chiaro dove l’obiettivo si trovi (e si sposta continuamente), la strada non è nota e non ci sono cartine affidabili della zona. Gli scout vanno in avanscoperta, trovano tracce, seguono una falsa pista e poi tornano sui loro passi. Una colonna di fumo all’orizzonte rende necessaria una riunione del team di comando che modifica radicalmente quanto ipotizzato fino a quel momento.
In sintesi: un progetto è un incarico con forti caratteri di novità, cerca di raggiungere un obiettivo che non è mai stato raggiunto prima (anche se possono esserci stati progetti analoghi in passato) e pertanto è per definizione non integralmente prevedibile.
Abitualmente, per contro, la nostra “mania del controllo” prevede che noi strutturiamo dei documenti di progetto che raccontano per filo e per segno quello che si andrà a fare, suddivide le attività in particelle (che vengono stimate al minuto) e raduna tutto quanto finora detto in un GANTT. Faccio outing: per me il GANTT è il male. Lo dico con l’enfasi provocatoria di un articolo e lo dico nonostante sappia che professionisti che stimo profondamente saranno in agguerrito disaccordo con me.
Quali sono le conseguenze di questa progettazione ipertrofica? Molteplici e nefaste:
- innamorarsi del documento redatto con tanto sforzo; se abbiamo passato tanto tempo e investito tanto nella redazione di questa pianificazione iniziale, saremo molto restii a cambiarla in corso d’opera, anche se la situazione mutata lo suggerisce. Questo è tanto più vero quanto più faticoso è stato trovare un compromesso iniziale tra punti di vista diversi: rimettere in discussione un documento considerato “condiviso” e “definitivo” può essere così complicato da non essere perseguibile
- inserimento del pilota automatico; chi opera nel progetto si sente l’autorizzato a procedere per la strada tracciata; a seconda di quanto è ampio e sparso il team, questo può voler dire che passeranno mesi prima del momento in cui ci si accorge che attività non prioritarie sono state portate avanti solo perché non problematiche
- il budget e il tempo fissati non saranno mai rispettati; la prima attività che “deraglia” (e qualcuna lo farà) spinge in avanti l’intero piano di lavoro (e con esso il budget)
- anche ammettendo per un istante (e vorrei vederlo succedere almeno una volta) che il project manager abbia la flessibilità necessaria a cambiare le carte in tavola ogni volta che serve, a portarsi dietro tutto il team in una attività condivisa – e farlo rispettando budget e tempi – quando questo accadrà le attività effettivamente svolte avranno poco o punto a che fare con la pianificazione iniziale; quindi la cosa che dobbiamo sperare ardentemente è che tutto il tempo speso a iperpianificare sia stato sprecato!
Ora: non sto proponendo di partire alla ventura senza strumenti di pianificazione e controllo del progetto. Sto solo proponendo di abbandonare la speranza di sapere cosa ne verrà fuori e accogliere l’imprevedibilità del mondo reale. Liberarci dai vincoli autoimposti ci permette di gestire un progetto in modo efficace.
Prendiamo come esempio la Ricerca e Sviluppo: questa area aziendale è solitamente invisa alla struttura aziendale perché non governabile e non controllabile. Le aziende in cui funziona bene sono quelle in cui questo ufficio è definito “vulcanico”, che vuol dire che è tollerato solo perché (e finché) raggiunge risultati. Ciò che non si capisce, spesso, è che l’imprevedibile vulcanicità è prerequisito necessario all’innovazione e non effetto collaterale.
Altro esempio eclatante: lo sviluppo software. Il modello waterfall (lett. a cascata), teorizzato negli anni ’70, è paradigmatico: analisi dei requisiti, progetto, sviluppo, collaudo, manutenzione. Questo modello è stato ampiamente sostituito a partire dagli anni ’90. Ma a tutt’oggi molte software house hanno ancora difficoltà a gestire i singoli progetti. Non parliamo poi delle aziende che fanno altro di mestiere (tipicamente macchine o servizi) e che hanno un processo interno di sviluppo software completamente alieno alle competenze della direzione e alla cultura aziendale. Il rischio di avere una “scheggia impazzita” nella struttura aziendale è così alto da meritarsi un articolo apposta.
Ma quali caratteristiche deve avere un sistema di gestione progetti per poter gestire la complessità? Senza voler dare ricette preconfezionate vi racconto cosa cerco io in un sistema di Project Management. In un articolo successivo ne analizzeremo uno in particolare (Scrum, appartenente alla “famiglia” delle Metodologie Agili).
- deve avere degli obiettivi dinamici, rivedibili in ogni istante a seconda delle mutate condizioni esterne e dei problemi e delle opportunità che nascono durante la strada
- deve avere budget e tempi ben definiti. All’interno di questi si devono rivedere gli obiettivi volta per volta ma a scadenza di budget e tempo si deve consegnare qualcosa di utilizzabile (magari molto diverso da quanto ipotizzato inizialmente)
- deve avere un meccanismo di fast failure, cioè una modalità ben scandita per dichiarare chiuso il progetto anzitempo se si prospetta inaccettabile
- deve avere un team autonomo, con forte delega, con interazione densa (cioè che discute molto spesso dell’andamento del progetto). Il team deve comprendere tutti gli attori (dal cliente agli operativi) perché tutti hanno competenze e interesse nel progetto e devono poter dire la loro
Nessuno mai ci potrà assicurare il successo di un progetto. Ma con i giusti strumenti possiamo essere in grado di ricavarne valore o almeno di farci poco male nel tentativo. Nell’epoca del caos è già un’ottima notizia!
Seguici su