Projecten doen en kwaliteit nastreven. Zo’n 10 jaar geleden ontdekte ik dat Prince2 daar een alleraardigste antwoord op had gevonden, met een duidelijke logische taxonomie. De klant heeft klantverwachtingen en die verwachtingen worden geoperationaliseerd naar acceptatiecriteria. De leverancier levert de produkten en de klant test of deze voldoen aan de gestelde acceptatiecriteria. Lever je wat er is verwacht, dan lever je kwaliteit. Geen vuiltje aan de lucht, zou je zeggen.
Zo’n aanpak gaat heel goed als je van tevoren weet wat je wilt, nee: als je als klant van te voren heel goed weet wat je wilt. Zelfs dan gaat er in het concreet beschrijven nog voldoende mis in de afstemming. Maar okay, het is dan wel een manier om met elkaar het werk af te spreken en de leverancier te beoordelen op de geleverde prestatie.
In het boek “Zen en de kunst van het motoronderhoud’ maakt Robert Pirsig onderscheid tussen klassieke kwaliteit en romantische kwaliteit. Het verhaal gaat over een reisgezelschap waarin de hoofdpersoon gedurende de reis zichzelf vragen stelt over de betekenis van kwaliteit. De klassieke kwaliteit gaat over het decomponeren van motorblokken, het mechanisch monteren door monteurs, het strikt volgen van de instructiehandleiding. Pirsig is zelf schrijver van technische handleidingen geweest. Ergens tijdens zijn werk moet hij zich afgevraagd hebben of al dat beschrijvend werk wel de gewenste waarde toevoegt. Wie leest de handleiding voordat het hij het produkt gebruikt? Staat de handleiding in dienst van de leverancier om zich te beschermen bij verkeerd gebruik?
Zien we de kwaliteit als risicomanagement, de acceptatiecriteria als schild ter bescherming, de afspraken om de leverancier “er aan te houden”?
Ik maak mee dat ik mij steeds meer aan steeds ingewikkeldere kwaliteitsprocedures moet houden. Op zich een wenselijke ontwikkelingen en toe te juichen streven om te leren van onze fouten, de repeterende zaken te borgen in geautomatiseerde procedures om er voor te zorgen dat de kans op fouten afneemt. En toch knaagt het.
We starten het project op en zitten bijeen. We kennen elkaar nog niet zo goed en moeten wennen aan elkaar. Er is van 9 uur ’s ochtends tot 16 uur ‘s middags veel energie in de groep. De goede wil is er om echt iets heel bijzonders van dit project te maken. Er heerst ook spanning. Kunnen de ontwikkelaars wel waarmaken wat ze beloven? Weten de gebruiker wel duidelijk aan te geven wat ze willen. En: sluit het vermogen om te maken aan bij de wens tot realisatie?
Dan zegt een van de gebruikers “dit is ook leven”. Wat een bijzondere opmerking. En ook zo waar. Dit hier wat we doen en vooral hoe we het doen, doet er ook toe. Het is bijna niet voorstelbaar dat er een mooi resultaat zou kunnen komen als de beleving tijdens de ontwikkeling er niet zou zijn. Het zijn juist de eerlijke diepgaande vragen die elkaar gesteld worden, die zorgen dat er een goede bijeenkomst ontstaat. Vragen als “wat doet het er toe dat jij die taak uitoefent voor jouw cliënt” en “wat drijft jou om jouw werk zo tw doen” geven de bijeenkomst spanning en diepgang.
Wat ik dan aantref is de romantische kwaliteit die Pirsig beschrijft. Die gaat over de beleving in het moment en de kwaliteit van de ervaring. Zoals Pirsig in de passage beschrijft hoe de hoofdpersoon met zijn motor door het landschap rijdt en geniet van de ondergaande zon, het geronk van de motor, het suizen van de wind. En hoe hij kiest voor onverwachte zijwegen, niet op voorhand goed wetend waar uit te komen.
Ik onderschrijf de noodzaak tot controles en procedures en zal deze met beleid toepassen. Ik stimuleer de beleving van de samenwerking tussen ontwikkelaars en gebruikers en beid graag ruimte om fouten te maken, zelf verbeteringen aan te brengen en er echt voor blijven gaan. Ik geloof in deze mensen die hun best doen en het beste willen, gewoon omdat zijn in dit project hun passie en expertise leggen.
Hier in zandbak van de samenwerking wordt de kwaliteit geboren, gewoon om ook die ervaring het leven is.
Comments