Softwareontwikkelingsprojecten met vaste prijs: 3 belangrijke punten om te onthouden

Softwareontwikkelingsprojecten met vaste prijs: 3 belangrijke punten om te onthouden

Er zijn verschillende manieren om een software ontwikkelingsproject uit te voeren. Dit zijn voornamelijk:

1. Toegewijde ontwikkelaar: U krijgt een ontwikkelaar die alleen voor u en uw organisatie werkt. Meestal wordt een maandelijkse prijs overeengekomen tussen de dienstverlener en de klant. De ontwikkelaar gaat fulltime (circa 160 uur per maand) voor de opdrachtgever werken.
2. Mens-en-Materiaal/ Tijd-en-Materiaal/ Agile/ Ontwikkelteam: Hier wordt een project afgesproken, maar de uitvoering wordt gedaan door een multidisciplinair team van projectmanagers, scrum masters, business analisten, business developers, software/web developers, software testers, etc. Hierbij wordt vaak gebruik gemaakt van een Agile methodiek en na elke Spring (een ontwikkelcyclus die ongeveer een maand duurt) worden de ontwikkeltijden aangepast. Het is geen vaste prijs, maar een ruw budget op basis waarvan het zal worden ontwikkeld. Het kan een ruw cijfer zijn, maar het kan ook een veelvoud van dat budgetcijfer zijn. In grote organisaties heeft deze aanpak meestal de voorkeur.
3. Vaste prijs: Dit wordt meestal gebruikt in kleinere projecten, waar de prijs EN de eisen vastliggen. Dit artikel gaat over dit type project, en waar rekening mee moet worden gehouden bij het uitvoeren van een dergelijk project met een vaste prijs.

Invoering

Veel kleine tot middelgrote bedrijven hebben een budget voor het ondergaan van softwareprojecten. Vooral bij niet-IT-bedrijven is de kennis over softwareprojecten beperkt. Zij hebben het liefst een vaste prijs, waarbij de projectmanager binnen die bedrijven makkelijk gecommuniceerd kan worden naar de CEO of het management van het bedrijf.

Het zou nogal moeilijk zijn om te zeggen: “Het duurt ongeveer 2 tot 8 maanden om te ontwikkelen en elk uur kost 100 dollar. Het kan ook 14 maanden zijn”.

Als het IT-servicebedrijf tegen de klant zegt: “ Het duurt 4 maanden en een budget van 30.000 US Dollar ”, kan het team van de klant daar een besluit over nemen.

Het grote probleem daarmee is -> Dit is niet hoe een softwareproject werkt. De volgende zijn de redenen:

1. Eisen veranderen tijdens het project: Niemand weet, zelfs de klant niet, wat er allemaal in de software/weboplossing moet zitten om succesvol te zijn. Meestal wordt pas na enkele weken de eerste versie of de eerste webgebruikersinterfaces zichtbaar. Dat is meestal wanneer de klant erachter komt “Oeps, er is deze functionaliteit, die van het grootste belang is. Zonder deze functionaliteit zal het project geen succes zijn”. Maar de projectkosten en de projectuitvoering zijn al “vast” van beide kanten, de klant en het IT-servicebedrijf. Dit kan een showstopper zijn.
2. Niemand weet precies hoe lang het duurt om een functionaliteit te ontwikkelen: Ook al kan een softwareontwikkelaar bij benadering aangeven hoe lang het duurt om een functionaliteit te ontwikkelen. Hij of zij weet het niet precies. Dit geldt zelfs voor de meest ervaren ontwikkelaar. Daarom: hoe groter het project, hoe groter het risico dat de schatting niet klopt. Toch probeert het softwareontwikkelingsbedrijf, met een grotere buffer in de projectraming, dit risico op de een of andere manier te verkleinen.

Dit betekent dat de IT-dienstverlener al het risico loopt niet te weten of de inschatting van de ontwikkelaar correct was en dat de opdrachtgever bovendien om wijzigingen binnen het project zou kunnen vragen.

Dit is ook de reden waarom volgens het veel geciteerde Chaos Report een groot percentage (zo’n 40 tot 60 procent) van alle IT-projecten mislukt.

Want in een Fixed Price Project wil niemand toegeven. De klant wil geen Amerikaanse dollar meer betalen “omdat er een vaste prijs is overeengekomen”, en de IT-serviceprovider zal erop staan alleen te bouwen wat is overeengekomen “omdat de vereisten aan het begin van het project waren vastgesteld”.

Hier enkele punten om te onthouden om projecten met een vaste prijs te laten werken

1) De eisen staan vast (en pas na afronding van deze eisen worden nieuwe functionaliteiten toegevoegd)

De softwareontwikkeling hoeft niet te stoppen als de in eerste instantie overeengekomen functionaliteiten zijn ontwikkeld. Nadat het initiële project is afgerond, kan de volgende stap worden besproken en uitgevoerd.

Tip 1: De klant moet het volgende doen: Weersta de drang om nieuwe eisen te stellen aan het lopende project. Ook al heb je sterk het gevoel dat het project niet de moeite waard is voor je opdrachtgevers.

Het zal zwaar genoeg zijn om de initiële vereisten te laten werken. Voeg daar niet aan toe.

2) Beschikbaarheid van de klant tijdens de ontwikkelperiode

In een project met een vaste prijs wijst het IT-servicebedrijf (in kleinere projecten) één tot drie ontwikkelaars, een teamleider, een projectmanager en een ontwerper toe.

Als het project eenmaal is gestart, gaat het snel en mag er geen tijd worden verspild.

Vooral belangrijk: als het IT-team vragen heeft over een taak of feedback nodig heeft, moet deze zo snel mogelijk door de klant beschikbaar worden gesteld. Het ergste dat kan gebeuren, is als het ontwikkelteam 2 dagen moet wachten op feedback van klanten en gedurende die tijd inactief is.

Als het ontwikkelteam niets doet, wordt die tijd meestal afgetrokken van het Vaste Tijdsbudget en probeert het team de taken in de resterende tijd af te ronden. Wat meestal geen goed idee is, maar misschien wel de enige manier om vooruit te komen.

Om te profiteren van het ontwikkelteam en hun tijd, moet de klant daarom direct beschikbaar zijn voor vragen van de IT-serviceprovider.

Tip 2: De beste oplossing hiervoor zou zijn: De opdrachtgever zorgt voor een vast aanspreekpunt, dat gedurende de gehele ontwikkelperiode bereikbaar is tijdens ontwikkeluren. John Smith van de klant is bijvoorbeeld beschikbaar vanaf 01. tot 30 juli. Augustus. In deze tijd is John Smith beschikbaar via Skype of Slack Chat en kan hij de vragen van het ontwikkelteam beantwoorden.

3) Zorg voor inhoud op tijd

In sommige gevallen is de opdrachtgever verplicht om teksten, video’s, afbeeldingen en andersoortige inhoud of materiaal aan te leveren.

Deze vooraf overeengekomen inhoud dient op tijd aangeleverd te worden.

In sommige gevallen heeft het ontwikkelbedrijf voorlopig de mogelijkheid om dummy teksten of dummy content te gebruiken.

Maar voor een goede uitvoer is in sommige gevallen de inhoud nodig.

Tip 3: Zorg ervoor dat de inhoud (zoals teksten of afbeeldingen) gereed is als het ontwikkelteam daarom vraagt.

Opmerking: het kan ook te maken hebben met het geven van goedkeuring, het uitvoeren van een taak of met een projectdocument dat moet worden ondertekend.

4) Vermijd: “Maar dit was onderdeel van de vereiste” Argumenten (aanvullende belangrijke tip)

In werkelijkheid kunnen de eisen bij aanvang van het project nooit volledig worden begrepen of opgeschreven.

Het softwareontwikkelingsteam werkt meestal met enkele voorbeeld-URL’s die door de klanten worden verzonden, een of twee online vergaderingen en wat geschreven materiaal zoals e-mails of pdf’s.

Er is meestal een algemeen begrip van de belangrijkste functionaliteiten, maar niet het 100 procent duidelijke beeld.

Dit kan door beide worden gebruikt, het ontwikkelingsbedrijf om te zeggen “ Maar dit was geen onderdeel van de eis, dit kost extra ” of de klant om te zeggen “ Maar dit was onderdeel van de initiële vereiste, we willen dit zeker gratis en zonder extra kosten ”.

Tip 4: Er moet aan beide kanten algemene rechtvaardigheid zijn. De prijs-kwaliteitverhouding moet er zijn. Maar aan de andere kant moet het ook niet zo’n onhaalbare opgave zijn, zodat het ontwikkelbedrijf helemaal geen winst maakt op de projecten.

Opmerking: in het algemeen moet de klant (indien hij geen IT-expert is) vertrouwen op de ontwikkelingsprocedure die door het IT-bedrijf wordt voorgesteld.

Conclusie

De betere manier om softwareprojecten aan te pakken is met de toegewijde ontwikkelaar of toegewijde ontwikkelaar/Agile-aanpak. Maar dit is voor sommige bedrijven niet haalbaar vanwege budgetbeperkingen.

Daarom bieden veel IT-servicebedrijven de mogelijkheid voor projecten met een vaste prijs.

Voor de opdrachtgever is het belangrijk op te merken dat wanneer de prijs vaststaat, de eisen ook vastliggen. Vaak wordt Fixed Price verward met een “All-You-Can-Eat-Buffet”, waarbij je één keer betaalt en zoveel kunt eten (ontwikkelen) als je wilt. Integendeel, het is meer een “A-La-Carte” menu-optie, waarbij je de steak voor 5 US dollar bestelt, wil je daar friet bij, dan moet je 2 US dollar extra betalen.

Maar ook: Softwareontwikkeling en Maaltijdbereiding zijn anders. Want bij het maken van een steak is de input vrij duidelijk. Bij softwareontwikkeling is dit niet altijd het geval.

De tips in dit artikel helpen om projecten met een vaste prijs tot een succes te maken.

Interessante artikelen:

Hoe u projecten met een vaste prijs voor u kunt laten werken

Uitdagingen bij de ontwikkeling van software met een vaste prijs

Foto’s: Canvas

De auteur: Sascha Thattil werkt bij Software-Developer-India.com, een onderdeel van de YUHIRO Group. YUHIRO is een Duits-Indiase onderneming die programmeurs levert aan IT-bedrijven, agentschappen en IT-afdelingen.