De belangrijkste keuzes in een maatwerktraject vallen voordat er een regel code staat. Of je nu een webapp laat bouwen, een klantportaal of een interne tool: die keuzes zitten in de vragen die vooraf wel of niet op tafel komen. Wat moet dit opleveren, wie gaat ermee werken, wat gebeurt er na de oplevering. In ruim tien jaar intakegesprekken over software op maat zien we steeds hetzelfde: de trajecten die goed aflopen, hadden de lastige vragen aan het begin, niet halverwege.
Daarom hieronder geen algemeen projectmanagementadvies, maar de vragen zoals ze bij ons aan tafel klinken. Eerst de vragen die wij aan jou zouden stellen, dan de vragen die jij aan elke ontwikkelpartner mag stellen, en tot slot wat je zelf regelt voordat het traject begint. Waarom trajecten stranden, beschreven we al in vijf redenen waarom webapplicaties falen; dit artikel gaat over de vragen die dat voorkomen.
Het doel gaat voor de functionaliteit
De meeste aanvragen die we krijgen zijn al een oplossing: een portaal met inlog, een koppeling tussen twee pakketten, een dashboard voor het management. “We willen een webapp” is een wens, geen briefing. Begrijpelijk, maar de eerste intakevraag negeert die lijst bewust. Wat moet er in je organisatie makkelijker worden? Welk werk blijft liggen, waar ontstaan fouten, welke beslissing duurt te lang omdat de informatie ontbreekt?
Het antwoord bepaalt wat er ontwikkeld moet worden, en soms is dat minder dan gevraagd. Een deel van de wensenlijst blijkt in bestaande software te passen, of vervalt zodra het onderliggende proces is versimpeld. Functionaliteiten die geen van de kernpunten raken, kunnen naar de reservebank. Twijfel je of maatwerk voor je situatie de juiste route is, lees dan eerst hoe maatwerk zich verhoudt tot standaardsoftware.
De vragen die wij bij een intake stellen
Elke organisatie is anders, maar deze vragen komen in vrijwel elk eerste gesprek terug:
- Welk proces kost je mensen nu de meeste tijd, en hoe verloopt het vandaag, stap voor stap?
- Wie gaat er straks dagelijks mee werken, en wie bepaalt of het geslaagd is?
- Met welke systemen moet de software gegevens uitwisselen, en wie beheert die systemen?
- Wat gebeurt er als je een jaar lang niets verandert?
- Wie onderhoudt de software na de oplevering: je eigen team of je ontwikkelpartner?
De antwoorden sturen keuzes die later moeilijk terug te draaien zijn. Het aantal koppelingen zegt meer over de complexiteit dan het aantal schermen. De minst technische gebruiker bepaalt hoe eenvoudig de interface moet zijn. En de vraag wat er gebeurt als je niets verandert, maakt zichtbaar wat het vraagstuk je nu al kost.
Op de eerste vraag is het antwoord vaak minder scherp dan je denkt. Een uur meekijken met een planner of een binnendienstmedewerker levert meer op dan een vergaderuur over functionaliteiten: je ziet waar het werk wringt, welke stappen een applicatie kan overnemen en welke omwegen niemand ooit heeft opgeschreven. Doe dat voordat je met ontwikkelpartners om tafel gaat, dan begint het gesprek bij de praktijk in plaats van bij aannames.
Wat je aan een ontwikkelpartner terugvraagt
Een goede intake werkt twee kanten op. Eerder werk zegt iets: bekijk cases en let op projecten die op jouw situatie lijken. Het eerste gesprek zegt meer. Een partner die doorvraagt, begint over je proces en je doelen, niet over zijn eigen technologie, en vertaalt elke technische keuze naar wat die jou oplevert. Met een paar vragen ontdek je of je met een partner of met een leverancier aan tafel zit:
- Van wie is de broncode na oplevering, en wie kan de applicatie later onderhouden?
- Hoe zie je tussentijds wat af is en wat nog niet?
- Hoe worden wijzigingen tijdens het traject besproken en geprijsd?
- Hoe snel staat er een eerste werkende versie, en wat kun je daar al mee?
- Wat kost onderhoud per jaar, en wat krijg je daarvoor?
Vooral die eerste vraag wordt te weinig gesteld; hoe je daarmee vendor lock-in voorkomt is een artikel op zich. Let ook op wat er niet gevraagd wordt. Een partij die na het aanhoren van je wensenlijst meteen begint te rekenen, heeft de belangrijkste stap overgeslagen: begrijpen waarom je die wensen hebt.
Houd je begroting eerlijk
Wat software op maat kost, hangt af van de omvang, het aantal koppelingen met andere systemen en de eisen aan beveiliging en gebruikersaantallen. Wat vrijwel elk traject gemeen heeft: er komt iets tussendoor dat niemand had voorzien. Reserveer daar vooraf ruimte voor, in budget en in planning. De grootste misverstanden over de prijs van een maatwerk webapplicatie zetten we apart op een rij.
Tel je eigen uren mee. Feedback geven, testen en collega’s meenemen kost tijd van mensen die het al druk hebben, en die tijd staat zelden in een offerte. Wijs iemand aan die namens je organisatie knopen doorhakt, en geef die persoon er de uren voor. Een traject wacht vaker op een beslissing dan op een developer.
Niet alles hoeft vooraf vast te staan
Een dichtgetimmerd bestek van veertig pagina’s is geen voorwaarde voor een goed traject. Het is eerder een risico, omdat het beslissingen vastlegt op het moment dat iedereen het minste weet. Wat wel scherp moet zijn voordat er iemand gaat programmeren: het doel, de gebruikers en de systemen eromheen. De rest krijgt vorm tijdens het traject, met een eerste werkende versie als toets in plaats van een document.
Begin die eerste versie bij de taken die dagelijks terugkomen en maak die vlekkeloos. Een applicatie die snel reageert en logisch in elkaar zit, wordt gebruikt; een applicatie vol mogelijkheden die traag of onoverzichtelijk is, wordt omzeild. De rest komt in een volgende ronde, gestuurd door wat gebruikers na de livegang nodig blijken te hebben.
Wil je weten waar die eerste versie bij jou zou beginnen? Op onze pagina over maatwerkapplicaties lees je hoe we van vraagstuk naar werkende software komen. Neem je antwoorden op de vragen hierboven mee, dan begint het gesprek niet bij software, maar waar het hoort te beginnen: bij hoe je organisatie werkt.