Data Driven Project Management: come fare?

Cosa ti è utile sapere per leggere questo articolo

Parliamo di Project Management, che riguarda tutti, visto che la vita di ciascuno di noi è piena di progetti. Per comprendere questo articolo non è necessario essere capi progetto certificati con 20 anni di esperienza (sperando tuttavia che anche costoro lo trovino utile) ma solo conoscere o avere sperimentato pochi concetti fondamentali. Quindi sapere che un progetto è uno sforzo coordinato per realizzare qualcosa (prodotto o servizio) che prima non c’era con un dato livello di qualità. Che ciò che viene prodotto si concretizza attraverso dei deliverable, tangibili (es. un palazzo, una linea ferroviaria, un prototipo di automobile…) o intangibili (es. software, documentazione digitale…). Che ogni progetto ha una data di inizio e una di fine. Che ogni progetto ha un responsabile del raggiungimento dei suoi obiettivi, che si chiama Project Manager. Che il Project Management, come dice il nome, è la disciplina che raccoglie contributi, idee, tecniche, strumenti e buone pratiche per gestire al meglio qualsiasi tipo di progetto, dall’invio del primo uomo su Marte al nuovo videogioco per il vostro smartphone.

“If we have data, let’s look at data. If all we have are opinions, let’s go with mine.”
(Jim Barksdale, past Netscape CEO) 

Farsi guidare da informazioni ricavate da dati oggettivi e misurabili è un buon modo di prendere decisioni. L’azione manageriale è un susseguirsi continuo di scelte e gestire progetti significa decidere, in ogni momento della giornata, se includere un nuovo requisito, se adottare un approccio di progettazione, se ricorrere a risorse esterne piuttosto che provare a fare tutto con le proprie, e così via. Tuttavia, raccogliere dati sulle attività di progetto è solo un primo importante passo, necessario ma non sufficiente, per prendere buone decisioni. I dati vanno analizzati, discussi e valutati per produrre informazioni utili. Ma tutto ciò ancora non basta per affermare che la gestione di progetto sia realmente data-driven se poi, invece di attuare “automaticamente” azioni già decise a priori in funzione delle informazioni elaborate, le scelte devono essere sempre e solo il frutto di ulteriori valutazioni contingenti. Quindi, dalla pianificazione alle stime e al controllo di avanzamento, come potete favorire all’interno della vostra organizzazione un approccio di Project Management realmente data-driven?

Le nostre decisioni sono data-driven?

No. Quasi certamente conoscete almeno una persona che ha paura a prendere l’aereo e nessuna preoccupata di salire in automobile, nonostante tutte le statistiche attualmente disponibili (cioè informazioni elaborate a partire da dati misurabili) mostrino come l’aereo sia un mezzo più sicuro. Nel processo decisionale l’aspetto emozionale e di percezione soggettiva gioca sempre un ruolo determinante. Vale per le persone come per i team e le organizzazioni.

Un’azienda può decidere di non investire in un progetto per la realizzazione di un nuovo prodotto pur avendone le possibilità tecniche, finanziarie e commerciali e nonostante analisi e report mostrino una richiesta da parte del mercato. Perché mai? Perché anche le aziende decidono “di pancia” o in base a consuetudini. Se il business deriva storicamente da attività “su commessa”, l’azienda sarà riluttante ad impegnare costi e risorse se non a fronte di un ordine specifico del cliente, limitando così la propensione ad innovare e rischiando di perdere opportunità che l’analisi dei dati a disposizione suggerirebbe invece di cogliere.

Quando gestite un progetto non c’è niente di diverso. Come Project Manager terrete certamente conto di quelle che il  PMBOK chiama work performance informations (ossia le misure di avanzamento del lavoro svolto), ma sarete inevitabilmente influenzati dalle vostre percezioni soggettive ed esperienze passate, a cui vi aggrapperete per similitudine, che vi porteranno ad agire “a sensazione” più spesso di quanto non pensiate. Le decisioni nel Project Management dovrebbero invece essere basate su una solida base di dati quantitativi e misurazioni oggettive dei fatti, a cui aggiungere solo in seconda battuta il vostro contributo di esperienza ed intuito applicati allo specifico contesto.

Utilizzo dei dati: dal PM data-informed al PM data-driven

L’evoluzione verso un approccio data-driven al Project Management è graduale e passa attraverso fasi di maturità intermedie. L’utilizzo dei dati a supporto delle decisioni prevede in linea generale tre step:

1. la raccolta di dati “grezzi”, relativi ad un insieme di metriche di interesse, la cui misurazione sia in grado di rappresentare se e come si stiano raggiungendo gli obiettivi di progetto
2. l’elaborazione dei dati per ottenere informazioni (filtrare, aggregare, sintetizzare, presentare) e la loro condivisione con gli attori del processo decisionale
3. l’utilizzo di queste informazioni per prendere decisioni.

Sin qui nessuna innovazione, niente più che semplice buon senso e nessuna necessità, per ora, di tirare in mezzo framework di BI/Big Data o soluzioni tecniche roboanti. Anzi, potreste obiettare che da sempre i Project Manager raccolgono dati ed elaborano informazioni sull’andamento dei propri progetti per capire come procedere, utilizzando diversi strumenti per rilevare, ad esempio, le effettive date di inizio e fine delle attività rispetto a quelle previste, per rendicontare i costi e confrontarli con quelli preventivati, per valutare la percentuale di completamento dei deliverable di progetto, per misurare la qualità del processo e del prodotto e confrontarli con quelli attesi, e così via.

Tuttavia, anche in aziende con una cultura progettuale radicata, professionisti certificati e processi strutturati di lavoro, si tende a confondere una gestione data-driven con una semplicemente data-informed.

La differenza sta nel modo con cui viene eseguito lo step 3. Una  volta raccolte le work performance informations (step 1) ed elaborate le informazioni (step 2):

1. se vi fermate e convocate sempre una bella riunione per decidere l’azione da intraprendere, state gestendo il progetto in modalità data-informed
2. se invece, in funzione delle informazioni raccolte e di un insieme di “regole” che avete definito a priori, vengono automaticamente avviate specifiche azioni di gestione, allora state gestendo il progetto in modalità data-driven.

Per essere più chiari, in un progetto data-driven c’è una strategia di azione in funzione dei dati disponibili, espressa da “regole” che implementano decisioni già prese.

Facciamo un esempio e immaginiamo il progetto di realizzazione di un sistema software, dove dovete decidere se e quando autorizzare il rilascio in ambiente di collaudo in funzione del numero e della tipologia di bug attualmente riscontrati nel codice. Con una gestione data-informed il rilascio in ambiente di collaudo sarà subordinato ad una decisione successiva alla misurazione dei bug. Con una gestione data-driven il rilascio in ambiente di collaudo (a parità di altre condizioni) verrà automaticamente autorizzato, e magari anche effettuato, quando il numero di bug rilevati scende al di sotto di determinati valori di soglia, definiti all’inizio per ciascuna tipologia di errore. Valori che naturalmente possono essere parametrici (es. numero massimo consentito di difetti, per ciascuna tipologia di bug, che danno “semaforo verde” al rilascio, modificabili tramite un opportuno cruscotto di configurazione).

Lo scenario descritto ha due vantaggi:

1. la rapida reazione al cambiamento, dovuta all’applicazione di una decisione già presa a priori
2. la maggiore efficacia dell’azione del Project Manager che, svincolato da dettagli operativi, può concentrarsi meglio sulla visione d’insieme del progetto da gestire.

E prima che vi vengano dei dubbi sul fatto che, come Project Manager, rischiate di essere esautorati dagli automatismi decisionali, tranquillizzatevi: si tratta solo di guadagnare in efficienza. Siete sempre voi che prendete le decisioni, la differenza è che lo fate, ove possibile, anticipatamente, senza dover reinventare ogni volta una valutazione per lo stesso scenario.

Come sempre in teoria funziona tutto, ma in pratica quali sono le fasi di un’ipotetica roadmap, come dicono quelli bravi, per rendere realmente data-driven il vostro approccio al Project Management?

FASE 1 – Scelta delle metriche di misura del progetto (aka, cosa vi interessa misurare) 

Tra le centinaia di potenziali metriche utilizzabili nella gestione di progetti, i criteri di scelta sono essenzialmente due:

1. orientatevi su metriche che abbiano un solido legame con gli obiettivi di progetto
2. non reinventate la ruota e date sempre la precedenza a metriche consolidate e “da letteratura” (qualcun altro prima di noi ha sicuramente affrontato e risolto brillantemente i nostri problemi).

Non ci sono regole fisse, ma un elenco “minimo” di metriche da considerare può essere il seguente.

1 – Metriche di predicibilità, servono a misurare gli scostamenti tra l’andamento effettivo di progetto e quello pianificato (baseline). Su tutte quelle previste dal metodo dell’Earned Value, che consentono un controllo integrato del progetto affiancando al tracciamento dei tempi una valutazione periodica dello stato di avanzamento “reale” dei deliverable e dei costi effettivamente sostenuti.

In particolare:

• l’indice di performance dei tempi (SPI, Schedule Performance Index) che indica quanto velocemente i vostri deliverable “progrediscono” in termini di valore rispetto a quanto pianificato. Valori inferiori ad 1 (o al 100%, se la misura è espressa percentualmente) indicano una tendenza a consegnare in ritardo quanto previsto. Valori superiori ad 1 indicano una tendenza a consegnare in anticipo. Un valore pari a 1 indica una tendenza a consegnare nel rispetto dei tempi previsti.
• l’indice di performance dei costi (CPI, Cost Performance Index) che indica quanti euro effettivamente state spendendo per ogni euro che avevate stimato di spendere per realizzare quanto previsto. Valori inferiori ad 1 (o al 100%, se la misura è espressa percentualmente) indicano una tendenza a spendere più di quanto previsto. Valori superiori ad 1 indicano la tendenza a spendere meno di quanto previsto. Un valore pari a 1 indica una tendenza a spendere correttamente il budget messo in preventivo.

Gli indici di performance sono metriche derivate a partire da misure semplici, come la percentuale di avanzamento fisico dei deliverable previsti e i costi effettivamente sostenuti sulle attività di progetto.

2 – Metriche di qualità, servono a rilevare difetti o non conformità a requisiti. In particolare:

• Numero di difetti rilevati sui deliverable di progetto, raggruppati in base allo stato (es. aperto, rinviato, chiuso, fix disponibile, etc.) e loro andamento in funzione del tempo
• Densità dei difetti, data dal rapporto tra numero dei difetti e dimensioni del progetto (es. nel caso di un’applicazione software può essere il numero di bug per function point). Utile per fare confronti tra progetti diversi, i difetti possono essere “pesati” in relazione alla loro gravità o priorità di risoluzione (es. differenza tra difetti che impediscono il funzionamento di un sistema e difetti che determinano solo un degrado delle prestazioni).

3 – Metriche di responsività, servono a misurare la velocità di risposta e di soluzione dei problemi nei confronti degli stakeholder di progetto, utilizzando sistemi di help desk che aprono un “ticket” in relazione ad un problema o una issue e ne tracciano l’iter di risoluzione. In particolare:

• Età del problema aperto, intervallo di tempo trascorso dall’identificazione di un problema e conseguente apertura di un ticket, combinato con l’età media di tutti i problemi aperti fornisce indicazioni sui tempi di attesa per la risoluzione del problema
• Tasso di risoluzione, numero di problemi/ticket che vengono chiusi in un periodo di riferimento.

Normalmente, anche i sistemi di help desk meno sofisticati mettono a disposizione numerose altre misure utili, come il rapporto tra numero di problemi risolti ed effort/costo impiegato per chiuderli (average turnaround time).

4 – Metriche di efficienza, servono a valutare l’utilizzo delle risorse disponibili (umane e non). In particolare:

• Tasso di utilizzazione delle risorse, come rapporto tra l’effort pianificato e l’effort (es. in giorni/persona) speso sul progetto, ricavato da sistemi di rendicontazione specifici (es. timesheet)

5 – Metriche di produttività, servono a valutare quanto output si riesce a produrre impegnando il tempo di una singola persona o di un team su una particolare attività. Per attività di sviluppo software, alcuni esempi di quantificazione del concetto di output sono:

• funzionalità aggiunte ad un’applicazione
• numero di difetti trovati/risolti
• numero di use case sviluppati/testati
• linee di codice prodotte
• quantità di function point sviluppata per unità di tempo (es. per giorno/persona)

Metriche come l’ultima citata sono particolarmente utili perché basate sulla misura di grandezze (in questo caso il function point) che prescindono dal contesto tecnologico di progetto e sono quindi abbastanza oggettive per consentire comparazioni tra progetti diversi.

FASE 2 – Raccolta dei dati (aka, come effettuerete le misure)

Individuate le metriche, per raccogliere i dati dovete definire il “processo di misura“, che in termini pratici significa decidere:

• quali strumenti di rilevazione e memorizzazione dei dati utilizzerete (es. timesheet per la rendicontazione di giornate di lavoro, sistemi di trouble ticketing per tracciare la difettosità dei deliverable di progetto, …)
• con che frequenza misurerete i dati (es. potreste avere frequenze di rilevazione diverse in funzione del dato, ad esempio potreste misurare mensilmente i dati di rendicontazione del lavoro delle persone e giornalmente la difettosità di quanto realizzato)
• chi sarà il responsabile di ciascuna rilevazione e della elaborazione e presentazione dei risultati (i membri del team di lavoro, il cliente, il Project Manager, …).

Fase 3 – Analisi dei dati (aka, quali informazioni state cercando)

Qui viene la parte più bella e difficile. I dati che avete raccolto sono in gran parte grezzi, numerosi e molto dettagliati. Per ottenere informazioni utili al processo decisionale li dovrete filtrare, aggregare ed elaborare. Tale elaborazione può essere orientata semplicemente alla comprensione della situazione corrente di progetto (analysis) oppure, sempre più di frequente e attraverso l’uso di tecniche e tool statistici, potete indirizzarla all’individuazione di tendenze, pattern e allo sviluppo di modelli predittivi di eventi e comportamenti (data analytics).

Un altro aspetto è quello dell’incertezza: qualsiasi misura numerica di processi e sistemi segue una distribuzione di probabilità determinata dalla natura del processo sottostante. Il Risk Management introduce il tema dell’incertezza nella gestione di progetto e nelle misure relative. I rischi sono eventi incerti con una certa probabilità di verificarsi e impattano su tutti gli aspetti, in particolare di pianificazione. Approcciare data-driven significa in questo caso esprimere le metriche di progettto in termini di “analytic certainty“. Ad esempio, nel comunicare una stima, invece di dire:

“occorrono 3 mesi/persona per realizzare l’attività e completare il deliverable”

dovreste riuscire a dire:

“abbiamo il 95% di probabilità di completare il deliverable con un effort compreso tra 2,5 e 3,5 mesi/persona“.

Contrariamente alla prima impressione, la seconda formulazione è più ricca di informazioni e quindi più utile a dare supporto alle decisioni. Vi dice che potreste anche riuscire a completare il lavoro in meno di 3 mesi (anche se c’è il rischio che possiate metterci di più) e vi dà un misura di attendibilità della valutazione, che nella prima formulazione manca del tutto. Naturalmente sia la percentuale che l’intervallo di variabilità dell’effort non sono il risultato di una stima “a sensazione” (ricordatevi, siete data-driven…) ma l’esito di una elaborazione statistica che applica ai dati raccolti (in questo caso dei dati di stima per la pianificazione di tempi e costi) una distribuzione di probabilità, ad esempio attraverso una simulazione Monte Carlo, da implementare con il vostro foglio elettronico preferito.

Così l’analisi statistica dei dati vi consente di rispondere a domande come queste:

“Qual è la probabilità che il costo di progetto sia entro il budget?”

“Quale costo ci garantisce la probabilità dell’90% di realizzare l’intero progetto?” 

“Qual è la probabilità che una determinata attività finisca entro una certa data?” 

“In quale data abbiamo il 90% di probabilità di avviare una determinata attività?”

“Quale costo ci garantisce la probabilità dell’80% di realizzare un’attività?”

Fase 4 – Supporto alle decisioni (aka, come utilizzare le informazioni ottenute)

Quanto sin qui detto serviva per arrivare al vero obiettivo del Project Management data-driven: l’utilizzo a supporto delle decisioni di informazioni ottenute dall’elaborazione dei dati per attuare, ove possibile, azioni di gestione decise a priori.

L’introduzione di elementi per il triggering di automatismi gestionali è tutt’altro che semplice e va affrontata in modo graduale. L’esempio precedente del rilascio in collaudo dell’applicazione, avviato automaticamente in funzione del livello misurato di difettosità del codice, è una semplificazione ideale. Nella realtà, il numero di bug per tipologia al di sotto di opportune soglie può essere una delle condizioni di rilascio, ma certamente non l’unica. Possono esserci altre condizioni di natura contrattuale (es. verifica di esistenza e completezza di documentazione associata – piano di collaudo, calendario dei test, etc.) o organizzativa (es. formalizzazione attraverso una lettera di accompagnamento firmata da un responsabile, etc.).

Le azioni di Project Management che, in base ai dati, possono essere modellate in anticipo con maggiore facilità sono quelle di comunicazione, per veicolare in modo più rapido e puntuale le informazioni di supporto ad un livello di decisione “strategico”, necessariamente “umano” e non eliminabile.  Il punto di partenza può essere una dashboard, come quella schematizzata in figura, che riassuma tutte le metriche essenziali per misurare lo “stato di salute” del progetto.

La parte superiore viene alimentata applicando il metodo dell’Earned Value (metriche di predicibilità), con gli indicatori di performance che riassumono la situazione attuale del progetto in termini di tempi e costi. Da questi si ricavano gli indicatori di forecast (ETC, Estimate To Complete) che indicano, in base ai dati disponibili, i costi ancora da sostenere e i tempi di lavoro residui per il completamento del progetto. Su queste metriche è abilitato il drill-down, per l’analisi delle misure rispetto a parti di progetto. Cliccando sul valore aggregato è possibile, ad esempio, navigare sulla WBS di progetto, per verificare i valori degli indicatori di performance sino alle unità di lavoro elementari (workpackage).

Ad esempio, un valore di SPC (Schedule Performance Index) pari a 0,9 indica un ritardo delle attività di progetto (in termini di valore prodotto) rispetto a quanto pianificato. Tuttavia, questa informazione, da sola, per quanto utile, non è di reale supporto alla decisione. La performance complessiva rispetto ai tempi è il riflesso di un ritardo “strutturale” sulla maggior parte delle attività o è dovuta ai problemi di un singolo ramo di progetto? Effettuando il drill-down potreste ad esempio verificare che su 10 attività di WBS, otto hanno SPC = 1 e due hanno SPC = 0,5. Ciò consente di decidere rapidamente e con certezza su quali specifiche aree intervenire o acquisire ulteriori informazioni.

Che tipo di decisione anticipata può essere implementata in questo caso? Ad esempio una comunicazione push di messaggi e allarmi multicanale alle figure di responsabilità del progetto o agli owner delle singole attività, quando i valori delle misure di performance indichino problemi di tempi e/o dei costi in specifiche aree di progetto.

La parte inferiore della dashboard riporta misure relative a metriche di qualità, di rischio (score di rischio calcolato per l’intero progetto e navigabile per le singole aree) e di produttività, rispetto alle quali possono essere definite ulteriori “decisioni anticipate”, sia di comunicazione che di attuazione, come nel caso dell’abilitazione al rilascio in collaudo dell’esempio precedente.

Conclusioni

In un progetto data-driven le decisioni del Project Manager sono sempre supportate da informazioni ricavate dai dati attraverso elaborazioni analitiche, sempre più frequentemente di natura statistica. Dove possibile, tali decisioni dovrebbero essere definite in anticipo e modellate tramite insiemi di regole, rivedute periodicamente, per consentire un’attuazione automatica di azioni a supporto della gestione. In questo modo si prendono meno decisioni sul momento, con una serie di vantaggi:

• orientamento verso una migliore qualità delle decisioni, valutate in base a criteri oggettivi
• le decisioni prese anticipatamente possono essere discusse senza l’urgenza di una situazione incombente
• l’esperienza e l’intuito nelle decisioni sono limitati alle situazioni di emergenza
• le situazioni di emergenza diminuiscono e diventano l’eccezione, mentre viene favorita una cultura della pianificazione, volta ad anticipare problemi e scenari di attuazione.

Allora, siete pronti a portare la gestione dei vostri progetti sul terreno dei fattori oggettivi?

Marco Caressa