Generative team e Team Liquido, la nuova frontiera del Team Building per progetti BIM.

Il BIM, si sa, è composto da tante sfaccettature, alcune di natura tecnologica, altre interessano la sfera legale, quella economica, fino a quella umana. In ogni caso, penso che possiamo essere tutti d’accordo su un punto: fare BIM richiede una notevole competenza, capacità di adattamento, attitudine al problem solving, e….ipersensibilità alla caffeina!!

Come dicevo sono numerosi gli aspetti attinenti al BIM, ma penso di non temere smentite se affermo che alcuni, fino ad ora, l’hanno fatta da padrone. Senz’ombra di dubbio una notevole quantità di energia è stata spesa nella ricerca e sviluppo di modi efficaci ed efficienti di impiegare le nuove tecnologie che oggi abbiamo a disposizione. In questo momento invece i riflettori si stanno spostando sull’aspetto normativo e legale, tavoli di lavoro sono aperti a diversi livelli….ma il punto, e l’argomento di cui voglio parlarvi oggi, è che la possibilità di sviluppare e sfruttare con più o meno soddisfazione questi strumenti, dipende dalla qualità del Team che abbiamo a disposizione. Il BIM è un onda che sommergerà il mondo AEC e che porta con se una nuova generazione di sfide, con nuovi paradigmi, e i team devono essere posti in condizione di affrontare queste sfide.

Una premessa, mi occupo di formazione in ambito tecnologico, niente mi farebbe più piacere quindi, di assicurarvi che la soluzione al problema “competenze delle risorse umane” consiste in un bel corso di formazione su di uno o più software o, perché no, la lettura di un buon manuale….sono attrezzato anche da questo lato….

Inoltre se qualcuno di voi teme che stia per parlarvi di approccio psicologico o tecniche di PNL (Programmazione Neurolinguistica), di un nuovo Framework di PM ( Project Management), o peggio, di un sistema organizzativo Multi-level voglio tranquillizzarvi: non è così. Il mio approccio alla materia è quello che potrebbe avere un BIM manager, un BIM Coordinator o più in generale chiunque si trovi nella posizione di dover guidare un team per consegnare un progetto BIM nei tempi e nei modi richiesti, allocando le risorse a disposizione ed eventualmente selezionandone di nuove da inserire in organico, in un ottica, questo si, di miglioramento costante.

Cosa non è il Generative Team

Come vi dicevo insegno software da parecchio e ho visto gruppi di lavoro prendere le informazioni che gli ho trasmesso e fare cose straordinarie, cose che hanno valorizzato il mio lavoro. A volte però, purtroppo questo non è successo. Ho speso, insieme ai colleghi, molto tempo chiedendomi il perchè, e analizzando diverse opzioni. Alla fine abbiamo identificato nelle diverse componenti e organizzazioni del team la risposta più plausibile. L’avvento del BIM, che estremizza l’aspetto collaborativo e la precisa richiesta da parte del mercato di fornire persone che sapessero adattarsi hai diversi e numerosi framework che porta con se ha fatto il resto; perciò oggi sono qui per parlarvi della necessita di un cambiamento di paradigma nel modo di intendere e costruire un gruppo di lavoro che operi in ambito BIM.

Cambiamento di paradigma che, in AM4, la società con cui lavoro, abbiamo sintetizzato con il termine Liquid Team. In AM4 siamo dei fan, anzi dei geek dei metodi di indagine utilizzati dai fisici, e, in particolare, dell’approccio alla definizione e ricerca di soluzioni che i fisici impiegano. Essi prima osservano un fenomeno (spesso molto complesso), poi operano tramite processi di modellizzazione che hanno lo scopo di togliere tutto il “superfluo” che sta attorno al problema e che può confondere le idee; il fine è quello di intuire ed estrarre più agilmente possibili soluzioni da sottoporre poi a test di verifica, rigorosamente condotti con metodo scientifico.

Approccio ereditato dalla Fisica

Così abbiamo fatto anche noi, dapprima osservando la natura del problema. Ci è apparso subito chiaro come avesse diverse sfaccettature, dalle relazioni interne, alla risposta allo stress, dalla mancanza di autonomia, alla adattabilità ai diversi modelli di Project Management posti in essere. Abbiamo quindi modellizzato il problema idealizzando le molteplici sfide che l’approccio BIM alla progettazione comporta, parificandole a un contenitore in grado di assumere qualsiasi forma e dimensione.

Modellizzazione del Progetto BIM.

Guardando il problema da questo punto di vista e ipotizzando il team quale contenuto del recipiente, è facile intuire come l’unico stato della materia in grado di adattarsi senza rompere il contenitore o disperdersi nell’etere sia il liquido. Continuando il parallelo con la fisica ci siamo spostati ad analizzare le proprietà di un liquido scoprendo cose interessanti, un liquido per essere definito tale deve avere le seguenti proprietà:

  • Fluidità. I liquidi sono scorrevoli c’è poco attrito tra le molecole al loro interno, si dice inoltre che non hanno forma propria.
  • Elasticità. Si deformano facilmente sotto uno stress per tornare poi alla forma originale. Questo ci ha indotto a soffermarci anche sul concetto di Duttilità, che proprio di un liquido non è, ma che è interessante dal punto di vista di un team perché aggiunge il concetto di dissipazione dell’energia in eccesso a quello di elasticità.
  • Incomprimibilità. Il volume di un liquido rimane costante a temperatura e pressioni costanti, cosa che, per esempio, non si può dire di un gas.

Ok, probabilmente a questo punto qualcuno di voi si starà chiedendo: ma cosa diavolo centra tutto questo con un team? Vediamolo.
Capito che lo stato liquido poteva essere la soluzione del problema, e che un liquido è tale solo se ha determinate proprietà, abbiamo ipotizzato che un team con le medesime proprietà potesse essere la risposta alle molteplici istanze che un BIM team deve soddisfare. Di più, ragionando sulla natura di queste proprietà, – e si ragioniamo parecchio in AM4, del resto stiamo a Lecco, e non ci rimane molto altro da fare – abbiamo identificato una serie di caratteristiche che un team deve possedere per essere efficiente ad esse in qualche modo riconducibili. Ovvero:

  • Fluidità
    • Adattabilità. Capacità di affrontare progetti di diversa natura per caratteristiche , dimensioni etc.
    • Ri-adattabilità. Capacità di far fronte a imprevisti, defezioni, ulteriori richieste etc.
    • Scalabilità. Capacità delle risorse di subentrare in qualsiasi fase del progetto, entrando di fatto a far parte del team solo all’occorrenza. Ma anche attitudine all’accogliere un nuovo membro, o far fronte all’uscita per qualsiasi motivo di un membro del team.
    • Scorrevolezza. In fisica la scorrevolezza è la capacità delle molecole di scorrere le une sulle altre producendo poco attrito. In un Team BIM è la capacità di lavorare fianco a fianco anche in condizioni di stress…senza strangolare il collega che ha sovrascritto una famiglia modificando il valore dei parametri, per altro senza avere la Proprietà del workset su cui stava…..misteri!!
    • Distribuibilità. Rappresenta la capacità di mantenere la stessa efficienza anche se i membri del team si trovano dislocati in sedi differenti. É ciò che accade, per esempio, con i diversi stakeholder che partecipano al progetto.
  • Elasticità
    • Duttilità. Questo termine viene spesso confuso con la capacità di essere adattabili e, in parte, ci può stare, ma, come vi dicevo, un soggetto duttile non solo si deforma se sottoposto a delle forze ma è in grado di ritornare alla forma originale quando le forze cessano la loro azione. Un team liquido è un team in cui lo stress a cui si è sottoposti durante lo sviluppo di un progetto BIM non lascia strascichi di sorta. Un team in grado di passare alla commessa successiva con il medesimo grado di efficienza e coesione se non addirittura superiore, perché ha saputo analizzare e fare tesoro dei propri errori.
    • Multifunzionalità. Qui vorrei soffermarmi un attimo, il BIM prevede dei ruoli ben definiti, e ci mancherebbe altro, ma pur rimanendo all’interno del proprio ruolo è possibile, naturalmente, svolgere compiti diversi. Essere multifunzionale è la caratteristica principale richiesta a un BIM Coordinator, che deve saper ricoprire, in caso di necessità, praticamente ogni ruolo. Ma essere multifunzionale è una qualità che deve pervadere l’intero team. Solo in questo caso è possibile allocare le risorse in funzione della necessità progettuali. Per farvi un esempio, uno specialista architettonico deve saper disegnare un impianto MEP, e specifico disegnare non progettare, per poter essere d’aiuto in caso di necessità, ma anche per comprendere il perchè gli viene chiesto di disegnare in un certo modo la propria parte. Al di la dell’ovvia considerazione che stiamo parlando di persone con una certa professionalità, va sottolineato che il manager che voglia sfruttare questa caratteristica deve egli stesso possedere alcune conoscenze che vanno al di la delle competenze tecniche. Per esempio deve saper discernere le diverse personalità e attitudini presenti all’interno del team, e allocare la risorsa più opportuna per capacità tecniche ma anche indole e personalità.
    • Poliedricità: Essere poliedrico significa avere, in senso positivo naturalmente, diverse facce. Ma essere poliedrico significa anche saper risolvere lo stesso problema con una poliedricità di metodi scegliendo di volta in volta quello più efficiente. Un effetto positivo dell’essere poliedrici e in parte anche multifunzionali è la possibilità di saper cogliere opportunità che, a nostro avviso, rappresenta una ulteriore caratteristica che un team liquido deve necessariamente possedere.
  • Incomprimibilità
    • Coesione. Un BIM team coeso in ultima analisi è un team in cui si rema tutti nella stessa direzione, quella della consegna. Non serve che venga io a raccontarvi quanto sia importante o che si operi in maniera coesa, ma quello che è realmente importante è comprendere quando un team possa dirsi coeso. In seguito all’ennesima sessione di ragionamento la nostra opinione è che un team possa dirsi coeso quando esiste:
      • Integrazione tra persone. L’integrazione qui è intesa in maniera diversa rispetto all’aspetto puramente sociale. È perfettamente normale che all’interno di un gruppo non si abbia lo stesso livello di interazione, sociale appunto, con ogni membro. È però inammissibile (sopratutto per chi ha la responsabilità del team), non conoscerne indole, credenze e valori che spingono un componente del team a prendere le sue decisioni. L’insieme di queste conoscenze si chiama “identità personale” e solitamente richiede parecchio tempo per essere indagata. Fortunatamente esistono “acceleratori di conoscenza” che permettono di acquisire molto rapidamente queste informazioni.
      • Una Identità condivisa. Si ottiene se i componenti del gruppo si identificano nei valori espressi dal gruppo. Uno dei casi più famosi di identità condivisa è quello del gruppo di “Pirati” creato da Steve Jobs per lo sviluppo del Macintosh.
      • Percezione del Potenziale condiviso. Quando il team percepisce che il Potenziale collettivo è superiore alla somma delle capacità di ugniuno.

La destrutturazione delle Proprietà in Caratteristiche è stata necessaria per rendere possibile l’individuazione di strumenti concreti che potessero implementarle all’interno di un gruppo di lavoro; strumenti che sono stati sviluppati sinergicamente e radunati in una metodologia pratica chiamata Generative Team®.
Il termine “Generative” non rappresenta una operazione di marketing ma piuttosto è espressione di quel cambiamento di paradigma a cui accennavo all’inizio; una piccola rivoluzione nel mondo del Teambuilding: invece di cercare di imprimere dall’alto le caratteristiche al gruppo, l’approccio “generative” permette di estrapolare in modo naturale tali caratteristiche direttamente dal Team, favorendone così lo sviluppo del massimo potenziale. È in pratica un sistema di modellazione dinamica del Team, fondato su processi che permettono il naturale sviluppo di soluzioni ottimali e la progettazione di una squadra di lavoro evoluta.
Processi basati su 4 pilastri fondamentali, identificati costruendo una matrice in cui sull’asse delle Y abbiamo posto le caratteristiche del Team e su quello delle X gli strumenti utili a svilupparle. Questo ci ha permesso di identificare quali strumenti influenzassero il maggior numero di caratteristiche contemporaneamente e poi, dopo un periodo di sperimentazione, di isolare i quattro più efficaci. Vediamoli:

I 4 Pilastri a fondamento del metodo.

*Tecniche di Problem Solving evoluto.* Le tecniche di analisi intrinseche nei vari metodi di PRS permettono, per esempio, l’auto determinazione dell’organico del team necessaria alla risoluzione di un problema.
*Capacità di stabilire una comunicazione efficace.* Forse l’elemento più importante: le informazioni sono la base per compiere le analisi, prendere decisioni, stabilire una strategia, ma anche aumentare l’efficienza tramite la condivisione di procedure etc. Stabilire una comunicazione efficace, per esempio con il cliente (si, anche il cliente fa parte della nostra visione del BIM team), è prerogativa imprescindibile per sviluppare un progetto BIM efficacemente.
*Metodo decisionale.*Chiunque prende decisioni lo fa sulla base delle proprie conoscenze, del proprio vissuto, della propria emotività e naturalmente del proprio tipo di intelligenza. Sarebbe interessante approfondire l’argomento delle sette tipologie di intelligenze identificate da Howard Gardner e dello sviluppo di queste teorie, che ha portato addirittura a nove questo numero, ma rischierei di andare fuori tema. Quello che è importante capire però, è che se è difficile incidere sui processi che portano un individuo a prendere una decisione noi crediamo fermamente sia possibile insegnare allo stesso individuo dei metodi per valutare l’impatto che la sua decisione avrà nei confronti del team.
*Strategia in tempo Reale*. In un mercato dove il prodotto è sempre un prototipo, dove strumenti, norme e processi, sono in evoluzione continua e rapidissima. Un mondo in cui all’interno delle organizzazioni è richiesto di prendere decisioni continuamente, in modo rapido e spesso senza potersi consultare con nessuno, i membri di un team su che basi possono compiere le proprie scelte? Noi riteniamo servano dei principi guida! Qualcosa di applicabile alle situazioni più disparate e che sia espressione della reale identità del team. Di nuovo l’esempio del team Macintosh è calzante. Dire di comportarsi da pirati infatti, cosa è se non un Principio Guida Semplice? Per i membri del team era infatti chiaro che di fronte ad una necessità, andare oltre alla rigidità dell’allora macchina Apple, non solo non sarebbe stato un comportamento demonizzato ma al contrario incoraggiato da chi del team si trovava ai vertici e ne aveva la responsabilità.
Si tratta di un principio valido per chiunque? Per chiunque appartenesse a quel team si, per tutti i team e le organizzazioni assolutamente no. Ecco perché ogni team deve *auto-generare i propri principi guida*. Insisto sul termine auto-generare; un principio guida per essere efficace deve nascere spontaneamente ed essere rappresentativo dell’intero team non può essere imposto dall’alto.
Fin qui, tutto molto bello. Ma come fare per implementare la cosa efficacemente? In AM4 crediamo che le tecniche di gammification rappresentino uno strumento estremamente potente. All’interno di quest’ambito abbiamo ricercato e individuato una metodologia fondata sulle teorie costruzioniste di Piaget che a permesso ad una organizzazione, che tutti conosciamo, di diventare uno dei brand più riconoscibili al mondo, al pari, se non superiore, a marchi come Ferrari e Apple; sto parlando di LEGO® e della metodologia in seno ad essa sviluppata chiamata LEGO® SERIOUSPLAY®.
LSP ( cosi mi adeguo alla follia dilagante con un altro acronimo) unisce la componente ludica alla base del gioco del LEGO® (gammification) alle infinite risorse di Problem solving che un approccio costruttivista ai problemi offre; e ancora, la forza comunicativa che un modello tridemensionale possiede (se ritenete che un modello 3D di un edificio abbia una valenza comunicativa superiore rispetto alla sua rappresentazione 2D, pensate alla potenza che potrebbe avere la rappresentazione 3D di un pensiero!!) alla capacità di porre tutto il team sullo stesso piano, in modo da generare soluzioni condivise.
Per questo motivo abbiamo adottato la metodologia LSP, ne siamo diventati esperti, l’abbiamo plasmata e integrata in un percorso fatto di diverse tappe, un metodo appunto, il Generative Team®di cui LEGO® SERIOUSPLAY® rappresenta uno dei tasselli fondamentali anche se non l’unico.
A questo punto vi starete chiedendo: ok ma si può fare davvero? E sopratutto funziona?
La risposta è si si può fare ed è stato fatto! Più volte.

Per esempio abbiamo preso un gruppo di studio e ne abbiamo fatto un Team in grado, sotto la guida di alcuni BIM Manager e Coordinator tra i più famosi di Italia, di sviluppare un progetto cloud tuo BIM di 90000 mq in circa 6 settimane.

Alcuni momenti di Workshop LSP

Ancora, abbiamo reso capace un altro team di 16 persone di restituire il modello BIM di un edificio storico di Milano i cui particolari di facciata sono stati modellati fino a LOD D, completo di Capitolato informativo, parametri di progetto, regole di clash, schede dei LOD, e tutto ciò che lo rende un vero progetto BIM. Il tutto impostato e modellato (completamente senza l’uso di famiglie in-place) e in poco meno di 4 settimane.

Rendering realizzati a partire dal puro modello Revit.

Rendering realizzati a partire dal puro modello Revit.

Termino questo lunghissimo articolo con un’ultima considerazione. Un team con le caratteristiche che ho illustrato rappresenta un valore enorme per una organizzazione, ma richiede un cambio di paradigma per essere implementato. L’equazione grande progetto = tanti elementi poco qualificati agli ordini di un limitato numero di figure che hanno realmente idea di cosa stia accadendo, è superata. Le variabili sono troppe, l’errore dietro l’angolo, e rifare semplicemente costa troppo. Un approccio efficiente alla progettazione BIM richiede figure estremamente fluide, in numero adeguato alla dimensione del progetto ma inferiore agli standard odierni, capaci di relazionarsi al progetto con cognizione di causa sia per quanto riguarda l’aspetto BIM che progettuale. Un cambiamento di paradigma, appunto.

SalvaSalva

SalvaSalvaSalvaSalva

SalvaSalva

SalvaSalvaSalvaSalva

SalvaSalva

1 Comment

Leave a Comment


Time limit is exhausted. Please reload CAPTCHA.