shelidonJune 22, 2017Leave a Comment

Principi di Project Management per vivere felici (parte 3)

“The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.”
(Bill Gates)

1. Ribattezzata “Principi di Project Management per restare in vita”, la prima parte della serie si trova qui e qui.
2. La seconda parte, con le strategie di Gestione, si trova qui e qui.

Questa terza parte entra nel merito dei principi.

3. Principi

Quando ho iniziato questa serie, avevo promesso “principi di project management per vivere felici”. Quali sono quindi questi principi? La domanda è filosofica e ogni framework dà una risposta differente. Secondo il PRINCE, i principi – come dicevo – sono biblicamente sette. Come i vizi.

1. Costante Giustificativo da un punto di vista del Business, ovvero essere sicuri che in ogni momento l’andamento del progetto giustifichi l’esistenza del progetto stesso. Se i costi di un progetto stanno superando la proiezione delle entrate o non sono più giustificati dai benefici previsti, il progetto deve essere terminato. Il documento che giustifica l’inizio del progetto è chiamato Business Case. All’interno del Business Case, il BIM manager e il BIM coordinator dovrebbero sviluppare un’appendice specifica circa ciò che il progetto può portare come ritorno all’infrastruttura aziendale, ad esempio quale parte degli standard, della libreria possono essere sviluppate/testate durante lo sviluppo del progetto.

2. Imparare dall’esperienza, ovvero accertarsi che ogni best practice e ogni errore commesso in passato su progetti simili sia noto, sia stato analizzato e sia stato messo a sistema. Allo stesso modo, ogni esperienza significativa che viene affrontata durante il progetto in corso deve essere correttamente documentata a beneficio dei progetti futuri. Dal punto di vista del modello e dei processi di modellazione informativa, questo tipo di attività è onere del BIM Coordinator e può essere coadiuvata da registri e report.

3. Il principio di gestione per fase, che prevede la suddivisione dei prodotti da consegnare (e delle relative strategie) in compartimenti sequenziali che hanno lo scopo di favorire la pianificazione e di ridurre il coinvolgimento delle alte sfere alle sole fasi di autorizzazione della fase successiva. Anche in questo caso, il principio rischia di andare in conflitto con una delle caratteristiche base del BIM, ovvero “iniziare con la fine in mente”: la gestione per fase non deve essere giustificazione di una miopia strategica. I punti di arrivo, gli obiettivi, gli usi del modello (con relativi LOD e deliverable finali) devono essere pianificati dall’inizio. Un buono strumento per tenere sotto controllo l’andamento del progetto è dividerlo in fasi più corte rispetto a quelle definite nel contratto: il modello di efficienza britannico, ad esempio, lavora in questo senso aumentando il numero delle fasi canoniche. Al di sotto di ogni fase è possibile individuare dei Substage, dei pacchetti di consegna intermedia, ma è necessario che il loro contenuto venga definito in stretta collaborazione con il BIM coordinator. Può aver senso pianificare ad esempio una consegna della sola facciata, mentre non ha senso pianificare una consegna delle sole costruzioni/demolizioni perché prevedono comunque di aver completato la modellazione. Un buon principio può essere che ai pacchetti intermedi corrispondano porzioni separate del modello così come è stato suddiviso durante la ristrutturazione a inizio di fase.

4. Il principio di gestione per eccezione, strettamente collegato al concetto di delega: ogni livello superiore delega al livello inferiore la gestione del progetto e definisce dei limiti di autorità. Il livello inferiore deve ricorrere al livello superiore solo in chiusura di fase oppure (e in questo consiste appunto l’eccezione) nel caso in cui si verifichi un evento che richiede una decisione che eccede i limiti di autorità imposti. Normalmente vengono imposti limiti in termini:

• tempi, perché il carattere temporaneo del progetto prevede che si abbiano chiaramente definito scadenze e date di consegna;
• costi, perché anche un progetto in cui i prodotti sono immateriali ha dei costi relativi al personale, alla ricerca, alle trasferte;
• ambito (il cosiddetto scope): il project manager di un progetto che ha in contratto la progettazione di facciata e strutture non può avere libertà di sviluppare in autonomia anche gli interni, senza essere stato autorizzato dal suo livello superiore;
• qualità: all’interno del mandato che il livello superiore conferisce al livello inferiore, devono figurare delle specifiche di qualità circa i risultati che ci si aspetta e naturalmente il livello inferiore ha il dovere di fare rapporto al livello superiore nonappena abbia anche solo il timore di non riuscire a consegnare un prodotto rispondente alle specifiche.

In aggiunta a questi limiti, entra in gioco un fattore di rischio, ovvero ciascuno di questi limiti deve avere una tolleranza, ad esempio un margine entro il quale è possibile andare fuori budget o un tempo entro il quale è possibile una certa elasticità di pianificazione. Da un punto di vista del business, particolarmente importante è la limitazione rispetto ai benefici: se ci si aspetta che un progetto dia un certo ritorno all’azienda, è necessario che il project manager segnali laddove questo ritorno venga in qualche modo compromesso.
Se applichiamo questo principio alla delega che il BIM manager opera nei confronti del BIM coordinator, le limitazioni possono essere di varia natura e può essere opportuno suddividerle in termini di strumenti e processi.

Da un punto di vista degli strumenti ad esempio, un coordinator difficilmente ha autonomia nella scelta del software di BIM authoring, ma può avere autonomia decisionale nella scelta dei plug-in accessori, purché all’interno di uno specifico budget. Il budget a sua volta può essere comune di progetto (ed è consigliabile che sia così) o specifico per la sfera tecnica. Questa seconda strada è sconsigliata, semplicemente perché le spese saranno in termini di strumenti ma i benefici saranno in termini di processo.
Da un punto di vista dei processi, per fare un altro esempio, un coordinator potrebbe non avere autonomia di decisione circa la frequenza nella condivisione dei modelli (che dovrebbe essere definita contrattualmente) ma viceversa avere totale autonomia nell’organizzazione dei protocolli di collaborazione accessori (conference call di coordinamento, aggiornamento dell’Observation & Comments Sheet).

5. Focus sul prodotto, uno dei principi che sono anche alla base del sistema di gestione della qualità definito nella ISO 9000. Gli elaborati di consegna sono i prodotti nel nostro settore, siano stessi elaborati bidimensionali estratti dal modello o modelli informativi: il focus sul prodotto prevede che siano chiaramente definiti in termini di specifiche. I Level of Development sono i più consolidati di queste specifiche, ma sono solo alcuni. Ogni tipologia di elaborato, ogni porzione del modello, dev’essere chiaramente pianificata nel suo scopo e nel suo contenuto. È bene che queste specifiche prendano le mosse da una base condivisa a livello aziendale o, nelle prime fasi dell’implementazione, che i prodotti opportunamente specificati servano da base per un assessment durante lo sviluppo degli standard di studio.

In aggiunta, due principi sono particolarmente importanti:
1. Ruoli e Responsabilità devono essere ben definiti: il Project Brief, la Project Initiation Documentation e, nel nostro caso, una sezione specifica del BIM Execution Plan devono contenere un chiaro organigramma delle figure che vi prendono parte, con il loro grado di coinvolgimento sul progetto, la loro reperibilità e responsabilità. Bisogna porre particolare attenzione che tutte le figure coinvolte abbiano chiara la loro posizione nell’organigramma, le loro responsabilità e i loro responsabili, i loro compiti. Le peculiarità, le differenze di competenza e prospettiva delle persone coinvolte sono un valore e devono essere tenute in considerazione durante la redazione dell’organigramma, liberandosi del falso mito che tutti i collaboratori siano tra loro equivalenti. Particolare attenzione deve inoltre essere posta alle strategie di comunicazione tra le figure ai vari livelli di gestione.
2. Il processo deve essere adattato all’ambiente di progetto: non esiste un’unica formula di gestione vincente e bisogna sempre tenere in considerazione le peculiarità del progetto.