shelidonJune 15, 20171 Comment on Gestione di un Progetto BIM [2]

Principi di Project Management per vivere felici (parte 2)

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

Ribattezzata “Principi di Project Management per restare in vita”, la prima parte della serie si trova qui e qui.

Chiarito cosa sia un progetto, come si differenzia dal cosiddetto “business as usual” e perché sia necessario dotarsi di una sovrastruttura gestionale, soprattutto quando il progetto in questione è un progetto in BIM, bisogna individuare una strategia di gestione tra le varie modalità disponibili.

2. Strategie di Gestione del Progetto

L’etimologia del termine “progetto” è incerta ma se vogliamo dare credito alla versione che la vedrebbe discendere dal francese, ha a che fare con il termine “proiettare”. È una versione che mi piace abbastanza: alla partenza di un progetto, stiamo cercando di pianificare come occuperemo il nostro tempo – nel dettaglio – durante i mesi a venire. Senza la fase di pianificazione, non siamo in presenza di un progetto: stiamo improvvisando (e aumentando i rischi connessi allo svolgimento del progetto stesso).

Le modalità di gestione del progetto sono oggetto di vari framework, vari telai concettuali all’interno dei quali sono organizzati diversi sistemi di procedure. Ogni framework parte da presupposti diversi e ha obiettivi diversi, ma tutti hanno dei principi comuni alla loro base.

I principali sono:

• il PRINCE2, probabilmente il più popolare, il cui acronimo (un po’ forzato) dice molto sulla filosofia generale: Projects in Controlled Environments, progetti in ambiente controllato. Controllo è la parola chiave. Il sistema combina al suo interno i principi del metodo PROMPTII, sviluppato nel 1975 all’interno dell’industria del software e che si focalizza sulle linee guida per gestire il flusso di lavoro da una fase all’altra all’interno di un progetto, e quelli del metodo Managing the Implementation of the Total Project sviluppato da IBM. Me ne occuperò per primo perché il suo framework tradizionale è, sotto molti aspetti, in diretta opposizione all’Agile: il primo si focalizza sulla pianificazione per minimizzare le possibilità che accadano imprevisti mentre il secondo esplora metodi per raggiungere una flessibilità tale da poter rispondere con prontezza alle richieste di cambiamento. Axelos, la proprietaria del PRINCE2, ha sviluppato un sistema-ponte i cui dettagli sono consultabili qui;
• l’Agile, di cui avrò modo di parlarvi in modo approfondito;
• il Critical Chain Project Management si focalizza sulla gestione delle risorse come strumento per mantenere costante il carico di lavoro e il flusso di produzione: me ne occuperò in seconda battuta perché la gestione delle risorse è uno dei punti critici in un team di progettazione;
• il sistema Lean, che si pone come obiettivo quello di consegnare un prodotto con la massima qualità e il minor spreco possibile (per una mappatura dei vari sistemi di spreco, ne parlo nel nostro libro quando affronto la questione dei processi e riprenderò brevemente i principi anche qui);
• Scrum, una variante del cosiddetto Extreme Project Management, in cui il progetto viene gestito tramite una serie di sprint;
• il Waterfall, tradizionalissimo sistema in cui tutto accade in sequenze pianificabili e gli asini volano.

Per praticità, comincerò dal sistema PRINCE e lo userò come base. Per infrangere le regole, si sa, è prima necessario conoscerle a fondo.
Non entrerò tuttavia nel merito di specifiche parti del framework (ad esempio i cosiddetti quattro elementi integrati), per le quali rimando a testi come la Study Guide di David Hinde in bibliografia.

Se volete invece avere una panoramica rapida ma efficace circa i vari metodi di project management, un bel eBook di Wrike ne elenca 16 (e tutto quello che vuole da voi è la vostra e-mail) ovvero:

• Quadro di progetto adattivo (Adaptive Project Framework);
• il nostro amico Agile;
• Realizzazione dei benefici (Benefits realisation management);
• il già citato Critical Chain Project Management;
• il Critical Path Method;
• l’Event Chain Methodology;
• l’Extreme Project Management, da cui discende lo SCRUM;
• il Kanban, che non è una mossa del bujutsu ma è un sistema di pianificazione giapponese nato per il Lean Manufacturing;
• il già accennato Lean;
• il PRINCE2;
• il PRiSM, ovvero Projects Integrating Sustainable Methods, concentrato sulla sostenibilità ambientale;
• il Process-Based Management;
• lo Scrum;
• Six Sigma, per la riduzione dei difetti nei prodotti dei settori industriali;
• Lean Six Sigma, una fusione tra i due metodi;
• Waterfall.

Vi consiglio di recuperarlo: è breve, intuitivo e soprattutto è completamente illustrato.

2.1 Le aree del Project Management

Secondo il PRINCE, le aree in cui si articola la gestione di un progetto sono quattro:
1. pianificazione, ovvero la fase in cui viene definito cosa si andrà a fare durante il progetto e come;
2. delega, ovvero l’arte del non fare sempre tutto da soli: è necessario individuare chi farà cosa e imparare a comunicare loro cosa bisogna fare, in quanto tempo, con quale budget e ogni quanto dovranno riportare i loro progressi;
3. monitoraggio, ovvero come far sì che una delega non si trasformi in un abbandono del team: chi gestisce il progetto deve avere degli strumenti di controllo che siano adatti ad anticipare i problemi ma anche ad individuare ogni possibile opportunità di avanzare con il progetto;
4. controllo, ovvero la possibilità di intraprendere azioni correttive laddove il progetto stia deviando dal suo corso prestabilito.

In BIM la prima fase viene generalmente portata avanti direttamente dal BIM manager e le corrisponde la redazione del BIM Execution Plan nella sua versione pre-contratto. La delega corrisponde alla nomina del BIM coordinator che, una volta partiti con il progetto, porterà avanti il lavoro. Ma anche il BIM coordinator a sua volta avrà necessità di delegare: delegare le operazioni di modellazione complessa a uno specialista, delegare le routine di clash detection, delegare il controllo dei documenti. Gli strumenti di monitoraggio sono quindi di due categorie: quelli sul modello, di natura tecnica, e quelli sul progetto. Il confine tra le due è, naturalmente, molto labile. La necessità di individuare criticità sul progetto prima che queste si verifichino è il motivo per cui il vostro coordinator non può essere uno smanettone in erba ma deve essere una persona che ha già visto diversi progetti aprirsi e chiudersi, e che è quindi in grado di dirigere ed eventualmente correggere la rotta.

Gli indici di monitoraggio sulle prestazioni di un progetto, sono:

• i suoi costi: i costi necessari per partire con il progetto sono generalmente delineati nel Project Implementation Plan, ma i costi veri di un’attività di progettazione sono generalmente collegati ai tempi;
• i suoi tempi;
• la qualità del prodotto, ovvero quanto è rispondente alle specifiche (che siano autoprodotte o ricevute dal cliente);
• l’aderenza allo scope, ovvero il controllo di quando è stato consegnato rispetto alle richieste del cliente e – soprattutto – di quanto è stato consegnato al di fuori di queste richieste;
• il livello di rischio, la quantità di incertezze che il progetto comporta;
• i benefici che il progetto sta portando e porterà all’azienda: può anche essere la prima volta che facciamo clash detection, con tutto ciò che questo comporta, ma alla fine del progetto pilota saremo in grado di farla su tutti i progetti (a patto che venga correttamente capitalizzata l’esperienza maturata durante il progetto stesso).

2.2 Processi e Attività

La differenza tra processo e attività, in project management, è una questione di scala: il processo contiene diverse attività con un obiettivo comune.
Ad esempio, la progettazione è un set di processi.
Il BIM è un set di processi. La modellazione informativa di una copertura è un’attività.

I processi relativi al project management secondo il PRINCE2 sono sette (le “cose” del PRINCE2 sono quasi sempre, biblicamente, sette):

1. Partenza, ovvero le attività relative alla domanda fondamentale: è il caso di dare inizio a un progetto o meno?
Questa fase per noi è critica perché spesso viene confusa con la stessa fase dal lato del cliente, e quindi gestita in modo errato. Il cliente ha deciso che vuole da noi il progetto di un albergo ma, come ho già detto, ora è il nostro turno per decidere se gestire l’attività come progetto o se si tratta di business as usual. Nelle prime fasi di transizione al BIM, e probabilmente per molto tempo dopo, il business as usual non esiste: ogni commessa deve essere trattata come una buona occasione per portare avanti l’implementazione di un altro passo. La nostra prima clash detection. Il nostro primo studio di fattibilità. Il nostro primo edificio storico. Si tratta di piccoli progetti pilota e, come tale, progetti. In senso stretto e proprio del termine.
Ciò che giustifica l’esistenza di un progetto viene chiamato Business Case.

2. Avvio, ovvero la fase di pianificazione.
Questa fase inizia con il BIM Execution Plan nella sua versione pre-contract ed è la fase in cui BIM manager e BIM coordinator si passano il testimone.

3. Direzione, il set di attività che il PRINCE assegna alla Project Board. Si tratta di attività decisionali ad alto livello: se far partire o meno il progetto, se autorizzare l’apertura di una nuova fase, se considerare chiuso il progetto. La questione delle fasi (punto 6) in BIM è particolarmente problematica.

4. Controllo, un’attività di controllo all’interno della singola fase, che è attività quotidiana del Project Manager e, nel nostro caso, del BIM coordinator. La delega e il monitoraggio sono attività cruciali all’interno di questo processo.

5. Gestione delle consegne, ovvero tutto ci; che è connesso all’attività di produzione vera e propria.
Va dall’accettazione dell’incarico (bisogna modellare un pezzo di facciata, si pensa a Giangigi e lui, correttamente informato circa ciò che ci si aspetta da lui, ha confermato che potrà occuparsene), attraverso lo svolgimento dell’incarico stesso (Giangigi modella la facciata) e la reportistica correlata (nel suo report settimanale, Giangigi conferma che tutto sta procedendo per il meglio), fino alla consegna del lavoro (Giangigi avvisa che la modellazione della facciata è stata ultimata e si suppone che qualcuno vada a controllarne la rispondenza a quanto ci si aspettava).

6. Gestione delle fasi, forse la più difficile tra le attività in architettura e una tra le più cruciali quando si tratta di BIM in generale e di Model Management in particolare. Ogni progetto attraversa una moltitudine di fasi, giusto? Le fasi di progettazione assumono e si articolano in modo diverso a seconda del framework legale in cui ci si trova.
Negli Stati Uniti ad esempio le fasi di progettazione che vengono individuate sono:
– Pre-Design / Programming;
– Schematic Design;
– Design Development;
– Construction Documents.

Nel Regno Unito, le fasi di un progetto attraversano i celebri sette stadi del RIBA:
– Strategic Definition;
– Preparation and Brief;
– Concept Design;
– Developed Design;
– Technical Design;
– Construction;
– Handover and Close Out;
– In Use.

In Italia, se la smettiamo di cambiare idea, abbiamo tre fasi di progettazione articolate in:
– Progetto di Fattibilità Tecnica ed Economica (che dovrebbe contenere anche il Documento di Fattibilità delle Alternative Progettuali);
– Progetto Definitivo;
– Progetto Esecutivo.

Ora, tra una fase e l’altra, ammesso di avere incarico per tutte le fasi, ci sono una serie di operazioni che è necessario portare avanti: reportistica, raccolta delle criticità e del materiale potenzialmente utile alla sovrastruttura, pianificazione della fase successiva, archiviazione del materiale non più rilevante. Dal mero punto di vista della gestione del modello, tra una fase e l’altra avviene quella che normalmente chiamiamo “ristrutturazione del modello”. Un modello pensato per la fase preliminare non è strutturalmente in grado di reggere il livello di dettaglio (sia geometrico che informativo) necessario a un progetto definitivo, ad esempio.

Tuttavia è valido anche il contrario.
Un modello strutturato per un progetto definitivo perde in flessibilità e diventa inadatto a sostenere le fluttuazioni e la necessità di portare avanti diverse opzioni in contemporanea, fenomeni tipici di un progetto preliminare. Qualunque BIM Coordinator competente sarà in grado di spiegarvi il perché.
Tra le attività del coordinator nelle transizioni di fase, quindi, troviamo una serie di operazioni tecniche, le cui basilari sono:

• la suddivisione del modello unico in vari modelli più piccoli collegati tra loro e la suddivisione dei componenti, all’interno del modello, in vari set di dati (es: i workset di Revit) e in diversi componenti;
• la sostituzione dei segnaposto con oggetti in grado di essere meglio specificati;
• l’estrazione e il salvataggio del materiale concettuale;
• il resoconto tecnico dell’andamento di fase per il suo BIM manager.

Una volta effettuate le operazioni sul modello destinato al definitivo, sarà sempre più difficile portare avanti operazioni tipiche del preliminare.

La cosa ci porta dritti a un problema sostanziale: quante volte capita di chiudere una fase ma di trascinare nella fase successiva operazioni che sarebbero proprie della fase precedente? Solo perché stiamo dicendo di essere in schematic design, non necessariamente lo siamo davvero. Se stiamo ancora portando avanti significative variazioni alla forma dell’edificio, siamo ancora in concept. Se il programma funzionale dell’edificio non è ancora ben definito, siamo ancora in concept. Se l’hotel operator non è ancora stato individuato, rischiamo di ritornare in concept da un momento all’altro. Per gestire correttamente la transizione di fase, quindi, è necessario individuare chiaramente le caratteristiche di ogni fase. Un lavoro troppo lungo per poter essere riportato su queste pagine, ma strettamente necessario a capire quando effettivamente si è passati da una fase all’altra e quando, quindi, prendersi quel tempo necessario per le operazioni elencate sopra.

7. Chiusura. Infine, simile alla chiusura di fase ma più complesso, viene il momento di chiudere il progetto. Un’altra operazione estremamente difficile, nel nostro settore, perché spesso siamo strettamente legati ai tempi del cantiere e le operazioni di supporto a costruzione e procurement si trascinano potenzialmente per anni. Questo è difficilmente sostenibile e difficilmente ammissibile. Le difficoltà sono molteplici: quando interrompere l’assistenza al cantiere, se non si viene pagati per farlo? Spesso il progettista si trova in una peculiare situazione, incastrato in una sorta di ricatto morale da parte del cliente: si sente obbligato a fornire la propria assistenza al cantiere sotto la tacita minaccia che, in caso contrario, ciò che verrà costruito non sarà ciò che ha progettato, non sarà al’altezza degli sforzi, sarà un’opera da disconoscere. Celebri i casi di Frank Gehry, Ai Weiwei (l’artista cinese dietro allo stadio-nido di Herzog & de Meuron) o, recentemente, l’episodio di David Chipperfield con il Museo delle Culture, qui a Milano. Per evitare che si arrivi a tanto (e leggete qui se volete un insight su cosa deve succedere perché un architetto disconosca la propria opera), spesso si è disposti a profondere nel progetto più lavoro di quanto sarebbe retribuito: in parte è conseguenza della menzogna che vede nell’architettura una professione prevalentemente creativa anziché creativa e tecnica. Si tratta di una dinamica da tenere sotto controllo.

2.3 Persone

Tempo fa ho disegnato una scherzosa piramide per i ruoli del BIM.

Molte cose sono successe dal disegno di quella piramide: abbiamo una norma italiana che per la prima volta parla di mansioni in modo chiaro e non vago (la UNI 11337-5) e che individua tre figure ricalcanti un altro schema, più generico e senza Piña Colada.

I framework di project management tendono a dettagliare con estrema dedizione le fasce dal di sopra di quella di produzione, per ovvi motivi. Queste fasce vengono generalmente divise tra “Directing Level” e “Managing Level”. Al livello più alto, il PRINCE raccomanda di costituire quella che viene chiamata una Project Board. Laddove l’organizzazione abbia più progetti per le mani, come si suppone debba accadere ad esempio in uno studio di progettazione, la fascia del Corporate Management si occupa di supervisionarli dall’alto in modo coordinato. Una riunione generale in cui si fa il punto su tutti i progetti attualmente aperti in studio è una riunione di Corporate Management. Paradossalmente è il livello della Project Board che generalmente manca.

Si tratta di un’organismo deputato a rappresentare tutte le parti in causa all’interno del progetto ed è composto da figure generalmente simboleggiate da:

• un Dirigente, che si occupa di tenere sotto controllo l’aderenza del progetto al piano di business in termini di guadagni, sia materiali che immateriali;
• un Senior User, ovvero una figura che utilizzerà il prodotto oppure che in passato ha utilizzato prodotti simili;
• un Senior Supplier, ovvero una figura che rappresenta il livello di produzione.

Si vede bene come mai raramente questo organismo è presente nell’organizzazione di un’attività di progettazione, che tende a essere monotematica e senza contaminazioni (tutti architetti, tutti ingegneri): è uno scenario principalmente pensato per progetti il cui prodotto verrà utilizzato all’interno dell’azienda e noi stiamo cercando di piegare il framework, in questo senso. Immaginiamo uno scenario in cui le decisioni più alte circa la progettazione di un albergo vengano prese collegialmente da un dirigente (e non da un architetto in fascia dirigenziale), da un architetto in fascia dirigenziale e da una figura rappresentante dell’hotel operator. Se avete mai progettato un albergo, sapete quanti mal di testi potrebbe risparmiarvi questo schema.

Stilare una corrispondenza altrettanto precisa tra questi ruoli e i ruoli del BIM management non è così semplice, perché molto dipende dalla grandezza e dall’articolazione dell’azienda. Sarà un lavoro da portare avanti nella parte 8 della norma UNI, anche in questo caso probabilmente la prima ad affrontare la questione in modo sistematico.
Per chiarire almeno un punto fondamentale, tuttavia, sia chiaro che il BIM manager in una struttura matura si trova al livello più alto (Corporate management) e può essere delegato di se stesso al tavolo direzionale (Directing Level), se esiste, ma non può scendere al livello gestionale a meno di perdere molte possibilità di svolgere a pieno le sue mansioni. Viceversa il livello gestionale è quello del BIM Coordinator, la cui funzione è affine a quella del Project Manager. Questo fenomeno va naturalmente in contrasto con uno dei principi base del project management, ovvero che le mansioni del Project Manager debbano essere centralizzate in una sola figura. Il problema affonda le sue radici nella natura transitoria dello scenario che stiamo affrontando: in un futuro virtuoso, il project manager avrà le competenze e l’autorevolezza necessarie a prendere decisioni anche riguardo al modello, ma in questo momento figure che riuniscano in sé entrambe le competenze sono estremamente rare. La tensione tra le due figure è inevitabile ma sciagure assai peggiori si verificano quando al coordinator viene negato potere decisionale.

Per progetti particolarmente articolati, è possibile che esistano più team e che ogni team abbia bisogno del suo coordinator: in questo caso abbiamo un coordinator che svolge la funzione di team manager e sopravviene la necessità di un coordinator a livello superiore, il BIM manager di progetto di cui si sente spesso parlare. Personalmente non amo questa definizione perché è fuorviante e rischia di creare confusione rispetto al ruolo del Corporate BIM manager: preferisco parlare di Lead BIM Cordinator.

Da manager del progetto, per lo meno dal punto di vista tecnico, il coordinator ha il suo set di Management Products, ovvero il set di strumenti che viene utilizzato per gestire un progetto, e questo set di strumenti deve essere già sviluppato quando il coordinator parte con il progetto. Se non sono già sviluppati, è possibile utilizzare il progetto per svilupparli e considerarli dei prodotti essi stessi, ma è estremamente rischioso e personalmente lo sconsiglio. Il framework PRINCE2 suddivide i management products in tre categorie:

• Baseline, documenti che vengono costantemente aggiornati e che servono, per l’appunto, da base per la conduzione del progetto: il BIM Execution Plan è tra questi documenti;
• Records, documenti univoci in cui vengono aggiunte nuove voci, come righe di una tabella: l’Observation & Comments Sheet, utilizzato ad esempio per tracciare i commenti del cliente e le risposte del team di progettazione, è considerabile un record;
• Reports, che tracciano periodicamente lo stato di avanzamento del progetto.

Esistono 26 Management Products codificati nel PRINCE e li trovate elencati, ad esempio, qui. Non devono essere confuso con gli Specialist Products, che sono gli elaborati di consegna del progetto. Sono spesso dei semplici documenti di gestione e non chiedetemi come mai vengono chiamati “products”.

Lo scenario dei documenti di gestione per un progetto BIM si è recentemente complicato (o minaccia di farlo) con l’introduzione delle nuove PAS 1192 (commentavo la pubblica revisione del capitolo 2 qui). Il nuovo framework proposto vede un parco documenti ricco e variegato, composto da:

• Employers Requirement (sui contenuti di progetto) e il suo corrispettivo sui contenuti informativi: l’Employer Information Requirements;
• una schedule creata seguendo il Digital Plan of Work;
• il BIM Execution Plan stilato in risposta agli Employer Information Requirements;
• il Master Information Delivery Plan con i Level of Development per ogni fase individuata nel Digital Plan of Work;
• la matrice di Ruoli e Responsabilità.

Nei vari documenti confluiscono in realtà molti più documenti preparatori, tra cui:

• il Project Implementation Plan (ne spiegavo l’utilizzo qui);
• i vari Resource e Supplier Capabilities Assessment.

Guardando ad altre industrie per ispirazione, troviamo il concetto di Design Document che è molto simile al nostro BIM Execution Plan: i suoi contenuti sono normati nello standard IEEE 1016-2009, IEEE Standard for Information Technology—Systems Design—Software Design Descriptions, di cui consiglio caldamente la lettura.
Uno dei principali contributi dell’Agile in questo senso è snellire la sovrastruttura di documenti e concentrare le informazioni utili in un unico documento vivo e accessibile. Una serie di Best Practice relative all’approccio da tenere nei confronti della documentazione in Agile è reperibile qui. In breve, i principi sono:

• Come documentare?
  • Ai documenti statici, preferire specifiche eseguibili: il concetto di executable specification è un concetto centrale in Agile e, per quanto strettamente collegato allo sviluppo del software, ha un’utilità enorme anche per quanto riguarda i nostri documenti di gestione BIM. Per ogni parte del BIM Execution Plan, ad esempio, è bene ridurre al minimo la riscrittura di elementi che si trovano già nel modello, trovando invece il modo di rendere operative queste specifiche. Se si lavora in Revit ad esempio, l’elenco dei parametri condivisi può/deve essere direttamente collegato o collegabile al file txt, solo per fare un esempio.
  • Utilizzare i documenti per specificare concetti e non speculazioni: tutta quella parte relativa ai BIM goals così come viene presentata nel celebre template di BIM Execution Plan della Penn State ad esempio è superflua, così come le domande filosofico-motivazionali nei template di Capabilities Assessment del CPIc.
  • Documentare solo ciò che non può essere dedotto dal prodotto (nel nostro caso, dal modello): il BIM Execution Plan è una guida per trovare gli elementi all’interno del modello, ma non deve mai sostituire il modello o generare ridondanza di informazioni.
  • I documenti devono essere semplici ma non semplicistici;
• • È bene ridurre al minimo il numero di documenti e non incorrere in sovrapposizioni, perché le informazioni devono essere veicolate in modo univoco: se esiste già una document list da qualche parte, ad esempio, è inutile ripeterla nel BIM Execution Plan;
  • Le informazioni devono essere posizionate nel luogo più appropriato, dove ci si aspetta di trovarle, e opportunamente indicizzate;
  • Le informazioni devono essere condivise e accessibili a tutti;
  • Le forme della documentazione scaturiscono dalla costante ricerca di modi nuovi e migliori per comunicare.
• Cosa documentare?
  • Ogni documentazione prodotta deve avere uno scopo;
  • Ogni documentazione deve avere una chiara e condivisa utilità per chi la riceve;
  • È chi riceve la documentazione a valutare se è sufficiente o meno: i documenti di design (tra cui il BIM Execution Plan) sono documenti al servizio del team;
• Quando documentare?
  • Il principio base dell’Agile è l’iterazione: ogni documento è un documento vivo che deve essere mantenuto aggiornato in modo costante. Questo a sua volta genera la necessità di altri due principi:
    • I modelli della documentazione devono essere aggiornabili;
    • La quantità di documentazione deve consentire un aggiornamento costante;
    • L’aggiornamento deve essere pianificato nei momenti di necessità.

A questi principi, Scott W. Ambler di Agile Modelling aggiunge quattro principi generali:

• Trattare la documentazione come un requisito: il BIM Execution Plan deve essere parte del contratto e i suoi aggiornamenti dovrebbero essere condivisi/consegnati insieme al modello;
• Richiedere giustificazione concreta per ogni richiesta di ulteriore documentazione;
• Riconoscere la necessità di produrre documentazione;
• Assumere, per redigerla, qualcuno che sappia scrivere.

E sull’ultimo punto, in particolare, non potrei essere più d’accordo.

Se non vi siete ancora stancati di leggere, potete provare ad approfondire alcuni testi riguardanti i documenti di gestione di un progetto BIM. In particolare consiglio:

• Simon Ashworth, Matthew Tucker, Carsten Druhmann: Employer’s Information Requirements (EIR): A BIM case study to meet client and facility manager needs.
• Rafael Sacks, A review of Building Information Modeling protocols, guides and standards for Large construction clients.
• Paolo Ettore Giana, Employer’s information requirements (EIR). Il collegamento tra committenza e fornitori (relatore di tesi: Giuseppe Martino Di Giuda).
• Alberto Pavan, Employer Information Requirements (EIR) e BIM Execution Plan (BEP),quanta confusione!

Le immagini numerate nell’articolo sono:

1. Complesso Symbiosis a Milano, progetto di Antonio Citterio e Patricia Viel;
2. Illustrazione a The Beginners’ Guide to Project Management a cura di Wrike;
3. progressione per il livello di dettaglio attraverso le varie fasi di un progetto, dalle due classi presentate a BILT asia 2017 con Claudio Vittori Antisari;
4. William Turner, The Fifth Plague.