Vijf manieren om je QA-input bruikbaar te maken in je project

Jaren geleden zat ik in een team dat een sproeidroog installatie ontwierp. Er zat een filter in dat gevoelig was voor microbiologische besmetting, en engineering wilde er een inspectieluik in.

Ik wilde dat niet. Wat binnen de installatie blijft, kan de omgeving niet besmetten, dacht ik.

Maar onderhoud kon niet zonder dat luik, en dat was een geldig argument. Een filter dat je nooit fatsoenlijk kunt onderhouden is ook een risico, alleen zie je dat risico pas veel later.

We kwamen samen uit op zes bouten. Geen klemsluiting die je even openklikt, maar een luik dat alleen openging als een monteur er met gereedschap de tijd voor nam.

De engineer keek me aan en zei: goed, maar dan noemen we het luik wel naar jou.

Wat me daarvan is bijgebleven, is niet dat ik gelijk kreeg, want dat kreeg ik niet.

Wat me is bijgebleven, is dat mijn bezwaar bruikbaar was.

Er zat een reden onder die iemand anders kon wegen, en er lag een alternatief naast.

Waarom dat verschil maakt

In een ontwerpoverleg wordt van alles tegen elkaar afgewogen.

Reinigbaarheid, onderhoudbaarheid, kosten, ruimte, doorlooptijd, veiligheid.

Iedereen aan tafel brengt iets in wat gewogen kan worden.

Voedselveiligheid komt vaak binnen als een verwijzing naar een norm.

En dat is het enige argument in de kamer dat je niet kunt wegen.

Je kunt het aannemen of betwisten, meer niet.

Dan word je niet genegeerd. Dan heeft het projectteam iets gekregen waar het weinig mee kan.

Hieronder vijf dingen die daar verschil in maken. Ze kosten geen budget en ze vragen geen mandaat.

1. Geef een productargument in plaats van een normverwijzing

"Dat mag niet van BRCGS" leidt tot een discussie over interpretatie, en de norm laat nu eenmaal ruimte.

"Dit product krijgt na deze stap geen verhitting meer, dus alles wat hier binnenkomt zit in het eindproduct" is iets anders. Dat is een feit over het proces, en daar kan een engineer iets mee.

De norm blijft natuurlijk gelden. Maar het is je onderbouwing, niet je argument.

2. Maak het concreet genoeg om mee te werken

"Hygiëne is hier belangrijk" is een zin waar iedereen het mee eens is, en daarom verandert er niets.

"Dit luik zit op vier meter van de High Care deur en kan tijdens productie open" geeft het team iets om over na te denken.

Een bruikbare vuistregel: als je bezwaar ook op een andere fabriek van toepassing zou zijn, is het waarschijnlijk te algemeen om er iets mee te doen.

3. Breng een richting mee, geen slotsom

Een nee sluit het gesprek. Een derde optie opent het.

Bij dat luik werd de bruikbare oplossing pas zichtbaar op het moment dat ik ophield met tegenhouden en begon met meedenken over hoe het dan wel kon.

Niet omdat ik toegaf, maar omdat er twee geldige belangen op tafel lagen en er nog geen oplossing was die aan allebei recht deed.

Die oplossing bedenk je zelden alleen. Dat is ook niet nodig.

Je hoeft de oplossing niet te hebben, je hoeft alleen de vraag goed te stellen: kan deze handeling verdwijnen, kan hij buiten de zone, en als het antwoord op allebei nee is, hoeveel moeite mag het dan kosten?

4. Kom op het moment dat aanpassen nog goedkoop is

Hetzelfde argument kost het projectteam in elke fase iets anders.

• Basic engineering: een middag tekenen.
• Detail engineering: een week, en het opnieuw afstemmen van wat eromheen zat.
• Bouw: geld dat al is uitgegeven.
• Na oplevering: een lijn die stil moet.

Dat is geen kwestie van wie er gelijk heeft. Vroege input is voor iedereen goedkoper, en dat is een argument dat je ook zo kunt brengen.

Praktisch: vraag aan het begin van een project wanneer de layout, de sluizen en de luchtbehandeling worden vastgelegd, en zet die momenten in je agenda.

Het projectteam weet vaak niet vanzelf wanneer jouw inbreng nodig is, en die momenten staan zelden ergens opgeschreven.

5. Zorg dat de onderbouwing bewaard blijft

Een mondeling bezwaar bestaat na de vergadering niet meer.

Zes weken later moet er misschien ruimte of budget worden ingeleverd, en stelt iemand voor om een sluis te schrappen. Op dat moment zit jij daar niet altijd bij. De vraag is dan niet of jij het er destijds mee eens was, maar of iemand nog weet waarom die sluis er stond.

Daarom is de onderbouwing van een zone geen administratie.

Ze is wat je collega's in staat stelt om zonder jou een verstandig besluit te nemen.

Praktisch: één regel per ruimte volstaat. Welk product, is het blootgesteld, hoe gevoelig, en volgt er nog een eliminatiestap. Dat is genoeg om het gesprek zes weken later opnieuw te kunnen voeren. En bij de audit scheelt het je ook nog een middag. 

Wat hier nog onder ligt

Deze vijf punten gaan over de manier waarop je je inbreng vormgeeft. Er zitten drie vragen onder waar deze blog niet aan toekomt.

1.Waarom goede zonering in projecten toch sneuvelt, terwijl de normen alles al voorschrijven.

2. Wat je nog kunt doen wanneer de fabriek er al staat.

3. Wat er gebeurt op het moment dat de zonering bewust wordt doorbroken, bijvoorbeeld wanneer er wordt gebouwd terwijl de lijn draait.

Die staan uitgewerkt in mijn whitepaper over zonering in engineeringprojecten. Klik op de link om de whitepaper te downloaden: