A chi serve il project management?

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 (291 download)
CMMI for Development (355 download)