4 nadelen van een fixed price in IT-projecten

Webbureaus zijn voorzichtig met het afgeven van een fixed price. Dat is vervelend, want je wil natuurlijk duidelijkheid over de kosten. Toch is het hanteren van een vaste prijs niet altijd in je belang. Waarom? Dat leggen we je graag uit.

Geert
Geschreven door Geert
fixed price website app webapplicatie
fixed price website app webapplicatie

Wat is fixed price?

Fixed price (ook wel fixed fee of flat rate) is een uitgesproken vaste prijs voor een dienst of product. In de supermarkt vind je altijd vaste prijzen. Hier liggen producten die al zijn gemaakt, dat maakt het makkelijk een passende prijs te berekenen. Voor diensten is het vaak moeilijker een vaste prijs te hanteren, zeker wanneer het diensten binnen de IT-sector betreft.  Veel webbureaus hanteren een uurtarief en voorzien je van schattingen. Mogelijk zit je zelf in de oriëntatiefase voor een nieuwe website, app of applicatie en heb je vol goede moed offertes aangevraagd bij webbureaus. De kans is groot dat de begrotingen flink fluctueren en de prijzen niet vast of ‘fixed’ zijn. Dat is niet zonder reden.

Wanneer je een fixed price hanteert, ontstaan er meerdere nadelen die het ontwikkelproces (en daarmee het eindproduct) negatief beïnvloeden. Deze nadelen leg ik hieronder voor je uit.

1. Fixed price beperkt het ontwikkelproces

In de IT is alles mogelijk en zijn er ontelbare technieken beschikbaar om een digitaal product te bouwen. Dat maakt het moeilijk om vooraf een project compleet uit te denken. Er leiden honderden wegen naar Rome. Maar welke is het beste? Het snelste? Het meest toekomstbestendig? Welke combinaties aan wegen zorgen voor de beste reis? Deze vragen kun je niet allemaal beantwoorden zonder een aantal wegen te hebben bewandeld.

een wegennet
Development is als een wegennet, je kunt alle kanten op!

Wanneer developers beginnen met ontwikkelen, kunnen ze technieken testen en combineren. Zo weten ze of deze goed samenkomen in een uiteindelijke website, app of webapplicatie. Dit proces kan mee- of tegenvallen en laat zich dus niet compleet voorspellen. Dat betekent dat de kosten fluctueren en daar kom je pas achter wanneer je bent begonnen met het project. Dat gaat natuurlijk niet samen met een fixed price.

Ga je toch stellig voor een vaste prijs? Dan weet je waar je financieel aan toe bent, maar staat de tijd voor development vast. Een mogelijk gevolg is dat er niet genoeg tijd is om de beste keuzes te maken in het ontwikkelproces. Daarbij is je product onvoldoende doordacht en bouw je mogelijk op een zwak fundament. Het eindresultaat bevat waarschijnlijk meer bugs, is niet goed geoptimaliseerd en gaat minder lang mee. De kosten om dit recht te trekken vallen waarschijnlijk hoger uit dan wanneer je eerder was afgestapt van een fixed prijs.

2. Fixed price biedt geen flexibiliteit

Niet alleen techniek laat zich vooraf moeilijk uitdenken. Hoe gebruikers omgaan met je digitale product en welke functionaliteiten precies nodig zijn, kun je vooraf ook niet volledig vaststellen. Tijdens de ontwikkeling van een webapplicatie, website of app ontstaan er altijd nieuwe ideeën om de oplossing een extra impuls te geven. Vaak geven observatie en feedback directe inspiratie, maar je hebt ook altijd eureka-momenten waarbij je denkt: ‘Dit zou eigenlijk beter werken als…’. Het is zonde als je die optimalisatiekansen niet kunt benutten vanwege een fixed price. Een fixed price is immers gebaseerd op alles wat vooraf is bedacht.

Flexibiliteit gaat niet alleen om optimalisatie. Ook wanneer een vooraf bedachte functionaliteit in de praktijk niet goed werkt, heb je ruimte nodig voor het zoeken naar alternatieven. Dat kan alleen met een flexibel budget. Is er een vast budget? Dan zit je vast aan een zwakke functionaliteit waarvan je weet dat die niet deugt.

3. Afhankelijkheid van externe factoren

Een fixed price is moeilijk te hanteren wanneer je afhankelijk bent van externe factoren. Met name bij de ontwikkeling van webapplicaties, apps en complexe websites worden API-koppelingen gemaakt met externe systemen. Denk bijvoorbeeld aan de koppeling van een CRM-systeem als Exact met je bedrijfsapplicatie, of de koppeling van e-mailmarketing software als MailChimp met de nieuwsbriefinschrijving op je website.

Het maken van een koppeling is ook weer een proces dat mee- of tegenvalt. Je bent afhankelijk van de kwaliteit, flexibiliteit, bereikbaarheid en documentatie van het externe systeem. Je hoopt dat dit allemaal in orde is, maar in de praktijk liggen er vaak onverwachte drempels op de loer. Mogelijk is documentatie onvolledig, werken sommige functionaliteiten niet als verwacht of kan het systeem niet omgaan met je verzoeken. Het kost dan meer tijd om de koppeling te realiseren. Soms ben je ook afhankelijk van een actie van de externe partij voordat je verder kunt, wat de risico’s voor vertraging en nieuwe drempels verder verhoogt.

een systeemnetwerk

Kortom, externe factoren hebben een invloed die je vooraf niet precies kunt inschatten. Het plakken van een fixed price op deze werkzaamheden is daarom praktisch onmogelijk en een te groot risico voor een ontwikkelaar.

4. Een applicatie of website is nooit af

De oplevering van digitaal product betekent niet het einde van de rit. Er zijn altijd uitgangspunten voor optimalisatie op basis van analytische gegevens, observaties, feedback en nieuwe doelen.  Als je echt stappen wilt maken met je product, is doorontwikkeling daarom een logisch vervolg. Hierbij kun je simpelweg niet uitgaan van een eenmalige vaste prijs.

In moderne projecten gaat men steeds meer uit van roadmaps waarbij een product beetje bij beetje wordt uitgebouwd. Een bekende theorie die hierbij wordt gebruikt is de MoSCoW-methode. Hierbij ga je uit van vier soorten producteisen:

  • Must have.

    Essentiële elementen die het product moet hebben voor oplevering.

  • Should have.

    Belangrijke elementen die het product moet hebben, maar ook later toegevoegd kunnen worden.

  • Could have.

    Wenselijke elementen die het product kunnen verbeteren en later toegevoegd kunnen worden.

  • Won’t have.

    Elementen die mogelijk later interessant zijn, maar verder niet voorkomen in de planning.

Voor de oplevering van een product zijn de must haves essentieel, maar alle andere zaken kunnen later nog worden opgepakt. Het hanteren van deze methode helpt je om snel een MVP op de markt te brengen en deze daarna verder te optimaliseren. De afkorting MVP staat voor Minimum Viable Product en betekent kortweg: de allereerste versie van je product die je uitrolt naar je doelgroep. Deze bevat de minimale eisen waaraan het product moet voldoen.

Op basis van de analytische gegevens, observaties en feedback bepaal je welke should haves, could haves (en eventueel won’t haves) op elk later moment het meest relevant zijn om je product kosteneffectief te verbeteren.

Door een flexibele methodiek te hanteren, kun je het project bijsturen en altijd de meest logische vervolgstap nemen. Het uitspreken van een fixed price over deze werkzaamheden is moeilijk, aangezien het project op elk moment een andere richting kan opgaan.

Hoe bewaak ik mijn budget zonder fixed price?

Het afstappen van fixed price betekent niet dat je een IT-bedrijf een blanco cheque overhandigt. Veel IT-bedrijven hebben een vast uurtarief en hanteren een flexibele (Agile) werkwijze tijdens de ontwikkeling van hun producten. Dat komt vaak neer op het volgende:

In meerdere ontwikkelperiodes (sprints) van een 2-3 weken wordt je product cumulatief opgebouwd. Elke sprint bestaat uit een vast aantal uren en aan het einde van elke sprint wordt het project bijgestuurd op basis van de voortgang.

Deze werkwijze geeft je inzicht in de voortgang en de flexibiliteit om slimme keuzes te maken tijdens het ontwikkelproces. Doordat elke sprint hetzelfde aantal uren bevat, weet je welke kosten je maakt over een bepaalde periode. Hoeveel sprints je er nodig zijn om het product te laten voldoen aan je uiteindelijke eisen, is wel een vraag die je pas later kunt beantwoorden.

De Scrum-methodiek is een bekende Agile werkwijze. Scrum staat tegenover de traditionele Waterval-methodiek, die juist uitgaat van een werkwijze waarbij een project vooraf compleet wordt uitgedacht. Dit gaat vaak gepaard met een vaste prijs en een vaste tijdsindeling. In een Waterval-project is de kans op een mismatch tussen je wens en het eindproduct dan ook veel groter dan bij een moderne methodiek als Scrum.

fixed price nadelen: de waterval-methodiek tegenover de agile scrum-methodiek
De Waterval-methodiek met een vaste uitkomst tegenover Agile met een cumulatieve uitkomst.

Samenvattend beperkt een fixed price je dus enorm in je digitale mogelijkheden. Het denken in vaste prijzen is niet meer van deze tijd. Als webbureau dagen we onze opdrachtgevers dan ook graag uit om niet te vragen wat een product kost, maar wat het ze uiteindelijk zal opleveren!

Benieuwd welke non-fixed price we aan de ontwikkeling van jouw webapplicatie, website of app zouden hangen? We helpen je graag gratis en vrijblijvend.

Vragen?
Geert
Geert
Geert

Ik help je graag verder!

Mail geert@linku.nlOf bel 024 3000 316