Het verbeteren van systemen vergt alleen maar meer investeringen. Maar het evalueren van de ICT-projecten zelf, en het werkelijke nut of het belang van de producten die ze opleveren blijven meestal onderbelicht. Drie kwaliteitsspecialisten tonen aan dat een aanpak voor het beheersen van projecten – het Capability Maturity Model – ook uitstekend bruikbaar is bij het evalueren van die projecten. Evaluatie met als doel het goede te behouden en te borgen, en te leren van gemaakte fouten.
Hoewel de hier beschreven aanpak op alle systeemontwikkelingsprojecten kan worden toegepast, is hij met name interessant voor projecten die zich op het Capability Maturity Model level 1 of 2 bevinden. Organisaties met projecten op een niveau 3 of hoger van dit model zullen minder moeite hebben met het evalueren; sterker nog, het evalueren van deze projecten is een vanzelfsprekende en bovendien continue aangelegenheid. Dit in tegenstelling tot projecten op niveau 1 en 2, waarbij evaluatie vrijwel uitsluitend achteraf plaatsvindt.
Eerst iets over de aanpak voor het beheersen van ICT-projecten, zoals deze is beschreven in het boek Kwaliteit op Maat (1). De auteurs beschrijven hierin het beheersen van IT-projecten met behulp van de Radar-methode. Vervolgens worden de begrippen product- en proceskwaliteit gerelateerd aan het CMM en de ISO 9126 standaard voor informatiesystemen. Hierbij wordt een synthese bereikt tussen inzichten uit de ‘kwaliteit op maat’ aanpak, en inzichten vanuit CMM en ISO. Het resultaat is een hanteerbaar stappenplan voor de evaluatie van ICT-projecten.
Product- en procesrisico’s
Het boek ‘Kwaliteit op Maat’ stelt dat er maar twee dingen mis kunnen gaan met een project: het uiteindelijke product blijkt niet aan de verwachtingen te voldoen en/of het proces waarmee het product tot stand wordt gebracht, voldoet niet aan de verwachtingen. Zowel product als proces zijn onderhevig aan risico’s. De productrisico’s hebben betrekking op de systeemfunctionaliteiten en de systeemhoedanigheden. De procesrisico’s hebben betrekking op de planmatige beheersing en de omgevingsfactoren.
Het niet voldoende beheersen van deze risico’s kan een product opleveren dat niet voldoet aan de verwachtingen van de gebruiker. Zo bestaat het risico dat de gebruikerswensen niet voldoende geïnventariseerd zijn (productrisico), of dat het project te maken krijgt met verloop van personeel, of dat de onderneming overgenomen wordt dan wel zelf gaat overnemen (procesrisico).
Om een project te beheersen en een ‘goed’ product af te leveren is het een vereiste de risico’s die gelden voor het op te leveren product of ontwikkelproces te kennen, in te schatten en vervolgens zo goed mogelijk te beheersen door het nemen van adequate voorzorgsmaatregelen. De auteurs van het boek komen dan ook tot de stappenmatrix van figuur 1.
Stappenmatrix
| STAP 1 Identificeren | STAP 2 Waarderen | STAP 3 Specificeren | STAP 4 Taxeren | STAP 5 Elimineren | |
| Functionaliteiten | |||||
| Hoedanigheden | |||||
| Planmatige beheersing | |||||
| Omgevingsfactoren |
Figuur 1. De rijen ‘functionaliteiten’ en ‘hoedanigheden’ duiden op aspecten van het product, dus het op te leveren of te onderhouden informatiesysteem.
De rijen ‘planmatige beheersing’ en ‘omgevingsfactoren’ duiden op de aspecten van het proces van de systeemontwikkeling.
De kolommen ‘identificeren’ tot en met ‘elimineren’ zijn de stappen die onderkend worden in het karakteristieke stappenplan dat uitgangspunt is van ‘Kwaliteit op Maat’.
Stappenplan
Het stappenplan kent vijf stappen en wordt kort toegelicht aan de hand van de rij ‘functionaliteiten’ van de stappenmatrix
Stap 1: identificeren.
Bepaal welke functionaliteiten het te ontwikkelen informatiesysteem moet bevatten. Interviews, workshops, bedrijfsanalyses, enzovoort zijn de middelen die in deze stap de functies boven tafel moeten krijgen die het informatiesysteem moet gaan bevatten. Het niet vinden van alle functies die het informatiesysteem moet verrichten, vormt een potentieel risico. Immers, de toekomstige gebruikers (in de ruimste zin van het woord) krijgen een informatiesysteem dat niet alle verwachte functionaliteit bevat.
Anderzijds vormt een teveel aan functies ook een risico: de kosten voor realisatie en onderhoud van het op te leveren systeem zullen navenant hoger zijn.
Stap 2: waarderen.
Bepaal het relatieve belang van elk van de functionaliteiten die stap 1 heeft opgeleverd. Als een relatief belangrijke functionaliteit niet de door de gebruiker beoogde prioriteit krijgt tijdens de systeemontwikkeling en als gevolg daarvan niet voorkomt in het op te leveren (eerste increment van het) informatiesysteem, dan zal de afnemer het informatiesysteem als kwalitatief ‘slecht’ ervaren.
Stap 3: specificeren.
Specificeer de op te leveren functionaliteiten. Koppel hier voldoende terug met de afnemer, opdat de functionaliteit voldoende en precies vast komt te liggen. Ga ook na of de functionaliteit op een geschikte manier gerealiseerd wordt.
Stap 4: taxeren.
Welke risico’s loopt men bij het realiseren van de functionaliteiten? Zijn er functies over het hoofd gezien waardoor de levensvatbaarheid van het systeem in gevaar komt? De kosten van het realiseren van functies blijken hoger te zijn. De volgorde van implementatie brengt voor het project extra kosten met zich mee.
Stap 5: elimineren.
Nu de risico’s bekend zijn bij het implementeren van de functionaliteiten, kunnen maatregelen bedacht worden om de invloed van de risico’s op het project te elimineren of te verkleinen. Dat betekent in ieder geval dat er voldoende tussenresultaten (mijlpalen, ‘intermediates’) behoren te zijn waaraan getoetst kan worden of de maatregelen voldoende effect sorteren.
Ook de andere rijen in de stappenmatrix moeten voor ieder project ingevuld worden. Kwaliteit op maat betekent nu: zet het project centraal en niet een overbodige hoeveelheid op te leveren documentatie en rompslomp. Maak voor iedere cel in de matrix de juiste afweging: een afweging tussen tijd, geld en kwaliteit. Alleen dan weet je wat de kwaliteit van het op te leveren product zal zijn.
Voor een organisatie op het niveau 1 of 2 van het CM-model zal het op te leveren product over het algemeen niet het gewenste kwaliteitsniveau hebben. Ook is het mogelijk dat het bereikte kwaliteitsniveau hoger ligt. In ieder geval is het gewenst aan het eind van het project terug te kijken en te analyseren wat er goed ging en dus bij een volgend project behouden moet blijven. Voor zaken die niet (zo) goed gingen zijn maatregelen nodig om bij een volgend project beter te scoren. Veel organisaties voeren daartoe een evaluatie uit, maar het effect van evaluaties laat vaak te wensen over. Men wil te veel informatie halen uit één evaluatie. De aanpak van ‘Kwaliteit op Maat’ levert twee handvatten die kunnen helpen beter te evalueren:
- Een evaluatie dient twee deelonderzoeken te bevatten: een op het product (het opgeleverde informatiesysteem) toegespitst deelonderzoek en een op het proces (van systeemontwikkeling) toegespitst deelonderzoek. Het combineren van deze twee deelonderzoeken in één evaluatie is in de praktijk niet realistisch.
- Het tweede handvat is het stappenplan: ook voor evaluaties is het nuttig de stappen ‘identificeren’, ‘waarderen’, ‘specificeren’, ’taxeren’ en ‘elimineren’ toe te passen. Tot zover ‘Kwaliteit op Maat’.
Standaard ISO 9126
Bij het beoordelen van een gebruiksartikel (wasmachine, CD-speler) is het nodig te letten op eigenschappen als gebruiksvriendelijkheid, aantal mogelijkheden, stroomverbruik, duurzaamheid, veiligheid, enzovoort. Voor informatiesystemen is er de ISO 9126 (Quint II) standaard van eigenschappen (zie figuur 2).
| H O O F D E I G E N S C H A P P E N | |||||||
| A T T R I B U T E N | Effectiviteit | Betrouwbaarheid | Bruikbaarheid | Efficiëntie | Onderhoudbaarheid | Portabiliteit | |
| ISO-9126 | Geschiktheid Juistheid Koppelbaarheid Inschikkelijkheid Beveiligbaarheid | Bedrijfszekerheid Foutbestendigheid Herstelbaarheid | Begrijpelijkheid Leerbaarheid Bedienbaarheid Behulpzaamheid Gebruikers- vriendelijkheid Inzichtelijkheid Overzichtelijkheid | Tijdbeslag Middelenbeslag | Analyseerbaarheid Wijzigbaarheid Stabiliteit Testbaarheid | Aanpasbaarheid Installeerbaarheid Volgzaamheid Vervangbaarheid | |
| QUINT II | Traceerbaarheid | Beschikbaarheid Degradeerbaarheid | Instelbaarheid Uitrustingsniveau | Beheerbaarheid Herbruikbaarheid | |||
Figuur 2: ISO-9126 (Quint II) standaard voor informatiesystemen.
De standaard kent een aantal hoofdeigenschappen en iedere hoofdeigenschap is weer onderverdeeld in een aantal (kwaliteits)attributen.
Dit is dé standaard om een informatiesysteem te specificeren en dus ook te beoordelen. Een informatiesysteem kent diverse soorten gebruikers; in elk geval de eigenaar, functioneel beheerders, eindgebruikers en systeembeheerders. Iedere soort gebruiker heeft zo zijn eigen kijk op het informatiesysteem en stelt zijn eigen (kwaliteits)eisen aan het informatiesysteem.
Het selecteren van die (kwaliteits)attributen die voor één soort gebruikers van belang zijn, vindt plaats in stap 1 van het stappenplan (identificeren) van de evaluatie. Het nagaan welke kwaliteitsattributen mogelijk van belang zijn, hoeft niet voor ieder nieuw project opnieuw uitgevoerd te worden. Beheerders, opdrachtgevers en front office-gebruikers hebben een patroon dat ‘enige jaren’ vast ligt.
Stap 2 van het stappenplan (waarderen) mag op het eerste gezicht geen problemen opleveren. Immers tijdens de requirement-fase (het opstellen van het programma van eisen) en het ontwerp is deze waardering al uitgevoerd. Zonder deze waardering is het zeer lastig, zo niet onmogelijk een goede acceptatietest uit te voeren. Een acceptatietest geeft een uitspraak over de mate van tevredenheid die de gebruiker kan ervaren dan wel over het risico dat de gebruiker zich niet kan vinden in het op te leveren informatiesysteem.
Stel dat het informatiesysteem opgeleverd is en dat het draait. Het is nu zinnig na te gaan of de waardering voor het informatiesysteem nog steeds strookt met de oorspronkelijke uitgangspunten. En deze controle is in wezen niets anders dan het opnieuw bepalen van de waardering voor het informatiesysteem.
Er kunnen diverse redenen zijn waarom het zinnig is deze waardering voor het opgeleverde informatiesysteem te bepalen. Enkele voorbeelden: de informatiebehoefte kan veranderd zijn door invoering van het informatiesysteem; de organisatie kan veranderd zijn; de belasting van het totaal computersysteem kan de gebruiker van het informatiesysteem positief of negatief beïnvloeden; enzovoorts.
Op basis van een vragenlijst die op een indirecte manier refereert aan de kwaliteitsattributen kan die waardering van de attributen plaatsvinden. De vragenlijst dient zodanig opgesteld te zijn dat de woordkeuze en de vraagstelling past bij de te onderzoeken gebruikersgroep. Een alternatief voor de vragenlijst kan het houden van enquêtes zijn, maar dit is meestal niet goedkoper.
Stap 3 van het stappenplan (specificeren). Stap 2 kan aanleiding zijn tot verder onderzoek: waarom zijn de gebruikers zo tevreden of waarom juist niet. Een goed vooronderzoek en bijvoorbeeld de juiste aandacht voor de impact van het informatiesysteem kunnen redenen zijn waarom de gebruikers zo tevreden zijn. Trends kunnen zichtbaar gemaakt worden. Er wordt in de praktijk nog te vaak te weinig aandacht besteed aan de redenen waarom het juist goed gaat (of ging). Zijn de gebruikers niet tevreden of niet voldoende tevreden dan dient verder onderzoek de oorzaak hiervan op te sporen.
Voor het uitvoeren van de stappen 2 en 3 kan een brainstormsessie een manier van aanpak zijn. Juist een brainstormsessie levert een hoge mate van betrokkenheid op.
Stap 4 van het stappenplan (taxeren). Nadere analyse van de resultaten van stap 2 en stap 3 geeft inzicht in de gebruikers(on)tevredenheid. Het resultaat van stap 4 geeft inzicht in effectieve maatregelen om risico’s aan te pakken. Of het verschaft informatie over juist die problemen die de organisatie in de toekomst te wachten staan. Of het geeft inzicht in de prioriteitsstelling voor de aanvragen tot verandering.
Stap 5 van het stappenplan (elimineren). Een goed uitgewerkte stap 4 geeft voor stap 5 de juiste informatie, die het management (de eigenaar van het informatiesysteem) de mogelijkheid biedt knopen door te hakken.
Evaluatie en tevredenheid
Een productevaluatie en een gebruikerstevredenheidsonderzoek liggen niet ver uit elkaar; sterker nog, een productevaluatie is in feite een bijzondere vorm van zo’n onderzoek. Ook voor een dergelijk onderzoek geldt het referentiekader ISO 9126.
Het verschil tussen een productevaluatie en een tevredenheidsonderzoek zit vooral in de analyse van de resultaten van de evaluatie en de terugkoppeling naar het proces van systeemontwikkeling, de causal analysis. Bij een productevaluatie wordt geanalyseerd waar het ‘mis’ (of juist goed) ging. Het project heeft een productrisicomatrix opgesteld. In zo’n matrix wordt aangegeven in welk tussenproduct tijdens de systeemontwikkeling een kwaliteitsattribuut een rol speelt of, sterker nog, aangetoond kan worden. Het moge duidelijk zijn dat een niet juist opgestelde productrisicomatrix kan leiden tot problemen bij de gebruikers. Ook als de systeemontwikkelaars niet juist omgaan met de matrix kan dit leiden tot problemen bij de gebruikers. Een juiste analyse levert ongetwijfeld een aantal verbeterpunten voor volgende projecten op.
Tijdens het analyseren is het niet juist slechts de problemen te zien. Ieder project heeft ongetwijfeld ook goede punten. Deze goede punten dienen opgenomen te worden in een best practices database. Nieuwe projecten moeten putten uit deze database.
Een organisatie die bewust omgaat met verbeteringen stelt voor ieder project met de projectleider een aantal punten op die speciale aandacht krijgen bij het nieuwe project. Deze aandachtspunten zijn juist verdeeld over goede punten van het systeemontwikkelproces en over te verbeteren punten. Zo’n aanpak staat garant voor een groei naar volwassenheid op de CMM-ladder.
Kwaliteit van het proces
Het maken of onderhouden van een informatiesysteem gebeurt door het primaire systeemontwikkelingsproces; vooronderzoek, programma van eisen, ontwerpen, realiseren, accepteren en in gebruik nemen. Het primaire proces wordt ondersteund door een aantal (secundaire) processen. Voorbeelden van (secundaire) processen zijn requirement management, project planning en tracking, software configuration management.
Deze ondersteunende processen bepalen voor een groot deel de kwaliteit van het ontwikkelproces. Een niet goed ingericht managementproces voor softwareconfiguratie kan een behoorlijk probleem veroorzaken bij het beheersen van de versies die een informatiesysteem doormaakt, voordat een definitieve versie van het informatiesysteem het levenslicht ziet. Het hoeft niet per se tot problemen bij de eindgebruikers te leiden. Vaak heeft een project een ‘held’ die iedere keer weer opnieuw in staat is orde op zaken te stellen en de juiste onderdelen in de juiste volgorde op het juiste moment samen te stellen. Voor de eindgebruiker van het informatiesysteem telt echter alleen de uitkomst van dit software-configuratieproces en niet de efficiëntie van het systeem-ontwikkelingsproces. (Indirect zal deze efficiëntie wel zichtbaar zijn in de kosten van het informatiesysteem.)
Regelmatig doorlichten van de manier van werken en stilstaan bij goede en te verbeteren punten van het systeemontwikkelingsproces behoren tot de procesevaluatie.
Beoordelingscriteria
Een procesevaluatie kent de volgende voorwaarden:
- Het management staat in woord en daad achter het evalueren. Goede evaluaties betalen zich uiteindelijk dubbel terug. Het management gebruikt de evaluaties niet om te (ver)oordelen.
- De evaluatie dient in elk geval plaats te vinden op een moment dat het project ‘nog net niet’ is afgesloten. De projectleden voelen zich dan nog redelijk betrokken en de feiten zijn nog niet vervaagd. Een evaluatie in een nog eerder stadium biedt bovendien de mogelijkheid tijdig bij te sturen.
- De projectleden zelf zijn de basis om verbeteringen te definiëren. Zo wordt mede een draagvlak voor verbeteringen voor een volgend project geschapen.
- De evaluatie moet ‘snel’ uit te voeren zijn. Naarmate de resultaten van een evaluatie langer op zich laten wachten wordt de betrokkenheid van de medewerkers geringer.
- Qua kosten moet de evaluatie redelijk zijn. Echter: ieder project verdient een evaluatie. De evaluatie moet in redelijke verhouding blijven staan tot de kosten van het project. Het evaluatiemechanisme moet die flexibiliteit bezitten.
- Het effect moet zichtbaar zijn. Een best practices database is daarom een voorwaarde. Het management moet er op toezien dat nieuwe projecten speerpunten definiëren.
- De evaluatie van het systeemontwikkelingsproces en de productevaluatie zijn twee verschillende evaluaties.
Referentiemodel
Bij de product-evaluatie werd het ISO 9126-model gehanteerd. Voor de proces-evaluatie zijn er weliswaar diverse referentiemodellen maar die zijn allemaal min of meer ongeschikt. Het inzetten van beoordelingen volgens het Capability Maturity Model of het Model Nederlandse Kwaliteit is voor kleinere projecten met relatief korte doorlooptijd niet realistisch. Deze evaluaties nemen te veel tijd in beslag, de uitwerking van de resultaten laat verhoudingsgewijs te lang op zich wachten, niet alle facetten komen voor, de aanpak is te abstract en vereist inzet van specialisten.
Bij gebrek aan een referentiemodel werd een eigen referentiemodel ontwikkeld. Hierbij is gebruikgemaakt van de structuur van ISO 9126. Naar analogie van de hoofdkenmerken zijn voor het proces aandachtsgebieden bepaald. Enkele aandachtsgebieden zijn in ieder geval: projectorganisatie, bemensing, projectomgeving, methoden, technieken en communicatie.
Hoofdkenmerken bij ISO 9126 bestaan uit attributen. De aandachtsgebieden bestaan uit een aantal aspecten. Zo kan het aandachtsgebied bemensing uit de volgende aspecten bestaan: capaciteit, kennis- en ervaringsniveau, motivatie en kennisoverdracht. De aandachtsgebieden moeten wel zodanig opgesteld worden dat ze enige tijd meegaan, anders wordt het vergelijken van resultaten uit de diverse projecten nogal moeilijk. Per aspect worden vragen opgesteld die op een schaal van ‘slecht tot goed’ beoordeeld moeten worden.
Het uitvoeren van de procesevaluatie kent ook de aanpak van het stappenplan: identificeren, waarderen, specificeren, taxeren en elimineren.
Stap 1: identificeren. Ga na welke aandachtsgebieden van belang zijn voor het te evalueren project. Stel de vragenlijst op. Houd er rekening mee dat de vragenlijst een tijd mee moet en dus niet per project opgesteld wordt. Het kenmerk van de vragenlijst moet zijn dat deze lijst snel in te vullen is. Als een vragenlijst uitnodigt tot commentaar dan geven de projectmedewerkers ook commentaar. Het risico is dan dat de vragenlijst op de grote stapel van ‘nog te doen’ terechtkomt. Commentaar hoort meestal thuis bij stap 3.
Stap 2: waarderen. Laat de projectmedewerkers de vragenlijsten onafhankelijk van elkaar invullen. Uit de verwerking van de vragenlijsten komt nu een waardering van een aantal aspecten boven tafel. De belangrijkste (zowel positieve als negatieve waardering) vormen input voor de volgende stap.
Stap 3: specificeren. In een vergadering met alle projectmedewerkers worden de belangrijkste aspecten van stap 2 gespecificeerd. Uitkomst is een lijst met ideeën en aanbevelingen voor volgende projecten. De best practices database wordt aangevuld met de goede aanbevelingen. (Een aanbeveling kan natuurlijk ook zijn dat in een volgend project bepaalde dingen niet op die en die manier aangepakt moeten worden.)
Stap 4: taxeren. Ga na welke hobbels men tegen kan komen bij opvolging van de resultaten van stap 3. Betrek in deze fase ook het management in het evaluatieproces.
Stap 5: elimineren. Bedenk maatregelen om de risico’s van stap 4 te elimineren. Het betrekken van de projectmedewerkers bij de stappen 4 en 5 werkt zeer positief. Zij zijn immers diegenen die in stap 3 concrete verbeteringen hebben aangedragen die door de meerderheid gedragen worden. Zij vormen een belangrijk draagvlak voor de implementatie van de verbeteringen.
Lijfs- en bedrijfsbehoud
Evalueren moet en is essentieel voor de (continue) verbeteractiviteiten van de systeemontwikkelingsorganisatie. Een goede evaluatie komt van binnenuit en dient gedragen te worden door het management. Het evalueren van projecten bestaat uit twee verschillende evaluaties: een product- en een procesevaluatie. Voor de productevaluatie dient ISO 9126 als referentiemodel. Voor de procesevaluatie is geen werkend model voorhanden. Echter, bij het maken van een eigen referentiekader staat de structuur van ISO 9126 model.
De aanpak van ‘Kwaliteit op Maat’ volgens het stappenplan met de stappen: ‘identificeren’, ‘waarderen’, ‘specificeren’, ’taxeren’ en ‘elimineren’ is niet alleen een aanpak om een project goed op de rit te zetten en te houden, maar ook een aanpak om evaluaties op te pakken en uit te voeren.
Jos van Vroonhoven en Jean-Jacques Pirson, Software Control en Kwaliteitszorg
Iquip Informatica
Paul van Alphen, Kwaliteitsmedewerker Belastingdienst/Automatiseringscentrum
Literatuur
[1] A. Boeters en B. Noorman, ‘Kwaliteit op Maat’, IT-projecten beheersen met de Radar-methode’, Kluwer BedrijfsInformatie, ISBN 90-267-2579-5 (1997).
Het Capability Maturity Model
CMM is in de VS ontwikkeld door het Software Engineering Institute (SEI) en beschrijft een evolutionair pad van een ad-hoc, chaotisch naar een gedisciplineerd softwareproces. Om met verbeteracties blijvende resultaten te verkrijgen, is het noodzakelijk om een pad te scheppen waarlangs de mate van volwassenheid van het softwareproces stapsgewijs kan worden verbeterd. Het CMM is daarom opgedeeld in vijf stappen (levels) of volwassenheidsniveaus. Elk niveau vormt een fundament voor verbetering op het volgende niveau. CMM Level 1 typeert het laagste niveau van beheersing van het proces. Projecten op dit niveau worstelen over het algemeen met beheersaspecten.
