Het is algemeen bekend dat veel softwarerealisatie projecten, die uitbesteed zijn aan een leverancier spaak lopen en minder rendement opleveren dan vooraf gedacht en gehoopt. Het is minder bekend dat de plank al misgeslagen wordt door keuzes bij de start van een project. In deze aflevering komt aan de orde waarom een prijs die gebaseerd is op een objectieve eenheid beter werkt dan een inspanningsverplichting.

Bij de meeste agile softwareprojecten wordt er gewerkt met zogenaamde ‘Time and Materials (T&M)’ contracten, waarbij de prijs gebaseerd is op de omvang en de kwaliteit van het ontwikkelteam van een leverancier. Agile teams bepalen zelf wat zij realistisch vinden in een sprint. Zij kunnen er dus ook voor kunnen zorgen dat er relatief weinig werk uit de product backlog in een sprint. De leverancier maakt zijn uren toch wel op het project. Het risico blijft op deze manier voor het grootste gedeelte bij de klant liggen. Zo’n situatie voorkom je als de beloning niet op inspanning gebaseerd is, maar gekoppeld is aan de productiviteit en de output van het ontwikkelteam.

Omvang bepalen lastig

Het is alleen lastig om de omvang van een softwareproject in te schatten. In het in een eerdere bloga al aangehaalde artikel ‘Towards a new IT model contract: changing the pricing method’ illustreren Charles Symons en Richard Stephens dit met een alledaags voorbeeld:

Meten is weten

Meten is weten, ook bij applicatieontwikkeling. METRI, een fact based IT adviesorganisatie gespecialiseerd in sourcing en benchmarking, is een samenwerking aangegaan met CAST, een vooraanstaande internationale leverancier van hulpmiddelen voor het doormeten van softwarecode. De samenwerking heeft tot doel organisaties te helpen op een kostenefficiënte manier inzicht te krijgen in de objectief vastgestelde omvang en kwaliteit van applicaties. Hiermee zijn de prestaties te meten van leveranciers die het onderhoud en beheer van applicaties uitvoeren ook vanuit de agile ontwikkelmethode. Op CIODay 2016 zal METRI volop aandacht besteden aan het adequaat sourcen van applicatieontwikkeling in het agile tijdperk. Kijk voor meer informatie op https://metrigroup.com/events/

“Stel dat je ongelode benzine (goed gespecificeerd) nodig hebt voor je auto en je ziet een benzinepomp die adverteert: ‘Vandaag benzine 1 EUR’. Dat klinkt niet slecht’, maar je hebt geen idee hoeveel benzine je krijgt. De volgende benzinepomp biedt benzine aan voor 20 EUR per minuut. Het probleem is nu dat je niet weet hoeveel benzine er per minuut uit de pomp komt.”

In de software-industrie zijn dit soort prijzen heel gewoon doordat er geen koppeling is tussen de prijs en de output ofwel de productiviteit van een ontwikkelteam. In juridisch bindende contracten gaan jaarlijks miljarden euro’s om, terwijl op klompen aan te voelen is dat deze prijs die gebaseerd is op inspanning afnemers niet de beste deal geeft. Maar heel weinig organisaties meten hoeveel software ze precies krijgen. Organisaties, die deze moeite wel nemen, doen dat vaak jammer genoeg op een minder relevante manier als het tellen van het aantal regels softwarecode.

Output meten

De enige internationale industriestandaard voor het meten van de output van software is ISO/IEC standaard voor functional size measurement, ofwel functiepunt analyse. Dat komt omdat functiepunt analyse een objectieve, herhaalbare, consistente en verifieerbare manier is voor het vaststellen van de hoeveelheid functionaliteit die door de gebruiker wordt gevraagd. Een functiepunt is gebaseerd op de onderliggende datastructuur en de transacties die nodig zijn om de functionaliteit mogelijk te maken. Weinig organisaties zijn op de hoogte van het feit dat functiepunten, die internationaal gestandaardiseerd zijn, een goede eenheid zijn om de output van softwareprojecten adequaat te meten.

Is functiepunt analyse, dat in de jaren tachtig van de vorige eeuw ontwikkeld is, nog relevant nu agile softwareontwikkeling de norm is geworden? Dat is de verkeerde vraag, want een standaard maat voor de omvang zegt niets over de te gebruiken techniek. De vierkante meter doet ook nog steeds zijn werk in de bouw, ook al worden muren tegenwoordig op een hele andere manier gemaakt dan enkele decennia geleden. Voor softwareontwikkeling is dit niet anders, omdat deze maat los van het programmeerplatform en methode aangeeft over hoeveel functionaliteit eindgebruikers kunnen beschikken. Leveranciers weten functiepunten heel adequaat de omvang van een nieuwbouw of onderhoud aan een applicatie weergeven. Ze willen alleen hun klanten niet wijzer maken. Inzicht in de uren per functiepunt biedt veel zicht op hun productiviteit en de kosten per functiepunt. Dit biedt mogelijk meer zicht op hun winstmarge dan hen lief is.

Risico’s

Als de prijs voor softwareontwikkeling gebaseerd is op een prijs per functiepunt in plaats van een gecombineerd uurtarief, dan worden de risico’s veel eerlijker verdeeld tussen leverancier en klant. De leverancier neemt risico door een prijs per functiepunt af te geven. De eigen productiviteit is vervolgens bepalend of deze leverancier de winstmarge op het project kan realiseren. Dit is een gezonde prikkel voor de leverancier die de beste mix van mensen moet vinden met een zo goed mogelijke balans in productiviteit en uurtarief. De opdrachtgever neemt het risico of de omvang van de op te leveren software goed ingeschat is en bewaakt de scope om budgetoverschrijdingen te voorkomen.

De kracht van dit inkopen op deze eenheden is dat alle wijzigingen die tijdens het project optreden ook tegen de prijs per functiepunt te realiseren zijn. De klant begrijpt de impact van een wijziging en betaalt de leverancier voor het extra programmeerwerk. Meer requirements en meer wijzigingen tijdens het project verhogen de kosten bij de opdrachtgever. Maar ook dat is niet meer dan fair. Na afloop wordt het totaal nog eens gemeten en mogelijk geverifieerd door een onafhankelijke expert. In de volgende blog komt voorbij hoe je productiviteit in een agile project het beste meet en inbrengt in een contract.