Per la buona gestione di progetto, il fattore umano è fondamentale. Però viene spesso interpretato in senso riduttivo: bisogna avere un gran bel quoziente intellettivo. In realtà, c‘è molto di più da dire: cerchiamo di mettere a fuoco alcuni aspetti importanti, ma non sempre trattati nell‘ampia letteratura disponibile.

Introduzione

A Chamonix, Dipartimento dell’Alta Savoia, Francia, è possibile ammirare un museo e una mostra fotografica sulla costruzione della Funivia dei Ghiacciai, un progetto di una difficoltà enorme, realizzato alla metà degli anni Cinquanta, nel tratto “impossibile” Rifugio Torino – l’Aiguille du Midi, dall’ingegnere Dino Lora Totino. Ciò che più impressiona sono le fotografie che lo ritraggono al lavoro: sempre direttamente coinvolto con la maestranze, sempre a indicare, sempre a studiare nuove soluzioni.

I concetti di base

L’esempio portato è eloquente, si trattava certamente di un capo carismatico. Ma devono essere tutti così? In tutti i progetti? Andiamo con ordine.

Nella realizzazione di un progetto [1] possiamo distinguere 4 fasi: definizione (initiation), pianificazione (planning), esecuzione (execution), chiusura (closure). I principali vincoli (constraints) che condizionano il progetto sono il contesto, il tempo, il costo.

Chiamiamo committente il soggetto che, dovendo perseguire un obiettivo in un determinato contesto, manifesta un’esigenza chiedendo a un interlocutore di tradurla in un progetto. Quando l’iniziativa è presa da un collegio di persone, il termine anglosassone usato è Steering Committee.

Cosa serve?

Le doti che il Project Manager deve avere possono così schematizzarsi (in ordine alfabetico):

• affidabilità
• apprezzamento dei valori
• autocontrollo
• apertura
• approccio sereno
• capacità di gestire conflitti e crisi
• coraggio
• creatività
• efficienza
• etica
• fermezza
• leadership
• motivazione
• orientamento ai risultati
• realismo

Nei paragrafi che seguono analizziamo nei dettagli queste doti necessarie per il PM, in certi casi combinandone alcune, e mettendo in luce il loro rapporto con aspetti particolari della gestione di progetto.

Autorevolezza

È la traduzione corretta in italiano del termine leadership. L’autorevolezza è una dote naturale, ma è necessario che sia stata coltivata dentro un’educazione, fin da giovane. L’istituzione della famiglia rimane l’alveo principale dove questa dote prende forma.

In un precedente articolo ho fatto, en passant, quest’affermazione: “il PM è un ragioniere”. Questa è l’occasione buona per riprendere la questione. Innanzitutto diciamo che è fondamentale per un PM ottenere la fiducia e la stima delle persone che lavorano al progetto. L’ideale è quando ha la forza, la capacità e il tempo di scendere, almeno in certi momenti, al livello di quei suoi collaboratori che fanno i lavori più umili (nel linguaggio giornalistico si dice talvolta gli “sherpa”, cioè i portatori di attrezzature nelle scalate alpinistiche in Nepal); dovrà ricordare il vecchio adagio: “la parola conduce, l’esempio trascina”.

Ma ci sono dei casi in cui i collaboratori, per loro predisposizione naturale o per aver avutoesperienze negative, sono assolutamente restii a entrare in una dinamica di rapporti umani, pur essendo onesti lavoratori o ottimi tecnici; ancor di più: affermano che questa autorevolezza è una favola per bambini… e non sono pochi. È questo il caso in cui il PM deve essere, più che altro, un ragioniere, nel senso che deve attenersi ai fatti, al prodotto, al tempo impiegato e ai costi. Senza scandalizzarsi.

Motivazione

Quali sono le molle che mettono in moto la mente e il cuore dell’uomo? Il denaro e il potere, potrebbe essere la risposta più facile; e avremmo chiuso il discorso. Forse ce n’è una ancora più forte, che è l’orgoglio. La figura più paradigmatica dell’uomo motivato è stata descritta da Dante, nella sua grandiosa rappresentazione della figura di Ulisse, il quale così arringava il suo equipaggio per spingerlo a superare i limiti allora ritenuti invalicabili (le Colonne d’Ercole):

fatti non foste a viver come bruti / ma per seguir virtute e canoscenza

Chissà, forse Ulisse già usava l’approccio Scrum? Interessanti poi le tesi di Edith Stein, che nel suo corso accademico all’Istituto di Pedagogia scientifica di Munster, nel 1932, affermava che “l’uomo è strutturato come domanda”: in tutto ciò che fa, l’uomo chiede di avere, davanti a se’, ciò che dà senso alla sua esistenza. Per par condicio: e se fosse solo una nevrosi? Di fronte a questi interrogativi, è lo studio della storia quello che ci aiuta di più a capire: per esempio, sappiamo il tipo di motivazione che aveva Cristoforo Colombo o conosciamo la storia di Guglielmo Marconi.

Approccio sereno, autocontrollo

Un approccio sereno serve per trasmettere tranquillità alle squadre, quindi per permetter loro di lavorare meglio. Ma dentro di se’, il Project Manager sarà veramente sereno? È cosa rara. Quando non è la responsabilità, è la paura del flop. Talvolta vengono concentrate su una sola persona responsabilità enormi, solo perche’ a qualcun altro faceva comodo non prenderle in quel momento: lo vediamo accadere spesso anche nel panorama politico. Comunque, non è un male essere preoccupati. L’importante è non eccedere la misura; e, in ogni caso, essere così discreti da non raccontarlo agli altri.

Apertura e creatività

La creatività non coincide con la fantasia, che è una caratteristica molto più abbondante nel mondo. Anche la creatività è una dote naturale, formata e ordinata da una buona educazione. L’educazione dovrebbe portare a guardare il mondo senza preconcetti, a possedere la capacità di meravigliarsi, e a prendere in considerazione tutto, approfondendo poi solo ciò che lo merita. È il concetto di apertura, cavallo di battaglia di Karl Popper [2]. Senza apertura, la creatività non esiste.

Realismo, fermezza

Possiamo chiamare questo argomento “l’altra faccia della luna” rispetto a quanto già detto sull’autorevolezza. La fermezza diventa necessaria quando ci si trova di fronte a collaboratori con un atteggiamento sleale o, peggio, disonesto. Capita che il PM tenti di comprendere, tenda una mano, ma la posizione è sempre la stessa: il collaboratore accusa e scarica sulla struttura dove lavora quelle che sono solo le sue paure, la sua incapacità, la rabbia repressa per ingiustizie subite, a suo dire, nel passato.

Aggiungiamo poi che non tutti i PM possono avere la pazienza di tentare un recupero: talvolta la pazienza è proprio corta, perche’ anche il PM, come tutti, ha i suoi bravi problemi personali. Il PM deve capire quando è il momento di cambiare registro, anche rischiando di disorientare i collaboratori “bravi”. Ci sono dei momenti in cui il buonismo diventa disastroso, e per “disastro” si intende che, durante l’execution, le milestone stabilite nel project plan cominciano a saltare.

Nei corsi di formazione per Project Manager, di solito, lo scenario del progetto che entra in crisi è descritto accuratamente. Ricordo un corso dove l’insegnante mimò la scenetta in cui il team leader si presentava al project manager scusandosi perche’, anche in questo task, non sarebbe riuscito a produrre il deliverable al tempo stabilito. Il PM non lo degnava di uno sguardo, ma continuava a sistemarsi le unghie con una limetta: “Sono affari tuoooi…” cantilenava. Traduzione: “se sgarri anche stavolta, non ci metto niente a chiamare la sorveglianza e a farti accompagnare alla porta”. Nella mia esperienza personale, ho visto gente esclusa dai progetti in maniera molto più gentile, ma ovviamente con risultato finale identico.

Orientamento alla qualità dei risultati

In questa articolo, volutamente, non ho affrontato le problematiche del progetto preceduto da una gara; un argomento che merita una trattazione a se’. Se c’è una gara, i livelli qualitativi sono ben identificati dal capitolato. Se non c’è un capitolato, ci sarà comunque la lista dei requisiti. Possiamo continuare a parlare prescindendo da ciò.

Gli obiettivi qualitativi di progetto e dei vari deliverables non devono essere perseguiti genericamente, ma devono essere attentamente pianificati. È controproducente cercare una qualità superiore a quella che il cliente, cioè il committente, chiede. Qui occorre fare una precisazione: se parliamo della qualità in senso stretto (cioè l’assenza di difetti), non si può scendere a compromessi. Diverso è il discorso se parliamo di qualità in senso lato: ipotizzando un progetto volto alla realizzazione di un macchinario, vanno modulate attentamente quelle caratteristiche che riducono la probabilità del verificarsi di un guasto (per esempio: lo proteggo dall’umidità), o rendono agevole il controllo dell’efficienza del prodotto da parte dell’utente (per esempio: metto un termometro in più e lo visualizzo sul monitor), o semplicemente riducono il tempo che occorre per imparare a usarlo correttamente (usabilità: più conosciuto con il termine di prodotto user friendly).

Un altro esempio familiare agli sviluppatori Java: se io implemento un test JUnit per ciascuna della classi che compongono la mia applicazione, è probabile che per la codifica impieghi un tempo superiore di un fattore 2 o 3; però chi farà manutenzione impiegherà molto meno tempo a testare la sua modifica. Bisogna vedere, a seconda delle situazione, se e quando ne vale la pena.

Ci sono poi dei difetti marginali, che provocano danni irrisori: per questi la ricerca assoluta anche del più piccolo difetto è contro il buon senso. Insomma, occorre tener presente che il controllo continuo della qualità assoluta di alcuni aspetti ha un costo, e che il denaro speso è sottratto alle iniziative che potevano incrementare la qualità in senso più generale. L’economia della qualità si può rappresentare con il diagramma di figura 1:

Figura 1 – Il costo della qualità.

Il costo delle ispezioni di controllo è dato da un costo base più un costo proporzionale alla quantità. I costi sostenuti per la riparazione dei guasti tendono a zero all’aumentare dei controlli. Il punto ottimo è quando il costo delle riparazioni, eventualmente anche del risarcimento del danno, bilancia il costo dei controlli di qualità, cioè il costo totale è minimo.

Nel caso di un progetto essenzialmente informatico, “l’ispezione di controllo” può essere la rivisitazione di segmenti di codice, l’introduzione di nuovi commenti e, nel caso di linguaggi Object Oriented, anche un refactoring. La “riparazione di un danno” può consistere non solo nello stanare un bug, ma anche nel bonificare sul DB dati errati che sono stati introdotti a causa del bug stesso.

Il vero significato del ragionamento è: guardate alla concretezza dei risultati, ma soprattutto rifuggite il perfezionismo. Sia perche’ la perfezione ha un costo, sia perche’ il perfezionista non dormirà mai sonni tranquilli e quindi lavorerà male.

Efficienza, affidabilità

L’affidabilità, quando è riferita a una macchina, è più conosciuta con il termine anglosassone reliability, e fa riferimento al tempo medio tra due guasti (mean time between failures); ma quando è riferita a una persona è la fiducia che questa riesce a riscuotere, perciò è soggettiva; l’efficienza invece è il complesso delle capacità oggettive, e la loro costanza del tempo. In questa accezione, l’efficienza è sinonimo di alta produttività.

L’efficienza si raggiunge quando si hanno chiari gli obiettivi e i metodi; è l’obiettivo che decide il metodo, non il fatto che il metodo piace a te. Avere un approccio sereno significa anche riuscire a lavorare con costanza, stabilendo un orario di lavoro costante, sempre lo stesso. Nei progetti fortemente tecnici, come lo sono quelli informatici, la sregolatezza del genio, la scintilla divina, fa più danni che altro.

Capacità di gestire conflitti e crisi, coraggio

Abbiamo già visto i rischi legati ai rapporti interpersonali; focalizziamoci ora sui rischi di tipo tecnico. Occorre fare un elenco dei rischi (risk identification), stimare per ciascuno la probabilità (risk assessment) e quale impatto avrebbe, per tutto il progetto, il verificarsi del default, cioè del fallimento della tecnologia, dello strumento, della risorsa che era stata inizialmente assunta (risk quantification). Occorre poi prevedere varianti al piano per il verificarsi di ciascun default, o almeno dei più importanti. Dunque non si può dire “a questa eventualità non voglio nemmeno pensare!”, altrimenti si fa la politica dello struzzo. L’impact matrix è del tipo di quella rappresentata in figura 2.

Figura 2 – Probabilità di un fallimento, suo impatto sul progetto e conseguente danno.

Sugli assi delle ascisse e delle ordinate occorre mettere valori da 1 a 9; è contro il buon senso pretendere di essere più precisi. I valori nelle celle, quindi gli aggettivi alto, medio, basso, fanno riferimento al danno per il progetto: danno ipotetico, nel caso non fossero disponibili alternative; danno in termini di tempo, di denaro, danno in termini di immagine nei confronti degli stakeholders. A meno che non si tratti solo di denaro, non è facile stimare questo danno nella scala da 1 a 100, come nella figura.

Il mio consiglio è di non mettersi il cuore in pace per aver fatto tutto questo studio; spesso quei numeri non possono che essere arbitrari, e il PM invoca il suo “fiuto” per giustificarli. Allora qual è la vera garanzia? A meno che non si usino tecnologie, strumenti, risorse già consolidati (ma così non si farà mai innovazione), occorre fare i test. Per esempio, sto sviluppando un’architettura software e ho deciso di usare SAAJ (SOAP with Attachments API for Java). Non basta dire: mi fido perche’ l’hanno fatta i californiani della Sun. Quanto la conosci? Se è nuova per te, allora è nuova anche se è uscita da 5 anni. Sei sicuro che ottieni proprio quello che ti serve? Allora occorre mettere nel project planning un congruo tempo solo per studiare e testare quella tecnologia.

Per semplificare, ho parlato come se lo studio di fattibilità (feasibility) fosse fatto dal PM. In realtà, sarà fatto da un tecnico assunto per questo: sarà lui advalutare l’opportunità di usare il package javax.xml.soap, ma la sostanza non cambia.

Veniamo ora alle dolenti note. Se ti metti nei guai, per esempio perche’ la tecnologia scelta per un sottosistema chiave si è rivelata troppo complessa, e cambiarla significa riprogettare anche gli altri sottosistemi, non bisogna dire: “lavoreremo sodo, anche di domenica, anche di notte”; le tecnologie non si domano solo con il fattore tempo, non è questa l’efficienza. Se il caso è grave, occorre fare un nuovo piano di comunicazione coinvolgendo nel problema tutti gli alti livelli, il committente, il management, le varie commissioni, concordando poi con loro l’estensione della comunicazione verso i livelli bassi. Se dimostri di aver fatto prima l’individuazione dei rischi, la valutazione della loro probabilità e la stima dell’impatto sul progetto, forse te la cavi. Ma devi essere pronto alla possibilità che il committente applichi il contratto, congedandoti e addebitandoti penali. Viceversa, se non hai questo coraggio può finire molto male. A proposito, accertatevi che il vostro committente non sia un’organizzazione mafiosa…

Apprezzamento dei valori

Si riferisce soprattutto alla selezione dei collaboratori, cioè dei componenti dei team. Spesso viene fatta in base a schemi precostituiti, se non proprio stereotipi. Il mio consiglio è: uscite dagli schemi; ma non per buonismo: fatelo perche’ volete vincere. So di alcune piccole aziende manifatturiere italiane dove, fuori da ogni schema, la maggior parte degli operai sono portatori di handicap, per esempio con sindrome di Down. Questo non toglie che, dove ci vuole uno skill tecnico preciso, per esempio un DB Administrator, non potete inventarvi niente.

Conclusione

Ho lasciato appositamente per ultima quella dote indicata nell’elenco come etica. Dice un proverbio: “In guerra è in amore tutto è permesso”. E nel Project Management? Ovviamente no.

Per la mia esperienza, è meglio non dire troppe bugie, perche’ hanno le gambe corte. Più è in alto il potere e la capacità di intelligence del committente, più si preoccuperà di verificare sempre ciò che tu gli dici. Sembra ovvio, ma occorre non dire bugie nemmeno a se stessi. C’è un errore nelle operazioni di controllo chiamata “Sindrome del 90%”: quando ho consumato il 90% del tempo, e mi accorgo che il completamento dell’attività è ancora lontano, modifico sulla report le stime dei tempi, per i task che mi rimangono, dichiarando che… ci metterò molto meno. Sulla carta il conto torna, ma solo sulla carta; l’illusione crolla molto presto. La cosa grave è quando questo è fatto in buona fede.

Un altro punto importante è avere rispetto dei tuoi collaboratori. Non puoi considerarli tutti potenziali nemici e quindi valutarli solo in base alla forza della loro posizione; se così fai, presto se ne accorgeranno, e l’ambiente di lavoro diventerà cupo. Non è vero che il collaboratore agisce solo per denaro: “se lo paghi bene, si impegnerà, se lo paghi male, si defilerà”. Commettere questo errore significa avere una visione ristretta del mondo, è da trogloditi. Viceversa, un ambiente davvero sereno si crea mediante un mix di tutte le doti qui descritte, ed è una circostanza fortunata che solo talvolta si riesce a catalizzare.

Riferimenti

[1] Corso per acquisizione certificazione IPMA, KPMG Advisory

http://www.animp.it/IPMA/certificazione.aspx

[2] Karl Popper, “La società aperta e i suoi nemici”, Armando Editore 1994