Riesame della progettazione: il paragrafo 8.3.4 della ISO 9001 spiegato come non te l'ha mai spiegato nessuno
Guida operativa al riesame della progettazione: metodologie, contaminazioni, lezioni e checklist in 10 step scaricabile
Il riesame come decisione, non come documento
Il riesame della progettazione è il punto in cui la qualità smette di essere un semplice adempimento e diventa una vera e propria decisione. Si tratta, infatti, del momento strutturale in cui un'organizzazione verifica se ciò che sta progettando funzionerà davvero e ha ancora il tempo e il coraggio di cambiare idea.
La ISO 9001 lo chiede al paragrafo 8.3.4, ma la sua efficacia reale dipende molto meno dalla conformità normativa e molto di più dalla cultura che lo circonda. Un buon riesame del progetto integra tre ingredienti che raramente stanno insieme:
- metodo ingegneristico (FMEA, DRBFM, stage-gate)
- disciplina decisionale (regola dei sette, entry ed exit criteria, pre-mortem)
- igiene cognitiva (contrasto ai bias, gestione del dissenso)
I casi Challenger, 737 MAX, Tacoma Narrows e Therac-25, di cui ti parlerò più avanti, mostrano che quando un riesame della progettazione fallisce, lo fa quasi sempre per gli stessi motivi che sono squisitamente umani e non, come si potrebbe pensare, tecnici.
Cosa chiede il paragrafo 8.3.4 della ISO 9001
Partiamo dalla norma. Il paragrafo 8.3.4 "Controlli della progettazione e sviluppo" della ISO 9001 impone sei obblighi molto concreti. Li metto in fila perché avere chiaro il perimetro normativo è la condizione minima per non sprecare tempo:
- definire i risultati da raggiungere;
- condurre riesami per valutare l'abilità dei risultati di soddisfare i requisiti;
- condurre verifiche per assicurare che gli output della progettazione soddisfino gli input;
- condurre validazioni per assicurare che il prodotto o servizio finale sia adatto all'uso previsto;
- intraprendere le azioni necessarie sui problemi rilevati;
- conservare le informazioni documentate di tutte queste attività.
Una nota della norma precisa che riesami, verifiche e validazioni hanno scopi distinti e possono essere condotti separatamente o combinati. Qui sta la patologia numero uno dei sistemi certificati: la confusione tra i tre concetti. La vedo talmente spesso che ormai è diventata, nel mio lavoro, la prima cosa che verifico quando entro in una nuova organizzazione.
Riesame, verifica, validazione: tre cose che non sono la stessa cosa
Le definizioni ufficiali della ISO 9000, il vocabolario del sistema di gestione, sono nette:
Un esempio per fissare l'idea. Stai progettando una trave per un ponte.
Un calcolo strutturale che confronta lo spessore progettato della trave con lo spessore richiesto dalla normativa di carico è una verifica (è un fatto oggettivo, si può contare).
Un test in galleria del vento su un prototipo di ponte in scala è una validazione (verifica che in condizioni d'uso reali il progetto funzioni).
Una riunione in cui quattro ingegneri strutturisti, un progettista, un rappresentante dell'appaltatore e il responsabile del sistema qualità discutono se il progetto preliminare del ponte risponda ai requisiti di sistema, ai rischi sismici e aerodinamici, e alla vita utile attesa è un riesame.
Il primo è un numero, il secondo è una prova, il terzo è una decisione. Se nel tuo verbale di riesame trovi solo calcoli e test, quello che hai documentato non è un riesame ma una verifica e una validazione.
Il paragrafo 8.3 nel suo insieme: una sequenza logica
Il riesame non è un punto del processo: è un controllo ricorrente che attraversa tutte le fasi della progettazione. Per capirlo davvero è utile guardare come si compone l'intero paragrafo 8.3 della ISO 9001:
La pianificazione (8.3.2) è dove decidi chi partecipa ai riesami e in quali fasi. Gli input (8.3.3) sono quello che il riesame verifica: requisiti funzionali, prestazionali, normativi, esperienze da progetti simili. Gli output (8.3.5) devono essere tracciabili sugli input, con criteri di accettazione e caratteristiche per un uso sicuro. Le modifiche (8.3.6) sono il punto più pericoloso e meno presidiato: la norma richiede che ogni modifica durante o dopo la progettazione sia soggetta allo stesso rigore del design originario. Questa è una lezione che, come vedrai più avanti, Boeing ha pagato a caro prezzo con il 737 MAX.
Consiglio operativo: se nel tuo sistema documentale il riesame compare come «step del processo» tra due altri step, sposta la logica. Il riesame dev'essere descritto come un checkpoint ricorrente che si attiva al completamento di ciascuna fase e al verificarsi di ogni modifica significativa. Questa piccola differenza architetturale cambia completamente il modo in cui le persone lo vivono: non più un'attività «da fare» a un certo punto, ma una porta che bisogna attraversare per proseguire.
Il riesame nelle norme settoriali (automotive, medicale, aerospace)
La ISO 9001 è una norma generalista e, proprio per questo, lascia molti spazi di interpretazione. Quando invece si entra in settori critici come quello medicale, l'automotive o l'aerospace, le regole del gioco si irrigidiscono parecchio e vale la pena conoscerle anche se non ti trovi a lavorare direttamente in uno di questi ambiti perché ti aiutano a capire quale sia lo «standard alto» del riesame della progettazione.
| Norma | Partecipazione indipendente | Fasi esplicite | Output documentale |
|---|---|---|---|
| ISO 9001 (qualità generale) |
Non esplicita | Non esplicite («fasi pianificate») | Sì (paragrafo 8.3.4 lettera f) |
| ISO 13485 (dispositivi medici) |
Sì, esplicita: rappresentanti delle funzioni coinvolte + altro personale specialista | Sì, per stage | Sì, nominativo (chi ha partecipato) |
| IATF 16949 (automotive) |
Multi-disciplinary team obbligatorio | Agganciate ad APQP | Sì, con Control Plan e PPAP |
| AS9100 (aerospace) |
Review formali a gate definiti | SRR, PDR, CDR, TRR, FRR | Sì, gate-by-gate con entry ed exit criteria |
La ISO 13485 per i dispositivi medici, al paragrafo 7.3.4, è particolarmente interessante perché rende esplicito quello che nella ISO 9001 resta implicito: al riesame della progettazione devono partecipare rappresentanti delle funzioni coinvolte e altro personale specialista, indipendente. Le registrazioni sono obbligatorie e nominative: devi sapere chi c'era e cosa ha detto.
La IATF 16949 nel mondo automotive collega il riesame al framework APQP (Advanced Product Quality Planning) e al PPAP (Production Part Approval Process), con il Control Plan come output vincolante. Le AS9100 dell'aerospace ereditano dal mondo della difesa il sistema PDR/CDR (Preliminary Design Review / Critical Design Review) codificato nei documenti NASA con entry criteria formali. Alla ISO 14971 per la gestione del rischio nei dispositivi medici è affidato invece un ruolo specifico: rendere obbligatoria la valutazione del rischio residuo individuale e complessivo durante ogni riesame.
Lezione trasferibile: anche se lavori in una realtà certificata solo ISO 9001, puoi prendere a prestito due pratiche dalle norme settoriali senza aggiungere burocrazia. Primo, registra sempre chi ha partecipato al riesame con ruolo e firma (lezione tratta dalla ISO 13485). Secondo, definisci gli entry criteria ed exit criteria per ogni riesame importante (lezione tratta dall'aerospace): cosa deve essere pronto per tenere la riunione e cosa deve essere chiuso per passare alla fase successiva. Queste due pratiche, da sole, fanno fare un salto di qualità enorme.
Le metodologie che trasformano il riesame in metodo
Un riesame del progetto senza metodo non porta da nessuna parte. Esistono modelli consolidati che strutturano la discussione, impongono consegne e rendono le decisioni difendibili davanti a un auditor o un cliente.
Stage-Gate di Robert Cooper: il padre di tutti i gate
Il più diffuso è lo Stage-Gate® di Robert G. Cooper, costruito su uno studio empirico di 252 progetti in 123 aziende e codificato nel libro Winning at New Products. La logica è semplice: cinque stage (Scoping, Business Case, Development, Testing, Launch) intervallati da cinque gate in cui un gruppo di senior manager cross-funzionali, i gatekeepers, cioè quelli che hanno l'autorità sulle risorse, decidono su quattro possibili esiti:
- Go — si procede alla fase successiva;
- Kill — si chiude il progetto (decisione coraggiosa e spesso evitata, ma essenziale);
- Hold — si sospende in attesa di condizioni diverse;
- Recycle — si torna indietro per rilavorare alcune parti.
I gatekeepers decidono sulla base di must-meet criteria (checklist binarie: o ce l'hai o non ce l'hai) e should-meet criteria (criteri pesati: fit strategico, vantaggio competitivo, fattibilità tecnica, rischio, ritorno economico). I riesami della progettazione formali si inseriscono tipicamente al Gate 3 (prima del pesante investimento in sviluppo), al Gate 4 (test readiness) e al Gate 5 (launch readiness).
DRBFM di Toyota: il riesame che guarda solo a cosa cambia
Accanto al framework dei gate, il riesame si arma di strumenti analitici specifici. Uno dei più potenti e semplici è il DRBFM, acronimo che sta per Design Review Based on Failure Mode, sviluppato dal Prof. Tatsuhiko Yoshimura alla Kyushu University con Toyota. La filosofia non è quella di rifare l'FMEA da zero a ogni modifica, ma concentrarsi esclusivamente sui punti che sono stati modificati e analizzarli in profondità chiedendosi sistematicamente "cos'altro potrebbe cambiare a cascata?"
Il concetto filosofico sottostante è il Mizenboushi, la prevenzione di ciò che non è ancora successo, inserito nel sistema GD³: Good Design, Good Discussion, Good Design Review, un mantra che vale la pena appendere nella sala delle riunioni di progetto.
Stai modificando un componente stabile da anni per ridurne il peso del 15%. Non serve rifare l'FMEA dell'intero sistema (costoso, dispersivo, e probabilmente diresti le stesse cose di tre anni fa) ma un DRBFM focalizzato sui soli effetti del cambio di peso, di materiale e di lavorazione, cercando metodicamente "cos'altro potrebbe cambiare?" a cascata: interfacce con i componenti adiacenti, comportamento in vibrazione, tolleranze di accoppiamento, impatto sul processo di assemblaggio, garanzia del fornitore, compatibilità elettromagnetica. Il 90% dei difetti nelle modifiche nasce lì.
Gli altri strumenti analitici: FMEA, FTA, QFD, DFMA
Gli strumenti principali che il riesame utilizza sono quattro e vale la pena averli tutti nella propria cassetta degli attrezzi:
Le metriche di efficacia: misurare per migliorare
Se vuoi capire se il riesame della tua organizzazione sta funzionando, oltre alla sensazione di «abbiamo lavorato bene» ti servono alcuni indicatori misurabili. I più utili, nella mia esperienza, sono quattro:
- Defect Removal Efficiency (DRE) = difetti trovati pre-release / difetti totali trovati (pre + post). Benchmark best-in-class oltre il 95%, media industriale intorno all'85%.
- Phase Containment Effectiveness = difetti chiusi nella fase in cui sono stati iniettati / difetti totali di quella fase. Benchmark Motorola ≥70%.
- Rework ratio = ore di rework / ore totali di progetto. Un indicatore economico che mette d'accordo quality manager e direzione finanziaria.
- First-pass yield al PPAP (in automotive) o al lancio prototipale: percentuale di pezzi che passano l'approvazione al primo tentativo.
Contaminazioni: red team e Pixar
Le metodologie tecniche danno una struttura ma il riesame di un progetto è anche e soprattutto un atto cognitivo di gruppo. Proprio per questo motivo, lle contaminazioni da altre discipline fanno tutta la differenza del mondo anche perché, ti posso assicurare, funzionano.
Il red team militare
Il red teaming è un gruppo strutturato di outsider con un grande spirito scettico che sfida assunzioni, piani e progetti dall'interno dell'organizzazione. La pratica ha radici militari (la CIA e l'esercito americano la usano dagli anni settanta) e la University of Foreign Military and Cultural Studies di Fort Leavenworth, soprannominata «Red Team University», ne ha codificato le pratiche.
Da questo lavoro emergono sei best practice che sono immediatamente applicabili a un riesame della progettazione aziendale:
- il red team deve essere esterno alla catena decisionale ma consapevole del contesto;
- deve essere composto da scettici coraggiosi ma non da provocatori gratuiti;
- deve essere dotato di una serie di trucchetti che aiutino le persone a riflettere ma che non devono diventare ripetitivi;
- occorre uno sponsor che appoggi davvero il processo;
- l'organizzazione deve essere disposta ad ascoltare le cattive notizie;
- va sottolineato tutto ciò che serve ma niente di più
Come implementare il red team in un riesame della progettazione: due-quattro persone esterne al progetto (altri dipartimenti aziendali, consulenti esterni, auditor interni non coinvolti), che non riportino al project manager del progetto, con un mandato formale, che intervengano prima del gate critico (non all'ultimo minuto, quando tutto è già stato deciso) e che producano un documento separato che riassuma le vulnerabilità identificate e che sia distinto dal verbale ordinario del riesame di progetto.
La Braintrust di Pixar
Ed Catmull, cofondatore di Pixar e autore di Creativity, Inc., ha codificato un principio che dovrebbe essere appeso in ogni ufficio tecnico: la Braintrust è un gruppo di colleghi con una grande esperienza che si riuniscono regolarmente per dare un feedback sui film in lavorazione ma che non ha alcuna autorità dato che il regista non è tenuto a seguire alcuno dei suggerimenti ricevuti.
La scelta di rimuovere l'autorità da chi offre un feedback è ciò che rende possibile la sincerità assoluta. I principi trasferibili al riesame della progettazione sono cinque e li trovo tutti preziosissimi:
- separare la persona dalle sue idee: "non sei la tua idea, quindi criticare l'idea non significa criticare te";
- focalizzarsi sul problema, non sulla persona: dire "questa scena non funziona" mai "tu non sai scrivere";
- notare ciò che è sbagliato, mancante o poco chiaro, senza prescrivere le soluzioni: le soluzioni restano al progettista;
- escludere eventuali presenze intimidatorie: Catmull escludeva lo stesso Steve Jobs quando un regista stava per ricevere feedback, perché la presenza del capo distorce quasi sempre il dialogo;
- accettare che le prime versioni siano brutte: Catmull parla apertamente di passare "da qualcosa che fa schifo a qualcosa di decente". Non c'è nessuna vergogna se le cose all'inizio non funzionano
I disastri insegnano
Studiare ciò che non ha funzionato in precedenza è la forma più economica di apprendimento. Nella storia dell'ingegneria, cinque casi meritano di essere conosciuti da chiunque si occupi di sistemi di gestione, perché mostrano come i disastri non nascano quasi mai da errori tecnici isolati ma da problemi che spesso fanno capo proprio al riesame della progettazione.
La notte del 27 gennaio la teleconferenza tra Morton Thiokol e la NASA fu, di fatto, un riesame del progetto. Roger Boisjoly e altri ingegneri Thiokol raccomandarono un sonoro «NO-GO» per temperature sotto i 53°F (11,7°C) ma erano previsti 26-29°F (-3/-1°C). La reazione del management della NASA è registrata negli atti: George Hardy disse "Sono sconvolto da ciò che dite" e Lawrence Mulloy aggiunse "Mio Dio, Thiokol, quando vuoi che effettui il lancio, ad aprile?"».
Il manager Jerald Mason disse testualmente al vicepresidente Bob Lund: "Toglietevi il cappello da tecnici e mettetevi quello da manager". La raccomandazione passò da NO-GO a GO e sette astronauti morirono 73 secondi dopo il decollo.
Lezione operativa: mai accettare l'inversione dell'onere della prova, cioè il passaggio da "dimostra che volare è sicuro" a "dimostra che volare non è sicuro". Il "cappello da manager" non deve mai coprire quello della sicurezza. Mai.
Due schianti (Lion Air 610 e Ethiopian 302) per un totale di 346 morti. Il Final Report del House Committee on Transportation and Infrastructure del 16 settembre 2020 identifica cinque temi centrali: pressione sulla produzione, assunzioni errate in fase di progettazione, cultura dell'occultamento, conflitto di interesse nell'ODA (Organization Designation Authorization) e influenza di Boeing sulla struttura di vigilanza FAA.
Il sistema MCAS era nato come dispositivo ad autorità limitata per alte velocità e fu riclassificato in corso d'opera con autorità di trim molto più ampia e attivazione anche a bassa velocità, senza una nuova analisi completa della sicurezza. Il sistema dipendeva da un singolo sensore e Boeing nascose alla FAA che un proprio pilota in fase di test aveva impiegato oltre 10 secondi per diagnosticare un'attivazione non comandata del sistema (le linee guida federali richiedono un massimo di 4 secondi).
Lezione operativa: ogni modifica richiede una nuova design review completa, non superficiale. Un single point of failure su sensori critici è una red flag assoluta. Chi effettua il riesame non deve dipendere gerarchicamente o economicamente da chi lo subisce (era esattamente il problema dell'ODA).
Il Carmody Board del marzo 1941 concluse che il ponte crollò per flutter aeroelastico torsionale perché il riesame della progettazione considerò solo carichi statici e teoria della deflessione, ignorando completamente l'aerodinamica; prima della costruzione non furono eseguiti test nella galleria del vento; i suggerimenti dell'Università di Washington, che avevano provato a mettere in guardia su un modello in scala 1:200, furono respinti.
Lezione operativa: una design review ben fatta si chiede sistematicamente "quali fenomeni fisici NON sono stati valutati?" I test su un prototipo in condizioni che replicano l'ambiente d'uso reale sono parte integrante del riesame, non un'aggiunta opzionale che si taglia quando non ci sono più risorse.
Sei dosi massive di radiazioni da parte di un acceleratore medico, diversi decessi. Nancy Leveson e Clark Turner nel loro articolo del 1993 su IEEE Computer identificarono una catena di errori:riuso di codice dalle versioni precedenti con modifiche non documentate, rimozione dei blocchi hardware di sicurezza che erano presenti nel predecessore (facendo affidamento solo sul software), messaggi di errore criptici tipo «Malfunction 54» che si potevano bypassare semplicemente premendo il tasto «P».
Lezione operativa: non rimuovere mai i controlli hardware di sicurezza affidandosi solo al software senza un riesame del progetto che dimostri un'equivalenza del livello di rischio. Un riesame del codice indipendente e l'analisi della concorrenza sono una parte non negoziabile del riesame di un software così critico per la sicurezza. Occorre anche un feedback loop strutturato dai siti di installazione verso il team di progettazione: quando un operatore segnala un'anomalia, qualcuno deve ascoltare.
Il crollo della passerella sospesa dello Hyatt Regency causò 114 morti e 216 feriti: al tempo, il più grave disastro strutturale della storia degli USA. Una modifica in corso d'opera richiesta dal fabbricante per semplificare l'assemblaggio raddoppiò il carico su una connessione critica e l'ingegnere che fece il riesame del progetto appose il sigillo sulla modifica senza rifare i calcoli.
Lezione operativa: ogni cambiamento durante la costruzione o la produzione deve attivare un riesame del progetto formale con nuovi calcoli.
I dieci passi per organizzare un riesame di progetto che funzioni
E arriviamo ora alla parte più operativa di questo articolo: come organizzo concretamente un riesame della progettazione che funzioni al meglio. Il riesame funziona quando la riunione inizia con tutti gli stakeholder già allineati per ciò che riguarda i dati e che dissentono solo sulla loro interpretazione. Questo si ottiene con una sequenza di dieci passi:
- Definisci in una frase lo scopo del riesame del progetto "Questa review deciderà se X può passare a Y". Senza questa frase in apertura, la riunione diventa solo l'ennesimo aggiornamento di avanzamento del progetto. Se non riesci a scriverla in una riga, vuol dire che la riunione non è ancora matura per essere convocata.
- La regola del sette per selezionare i partecipanti Lo studio di Blenko, Mankins e Rogers di Bain & Company, pubblicato nel libro Decide & Deliver, mostra che, quando si riuniscono oltre sette decisori nella stessa stanza, ogni partecipante aggiuntivo riduce l'efficacia decisionale del 10%.
- Scrivi i criteri in ingresso e in uscita I criteri in ingresso sono i prerequisiti senza i quali il riesame non si può tenere: la documentazione completa del progetto già distribuita ai partecipanti, il registro dei rischi aggiornato, i test di verifica chiusi, l'FMEA revisionata. I criteri in uscita sono le condizioni necessarie per chiudere positivamente la review.
- Distribuisci i materiali da 5 a 10 giorni prima Specifiche, disegni, calcoli, FMEA, registro dei rischi, ordine del giorno, criteri in uscita, stato delle azioni aperte dal riesame precedente. Richiedi esplicitamente la lettura preventiva in modo che le persone arrivino già con le domande, senza scoprire in quel momento le caratteristiche del progetto.
- Definisci un ordine del giorno di 2-3 ore massimo Per un riesame di progetto tipo: 15 minuti per l'apertura e la verifica dei criteri in ingresso; 30 per lo stato del progetto e per la chiusura delle azioni precedenti; 45 per i requisiti e la tracciabilità; 60 per la progettazione di dettaglio; 45 per affidabilità e gestione del rischio; 45 per produzione e catena di fornitura; 30 per costi e programmazione; 45 per la raccolta di ciò su cui non si concorda; 30 per il consolidamento delle azioni da compiere; 30 per la decisione finale.
- Conduci la riunione con regole chiare Un punto alla volta: registra ciò che non convince, non le soluzioni (le soluzioni arrivano dopo, dal team di progetto).
- Registra le decisioni con una tassonomia esplicita Ci sono solo quattro esiti possibili: approvato / approvato con azioni / richiesta rilavorazione del progetto / respinto. La differenza tra "approvato con azioni" e "richiesta rilavorazione del progetto" è nella natura delle azioni: se sono minori e verificabili solo tramite una revisione dei documenti siamo nel primo caso, altrimenti siamo nel secondo.
- Compila la lista delle azioni con un responsabile singolo Niente "gruppo X" o "team Y": per ogni azione: ID univoco, descrizione, responsabile (persona, non reparto), deadline, priorità, criterio oggettivo di verifica. Aggiorna contestualmente il registro dei rischi del progetto.
- Archivia secondo la ISO 9001 punto 7.5 Ogni informazione deve far risalire a chi ha fatto cosa, deve essere leggibile, deve essere esatta, completa, capace di durare nel tempo e disponibile per chi ne ha bisogno.
- Chiudi il loop con un follow-up strutturato Monitoraggio settimanale delle azioni. Ogni chiusura di azione richiede un'evidenza oggettiva.
Le trappole ricorrenti del riesame
Le trappole ricorrenti del riesame della progettazione sono, più o meno, sempre le stesse. Le elenco perché riconoscerle è il primo passo per evitarle:
Le dieci trappole che fanno fallire un riesame di progetto:
1. Recita — si mette in piedi un teatrino per l'auditor, non per il prodotto.
2. Groupthink — nessuno osa contraddire i senior in stanza.
3. Mancanza di occhi esterni — tutti i partecipanti hanno lavorato sul progetto e non c'è nessun esterno.
4. Riesame fatto troppo tardi — quando cambiare costa troppo
5. Criteri di accettazione soggettivi o assenti — "a me sembra ok" non è un criterio.
6. Confusione tra riesame, verifica e validazione — la madre di tutte le trappole.
7. Pressione — la fretta che comprime la qualità della discussione.
8. Documentazione ridondante — spesso nasconde l'assenza di sostanza.
9. Modifiche trattate come irrilevanti — il caso dell'Hyatt Regency.
10. Inversione dell'onere della prova — il caso Challenger, quando "dimostra che è sicuro" diventa "dimostra che non è sicuro".
La checklist operativa scaricabile
Per rendere tutto questo immediatamente utilizzabile, ho preparato una checklist operativa in Excel che è la sintesi metodologica di tutto quello che ti ho raccontato finora e che puoi adottare subito per il prossimo riesame di progetto.
Checklist per il riesame della progettazione
template Excel con 10 fogli: criteri in ingresso e in uscita, agenda-tipo time-boxed, matrice RACI precompilata, checklist dei requisiti normativi (ISO 9001 punti 8.3.4, 8.3.6 e 6.3), griglia di domande, protocollo pre-mortem, template Red Cell memo, tracker delle azioni, indicatori di efficacia e verbale finale.
⬇ scarica la checklist (Excel)Usala integralmente o adattala a pezzi al tuo contesto. Quello che conta non è compilare tutti i fogli ma sviluppare l'abitudine a ragionare con quella struttura. Se la utilizzi bene, il paragrafo 8.3.4 della ISO 9001 è coperto con un margine abbondante ma, soprattutto, il tuo sistema di gestione diventa davvero capace di prevenire errori costosi.