Project Management: lezione imparata

Dopo aver terminato il percorso per la certificazione PMI, recentemente ho completato anche il corso sulla TOC (Theory Of Constraints), un add-on della teoria del Project Management, improntato alla produzione. Ho pensato di scrivere un articolo un po’ più tecnico, che tuttavia può essere interessante anche per chi è curioso di sapere che lavoro svolge chi si specializza in questo campo.

Storia del Project Management

Prima di addentrarmi in merito, un po’ di nozioni.

Innanzitutto, un progetto è un insieme di attività rivolte alla realizzazione di un unicum, si tratti di un prodotto, di un processo, dell’introduzione di una tecnologia, ecc., in grado di portare valore nella realtà che lo ha lanciato e promosso.

I progetti esistono da migliaia di anni, pensiamo alle Piramidi o altre opere simili e ai rispettivi capi progetto, ma di Project Management come disciplina si è cominciato a parlare solamente negli anni ’60 negli Stati Uniti. Infatti, in quegli anni si mettevano i presupposti per grandi opere, come il Progetto Apollo della NASA, che portò l’uomo sulla superficie lunare nel 1969, così come annunciato da Kennedy nel suo celebre discorso. La gestione dei progetti siffatta era applicata con ottimi risultati anche alle costruzioni, all’aeronautica e alla difesa.

Le istituzioni

Il PMI Project Management Institute), nato negli anni ’80, in un’epoca in cui si cominciava a dare importanza ad una certa standardizzazione dei processi, ad oggi conta nel mondo quasi 3 milioni di adepti. questi professionisti, non solo lavorano nelle aziende per assicurare che i progetti abbiano successo, ma contribuiscono anche alla diffusione del “verbo” (metodo).

Proprio così, il PM è un advocate (o influencer) del PMI: attraverso i suoi comportamenti etici ed irreprensibili, sostenuto dai suoi soft skills, applica le Best Practices e, laddove possibile, ne introduce di nuove. Ciao è utile sia per garantire l’evoluzione della teoria, sia per avvicinarla alla pratica e al tempo stesso per creare un ambiente di lavoro sano e corretto. Tutto lo scibile del PMI è racchiuso nel PMBOK, il body of knowlegment. La prima release è del 1996 e oggi siamo alla 6°. Ogni 2-3 anni circa i PM possono includere, se approvate, modifiche o miglioramenti alla disciplina, che confluiscono in una nuova edizione.

torna all’indice

Il moderno Project Management

Ancora oggi questa filosofia è molto utilizzata, specialmente nella sua versione “agile” (pronunciatela in italiano o in inglese, a seconda dei vostri gusti o principi) nata nel 2000 dalla necessità di gestire in maniera più snella e rapida lo sviluppo del software. Questa sotto-disciplina è davvero affascinante, anche fosse solamente per i termini usati (Scrum Master, Product Backlog, Sprint, ecc.). Pensate che esiste un vero e proprio manifesto, che personalmente mi ha ricordato quello dei Futuristi. Cliccate qui se volete leggerlo.
Il metodo agile può essere applicato anche in certe fasi di un progetto classico, laddove i requisiti evolvono con lo sviluppo dello stesso ed è vitale una certa snellezza e rapidità nelle procedure.

torna all’indice

I ruoli

È doveroso distinguere due ruoli, quello del Project Manager e del Program Manager (in realtà c’è anche il Portfolio Manager), perché in Italia abbiamo un concetto tutto nostro.

Il Project Manager

Il primo, dirige un progetto gestendo tutti i vincoli, quali tempo, budget, risorse, qualità, scopo e rischio, riportando al Program Manager. Quest’ultimo è responsabile di molti progetti, in modo da generare le giuste sinergie, affinché tutti avanzino in sintonia, senza interferire in maniera negativa l’uno con l’altro. Inoltre, il Program Manager collabora direttamente con il top management aziendale per elaborare e realizzare la strategia aziendale.

Nel territorio nostrano, invece, il Project Manager è sovente considerato come un ruolo tecnico, al pari del project leader. Colui che dirige un progetto a livello tecnico, partecipa alla definizione dei requisiti, riveste il ruolo di supervisor alle review tecniche (PDR, CDR, FRR, FAT, ecc.), gestisce le risorse allocate, il tutto nel rispetto, ovviamente, di tempi e costi concordati con il cliente. Molto spesso è associato a figure nell’ambito IT, sia per la gestione e implementazione del Cloud, che per lo sviluppo del software.

Il Program Manager

Il Program Manager, invece, similmente al resto del mondo, è una figura più gestionale, meno tecnica, di più alto livello. Infatti, avendo una visione globale dell’azienda, controlla e monitora l’andamento del progetto, nel rispetto delle guidelines della PMBOK.

Ricordiamoci tuttavia che, come tutte le teorie, senza senso pratico ed esperienza, restano un po’ fine a se stesse. Inoltre, alcune tecniche (penso in particolare a quella della TOC) si applicano più facilmente ad aziende che sfornano grandi numeri in termini di prodotto, il che significa non a tutte. Il compito del PM è quello di adattare le procedure standard al progetto e all’azienda in cui è inserito.

Per questo motivo, con una conoscenza limitata dell’azienda, dei suoi processi, delle persone (in particolare di quelle al comando, ma anche dei tecnici), dei prodotti, dei problemi, ecc. non è semplice implementare con successo questi metodi per aumentare il ROI (per i non addetti il Return On Investment) dell’azienda o per creare valore.

torna all’indice

Il Project Manager

Ecco spiegato perché, quando un PM arriva d’emblée in un’azienda, seppur avendo anni di esperienza in un’altra, per di più in un altro settore, può, almeno all’inizio, non essere molto performante. Il PM deve dimostrare una certa dose di umiltà, soprattutto se è appena stato introdotto nell’organizzazione.

Come deve comportarsi un PM appena arrivato in azienda?

Per prima cosa, deve farsi permeare dai meccanismi relazionali e processuali interni. Molti tendono a ricalcare quanto visto e implementato nella precedente azienda, invece di migliorare significativamente quanto già in essere. Pensate a quanto sia fastidioso sentirsi dire da un estraneo che si è sempre lavorato male! Sui CV molti millantano di avere doti eccezionali di comunicazione e poi li si vede cadere miseramente in questi banali errori. Con alcune persone, soprattutto i più esperti nell’ambito (ingegneri in primis!), può bastare una frase detta male per giocarseli per sempre.

Consigli pratici da un PM

Nel mio piccolo, ho cercato di mettermi il più possibile nei panni dell’altro e trattare tutti con rispetto e riverenza (dove necessario e quasi obbligatorio) chi era più anziano di me in termini di presenza sul progetto. La gentilezza e l’educazione sono alla base anche di questa disciplina. Posso affermare senza dubbio lo siano anche dell’intera esistenza umana.

Dove lavoro attualmente, prima di occuparmi del marketing, che in tempi come questi ha purtroppo vita molto dura, a causa principalmente della riduzione (leggi annullamento) del budget, ho fatto il PM per diversi anni. Devo ammettere che è molto più divertente essere un Project Manager che un Program Manager, soprattutto se si ha un animo tecnico, si è curiosi e si ami il dettaglio.

Il PM è sempre indispensabile?

Ogni tanto sento dire da qualche sciagurato che i PM sono inutili e che si arriverebbe ai medesimi risultati anche in loro assenza. Certo, se un PM non è bravo, non può che peggiorare la situazione. Ahimè, di PM non troppo organizzati ne ho conosciuti….il che è tutto dire. Il PM è una figura fondamentale laddove i progetti sono complessi e diversi tipi di stakeholder sono coinvolti. Nelle grandi Corporate, ad esempio, sarebbe impossibile lavorare senza di lui. Al contrario, nelle startup è una figura che “imbroglia” la snellezza organizzativa che la contraddistingue, a meno che il soggetto in questione non sappia applicare la metodologia agile.

Va precisato anche che esistono aziende in cui è più facile lavorare perché l’organizzazione è progetto-centrica e non ci sono i singoli capi funzione che si mettono costantemente di traverso quando hai bisogno delle loro risorse. Non a caso, la gestione duale delle risorse crea i principali problemi nei progetti ed è una delle maggiori cause del loro fallimento.

torna all’indice

Il PMO

Ma il PM deve fare tutto da solo?

Certo che no! In primis, in un’azienda seria e abbastanza grande, esiste un PMO, ovvero un ufficio che raccoglie le best practices e le fa applicare. Inoltre, archivia le lesson learnt (tutto quanto si è appreso nei progetti precedenti). Non solo, è anche proprietario della maggior parte dei tools necessari ad una migliore gestione del progetto: si spazia dal registro e classificazione dei rischi, alla matrice di engagement degli stakeholders, ai template di reporting, ecc. Questi tools possono essere creati internamente o acquistati da altre realtà specializzate.

Sul mercato esistono moltissimi software di PM, c’è l’imbarazzo della scelta; dalla semplice gestione delle attività e dei collaboratori, all’integrazione con l’ERP (Enterprise Resource Planning) o degli altri “big data”.

torna all’indice

I principali fattori di fallimento (da evitare!)

Pertanto, nonostante i tools, la teoria e le guide, la preparazione personale e le doti di comunicazione, come mai non tutti i progetti hanno successo?

Quando il progetti sono “terminati”

Vorrei prima precisare che esistono diversi tipi di terminazione, naturale o prematura di un progetto, strettamente legate con il relativo fallimento:

1. Terminazione perché il business case non è più rilevante per l’azienda
2. Riversamento (assorbito) in un altro
3. Conclusione ma in ritardo (e solitamente con una spesa superiore al budget assegnato)
4. Completamento nei tempi e nei costi ma il risultato non ha portato valore aggiunto

I vari problemi nella gestione dei progetti

Durante quest’excursus avrete già afferrato alcuni dei punti salienti che solitamente conducono al fallimento un progetto. Poiché spesso esistono delle cause “comuni” e facilmente individuabili, provo ad elencarle e a dare qualche rapida indicazione di come non incappare in esse qui di seguito:

fondamentali

1. Requisiti incompleti o non chiari: si deve lavorare a stretto contatto con tutti gli stakeholder, ascoltare e porre tante domande per far emergere subito tutte le questioni “spinose”
2. Variazioni dello scope (scope creep) durante la fase di esecuzione: si deve chiarire sempre con il cliente la ragione per cui chiede di modificare lo scopo
3. Gold plating (tecnico): add-on che non danno valore aggiunto, che consumano risorse, budget: si deve limitare la libertà di sviluppo di tecnici che tendono a gratificarsi

molto importanti

1. Pianificazione irrealistica (stime sbagliate): di devono usare metodi statistici per trovare le stime più corrette, applicando anche la teoria della critica chain per la variabilità
2. Mancanza delle giuste risorse (quantità/skills; approvvigionamento da fornitori non all’altezza): si deve fare una fotografia della situazione e valutare la capacità interna dell’azienda; considerare anche l’ipotesi di affidare all’esterno alcuni work-packages (da controllare e monitorare costantemente)
3. Tempismo sbagliato di Finanziamenti vs Budget: si devono pianificare le attività in modo da fasare le uscite con le entrate

importanti

1. Stakeholders non correttamente identificati e cattivo coinvolgimento (buy-in): i protagonisti più influenti (di solito anche i più scomodi) devono essere sempre nel loop delle decisioni
2. Salto di tecnologia (tools nuovi): se l’azienda deve realizzare un prodotto nuovo, ma non dispone della tecnologia adatta, potrebbe essere più saggio dotarsi prima della tecnologia con un progetto ad hoc
3. Rischi sottovalutati (o non classificati): si deve innanzitutto valutare la propensione al rischio dell’azienda per capire come procedere. In base a questo, sviscerare tutti i rischi noti, assegnar loro una contingency e lasciare una management reserve per quelli imprevisti (ad es. il Covid-19)
4. Errori di comunicazione: usare al massimo i propri soft skills, sia per le comunicazioni interne che per le esterne; customizzare la tecnica da usare e il contenuto da mostrare a seconda del destinatario

La Lesson Learnt (ciò che abbiamo imparato)

Ad ogni modo, l’importante è che, dopo la chiusura del progetto, si riversino le conoscenze ed esperienze maturate con esso a beneficio dell’azienda. Buona regola è carpire la lesson learnt, la lezione imparata, tramite il coinvolgimento di tutti gli stakeholders.

In seguito, bisogna valutare il progetto concluso in base, ad esempio, alle sue performance. Lo stesso dev’essere può applicato per le risorse umane, al fine di capire se queste fossero o meno adeguate o se necessitino di formazione per i progetti futuri.

torna all’indice

Conclusioni

Personalmente, penso di essere tagliata come PM, perché di natura sono organizzata, tengo sempre il budget al centro dell’attenzione, valuto correttamente le stime delle attività tecniche (e non solo), tengo sempre i tempi e mi piace collaborare con le diverse funzioni aziendali.

Le caratteristiche del buon PM

Per essere un buon PM, tuttavia, non basta essere un buon tecnico (esiste un cosiddetto effetto “halo”, che sconsiglia di mettere un tecnico eccezionale a gestire un progetto) e avere nozioni di economia e finanza, ma bisogna saper trattare adeguatamente le persone. Bisogna essere, insomma, un po’ psicologi. I soft skills, quali la capacità di negoziazione, di mediazione, di risoluzione dei conflitti, ecc. si affiancano al problem solving e alla solution finding, perfettamente amalgamati ad una vera e propria propensione per l’etica, la correttezza politica, alla irreprensibilità.

Ogni persona è speciale (alla francese!)

L’aver vissuto esperienze positive con il management, con i collaboratori, i clienti e i fornitori (ovvero con tutti gli stakeholders), significa aver compreso che ogni persona è un caso (a volte umano) a parte, che va trattato in modo peculiare e dedicato. Strategie che si adattano ad alcuni, sono totalmente errate con altri. Ciò perché le persone con cui lavoriamo sono di diverso tipo. Ad esempio i collaboratori possono essere classificati come persone di tipo X o Y, a seconda che abbiano o meno bisogno di indicazioni precise sul loro operato, nonché ricevere continui aggiornamenti, ecc.. Alcuni possono mostrare comportamenti distorti o meno (procrastinazione, sindrome dello studente, ecc. Infine possono avere necessità personali diverse (alla Maslow ad esempio) da soddisfare.

E voi avete mai lavorato su un progetto? Dove avete incontrato le maggiori difficoltà? Con chi avete collaborato meglio?
Scrivetelo nei commenti!

Se vi è piaciuto questo articolo, vi consiglio anche quello sul time vs budget management. Lo trovate qui.