Het kost ICT-dienstverleners grote moeite om het hun klanten naar de zin te maken. Om de haverklap bereiken berichten de pers over afnemers van ICT-diensten die hun leveranciers aansprakelijk stellen voor het falen van projecten. Andersom neemt bij de dienstverleners de irritatie toe over de ‘klant die niet weet wat hij wil’. De achterliggende oorzaak is vaak gelegen in onduidelijke afspraken omtrent (project)doelen. Toch kan het ook anders. Het opstellen en onderhouden van een eisendossier bevordert de communicatie tussen leverancier en afnemer én de kans op succes, zo stelt een productmanager.
Afgaande op recente onderzoeken slaagt de ICT-sector er bij maar liefst tweederde van de projecten niet in om kwaliteit, op tijd en binnen budget op te leveren. Hoe is dit mogelijk? Het personeel van de meeste ICT-dienstverleners is hoog opgeleid, gemotiveerd en ambitieus. Moderne ontwikkeltools zorgen er (in theorie) voor dat er minder fouten gemaakt kunnen worden bij het ontwerpen en bouwen van informatiesystemen. Allerlei vernieuwende ontwikkelmethodieken zoals rad (rapid application development) en dsdm (dynamic system development methodology) beogen systemen sneller en goedkoper te ontwerpen en te bouwen. Waarom gaat het dan toch zo vaak mis? Aangezien de wereld niet zwart-wit in elkaar steekt, is er niet één allesomvattende oorzaak aan te wijzen. Een complex samenspel van factoren ligt aan de basis van het falen van projecten. Voorbeelden van dergelijke faalfactoren zijn het ontbreken van een ervaren projectleider met een helder mandaat, een te optimische inschatting in de startfase, een gebrek aan betrokkenheid van de (gebruikers)organisatie, onervarenheid van het IT-personeel en het gemis aan wederzijdse verbondenheid en vertrouwen binnen het projectteam
Eisenpakket
De opsomming is zeker niet volledig, maar illustreert met welke problematiek men in projecten geconfronteerd kan worden. De belangrijkste reden voor het falen van projecten ontbreekt nog in dit overzicht. Dit is het feit dat er vaak onduidelijkheid bestaat omtrent de doelstellingen van het project en de eisen die aan het op te leveren product worden gesteld. Een typisch voorbeeld daarvan ondervond ik tijdens een omvangrijk project waarbij ik als testmanager betrokken was. Op basis van een overeenkomst van twee A4’tjes werd door de organisatie in kwestie opdracht gegeven tot de bouw van een informatiesysteem. Ongeveer een jaar later werd ik ingezet op het project. Vervolgens kwam binnen enkele weken aan het licht dat de opdrachtgever en de leverancier een totaal verschillende beeld hadden van het eindresultaat. Besloten werd om alsnog in kaart te brengen aan welke eisen het systeem diende te voldoen. Het spreekt voor zich dat hier veel tijd mee was gemoeid. De uitkomsten van de inventarisatie noopten bovendien tot een aanzienlijke herziening van de programmatuur. Het zal geen verbazing wekken dat het project niet op tijd werd opgeleverd. Was er echter bij de start overeenstemming bereikt over de projectdoelstellingen, dan had men zich veel tijd en geld kunnen besparen.
Taal verstaan
Het bovenstaande voorbeeld is zeker niet uniek. In tal van projecten komt pas tijdens de acceptatiefase aan het licht dat het opgeleverde systeem niet aansluit bij de eisen en wensen van de klant. Soms is het dan al te laat en wordt het project afgeblazen. Waarschijnlijker is dat de oplevering vertraagd wordt en dat de gebruikers uiteindelijk opgescheept zitten met een systeem dat net (niet) voldoet. De kern van het probleem is dat ontwikkelaars en afnemers van ICT-producten elkaars taal niet verstaan. De remedie is even eenvoudig als doeltreffend. Opdrachtgever en opdrachtnemer dienen bij aanvang van het project te inventariseren wie de belanghebbenden bij het resultaat zijn en welke eisen door hen worden gesteld. Dit kan middels een of meerdere workshops. In overleg met de betrokkenen worden de eisen vervolgens geprioriteerd. Zodoende wordt duidelijk welke eisen bepalend zijn voor acceptatie van het product. Met behulp van een norm van de International Organization for Standardization (ISO) vindt een vertaling plaats naar meetbare grootheden. Deze norm, ISO 9126, beschrijft hoe de kwaliteit van software producten meetbaar kan worden gemaakt. Dit geschiedt door de relevante kwaliteitseigenschappen te bepalen en per eigenschap een aantal indicatoren overeen te komen die voorschrijven op welke wijze meting plaatsvindt. Grote voordeel van het hanteren van deze norm is dat de eisen aan een informatiesysteem eenduidig worden beschreven. De kans op misverstanden wordt daardoor geminimaliseerd.
Het aanleggen en onderhouden van een eisendossier bevordert de communicatie tussen partijen en daarmee de kans op succes. Door eisen te koppelen aan de fase van systeemontwikkeling waarin zij worden gerealiseerd, ontstaat inzicht op welk moment toetsing kan plaatsvinden. Als de quality assurance-activiteiten hierop worden afgestemd, worden fouten zo vroeg mogelijk ontdekt. De herstelkosten blijven daardoor tot een minimum beperkt. De combinatie van helderheid over de producteisen én vroegtijdige detectie van fouten bevordert de kans dat het project op tijd en binnen budget het gewenste resultaat oplevert.
Marco Dekkers, productmanager KZA kwaliteitszorg
waar kan ik de antwoorden vinden van het boek onderhoud en beheer in de praktijk van Ad J van Dijk
in dit hoofdstuk. Dit is praktijk casus 4.4