[Part of a baby car]
Kwaliteit: wat is voldoende voor welke prijs?
In 1998 leerde ik de kreet MOSQUITO, wat staat voor Money, Organisation, Safety, Quality, Information en Time. Quality is vanzelfsprekend één van de aspecten waar je als projectmanager rekening mee moet houden. Het is misschien wel de belangrijkste grootheid uit het duivelsvierkant: je project kan op tijd en binnen budget de gevraagde resultaten hebben opgeleverd, maar als de kwaliteit hiervan niet overeenkomt met de (onuitgesproken) verwachting van je opdrachtgever, dan heb je het toch slecht gedaan. De kwaliteitsbeleving is datgene wat nog blijft hangen lang na het afronden van het project.
In veel projectplannen / project initiatie documenten die ik heb gelezen komt het hoofdstuk 'Kwaliteit' er maar bekaaid af; of er wordt verwezen naar een niet onderhouden kwaliteitshandboek of er staan een aantal algemeenheden in die gekopieerd zijn uit eerder geschreven projectplannen.
Maar wat is kwaliteit nu precies? Ik denk dat kwaliteit zich het beste laat vertalen met voldoende aandacht, en dan bedoel ik met aandacht vooral de tijd die er in gestoken wordt. Maar wat is voldoende? Dat kan ik het beste uitleggen met het volgende voorbeeld. Misschien heb je wel eens met een huilende baby op je arm gestaan, net voordat je zelf wilde gaan slapen. Al wiegend krijg je je baby wel in slaap, maar doe je dit tekort, dan begint het huilen opnieuw, zodra je je baby in de wieg legt. En als je dit te lang doet, dan kost het je misschien een uur extra van je eigen slaap. Proefondervindelijk zal je dus moeten uitvogelen wat voldoende tijd/aandacht is. En dat verschilt per kind en per situatie.
In de testtheorie hebben we hiervoor de S-kromme. Op de X-as zet je dan de tijd uit, en op de Y-as het aantal gevonden fouten. In het begin zal je per tijdseenheid weinig fouten vinden, omdat je de testomgeving nog aan het opzetten bent, etc. Op een bepaald moment ga je veel meer fouten vinden, maar dit aantal vlakt af als je langer doortest en op een bepaald moment vind je helemaal niets meer. Hier is het de kunst om te stoppen met testen zodra het aantal fouten afvlakt.
Kwaliteitscontrole kan je ook overdrijven. Bij een opdrachtgever, waar ik voor werkte, werd de FAGAN-inspectiemethode gebruikt. Bij deze methode wordt een vergadering belegt met de schrijver van een stuk, een voorzitter (moderator), een notulist en alle personen die het stuk al eerder hebben beoordeeld/gereviewed. Doel is om zoveel mogelijk fouten/defects te vinden. Die schrijver mag alleen verduidelijking geven, maar zijn stuk vooral niet verdedigen of in discussie gaan. De moderator bewaakt dit proces en bepaalt het tempo waarin het stuk alinea voor alinea wordt doorgelopen. De notulist maakt hiervan een inspectierecord met alle opmerkingen over dat er tekst mist, tekst niet klopt, tekst overbodig is, etc., voorzien van volgnummer, bladzijdenummer en regelnummer. Het inspectierecord wordt later door de schrijver aangevuld met wat deze met de genoemde defects heeft gedaan en teruggekoppeld aan de deelnemers van de FAGAN-inspectie.
FAGAN-inspecties werken uitstekend, maar zijn duur om uit te voeren, vanwege het aantal mensen en de tijd die er in gaat zitten. Voor sommige documenten was dit echt overkill en was een 'normale' review voldoende.
In een projectplan zou je dus per op te leveren (deel)product verwachten hoe de kwaliteit van dit product getoetst wordt (normale review, FAGAN-inspectie, etc.), door wie/welke rollen getoetst wordt, op basis van welke criteria, en wie dan uiteindelijk het (deel)product een definitieve status mag geven. De uitdaging is om dit proces met de opdrachtgever te doorlopen, zodat vooraf duidelijk is welke (deel)producten worden opgeleverd, hoe hiervan de kwaliteit wordt bepaald en wat dan voldoende kwaliteit is.
[Logboek]
Oudere blogs
- First thing first (augustus 2014)
- Duivelsvierkant in de supermarkt (september 2014)