Bij veel organisaties die verantwoordelijk zijn voor het ontwikkelen, testen of beheren van applicaties, is kwaliteitsverbetering aan de orde van de dag. Als het grote verbetertrajecten betreft, wordt een zogenaamd Software Process Improvement (spi) project ingericht. Spi-consultant Jan Jaap Cannegieter van Sysqa was verantwoordelijk voor een project bij één van zijn opdrachtgevers. In dit artikel doet hij verslag van zijn ervaringen.
In Computable van 4 mei 2001 is in het artikel ‘Op naar het licht’ ingegaan op de opzet en uitkomsten van een cmm-onderzoek (Capability Maturity Model) bij één van de opdrachtgevers van Sysqa. Dit onderzoek leverde een set aanbevelingen op. De belangrijkste waren de opzet en implementatie van een organisatiebrede aanpak voor it-projecten en de implementatie van reviews. In dit artikel wordt ingegaan op de volgende stap in het verbeterproces: de opzet en inhoud van het kwaliteitssysteem dat bij deze opdrachtgever is ingericht. Tijdens de afdelingsbrede presentatie van de resultaten van het cmm-onderzoek werd duidelijk dat de systeemontwikkeling verbeterd kon worden. Voldoende aanleiding om de aanbevelingen enthousiast op te pakken.
Top down en bottom up
Software Process Improvement is een verzamelnaam van verbetertrajecten bij organisaties die systemen bouwen en onderhouden. Het inrichten van een kwaliteitssysteem is een mogelijk spi-traject. Spi kan grosso modo op twee manieren worden aangepakt, top down en bottom up. Bij de top down benadering is er een groep personen, vaak externen, die namens het management softwareprocessen inrichten en implementeren. Vaak moet dan ook worden afgedwongen dat de processen worden nageleefd. Degenen die de processen namelijk dienen uit te voeren, zijn niet of in beperkte mate betrokken geweest bij de inrichting van de processen. Daar staat wel tegenover dat het slagvaardiger is en het een consistente set processen en procedures oplevert. Het draagvlak is echter vaak veel minder.
Bij de bottom up methode wordt een organisatiebrede werkgroep geformeerd die zelf de procesverbeteringen ontwerpt en invoert. De voordelen zijn dat de set maatregelen over het algemeen veel beter bij de organisatie past en een breed draagvlak ontstaat. De leden van de organisatie dienen wel in staat te zijn kritisch naar hun werkwijze te kijken. Dit veronderstelt ook voldoende kennis van en ervaring met systeemontwikkelingsmethoden. Daarnaast is het uitvoeren van een verbetertraject toch iets anders dan het ontwikkelen van een systeem. Daarom wordt het verbetertraject vaak door een externe consultant begeleid. Bij deze opdrachtgever is voor de bottom up methode gekozen, met name vanwege de hoge acceptatie.
Eisen
Samen met de opdrachtgever werd allereerst een spi-team geformeerd. Er was een aantal eisen aan de werkgroep gesteld.
De eerste eis was de samenstelling: tenminste de manager systeemontwikkeling en minimaal één functioneel projectleider, één technisch projectleider en één medewerker van software support dienden in het team plaats te nemen. Bij deze samenstelling waren alle betrokken groepen van functionarissen vertegenwoordigd. Het team werd begeleid door een externe consultant. Hij vervulde de rol van ‘changemanager’; het begeleiden van de verandering zonder inhoudelijk betrokken te zijn.
De tweede eis was dat de werkgroep een goede afspiegeling vormde van de organisatie. In grote lijnen ontwikkelt de organisatie die onderzocht werd, twee soorten systemen. Een groot administratief systeem (met een aantal daarmee samenhangende subsystemen) en een aantal internetapplicaties om de diensten ook via internet aan te bieden. Vertegenwoordigers van beide systemen dienden in de werkgroep te zitten.
De derde eis was dat de leden voldoende ervaring in de projecten bij de opdrachtgever dienden te hebben. De laatste eis is weliswaar een voor de hand liggende, maar misschien wel de belangrijkste. Het betreft enthousiasme voor het project en bereidheid om te veranderen. Met onwillige honden is het slecht hazen vangen, dus instelling en motivatie wegen bijzonder zwaar. Ondanks de geformuleerde eisen bleek één oproep voldoende goede kandidaten op te leveren om de werkgroep te vullen. Het aantal aanmeldingen was zodanig dat we uiteindelijk op een groep van acht personen uitkwamen die inderdaad een goede afspiegeling van de organisatie vormde. Uit het feit dat goede kandidaten zich direct meldden bleek al dat de organisatie achter het initiatief stond.
Het gebeurt regelmatig dat verbeterteams direct vol enthousiasme aan de gang gaan, maar niet helder voor ogen hebben wat ze willen bereiken en hoe dit bereikt moet worden. Daarom belegden we met de werkgroep eerst een aantal oriënterende sessies. Onderwerpen tijdens deze sessies waren wat precies onze opdracht was en hoe we te werk moesten gaan. Als uitgangspunt hadden we de uitkomsten van het cmm-onderzoek. Over de aanpak van de veranderingen was nog niets bekend.
Uiteindelijk resulteerden deze sessies in een plan van aanpak voor het spi-traject. Het plan van aanpak bestond uit de opdrachtformulering, de doelstellingen, de afbakening (wat doen we wel, wat doen we niet), de randvoorwaarden, een beschrijving van de werkwijze, de op te leveren producten, de planning, de communicatie en de middelen. Pas toen dit document was goedgekeurd door de directeur Informatie & Automatisering, begon de werkgroep daadwerkelijk met de uitvoering van het traject.
Bij deze opdrachtgever was deze aanpak nieuw. Men was hier gewend een probleem direct aan te pakken en (te proberen) op te lossen. Nu werd eerst nagedacht over het wat en hoe. Voor een aantal teamleden een verfrissende aanpak die de nodige helderheid verschafte.
Kwaliteitssysteem
De werkgroep stelde zich ten doel een kwaliteitssysteem in te richten dat als beheersinstrument moest gaan dienen voor de automatiseringsorganisatie. Een kwaliteitssysteem is een op de organisatie toegesneden werkwijze die vastgelegd en geborgd is. Kenmerken van een kwaliteitssysteem zijn dat het flexibel dient te zijn, goede ideeën dient te absorberen en niet vrijblijvend is.
Bij dit traject bestaat het kwaliteitssysteem uit procesbeschrijvingen, een aantal procedures en modellen van mijlpaalproducten. De procesbeschrijvingen bestaan uit activiteiten met een ‘flowchart’ om de volgtijdelijkheid van de activiteiten aan te geven, een beschrijving van de activiteiten, de te gebruiken hulpmiddelen, de te realiseren tussenproducten en alle taken en rollen. Deze taken en rollen zijn beschreven in termen van Raci (Responsible, Accountable, Consulted en Informed).
Naast de procesbeschrijvingen is er ook een aantal procedures. Die hebben betrekking op de werking van het kwaliteitssysteem zoals eerder beschreven. De eerste procedure heeft betrekking op flexibiliteit. Een kwaliteitssysteem mag geen ‘loden zwemvest’ zijn. Het mag dus geen onnodige ballast zijn die efficiënte en effectieve uitvoering van projecten in de weg staat. Ieder kwaliteitssysteem is de grootste gemene deler van alle projecten. Het kan dus in sommige gevallen beter zijn af te wijken van het kwaliteitssysteem. Wanneer de projectleden dit goeddunkt? Nee, als de projectdoelstellingen dit legitimeren en dit in goed overleg gebeurt met de softwaresupport medewerker (een medewerker die de implementatie begeleidt en tweedelijns support uitvoert) die toegewezen is aan dat project. De softwaresupport medewerkers zijn daarmee project kwaliteitsmedewerkers geworden. De afwijkingen dienen wel beschreven te worden in het plan van aanpak van het project. Door het bieden van de mogelijkheid op gecontroleerde wijze af te wijken van het kwaliteitssysteem, is het kwaliteitssysteem een stuk flexibeler geworden.
De tweede procedure heeft betrekking op het opnemen van goede ideeën in het kwaliteitssysteem. De werkgroep was weliswaar een goede afspiegeling van de organisatie, maar andere medewerkers hebben wellicht ook hele goede nieuwe ideeën. Daarnaast kunnen in de loop van de tijd nieuwe inzichten ontstaan en nieuwe ervaringen worden opgedaan. Deze procedure beschrijft de wijze waarop medewerkers van de organisaties verbetersuggesties kunnen aandragen, hoe die suggesties worden beheerd, wie beslist over het verwerken van de suggesties en hoe dit wordt gecommuniceerd. Hierdoor is het kwaliteitssysteem in staat nieuwe ideeën en ‘best-practices’ op te nemen en valkuilen te voorkomen. De combinatie van flexibiliteit en aanpasbaarheid van het kwaliteitssysteem versterken elkaar. Als een projectleider onderdelen van het kwaliteitssysteem niet wil toepassen, wordt samen met de softwaresupport medewerker gekeken of de projectdoelstellingen dit legitimeren. Als dat zo is, wordt gekeken of de aanpassing voor de meeste projecten geldt. Als dat zo is, is er een verbetersuggestie. Is het alleen voor dit project gelegitimeerd, dan hebben we een afwijking. Is het niet gelegitimeerd, dan wordt gewoon het kwaliteitssysteem toegepast.
De derde procedure heeft betrekking op borging van het kwaliteitssysteem. Het maken van een op de organisatie toegesneden werkwijze is mooi, maar als niemand erop toeziet dat het ook daadwerkelijk wordt toegepast, ontstaat een papieren tijger. Daarom worden er ‘reviews’ aan het einde van iedere projectfase uitgevoerd. Doel van de reviews is het vaststellen of de tussenproducten aan van tevoren gedefinieerde kwaliteitseisen voldoen. De softwaresupport medewerker, in de rol van project kwaliteitsmedewerker, begeleidt deze reviews. Bij iedere review wordt gekeken welke medewerkers binnen en buiten de organisatie belang hebben bij het product en zij dienen aan te geven of het product aan de eisen voldoet en of er verbetersuggesties zijn. Op deze wijze wordt er feitelijk toegezien op de toepassing van het kwaliteitssysteem.
Voordelen
Een kwaliteitssysteem maak je niet voor niets, het heeft bepaalde voordelen. Uit de ervaring blijkt een kwaliteitssysteem de volgende voordelen te hebben:
- Voorspelbare kwaliteit. Door het toepassen van het kwaliteitssysteem is de kwaliteit van het opgeleverde eindproduct, alsmede de documentatie voorspelbaar. Minder onverwachte zaken gebeuren in de projecten;
- Mogelijkheid het kwaliteitsniveau aan te passen. Indien tijd of geld beperkende factoren zijn, kan bewust gekozen worden voor een mindere kwaliteit. Deze beslissing wordt expliciet in plaats van impliciet genomen. Risico’s die samenhangen met het verlagen van de kwaliteit worden hierdoor zichtbaar;
- Inwerken nieuwe medewerkers. Toen het kwaliteitssysteem net klaar was, kwam een nieuwe projectleider bij de opdrachtgever. In heel korte tijd had hij zich de werkwijze van de opdrachtgever, alsmede de taken, bevoegdheden en verantwoordelijkheden binnen de projecten eigen kunnen maken;
- De mogelijkheid mensen te kunnen uitwisselen tussen projecten. Doordat alle projecten volgens het kwaliteitssysteem gaan werken, kunnen medewerkers makkelijker tussen projecten worden uitgewisseld. De werkwijze is immers bij alle projecten hetzelfde:
- Betere communicatie. Doordat helder is wat gedaan wordt, welke producten gerealiseerd worden en wie welke rol hierin speelt, loopt de communicatie beter;
- Verbeterde werksfeer. Door minder onduidelijkheden en fouten gebeuren minder onverwachte zaken. Hierdoor ontstaan minder brandjes en gebeurt het minder vaak dat medewerker A dacht dat medewerker B een bepaalde activiteit zou doen en andersom;
- Betere planningen. Door de voorspelbare werkwijze zijn inspanningen veel nauwkeuriger te plannen, waardoor kosten en kwaliteit vooraf beter inzichtelijk zijn;
- Soepelere gang van zaken. Voor iedereen is duidelijk wat zijn taken, bevoegdheden en verantwoordelijkheden zijn. Hierdoor is er sprake van minder ‘paniekvoetbal’.
Bouw kwaliteitssysteem
De verwachting was dat het maken van de procesbeschrijvingen binnen korte tijd gerealiseerd kon worden. De leden van de werkgroep hadden namelijk de overtuiging dat in hoge mate duidelijk was hoe automatiseringsprojecten aangepakt werden. Al snel bleek dat dit echter niet zo duidelijk was. De te ondernemen activiteiten, de volgorde maar vooral de Raci’s leverden veel discussie op. Het bleek, conform de uitkomsten van het cmm-onderzoek, dat er grote verschillen waren in aanpak. De discussies liepen hierbij soms hoog op, maar desondanks kwam de werkgroep altijd tot overeenstemming over de toekomstige werkwijze.
Naast de procesbeschrijvingen bestond het kwaliteitssysteem uit een aantal modellen van mijlpaalproducten. Bij de opdrachtgever waren al modellen van alle mijlpaalproducten. Deze werden echter nauwelijks gebruikt. Voornaamste reden was dat de modellen nooit echt geïmplementeerd waren. De meeste functionarissen maakten gebruik van eigen modellen. Bij een nieuw project werd gewoon het oude plan genomen en aangepast. De bestaande modellen bleken echter zeer waardevol. Ieder model werd wel beoordeeld, zeker in het licht van de nieuwe procesbeschrijvingen, maar in grote lijnen bleven de bestaande modellen overeind staan.
In de praktijk komt het vaak voor dat er goed bruikbare zaken bij een opdrachtgever zijn die beperkt gebruikt worden. Een ‘quick win’ is het verzamelen, ordenen en implementeren van wat er reeds is in plaats van weer iets nieuws bedenken.
Het ontwerpen van een kwaliteitssysteem lijkt in sommige aspecten op het ontwerpen van een automatiseringssysteem. Eerst ontwerp je het in hoofdlijnen. Bij een automatiseringssysteem is dat de architectuur, bij een kwaliteitssysteem de fases en activiteiten. Vervolgens wordt per onderdeel deze hoofdstructuur uitgewerkt. Door die parallellen kan ook op sommige punten gebruik worden gemaakt van dezelfde technieken. Bij het ontwerpen van de processen en procedures maakten we als werkgroep gebruik van ‘brown paper’-technieken. Essentie van deze techniek is dat je met behulp van gele briefjes op grote vellen bruin papier ontwerpen gaat maken en discussieert op basis van wat er op enig moment hangt. Door toepassing van de techniek werd gericht gediscussieerd. ‘Brown-paper’ is in hoge mate visueel, wat het begrip bij de deelnemers aanzienlijk kan verhogen. Voor alle medewerkers uit de werkgroep was deze werkwijze nieuw en werd het als zeer verfrissend ervaren. Daarnaast werd iedere werkgroepsessie afgesloten met Pbca’s. Dit staat voor Parkeerflap, Benefits, Concerns en Actielijst. Op de parkeerflap mag iedere deelnemer hangen wat hij van belang vindt, maar wat op dat moment niet bediscussieerd wordt. Krijgt een deelnemer ineens een idee of een vraag die niet in de discussie past, dan schrijft hij dit idee of de vraag op en hangt hem op de parkeerflap. Voordeel is dat de discussie niet verstoord wordt door belangrijke aspecten die op dat moment echter niet besproken worden. De ideeën en vragen worden echter niet vergeten! ‘Benefits’ zijn alle zaken die goed zijn en positief ervaren worden. ‘Concerns’ zijn de zaken die niet goed zijn en negatief worden ervaren. Alle deelnemers werden aan het eind van de sessie uitgenodigd de ‘benefits’ en ‘concerns’ op geeltjes te schrijven, waarna ze besproken werden. Voordelen hiervan zijn dat alle gevoelens en ideeën uitgesproken worden zodat de ‘changemanager’ hiernaar kan handelen. Door iedere week de ‘benefits’ en ‘concerns’ te behandelen, werd duidelijk hoe iedereen over zaken dacht, werd het proces binnen de werkgroep op basis van ervaringen bijgestuurd en kon iedereen zijn ei kwijt. Hierdoor bleef de sfeer open en leverde iedereen zijn bijdrage aan het proces. Zeker dit gedeelte werd als zeer positief ervaren. Aan het einde van iedere sessie werd een actielijst gemaakt met daarop wie, wat en wanneer. Door de strikte sturing op acties werd het project beter bestuurbaar en concreet wat er diende te gebeuren. De actielijst werd overgenomen in een procesdocument. Dit is één A-viertje met daarop de actielijst, de planning (op hoofdlijnen), zwaarwegende ‘concerns’ die gemonitord dienen te worden, de besluitenlijst en de volgende vergaderdatum met agenda van de vervolgbijeenkomst. Door het raadplegen van het procesdocument hadden de leden van de werkgroep direct inzicht in de status van het proces en de lopende acties. Van de bijeenkomsten werden alleen captures gemaakt: een soort notulen die alles bevatten wat op het ‘brown paper’ stond. Als iets niet op een geeltje stond, werd het niet vastgelegd en dus niet verder meegenomen.
Eindproduct
Kwaliteitssystemen bestonden in het verleden vaak uit dikke ordners, die op iedere afdeling aanwezig dienden te zijn, maar die niemand gebruikte. Bekende redenen waarom kwaliteitssystemen niet succesvol waren, zijn ontoegankelijkheid, het helpt de projectmedewerkers niet, maar is eerder een blok aan het been, het is niet toepasbaar in dit project (niet flexibel), er werd toch niet op de toepassing toegezien en het is verouderd. Door de in dit artikel beschreven werkwijze is een groot aantal van de nadelen ondervangen. Ten eerste de omvang. Het totaal van leeswijzer, procedures en procesbeschrijvingen is 39 pagina’s. De model-mijlpaalproducten zijn hierbij niet opgenomen in de papieren versie (die ook elektronisch beschikbaar is). De model-mijlpaalproducten pakt de gebruiker van het kwaliteitssysteem alleen erbij als hij dat product gaat maken. De toegankelijkheid en actualiteit worden gewaarborgd door het kwaliteitssysteem via een geautomatiseerde toepassing beschikbaar te stellen. Door de procedure ‘afwijking van het kwaliteitssysteem’ is het kwaliteitssysteem flexibel en is er bij ieder project nagedacht over de wijze waarop dit project aangepakt gaat worden. Door de procedure ‘aanvulling van het kwaliteitssysteem’, worden eventuele fouten en verbeteringen gesignaleerd, verwerkt en beheerst. Goede werkwijzen komen zo ter beschikking van alle medewerkers. De procedure ‘review’ tenslotte zorgt ervoor dat ook wordt toegezien op de toepassing, terwijl direct ook andere voordelen van ‘reviews’ worden benut. Daarnaast wordt de toepassing en verbetering van het kwaliteitssysteem geborgd door het uitvoeren van evaluaties. De grootste ‘benefit’ van het op deze wijze bouwen van een dergelijk kwaliteitssysteem is dat de leden van de werkgroep ‘change-agents’ zijn geworden; voorlopers in de implementatie van het kwaliteitssysteem. Zij zijn de vooruitgeschoven posten in het verbeteren van de kwaliteit van de systeemontwikkeling.
Jan Jaap Cannegieter Productmanager Sysqa
