Hoe een schatting van de softwarekosten te beoordelen (voor niet-technische personen)

Hoe een schatting van de softwarekosten te beoordelen (voor niet-technische personen)

Het is best moeilijk om een softwareproject te evalueren en er een prijskaartje aan te hangen.

In het artikel enkele uitdagingen en hoe u schattingen van softwarekosten kunt beoordelen.

Invoering

Volgens het chaosrapport, dat vaak wordt aangehaald, mislukt ongeveer 30 procent van alle softwareprojecten. Dat betekent dat ofwel de projectduur te lang wordt ofwel het budget niet wordt gehaald.

Hier enkele uitdagingen in softwareprojecten:

1) Moeilijk om de exacte vereisten te controleren

Als u een groot huis op maat wilt bouwen, kan er alleen een prijs worden vastgesteld als elk onderdeel van het werk goed wordt beoordeeld. Tot de laatste schroef, die zal worden gebruikt.

De architect zal een plan maken met een exact plan, waarbij het hele huis wordt gerepliceerd op papier of tegenwoordig vaak als 3D-model. En in deze programma’s kan worden berekend hoeveel schroeven, enz. nodig zijn om het huis te bouwen.

Met deze informatie is het mogelijk om een exacte schatting te geven voor het woningbouwproject.

Maar we weten ook: bij zeer grote bouwprojecten kloppen de prijsopgaven meestal niet. En wat 500 miljoen euro moest kosten, zal uiteindelijk 5 miljard euro of meer kosten. De luchthaven van Berlijn, de Elbphilharmonie in Hamburg en het centraal station in Stuttgart, Duitsland zijn drie voorbeelden, in de meeste gevallen waren de kosten een miljard euro of meer.

In het geval van het centraal station in Stuttgart bedroeg de vergoeding voor de architect ongeveer 36 miljoen euro. Ook al kreeg de architect zo’n hoog bedrag betaald. De raming van de projectkosten was ongeveer 1 miljard euro lager.

Soortgelijke uitdagingen zijn te zien in softwareprojecten.

Zeker als niet-technische mensen betrokken zijn bij het doorgeven van de eisen aan het software- of webproject. Gewoonlijk zullen de projectbeschrijvingen slechts een paar regels in een e-mail bevatten. Of een telefoontje waarin de gewenste oplossing wordt geschetst.

Ter referentie worden enkele voorbeeldwebsites gegeven. Niet zelden zijn deze voorbeeldwebsites gedurende vele jaren gebouwd en hebben ze honderdduizenden euro’s gekost, soms miljoenen.

Maar het budget voor de webapplicatie of softwareoplossing zal rond de 4.000 tot 40.000 euro liggen en het zou binnen 2 maanden, maximaal 3 maanden, gebouwd moeten zijn. (Dat is meestal de wens van de niet-IT-er die naar de prijs vraagt).

De realiteit is dit: zonder een gedetailleerd aanvraagdocument van de klant, dat ongeveer 10 tot 50 pagina’s zal zijn en een gedetailleerd voorstel dat door het IT-bedrijf is gemaakt op basis van dat gevraagde document, kan er geen prijs voor het project worden bepaald.

En zelfs als er een exact voorsteldocument is. Doorgaans veranderen de vereisten tijdens het project, waardoor deze oefening van het maken van voorstellen, die weken kan duren, een onnodige taak is.

2) Veranderende eisen tijdens het project

Er is bijna geen IT-project waarbij het aanvankelijk geciteerde softwareproject gedurende het project hetzelfde blijft.

De reden is, dat pas als de software vorm begint te krijgen, de opdrachtgever inziet dat er een aantal belangrijke dingen ontbreken, zonder welke het project geen succes kan worden en de software de bedrijfsprocessen niet zou helpen.

Maar wat als er een vaste prijs is afgesproken? Hoe kan de IT-dienstverlener wijzigingen toestaan tijdens het project. Dat kan bijna niet, want dan maakt de IT-dienstverlener helemaal geen winst.

Aan de andere kant zal de klant aandringen op de vaste prijs en zeggen: “Voor deze kleine wijziging is het niet nodig om het budget te wijzigen. Dit kleine wijzigingsverzoek kunt u in de eerste offerte plaatsen”.

En hier begint meestal het dilemma. Deze discussie over wijzigingsverzoeken gaat maar door. En het project loopt vast.

Het is dus altijd beter om het projectbudget vloeibaar te houden. Waarbij de klant zoveel betaalt als de softwareontwikkeling vereist. -> Natuurlijk kan dit voor de klant “een hemel voor het softwarebedrijf” lijken, omdat hij/zij zal denken dat ze meer uren zullen maken dan nodig is.

Maar vergelijk het met een restaurant. Als je een extra coca cola of een extra steak bestelt, moet je ook voor dat extra ding betalen. Waarom zou dat bij softwareontwikkeling anders zijn? Zeker in de IT waar de uurtarieven doorgaans veel hoger liggen.

3) Moeite om de complexiteit van softwareontwikkeling door de niet-IT-persoon te begrijpen

Het is meestal erg moeilijk te begrijpen voor een niet-IT-persoon om de complexiteit van softwareontwikkeling te begrijpen.

“Mijn vriend heeft deze ene website in één dag gebouwd en heeft veel functies. Waarom heb je als expert meer dan 6 maanden nodig om deze functies te ontwikkelen?”

Hoogstwaarschijnlijk gebruikte de vriend een Content Management System zoals WordPress of Drupal en gebruikte hij enkele standaard plug-ins, die meestal veel functionaliteiten bieden. Maar dit zijn geen op maat gemaakte softwareoplossingen voor de vriend. Dat zijn systemen en plug-ins die gewoonlijk door duizenden en honderdduizenden mensen worden gebruikt, met vergelijkbare vereisten. Dat zijn geen op maat gemaakte oplossingen.

Maar: voor het bouwen van deze plug-ins waren waarschijnlijk ongeveer 2 tot 5 of meer ontwikkelaars fulltime nodig voor enkele maanden of zelfs jaren. Dus ook al gebruikt de vriend schijnbaar eenvoudige oplossingen. Ze zijn gemaakt in een zeer complexe softwareontwikkeling.

Dus voor het geval de klant een eis heeft waaraan kan worden voldaan door die plug-ins en “kant-en-klare oplossingen”. Dan kun je ze beter gebruiken. Maar in de meeste gevallen zijn deze “kant-en-klare” softwaresystemen niet wat de klant nodig heeft.

Het beste voorbeeld is de Google-zoekmachine. Aan de voorkant (wat de gebruiker ziet) is er alleen een zoekbalk en twee knoppen. Dus een niet-IT-persoon zou zeggen: “het zou maar een week kunnen duren om dit te ontwikkelen. Er is alleen een zoekbalk en twee knoppen”. In werkelijkheid zijn er veel “verborgen” backend-functionaliteiten, die door duizenden en duizenden ontwikkelaars zijn ontwikkeld en dat gedurende vele jaren.

Afhankelijk van de complexiteit, schaalbaarheidsbehoeften, enz. van het klantproject, kan de softwareontwikkeling meer tijd in beslag nemen dan verwacht.

Mogelijke oplossingen

Er zijn enkele oplossingen hoe een niet-IT-persoon het verzoek aan de IT-serviceprovider zou kunnen benaderen.

1) Schakel een softwareontwikkelaar in

Idealiter zou er een interne softwareontwikkelaar of IT-expert zijn, die de schatting door het IT-servicebedrijf zou kunnen controleren.

Meestal zal die softwareontwikkelaar adviseren om de projectomvang flexibel te houden, zodat veranderingen kunnen worden opgevangen.

Als de inschatting van het softwarebedrijf aannemelijk is, geeft de softwareontwikkelaar groen licht.

Op die manier zal, als een interne medewerker het project beoordeelt, ook de niet-IT’er overtuigd zijn van de inspanningen voor de ontwikkeling.

2) Gebruik van toegewijde ontwikkelaar

Een toegewijde ontwikkelaar is een ontwikkelaar die fulltime aan de klant wordt geleverd.

Het voordeel hiervan is, dat de ontwikkelaar nauw samenwerkt met de opdrachtgever en ook met het team van de opdrachtgever. Dit vergroot de transparantie. En de klant of het team kan vragen stellen en realtime antwoorden krijgen.

Dit model werkt op verschillende manieren:

• Ter plekke: Het IT-servicebedrijf vraagt de ontwikkelaar om naar de locatie van de klant te gaan en op de locatie van de klant te werken.
• IT-outsourcing: Bij het IT-servicebedrijf werkt een team van ontwikkelaars.
• Nearshore-outsourcing: De toegewijde ontwikkelaar werkt bij een IT-dienstverlener in een nabijgelegen land. Voor Zweden zou dat Polen of Oekraïne zijn. Voor Japan zou dat Maleisië of China zijn.
• Offshore outsourcing: Hier zit de ontwikkelaar in het pand van een softwarebedrijf in een ver land. Voorbeelden zijn India, Pakistan, enz. Maar de woorden Nearshore of Offshore kunnen door elkaar worden gebruikt. Het hangt ervan af waar de klant zich bevindt. Als de klant zich in Japan bevindt, is India een bestemming voor Nearshore Outsourcing.

De klant kan de toegewijde ontwikkelaar gebruiken zolang hij/zij wil. Tot het project klaar is. Als het project te lang duurt. De klant en het team kunnen met de ontwikkelaar bespreken welke kant het op moet om de doelen sneller te bereiken.

3) Vermijd rigide projecten met een vaste prijs

Een vaste prijs is meestal geen goed idee. Alleen als het project erg klein is. Zoals een website van één pagina of iets dergelijks.

Vaste prijzen kunnen leiden tot een valse hoop dat alles binnen die prijs wordt gedaan. (Zelfs All-You-Can-Eat werkt niet zo. Je kunt zoveel eten als je wilt, maar slechts voor één maaltijd. Niet voor dagen achter elkaar. Maar dat is wat klanten verwachten, als ze een vaste prijs krijgen in software ontwikkeling)

Het is beter om te gaan voor een agile prijsstelling, waarbij de tijd en moeite van de softwareleverancier wordt vergoed, afhankelijk van hoeveel moeite er in de ontwikkeling wordt gestoken.

Of gebruik een toegewijde ontwikkelaar of een team van toegewijde softwareprofessionals om aan uw project te werken.

Conclusie

Veel softwareprojecten mislukken gewoon, omdat men niet begrijpt wat maatwerk softwareontwikkeling inhoudt. Schijnbaar eenvoudige projecten kunnen weken en maanden duren.

Daarom moet er een beoordeling door de klant worden gemaakt. Wat is het kostenbereik voor de softwareontwikkeling en wat is de bedrijfswaarde die daardoor wordt gecreëerd. Is de gecreëerde bedrijfswaarde veel hoger dan het budget dat nodig is voor de softwareontwikkeling? Goed, dan is het goed om te gaan. Start het project.

Als de gecreëerde bedrijfswaarde en de kosten niet overeenkomen. Dan is het misschien beter om gebruik te blijven maken van handmatige oplossingen, Excel-bestanden of standaard software of weboplossingen, waarop u zich kunt abonneren, tegen een laag maandbedrag.

Op naar een interessante discussie.

Interessante links:
Waarom schattingen misschien geen goed idee zijn?
De mythe van softwareschattingen uitgelegd

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.