Un aspetto critico è dato dalla gestione delle comunicazioni interne ed esterne. L’elevata quantità di fonti informative rende difficile raccogliere i dati che servono
Il 20 settembre 1519 cinque navi partivano da Cadice facendo vela verso sud-ovest. L’equipaggio era composto da 235 persone; il comandante della spedizione era un uomo di 38 anni, non bello di aspetto, claudicante, di origine portoghese, anche se la flotta batteva bandiera spagnola. Il suo nome era Fernão Magalhaes, meglio conosciuto come Magellano. Obiettivo della missione: trovare e percorrere il passaggio verso l’Asia navigando verso Ovest, cioè senza circumnavigare l’Africa, e tornare indietro.
Le cose andarono però in modo molto differente. Per una incredibile serie di circostanze, infatti, dopo aver percorso quello che avrebbe preso il nome di Stretto di Magellano, le navi seguitarono a veleggiare verso ovest invece di tornare indietro.
Al termine del viaggio, durato 2 anni, 11 mesi e 17 giorni, la spedizione aveva provato ciò che molti intuivano, ma che nessuno era riuscito fino ad allora a dimostrare, cioè che la Terra è sferica e può essere circumnavigata.
A tornare indietro furono in 18 (lo stesso comandante perse la vita nel corso del viaggio) dopo innumerevoli avventure, un ammutinamento, fame, sete, scontri a fuoco con gli indigeni. Ciò nonostante, le spezie scaricate dall’unica nave superstite bastarono a ripagare i costi della spedizione e a far realizzare un cospicuo guadagno.
All’inizio del viaggio, insomma, l’obiettivo era chiaro, anche se nessuno sapeva se fosse realmente raggiungibile. Strada facendo esso si rivelò essere un “falso” obiettivo, mentre la meta reale divenne banalmente quella di tornare a casa. Nessuno, però, sapeva né conosceva i tempi, il costo umano ed economico. In breve, nessuno avrebbe difficoltà a definire l’impresa di Magellano un progetto “complesso”.
Una definizione di complessità
Cosa significa complessità in un progetto It? E perché è importante gestirla? In termini organizzativi, è determinata da un’elevata quota di elementi coinvolti, sicché il numero di interazioni tra le varie parti è esponenzialmente più alto rispetto a un sistema più semplice. Un esempio elementare è dato dal cervello umano, che pur essendo costituito essenzialmente da due soli elementi, i neuroni e le sinapsi, è caratterizzato da una impressionante complessità rispetto ad altri organi ben più complicati dal punto di vista fisiologico.
La complessità intesa in questo senso sottende quindi l’incapacità di acquisire e, per così dire, “digerire” un numero troppo elevato di informazioni. Viene alla mente il concetto di razionalità limitata, elaborato da Herbert Simon (nobel per l’economia nel 1978) secondo il quale la razionalità di un individuo è limitata dalle informazioni in suo possesso, dalla finitezza delle sue capacità razionali, nonché dallo scarso tempo a disposizione per prendere delle decisioni. Ciò fa sì che il decision-maker non abbia in genere le capacità per arrivare alla soluzione ottimale, ma debba semplificare le alternative a disposizione, accontentandosi di una “soddisfacente”.
Nel campo del project management, se accettiamo la definizione di progetto complesso come uno in cui viene gestito un elevato numero di informazioni, si corre però il rischio che tutti i progetti diventino complessi. Come ogni It manager sa, infatti, è difficile definire un progetto non complesso, anche adottando un criterio quantitativo (ad esempio il numero di attori coinvolti, quello di interazioni, di informazioni presenti e così via). Anche considerando un criterio quali-quantitativo, ad esempio la percentuale di raggiungimento degli obiettivi, oppure il grado di copertura dei requisiti, non è per niente facile riscontrare tassi del 100%, segno che di progetti semplici ce n’è in giro davvero pochi.
Ma allora, se criteri quantitativi e qualitativi non bastano a definire la complessità di un progetto It, esiste un razionale che non sia soltanto convenzionale per comprenderla?
Viene in aiuto la teoria della complessità. Secondo quest’ultima, i sistemi complessi non sono caratterizzati soltanto da un numero elevato di elementi; questi ultimi devono essere eterogenei e legati da connessioni non lineari. In particolare, devono adattarsi e cambiare in seguito all’esperienza, proprio come gli organismi viventi, dotati di capacità evolutive.
La complessità così definita può essere una condizione oggettiva del progetto (ad esempio laddove esistano dei vincoli tecnologici o temporali particolarmente forti) oppure una scelta, come nel caso in cui l’organizzazione decida di adottare un approccio particolare alla gestione dei progetti. La definizione di specifiche metodologie e strumenti è oggetto di attenzione e studio da parte del Project Management Institute, organo rappresentativo a livello mondiale ed ente certificatore. Il chapter italiano dell’organizzazione ha creato un gruppo di lavoro, composto da professionisti operanti in diversi settori, con il compito di studiare l’argomento: i risultati finora conseguiti sono stati presentati in un workshop tenutosi di recentei.
Un primo punto fermo è che avere a che fare con progetti complessi non è solo una condizione esogena, dettata dall’esterno, ma vuol dire adottare una certa impostazione mentale. Secondo l’Istituto, infatti, la metodologia (tradizionale) del project management è fondamentalmente basata su un approccio lineare. A partire dalle informazioni oggi disponibili è possibile prevedere cosa accadrà in futuro. Si possono fare proiezioni sul futuro estrapolando gli andamenti di grandezze significative. Ma l’esperienza pratica dimostra che la natura del progetto, per come è vissuta quotidianamente da chi vi è coinvolto, non è rappresentabile attraverso il modello lineare. In sintesi, l’approccio in questione consiste nella capacità del project manager di rinunciare a prevedere con esattezza le evoluzioni del progetto, gestendo il “caos” che ne deriva.
Quali strumenti utilizzare
Se gestire un progetto complesso significa sviluppare un approccio particolare, occorre assicurarsi che le azioni operative e gli strumenti utilizzati siano in linea. Questo non significa necessariamente che i “ferri del mestiere” tradizionali siano da abbandonare. Occorre, invece, adattarli alla nuova realtà. Per fare un esempio riportato dal Project Management Institute: la Work breakdown structure (l’elenco di tutte le attività di un progetto) può e deve essere ridefinita istante dopo istante. Quella iniziale è solo legata al tempo zero ed è in continua ridefinizione. Non bisogna pianificare tutte le azioni, ma accettare di non conoscere completamente i fattori influenzanti.
Le interrelazioni e i legami tra le diverse attività di un progetto ne costituiscono la sintassi, ossia disegnano il cammino per raggiungerne gli obiettivi, esattamente come diverse parole formano il senso di una frase. Ma la Wbs non è più una variabile indipendente, diventa essa stessa dipendente dal progetto, dal mutare del contesto e dalla sua maggiore o minore rispondenza agli obiettivi.
Un altro aspetto critico è rappresentato dalla gestione delle comunicazioni, interne ed esterne. L’elevata numerosità di fonti informative rende difficile raccogliere i dati rilevanti nel momento in cui servono e portarli all’attenzione dei soggetti che ne hanno bisogno. A questo scopo, per permettere a tutti i partecipanti di interagire, è possibile introdurre strumenti innovativi, come un Wiki di progetto all’interno del quale aggiornare informazioni inerenti i documenti di analisi (che rispetto ai progetti tradizionali avranno un più basso grado di formalizzazione, ma una maggiore immediatezza di fronte al cambiamento dei requisiti), l’evidenza dei punti aperti (in modo da permettere a tutti gli attori di condividere le issue del progetto e venire informati tempestivamente della loro chiusura) e la pianificazione di progetto. All’interno del piano, un posto particolare sarà occupato dalle milestone esterne (ad esempio l’integrazione con altri sistemi, la consegna di hardware o software e così via), che sono critiche per poter effettuare determinate attività. Quelle interne, viceversa, non devono essere obbligatoriamente evidenziate, in quanto soggette a cambiamenti e ripianificazioni.
Bisogna anche tenere in considerazione ulteriori aspetti, tra cui lo staffing. In alcuni progetti, infatti, i tempi non consentono di effettuare training on the job o altre forme di apprendimento nel corso dell’attività; le risorse impegnate, dunque, devono essere già formate e dotate delle competenze, spesso specialistiche, richieste. Pure le attività di test sono essenziali per un It manager per garantire la qualità; in genere più sono condotte in modo strutturato e approfondito, più permettono di raggiungere appieno gli obiettivi. Nel caso dei progetti complessi, però, l’approccio è differente; avendo a che fare con fasi ipercollassate e tempi di delivery molto sfidanti, oltre che con Wbs mai chiuse al 100%, il project manager si trova al centro di un dilemma tra rapidità ed essenzialità da un lato, e completezza e qualità dell’output dall’altro.
Si rende quanto mai necessario, quindi, adottare strumenti che facilitino l’esecuzione dei test e permettano di identificare con rapidità chi deve risolvere le eventuali anomalie, saltando i passaggi e le escalation tipiche dei progetti It. È vitale che le informazioni rilevanti arrivino con immediatezza a chi ne ha bisogno (in questo caso lo sviluppatore) il quale, una volta risolto il problema, deve comunicare la chiusura dell’anomalia in tempo reale a chi effettua i test.
La complessità richiede
un cambiamento di paradigma
Se si fa una ricerca su Google si nota che a “progetti complessi” vengono collegati indistintamente i progetti che presentano un generico fattore di complessità, che tutti i progetti, per definizione, possiedono. Ma il project management dei progetti complessi si configura in primo luogo come approccio, cioè come un insieme di metodologie e strumenti che permettono di raggiungere gli obiettivi a prescindere dalla loro complessità e soprattutto dal grado di impredicibilità dell’ambiente circostante. Questo approccio rappresenta, in seno al project management, uno slittamento di paradigma, nel senso descritto da Thomas Kuhn (storico della scienza e filosofo statunitense): un determinato paradigma scientifico si forma e si rafforza per un determinato periodo di tempo, durante il quale viene accettato comunemente. Si verificano, però, nel tempo delle rivoluzioni scientifiche, conseguenza di una crisi determinata dalla falsificazione del paradigma fino ad allora accettato. Quando ciò si verifica, si apre una nuova fase, in cui si creano paradigmi diversi che non nascono dai risultati raggiunti dalla teoria precedente (come un naturale proseguimento del progresso scientifico), ma dall’abbandono di quello dominante.
Il project manager si trova, dunque, nella situazione di dover riuscire in un’impresa impossibile, nel senso di portare a termine la sua missione senza sapere bene cosa troverà sulla rotta e, anzi, di essere capace di inventare la rotta strada facendo.
