Door de risico’s vroegtijdig te onderkennen en daar passende maatregelen aan te koppelen, is de kans op een succesvol project groter. De radar-methode biedt de projectleider, die moet schipperen in de duivelsdriehoek van geld, tijd en kwaliteit, concrete middelen tot risicobeheersing. De methode is aanvullend op en onafhankelijk van de gehanteerde ontwikkelmethodiek.
Vanuit de traditionele projectmanagementtechnieken krijgt de projectleider hulpmiddelen aangereikt om het project te sturen. De belangrijkste (meest gebruikte) stuurmogelijkheden zijn budget-afhankelijke variabelen gerelateerd aan tijd en geld. In principe krijgt de projectleider vooral hulpmiddelen om het proces beheersbaar te maken.
De bekende ‘duivelsdriehoek’ geeft aan dat een project onder druk staat van tijd, geld en (product)kwaliteit. Omdat een projectleider vaak onvoldoende mogelijkheden heeft om op kwaliteit te sturen, wordt er vooral op tijd en geld gestuurd. Als er druk komt te staan op tijd of geld sneuvelt de kwaliteit meestal. Elke projectleider krijgt hier vroeg of laat mee te maken. Als de einddatum onder druk staat en het budget blijft hetzelfde, moet dit wel ten kosten gaan van de kwaliteit. Tijdens de productiefase blijkt dan dat gewenste functies ontbreken, dat de prestaties van het systeem onder de maat blijven of dat het veel geld kost om het systeem te onderhouden.
Het ontbreekt dus aan mogelijkheden om op kwaliteit te sturen. Basisvoorwaarde is kennis van de verwachtingen. Om aan kwaliteitseisen en -wensen te kunnen voldoen, moet het projectteam deze wel kennen. De gewenste productkwaliteit kan er niet aan het einde van het ontwikkeltraject ‘nog even ingetest worden’. Bovendien heeft Boehm al in 1973 duidelijk gemaakt dat tekortkomingen het beste in een zo vroeg mogelijk stadium kunnen worden aangetoond, omdat de herstelkosten dan het kleinst zijn.
Het projectteam moet dus vanaf het allereerste begin de verwachtingen kennen om het juiste product te kunnen maken. Het informatiesysteem moet aan de verwachtingen voldoen, maar ook weer niet (veel) meer dan dat. Waar dat niet mogelijk is, moeten de verwachtingen tijdig worden bijgesteld. Een goed project levert ‘kwaliteit op maat’.
Maar welke extra inspanningen zijn er nu precies nodig in het project om dat zeker te stellen ?
Het projectteam moet een bepaald informatiesysteem bouwen. Maar wat dat systeem exact moet doen, zit vooral in de hoofden van de gebruikers. Allereerst dient dus het beeld dat de gebruiker van het nieuwe systeem heeft, te worden overgedragen aan de leden van het projectteam. Een complicatie daarbij is dat ‘de gebruiker’ niet bestaat: er zijn veel gebruikers, vaak met specifieke eigen wensen. Het projectteam moet daarom een ’totaalplaatje’ zien te krijgen van alle verwachtingen (probleem 1). Als het projectteam eenmaal een duidelijk beeld heeft van het nieuwe systeem, moet dat beeld nog wel gerealiseerd worden (probleem 2). Ook daarbij kan van alles fout gaan. Eisen kunnen bijvoorbeeld verloren gaan in het proces. Verder is het automatiseerders eigen om alles mooier te willen maken dan strikt genomen wenselijk is en om eigen goede ideeën aan het systeem te willen toevoegen.
Als het gewenste systeem is gerealiseerd, moet het beoordeeld en geaccepteerd worden. Idealiter doen gebruikers en andere belanghebbenden (zoals opdrachtgever en beheerder) dat zelf. Daarbij vergelijken ze het nieuwe systeem met de eigen verwachtingen. Het probleem is dat hier niet de verwachtingen worden gehanteerd die als uitgangspunt voor het project golden, maar de verwachtingen van dat moment. Verwachtingen hebben de natuurlijke neiging te verschuiven in de loop van de tijd (probleem 3). De discrepantie tussen oorspronkelijke en huidige verwachtingen wordt uiteraard groter naarmate de doorlooptijd van het project groter is. Wanneer de verwachtingen veranderen, moet de projectleider �f het project bijstellen, �f de ontstane verwachtingen bijsturen ! De projectleider moet de verwachtingen dus op elk moment kennen.
Hij zal de drie probleemgebieden beheersbaar moeten houden om aan het eind van de rit het verwachte informatiesysteem te kunnen leveren. Daarnaast kan er ook procesmatig in een project van alles fout gaan (probleemgebied 4). Het resultaat is dan wellicht nog wel een goed systeem, maar te laat of te duur (en meestal een combinatie van beide).
De rol van specificaties
Projecten buiten de IT-wereld kennen in wezen dezelfde problematiek. Het op te leveren product is in specificaties vastgelegd en er zijn afspraken over oplevering en kosten. Bij de bouw van een woning krijgt de aannemer een gedetailleerde bouwtekening (bestek en voorwaarden) van de architect aangeleverd. Naast alle unieke wensen van de opdrachtgever, is ook rekening gehouden met alle wettelijke voorschriften.
De IT-praktijk blijkt lastiger: de architect ontbreekt en de gedetailleerde bouwtekeningen zijn voor een gebruiker niet te begrijpen. Het project levert een dik pak specificaties op waaruit alle betrokkenen geacht worden de voor hen belangrijke informatie te destilleren. Het document bevat vaak veel meer details dan gebruikers, beheerders of opdrachtgevers nodig hebben. De belangrijkste doelgroep voor de specificatie blijkt in de praktijk toch vaak de groep die ermee verder moet: de automatiseerders zelf. Aan de andere kant zijn de specificaties vaak te beperkt. De gewenste functionaliteit is nog wel expliciet gemaakt, maar zaken als bruikbaarheid, snelheid en onderhoudbaarheid komen vaak in een veel later stadium aan de orde (vaak zelfs pas na oplevering). Eisen en wensen op dit gebied zijn zeer wezenlijk voor een projectteam, omdat de eerste opzet van het systeem al bepalend is voor veel van dergelijke eigenschappen.
De bedoeling van een specificatiedocument moet dan ook in een ander licht worden gezien: het moet de eerste vertaalslag van gebruikers naar projectteam vastleggen tot op het niveau dat het projectteam de risico’s kan bepalen die het project gaat lopen bij de realisatie daarvan.
De radar-methode
Het opgeleverde informatiesysteem kan op twee fronten tekort schieten: de functionaliteit is onvoldoende (het systeem biedt niet die ondersteuning die het bedrijfsproces nodig heeft) of de manier waarop het systeem die functionaliteit biedt, de hoedanigheid, deugt niet (het systeem is bij voorbeeld te moeilijk te gebruiken of te traag).
Behalve productrisico’s loopt een project procesrisico’s. Over projectmanagement zijn vele boeken geschreven. Projecten worden beheerst op basis van plannen; de kwaliteit van de plannen en van de uitvoering en bijstelling ervan bepaalt voor een belangrijk deel de voorspelbaarheid van het projectverloop en de resultaten.
Wanneer de planmatige beheersing van het project goed is, zijn er altijd nog externe factoren die het projectverloop nadelig kunnen beïnvloeden, zoals een reorganisatie of een wetswijziging. Dergelijke omgevingsfactoren vormen eveneens een risicogebied dat de projectleider zal moeten bewaken.
Wanneer de eisen en wensen (de verwachtingen) niet duidelijk zijn bij het projectteam, ontbreken ook de stuurmiddelen. De radar-methode biedt een aanpak waarin deze stuurmiddelen centraal staan. Verwachtingen ten aanzien van het proces worden door de opdrachtgever onder andere uitgedrukt in tijd en geld. Verwachtingen ten aanzien van het product worden uitgedrukt in functionele en in hoedanigheidseisen. Wanneer de stuurmiddelen voor productkwaliteit onvoldoende zijn, is het logisch dat de projectleider vroeger of later ’terugvalt’ op de traditionele stuurmiddelen tijd en geld. Als de projectleider dat zelf niet doet, dwingt de opdrachtgever hem daar wel toe.
Een goede projectleider is eigenlijk voortdurend bezig met risico- management. Waar zitten de bedreigingen voor mijn project en wat kan ik daar aan doen ?
Feitelijk heeft een projectleider een ingebouwde radar nodig, zoals bijvoorbeeld de ‘goalkeeper’ die heeft. De ‘goalkeeper’, bekend geworden in de golfoorlog, is een verdedigingssysteem met een radar in drie lagen. De omgevingsradar signaleert objecten die een risico kunnen vormen. De volgradar neemt een object over dat te dicht in de buurt komt en wellicht een bedreiging zou kunnen vormen. Als blijkt dat een object inderdaad als een bedreiging moet worden gezien, houdt de schietradar het object vast tot het risico is geëlimineerd
Het zou natuurlijk mooi zijn als een projectleider ook over een dergelijke ‘gelaagde radar’ zou beschikken. Niet omdat een project hetzelfde is als oorlog voeren, maar wel omdat er een analogie bestaat met de stappen voor risicobeheersing in een project. In de radar-methode zijn deze stappen dan ook weer terug te vinden. Om de vier genoemde risicogebieden (functionele-, hoedanigheids-, planmatige- en omgevingsrisico’s) beheersbaar te maken, hanteert de methode vijf stappen.
Eerst moeten de mogelijke risico’s worden onderkend (de ‘omgevingsradar’). Die risico’s zijn rechtstreeks gekoppeld aan de verwachtingen. Elke eis of wens is in potentie een risico. Deze eisen en wensen moeten eerst worden geïdentificeerd (1). Vervolgens bepaalt het belang van een bepaalde eis of wens de omvang van het risico; de individuele eisen en wensen moeten worden gewaardeerd (2). Belangrijke eisen moeten in een vroeg stadium gerealiseerd worden; voor belangrijke eisen is bijvoorbeeld een grotere testinspanning gerechtvaardigd. Tenslotte moeten de eisen en wensen voldoende concreet worden gemaakt voor het projectteam (gespecificeerd, (3)). De doelstelling hierbij is dat het projectteam begrijpt wat er verwacht wordt en dat het in staat is de risico’s te bepalen die het project daarbij loopt. Doelstelling is dus niet een gedetailleerde specificatie waarin de ontwikkelaars alvast een voorschot nemen op de verschillende ontwerpbeslissingen die nog genomen moeten worden.
Als het projectteam dan tot de conclusie komt dat aan het realiseren van bepaalde verwachtingen duidelijke risico’s zijn verbonden (taxeren (4), de ‘volgradar’), kan de projectleider maatregelen nemen om deze risico’s te elimineren ((5), de ‘schietradar’).
Wanneer gebruikers ‘snelheid’ als een belangrijke eigenschap van het systeem hebben genoemd en deze verwachting meetbaar hebben gemaakt door een aantal concrete eisen te specificeren (stappen 1 t/m 3) moet het projectteam zich afvragen hoe gemakkelijk het is, gegeven bijvoorbeeld de omgeving waarin het systeem moet draaien, aan die eisen te voldoen. Wordt het risico te groot geacht, dan zijn extra maatregelen nodig om vroegtijdig na te gaan �f en hoe aan de eisen voldaan kan worden. In het uiterste geval zal de verwachting van de gebruikers moeten worden bijgesteld.
Functionaliteit vs hoedanigheid
Vaststellen welke eigenschappen bepalend zijn voor het succes van een informatiesysteem vormt een probleem op zich. De functionaliteit van een (nieuw) systeem bepalen is één ding, het concretiseren van de overige eisen blijkt in de praktijk vaak veel lastiger. Toch wordt het succes van een nieuw informatiesysteem in toenemende mate bepaald door eigenschappen als beschikbaarheid, flexibiliteit, bruikbaarheid, snelheid en onderhoudbaarheid: de hoedanigheid van een systeem.
Dit heeft een aantal oorzaken. Software evolueert snel. Het onderscheid tussen bij voorbeeld twee tekstverwerkers zit ‘m al lang niet meer in de geboden functionaliteit, maar in zaken als gebruikersvriendelijkheid en uitwisselbaarheid van documenten (hoedanigheid). Bovendien verandert de aard van de systemen. Naast de bedrijfsgerichte systemen ontstaan meer en meer marktgerichte systemen. De gebruikers van het systeem zijn niet meer de medewerkers in de eigen organisatie, maar zijn met name ook daarbuiten te vinden (denk aan Internet-toepassingen). Dit stelt heel andere eisen aan het informatiesysteem (gebruikersvriendelijkheid, installeerbaarheid, enzovoort). Om snel op nieuwe marktontwikkelingen te kunnen reageren, worden ook flexibiliteit en in het verlengde daarvan onderhoudbaarheid steeds belangrijkere eigenschappen. Het is de kunst deze eigenschappen zodanig concreet te maken, dat een projectteam weet wat ervan verwacht wordt en dat het in staat wordt gesteld het verlangde systeem te realiseren en tijdig te leveren.
Bij het vaststellen van de hoedanigheidseisen spelen verschillende belangen een rol. De gebruiker wil een systeem waarmee hij plezierig kan werken; specifieke gebruikers zoals accountants stellen hele specifieke eisen, bij voorbeeld ten aanzien van traceerbaarheid van financiële gegevens. De toekomstige beheerder wil een systeem dat goed geëxploiteerd en onderhouden kan worden, en vanuit bedrijfsbelang (management) is het wellicht nodig het systeem goed te beveiligen.
De radar-methode bevat een hulpmiddel dat deze eigenschappen bespreekbaar maakt met de verschillende betrokkenen. Op basis van het Extended ISO-model (gebaseerd op ISO-9126, en nader uitgewerkt in het Quint II project) wordt op een pragmatische manier het relatieve belang bepaald van de verschillende eigenschappen en worden de belangrijke eigenschappen vervolgens concreet (= meetbaar) gemaakt. Op basis daarvan kan het projectteam aan de slag.
Naast eisen ten aanzien van het product zijn er ook eisen ten aanzien van het proces. Als het halen van een bepaalde einddatum belangrijk is en de bedrijfsrisico’s, gekoppeld aan het niet halen van die einddatum, duidelijk zijn, is de vraag aan het projectteam: hoe groot is het risico dat we met het project de einddatum niet halen ? En wat moeten we doen om dat risico beheersbaar te maken?
Verwachtingen
De radar-methode biedt de projectleider een benadering in concrete stappen om te komen tot risicobeheersing in een project. De methode is aanvullend op en onafhankelijk van de gehanteerde ontwikkelmethodiek. Achtergrond daarbij is dat kwaliteitszorg gedurende het project zich moet richten op die risico’s. Preventieve en detectieve activiteiten, zoals die in een kwaliteitsplan worden aangeven, moeten een afgeleide zijn van de risico’s in een project. Daar waar het fout kan gaan, zijn extra toets- en testactiviteiten gewenst of kan wellicht een productstandaard goede diensten bewijzen. Een benadering waarin alles klakkeloos wordt gestandariseerd, gereviewd en getest houdt een project onnodig op en kost te veel geld.
Voor een succesvol project moet het projectteam de verwachtingen kennen. Het gaat daarbij in eerste instantie om alle verwachtingen, ook die waaraan het project niet kan of niet wil voldoen. Het laatste woord is wat dat betreft aan de opdrachtgever, systeemeigenaar of budgetbeheerder. Voor het projectteam is het van belang dat duidelijk wordt wat er gerealiseerd moet worden en in hoeverre het systeem gaat afwijken van de bestaande verwachtingen. Waar nodig kunnen die verwachtingen vervolgens worden bijgesteld. Gebruikers moeten niet alleen tijdig weten wat ze gaan krijgen, maar ook wat ze niet gaan krijgen.
Andre Boeters en Bert Noorman zijn werkzaam als consultant bij IP/Informatica Projectgroep.