Un progetto relativo a una camera bianca passa per molte mani prima di diventare uno spazio operativo, e nel momento in cui due parti ritengono che la responsabilità di un determinato ambito spetti all’altra, quell’ambito smette di essere gestito da chiunque. La questione non è se esista o meno una matrice delle responsabilità sulla carta, ma se essa sia strutturata attorno ai punti effettivi in cui il lavoro, le informazioni e le approvazioni passano di mano.

Tracciare i confini del progetto prima di assegnare i nomi

Prima che nomi o ruoli aziendali vengano inseriti nella matrice, il team di progetto deve avere un quadro chiaro di dove finisce il lavoro di una parte e dove inizia quello di un’altra. Questi confini non coincidono con i ruoli organizzativi. Una singola azienda può trovarsi su entrambi i lati di un’interfaccia — realizzando un layout e successivamente occupandosi della sua installazione — e la matrice deve comunque separare queste due posizioni perché, se non vengono chiarite, comportano rischi diversi.

In un progetto relativo a una camera bianca ricorrono due tipi di confini. Un’interfaccia fisica è il punto in cui si incontrano approvvigionamento, lavori in cantiere, installazione e collaudo: il punto in cui un’apparecchiatura smette di essere un articolo acquistato e diventa qualcosa di fisso, collegato e pronto per il collaudo. Un’interfaccia informativa è il punto in cui un documento o un set di dati cambia di mano o cambia stato: il punto in cui un disegno passa dalla fase di produzione a quella di coordinamento con le maestranze adiacenti, per poi essere approvato per la costruzione. Considerare questi due tipi di confine come equivalenti crea ambiguità, poiché chi redige un documento non è necessariamente chi lo coordina con altri servizi, né tantomeno chi ne approva l’adozione.

La condizione che determina come debba essere mappato un confine è se il lavoro o le informazioni in quel punto dipendano dal risultato fornito da un’altra parte prima di poter procedere. Laddove un confine sia autonomo — ovvero una parte fornisce, installa ed esegue i collaudi senza necessitare di un input a monte da parte di qualcun altro — può essere sufficiente indicare semplicemente il proprietario. Laddove un confine dipenda da una sequenza operativa, come ad esempio un passaggio murario che deve corrispondere alle dimensioni di montaggio di un’unità, oppure un disegno che deve essere coordinato con gli schemi meccanici ed elettrici prima di poter essere approvato, la matrice deve rilevare esplicitamente tale dipendenza, anziché presumere che venga risolta in modo informale in cantiere.

Questa fase di mappatura è quella che determina il numero di righe di cui la matrice avrà bisogno alla fine. Una matrice costruita a partire da un elenco generico di ruoli aziendali tenderà a sottostimare il numero di interfacce, poiché raggruppa le attività in base a chi le svolge piuttosto che al luogo in cui avvengono effettivamente i passaggi di consegne. Una matrice costruita a partire dalle interfacce fisiche e informative metterà in evidenza i confini che un elenco basato sui ruoli unirebbe in un’unica riga, ed è proprio lì che tende a nascere l’ambito non assegnato.

Separare la funzione di progettazione dalle mansioni relative all’approvvigionamento e all’esecuzione

Una volta definiti i confini, il passo successivo consiste nel stabilire chi detiene l’autorità in ciascuno di essi — e l’autorità non è un concetto unico. Realizzare un progetto, coordinarlo con altre discipline, approvarne l’utilizzo, installare ciò che esso prevede e testare il risultato installato sono cinque compiti distinti, e una matrice delle responsabilità che li raggruppi in un’unica colonna denominata “soggetto responsabile” sottovaluterà i punti in cui possono sorgere disaccordi.

L’autorità di progettazione riguarda specificamente chi ha il diritto di determinare quale debba essere la soluzione — il layout, le specifiche, le dimensioni dell’interfaccia. Ciò è diverso dall’autorità di fornitura, che riguarda chi fornisce le attrezzature o i materiali fisici, e ancora diverso dall’autorità di esecuzione, che riguarda chi provvede all’installazione, al collegamento e alla messa in servizio. Una parte può detenere l’autorità di progettazione senza detenere l’autorità di fornitura o di esecuzione, e una parte può fornire le apparecchiature senza aver avuto voce in capitolo sulle specifiche. Laddove questi ruoli non siano separati nella matrice, un errore comune è che la parte che esegue il lavoro dia per scontato che l’intento progettuale sia già stato definito, mentre la parte con l’autorità di progettazione presuma che l’esecuzione solleverà domande qualora qualcosa non fosse chiaro.

La condizione che determina il grado di separazione necessario tra queste responsabilità è il livello di interdipendenza tra il risultato progettuale e i vincoli fisici individuati in un secondo momento. Laddove un progetto possa essere finalizzato indipendentemente dalle condizioni del sito, la separazione assume minore importanza nella pratica poiché le possibilità di conflitto sono scarse. Laddove invece un progetto debba rispondere a condizioni confermate solo durante l’installazione — spazi liberi, interfacce strutturali, tracciato degli impianti — diventa necessario mantenere distinta l’autorità progettuale dal compito esecutivo, poiché qualcuno deve avere l’autorità per decidere se una condizione in loco richieda una modifica progettuale o semplicemente un adeguamento in loco nell’ambito dell’intento originario.

L’autorità di approvazione merita ancora una volta un trattamento a parte. Approvare un disegno o un’interfaccia completata non equivale a produrla, coordinarla, installarla o testarla, anche se talvolta un unico soggetto ricopre più di uno di questi ruoli in un determinato progetto. Laddove l’approvazione spetti allo stesso soggetto che ha prodotto il lavoro da approvare, la matrice dovrebbe comunque indicarlo esplicitamente, anziché lasciare vuota la colonna dell’approvazione partendo dal presupposto che la produzione implichi l’approvazione.

Registrare gli input, gli output, le approvazioni e le prove di accettazione in corrispondenza di ciascuna interfaccia

Una volta mappate le interfacce e separate le competenze in base alle mansioni, ogni interfaccia richiede una serie coerente di campi associati, poiché un’interfaccia con un responsabile designato ma senza input o output definiti rimane comunque incompleta. Il responsabile indica chi è responsabile; i campi rimanenti specificano cosa copra effettivamente tale responsabilità.

Gli input richiesti sono importanti perché un’interfaccia non può essere realizzata correttamente se il soggetto responsabile non sa da quali informazioni o materiali dipende. La posizione di una pass box, ad esempio, dipende sia dalla planimetria della stanza sia dalla progettazione del corridoio adiacente o dell’area di supporto; registrare tale dipendenza come input esplicito evita di dare per scontato che chi la installa disponga di tutto il necessario senza che gli venga specificato. Gli output sono importanti per lo stesso motivo, ma al contrario: la matrice dovrebbe indicare ciò che ci si aspetta che l’interfaccia produca, che si tratti di un’installazione fisica pronta per il collaudo, di un disegno pronto per il coordinamento o di un set di dati pronto per il lavoro di progettazione di un’altra parte.

L’approvazione è il punto in cui molte matrici diventano poco chiare, poiché spesso si dà per scontata l’approvazione anziché assegnarla. La condizione che determina se l’approvazione richieda una riga a sé stante è la possibilità che più di una parte possa plausibilmente rivendicare o negare la responsabilità dell’approvazione. Laddove solo una parte possa mai trovarsi nella posizione di approvare un determinato risultato, il rischio di ambiguità è minore. Laddove l’approvazione possa ragionevolmente spettare a un progettista, a un appaltatore o a un rappresentante del committente, lasciare quel campo non assegnato significa che il progetto non dispone di alcun meccanismo per risolvere eventuali disaccordi quando questi dovessero sorgere.

La prova di accettazione è un ambito distinto dalla titolarità e non dovrebbe essere dedotta da quest’ultima. Il fatto di possedere un’interfaccia non costituisce di per sé la prova che l’interfaccia sia stata completata correttamente; la matrice deve registrare quali prove saranno utilizzate per accettare il risultato — che si tratti di un risultato di test, di un verbale di approvazione o di un altro deliverable definito legato a quella specifica interfaccia piuttosto che al progetto nel suo complesso. Questa separazione riflette la struttura del ciclo di vita descritta in ISO 14644-4, che considera la progettazione, la costruzione e la messa in servizio come una sequenza dotata di un proprio processo di verifica, senza stabilire quale parte contrattuale debba svolgere ciascuna fase; la norma descrive le fasi del ciclo di vita, mentre è la matrice specifica del progetto ad assegnare le risorse umane e la documentazione all’interno di ciascuna di esse.

Un acquirente che sta preparando queste informazioni per la revisione di un'offerta trae vantaggio dal fatto che tali campi siano già definiti, poiché i dettagli di configurazione di cui un fornitore ha bisogno — quali input riceverà, quali output dovrà fornire e quali prove saranno utilizzate per accettare il suo ambito di intervento — sono gli stessi campi richiesti dalla matrice in ogni interfaccia che riguarda tale attrezzature del fornitore.

Risolvere le questioni relative alle parti multiple e all’ambito non assegnato tramite chiarimenti sull’offerta

La mappatura delle interfacce e la registrazione dei campi metteranno in luce eventuali lacune, e le lacune stesse sono fonte di informazioni. Un proprietario non specificato, un elenco di collaboratori senza un unico soggetto responsabile, un input o un output mancante, oppure la mancanza di una voce relativa alla prova di accettazione: ciascuno di questi elementi indica un diverso tipo di ambito irrisolto e ciascuno dovrebbe essere trasformato in una domanda di chiarimento specifica prima che il progetto proceda ulteriormente verso la fase di appalto o di costruzione.

Un'interfaccia priva di un responsabile designato rappresenta la lacuna più evidente, e il chiarimento da apportare è altrettanto diretto: occorre identificare chi sarà responsabile di tale interfaccia prima di procedere con il lavoro. Un'interfaccia che elenca diverse parti senza un unico responsabile chiaro rappresenta un problema diverso: i contributori possono essere tutti correttamente identificati, ma la matrice necessita comunque di una parte responsabile che si distingua dalle altre, poiché contributo e responsabilità non sono intercambiabili.

Quando un campo di input o di output è vuoto, il chiarimento necessario non riguarda necessariamente la titolarità, ma la definizione: cosa richiede, nello specifico, questa interfaccia per procedere o cosa produce una volta completata. Lasciare questo campo vuoto non significa che l’informazione non sia necessaria; significa che la matrice non ha ancora costretto il team di progetto a specificarla.

Laddove l’approvazione manchi o sia stata integrata nelle responsabilità dello stesso soggetto incaricato della produzione, del coordinamento, dell’installazione o del collaudo dello stesso risultato, il chiarimento consiste nel separare esplicitamente tale compito di approvazione, anche se la stessa azienda svolge in ultima analisi entrambi i ruoli nell’ambito di funzioni diverse. E laddove la prova di accettazione sia vuota, il chiarimento consiste nell’indicare quale prova verrà effettivamente utilizzata — poiché un’interfaccia priva di una prova di accettazione definita non offre alcun modo per confermare che sia stata completata secondo gli standard richiesti dal progetto, indipendentemente da quanto chiaramente sia stata assegnata la responsabilità.

La condizione che determina l’urgenza con cui tali lacune devono essere risolte è la tempistica della fase di gara o di offerta rispetto al congelamento del progetto. Laddove le richieste di chiarimento vengano sollevate mentre il progetto è ancora in fase di gara, un’interfaccia non assegnata può essere risolta attraverso un processo di domande e risposte prima che qualsiasi parte abbia stabilito un prezzo o si sia impegnata in merito all’ambito di lavoro. Laddove la stessa lacuna venga individuata solo dopo la firma dei contratti, la stessa interfaccia non assegnata tende invece a emergere come richiesta di variazione tardiva o come controversia su quale delle parti avrebbe dovuto coprirla nell’ambito del proprio ambito di competenza. Trasferire ogni cella della matrice non risolta nella registro dei chiarimenti sulle offerte, anziché lasciare che la questione venga risolta in modo informale durante l'esecuzione, è ciò che mantiene tale risoluzione all'interno del processo commerciale, dove deve stare.

Inserire la matrice delle responsabilità nel contratto e nel processo di modifica

Una matrice delle responsabilità che sia stata finalizzata ma mai inserita nel contratto non ha più valore di una semplice nota di pianificazione, poiché nulla obbliga alcuna delle parti a rispettarla una volta iniziati i lavori. La matrice deve diventare un documento contrattuale di riferimento, non un documento che coesiste in modo informale con il contratto.

Una volta definita, la matrice deve anche avere un rapporto ben definito con il processo di cambiamento, poiché i progetti cambiano: l’ambito si modifica, le interfacce si spostano, una parte a cui era stato originariamente assegnato un risultato potrebbe non essere più in grado di fornirlo. Ciò che distingue una matrice ben gestita da una fragile non è il fatto che si verifichino o meno dei cambiamenti, ma piuttosto l’esistenza o meno di una procedura definita per la sua revisione quando ciò accade. In assenza di tale procedura, il primo cambiamento nel progetto tende a invalidare informalmente la matrice, poiché nessuna parte è obbligata ad aggiornarla o a confermare che l’aggiornamento sia stato concordato dalle altre parti interessate.

Una matrice integrata nel contratto dovrebbe specificare chi può proporre una modifica all’assegnazione di un’interfaccia, chi deve approvare tale modifica e in che modo la versione aggiornata viene distribuita e riconfermata a tutte le parti che ne dipendono. Ciò è distinto dall’approvazione a livello di interfaccia discussa in precedenza, poiché riguarda le modifiche alla matrice stessa piuttosto che l’approvazione di un determinato risultato all’interno di una matrice immutata. Laddove un progetto tratti questi due aspetti come lo stesso meccanismo, una modifica alla matrice può essere apportata dalla stessa parte di cui la matrice avrebbe dovuto definire l’autorità, il che indebolisce la funzione della matrice come documento di controllo.

Le informazioni relative alle attrezzature e alle interfacce registrate in precedenza nella matrice influenzano anche le modalità di gestione dell’esecuzione e del coordinamento man mano che il progetto procede — un sistema di camera bianca L'assemblaggio di più famiglie di apparecchiature dipende proprio dalla chiarezza delle interfacce che la matrice è stata concepita per garantire, poiché i confini fisici e informativi di ciascuna famiglia rispetto all'ambiente circostante e ai servizi erano il motivo stesso per cui la matrice era stata creata. Il "congelamento" della matrice non elimina la necessità di esercitare il proprio giudizio man mano che il progetto procede; determina piuttosto chi ha l'autorità di esercitare tale giudizio e quali elementi di prova saranno verificati prima che una modifica a qualsiasi interfaccia venga accettata come definitiva.

Domande frequenti

Q: Quanto deve essere dettagliata una matrice delle responsabilità per le camere bianche?
A: Strutturatelo in base a ciascuna interfaccia fisica o informativa rilevante in cui la titolarità o l’accettazione potrebbero risultare poco chiare, piuttosto che in base a un elenco generico di aziende. Ogni interfaccia dovrebbe identificare un titolare, eventuali collaboratori, gli input e gli output richiesti, la responsabilità dell’approvazione e la prova di accettazione.

Q: Il fatto di indicare il fornitore della camera bianca lo rende responsabile di ogni attività relativa alla camera bianca?
A: No. L'ambito di competenza del fornitore deve essere distinto dall'autorità di progettazione, dai lavori in cantiere, dall'installazione, dai collaudi e dall'approvazione in corrispondenza di ciascuna interfaccia. Definire i confini esatti della camera bianca modulare o del pacchetto del sistema di camera bianca, quindi assegnare esplicitamente ogni responsabilità adiacente.

Q: È possibile che un unico soggetto si occupi della creazione, del coordinamento e dell'approvazione dello stesso disegno?
A: Il progetto può assegnare diversi compiti a un unico soggetto, ma la matrice dovrebbe comunque registrare separatamente la produzione, il coordinamento e l’approvazione. Ciò rende visibili i controlli previsti ed evita che un incarico generico nasconda un compito di cui nessuno si fa carico.

Q: In che modo un acquirente dovrebbe confrontare offerte che definiscono in modo diverso la stessa interfaccia?
A: Confrontare le offerte relative alla stessa riga dell’interfaccia, quindi chiarire i dettagli relativi al titolare proposto, ai collaboratori, agli input, agli output, all’approvazione e alle prove di accettazione. Risolvere le discrepanze sostanziali nel registro dei chiarimenti sulle offerte prima che la matrice venga incorporata nel contratto.

Q: Una matrice delle responsabilità compilata dimostra la conformità alla norma ISO 14644-4?
A: No. La matrice assegna le responsabilità relative al progetto e le prove di accettazione; di per sé, tuttavia, non dimostra che i requisiti relativi alle camere bianche o la verifica siano stati soddisfatti. La norma ISO 14644-4 fornisce il contesto del ciclo di vita per la progettazione, la costruzione, la messa in servizio e la verifica, mentre il progetto deve comunque definire le proprie modalità di consegna, approvazione e accettazione.