Een waardige opvolger

Het ‘oude’ Capability Maturity Model is een successtory. Het is de de facto-standaard voor verbetering van systeemontwikkeling. Onder het motto: ‘never change a winning concept’ kun je dus verwachten dat het CMM het CMM blijft. Toch heeft het Software Engineering Institute (SEI), de ontwikkelaar van het model, eind 2001 de opvolger geïntroduceerd: het CMMI. In het CMMI is veel van de kritiek die op het CMM is geuit verwerkt. De essentie van deze kritiek is dat het CMM in hoge mate inflexibel is. Het biedt een ‘one size fits all’-benadering van softwareprocesverbetering. Men moet het doen zoals het in het CMM staat. Dit kan bij sommige organisaties leiden tot onnodige bureaucratie, het belemmert organisaties in het stellen van eigen prioriteiten en het werkt soms zelfs contra-productief. De kracht van het CMM is tegelijk zijn zwakte. Door slechts één marsroute op te nemen, weten organisaties precies wat er dient te gebeuren om het softwareproces te verbeteren, het is daardoor echter wel inflexibel. Het CMMI behoudt de voordelen van het CMM terwijl het tegemoet komt aan de nadelen doordat het CMMI twee voorstellingen (representations) kent: gelaagd (staged) en continu (continuous). De gelaagde voorstelling is in hoge mate vergelijkbaar met het oude CMM. Het kent vijf niveaus van volwassenheid waarlangs organisaties hun systeemontwikkelingsproces verbeteren. Per niveau kent het CMMI een aantal procesgebieden. Om op een bepaald niveau te komen dient aan alle eisen van de procesgebieden van dat niveau te worden voldaan. De continue voorstelling heeft een hele andere opbouw. Hier zijn de procesgebieden niet ingedeeld naar volwassenheidsniveau. De procesgebieden zelf kennen vijf niveaus. De volgorde van de implementatie van de procesgebieden bepaalt de organisatie in theorie zelf, de volwassenheid per procesgebied ook. Deze vlieger gaat niet helemaal op, want er zijn een groot aantal afhankelijkheden tussen de procesgebieden, maar het is wel een stuk flexibeler dan de gelaagde voorstelling. Flexibeler De continue voorstelling van CMMI is dus veel flexibeler en kan aangepast worden aan de situatie en wensen van de organisatie. Heeft de gelaagde voorstelling dan wel bestaansrecht? Zeker! Organisaties die hun systeemontwikkeling willen verbeteren kunnen ingedeeld worden in twee categorieën. Aan de ene kant hebben we de organisaties die doorhebben dat het systeemontwikkelingsproces niet beheerst verloopt, zij weten dat het moet verbeteren maar hebben geen idee in welke volgorde dat moet gebeuren en wat het niveau is dat de organisatie wil halen. Onvriendelijk gezegd hebben deze organisaties geen (eigen) visie op het verbeteren van systeemontwikkeling. Zij kunnen het beste de gelaagde variant gebruiken. Deze neemt ze bij de hand, vertelt wat ze moeten verbeteren en in welke volgorde. Hiermee bewandelen ze een bewezen weg naar succes. Aan de andere kant zijn er de organisaties die precies weten wat er goed en wat er misgaat. Ze kunnen aangeven welke zaken moeten verbeteren en welk niveau ze op die gebieden willen bereiken. Deze organisaties hebben dus een visie op het gebied van het verbeteren van systeemontwikkelingsprocessen. Deze visie dient wel vertaald te worden naar concrete procesgebieden en niveaus, maar de organisatie bepaalt dus zelf haar marsroute. Consultants De twee voorstellingen hebben grote gevolgen voor CMM-implementaties en CMM-consultants. De aanpak van een CMM-implementatie was vroeger relatief eenvoudig. Er werd begonnen met een nulmeting (assessment). Organisaties die weinig aan kwaliteitsverbetering hadden gedaan kwamen meestal uit op het laagste niveau, niveau 1. Op basis van de uitkomsten werden de procesgebieden van het volgende niveau opgepakt en één voor één geïmplementeerd. Over de volgorde werd soms nog nagedacht, maar meestal werd de standaardvolgorde van het CMM gehanteerd. Overigens is het feitelijke veranderingsproces wel een complexe aangelegenheid, de opzet was echter relatief eenvoudig. Met het CMMI is dit niet meer zo makkelijk. Allereerst verandert de nulmeting. Naast het vaststellen of aan bepaalde eisen wordt voldaan dient ook te worden vastgesteld waar de grootste voordelen te behalen zijn. Dit betekent dus een andere manier van interviewen en informatie vergaren. Naast vaststellen of een bepaald niveau is gehaald dient beoordeeld te worden of dit een werkbare situatie is en op welke gebieden de grootste winst te behalen is. Hierbij spelen visie, strategie, kwaliteitsbeleid en cultuur een belangrijke rol. Het voortraject van CMMI-implementaties vraagt dus al veel meer van de consultant. Vervolgens dient er een consistent plan van aanpak te worden gemaakt. Om dit te implementeren is een bredere kennis van de consultants nodig. Ieder traject wordt anders, succesformules zijn minder makkelijk te kopiëren. Prioriteiten En of dat nog niet allemaal genoeg is dient op basis van de ervaringen tussentijds beoordeeld te worden of de organisatie nog steeds de juiste zaken aan het verbeteren is. Dat heeft dan weer tot gevolg dat een nieuw plan van aanpak gemaakt wordt met nieuwe prioriteiten. Is het dat allemaal waard? Kunnen we niet gewoon het oude, vertrouwde concept van de gelaagde voorstelling hanteren? In sommige situaties wel. Er dient echter wel eerst beoordeeld te worden of dit de aanpak is die het meeste oplevert. In andere situaties verdient een op de organisatie afgestemde aanpak de voorkeur. Een belangrijke vraag is natuurlijk of het CMMI gebruikt gaat worden. Op dit moment is het gebruik nog miniem, wat niet vreemd is gezien de recente verschijning. Er is nog weinig praktijkervaring. Diverse organisaties beoordelen op dit moment of ze het CMMI gaan gebruiken. Andere experimenteren er al mee. De verwachting is dat het model zijn weg naar de softwarewereld zal vinden. De voordelen zijn van dien aard dat de verwachting gerechtvaardigd is dat het CMMI de nieuwe standaard voor procesverbetering wordt. Het SEI heeft ondanks het succes van CMM de kritiek ter harte genomen en veel hiervan verwerkt in het CMMI. Een waardige opvolger dus. Drs. H.J.J. Cannegieter (jcannegieter@sysqa.nl) is productmanager van SYSQA BV, een onafhankelijke organisatie gespecialiseerd in kwaliteitszorg in ICT. Hij is de auteur van het in 2001 uitgegeven boek ‘Kwaliteitszorg in ICT-projecten’.