DDCgroup Logo

Fixed-price, waar vind je dat nog tegenwoordig

21 januari 2016

Wij bij Deep Blue halen onze motivatie uit tevreden klanten. En een klant is tevreden als aan zijn verwachtingen wordt voldaan, of deze worden overtroffen. Eén aspect van de verwachtingen is de prijs. Bij de beslissing om software te laten ontwikkelen, speelt de prijs vaak een rol:

  • Hoe verhoudt de prijs van maatwerk zich ten opzichte van andere (standaard) oplossingen;
  • Kan ik de investering rechtvaardigen (terugverdienen);
  • Welke leverancier biedt de beste prijs-kwaliteit verhouding.

Een potentiële klant zal dus voordat een project wordt gestart een indicatie van de kosten willen ontvangen. En het liefst weet hij precies waar hij aan toe is voordat de handtekening wordt gezet. Logisch, bij andere grote uitgaven is het niet anders (auto, huis). En toch kiezen steeds meer softwarebedrijven ervoor om geen fixed-price projecten uit te voeren. Nee: scrum en agile, dat is tegenwoordig de beste aanpak. Want flexibel. Vanwaar deze trend? En is de klant daar wel bij gebaat? Een korte analyse:

Gebaseerd op informatie van andere IT bedrijven, wordt de voorkeur gegeven aan scrum omdat fixed-price projecten te vaak op een teleurstelling uitliepen. Het is inderdaad lastig om vooraf een goede prijscalculatie te maken. En gezien de commerciële druk om een nieuwe klant binnen te halen, worden prijzen vaak te laag ingeschat (waardoor de klant eerder besluit om het project te starten). Als aan de genoemde prijs wordt vastgehouden, snijd de leverancier zich in de vingers. In de meeste fixed-price projecten zal de leverancier echter proberen om de extra kosten alsnog bij de klant te verhalen. Zie hier het ontstaan van het IT-project stigma (kost altijd meer tijd en geld dan vooraf verwacht)

Maar is de beste oplossing dan werkelijk om geen toezeggingen meer te doen, en het risico volledig bij de klant te leggen (Scrum)? Nee, natuurlijk niet: je kunt beter werken aan het verbeteren van de kostenraming. Maar dat is een ambacht dat maar door weinig techneuten wordt beheerst. Er is een tekort aan kennis en ervaring:

Kennis
Voor het maken van een goede kostenraming is brede kennis nodig van zowel de business kant (wat bedoelt de klant nou eigenlijk) als de technische kant (hoe kunnen we dat bouwen). Er zijn maar weinig mensen in Nederland die deze kennis combineren. Ondanks dat IT een steeds grotere rol speelt in het dagelijks leven, blijft het aantal aanmeldingen voor IT studies bedroevend laag. Het aantal inschrijvingen voor de studie Technische Informatica aan de TU Eindhoven (de grootste van de 3 Technische Universiteiten op dit gebied) bedroeg recent slechts 114. Dat is vrijwel hetzelfde aantal als 25 jaar geleden. En toen haalde slechts 34% de eindstreep van de opleiding. Een instroom van slechts enkele tientallen nieuwe talenten op de arbeidsmarkt dus. Veel te weinig!

Ervaring
Alleen kennis van software ontwikkeling is niet genoeg. Er is ervaring nodig om te weten hoeveel tijd het ontwerpen, bouwen en testen gaat kosten. Aspecten als projectmanagement, risico’s en het effect van de teamomvang moeten worden meegenomen. En er moet rekening worden gehouden met onvoorziene aspecten en de complexiteit van het project. Het opdoen van deze ervaring kost tijd. En alleen in projecten van voldoende omvang komen alle aspecten aan bod.

Er zijn dus maar weinig experts in Nederland die de benodigde kennis én ervaring hebben om echt goede kostenramingen te kunnen maken.
Software ontwikkelaars hebben de neiging om bij een calculatie de tijd die ze zelf nodig hebben als uitgangspunt te nemen. Tijd voor overleg met de klant, projectmanagement, intern overleg en documentatie worden vaak over het hoofd gezien. En inschattingen zijn doorgaans te positief, houden geen rekening met tegenvallers.
Sales consultants hebben dezelfde neiging: ze willen het project graag verkopen, en vertrouwen er daarom op dat de laagste kostenraming wel haalbaar zal zijn, dat verkoopt een stuk makkelijker, en daarna zien we wel.

Dat gaat natuurlijk fout!

Gelukkig zijn er nog softwarehuizen die wél beschikken over de juiste kennis en ervaring. Bij Deep Blue hebben alle consultants/projectmanagers en vrijwel alle ontwikkelaars Informatica gestudeerd. En onze projectmanagers hebben ieder ten minste 20 jaar ervaring met software ontwikkeling in projecten. Wij durven het wel aan: vrijwel alle projecten bieden wij fixed-price aan. Daarbij dient een degelijk functioneel ontwerp als uitgangspunt, zodat er vooraf duidelijkheid is over wat we gaan bouwen.

En die flexibiliteit dan? Die is er ook bij ons. Maar vaak is dat helemaal niet nodig. Liever goed nadenken over wat je wilt vóórdat je begint met bouwen.
Meer weten? Neem contact met ons op voor een vrijblijvend gesprek.
Terug

Gerelateerd nieuws

  • Mendix past prijsbeleid aan

    17 februari 2021
    In de afgelopen jaren is het gebruik van Rapid Application Development platforms als Mendix, Betty Blocks, Outsystems en Microsoft PowerApps steeds populairder geworden. Begrijpelijk, want met low-code/no-code ontwikkeling zijn vooral informatiesystemen enorm snel en flexibel te realiseren.Met de stijgende populariteit stegen bij veel aanbieders echter ook de prijzen. Voor een deel van de markt was deze oplossing daardoor minder interessant. Erg jammer. Mendix heeft besloten om hun pricing model drastisch te wijzigen. Daardoor is gebruik van Mendix nu ook erg interessant voor start-ups, MKB en juist ook heel grote toepassingen met erg veel incidentele gebruikers.Waar de vanaf-prijs voorheen zo’n € 20.000,- per jaar bedroeg, kan nu al voor enkele honderden euro’s per jaar van Mendix gebruik worden gemaakt. En waar voorheen stevige meerprijzen werden berekend voor extra user-packs, is uitbreiding nu veel flexibeler en vaak goedkoper. In sommige gevallen zal de totaalprijs niet enorm afwijken van het oude model, maar de instap wordt in veel gevallen veel aantrekkelijker en dat opent nieuwe mogelijkheden.Meer weten over Mendix en de mogelijkheden voor jouw bedrijf? Neem contact op met Maurice Gelden voor een vrijblijvend aanbod.
    Lees meer
  • Rapid Application Development versus coderen

    18 januari 2021
    Rapid Application Development (RAD) is here to stay. Juist bij het ontwikkelen van informatiesystemen bieden RAD tools als Mendix en Betty Blocks flinke voordelen: véél sneller bereik je het gewenste resultaat. En je behoudt flexibiliteit na oplevering. Dat wil echter niet zeggen dat RAD altijd te prefereren is boven ‘traditioneel’ coderen in talen als Java of .NET. Het is uiteraard belangrijk om bij aanvang van een project de juiste techniek te kiezen. We beschrijven hieronder enkele belangrijke aspecten die een rol spelen bij de keuze tussen RAD of coderen.Meer weten? Wij helpen je graag bij het maken van de juiste keuze. We hebben alle expertise in huis, en zijn daardoor in staat om werkelijk onafhankelijk te adviseren.FunctionaliteitOndanks de flexibiliteit van RAD tools zijn er altijd grenzen verbonden aan de mogelijkheden. Bij maatwerk ontwikkeling in Java of .NET bestaan die grenzen (vrijwel) niet: alles is mogelijk. RAD platforms bieden supersnelle resultaten bij het ontwikkelen van informatie systemen. Maar als de behoefte breder is dan dat (ingewikkelde logica, bijzondere visualisaties, specifieke koppelingen) dan is coderen toch vaak de betere oplossing.KostenDit aspect is wat complexer: RAD development kan erg snel gaan (factor 5 tot 10 keer sneller) waardoor de bouwkosten lager zijn dan bij maatwerk in .NET of Java. Echter: de uurtarieven voor RAD ontwikkeling liggen meestal hoger. En dat verschil is bij ons nog extra groot, omdat we voor maatwerk ontwikkeling in veel gevallen onze ontwikkelaars in Oost-Europa kunnen inzetten. Daar komt bij dat voor gebruik van het RAD platform jaarlijks licentiekosten dienen te worden betaald. Als die kosten worden meegewogen, is gebruik van een RAD platform toch al snel duurder dan op maat programmeren. Daarbij zijn immers in de meeste gevallen geen licentiekosten van toepassing.OnafhankelijkheidIndien gebruik wordt gemaakt van een RAD platform, zal de ontwikkelde software alleen nog op dat platform draaien. In dat geval is er dus een grote afhankelijkheid van de leverancier van dat platform. Indien wordt gekozen voor programmeren in Java of .NET bestaat die afhankelijkheid niet. Vandaar ook onze keuze voor bewezen en veel gebruikte programmeertalen: de kennis die nodig is om hierin te ontwikkelen is nu en in de toekomst gewaarborgd.Rechten en eigendomBij alle software die wij voor klanten ontwikkelen, wordt het intellectueel eigendom standaard overgedragen aan de klant. Dit maakt dat de klant na oplevering alle vrijheid heeft om bijvoorbeeld de software aan derden aan te bieden voor gebruik (licenties). Ook bij RAD applicaties ligt het IE bij de klant, maar dat betreft slechts de configuratie. De basis wordt gevormd door het RAD platform en daarvan wordt de klant nooit eigenaar. Dit maakt dat voor ontwikkeling van applicaties die je wilt gaan verkopen aan derden, programmeren vaak beter geschikt is dan gebruik van een RAD platform.
    Lees meer
  • Nationale Vrijwilligersdag

    7 december 2020
    Vandaag, 7 december, is het de Nationale Vrijwilligersdag. Een dag waarop mensen die zich het hele jaar door vrijwillig inzetten om anderen te helpen, zelf eens in het zonnetje worden gezet.Kenniscentrum Vrijwilligers is een organisatie die ondersteunt bij het effectief inzetten van vrijwilligers. Voor deze organisatie ontwikkelde DDC de vrijwilligerstool "Fenna". Hierin worden alle relevante gegevens over vrijwilligers bijgehouden. En Fenna helpt bij het selecteren van de best passende vrijwilliger voor een specifieke taak. Vrijwilligers hebben indien gewenst ook zelf toegang tot het systeem voor bijvoorbeeld het bijhouden van hun rooster of het indienen van declaraties.Fenna groeit erg hard de laatste tijd. Wekelijks sluiten nieuwe organisaties zich aan, tot inmiddels bijna 50 organisaties met al zo’n 10.000 vrijwilligers in het systeem.Meer weten over Fenna? www.vrijwilligersaanzet.nl
    Lees meer