Het implementeren van een kwaliteitssysteem – een flexibele, organisatiebrede, maar zeker n�et vrijblijvende werkwijze – vraagt extra inspanning van de organisatie. Het is niet zinvol een organisatie te dwingen bepaalde werkzaamheden op een bepaalde manier uit te voeren. De implementatie van een kwaliteitssysteem moet gericht zijn op het helpen toepassen ervan. Consultant Jan Jaap Cannegieter was verantwoordelijk voor de invoering van zo’n systeem. Hij doet verslag van zijn ervaringen, onder zijn persoonlijke motto: ‘veranderen betekent helpen’.
In TARGET=”_blank” HREF=”https://www.computable.nl/artikels/archief1/d18ag105.htm”>Computable 18, 4 mei 2001) werd ingegaan op de opzet en uitkomsten van een cmm-onderzoek bij een opdrachtgever. Eén van de conclusies was dat bij de diverse projecten een andere aanpak werd gehanteerd en er weinig tot geen tussentijdse kwaliteitsmaatregelen werden genomen bij deze opdrachtgever. De belangrijkste aanbevelingen waren derhalve dat er een organisatiebrede werkwijze moest worden ontworpen en geïmplementeerd en dat reviews onderdeel van het proces gemaakt moesten worden.
In het artikel ‘Goed, beter, best’ (Computable 43, 26 oktober 2001) is ingegaan op de opzet en werking van het kwaliteitssysteem, dat vervolgens door een organisatiebrede werkgroep is gemaakt. In het kwaliteitssysteem staat de organisatiebrede werkwijze beschreven en is een aantal ondersteunende producten opgenomen, zoals sjablonen van tussenproducten.
Het kwaliteitssysteem heeft drie kenmerken. In de eerste plaats is het aanpasbaar; nieuwe en goede ideeën kunnen er in worden opgenomen. Ten tweede is het niet vrijblijvend. De projectmedewerkers kunnen het niet naar eigen inzicht wel of niet toepassen. De organisatie bepaalt immers de werkwijze. En in de derde plaats is het flexibel. Indien de projectdoelstellingen dit legitimeren, kan namelijk op beheerste wijze worden afgeweken van het kwaliteitssysteem.
In dit artikel beschouwen we de wijze waarop het kwaliteitssysteem bij de opdrachtgever geïmplementeerd is, het implementatiescenario, de implementatieactiviteiten en de resultaten.
Implementatiescenario
Op het moment dat organisaties willen verbeteren door een kwaliteitssysteem in te voeren, ontstaat de vraag hoe deze verandering moet worden doorgevoerd. In principe zijn er drie implementatiescenario’s. Bij het eerste wordt het kwaliteitssysteem in de toekomst toegepast bij nieuwe projecten. Projecten die geen gebruik maken van het kwaliteitssysteem ‘sterven langzaam uit’. Het duurt in dat geval lang voordat de voordelen van het kwaliteitssysteem benut worden, en verschillende projecten werken op een verschillende manier.
Het tweede scenario is dat projecten vanaf een bepaald tijdstip allemaal gebruik maken van het kwaliteitssysteem. Voordeel is dat het moment van verandering helder is, nadeel is dat de voorgeschiedenis van het project wordt meegenomen en dit voortraject vaak niet in lijn met het kwaliteitssysteem is uitgevoerd. Bij het derde scenario gaan alle projecten bij overgang naar een nieuwe fase gebruik maken van het kwaliteitssysteem.
Bij deze specifieke opdrachtgever is gekozen voor een variatie op het tweede scenario. Bij diverse projecten was er op het moment van de implementatie geen goed beeld van de status van de projecten en de nog uit te voeren activiteiten. Voor bijna alle projecten – er gold alleen een uitzondering voor projecten die in een eindfase verkeerden – werd een nieuw plan van aanpak gemaakt. In het nieuwe plan van aanpak stonden de huidige status van het project en reeds aanwezige producten beschreven. Daarnaast werd geschetst welke fases en activiteiten in welk tijdspad nog ondernomen moesten worden.
In eerste instantie lijkt dit een aanzienlijke inspanning voor de organisatie. Maar zoiets hoeft heel weinig tijd te kosten als de projectleider zijn zaakjes goed op orde heeft. En als dit niet het geval is, is het juist goed dat het plan van aanpak wordt gemaakt. Er is in die gevallen namelijk te weinig zicht op dat project, een situatie die in de toekomst waarschijnlijk nog meer problemen zal opleveren. Ook komt er meteen een aantal knelpunten boven, die in tegenstelling tot het verleden direct opgepakt kunnen worden.
Voorwaarden
Voordat het kwaliteitssysteem werd geïmplementeerd, moest een aantal voorwaarden vervuld zijn. Anders zou het succes van de implementatie in gevaar komen. De eerste voorwaarde was dat de bezetting van de afdeling software-ondersteuning op peil moest zijn. Deze medewerkers verrichten in het kader van reviews en projectbeheer extra werkzaamheden die voor het succes van de implementatie van doorslaggevend belang zijn. Door ziekte en een vacature was deze afdeling echter onderbezet. In deze situatie kon de afdeling de nieuwe werkzaamheden niet oppakken, waardoor de reviews en de overige taken nooit goed uitgevoerd konden worden. Eerst werd de bezetting van deze afdeling dus op peil gebracht.
Een andere belangrijke voorwaarde is dat er voldoende managementcommitment is en dat dat ook actief wordt uitgedragen. De manager systeemontwikkeling zat in de werkgroep SPI (Software Process Improvement) en uit gesprekken met de directeur automatisering bleek dat hij het kwaliteitssysteem voldoende steunde. Door diverse activiteiten en uitlatingen werd het commitment van het management uitgedragen naar de medewerkers. Overigens is het uitdragen van commitment één, de voorbeeldfunctie van management en directie was minstens zo belangrijk. Dat was bij deze opdrachtgever allemaal dik in orde.
De derde voorwaarde is dat de medewerkers in de beginperiode na de introductie voldoende tijd hebben om zich het kwaliteitssysteem eigen te maken. Hiervoor werd binnen de implementatieactiviteiten ruimte gemaakt.
Kick-off
Om de implementatie te laten slagen, werden er diverse implementatieactiviteiten uitgevoerd. De meest in het oog springende activiteit was een kick-off van het kwaliteitssysteem. Het gebeurt regelmatig dat een kick-off vooral bestaat uit informatieoverdracht en een motivatiepraatje. Bij deze opdrachtgever is voor een ander soort kick-off gekozen. Op een andere manier gaan werken betekent voor veel mensen vaak dat ze hun eigen werkwijze ook kritisch moeten bekijken. Om hiervoor de toon te zetten, stelde de werkgroep SPI zichzelf kwetsbaar op. Na de opening gingen de deelnemers in kleine groepjes het kwaliteitssysteem ‘reviewen’. De bevindingen die tijdens deze sessies werden gedaan, werden door de werkgroepleden verzameld en vormden de input voor het verbeteren van het kwaliteitssysteem.
Tijdens de review-sessies ontstonden goede, meestal positief getinte, discussies over opzet, inhoud en werking van het kwaliteitssysteem. Daarnaast leverde het goede verbeterpunten op voor het kwaliteitssysteem zelf, die na de kick-off werden opgepakt. Doordat de medewerkers allemaal de mogelijkheid hadden gekregen hun bijdrage te leveren, werd het kwaliteitssysteem ook een beetje ‘van hun’. Een ander voordeel was dat de opzet en inhoud van het kwaliteitssysteem meteen bij iedereen bekend waren.
De kick-off werd afgesloten met ‘voordelen’ en ‘zorgen’. Hierbij kon iedereen aan de hand van gele notitiebriefjes alle gevoelens en vragen naar buiten brengen. Er bleken veel ‘zorgen’ te bestaan. Aan de ene kant hadden deze betrekking op de onvolledigheid van het kwaliteitssysteem. De werkgroep had ervoor gekozen snel met een eerste product te komen, in plaats van jaren lang het perfecte systeem, dat vaak onhandelbaar dik is, te ontwikkelen. Aan de andere kant was er ook bezorgdheid over het nut en de werkbaarheid van het systeem. Is het kwaliteitssysteem geen beperking van de vrijheid? Wat nu als het niet werkt in mijn project? Doordat deze gevoelens uitgesproken werden, kon hierover gepraat worden.
Gelukkig zagen de deelnemers ook veel ‘voordelen’. Die hadden bijvoorbeeld betrekking op het gevoel dat de organisatie nog nooit zo ver was geweest met het verbeteren van de kwaliteit. Veel deelnemers vonden het een nuttige dag voor de organisatie. En de deelnemers zagen ook de toegevoegde waarde van het kwaliteitssysteem. Al met al overheerste het positieve gevoel. De enkele negatieve geluiden werden overstemd door de positieve.
Na afloop van de kick-off hadden alle medewerkers het kwaliteitssysteem tot hun beschikking, zowel op papier als via het intranet.
Implementatiemanager
Een deel van de implementatieactiviteiten had betrekking op de medewerkers software-ondersteuning. Deze medewerkers hielden zich tot het moment van de implementatie bezig met de begeleiding van software-uitleveringen, tweedelijns ondersteuning van de gebruikers en projectbeheer. Na de introductie van het kwaliteitssysteem kregen deze medewerkers ook taken in het kader van toezicht op de toepassing van het kwaliteitssysteem en het begeleiden van de reviews.
Binnen de organisatie was vrijwel geen ervaring met ‘reviews’. Omdat het takenpakket van de medewerkers software-ondersteuning fors veranderde, zijn zij door een apart aangetrokken implementatiemanager opgeleid en begeleid. In diverse workshops werden de medewerkers aan de hand van theorie en cases getraind in het begeleiden van reviews. Wat zijn het doel en de opzet van reviews? Hoe stel je je op als reviewleider? Hoe ga je om met bepaalde situaties? Deze en andere vragen kwamen tijdens deze training ter sprake.
De medewerkers software-ondersteuning waren niet de enige die werden ondersteund. Ook de overige medewerkers werden geïnformeerd en ondersteund in het kader van de reviews. De implementatiemanager was bovendien in het kader van het kwaliteitssysteem beschikbaar voor alle medewerkers van de opdrachtgever. In de eerste plaats als helpdesk en vraagbaak. Wanneer medewerkers moeite hadden met het toepassen van het kwaliteitssysteem, konden zij aankloppen bij de implementatiemanager. Ook als medewerkers onderling onenigheid hadden over de interpretatie van het systeem, was de implementatiemanager de aangewezen man om ze te helpen eruit te komen.
De implementatiemanager kon ook op eigen initiatief naar een medewerker toestappen als bleek dat deze moeite had met het kwaliteitssysteem. In dit geval was er dus sprake van actieve ondersteuning. Signalen dat medewerkers moeite hadden met het toepassen van het kwaliteitssysteem, kreeg de implementatiemanager van het hoofd systeemontwikkeling, één van de medewerkers software-ondersteuning of van andere medewerkers. In sommige gevallen liep de implementatiemanager zelf tegen dit soort signalen aan.
Naast de individuele begeleiding organiseerde de implementatiemanager ook zogenaamde kennissessies. Tijdens deze sessies werd een bepaald onderdeel van het toepassen van het kwaliteitssysteem, zoals bijvoorbeeld reviews, besproken in een kleine groep. Problemen, onduidelijkheden en eventuele weerstanden werden interactief besproken. Deze sessies werden door de deelnemers zeer positief gewaardeerd.
Weerstand
Soms is er bij veranderingen veel weerstand. Er was echter gekozen voor een groot aantal contactmomenten, om doelstellingen en voordelen te communiceren, en er waren uiteenlopende ondersteunende activiteiten georganiseerd om het kwaliteitssysteem te implementeren. Mede hierdoor, en doordat de organisatie zelf nauw bij het geheel betrokken is, was de openlijke weerstand nihil. De positieve sfeer op de kick-off droeg hier ook toe bij, evenals de professionele wijze waarop de medewerkers software-ondersteuning, na een periode van actieve begeleiding van de implementatiemanager, de reviews begeleiden.
Was er dan helemaal geen weerstand? Natuurlijk wel, maar dan in de vorm van ‘passieve weerstand’. Deze bleef beperkt tot twee à vier personen. Bij passieve weerstand spreekt degene die de weerstand levert dit niet uit, maar probeert zich aan het kwaliteitssysteem en de reviews te onttrekken. Hij of zij trekt gewoon zijn eigen plan en hoopt dat niemand dit merkt en dat ‘het wel overwaait’. Door de hoge acceptatiegraad viel dit echter wél op.
Deze vorm van weerstand is echter het moeilijkst te bestrijden. Degene om wie het gaat, spreekt zich namelijk niet uit tegen het kwaliteitssysteem. Op zichzelf is deze weerstand niet nodig. Omdat het kwaliteitssysteem aanpasbaar is en afwijking onder bepaalde voorwaarden is toegestaan, is het flexibel genoeg. Degene die passieve weerstand pleegt, maakt hier echter geen gebruik van en stelt zijn kennis en ervaring ook niet ter beschikking van anderen. Als bleek dat medewerkers zich aan het kwaliteitssysteem onttrokken, werden ze hierop aangesproken door de medewerker software-ondersteuning of de implementatiemanager. Leidde zo’n gesprek niet tot een oplossing, dan ging men een stapje hoger, naar de manager systeemontwikkeling.
Vervolg
Is de implementatie hiermee afgesloten? Nee, voor zover de implementatie überhaupt afgesloten kan worden (het toepassen van het kwaliteitssysteem en reviews zijn immers onderwerpen die altijd aandacht verdienen), kan dat pas na een evaluatie. Bij de implementatie is er reeds afgesproken dat de evaluatie na een half jaar plaats zal vinden. De onderwerpen van de evaluatie zijn inmiddels in grote lijnen bepaald.
Tot nu toe zijn de meeste medewerkers van de opdrachtgever, evenals de opdrachtgever zelf, enthousiast over het kwaliteitssysteem. Zeker de reviews worden, na enige scepsis, als zeer positief beoordeeld. Fouten worden door de reviews vroegtijdig gevonden en in een vroeg stadium wordt overeenstemming bereikt. Dit heeft een sterk kwaliteitsverhogende werking. Per review is bijgehouden hoeveel tijd deze heeft gekost en ook hoeveel tijd ermee gewonnen is. Reviews kunnen namelijk tijd opleveren, doordat fouten in een vroeg stadium worden gevonden en er dus minder tijd nodig is om ze te herstellen. Na zes maanden blijkt dat de reviews bijna vier keer zoveel tijd hebben opgeleverd dan ze hebben gekost.
Het werk is nog niet af, ook niet na de evaluatie. De opdrachtgever heeft namelijk besloten de weg van kwaliteitsverbetering verder in te slaan. Dat wil zeggen dat opnieuw de balans opgemaakt gaat worden. Bepaald wordt wat nu de verbeteracties zijn die de meeste meerwaarde hebben. In de werkgroep SPI zijn al diverse ideeën geopperd. Nu de medewerkers eenmaal ervaring hebben met procesverbetering zien zij, bij het uitvoeren van hun projecten, steeds meer zaken die beter kunnen, die de organisatie nog succesvoller kunnen maken.
Veranderingen in organisaties zijn niet altijd succesvol. De implementatie van het kwaliteitssysteem bij deze opdrachtgever is echter wél een groot succes. Dat is zeker geen toeval. Twee zaken zijn van doorslaggevend belang geweest. Allereerst het besef dat de implementatie niet vanzelf gaat. Via een apart implementatieplan, een concrete set activiteiten en de tijdelijke inzet van een implementatiemanager, kreeg de implementatie inhoud. De implementatie was meer dan het roepen dat het anders moest en het beschikbaar stellen van een aantal documenten en sjablonen. Ten tweede was er de filosofie achter de implementatieactiviteiten dat alle medewerkers een bijdrage konden leveren en iedereen geholpen werd bij de verandering. De ene medewerker had dat meer behoeften dan de andere, maar iedereen kreeg de aandacht die nodig was. Daarom: veranderen betekent helpen.
Jan Jaap Cannegieter productmanager Sysqa