shelidonJune 9, 20172 Comments on Gestione di un Progetto BIM [1]

Principi di Project Management per vivere felici.

“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)

Uso spesso questa citazione, o una parafrasi, quando apro una sessione di training sul BIM e la trovo particolarmente calzante: una tecnologia efficiente applicata a un processo inefficiente ne amplificherà l’inefficienza, specialmente in una fase del processo che non può (più) permettersi errori o distrazioni. Alla fase di progettazione il BIM richiede maggiore accuratezza e precisione, un maggior approfondimento, pena l’inefficienza dell’intera catena.

Pur non avendo dubbi che il BIM costituisca un’innovazione nei processi di progettazione, l’introduzione di una nuova tecnologia (per quanto più efficiente) deve accompagnarsi a un’efficienza nel processo. Molti dei problemi che si verificano in fase di adozione avvengono perché la nuova infrastruttura tecnologica fa emergere problemi di processo.

Nel nostro caso, quando si parla di BIM e architettura, bisogna distinguere tra processo e processo: esiste un’efficienza da ricercare all’interno del progetto, con il vostro fedele BIM coordinator, e un’efficienza da ricercare a livello superiore, il livello aziendale, che è dominio del BIM manager. La costruzione di questa seconda infrastruttura è tra gli oggetti principali di quella che chiamiamo “implementazione”. Esiste una libreria centralizzata? Un set di template, sia per i modelli che per i documenti collaborativi? Strumenti come questi sono fondamentali per appiattire, per quanto possibile, il piccolo di lavoro che la curva esplicita nella parte iniziale.
Non mi stancherò mai di citare, a questo proposito, l’articolo di Jared Banks su Shoegnome: Why BIM is still bankrupting your firm?.

La costruzione di queste infrastrutture, la fase di “Process Development” a livello aziendale, necessiterebbe non tanto una serie di articoli quanto – probabilmente – un libro a sé.

Dato però che costruiamo l’implementazione proponendo inizialmente un progetto pilota (e se non avete presente le tre fasi dell’implementazione, recuperate la nostra classe all’Autodesk University dell’anno scorso) potrebbe paradossalmente essere utile iniziare a mettere a posto dei principi base nella gestione di un progetto.

Esistono diversi metodi, per la gestione di un progetto nel senso più ampio del termine: accanto al project management tradizionale, che si accompagna ad un sistema di sviluppo “waterfall”, sistemi di gestione alternativi si sono già affacciati da tempo in altri settori (si suppone che al BIM si accompagnino meglio sistemi di sviluppo “agile”).

Non andate via, ora mi spiego meglio, ma per farlo ho bisogno di affrontare nell’ordine alcuni temi non banali, ovvero:

• project management tradizionale e come si applica in architettura, dove il concetto di “progetto” assume un’accezione particolarmente forte e potenzialmente fuorviante;
• principi di lean manufacturing e lean construction, in cui alla progettazione vengono posti specifici vincoli di efficienza per una costruzione più sostenibile;
• project management e produzione agile, infine.

Per farlo, avrò bisogno di più di un articolo. Questo quindi è il primo di una serie.

Bibliografia di riferimento: le basi

Leonardo Caporarello, Francesco Saviozzi, Beatrice Manzoni
L’Architetto. Sette sfide manageriali per la crescita professionale.
2004, Ed. Egea.
Prefazione di Daniel e Lev Libeskind.
«Un buon management è fondamentale per la buona architettura. Molte delle sfide che l’architetto affronta nella sua attività sono infatti, sempre più, di natura imprenditoriale e manageriale. Anche grazie all’esperienza, unica, maturata dagli autori in una serie di workshop con architetti, designer e ingegneri, il libro suggerisce logiche e pratiche di management che permettono di far fronte in modo vincente alle sette sfide che interessano la professione:
– la sfida imprenditoriale: come sviluppare imprenditorialmente uno studio di architettura?
– la sfida dei clienti: come generare valore per il cliente e attraverso il cliente?
– la sfida delle persone: come far crescere le persone in quanto risorse chiave dello studio?
– la sfida del team: come creare e gestire il team di lavoro in modo efficace?
– la sfida dei progetti: come applicare strumenti di project management a commesse piccole e gradi?
– la sfida dei numeri: come misurare e valutare i risultati economici dello studio?
Esauriente guida sia per i professionisti che decidano di avviare uno studio in proprio sia per chi gi lavora all’interno degli studi di architettura in posizioni tecniche o con ruoli di gestione, il libro propone modelli di management e strumenti operativi declinati sulle specificit del settore. A questi si aggiungono casi ed esperienze di grandi studi internazionali (tra cui Foster + Partners, Renzo Piano Building Workshop, Roger Stirk Harbour + Partners, Zaha Hadid Architects), liberi professionisti e realtà italiane di varie dimensioni (tra cui Lombardini22, LPzR, NEXIAR e WIP Architetti)».
L’indice è scaricabile a questo indirizzo. Ulteriore materiale a riguardo è reperibile qui.

David Hinde
PRINCE2 Study Guide
2012, Ed. Sybex.
Indice del testo:
– Introduction
– Assessment Test
– Chapter 1 Overview of PRINCE2
– Chapter 2 Starting a Project Successfully with PRINCE2
– Chapter 3 Organization Theme
– Chapter 4 Business Case Theme
– Chapter 5 Plans Theme
– Chapter 6 Quality Theme
– Chapter 7 Risk Theme
– Chapter 8 Change Theme
– Chapter 9 Progress Theme
– Chapter 10 Managing the Middle of a Project Successfully with PRINCE2
– Chapter 11 Managing the End of a Project Successfully with PRINCE2
– Chapter 12 Tailoring PRINCE2 to the Project Environment
– Appendix A Answers to Review Questions
– Appendix B Management Products in PRINCE2
– Appendix C Passing the Accreditation Exams
– Appendix D Sample Foundation Examinations
– Appendix E About the Additional Study Tools.
Il libro è acquistabile, ad esempio, qui.

1. Il Concetto di Progetto

1.1 Cos’è un progetto?

Prima di poter gestire un progetto, ça va sans dire, è necessario mettersi d’accordo circa cosa si intenda per progetto. Dato che il nostro core business è la progettazione, saremmo tentati di pensare che tutto sia un progetto. Non è così. Un progetto in senso tradizionale ha delle caratteristiche specifiche che lo separano da ciò che quotidianamente viene svolto in azienda, viceversa chiamato “business as usual”.

Un progetto viene caratterizzato dalla presenza di un’organizzazione temporanea, che viene creata per consegnare un prodotto specifico sulla base di una specifica necessità.
Nel nostro caso, parliamo di progetto perché la “specifica necessità” è quella del cliente ed è già stata accertata altrove: il cliente ha deciso che vuole un albergo nel centro di Amsterdam (così, per dire) e nostro compito è consegnargliene uno. La produzione di suddetto progetto (l’albergo) determina l’avvio di un progetto (l’attività di progettazione) all’interno dell’azienda (lo studio di progettazione). Per quanto possa sembrare schizofrenica, la distinzione è fondamentale.
Ciò di cui mi sto occupando in questi appunti è la gestione dell’attività di progettazione internamente all’organismo che se ne occupa e in relazione alle strategie digitali: la gestione della costruzione rispetta delle regole diverse, la cui integrazione con il BIM sarebbe discorso più lungo e complesso.

Esistono alcune caratteristiche base del progetto tradizionalmente inteso, tuttavia, che non si applicano al progetto in senso architettonico. Il fatto che non si applichino, come vedremo, genera parte di quell’inefficienza che diviene critica con l’introduzione del BIM e che rischia di essere amplificata.

Le caratteristiche primarie di un progetto, sono:

1. Si tratta di un’attività temporanea: la progettazione dell’albergo non durerà in eterno (o, per lo meno, non dovrebbe).
2. Si connota come un’attività cross-funzionale, ovvero che coinvolge persone con capacità e competenze diverse, provenienti da dipartimenti diversi e, spesso, da diverse organizzazioni: non confondiamo questo punto con la necessità di collaborare all’esterno dell’azienda (ad esempio con l’ingegnere strutturista) perché in questo caso siamo alla ricerca di un’efficienza interna quindi stiamo semplicemente cercando di gestire la disomogeneità di competenze all’interno della stessa struttura aziendale. Sapete, ad esempio, quali sono le implicazioni dell’esportare una vista di Revit al vostro dipartimento grafico? (leggete qui, se la risposta è no). Avete sviluppato un workflow efficiente tra la squadra di progettazione e chi si occupa dei rendering? Il vostro modellista lavora a partire dal modello digitale?
3. Si tratta di un’attività unica nel suo genere (il nostro primo albergo) o significativamente diversa da quelle analoghe svolte in precedenza (un altro albergo simile al precedente, ma in una nuova posizione) e ovviamente il grado di unicità del progetto ha diverse implicazioni nella sua gestione;
4. Si tratta di un’attività che presenta incertezze e rischi;
5. È un’attività che introduce un cambiamento: a livello aziendale, la nostra organizzazione al termine del progetto sarà diversa da com’era prima dell’inizio del progetto.

L’ultimo punto, come si può facilmente immaginare, è il più difficile da applicare ai progettisti. L’organizzazione sarà diversa, dopo aver progettato un albergo? Generalmente non è ciò che accade. Ma, pensandoci bene, dovrebbe accadere: al termine della progettazione del nostro primo albergo, il team di progetto avrà acquisito una serie di competenze che prima non aveva e potrebbe aver sviluppato dei metodi e delle tecniche per svolgere il lavoro in modo diverso da come facevamo prima. In BIM, soprattutto quando il progetto è il nostro progetto pilota, il team uscirà dall’attività con un set di output ben definiti che devono essere capitalizzati. Far sì che ogni progetto (in senso proprio) introduca un miglioramento a livello infrastrutturale è un punto fondamentale, nella ricerca dell’efficienza. Il lavoro svolto durante le fasi di produzione restituisce ricchezza alla fase di pianificazione (ricordate la curva di Jared Banks?) chiudendo il cerchio. Così come un progetto non inizia nel momento in cui si apre il computer, esso non finisce nel momento in cui si salva il file per l’ultima volta.

Nel processo di chiusura, vedremo quali possono essere gli output che hanno un valore a livello infrastrutturale e che si deve essere in condizione di raccogliere da ogni progetto in fase di conclusione.

1.2 Progetto vs. Business as usual

In architettura, la distinzione tra progetto e business as usual è particolarmente problematica perché, come dicevo poco fa, tendiamo a chiamare tutto “progetto”. Esistono però delle situazioni in cui alcuni cosiddetti progetti potrebbero essere business as usual, ordinaria amministrazione.
Faccio un esempio.
Se il vostro è uno studio di architettura specializzato in edilizia residenziale e vi aggiudicate la commessa dell’ennesima torre di appartamenti a Taiwan (un esempio a caso), quello è a tutti gli effetti un progetto. Si tratta di una nuova torre e, per quanto sia analoga a progetti già sviluppati, le differenze sono tali da connotarlo come un prodotto nuovo.
Viceversa, se il vostro studio si occupa di progettare tutti i negozi di Benetton (altro esempio a caso), il trentesimo negozio potrebbe avere alcune caratteristiche del business as usual. La progettazione dei negozi all’interno degli uffici tecnici di un’azienda è generalmente gestita con le caratteristiche del business as usual, ovvero una struttura gestionale snella e processi quanto più standardizzati possibile: perché negli studi di progettazione dovrebbe essere diverso?

Si definisce business as usual la normale attività di un’organizzazione: solitamente si tratta di un’attività che viene portata avanti da persone nello stesso settore, a partire dalla struttura aziendale esistente ed è spesso il risultato di un progetto. Ad esempio, un progetto è quello di implementazione del BIM: il suo obiettivo è far sì che tutti siano in grado di lavorare in BIM entro un certo periodo di tempo. Quando l’obiettivo viene raggiunto, il progetto viene chiuso e lavorare in BIM diventa business as usual.
Oppure no?

1.3 Gestire la sovrastruttura

Impostare una struttura di gestione del progetto in senso tradizionale non è gratis: comporta la creazione di una sovrastruttura di gestione. La domanda che ci si pone quindi è se valga la pena trattare l’attività come un progetto oppure, viceversa, se si tratta di business as usual.

I fattori che possono concorrere alla decisione di trattare un’attività come progetto anziché come ordinaria amministrazione possono essere:
– l’importanza dell’attività stessa (il nostro primo grattacielo dovrà sicuramente essere trattato come progetto);
– l’alto livello di rischio (un progetto per un cliente già rivelatosi problematico in passato avrà certamente bisogno di una sovrastruttura di gestione per ridurre le possibilità che qualcosa vada storto).
In sintesi, la struttura di gestione di un progetto ne aumenta le possibilità di successo. Ne aumenta anche i costi. Trattare tutto come un progetto non è conveniente. In architettura, abbiamo trovato una soluzione geniale al problema: tutto viene chiamato “progetto”, ma poi è molto raro che il progetto venga gestito come tale.
Lavorando in BIM, soprattutto nelle prime fasi, ogni progetto presenta un alto livello di rischio (l’inesperienza del team e l’immaturità delle infrastrutture concorrono a questo fenomeno) quindi è bene dedicate a ogni commessa la giusta attenzione in termini di progetto. Dato che non è economicamente sostenibile sviluppare a tavolino ogni tassello necessario, ogni commessa è anche l’opportunità per sviluppare e testare nuovi pezzi dell’implementazione. Questi prodotti aggiuntivi contribuiscono a giustificare i costi della sovrastruttura di gestione, rendendo la transizione più sostenibile. In più, parte dei costi di implementazione possono essere distribuiti tra gli oneri di progettazione. Questa prospettiva è chiamata Business Perspective e, all’interno dell’organo decisionale di fascia più alta, deve rivestire un’importanza pari a quella di chi si occupa di supervisionare la creazione del prodotto o di verificare che il prodotto rispetti le richieste del cliente.

Per ora, mi limiterò a fare alcuni esempi di output estraibili da un progetto a beneficio dell’infrastruttura aziendale:

• componenti inseribili all’interno della libreria centrale (in Revit, famiglie caricabili che si possono salvare come file esterno e famiglie di sistema che si possono raccogliere in un file “showroom”);
• routine di mappatura per l’interscambio dati (in presenza di uno standard, è possibile riutilizzare ad esempio la struttura delle tabelle e i vari script per l’inport/export dei dati);
• script per l’automazione della produzione;
• script per il controllo del progetto.

Un progetto ben gestito è in grado di contribuire abbondantemente al patrimonio d’infrastruttura, a patto che anche questa sia ben gestita, e la cosa va a naturale vantaggio dei progetti successivi. Senza una gestione corretta e senza un’infrastruttura centrale, viceversa, ogni progetto si troverà a reinventare la ruota o a riciclare materiale non verificato, con picchi di inefficienza che il BIM porta alla luce e amplifica, laddove i vecchi processi tendevano a mascherarli.

Se non siete ancora stanchi di leggere, o se volete tagliare attraverso i boschi e affrontare direttamente le tecniche di project management Agile, l’European Conference on Product and Process Modelling è un buon punto di riferimento. Dall’edizione dell’anno scorso, in particolare vi consiglio:

• Udo Kannengiesser e Ana Roxin: An Agile Process Modelling Approach for BIM Projects (qui potete richiedere il paper, qui potete vedere le slide).

Le immagini nell’articolo sono:

1. Variante sulla curva di MacLeamy, mostrata per la prima volta con Claudio Vittori Antisari durante il convegno i-Learning & Connected Buildings il 4 marzo 2016 al Politecnico di Milano (qui il video);
2. Jared Banks, variante della curva di MacLeamy in Why BIM is still bankrupting your firm?
3. Conservatorium Hotel, Amsterdam (qui il sito dell’albergo). Progetto di Piero Lissoni.
4. Complesso Symbiosis, Milano. Progetto di Antonio Citterio e Patricia Viel.
5. Negozio Benetton in corso Buenos Aires a Milano (qui un comunicato stampa). Progetto di Piero Lissoni.