‘Succes is een keuze’
Om een softwareontwikkelingsproject succesvol uit te kunnen voeren, zullen de aanpak en projectinrichting zo goed mogelijk moeten aansluiten bij de business case van het project, de beslissingsstructuur, cultuur, politiek, markt et cetera. Te vaak nog kiest de leverancier voor de projectaanpak. Deze stelt in zijn offerte een algemene of eigen aanpak voor, zonder dat hij deze keuze goed kan onderbouwen. Dat is begrijpelijk, want de leverancier kent de organisatie van de opdrachtgever vaak niet goed genoeg. Opdrachtgevers besteden op hun beurt vaak te weinig aandacht aan het kritisch bekijken van de door de leverancier voorgestelde aanpak. Dit leidt maar al te vaak tot verschillende verwachtingen en denkbeelden bij de uitvoering van het project. Met als mogelijke gevolgen: het projectresultaat is van te lage kwaliteit, het project is te duur of het vergt te veel aandacht van de stuurgroep. De sleutel tot het succes van een softwareontwikkelingsproject ligt in eerste instantie bij de opdrachtgever zelf. Het project begint namelijk niet op het moment dat een overeenkomst met de leverancier wordt aangegaan. Al veel eerder, tijdens het schrijven van het bestek, moet de opdrachtgever nadenken over de wijze waarop hij tijdens de opdrachtuitvoering met de leverancier wil samenwerken. Omdat de opdrachtgever zelf als geen ander het project en de omgeving kent, kan hij de beste keuzes maken op de vier meest fundamentele inrichtingsaspecten van een softwareontwikkelingsproject, namelijk: de ontwikkelingsaanpak, omgaan met eisen en wensen, omgaan met de duivelsdriehoek (spanningsveld tussen tijd, budget en functionaliteit) en de taak/rolverdeling in het project. De opdrachtgever houdt de succesfactoren van zijn project in eigen hand door voorafgaand aan de uitbesteding van zijn softwareontwikkeling zelf deze vier keuzes te maken. Succes is een keuze, of beter gezegd: vier keuzes. Welke ontwikkelingsaanpak? Er zijn verschillende aanpakken mogelijk bij het ontwikkelen van software. Traditioneel is er de lineaire of watervalaanpak; tegenwoordig worden vaak iteratieve aanpakken toegepast. Elke aanpak heeft zijn kracht in specifieke situaties. Een belangrijke factor bij het bepalen van de meest geschikte ontwikkelingsaanpak, is de (on)zekerheid die de opdrachtgever heeft over de eisen aan de software. Bij onzekerheid zullen de eisen tijdens het project zeer waarschijnlijk nog veranderen. Een iteratieve aanpak is ingericht om met dit voortschrijdend inzicht om te gaan. Met een lineaire aanpak daarentegen heeft men bijvoorbeeld ingewikkelde procedures nodig om met deze veranderende eisen om te kunnen gaan. Dit kan het project flink vertragen of leiden tot ontevreden gebruikers. De keuze tussen lineair of iteratief wordt ook beïnvloed door het draagvlak voor het projectresultaat bij de toekomstige gebruikers. Een softwareontwikkelingsproject is immers bijna altijd een veranderingsproces. Zeker wanneer de verandering relatief omvangrijk is, helpt juist een iteratieve aanpak de gebruikers om deze verandering in een gedoseerd tempo door te maken. Hoe omgaan met eisen? Bij het testen van de ontwikkelde software ontstaat meestal veel discussie over de vraag of de software wel of niet voldoet aan de gestelde eisen. Vaak blijkt dan pas dat de eisen niet goed zijn vastgesteld. Dit kan leiden tot veel frustratie, escalaties en extra kosten. Het is dus zaak om vooraf afspraken te maken over het beheren en vastleggen van eisen. Het beheren van eisen betreft onder meer het inventariseren van alle eisen en het prioriteren daarvan. Men moet besluiten op welke wijze de eisen worden vastgelegd en hoeveel ruimte in het project gelaten wordt (en in welke fase) om fundamentele discussies te voeren over deze eisen. Als de leverancier in de ontwerpfase te weinig ruimte biedt aan dergelijke discussies, zorgt hij ervoor dat er tijdens de bouwfase (of erger nog: tijdens de acceptatietest) allerhande veranderingen de kop op kunnen steken. Haastige spoed is ook hier niet goed. Daarnaast blijkt dat het goed formuleren van een eis lastig is. Zo is het bijvoorbeeld verleidelijk te eisen dat het datamodel flexibel is. Maar hoe toetst men dit? Wat betekent flexibel voor de gebruiker? De leverancier zal altijd een voorbeeld weten te geven om de flexibiliteit aan te tonen en de opdrachtgever zal altijd een voorbeeld weten te geven waarin de oplossing niet flexibel blijkt te zijn. Het is dus van belang aan te geven op welke concrete aspecten flexibiliteit nodig is. Vervolgens is het belangrijk om de eis ‘smart’ te specificeren (specifiek, meetbaar, acceptabel, realistisch en tijdgebonden). Dit geldt overigens niet alleen voor flexibiliteit, maar voor alle kwaliteitsattributen. Hoe omgaan met de duivelsdriehoek? In softwareontwikkelingsprojecten is de uitdaging om met de beschikbare hoeveelheid tijd en geld de gewenste functionaliteit (met de gewenste kwaliteit) te realiseren. Het is een natuurwet dat het project anders verloopt dan de vooraf gemaakte inschatting van de hoeveelheid tijd en geld. Er zal dus geschipperd moeten worden, ofwel met het budget (tijd en geld) of met de functionaliteit. Deze onderlinge wisselwerking tussen tijd, geld en functionaliteit is de duivelsdriehoek. De spanning tussen deze drie aspecten is in elk project aanwezig. Daarom is het belangrijk dat de opdrachtgever vooraf nagaat op welk van de aspecten verschuivingen het minst wenselijk zijn. Als dit vervolgens in het bestek duidelijk wordt gemaakt, kan de leverancier ervoor zorgen dat projectinstrumenten (zoals rapportage over budgetuitputting en over verwacht benodigd budget, of het periodiek kunnen evalueren van prioriteiten aan eisen) worden aangeboden waarmee de opdrachtgever de risico’s zo veel mogelijk kan beperken. De veelvoorkomende eis van ‘fixed price/ fixed date’ betekent onherroepelijk dat de functionaliteit of de kwaliteit daarvan in enige mate variabel wordt. Als vooraf niet is afgestemd hoe men hiermee om moet gaan, kan dit tot gevolg hebben dat de relatie tussen de opdrachtgever en leverancier voortdurend onder spanning komt te staan. Het hard fixeren van zowel budget als functionaliteit wordt wel eens geprobeerd, maar is dus niet reëel. Vergelijk het met een ballon: als je er aan één kant de lucht uitknijpt, komt de andere kant verder onder druk te staan. Knijpt men ook daar de lucht eruit, dan klapt de ballon onherroepelijk. Wie doet wat? Het tot een succes brengen van een softwareontwikkelingsproject vraagt een veelheid aan expertises en verantwoordelijkheden. Die zullen door zowel de leverancier als de opdrachtgever ingebracht moeten worden. Het is belangrijk dat de opdrachtgever vooraf helderheid geeft over de wenseljke verdeling: wat doet de opdrachtgever zelf en wat moet de leverancier doen? Daarbij is het essentieel dat de leverancier niet alleen verantwoordelijk gemaakt wordt voor het opleveren van een projectresultaat, maar dat ook afgesproken wordt welke rol de leverancier moet spelen bij het proces om tot dat resultaat te komen. Vaak zien we dat de leverancier de betekenis van bepaalde taken zeer conservatief stelt: ‘Vertel ons maar je wensen, dan schrijven wij dat gestructureerd op’. Terwijl de gebruikers verwachten dat de leverancier hen juist helpt bij het achterhalen van hun wensen. Met teleurstelling en extra kosten tot gevolg (meerwerk van de leverancier, of de opdrachtgever steekt er zelf meer tijd in). De enige manier om met zekerheid de juiste houding van de leverancier te krijgen, is door er expliciet om te vragen. Erik van Ginneken (ginneken@vka.nl) en Reinier Balt (balt@vka.nl) zijn respectievelijk als seniorconsultant en consultant werkzaam bij het onafhankelijke ICT adviesbureau Verdonck, Klooster & Associates te Zoetermeer.