A chi serve il project management?

La gestione di progetti, soprattutto in alcuni settori critici come quelli delle costruzioni e dell’ICT, è una materia forse troppo dimenticata dalle Direzioni aziendali delle piccole e medie imprese, anzi essenzialmente delle piccole organizzazioni che si occupano quasi esclusivamente di progettazione di opere o sistemi informatici. Questo poiché nel nostro Paese gran parte delle società che operano in questi settori sono di piccole dimensioni.

Nonostante ciò la dimensione dei progetti che gestiscono le piccole organizzazioni è spesso notevole e quand’anche l’impegno progettuale non assomma un numero di giorni/persona considerevole (fino a 250 ore di lavoro il progetto si definisce piccolo, medio fino a 2500 ore, cfr. PMBOK® Guide) talvolta il risultato del progetto è da considerarsi critico perché riguarda un’opera o un sistema che può influenzare significativamente la vita delle persone e addirittura, in caso di errori di progettazione, può provocare seri danni a persone o cose.

Ma quanto le PMI sono in grado di tenere sotto controllo la progettazione? Quanto sanno gestire i progetti?

Ricordiamo i requisiti principali della norma UNI EN ISO 9001:2008 sui sistemi di gestione per la qualità relativamente al processo di “Progettazione e sviluppo”:

1. Pianificazione della progettazione e sviluppo
2. Elementi in ingresso alla progettazione e sviluppo
3. Elementi in uscita dalla progettazione e sviluppo
4. Riesame della progettazione e sviluppo
5. Verifica della progettazione e sviluppo
6. Validazione della progettazione e sviluppo
7. Tenuta sotto controllo delle modifiche della progettazione e sviluppo.

Tutti questi requisiti sono elementi fondamentali del project management.

1) Devo pianificare la progettazione in modo documentato, preferibilmente attraverso un piano di progettazione che riporti una scomposizione della progettazione in fasi, sottofasi ed attività con il dettaglio necessario per poi identificare, per ognuna di esse, tempi di svolgimento, risorse necessarie, vincoli, ecc.

Spesso quest’attività viene riduttivamente documentata attraverso un diagramma di Gantt che, non dimentichiamolo, è semplicemente una vista del piano di progetto. Ancor più semplicistico è ridurre il project management al project planning, magari senza capire la differenza fra planning (=definire fasi ed attività del progetto e la loro durata) e scheduling (=collocare ogni fase ed attività nell’asse dei tempi reali, ovvero assegnare una data di inizio e fine per ogni attività pianificata), laddove in italiano i termini pianificazione e programmazione non rappresentano esattamente gli stessi concetti. Troppe volte, poi, un “cronoprogramma” della progettazione, sviluppato all’inizio della stessa, non viene più mantenuto aggiornato, annullando parte dei benefici di una buona programmazione.

2) Devo definire i requisiti della progettazione, ovvero gli input ad essa, preferibilmente in modo documentato al fine di evitare ambiguità durante lo sviluppo del progetto. Talvolta l’assenza di un’attenta analisi dei requisiti contrattuali – e di quelli cogenti applicabili – porta a realizzare progetti (e quindi opere o sistemi informatici) che non soddisfano le esigenze del cliente, con tutto quel che ne consegue, sia in termini di immagine, sia in termini di possibili contenziosi (spesso la lievitazione dei costi di opere di ingegneria civile dovute a varianti in corso d’opera è proprio causata da errori di progettazione o scarsa chiarezza del progetto esecutivo).

3) Devo stabilire quali risultati della progettazione si aspetta il Committente. Non solo quelli evidenti, ma anche quelli meno palesi come il formato di output degli elaborati progettuali di un’opera, i sorgenti di un programma software oppure la documentazione utente di un sistema informatico.

4-5) Per non progredire con la progettazione alla cieca, rischiando di intraprendere strade sbagliate oppure di accumulare ritardi incolmabili nei tempi di conclusione del progetto, devo definire e pianificare dei momenti di riesame e verifica della progettazione, in corrispondenza dei quali esaminerò lo stato di avanzamento del progetto e le problematiche incontrate; verificherò, inoltre, la congruenza dei risultati intermedi della progettazione. Effettuare questi riesami e verifiche in momenti opportuni e con il contributo delle persone giuste, aiuta ad evitare di procedere perseguendo decisioni sbagliate o iter progettuali non corretti: bene che vada – se mi accorgo degli errori in fasi successive – evito di svolgere del lavoro per nulla, che dovrò probabilmente rifare. Bene che vada finirò in ritardo e produrrò un progetto non conforme alle specifiche con conseguente aggravio di costi.

6) Dovrei anche “validare” la progettazione al termine della stessa, magari attraverso il test di un prototipo nell’ambiente operativo di utilizzo. Quanti software hanno fallito in fase di installazione dal cliente perché non era stato effettuato un test di accettazione nel medesimo ambiente operativo, comprendente hardware e software di base, interfacce, ecc.?

7) Devo inoltre tenere sotto controllo le modifiche ai risultati della progettazione, sia durante che dopo la conclusione della stessa, attraverso un sistema di controllo delle revisioni o versioni. Il controllo della configurazione oggi è un must non solo per l’attività di sviluppo software (tra l’altro a volte realizzata in luoghi differenti da persone differenti), ma anche per la progettazione di opere edili ed infrastrutturali, dove gli elaborati vengono realizzati in formato elettronico e revisionare un elaborato senza le dovute accortezze porta a confondere facilmente l’ultima versione con una versione precedente.

Tutto questo è project management, ma non solo; è possibile fare di più, quando serve.

Un’indagine Standish Group del 2012 ha evidenziato i dieci fattori critici che possono determinare il successo (o l’insuccesso) di un progetto IT, alcuni di essi sono chiaramente correlati al project management:

3° Chiara definizione dei requisiti

4° Corretta pianificazione

6° Milestone di progetto ravvicinate

7° Competenza del gruppo di lavoro

8° Titolarità del progetto

9° Chiarezza della visione e degli obiettivi

10° Gruppo di lavoro efficiente e focalizzato sul progetto.

Anche se qualcuno potrebbe dubitare, tutti questi elementi sono legati ad una buona gestione del progetto ed ad attività di project management ben documentate e svolte secondo le regole di questa disciplina. Già, ma quali sono le regole del project management?

Esistono degli standard di riferimento, uno di essi – forse il migliore – è il cosiddetto PMBOK ® Guide – Project Management Body of Knowledge, che è stato anche tradotto in italiano ed integrato da TenStepItalia. Esiste poi il PRINCE 2 – PRojects IN Controlled Environments ed anche il modello del SEI CMMI® (Capability Maturity Model® Integration) for Development (Software Engineering Process Management Program (relativo allo sviluppo dei sistemi informatici) contiene alcuni capitoli dedicati al Project Management,

La definizione di “Progetto” ci serve per capire cosa vuol dire Project Management: un progetto è uno sforzo temporaneo intrapreso allo scopo di creare un prodotto, un servizio o un risultato unico. La temporaneità e l’unicità del risultato rende il progetto diverso da un lavoro di routine, da operazioni che vengono svolte sempre nel medesimo modo.

I progetti sono dunque caratterizzati da attività non-ricorrenti e non-ripetitive. Proprio per questo vanno gestite in modo diverso rispetto ad un lavoro ordinario e le cosiddette “procedure” non sono pienamente adatte a descrivere le modalità di gestione di un progetto.

Per questo motivo occorre redigere un piano di progetto e magari anche un piano della qualità del progetto.

Gli elementi fondamentali da valutare, documentare e monitorare per gestire correttamente un progetto sono i requisiti (di qualità e quantità del risultato della progettazione), i tempi e i costi.

Il project management è, dunque, costituito dalla pianificazione, il monitoraggio ed il controllo di tutti gli aspetti di un progetto e di tutte le motivazioni che implicano il sicuro raggiungimento degli obiettivi di progetto entro tempi, costi e criteri di performance stabiliti (def. APM).

Il project management è l’applicazione di conoscenze, skill, strumenti e tecniche alle attività di progetto al fine di soddisfarne i requisiti (def. PMI).

Si può anche dire che il project management è una gestione sistemica di un’impresa complessa, unica e di durata limitata, finalizzata al raggiungimento di un obiettivo predefinito, mediante un processo continuo di pianificazione e controllo di risorse differenziate e limitate, con vincoli di tempo, di costo e di qualità, e rappresenta una tecnica di realizzazione e controllo delle attività particolarmente efficace negli attuali scenari di continua e rapida evoluzione.

I processi di Project management sono stati identificati nei seguenti:

1. Processi di Avvio
2. Processi di Pianificazione
3. Processi di Esecuzione
4. Processi di Monitoraggio e Controllo
5. Processi di Chiusura

In molte organizzazioni si dà prevalenza ai processi esecutivi (punto 3), trascurando soprattutto Pianificazione e Monitoraggio/Controllo del progetto, sebbene il tempo investito in questi processi ne faccia risparmiare molto altro sul Ciclo di vita dell’intero progetto.

La Pianificazione, anche se non costituisce il Project Management, come abbiamo detto sopra, è forse il processo più importante e più trascurato.

Le norme ed i metodi di programmazione possono variare in relazione al tipo ed alla complessità del progetto da realizzare, però i principi alla base di ogni tecnica sono sempre gli stessi e possono identificarsi in regole generali che permettono di conseguire determinati obiettivi come:

• la miglior utilizzazione dei mezzi tecnici e delle risorse;
• il rispetto dei termini di consegna;
• la tempestività nell’assegnazione del lavoro;
• l’eliminazione dei tempi morti per le risorse interne di progettazione;
• l’individuazione delle attività che condizionano la durata dell’intero progetto;
• la minimizzazione del tempo di realizzazione;
• il controllo dell’avanzamento del lavoro.

L’attività di programmazione, qualunque sia il metodo adoperato per svolgerlo razionalmente, inizia con la suddivisione dell’intero lavoro in attività elementari secondo tecniche consolidate come la creazione della WBS.

Ciò ha l’innegabile vantaggio di facilitare le previsioni e di conseguire quindi maggiore accuratezza nelle stesse, poiché è più facile trattare singolarmente piccoli problemi piuttosto che uno solo molto complesso. Quindi, per il conseguimento dell’obiettivo definito, che costituisce la prima fase delle attività del project management, vengono definite implicitamente le attività necessarie da realizzare per il conseguimento dello stesso: queste, una volta esplicitate e formalizzate, saranno caratterizzate da legami di precedenza le une con le altre, da durate (stimate, e quindi con distribuzioni statistiche associate ad esse, oppure deterministiche, magari per le quali si espliciti il legame funzionale fra durata e costi relativi), da una collocazione (allocazione) nel tempo, in dipendenza con i legami funzionali con le altre attività, dalla indicazione della tipologia e dell’ammontare delle risorse necessarie per l’esecuzione.

Creare una WBS (Work breakdown Structure) significa, quindi, scomporre il progetto in deliverable (oggetti da consegnare come risultati del progetto, tipicamente elaborati progettuali, documenti di analisi o moduli software) e quindi in fasi ed attività più piccole, che possono essere gestite più facilmente.

Si può anche definire, all’interno della WBS, il c.d. work package (WP), definito come il pacchetto elementare di attività da allocare ad una risorsa elementare. I WP non sono altro che risultati elementari dell’attività progettuale sui quali si può basare l’attività di monitoraggio, verifica e controllo in itinere del progetto.

Una buona scomposizione del progetto è molto utile per valutare i costi, infatti è assodato che se chiedo ad un gruppo di persone di pari capacità di stimare la durata di un progetto considerando una fase unica oppure scomponendolo in tante fasi più piccole valutate singolarmente ottengo risultati molto diversi. Nel primo caso (valutazione del progetto nella sua globalità) ottengo una stima più grossolana e spesso sottostimata dell’impegno che poi richiederà effettivamente il progetto, mentre nel secondo (stima dell’intero progetto come somma della valutazione di ogni singolo componente nel quale è stato scomposto il progetto) le stime convergono facilmente verso una valutazione più realistica.

Altro aspetto sottovalutato in fase di pianificazione è quello dell’assegnazione delle attività nelle quali è stato scomposto il progetto ai componenti del gruppo di lavoro. Spesso l’assegnazione delle risorse alle attività è svolta in modo approssimativo e non si tiene in debita considerazione l’impegno che altri progetti assorbono alle medesime risorse.

In un processo produttivo svolto da macchine è solitamente chiaro a chi programma la produzione il concetto di schedulazione a capacità finita: una macchina che produce tot pezzi all’ora, se lavora su più turni, anche per 24 ore, più di tanti pezzi alla settimana non può produrre! Viceversa chi pianifica le attività intellettuali su progetti spesso non stima correttamente il tempo necessario per svolgere le singole attività e, pertanto, si comporta come se le risorse umane abbiano una capacità infinita di tempo a disposizione. Di conseguenza i progetti sono in ritardo e le risorse sovra saturate rendono meno.

Altro processo critico è quello di monitoraggio e controllo del progetto: se il progetto è stato ben pianificato sarà più facile tenerlo sotto controllo e l’attività di monitoraggio più raramente rileverà scostamenti rispetto a quanto pianificato in termini di rispetto di tempi di calendario, impegni delle risorse, costi diretti e qualità dell’output della progettazione rispetto ai requisiti stabiliti.

Sulle design review (riesami della progettazione) non a caso è stata costruita una teoria affermatasi nel modello CMMI, nella metodologia Stage- Gate® ed in altri schemi. La tecnica delle Gate Review nelle quali obbligatoriamente l’esito è passa/non passa (GO/NO GO) è certamente molto coraggiosa perché impone di fermare il progetto se qualcosa di importante non è stato completato correttamente, ma fa risparmiare tempo successivamente, evitando i rifacimenti quasi certi.

Anche la definizione delle milestone corrette aiuta a mantenere il controllo del progetto ed a monitorarlo mediante indicatori precisi, inoltre aumenta la consapevolezza del team di progetto sugli obiettivi e sullo stato di avanzamento del progetto.

Nell’analisi e nell’osservazione delle caratteristiche inerenti la conduzione di progetti, sono osservate tutta una serie di fenomenologie:

• il tempo fra l’avvio ed il completamento di un progetto tende a dilatarsi (legge di Parkinson sul comportamento gassoso);
• l’impiego finanziario richiesto da un progetto cresce nel corso della realizzazione;
• maggiore è il contesto tecnologico, maggiori sono i costi;
• maggiore è la tecnologia, maggiore deve essere l’efficienza;
• maggiore è la tecnologia, maggiore è il grado di specializzazione;
• maggiore è la tecnologia, maggiori sono le risorse.

Quando c’è un ritardo nella realizzazione del progetto bisogna provvedere a recuperare il tempo perduto per giungere al completamento negli stessi tempi programmati. Se non si monitora costantemente l’avanzamento del progetto (utili a questo scopo sono le curve di progetto), queste azioni correttive potrebbero risultare tardive.

La definizione delle attività necessarie, della loro relazione reciproca, delle loro durate stimate, dei costi associati e/o risorse finanziarie o non finanziarie da impegnare, il conseguente impegno finanziario totale e la durata complessiva del progetto, possono essere effettuate e determinarsi sia in fase preventiva e previsionale (fase di definizione, pianificazione, organizzazione), sia ripetutamente durante lo svolgimento del progetto (controllo, revisione o ripianificazione), sia a consuntivo al termine dello stesso. Ciò al fine di misurare gli scostamenti in termini di attività realizzate con quelle pianificate, la loro durata, le risorse effettivamente impiegate con quelle previste, i costi effettivi con quelli programmati, la durata prevista complessiva realizzata con quella pianificata e così via.

La gestione del progetto deve considerare anche altri aspetti quali:

• la gestione delle informazioni (documenti di input/output, dati sull’andamento del progetto, ecc.);
• la gestione degli approvvigionamenti (servizi e materiali acquistati, se non ben pianificati, possono influenzare negativamente i tempi, la qualità ed i costi finali del progetto);
• la gestione delle risorse umano e in generale del capitale umano, con tutte le problematiche connesse in termini di competenze possedute, competenze necessarie/richieste, relazioni gerarchiche, rapporti interpersonali, motivazioni, ecc.;
• la gestione dei rischi di progetto.

Su quest’ultimo punto occorre ricordare che I rischi possono essere di varia natura:

1. Rischi di conduzione del progetto: possibilità di non adempimento delle attività pianificate nei modi e tempi previsti.
2. Rischi di qualità del risultato del progetto: possibilità di non adempimento del livello di qualità del prodotto previsto come risultato del progetto rispetto alle attese del cliente.
3. Rischi di bontà dell’investimento: possibilità di non adempimento del livello di costi e benefici previsto, o per un innalzamento dei costi di realizzazione del progetto, o per una diminuzione dei benefici reali (economici, commerciali o di immagine) a fronte di quelli ipotizzati.

In fin dei conti il project manager (PM) non è solo un tecnico con più esperienza degli altri e buone capacità relazionali che viene nominato “capo progetto”. Occorre possedere anche qualità gestionali, organizzative e tecniche di project management.

Un buon PM non conoscerà solo la scomposizione in WBS del progetto e la generazione del diagramma di Gantt, ma sarà in grado – magari attraverso l’utilizzo di appositi tool – di “vedere” il progetto sotto diversi punti di vista attraverso:

• La generazione del Diagramma di PERT e l’individuazione del cammino critico (Critical Path Method);
• L’ affiancare alla WBS la OBS (Organizational Breakdown Structure), che è una “dimensione” di scomposizione relativa alla struttura organizzativa interna del progetto, la quale permette di giungere, attraverso un processo di successive disaggregazioni delle unità organizzative individuate, all’identificazione dei singoli reparti funzionali e dei singoli componenti il team di progetto;
• La determinazione del carico di lavoro delle risorse considerando le altre attività da svolgere estranee al progetto in questione;
• La definizione ed il monitoraggio di appositi indicatori in grado di misurare l’avanzamento temporale e l’avanzamento fisico del progetto, nonché i costi consuntivati vs i costi preventivati (a budget).

Infine è opportuno menzionare l’importanza di gestire una consuntivazione delle ore di lavoro accurata e tempestiva al fine di controllare costi e ricavi del progetto sia dal punto di vista economico, sia da quello finanziario, per garantire un controllo di gestione efficace a livello dell’intera organizzazione.

PMBOK TenStep Italiano.pdf

 

CMMI for Development