Kwaliteit is een subjectief begrip. Als een project de afgesproken doorlooptijd en het afgesproken budget ver overschrijdt, maar wel een kwalitatief goed eindresultaat oplevert, is de projectkwaliteit dan goed? Nee, zul je zeggen, want met genoeg tijd en geld kun je altijd wel het gewenste resultaat bereiken. Vaak worden in een project de aspecten tijd, geld en kwaliteit onderscheiden. Het aspect kwaliteit staat op zich. Het heeft betrekking op het op te leveren resultaat. De kwaliteit kan goed zijn terwijl op de aspecten tijd en geld grote overschrijdingen zijn.
Kwaliteitsproblemen zijn vervelend. Ze kunnen zich uiten in:
Het oplossen van kwaliteitsproblemen is lastig; alleen als het probleem bekend is, is er wat aan te doen. De meeste klanten echter klagen niet, maar komen niet meer terug en praten erover met anderen. Bovendien is het achteraf oplossen van kwaliteitsproblemen duur; veel duurder dan het voorkomen van de problemen.
Als er zich geregeld kwaliteitsproblemen voordoen en als deze hardnekkig blijken te zijn, overweegt je dan om de kwaliteitsborging anders en explicieter te gaan organiseren.
Dit artikel geeft een theoretisch én praktisch kader voor QA en gaat in op hoe de QA-functie ingericht kan worden in een organisatie en hoe dit succesvol kan gebeuren.
De woorden (quality) assurance en (kwaliteits)borging worden vaak gebruikt, in allerlei sectoren, maar opvallend vaak in food, farma en ICT. In de praktijk blijken ze lang niet altijd de betekenis te hebben die je zou verwachten. Blijkbaar zijn het woorden waarvan men vindt dat ze wel goed klinken en die creatief gebruikt kunnen worden, zoals dat uitkomt. Met een beetje zoeken zijn er al snel verschillende betekennissen te vinden voor het woord borg:
Het woord kwaliteit is nog meer een containerbegrip, en betekent dus eigenlijk niets zonder verdere context. (Zie ook het artikel ‘Betere software door product- of proceskwaliteit’.)
Onder kwaliteit verstaan we in dit artikel:
voldoen aan afspraken en voldoen aan impliciete eisen en verwachtingen.
Onder kwaliteitsborging verstaan we:
De verantwoordelijkheid voor het leveren van kwaliteit verschuift dus niet als er kwaliteitsborging wordt gedaan c.q. als de QA functie is ingericht. De leverende partij (lijn, project, leverancier) blijft verantwoordelijk voor de kwaliteit. QA is een (staf)functie welke verantwoordelijk is voor toetsen en voor herstellen en voorkomen van kwaliteitsafwijkingen.
Omdat het ofwel technisch ofwel bedrijfseconomisch onmogelijk is om alle processen en producten volledig te controleren op alle kwaliteitsaspecten, worden keuzes gemaakt in wat de QA functies controleert en hoe de QA functie dit doet. Gebruikelijk is om op basis van risicoafweging, keuzes te maken in verificatie- en validatietechnieken en in intensiteit waarin deze toegepast moeten worden (steekproefgrootte en interval).
Het is dus heel goed mogelijk dat, ook met een goed ingerichte QA functie, zich tot nog kwaliteitsproblemen voordoen.
QA is kort gesteld:
uitvoeren van de CHECK en toezien op ACT in de verbetercyclus.
We geven in dit artikel 3 normenkaders voor kwaliteitsborging:
ISO 9001:2008 is een veelgebruikte, algemeen geldende norm voor kwaliteitsmanagement-systemen. De eisen in deze norm beslaan 16 bladzijden tekst, waarvan 3 bladzijden de kwaliteitsborging betreffen (het driehoekje in bovenstaande figuur). De norm zelf spreekt niet over (kwaliteits)borging, maar noemt het hoofdstuk “Meting, analyse en verbetering”. De norm schrijft voor dat een organisatie de klanttevredenheid moet meten (zie het artikel ‘Tevredenheidsonderzoeken’), interne audits moet uitvoeren en zowel processen als producten moet monitoren en meten en op basis van analyse van verkregen gegevens correctieve en preventieve maatregelen moet nemen om afwijkingen op te heffen en te voorkomen.
Prince2 is een standaard voor projectmanagement. Het biedt een integrale en samenhangende aanpak voor de besturing, beheersing, inrichting, fasering en verantwoording van en door projecten. Prince2 heeft een duidelijke visie op productkwaliteit en projectborging.
Prince2 schrijft voor dat de resultaten van een project in de beginfase duidelijk en systematisch worden gedefinieerd in een productbreakdownstructure en dat de op te leveren producten worden beschreven, inclusief de kwaliteitscriteria. Van elk product wordt vooraf vastgelegd op welke wijze de kwaliteit zal worden getoetst.
De leden van de project board (stuurgroep) hebben de verantwoordelijkheid om de resultaten van het project inhoudelijk te toetsen en toezicht te houden op het project, onder meer door:
Prince2 noemt dit project assurance (projectborging). Dit is een ruimer begrip dan kwaliteitsborging. Het omvat namelijk ook borging van de aspecten (doorloop)tijd en geld.
CMMi is een standaard voor de ontwikkeling van IT-producten en is, net als het INK-managementmodel, een model met vijf volwassenheidsniveau. Op elk van die vijf niveaus zijn de eisen verdeeld in Key Proces Areas (KPA’s). Een KPA van level 2 (dus feitelijk een must voor elke IT-ontwikkelorganisatie) is Process en Product Quality Assurance (PPQA). Het doel van PPGQ is om de staf en het management objectief inzicht te bieden in de processen en gerelateerde producten. Quality Assurance houdt volgens CMMi in:
CMMi schrijft niet voor hoe de QA-functie ingericht wordt, wel dat deze objectief moet zijn. Gebruikelijk is dat er een onafhankelijke QA-groep bestaat. Maar in kleine organisatie en in organisaties die erg kwaliteitsgericht zijn, kunnen de QA-werkzaamheden ook worden geïntegreerd in het voortbrengingsproces.
De 3 normenkaders voor QA voldoen aan de eerder gegeven definitie van kwaliteitsborging, maar zijn verschillend qua diepgang en accenten. Met de keuze voor een norm bent je er echter nog niet.
Voor de inrichting van de QA-functie bestaat geen kant en klaar recept. Een goede inrichting hangt af van de volgende factoren:
Voor QA zijn tal van monitoring- en meetinstrumenten beschikbaar. De kunst is deze RESULTAATgericht toe te passen. Dit pleit ervoor te starten met een centrale inrichting van de QA-functie, zeker als organisaties nog weinig ervaring hebben met QA. Dit biedt betere mogelijkheden om de QA-taken goed uit te voeren en hiermee het gewenste effect te bereiken. Naarmate de organisatie volwassener en kwaliteitsgerichter wordt en er meer kennis binnen de organisatie aanwezig is, kan de QA functie geleidelijk gedecentraliseerd worden.
Vaak is het doel van QA, in eerste instantie, om snel resultaten te behalen en veranderingen te bewerkstelligen, bij voorbeeld:
In eerste instantie is het goed om de focus te leggen op de producten (zijn de producten aanwezig en voldoen deze aan gestelde eisen) en daar waar bepaalde producten ontbreken (bij voorbeeld beheerdocumentatie) of niet voldoen aan normen op onderzoek van het proces, met als doel oorzaken te achterhalen. Focus op productkwaliteit begrijpt iedereen en roept minder weerstand op dan focus op proceskwaliteit. Later, nadat QA zich bewezen heeft, kan de focus verlegd worden naar proceskwaliteit.
Voor uitvoeren van QA-activiteiten is het nodig om een eenduidig normenkader te hebben. In eerste instantie wordt de normenset beperkt tot de essentie: welke producten moeten beschikbaar zijn, wat zijn de belangrijkste (kwaliteits)eisen die aan de producten worden gesteld en op welke wijze dient de kwaliteit beheerst te worden (QC, Quality Control).
Meestal zijn er met een beperkte normstelling al veel afwijkingen te constateren. Het is een valkuil om veel tijd te besteden aan genuanceerde normenkaders en aan procedures hoe hier mee om te gaan. Verstandiger is om te starten met een beperkte set aan ondubbelzinnige normen en het toetsingskader pas uit te breiden zodra de eerste set weinig afwijkingen meer oplevert. Op deze manier snijdt het mes aan twee kanten: Enerzijds kan men al snel beginnen met de monitoring van activiteiten en op basis van gevonden afwijkingen snel verbeteringen doorvoeren, anderzijds kunnen de ervaringen gebruikt worden om het toetsingskader te verdiepen.
Een zinvolle QA-aanpak voor de korte termijn is dan ook vaak om te starten met het invoeren van interne kwaliteitsaudits, onder leiding van de QA-manager, met de volgende kenmerken:
De interne QA-auditors moeten uiteraard getraind worden en begeleid worden, als zij nog geen ervaring hebben. Voor meer informatie over interne auditing zie het artikel ‘Interne auditing: veel compliance, weinig verbetering’. Voorwaarde is enige senioriteit van de QA-medewerkers (zowel met de producten als met de bedrijfsprocessen en natuurlijk affiniteit met kwaliteit). Dit is nodig om “overeind te blijven” in de interviews en de nabespreking van het auditrapport, en ook om de interne QA-audits uniform, effectief en efficiënt uit te voeren. Het op uniforme wijze uitvoeren van de interne QA-audits is belangrijk om de verkregen inzichten te kunnen aggregeren en trendanalyses te kunnen doen.
Met deze systematiek kunnen QA-resultaten snel zichtbaar worden gemaakt.
QA is succesvol als verbeteringen (die nodig zijn om op het gewenste kwaliteitsniveau te komen) worden doorgevoerd. Het succes van de QA wordt bepaald door:
QA is interessant en leuk. Bedenk dat QA ongekende kansen biedt jouw organisatie te verbeteren. QA’ers kunnen de afstand van werkvloer naar directie overbruggen en op basis van objectieve informatie verbeteringen initiëren. Succes!