Het lijkt wel of digitale platformen altijd duurder uitvallen dan vooraf begroot. Is dat zo? En is dat te voorkomen?
Zo bekeken vallen platformen dus in de categorie: Bouw. Alles wat je bouwt heeft het risico in zich om boven begroting te eindigen. Maar in vele gevallen is dit te voorkomen. Het hoe en waarom zal ik hieronder toelichten.
Allereerst is het belangrijk om je goed voor te bereiden. Dat is iets dat je zelf kunt doen maar it takes two to tango...dus ook het beoogde digitale bureau dat voor je aan de slag wil gaan speelt hierin een belangrijke rol. Zij zijn immers de experts op dit gebied en dienen je van goede informatie te voorzien.
Een aantal van de mogelijke valkuilen zal ik hieronder voor je op een rijtje zetten.
De scope wordt aangepast
Iedereen kent het wel je gaat naar de showroom toe en uiteindelijk ben je altijd meer kwijt. Niet omdat de verkoper persé allemaal truukjes uithaalt maar gewoon omdat je toch voor de opties gaat die tegen meerprijs leverbaar zijn. Dus bepaal vooraf wat je nodig hebt en wees standvastig op het moment van daadwerkelijk je keuze maken. Dit zien we ook vraag bij datagedreven of digitale platformen. Bij de inventarisatie wordt er ook gekeken naar alles wat er nog meer mogelijk is. De opdrachtgever komt in een euforie stemming omdat er digitaal alles gebouwd kan worden. Alleen alles heeft een prijskaartje. Mijn standpunt als digitale gangmaker? Hou de eerste oplevering klein. Ga kijken of het platform jou brengt wat je voor ogen had. En in de daaropvolgende opleveringen ga je -indien nodig- extra features toevoegen. En in tegenstelling tot auto's betaal je dan niet twee keer de prijs. Een robuust digitaal platform kan makkelijk van een handmatige naar een automatische koppeling tegen reële kosten. Voor de opdrachtgever ligt er wel een uitdaging bij de start. Durf te dromen maar houd tijdens de brainstorm voor ogen wat je doel is. En als dat een functioneel doel is (bijvoorbeeld een medewerkerstevredenheidsonderzoek) laat het dan ook functioneel zijn. Een spetterend en fancy voorkomen kan altijd nog als het zich bewezen heeft en je verder wil gaan in het boeien en binden van je personeel. Tijdens de designsprint is dit iets dat ik vaak verloren zie gaan. Zowel de projectleider (vanuit de opdrachtnemer) wordt door kennis en "denken in mogelijkheden" enthousiast en de deelnemers (van de opdrachtgever) gaan op in dagdromen en het platform is al duurder geworden voordat het zelfs begonnen is. Laat staan dat er tijdens de bouw nog features toegevoegd worden. Zoals je begrijpt was er weliswaar een scope maar die is al een aantal keren aangepast voor de eerste oplevering. Met als gevolg oplopende kosten en een duurder platform.
Hoe kun je dit voorkomen? Een beproefde methode is de MOSCOW-methode. Dit is de afkorting voor M - must haves, S - should haves, C - could haves en W - won't haves. Kortom prioriteiten tijdens de software-bouw en vasthouden aan deze uitgangspunten. En als laatste in de tussentijdse opleveringen (Agile/scrum) de belangrijkste uitgangspunten naar elkaar blijven herhalen: Scope, Tijdslijn, Features en Budget.
Risico's liggen aan een zijde binnen het project
In de basis zijn er twee soorten van aanrekening van de inspanningen die een digitaal bureau maakt. Als eerste op uurbasis. Alle activiteiten worden doorberekend aan de opdrachtgever op basis van de daadwerkelijk gemaakte uren. De tweede variant gaat uit van een vaste prijs (soms per onderdeel). Daarin worden de onderdelen gemaakt tegen een vooraf vastgestelde prijs. In de eerste situatie ben je flexibeler om zaken aan te passen tijdens het project. Je betaalt immers de extra uren. Bij een vaste prijs is die flexibiliteit er alleen als je de meerkosten goedkeurt.
De risico's liggen in beide varianten erg uit elkaar. Per uur wordt dan al snel "u vraagt- wij draaien". En in de vaste prijs is er maar een weg naar voren en die wordt hoofdzakelijk bepaald door de aannemende partij. Belangrijk is wel om te vermelden dat in de vaste prijs er veelal een opslagpercentage zit voor "onvoorziene zaken". In voorkomende gevallen kan dit oplopen tot 25%.
Omdat we bij DAAT niet geloven in deze twee uitersten zie je dat wij veelal kiezen voor een degelijke intake (in de vorm van een designsprint) aan de voorzijde. Daarbij bepalen we gezamenlijk de scope en verankeren deze in een offerte met uren en werkzaamheden uitgesplitst per onderdeel. Loopt een onderdeel in uren uit de pas en dit is ons aan te rekenen? Dan zien jullie die extra uren niet terug op een rekening. Wij zijn immers de experts.
De complexiteit is niet inzichtelijk gemaakt
Data is niet eenvoudig en het bouwen van een platform dat deze data verrijkt tot informatie met externe koppelingen en daaraan gekoppelde privacy al helemaal niet. Lichtvoetig een prijs afgeven voor de bouw is dan ook een fout die we in onze beginjaren maakten maar inmiddels achter ons hebben gelaten. We doen een gedegen intake en gaan in een gestructureerd proces niet alleen door de wensen en eisen van de opdrachtgever heen. Maar we kijken ook naar de allesomvattende vraag: "Maar hoe gaan we dit dan bouwen?" Dat geeft veel duidelijkheid in de eventuele complexiteit maar ook in het voorkomen daarvan. Er zijn meerdere oplossingen voor hetzelfde vraagstuk en met een beetje meedenken en flexibiliteit komen we regelmatig op betere of goedkopere oplossingen. Door het weghalen van deze onzichtbare complexiteit kunnen we beter, goedkoper en transparant bouwen zonder dat we risico's moeten incalculeren in de offerte.
Oplopende kosten na oplevering
Na oplevering van jouw digitale platform moet er nog steeds hosting plaatsvinden. Al dan niet gekoppeld aan onderhoudscontracten en andere additionele kosten. In veel gevallen zijn deze echter niet te voorkomen. Wat je niet wil is dat deze kosten echter om de verkeerde redenen oplopen. De oorsprong van deze oplopende kosten is vaak een "vendor-lockin". Anders gezegd: Je hebt de nieuwe auto gekocht bij een dealer en het onderhoud moet daar plaatsvinden omdat anders de fabrieksgarantie vervalt. Tja dat worden niet de goedkoopste onderhoudsbeurten.
Hoe kun je dit voorkomen? Allereerst door af te spreken bij wie het eigendom van het platform ligt. Dit noemen we het Intellectual Property (IP). Als het platform voor jou gemaakt is dan hoor jij ook de eigenaar te zijn. Als het standaard-software is dan ligt het bij de software-leverancier. Daarin zijn nog wel wat nuances maar als je de eigenaar bent, dan ben je ook vrij om je platform op te pakken en elders te plaatsen zodat je onterechte additionele kosten voorkomt.
Het tweede wat je wil afspreken is dat je voor de hosting en het daadwerkelijke gebruik aangerekend wordt. Ook hiervoor geldt dat dit niet veel anders is dan een huurhuis. Je betaalt voor de huur en als je veel energie verbruikt betaal je meer. Bij een gehoste applicatie hoort dit net zo geregeld te zijn. Als je bijvoorbeeld een outboundmarketing actie hebt, die vraagt om het tijdelijk opschalen van resources (CPU, RAM etc.) dan wil je alleen maar belast voor de tijd dat je het gebruikt hebt. Heroku en Azure zijn twee partijen die hun resources op die manier (automatisch) op- en afschalen. Het is dan ook redelijk om dit ook op die manier van je leverancier doorberekend te krijgen.
Doorontwikkeling en refactoring
Na de oplevering breekt er een tijd aan dat je gaat werken met de geboden oplossing. Al snel zie je wat mogelijke verbeteringen en er ontstaan nieuwe wensen. Belangrijk is wel dat je allereerst blijft kijken naar het van tevoren bepaalde doel. Dus wat moest het oplossen? Wanneer dient het platform het doel? Laat ik het anders zeggen: het kan nog zo'n mooi platform zijn maar als het niet de verhoogde omzet brengt of de verlaagde uitval realiseert dan schiet het platform het doel voorbij. Dus gebruik de tijd om dit uit te vinden. En als het voldoet aan je verwachtingen dan kun je gaan denken aan de doorontwikkeling. Belangrijk is wel om dus niet alleen de bouw van het platform te budgetteren maar ook om in het jaar van "release" de doorontwikkeling in te schatten.
Als laatste wil ik "refactoring" bij je onder de aandacht brengen. Dit is het gegeven dat je na verloop van tijd of na het toevoegen van een aantal features en veranderingen de onderliggende software opnieuw moet aanlijnen. Dit noemen ze refactoring. Op hoofdlijnen is dit vooraf in te schatten maar het betekent dat je niet alleen maar nieuwe functionaliteit kunt toevoegen zonder dat je ook de oude software aanpast. Inmiddels is low-code software zo volwassen geworden dat binnen de toolset dit grotendeels al opgelost wordt. Maatwerksoftware echter heeft dit nog wel als uitdaging in het doorbouwen op een eerder opgeleverd platform.
En nu?
Het belangrijkste is dat je vooraf afspraken moet maken met de beoogde leverancier. Reeël kijken naar je eigen verwachtingen en insteek in dit avontuur is daarbij een eerste vereiste.
Minimaal maak je vooraf bespreekbaar:
bepalen scope en intake (desingsprint)
inzicht in risico's en complexiteit
afspraken over oplevering en doorontwikkeling