De kern is goed opdrachtgeverschap

In dit artikel zal worden betoogd dat de werkelijke kwaliteit van softwareontwikkeling maar deels te maken heeft met de wijze van construeren, maar meer nog met de wijze van specificeren, expliciteren en aansturen. Het proces en de rollen dus. Er gaat nog steeds veel mis met softwareprojecten, zowel in tijd, in kosten als in kwaliteit. Terwijl er de laatste decennia enorm veel is gedaan aan de professionalisering van het vakgebied. Denk bijvoorbeeld aan nieuwe, snellere (agile) ontwikkelmethodieken die in specifieke situaties zeer succesvol zijn. Ook aan de hulpmiddelenkant zijn verbeteringen zichtbaar, zoals test-driven softwareontwikkeling en refactoringfunctionaliteit in de ontwikkelomgevingen (IDE’s). Dan blijft het onbegrijpelijk dat softwareprojecten uitlopen in tijd, veel meer kosten dan begroot, en niet of onvoldoende voldoen aan vooraf overeengekomen specificaties. Interne ICT-afdelingen die projecten laten uitlopen worden gedoogd, externe ICT-aanbieders die projecten laten ontsporen worden geaccepteerd, en opdrachtgevers die ICT-projecten laten glippen worden begrijpend aangekeken. ‘Ach, het gebeurt meestal zo, toch? Had je anders verwacht dan?’. Falen deze projecten dan omdat de software zo complex is of omdat ontwikkelmethodieken of -hulpmiddelen niet toereikend zijn? Onze stelling is dat meer projecten falen door gebrekkige afspraken en communicatie dan door gebrekkige constructie of een te complex domein. Succes draait met name om het goed invullen van de opdrachtgever/opdrachtnemerrelatie bij het uitvoeren van softwareontwikkelingsprojecten. Vak apart Het verstrekken van de opdracht tot het uitvoeren van een softwareproject is geen sinecure en niet elke manager is daartoe geëquipeerd. Het lijkt vaak zo eenvoudig: de organisatie heeft een bepaalde informatiebehoefte, softwarebouwers spoeden voorwaarts om mee te dingen naar de gunst van de potentiële opdrachtgever, en tijdens de definitiefase hoeft nog niet alles bekend te zijn, want dat wordt vanzelf duidelijk tijdens het project. In de praktijk is dit echter lang niet zo eenvoudig. Blijkbaar is IT-opdrachtgeverschap een vak apart, en is het erbij halen van expertise in bepaalde gevallen een must. In de opdrachtgever/opdrachtnemerrelatie zijn er twee partijen met in potentie afwijkende belangen. De opdrachtgever wil zijn (business)probleem zo goed mogelijk opgelost zien en de opdrachtnemer wil binnen de beperkingen van tijd en budget opleveren. Deze belangen kunnen overeenkomen, maar in de praktijk ziet men vaak dat de belangen strijdig zijn: de opdrachtgever heeft bepaalde verwachtingen ten aanzien van functionaliteit en kwaliteit, en verwacht van de opdrachtnemer flexibiliteit enerzijds en duidelijkheid over tijd en budget anderzijds. De opdrachtnemer daarentegen zal tijdens het commerciële traject scherp aanbieden om te kunnen winnen van de concurrentie. Wanneer het bestek niet duidelijk genoeg is, of ruimte laat voor eigen interpretatie, wordt de omvang vaak onderschat. Hierdoor start de opdrachtnemer met een te krap budget en heeft vanaf de aanvang niet scherp wat de precieze omvang van het project is. Het moge duidelijk zijn dat dergelijke projecten onder een slecht gesternte van start gaan. Hoe kan dit verbeteren? De kern is goed opdrachtgeverschap. In een eerder in Automatisering Gids verschenen artikel (8-8-2003, ‘Succes is een keuze’) zijn vier belangrijke keuzes beschreven die een opdrachtgever vooraf moet maken alvorens te starten met een project. ‘Welke ontwikkelaanpak wordt gehanteerd?’, ‘Hoe gaan we om met eisen?’, ‘Hoe gaan we om met de duivelsdriehoek?’ en ‘Wie doet wat?’. Deze vragen en, in het verlengde daarvan, keuzes zorgen voor een helder en transparant proces. Aan het stuur Daarnaast ziet men in de praktijk vaak onduidelijkheid over het doel van het project. Wat moet nu precies gebouwd worden? Als dit vooraf helder is, kan dit duidelijk beschreven worden in het programma van eisen (de functionele en niet-functionele eisen) voordat de bouw wordt aanbesteed. Als men zelf de mogelijkheden niet heeft om dit programma van eisen op te stellen kan men overwegen dit proces uit te besteden. Bovendien is van belang dat de opdrachtgever in dit proces aan het stuur zit, want de opdrachtnemer is al snel geneigd alle wensen van de gebruikers over te nemen in het programma van eisen (en is het doel dan nog realistisch en haalbaar?). Wanneer de opdrachtgever niet exact voor ogen heeft wat hij wil, kan een flexibel proces, waarin veranderingen mogelijk zijn, uitkomst bieden. Dit betekent dat ‘fixed-price/fixed-date’ niet de gewenste vorm is in die situatie. Er zijn ook andere mogelijkheden om op kosten te sturen. Zo kan men het project gefaseerd laten verlopen (definitiestudie, functioneel ontwerp/architectuur, proof-of-concept, bouw en pilot, uitrol et cetera) waarbij elke fase opnieuw (eventueel in concurrentie) kan worden aanbesteed. Ook kan men vooraf voor het gehele traject afspraken maken over uurtarief en projectcondities om de lock-in te voorkomen. Een ander belangrijk element is dat de opdrachtgever voldoende invulling geeft aan zijn opdrachtgeverschap zodat het mogelijk is om de opdrachtnemer goed te kunnen aansturen. Dat betekent bijvoorbeeld dat de opdrachtgever voldoende expertise georganiseerd moet hebben om volwaardig gesprekspartner te zijn van de opdrachtnemer. Dit geldt niet alleen bij het begin van de aanbesteding en aan het eind bij de overdracht, maar ook tijdens de uitvoering. De opdrachtgever zal bij voorkeur zowel de aanpak als de deliverables (inhoudelijk) willen toetsen; de opdrachtnemer moet opleveren wat de organisatie gevraagd heeft. Dit lijkt een open deur, maar vaak ziet men in de praktijk dat alleen op voortgang en escalaties wordt gestuurd. Nieuwe en verbeterde methodieken en hulpmiddelen voor softwareontwikkeling zullen de kwaliteit van software verhogen. Klantorganisaties kunnen echter ook zelf meehelpen aan verbetering van het proces van softwareontwikkeling, en dat begint bij de opdrachtgever. Dan krijgen softwareontwikkelingsprojecten een grotere kans op succes. Bestuurders van organisaties moeten ophouden met het accepteren, gedogen, goedpraten of beredeneren van softwareontwikkelingsprojecten die mislukken. Natuurlijk is de software complexer en fragieler geworden, de eenvoudige softwarepakketten zijn als eerste gebouwd. Maar softwareontwikkelingsprojecten moeten ook niet mystieker worden gemaakt dan ze zijn. Met goed opdrachtgeverschap, heldere doelen, transparante processen en realistische projecten die stevig worden aangestuurd is succes ook in de ICT binnen handbereik. AUTEUR: Danny Jolink en Reinier Balt Danny Jolink (danny.jolink@vka.nl) en Reinier Balt zijn als seniorconsultant werkzaam bij Verdonck, Klooster & Associates in Zoetermeer.