Als we het hebben over kwaliteit binnen projecten zie je veel wenbrauw fronzen en ogen staren omdat we dat verbinden met geavanceerde statistiek, controle diagrammen en process control theorien.

De uitdaging is, natuurlijk, dat een statistisch controle proces goed past bij een productie bedrijf (of proces) waar sprake is van consistentie, herhaling en betrouwbaarheid. Projecten spelen zich af in een compleet ander context, ze zijn van nature inconsistent, niet herhalend en (betwistbaar) onbetrouwbaar.

Is dan alle hoop verloren voor kwaliteit management binnen projecten? Moeten we ons er bij neerleggen en het maar vergeten? Of is er een betere manier om kwaliteit te meten en besturen?

Kwaliteitsmanagement = begrijpen van defecten

In basis gaat kwaliteitsmanagement over het begrijpen van defecten. Over het algemeen is een defect een afwijking van de basis scope van het project. Letterlijk gesproken, het inpassen van niet geplande uitbreidingen, zo ook features die niet werken zoals gepland. Voor deze blog hou ik het bij de dingen die niet werken en binnen project gerepareerd moeten worden.

De meeste mensen denken dat defecten naar voren komen en bestuurd worden doordat er getest wordt. Bijvoorbeeld, iemand schrijft een stuk programma-code, een ander vind een probleem en het probleem wordt in het incident proces gestopt zodat een ander het kan repareren. Binnen de meeste projecten is een erg goed 'tracking'-mechanisme voor problemen die tijdens testen worden gevonden.

Kwaliteit in de hele lifecycle

Kwaliteitsmanagement kan hier waarde toevoegen, door het inzetten van dit idee op de hele lifecycle van het project. Het vastleggen van problemen waar en wanneer ze worden gevonden moet altijd plaatsvinden. Het speuren naar defecten is niet alleen een onderdeel van het test proces, maar een proces dat toegepast kan worden op elk kwaliteitsbewakings activiteit: inspecties, reviews, walkthroughs en andere activiteiten.
De waarde in het tracken van defecten is niet alleen in wáár het defect is gevonden. Om echt waardevol te zijn moeten we begrijpen wat het defect veroorzaakt. In welke activiteit -of praktischer in welke fase- is het defect ontstaan? Werd het defect veroorzaakt door verkeerde requirements (of uitgangspunten), was het ontwerp incorrect of omdat iemand een verkeerde handeling uitvoerde?

De belangrijke requirementsfase

Als we, voor elke defect, vastleggen wat zowel de kwaliteits bewakingsactiviteit is en de bron van het defect, dan krijgen we een extreem duidelijke statistieken over het project.
Bijvoorbeeld: in een review van een recent afgerond project werd vastgesteld dat het merendeel van de defecten gevonden werd tijdens het testen. Een groot deel is veroorzaakt in het ontwerp en nog meer defecten in de requirements fase. Als dat het geval is dan betekent dit er iets mis is met de fase waarin we requirements vastleggen.

Is er te weinig inspanning geweest om de requirements vast te leggen, of is de informatie niet van de juiste personen gekomen? Wellicht zijn de requirements niet gevalideerd, of heeft iemand zijn mening gewijzigd? Waar we mee te maken hebben is een scenario waarin defecten vroeg het proces worden gecreeerd en vrij laat worden gevonden.
De consekwentie is dat het defect een tijd blijft bestaan. Om een fout in de requirements op te lossen die in de test fase wordt gevonden betekent dat we terug moeten vaststellen wat de requirement moet zijn. Gebaseerd op het aangepaste requirement is de volgende stap om te controleren en vast te stellen welke gevolgen dit heeft voor het ontwerp en reeds afgeronde delen van het project. Elke aspect van het proces moet overnieuw worden gedaan, tot het punt waar het defect is gevonden. Dit is niet alleen een boel werk, maar hetzelfde werk nóg een keer.

Lessons learned

De lessen uit dit project zijn tweezijdige:
Enerzijds; wat kunnen doen om het vaststellen van requirements te verbeteren?
Anderzijds; Hoe kunnen we defecten eerder opsporen?
Mischien moeten we zekerstellen dat er meer tijd aan wordt besteed, want een analyse van onze inspanning om requirements op te stellen toont aan dat we te agressief zijn om de volgende stappen in het project uit te voeren. Of zijn er problemen met het vaststellen en raadplegen van de stakeholders rondom het project. Met deze informatie kunnen we het huidige project niet verbeteren, maar het geeft ons een fantastisch inzicht in hoe volgende projecten verbeterd kunnen worden.

Net zo belangrijk, wat kunnen we doen om het defecten eerder op te sporen? Idealiter zou een defect in requirements opgespoord worden in de requirementsfase. Als een defect later wordt gevonden is reparatie duurder. Door weinig te doen aan kwaliteitsbewaking vroeg in het project, dan is dat een sterke indicator om verandering door te voeren in het accepteren van requirements.

Kosten besparen door registratie van defecten

Het gebruiken van twee basisgegevens over defecten, wanneer is het gevonden en waar is het veroorzaakt, geeft de kans om met heel weinig kosten kostbaar inzicht te creeren. Zonder gebruik van statistieken of controle diagrammen krijgen we een beter zicht op de werking van onze projecten en hoe de oplevering van projecten kan worden verbeterd. Als we de meeste uitdagingen ondervinden in het opstellen van de project 'deliverables' en succesvol zijn om ze te identificeren dán zijn we over projecten aan het leren.

Door beter te leren van onze ervaringen, kunnen we beter worden. Het gaat tenslotte om op een eenvoudige manier te verbeteren, of niet?
Bron: Managing for quality, Mark E. Mullaly

Meer informatie over kwaliteitsmanagement en projecten? Neem contact met ons op.