Gestione di un Progetto BIM [4]

Principi di Project Management per vivere felici (parte 4) “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 […]

Principi di Project Management per vivere felici (parte 4)

“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. Strategie di Gestione, qui e qui.
  3. Principi, qui e qui.

 


 

4. Fasi

Le fasi di un progetto in senso lato solitamente vengono individuate in:

  • una fase di pianificazione;
  • una fase di produzione (con relative consegne intermedie);
  • una fase di consegna finale del prodotto o dei prodotti commissionati.

 

PM - Project Stages

La fase di pianificazione, cui il PRINCE2 dedica ben due passaggi, è solitamente la più negletta. Come si diceva, è una fase cruciale. Partire con un progetto senza adeguata pianificazione è grave tanto quanto i ritardi dovuti a un’eccessiva sovrastruttura. Il bilanciamento è cruciale.

PM - Balance

1. Pre-Project

Nel panorama generale, il progetto per realizzare una costruzione inizia con una fase completamente a carico del cliente.
Il RIBA Plan of Work chiama questa fase la Fase 0, perché è la fase in cui si decide se il progetto vedrà la luce o meno. È la fase di Strategic Definition, i cui obiettivi sono il Business Case (ovvero la giustificazione commerciale per l’esistenza del progetto) e un Brief Strategico contenente gli obiettivi del progetto. Sull’importanza di ricevere il brief in formato digitalizzato abbiamo tenuto una classe all’Autodesk University di Las Vegas l’anno scorso: la trovate qui. Dall’ultima volta che ne abbiamo parlato, Autodesk ha anche aggiunto la trascrizione completa della classe (qui).

BIM for Hotels (8)

Da progettisti, non siamo noi a dover decidere se il progetto abbia senso di esistere o meno, ma possiamo venire chiamati in consultazione durante questa fase. È la fase in cui ci può venire richiesto un cosiddetto Studio di Fattibilità. Indipendentemente da questo, un cuore di attività principali ha luogo prima che venga autorizzata l’apertura del progetto e pongono le basi per quella giustificazione commerciale che dovrà essere tenuta sotto controllo durante l’intera sua durata.

PM - Activities - Pre Project

1. Creazione del Mandato. Da qualche parte, in alto in alto, qualcuno crea un mandato per il progetto. Il mandato è un documento base che contiene le informazioni principali relative alla commessa, schematizzabili come:

  • di cosa tratta il progetto? Qual è il prodotto che mira a creare o il cambiamento che mira a introdurre?
  • chi sarà coinvolto nel progetto e a chi sono destinati i prodotti finali?
  • dove si svolgerà il progetto? Dove verranno fisicamente realizzati i prodotti finali?
  • quando avrà inizio il progetto ed entro quando dovrà chiudersi?
  • come sarà realizzato il progetto?
  • qual è la giustificazione di business per il progetto?

 

PM - Project Mandate
Il mandato è un documento che risponde alle domande fondamentali

Ragionando nel contesto di un progetto BIM e quindi cercando di individuare il contributo del BIM manager a questo tipo di documento, le domande si declinano in questo modo:

  • [Cosa]
    In stretta collaborazione con chi definisce il contenuto del progetto, questa è la sede per iniziare a interrogarsi sugli usi del futuro modello. Dagli usi infatti discendono gli specialisti che dovranno essere coinvolti (chi) e gli strumenti di cui si ipotizza l’utilizzo (come).
  • [Chi]
    Nel roster di BIM coordinator a disposizione, si inizia a individuare chi sarebbe la persona più adatta a seguire il progetto e, a seconda dell’approfondimento nell’individuare il “cosa”, è possibile che sia già il momento per fare il nome di qualche specialista. Il coinvolgimento di figure specializzate tuttavia spesso discende dalle caratteristiche fisiche del progetto (es: il livelllo di complessità delle geometrie), che a questo punto potrebbero non essere ancora note.
  • [Dove]
    In senso non fisico ma digitale, il “dove” riguarda gli spazi di elaborazione e condivisione dei dati: la presenza di un Common Data Environment e la sua natura incide pesantemente sul budget del progetto, sulla sua fattibilità e sul suo livello di rischio, oltre che sulle persone coinvolte.
  • [Quando]
    A cascata e in preparazione al “come”, il quando incide profondamente sul tipo di tecnologia utilizzabile. Se è previsto che un progetto coprirà uno span di cinque anni, non è saggio proporre un piano tecnologico che si avvalga di strumenti innovativi ma non consolidati (es: un software appena affacciatosi sul mercato e che tra un anno potrebbe essere non più supportato). La sperimentazione di nuovi strumenti è importante ma è altrettanto importante scegliere con cautela i progetti pilota sui cui sperimentarli.
  • [Come]
    “in BIM” non è naturalmente una risposta sufficiente.
    In questa fase di solito è già necessario ipotizzare/consigliare un livello collaborativo, che ha profonde influenze sul “dove” in termini di Common Data Environment, ed è possibile individuare gli strumenti tecnologici di cui ci si avvarrà. In molti casi, e per ottimi motivi, la strategia digitale dell’azienda è compatta indipendentemente dal progetto: esiste uno strumento di authoring preferito, un livello collaborativo preferito, un set di strumenti collaterali cui si fa affidamento. Tuttavia è sempre bene fermarsi un attimo per mettere in discussione la policy alla luce di ogni nuovo progetto.
  • [Perché]
    Ovvero come si può utilizzare il progetto per arricchire le infrastrutture aziendali. Potrebbe essere una buona occasione per un progetto pilota su un nuovo processo o per lo sviluppo di una particolare categoria di componenti in modo che siano riutilizzabili al termine del progetto stesso.

2. Nomina del Dirigente e del Project Manager. La prima persona che viene individuata all’interno dell’organo direttivo, la Project Board, è quel dirigente che sarà responsabile di garantire che il progetto sia ancora conveniente da un punto di vista commerciale. È questo dirigente a individuare un Project Manager adatto al ruolo. Nella transizione che stiamo vivendo, con sdoppiamento dei ruoli, il BIM manager è consigliere di questo dirigente e si occupa di nominare il BIM coordinator adatto, che a sua volta sarà consigliere del project manager. Nelle prime fasi, queste quattro figure lavorano insieme.

 

In questa prima fase, il project manager crea un documento chiamato Daily Log, una sorta di diario di bordo in cui appunta le criticità e le questioni riscontrate durante la fase di avviamento del progetto. Il Daily Log farà da base per altri due documenti, che generalmente vengono sviluppati sono con l’apertura ufficiale del progetto, ovvero il Risk Register (Registro dei Rischi, cosa potrebbe andare male) e l’Issue Register (Registro dei Problemi, cosa effettivamente è andato male). Project Manager e BIM Coordinator potrebbero condividere lo stesso strumento, la stessa dashboard da utilizzare come Daily Log. Il Daily Log è un management product relativamente “smart”, rispetto ad altri documenti più strutturati che appaiono nelle fasi successive, e può appoggiarsi a strumenti per la pianificazione condivisa del lavoro. Generalmente comprende informazioni di base quali:
– Data;
– Oggetto, suddiviso in categorie che possono essere “Problema”, “Azione da intraprendere” o “Evento”;
– Persona responsabile di azione;
– Data di azione;
– Risultato.

Tra gli strumenti “agili” disponibili sul mercato, Trello è al momento uno dei migliori e si può rivelare molto adatto per fare da Registro dei Rischi e Registro dei Problemi, a patto che venga ben impostato.

Trello
Un esempio di “Scheda” in Trello. A ogni scheda corrisponde un rischio o un problema.

 

Ha anche una decente integrazione con Revit, cosa che consente al Coordinator di appuntarsi i rischi a mano a mano che procede nell’impostazione del modello. Consiglio a questo proposito l’articolo di Simone Pozzoli, “Da Revit a Slack passando per Trello” (qui).

 

3. Creazione della bozza di Business Case. Secondo il framework tradizionale, in questa fase si sta ancora decidendo se sia il caso di far partire il progetto o meno, quindi grande attenzione viene posta al giustificativo del progetto, il Business Case appunto. In questa fase, BIM manager e BIM coordinator devono portare avanti – per citare il blog di Casey Rutland – il loro Case for BIM. Non dovrebbe (più) essere il momento di domandarsi se portare avanti il progetto in BIM o meno (vero?), ma è il momento di domandarsi quali usi del modello e quale livello collaborativo è sostenibile/ragionevole proporre, quale parte degli standard, della libreria e in generale dell’infrastruttura aziendale può essere sviluppata/testata durante lo sviluppo del progetto.

 

Integrato nel Business Case si trova la Project Product Description, in cui vengono date le specifiche del prodotto finale. Non bisogna confonderla con le Product Description, che contengono le specifiche dei singoli sotto-prodotti (nel nostro caso si può trattare di caratteristiche per un prodotto tecnico: un modello, un set di componenti per la libreria, un set di script) ma soprattutto i criteri di accettazione di questi prodotti. Sono i benchmark di qualità che determineranno la valutazione del prodotto durante la sua produzione e prima della sua consegna.

Un esempio di Project Product Description Template, facilmente adattabile al prodotto di un progetto in ambito BIM
Product Description Template
Product Description Template

3. Creazione del Brief. A seconda del livello di approfondimento del Mandato, le prime attività una volta iniziato il progetto saranno di ulteriore sviluppo o di verifica rispetto ai sei punti proposti (cosa, chi, dove, quando, come e perché). I sei punti vanno a integrazione di quelli proposti dal cliente nel suo Employer Information Requirements e compongono una parte di quello che sarà il pre-contract BIM Execution Plan.

ideal
Il rapporto è sempre del tipo domanda – risposta.

 

Con un Project Brief ben fatto e l’autorizzazione a procedere, siamo usciti dalla fase di Pre-Project, la prima delle due fasi di pianificazione e start-up.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>