Online gepubliceerde prijsbandbreedtes zijn zonder context vrijwel nutteloos. Wat telt zijn de variabelen die het bedrag bewegen — en hoe u een offerte leest zodat u bij elke leverancier hetzelfde vergelijkt.
Elk artikel over dit onderwerp drukt uiteindelijk een tabel met prijsbandbreedtes af. Die bandbreedtes zijn breed genoeg om voor vrijwel elk project waar te zijn, en juist daarom zeggen ze niets over het uwe. Een nuttiger vraag is welke variabelen het bedrag werkelijk bewegen, want zodra u die ziet, kunt u zowel verstandig plannen als een offerte kritisch lezen.
Wat de kosten werkelijk bepaalt
Het aantal afzonderlijke werkprocessen
Geen functies — werkprocessen. Een systeem waarin vijf rollen elk een andere route door dezelfde data volgen, is aanzienlijk meer werk dan een systeem waarin iedereen hetzelfde doet met meer opties. Elke rol vermenigvuldigt de rechtenlogica, de schermtoestanden en het testwerk. Tel bij het afbakenen de afzonderlijke routes in plaats van de schermen.
Koppelingen met systemen die u niet beheert
Dit is de post die in dit vak het meest consequent wordt onderschat. Koppelen aan een boekhoudpakket, een vervoerder of een betaaldienst is zelden de beloofde middag werk. De documentatie is onvolledig, de testomgeving gedraagt zich anders dan productie, snelheidslimieten duiken op onder echte belasting, en u moet gedeeltelijke storingen afhandelen zodat een time-out geen order dubbel aanmaakt. Reken op twee tot drie keer wat de koppeling lijkt te vragen.
Datamigratie
Moet bestaande data mee, dan bepaalt de kwaliteit ervan de kosten. Vijftien jaar aan records met inconsistente opmaak, dubbelingen en vrije tekstvelden waar een code werd verwacht, kost meer tijd om netjes te migreren dan het nieuwe systeem kost om te bouwen. Dit is het onderzoeken waard voordat iemand offreert, niet erna.
Hoe zeker de eisen zijn
Een vastgelegd proces met afgesproken regels is een rechttoe rechtaan inschatting. 'We herkennen het als we het zien' is geen inschatting, en elke vaste prijs die daaraan hangt bevat een forse reserve — die u betaalt, of die nu nodig blijkt of niet. Onzekerheid wegnemen vóór het offreren is de meest doeltreffende manier om kosten te verlagen.
Compliance en wettelijke eisen
Het verwerken van gezondheidsgegevens, betaalgegevens of gereguleerde financiële informatie voegt audittrails, encryptie-eisen, bewaartermijnen, toegangscontroles en vaak een externe beoordeling toe. Het is geen opslagpercentage; het is extra werk met een eigen doorlooptijd.
Waarom twee offertes voor één opdracht zo ver uiteenlopen
- Ze hebben anders afgebakend. De één nam datamigratie, training en drie maanden nazorg mee; de ander offreerde alleen de bouw. Dat verklaart de meeste grote verschillen.
- Ander leveringsmodel. Een offshoreteam tegen een lager dagtarief naast een lokaal team tegen een hoger tarief — de vergelijking die telt is de totale kosten inclusief aansturingslast, niet het tarief.
- De één offreert wat u vroeg en de ander wat u nodig heeft. Een hogere offerte weerspiegelt soms een leverancier die een eis heeft opgemerkt die u niet had genoemd.
- Andere reserve. Een vaste prijs draagt risico, en de leverancier beprijst dat risico. Een vage opdracht levert een grotere buffer op.
- De één wil winnen op prijs en terugverdienen op meerwerk. Dat komt vaak genoeg voor om op te letten: kijk wat het contract zegt over wijzigingen in de scope.
Prijsmodellen, en wat elk model met u doet
| Model | Werkt goed wanneer | Het risico dat u draagt |
|---|---|---|
| Vaste prijs | De scope is werkelijk goed omschreven | Wijzigen is duur; de leverancier kan kwaliteit inleveren om marge te beschermen |
| Nacalculatie | De scope gaat evolueren en u kunt wekelijks bijsturen | Kosten zijn open zonder actieve sturing |
| Vaste prijs per fase | De meeste zakelijke softwareprojecten | Vraagt discipline om de scope binnen een fase te houden |
| Toegewijd team | Doorlopende ontwikkeling over kwartalen | U stuurt het team feitelijk zelf aan, dus u moet die capaciteit hebben |
Vaste prijs per fase is de afspraak die wij het meest gebruiken, omdat die u een hard bedrag geeft voor een omschreven stuk werk en een echt beslismoment bij elke grens — inclusief de beslissing te stoppen. Eén vaste prijs voor een heel programma klinkt veiliger en is dat meestal niet: het dwingt beide partijen elke wijziging tegen een contract te onderhandelen in plaats van tegen het doel.
Hoe wij tot een bedrag komen
Wij publiceren geen prijslijst, omdat een bedrag dat tot stand komt voordat iemand uw eisen heeft gelezen een gok is in de kleren van een offerte. De volgorde die wij in plaats daarvan volgen, is aan het begin bewust traag:
- Wij halen de eisen op — wat het systeem moet doen, wie het gebruikt, met welke bestaande hulpmiddelen het moet samenwerken, en wat waar moet zijn wil de eerste oplevering de moeite waard zijn.
- Daaruit stellen wij de scope vast en leggen die schriftelijk vast, inclusief wat bewust buiten beschouwing blijft en wat naar een latere fase gaat. Overeenstemming over de uitsluitingen telt even zwaar als over het werk.
- Wij maken een eerste offerte tegen die vastgelegde scope, met de aannames erachter uitgeschreven, zodat u ziet waar het bedrag werkelijk van afhangt.
- Vervolgens lopen wij de eisen en de calculatie punt voor punt met u door. Daar zit de meeste beweging: de scope wordt bijgesneden, een eis blijkt harder of losser dan hij eerst las, en het bedrag beweegt mee.
- Zodra de scope vaststaat en er niets wezenlijks meer openstaat, bevestigen wij de definitieve projectkosten voor die fase en start het werk daartegen.
De kosten die men vergeet
Software is geen investering die daarna stil blijft staan. Begroot het doorlopende deel vanaf het begin, want het komt hoe dan ook.
- Hosting en diensten van derden — meestal bescheiden, maar maandelijks en blijvend.
- Beveiligingspatches en updates van afhankelijkheden. Niet-onderhouden afhankelijkheden worden kwetsbaarheden, en de achterstand stapelt op: een framework dat twee hoofdversies achterloopt is een project om bij te werken, geen taak.
- Wijzigingen naarmate het bedrijf verandert. Elk systeem dat echt wordt gebruikt genereert wijzigingsverzoeken, en dat is een teken van succes en geen fout in de afbakening.
- Ondersteuning voor de mensen die het gebruiken, vooral in de eerste maanden.
- Reken het doorlopende deel als een vaste regel in de begroting in plaats van als een incidentele verrassing. Hoeveel het wordt hangt af van hoe intensief het systeem wordt gebruikt en hoe snel het bedrijf eromheen verandert, dus het is de moeite waard het bij het afbakenen van de bouw af te spreken en niet na livegang.
Hoe u de kosten eerlijk verlaagt
- Snijd in de scope, niet in de kwaliteit. Een kleiner systeem dat goed is gebouwd wint het van een groot systeem dat goedkoop is gebouwd — dat tweede wordt onhoudbaar en wordt eerder vervangen.
- Bouw eerst één volledig werkproces en neem het echt in gebruik. U ontdekt welke van uw andere eisen aannames waren.
- Leg uw proces vast voordat u offertes vraagt. Leveranciers beprijzen onzekerheid, en u haalt die goedkoper weg dan zij.
- Gebruik bestaande producten voor standaardfuncties. Betalingen, e-mail, authenticatie en analytics zijn opgeloste problemen; betalen om ze na te bouwen is zelden te rechtvaardigen.
- Schoon uw data op vóór de migratie, met uw eigen mensen die de data begrijpen.
- Wees eerlijk over wat werkelijk nodig is voor de eerste oplevering. 'Fase twee' is een legitiem antwoord en meestal het juiste.
En wees op uw hoede bij de laagste offerte als die ver onder de andere ligt. Meestal wijst dat erop dat de leverancier de opdracht niet heeft begrepen, wat betekent dat het verschil later terugkomt als meerwerk — of als een systeem dat opnieuw gebouwd moet worden.
Dit is het soort werk dat wij doen. Is het van toepassing op iets dat u van plan bent, dan beschrijft onze pagina over maatwerksoftware hoe wij het aanpakken, of u kunt het project beschrijven en dan zeggen wij wat wij ervan denken.