Le scelte di gestione possono e devono sempre essere sostenute da informazioni ricavate dai dati.
In teoria siamo tutti d’accordo, in pratica un po’ meno.
Quante decisioni prendiamo nella nostra vita professionale e personale basandoci su sensazioni e suggestioni piuttosto che su dati e informazioni? Quante volte cerchiamo di dare giustificazioni ex-post di tipo razionale a scelte che invece abbiamo determinato emotivamente? Lo facciamo tutte le volte che, in barba a statistiche inconfutabili, ci sentiamo più sicuri nel salire su un’automobile invece che su un aereo. Oppure quando ad un SAL di progetto ci dichiariamo confidenti di poter recuperare “quelle 2 settimane di ritardo” sul piano di lavoro “potenziando il team con risorse aggiuntive” (un classico, ndr) quando invece un’analisi appena approfondita dei KPI di tempi e costi con il metodo Earned Value ci darebbe come previsione più probabile un ulteriore slittamento di una settimana sui tempi di consegna.
Quindi lasciatemi ripetere, una volta di più, il mantra del Project Manager Data-driven: dovete prima definire le metriche che vi interessa tenere sotto osservazione, poi avere un efficiente sistema di raccolta dei dati di progetto, quindi produrre informazioni attraverso elaborazioni analitiche dei dati (Project Management Analytics) e infine utilizzare tali informazioni per prendere decisioni come Project Manager realmente informati sui fatti.
L’applicazione di tecniche di machine e deep learning potrà presto darvi supporto attraverso algoritmi di Intelligenza Artificiale, che potranno prendere decisioni di gestione in vostra vece o anche semplicemente suggerirvi degli specifici course of action.
In realtà, tutta questa enfasi sulla raccolta di dati di progetto granulari e strutturati (work performance information) e la spinta ad automatizzare almeno parzialmente le decisioni con sistemi di regole o bot di Intelligenza Artificiale hanno un solo scopo: liberare parte del vostro tempo per permettervi di concentrarvi su task non ripetitivi e difficilmente automatizzabili, in particolare la comunicazione con gli stakeholder, nei vari canali con cui ha luogo.
Secondo il PMBOK 5th Edition (Project Management Body of Kowledge, PMI) un Project Manager impegna fino al 90% del suo tempo comunicando con gli stakeholder e di questo fino al 50% per comunicare con il team. Da ciò si traggono due conseguenze:
-
alla gestione degli aspetti normalmente ritenuti core di qualsiasi progetto (vincolo triplo: scope, time, cost) il Project Manager dedica appena il 10% della sua giornata lavorativa
-
la gran parte del contenuto informativo prodotto da un progetto è costituito da dati e informazioni non strutturati e una fetta consistente di questi, quella relativa alle conversazioni de visu, non viene nemmeno tracciata (tranne i verbali prodotti durante le riunioni ufficiali).
Quante decisioni di progetto vengono quindi prese sulla base di ciò che sopravvive come tradizione orale nella memoria degli stakeholder? Molte. Probabilmente la maggior parte.
Sono sempre i dati e le informazioni che guidano le decisioni, ma dobbiamo lasciare il recinto sicuro dei dati strutturati, e quindi facilmente trattabili anche da macchine e algoritmi, per abbracciare un concetto di data-driven open minded, includendo nel perimetro tutti i dati e le informazioni disponibili senza alcuna preclusione, anche quelli pseudo o non strutturati e frammentari.
Social Project Management
La schiacciante preponderanza degli stream vocali e testuali non strutturati in un progetto è la logica conseguenza di una evoluzione del Project Management determinata da due fattori fondamentali di cambiamento.
Il primo fattore è la delocalizzazione delle attività. I team di progetto sono sempre più virtuali, distribuiti sul territorio e spesso operanti in mobilità. Ciò da un lato tende a far aumentare la componente “verbale” dei flussi di comunicazione, ossia quella basata sullo scambio di conversazioni e testi, sia asincrono (email, blog e forum di discussione, note audio tramite app di messaggistica come Telegram o Whatsapp) che sincrono (call audio e video, sistemi di chat). Dall’altro rende indispensabile l’utilizzo di piattaforme software di tipo collaborativo, per fornire ai membri del team un unico punto di accesso alle informazioni e alle conversazioni di progetto.
Il secondo fattore, che origina dalla crescente adozione di metodi e tecniche di Agile Project Management, è una profonda modifica delle caratteristiche del team di lavoro, in particolare del ruolo del Project Manager. Egli resta sempre il responsabile ultimo dei risultati e del raggiungimento degli obiettivi, ma le attività di gestione sono sempre più partecipate e condivise, la struttura del team è piatta e lo stile di management assume i connotati della cosiddetta servant leadership. L’Agile Project Manager più che un capo gerarchico è un facilitatore che rimuove ostacoli e impedimenti, permettendo ad un team di professionisti con competenze trasversali e in parte sovrapponibili, di auto-organizzarsi nella gestione operativa dei task di progetto.
I metodi e le tecniche agili enfatizzano la comunicazione informale e “poco o non strutturata”, moltiplicando i momenti di confronto e di coinvolgimento attivo degli stakeholder attraverso l’uso di strumenti a bassa tecnologia e ad alta visibilità.
Nel mondo tradizionale la vista day-by-day dello stato del progetto si trova all’interno di un file MS Project sul PC del Project Manager e nelle slide che periodicamente vengono prodotte per le riunioni di SAL (Stato Avanzamentoo Lavori). Nel mondo agile un kanban board, come quello mostrato in figura su un cartellone di 1 metro per 2 attaccato al muro o sui pannelli dell’open space, funge da information radiator, mostrando in maniera immediata a chiunque passi di lì cosa è stato fatto, cosa è in lavorazione, cosa deve essere ancora iniziato e cosa è completato, semplicemente spostando dei post-it.
Laddove, per effetto della delocalizzazione e della virtualizzazione del team, i partecipanti al progetto non siano tutti nello stesso luogo fisico, il kanban può essere di tipo digitale e numerose sono le piattaforme software, quasi tutte cloud based, in grado di fornire oggi ambienti e viste collaborative di questo tipo.
In definitiva, un team di progetto è sempre più assimilabile ad una community a cui possono applicarsi strumenti e paradigmi tipici delle reti sociali, per arrivare a definire una nuova modalità di gestione del progetto: il Social Project Management.
Le nuove piattaforme software a supporto del Project Management si stanno già evolvendo in questa direzione, mutuando dai social network nuovi paradigmi di interfaccia. Nei tool di Project Management tradizionali la vista principale di progetto è centrata sulle attività e la loro schedulazione (WBS + diagramma di Gantt).
In un tool di Social Project Management la vista principale è una dashboard sintetica che mostra lo stato di salute del progetto attraverso pochi indicatori essenziali (es. i tradizionali CPI e SPI calcolati con il metodo Earned Value o magari CFD e burndown-chart in contesti di gestione agile) e dove l’elemento centrale è un feed che raccoglie e traccia tutti gli tutti gli stream vocali e testuali prodotti dal progetto, eventualmente visibile in maniera controllata anche ad altri stakeholder.
Lo scopo è rendere esplicita e visibile gran parte di quei flussi di comunicazione non strutturati a cui ogni Project Manager dedica gran parte delle sue energie e del suo tempo.
Quindi, la view principale di progetto più o meno come una pagina Facebook? Perché no? Però non ditelo a quelle aziende che vedono ancora i social network solo come passatempo time-wasting per dipendenti annoiati e non ne hanno ancora esplorato appieno le potenzialità di business.
È ormai acclarato che la collaborazione con strumenti che mutuano ambienti e modalità di interazione dalle piattaforme social sia di maggiore ispirazione per chi lavora su un progetto, Project Manager incluso, che compilare pianificazioni con fogli Excel o con un qualsiasi editor di diagrammi di Gantt.
In prospettiva poi, l’applicazione a questo feed di progetto di algoritmi e tecniche di machine learning e data mining potrebbe renderlo molto più che un semplice log delle conversazioni e delle attività, bensì una sorta di knowledge base costantemente aggiornata a supporto delle decisioni, in affiancamento alle work performance information strutturate.
Per concludere…
I dati di progetto strutturati, opportunamente elaborati, forniscono una base indispensabile per il supporto alle decisioni. È però necessario ragionare in un’ottica di data-driven open minded, includendo anche informazioni e contenuti non strutturati, derivanti dai flussi di comunicazione tra gli stakeholder a cui il Project Manager dedica fino al 90% del suo tempo.
La moderna gestione di progetto, sempre più partecipativa e collaborativa grazie alla diffusione degli approcci agili, in aggiunta alle spinte di delocalizzazione e virtualizzazione dei team di lavoro, determina la moltiplicazione dei momenti di confronto e di coinvolgimento attivo degli stakeholder.
Le decisioni di progetto devono continuare a basarsi sui dati, ma questi non possono essere più limitati al contenuto di una WBS o di un diagramma di Gantt. Devono piuttosto includere e considerare tutti i feed e gli stream testuali e vocali prodotti dal progetto, secondo un paradigma di Social Project Management. Ciò comporta una progressiva evoluzione degli strumenti software di supporto, che in futuro saranno sempre più simili a vere e proprie piattaforme social di progetto, piuttosto che ad applicazioni di mero controllo di attività, tempi e costi.
Marco Caressa