shelidonSeptember 8, 20152 Comments on Braccia rubate all’agricoltura? Come preparare un Project Implementation Plan

Il Project Implementation Plan è uno dei passi fondamentali durante l’avvio di un progetto, specie se il progetto in questione si troverà a muoversi in un contesto diverso da quello tradizionale. È il documento di preparazione, in cui vengono elencate e sistematizzate tutte le azioni da intraprendere prima di partire con il progetto, spesso pregiudiziali per la buona riuscita del progetto stesso.

Generalmente si rivela tanto più traumatico (e corposo) quanto più è acerba la transizione aziendale al BIM.

Come altri protocolli, è un documento che non nasce in contesto BIM, ma che viene ereditato dagli strumenti classici del Project Management. In un mondo ideale, dovrebbe essere realizzato prima ancora della stesura del contratto e dell’offerta economica, perché molte delle spese individuate nel documento dovranno essere assorbite dai costi di progetto e, possibilmente, ammortizzate.

Piano di implementazione: rimanere semplici, rimanere pratici

A meno che non siate improvvisamente diventati un Project Manager di Gensler e non vi sia appena stato affidato il coordinamento della nuova torre di Shanghai in tutti i suoi 632 metri di altezza, è improbabile che il vostro Piano di Implementazione debba eccedere un certo “limite volumetrico”. Idealmente il documento non dovrebbe superare, in numero di pagine, il numero di persone che dovranno leggerlo. E se il vostro documento è destinato a 15.000 persone, mi risulta comunque difficile credere che tutte e 15.000 saranno interessate a tutte le 15.000 pagine di documento.

Il concetto chiave che dovrebbe guidare la stesura del Piano di Implementazione è uno soltanto: la praticità. Senza volerlo ridurre a una lista della spesa, si tratta di un elenco dettagliato di compiti che dovranno essere portati a compimento nel più breve tempo possibile: a questi tempi, spesso non brevi, non può e non deve aggiungersi il tempo di leggere 15.000 pagine.

Stendere un Piano di Implementazione: procedure rubate all’agricoltura

Nel tentativo di trovare una guida semplice e un po’ meno circonvoluta di quelle che si trovano in ambito BIM, mi sono imbattuta nel sito della FAO (sì, proprio la Food and Agricolture Organization of the United Nations), che all’interno del Corporate Document Repository offre una guida pratica per informatizzare le cooperative agricole. Una realtà che trovo molto molto vicina a quella che tanti di noi si trovano quotidianamente ad affrontare nell’implementazione del BIM. Per anni abbiamo rubato braccia all’agricoltura (le mie, giusto per nominarne alcune): mi sembra giusto rubarle anche le procedure per completare il cerchio.

Ciò che segue è quindi tratto da quella guida, ma adeguatamente parafrasato e adattato all’ambiente BIM.
Se al termine del piano avrete ottenuto un campo di patate, anziché un edificio, inviatemi pure i vostri reclami.

1) Le cinque domande fondamentali

Cinque domande che è bene porsi prima di intraprendere un progetto in BIM durante la fase di transizione, e che possono anche portare a decidere di non portare avanti lo specifico progetto in BIM.

• Quali benefici ci si aspetta dal BIM in questo progetto?
• Quali sono i rischi?
• Qual è la scala delle soluzioni tecnologiche necessarie per il progetto?
  Esempio: inutile imbarcarsi in un sistema di Document Controlling quando l’organico ha a malapena imparato a usare Outlook.
  Nell’implementazione di soluzioni tecnologiche ad hoc è sempre bene tenere a mente il fattore umano, e che esiste un punto critico oltre il quale non è bene spingersi se non si vuole innescare una crisi isterica a catena che, inevitabilmente, andrà ad impattare sulla qualità del progetto.
• Quali servizi normalmente assolti dallo studio / dal contractor possono essere f0rniti tramite il BIM?
  Esempio: le tabelle di quantità e le schede prodotto, normalmente sviluppate a latere rispetto ai disegni, possono essere assorbiti dal modello.
• Com’è composto il personale che sarà coinvolto nel progetto?
  Non si intende, in questa fase, la composizione esatta del team: si sta ancora parlando delle categorie professionali interne allo studio, che andranno a inserirsi nel flusso di lavoro. In questa fase ad esempio è bene individuare se verranno coinvolti renderisti, modellisti, professionisti specializzati nei computi, artisti e tecnici di altra natura. È necessario definire se e come questi professionisti andranno a contribuire alla creazione del modello BIM: nel caso rimangano esterni alla costruzione del modello, è comunque necessario affinare procedure di scambio dati che siano il più fluide possibile, per evitare colli di bottiglia.
• Come possiamo garantire una buona performance anche durante la transizione?
  Inevitabilmente durante la realizzazione dei primi progetti in BIM arriva un punto in cui qualcuno vi farà notare che “Ci avremmo messo meno con AutoCAD”. Come giustamente diceva Jared Banks su Shoegnome nel suo ormai celebre articolo How BIM can bankrupt your Firm, questa è la fase critica, durante la quale gli svantaggi sembrano superare i vantaggi: passare al CAD in questo momento, tuttavia, avrebbe risultati disastrosi per il progetto specifico (si veda il grafico) e apocalittici per l’implementazione a livello aziendale. Evitare il panico è difficile, ma possibile: questo è il momento di pianificare gli accorgimenti che ci consentiranno di abbattere l’inevitabile calo di performance.

• Come può questo progetto contribuire al livello superiore dell’implementazione?
  Il BIM, e in particolare Revit, è come il maiale: non si butta via niente (e molti considerano che sia impuro, ma questa è un’altra storia). Fin da subito, è bene individuare quale sarà l’apporto del singolo progetto in un’ottica di arricchimento degli asset aziendali. Il progetto può essere individuato ad esempio come progetto pilota per testare procedure non ancora messe in atto, come master per sviluppare porzioni del template aziendale, come traccia per stilare nuovi documenti. Il Project Implementation Plan è uno di questi. Sconsiglio vivamente di cimentarsi con documenti complessi a livello teorico: l’approccio pratico è sempre il migliore, anche se significa mettersi in gioco con un progetto reale, rischiando un po’ di più.

Come giustamente ci ricorda la FAO, la stesura di un Piano di Implementazione dev’essere un’operazione partecipativa, specie in una fase critica come la transizione dal CAD al BIM: più persone saranno coinvolte, anche solo in un paio di riunioni di brainstorming, minore sarà il rischio che la transizione venga percepita come un macigno calato dall’alto.

Definire obiettivi di progetto e business goals

Perché stiamo facendo questo progetto in BIM?

Questa è la domanda che vi sentirete rivolgere più spesso ed è fondamentale essere preparati. E, come diceva Einstein, se non sapete spiegarlo in modo semplice significa che voi stessi non l’avete chiaro. Non si tratta di una domanda generale sul BIM e non può essere risposta sventolando la famigerata ruota (che comunque a mio avviso non risponde adeguatamente nemmeno a una domanda posta sul livello aziendale dell’implementazione). Si tratta di una domanda specifica che vuole sapere perché è stato scelto questo progetto specifico e non un altro, considerati i tempi e le risorse a disposizione.

1. Definire la scala degli obiettivi rispetto alle tempistiche di consegna.
A seconda delle tempistiche richieste (definite nel Master Information Delivery Plan), delle persone a disposizione e della disponibilità d’investimento sullo specifico progetto, gli obiettivi devono essere realistici: una delle cause principali nel fallimento dell’implementazione (a parte il panico di cui sopra) è la tendenza a partire con obiettivi troppo ambiziosi, o l’integralismo del voler fare tutto in BIM anche quando non è realistico. Non c’è nulla di male a ridimensionare i propri obiettivi. Ad esempio:
– non ha senso parlare di BIM livello 2 (totalmente collaborativo) senza prima essere passati tramite uno scambio di modelli in livello 1;
– potrebbe non aver senso parlare di clash detection in BIM se si è alla prima collaborazione tra architetti e impiantisti;
– una collaborazione interamente tramite modello può passare anche attraverso viste bidimensionali senza che per questo vengano squalificati lo sforzo e il processo.

2. Identificare obiettivi che siano verificabili e misurabili.
Ci siamo già imbattuti in questo concetto riguardo ai principi dell’apprendimento da adulti: l’adulto tende a infastidirsi quando non gli viene dato uno strumento per verificare la propria efficienza. Non consentire al professionista di misurarsi con i propri obiettivi è una forma di schiavitù: genera stress e, a meno che non si stia costruendo una piramide piena, immancabilmente incide negativamente sulla buona riuscita del progetto. E certe volte persino una piramide piena può riuscire male, se si dispone di schiavi poco motivati.

3. Ottenere il consenso del management.
Che sia il primo progetto in BIM o il milionesimo, è fondamentale che il management e il capoprogetto siano allineati rispetto agli obiettivi. Se necessario, questo è il momento di pianificare incontri per raccogliere le loro perplessità e ascoltare i loro timori. Nulla è più dannoso di un approccio accondiscendente: qualunque sia il motivo per cui il capoprogetto si trova in quella posizione, qualunque sia l’opinione che abbiamo di lui, è necessario prendersi del tempo per rassicurarlo nei suoi timori e farlo innamorare del progetto di implementazione. Dimostrando i vantaggi ottenuti sui progetti precedenti, ad esempio, o mostrando la potenza del nuovo strumento rispetto ai punti su cui hai dimostrato maggior sensibilità. Un interior designer potrebbe ad esempio dimostrarsi più sensibile a Bill of Quantities e tavole accattivanti, mentre un impiantista potrebbe rispondere meglio a dimostrazioni di progettazione 3d e clash detection.

4. Sviluppare un metodo per misurare i progressi.
Nella sua forma compiuta, il Progetto di Implementazione sarà costituito da un elenco di task, ciascuno con il proprio responsabile. Spesso a questi compiti viene affiancata una barra di progressione da 0% a 100%. Altrettanto spesso, si tratta di task i cui due stati possibili sono “da completare” e “completato”: questo è il momento di domandarsi se una semplice check-list non sia sufficiente allo scopo, o se veramente sia necessario fissare punti di controllo intermedi.

Il Piano di Implementazione (in due rapide fasi)

1. Individuare il team. Molto dipende da chi sarà coinvolto nel progetto, ma è fondamentale che vengano individuate figure per coprire almeno i seguenti ruoli:
– il BIM manager (a livello aziendale), che non sarà direttamente coinvolto nel progetto, ma dovrà restarne informato a un livello superiore: se il progetto di implementazione aziendale è agli inizi, ogni singolo progetto deve essere sfruttato come occasione per testare le procedure e sviluppare gli standard;
– il BIM coordinator, che sarà il braccio armato del BIM manager all’interno del progetto e si occuperà di coordinare gli scambi di modello con le parti esterne, verificare gli output e vigilare che all’interno del/dei modello/i vengano rispettati gli standard;
– almeno un power user / BIM specialist, cui gli utenti meno esperti potranno rivolgersi per aiuto e consiglio nel momento del bisogno (tipicamente la prima volta che bisognerà fare una famiglia di porta).
Sarebbe bene che queste figure fossero coinvolte da subito nella stesura del Progetto di Implementazione: ciascuno di loro avrà richieste e/o preziosi suggerimenti da integrare. In un mondo ideale, il Progetto di Implementazione dovrebbe essere steso dal BIM coordinator, in stretta sinergia con il BIM manager.

2. Identificare i task. Cuore del Progetto di Implementazione, l’elenco task deve essere suddiviso in categorie semplici che isolino l’ambito, e che tipicamente possono essere:
– richieste di personale, ovvero quante e quali persone sono necessarie per portare a compimento il progetto. Le figure chiave sono tutte allocate? È necessario assumere qualcuno? In particolare è sempre bene ricordare che, come diceva Fred Brooks, non è possibile fare un bambino in un mese, nemmeno assumendo nove donne (The Mythical Man-Month, Addison-Wesley 1975).
– un elenco di software necessari al progetto. Tra i documenti collaterali allo sviluppo di un progetto, l’IT Assessment Form contiene un elenco dei vari elaborati e dei software corrispondenti: è opportuno prendersi del tempo per verificare che tutti i software siano stati acquistati e installati, su tutte le macchine, nella corretta versione.
– un piano di formazione mirato al personale individuato nel primo punto e sviluppato rispetto ai software individuati nel secondo punto: chi deve essere formato e quanto tempo occorre per rendere operativi i professionisti? L’ideale è sviluppare un programma di formazione e assistenza che vada di paripasso con il progetto, evitando l’information-dumping (quel fenomeno per cui il fruitore viene schiacciato sotto una mole di informazioni tale da renderle inutili).
– un piano di acquisti, che possono andare dall’equipaggiamento hardware per specifici task (es: il famigerato doppio monitor per il BIM coordinator, o l’equipaggiamento per effettuare conference call di coordinamento) alla sedia nuova per il nuovo stagista. Meglio non dare niente per scontato: è così che il nuovo stagista si trova a lavorare in piedi.

Memento

Il Project Implementation Plan non è il vostro progetto, ma un documento riassuntivo di ciò che è necessario perché il vero progetto debba partire. Il bello deve ancora arrivare.