Maatwerksoftware ontwikkelen: wat kost dat eigenlijk?

U overweegt maatwerksoftware te laten ontwikkelen voor uw organisatie. Bijvoorbeeld om knelpunten in uw levering aan te pakken of uw concurrenten voorbij te streven in gebruiksgemak. Maar hoe weet u wanneer de nieuwe software de investering waard is?

Michiel de Jongh, hoofd software-ontwikkeling bij OGD, vertelt u in deze blogpost dat het niet zoveel zin heeft vooraf een traditionele ROI-berekening te maken. Zijn advies: pak aan het begin van het ontwikkeltraject eerst de onbekende factoren aan. Alleen als u daarin succesvol bent, kunt u beginnen met het bouwen van een eenvoudige eerste versie (MVP). Zo komt u er snel en veilig achter wat uw nieuwe maatsoftware waard is.

Een ROI-berekening is geen goede indicator voor succes

In 1995 werd Windows 95 gelanceerd met een enorme hoeveelheid bombarie. Het werd de meest succesvolle software-release ooit: in het eerste jaar ging Windows 95 veertig miljoen keer over de toonbank. Daarentegen duurde het ontwikkeltraject veel langer dan gepland en heeft daardoor miljoenen meer gekost. Het kostte bovendien nog twee jaar aan ontwikkeling en updates voordat de grootste bugs eruit waren. De investering die Microsoft in het product heeft gestopt is daarmee vele malen groter dan geraamd.

Toch zal niemand zeggen dat de release van Windows 95 een mislukking was, ook al was de benodigde investering veel groter dan geraamd. Windows 95 maakte van Microsoft immers de marktleider in desktopbesturingssystemen. Welke ROI-berekening Microsoft vooraf ook misschien gemaakt had, die kon in de prullenbak. En dat strookt met onze ervaringen: een ROI-berekening schiet tekort bij het definiëren van succes van een ontwikkeltraject.

Elk ontwikkeltraject is uniek

Eigenlijk vertel ik u daar niks nieuws mee. Als u begint aan een ontwikkeltraject voor een nieuw maatwerksoftwareproduct, bestaat het product nog niet. Dus u zult altijd tegen problemen aanlopen waar u nog niet eerder mee te maken hebt gehad. Ook al heeft u een goed doortimmerde business case, dan nog weet u niet precies wat het product zal opleveren, want u hebt er nog nooit mee kunnen werken. Een beoogde ROI vaststellen (lees: verzinnen) levert dus alleen maar schijnzekerheid op.

Ook onze ontwikkelaars merkten dat ze er steeds weer tegenaan liepen dat elk software-ontwikkeltraject nou eenmaal onbekende factoren bevat die het heel moeilijk maken om aan het begin van het traject een nauwkeurige planning te maken. Al te precieze afspraken met een klant maken over hoeveel iets mag kosten en wat de klant daarvoor krijgt, voordat er ook maar een regel code is geschreven, is voor beide partijen dan ook ondoenlijk. Eerst moet er wederzijds vertrouwen zijn en een gezamenlijk ontwikkelde visie. Wij kiezen daarom voor een andere aanpak.

Tijdens de projectintake onbekende factoren in kaart brengen

Volgens ons is het veel beter eerst de onbekende factoren in een softwaretraject te erkennen. Samen met u brengen we die onbekende factoren in kaart en op basis daarvan richten we het ontwikkeltraject iteratief in, waarbij we ons richten op het bouwen van een MVP (minimum viable product). Nadat u het MVP in productie heeft genomen, ontdekt u door gebruikersfeedback welke features u belangrijk genoeg vindt om later toe te voegen aan de applicatie.

Dit proces begint bij de projectintake, waarbinnen we de onbekende factoren in het traject in kaart brengen voordat we gaan bouwen. Daarvoor gebruiken we het liefst een zogenaamde onzekerheidsmatrix. We kennen samen met u scores toe aan een aantal vaak voorkomende onbekende factoren. Zo bekijken we in hoeverre wij u en uw business snappen, en andersom, in hoeverre u onze aanpak en visie begrijpt. We bespreken ook hoe zeker en helder het doel is van het nieuwe softwareproduct en welke technische of organisatorische valkuilen nu al zijn te herkennen.

Kennis van uw business is cruciaal in het succes van het traject. Zeker als het gaat om een softwareproduct dat u weer aan zijn klanten gaat verkopen. Wat is het product straks waard voor uw klanten? Zo konden we voor Greenvis Energy Solutions de ideale pipe flow analysis-webapplicatie bouwen, omdat we ons hebben verdiept in wat de klanten van Greenvis willen: gebruiksgemak, snelheid en heldere rapportages.

Vóór het echte bouwen onbekende factoren aanpakken

Mochten we er tijdens het invullen van de onzekerheidsmatrix achter komen dat er teveel onbekende factoren bestaan om aan de slag te kunnen met het MVP, dan gaan we eerst de grootste onbekende factoren stap voor stap verkleinen. Dat doen we zo:

Het resultaat: tegen minimale investering de juiste oplossing ontwikkelen

Pas als we deze onbekende factoren hebben overwonnen, gaan we aan de slag met een MVP. Op deze manier ontwikkelen we gaandeweg samen met u een realistische visie op scope, planning en budget van het traject. Wij merken dat onze opdrachtgevers hier veel blijer van worden. We bieden ze niet vooraf een onhaalbare prognose, met alle wederzijdse frustraties van dien, maar gaan samen onderweg, met hetzelfde doel voor ogen: het beste product voor de beste prijs, zo snel mogelijk opgeleverd.

In een volgende blogpost vertel ik hoe u door snel en vaak te falen een beter softwareproduct zult krijgen. Wilt u weten wanneer deze volgende blogpost gepubliceerd is? Schrijf u dan in met het formuliertje rechts onderaan deze pagina.

maatsoftware-CtA

Nog geen reacties

Reageer als eerste

Ben jij al bekend met ITIL 4?

Kom vrijdag 19 april naar de ITIL 4 kennissessie en laat je meenemen op een tour langs alle verandering en mogelijkheden van ITIL 4.

> Meld je nu aan!

Maatwerksoftware ontwikkelen: wat kost dat eigenlijk?

Posted by Michiel de Jongh on 10-dec-2014 16:37:20

U overweegt maatwerksoftware te laten ontwikkelen voor uw organisatie. Bijvoorbeeld om knelpunten in uw levering aan te pakken of uw concurrenten voorbij te streven in gebruiksgemak. Maar hoe weet u wanneer de nieuwe software de investering waard is?

Michiel de Jongh, hoofd software-ontwikkeling bij OGD, vertelt u in deze blogpost dat het niet zoveel zin heeft vooraf een traditionele ROI-berekening te maken. Zijn advies: pak aan het begin van het ontwikkeltraject eerst de onbekende factoren aan. Alleen als u daarin succesvol bent, kunt u beginnen met het bouwen van een eenvoudige eerste versie (MVP). Zo komt u er snel en veilig achter wat uw nieuwe maatsoftware waard is.

Een ROI-berekening is geen goede indicator voor succes

In 1995 werd Windows 95 gelanceerd met een enorme hoeveelheid bombarie. Het werd de meest succesvolle software-release ooit: in het eerste jaar ging Windows 95 veertig miljoen keer over de toonbank. Daarentegen duurde het ontwikkeltraject veel langer dan gepland en heeft daardoor miljoenen meer gekost. Het kostte bovendien nog twee jaar aan ontwikkeling en updates voordat de grootste bugs eruit waren. De investering die Microsoft in het product heeft gestopt is daarmee vele malen groter dan geraamd.

Toch zal niemand zeggen dat de release van Windows 95 een mislukking was, ook al was de benodigde investering veel groter dan geraamd. Windows 95 maakte van Microsoft immers de marktleider in desktopbesturingssystemen. Welke ROI-berekening Microsoft vooraf ook misschien gemaakt had, die kon in de prullenbak. En dat strookt met onze ervaringen: een ROI-berekening schiet tekort bij het definiëren van succes van een ontwikkeltraject.

Elk ontwikkeltraject is uniek

Eigenlijk vertel ik u daar niks nieuws mee. Als u begint aan een ontwikkeltraject voor een nieuw maatwerksoftwareproduct, bestaat het product nog niet. Dus u zult altijd tegen problemen aanlopen waar u nog niet eerder mee te maken hebt gehad. Ook al heeft u een goed doortimmerde business case, dan nog weet u niet precies wat het product zal opleveren, want u hebt er nog nooit mee kunnen werken. Een beoogde ROI vaststellen (lees: verzinnen) levert dus alleen maar schijnzekerheid op.

Ook onze ontwikkelaars merkten dat ze er steeds weer tegenaan liepen dat elk software-ontwikkeltraject nou eenmaal onbekende factoren bevat die het heel moeilijk maken om aan het begin van het traject een nauwkeurige planning te maken. Al te precieze afspraken met een klant maken over hoeveel iets mag kosten en wat de klant daarvoor krijgt, voordat er ook maar een regel code is geschreven, is voor beide partijen dan ook ondoenlijk. Eerst moet er wederzijds vertrouwen zijn en een gezamenlijk ontwikkelde visie. Wij kiezen daarom voor een andere aanpak.

Tijdens de projectintake onbekende factoren in kaart brengen

Volgens ons is het veel beter eerst de onbekende factoren in een softwaretraject te erkennen. Samen met u brengen we die onbekende factoren in kaart en op basis daarvan richten we het ontwikkeltraject iteratief in, waarbij we ons richten op het bouwen van een MVP (minimum viable product). Nadat u het MVP in productie heeft genomen, ontdekt u door gebruikersfeedback welke features u belangrijk genoeg vindt om later toe te voegen aan de applicatie.

Dit proces begint bij de projectintake, waarbinnen we de onbekende factoren in het traject in kaart brengen voordat we gaan bouwen. Daarvoor gebruiken we het liefst een zogenaamde onzekerheidsmatrix. We kennen samen met u scores toe aan een aantal vaak voorkomende onbekende factoren. Zo bekijken we in hoeverre wij u en uw business snappen, en andersom, in hoeverre u onze aanpak en visie begrijpt. We bespreken ook hoe zeker en helder het doel is van het nieuwe softwareproduct en welke technische of organisatorische valkuilen nu al zijn te herkennen.

Kennis van uw business is cruciaal in het succes van het traject. Zeker als het gaat om een softwareproduct dat u weer aan zijn klanten gaat verkopen. Wat is het product straks waard voor uw klanten? Zo konden we voor Greenvis Energy Solutions de ideale pipe flow analysis-webapplicatie bouwen, omdat we ons hebben verdiept in wat de klanten van Greenvis willen: gebruiksgemak, snelheid en heldere rapportages.

Vóór het echte bouwen onbekende factoren aanpakken

Mochten we er tijdens het invullen van de onzekerheidsmatrix achter komen dat er teveel onbekende factoren bestaan om aan de slag te kunnen met het MVP, dan gaan we eerst de grootste onbekende factoren stap voor stap verkleinen. Dat doen we zo:

Het resultaat: tegen minimale investering de juiste oplossing ontwikkelen

Pas als we deze onbekende factoren hebben overwonnen, gaan we aan de slag met een MVP. Op deze manier ontwikkelen we gaandeweg samen met u een realistische visie op scope, planning en budget van het traject. Wij merken dat onze opdrachtgevers hier veel blijer van worden. We bieden ze niet vooraf een onhaalbare prognose, met alle wederzijdse frustraties van dien, maar gaan samen onderweg, met hetzelfde doel voor ogen: het beste product voor de beste prijs, zo snel mogelijk opgeleverd.

In een volgende blogpost vertel ik hoe u door snel en vaak te falen een beter softwareproduct zult krijgen. Wilt u weten wanneer deze volgende blogpost gepubliceerd is? Schrijf u dan in met het formuliertje rechts onderaan deze pagina.

maatsoftware-CtA

Topics: Software