Over appels en peren: 5 aanbevelingen voor opdrachtgevers

Wiskundige formules, onze hypotheek, de auto onder de motorkap, het pensioen, het thuismodem-wifi-gebeuren: dingen die complex zijn, roepen bij de meeste mensen weerstand op. We proberen eraan te ontkomen, schuiven eindeloos voor ons uit, zuchten en steunen. Dat geldt ook als het gaat over UX, HTML, PHP, SEO, SSL en OTAP. Alleen al de afkortingen roepen weerzin op en veel opdrachtgevers van online-ict-internetbureaus lopen bovendien niet warm voor techniek.

Weerstand als het gaat om techniek is soms lastig. Jammer vaak ook, want ict-projecten worden beter en leuker als je een beetje ruimte en aandacht maakt voor technische complexiteit. Toen ik op de middelbare school zat, werkte mijn vader aan de universiteit in Delft en deed de hele dag Complexe-Dingen-Met-Wiskunde. Als er een onvoldoende voor wiskunde op mijn lijst dreigde, zat er maar één ding op: mijn vader vragen. Ik pruttelde er altijd bij dat ik alleen de sommen moest kunnen óplossen en dat ik niks hoefde te weten over het waaróm van die formules. Helaas. Het draaide er steevast op uit dat mijn vader toch ging uitleggen hoe de boel in elkaar zat. Mijn proefwerk was na zo’n bijles altijd een inkoppertje en ik moet toegeven dat het zelfs leuk werd.

In het kielzog van het artikel ‘Waar opdrachtgevers het zuur van krijgen‘ interviewde ik de afgelopen tijd collega’s bij online-ict-internetbureaus. Waar het bij het eerste artikel ging over de vraag wat wij bureaus nóóit mogen doen, vroeg ik collega’s nu wat het werken in opdracht moeilijk maakt en wat er beter zou kunnen. Ook nu waren de antwoorden herkenbaar en maakte ik grinnikend aantekeningen. In de kern komt het erop neer dat bureaus opdrachtgevers willen uitnodigen om bij UX, HTML, PHP, SEO, SSL en OTAP een beetje weerstand te overwinnen. Ict-projecten worden er – net als wiskundeproefwerken – beter en leuker van. Vijf aanbevelingen.

1. Offerteaanvraag = projectfase 1

Het begint vaak bij de offerte. Een veelgehoorde verzuchting van opdrachtgevers is: ingediende offertes blijken onvergelijkbare appels en peren. De ene aanbieding is zomaar twee keer zo duur als de andere en waar het verschil in zit, blijft onduidelijk.

Voor goede en vergelijkbare offertes is een goede offerte-aanvraag nodig. Mijn bureau bouwt websites en helpt opdrachtgevers op weg te met deze checklist offerteaanvraag nieuwe website. Deze checklist somt mogelijke onderwerpen op zodat je geen zaken over het hoofd ziet. En je dus betere offertes krijgt.

Verder helpt het om de offerteaanvraag niet te zien als iets wat even vooraf moet, maar als een substantieel onderdeel, als fase 1 van het project. Pim Snel van bureau Lingewoud stelt: “Besteed 20% van het budget aan vooronderzoek en nog eens 20% aan conceptontwikkeling. En dan bouw je het project met die 60%. Zo zou het moeten. En niet in een verhouding 10% voorwerk en 90% bouw zoals je vaak ziet.”

Collega Sanne Witkamp van Wingspan begeleidde diverse organisaties bij het maken van een offerteaanvraag. Zij betrekt verschillende interne partijen en onderzoekt samen eisen en wensen, weegt ze in een MoSCoW-lijstje en werkt ze uit. Als het even kan, haalt ze er een techneut bij: “Hoe verder je bent met je interactie-functioneel-technisch-whatever-ontwerp, hoe helderder offertes worden. En niet onbelangrijk: het eindproduct wordt er beter van.”

Het is geen gek idee om de onderzoeks-/conceptfase los te koppelen van de bouw. Je werkt eerst – al dan niet samen met een bureau – het concept uit en op basis daarvan doe je een offerteaanvraag bij een aantal partijen. Dan krijg je een offerte voor appels als er daarom vraagt. Of je krijgt een peren-voorstel, dat je dan met andere peren-voorstellen kunt vergelijken.

2. Maak werk van wensen en eisen

“Een huis met vier kamers, graag.” Mark Rooijens van Cipix vergelijkt laten bouwen van een huis met het laten bouwen van een website, “Je zou wel gek zijn om het bij ‘ik wil vier kamers’ te laten als je met een aannemer aan tafel zit om plannen te maken voor je nieuwe huis. Je wil sturing op het aantal vierkante meters, verdiepingen en ramen. Maar je wil ook beslissen over dakconstructies en isolatiemethodes omdat ze consequenties hebben voor kosten en wooncomfort.” Om te kunnen besluiten over requirements, moet je erin. In de techniek van dakconstructies en isolatiemethodes of van CMS’en en specs, tot je oksels. Of tenminste tot je middel.

Onlangs begonnen we met mijn bureau aan een project. De wensen/eisen-lijst was een veelkleurig pallet. Ik las ‘nieuwsberichten moeten tot een bepaalde datum tot een bepaalde tijd op de homepage bovenaan kunnen blijven’ en meteen daaronder ‘de website moet gebruikersvriendelijk zijn’ gevolgd door ‘je moet kunnen zoeken op de website’. Men had daarbij geen specifieke voorkeur voor een bepaald CMS. En pas bij een tweede vragenronde kwam boven water dat er een koppeling met een CRM nodig was. Lijkt misschien niet zo’n ding, maar gelukkig ontdekten we het nog binnen het aanbestedingstraject…

Als je als opdrachtgever tot je middel in de wensen en eisen en eisen zit, kom je er achter dat dat van die nieuwsberichten in het ene CMS zo gepiept is, maar bij het andere CMS moet er duur maatwerk aan te pas komen. Als het een belangrijke eis is, kun je je CMS er dus bewust op uitkiezen. Is het gewoon een ‘lijkt me wel handig’ van de beheerder van de nieuwsberichten is, dan heb je – op dit punt – inderdaad geen voorkeur voor een bepaald CMS.

Zoekmachines, ook zoiets. In het project dat we begonnen waren, bleek de gewenste zoekmachine niet het modale middenklassertje te zijn waarvoor we geoffreerd hadden. Er bleek een vrij zwaar topmodel nodig te zijn: hij moest ook door pdf’s crossen en zoekresultaten gewogen inparkeren. Meteen dreigde een budgetoverschrijding. Gelukkig hebben we dit zoekmachineprobleem kunnen oplossen door een andere functionaliteit wat lichter uit te voeren. Maar een beetje nauwkeuriger voorwerk had stress over geld en verwachtingen gescheeld.

Jeroen van Gogh van Open Web IT raadt bovendien aan om projecten – als het even kan – op te delen in fasen. Ook hij vergelijkt het met een huis: “Als je gaat verbouwen, wil je ook niet de badkamer, de keuken en de aanbouw tegelijk realiseren. Doe datgene wat het meest nodig is eerst en bepaal dan de volgende stap. Omarm de scrum-gedachte.”

Het beschrijven van specs en het plannen van projectfasen is best een werkje, maar laten we wel wezen: het is geen hogere wiskunde. Het kost serieuze aandacht en tijd, soms even bijstand van een techneut en verder Hollands polderverstand. En dan ben je al een eind op weg. Dat een goed begin het halve werk is, is misschien niet helemaal waar, maar het voorkomt budgetoverschrijdingen en je krijgt wat je nodig hebt.

3. Bepaal welk type leverancier je nodig hebt

Online-ict-internetbureaus zijn net kledingwinkels: bij de ene koop je überhip, bij de andere degelijk en niet stuk te krijgen en bij weer een volgende krijg je twee voor de prijs van één. En dan zijn er ook nog die alleen galajurken of stropdassen verkopen.

Als je de markt niet zo goed kent, lijken al die bureaus op elkaar: overal mannen met brillen en baarden achter grote schermen. Maar. Als je de markt wel kent, vraag je je regelmatig af hoe sommige opdracht-bureaucombinaties in vre-des-naam tot stand komen. Alsof iemand voor een klusbroek naar de Men at work ging of een zeilpak denkt te kunnen aanschaffen bij Zeeman.

Het helpt natuurlijk al enorm als je weet wat je nodig hebt. Is er een storytelling-concept met spetterende graphics nodig? Wil je strategische input op je online aanwezigheid? Moeten bezoekers vriendelijk door een beslis- en aankoopproces geleid worden of moeten systemen online ontsloten worden? Met andere woorden: is de opdracht meer conceptueel, grafisch, strategisch, ux of technisch van aard?

Bureaus zijn niet in enge hokjes te proppen, maar als je goed kijkt, zie je wel vaak wel waar de kernkwaliteiten liggen. Vaak zegt een portfolio veel. Wat voor soort klussen doen ze? In welke branches? Met welke methoden en systemen werken ze? Voor wat voor soort klanten? Als het allemaal een beetje in lijn ligt met de opdracht die jij te vergeven hebt, zit je goed. Hoe beter de competenties van het bureau op de opdracht passen, hoe soepeler het project en hoe beter het eindproduct.

4. Alsjeblieft: géén design-pitch

Aan één ding hebben alle bureaus een grondige hekel: de design-pitch. Het is duur, je moet een designer aan het werk zetten. Maar dat is niet de voornaamste reden van de aversie. “Schot in het duister” verklaren mijn collega’s stuk voor stuk terwijl ik hevig instemmend ja zit te knikken. Een design-pitch is een nogal frustrerende aangelegenheid. Je kunt alleen een goed grafisch ontwerp maken als je echt ingevoerd bent op wat er nodig is. Bovendien is het grafisch ontwerp vaak maar een heel klein deel van de opdracht. Je maakt dus voor veel geld iets waarvan je maar hoopt dat het het juist valt en terwijl het eigenlijk niks zegt over je kwaliteiten om de opdracht te volbrengen. Een poosje geleden pitchte ik met mijn bureau met een design waarin we het betrouwbare huisstijlblauw van de gehoopte opdrachtgever solide ingezet hadden. Tijdens de pitch bleek dat ze net naar ‘jonger en dynamischer’ wilden. En ondertussen repte er niemand over de complexe database-migratie die nodig was en waarvoor we iets slims in petto hadden. Echt. Het is voorgekomen.

Een grafisch ontwerp lijkt een aantrekkelijke manier om verschillende aanbieders met elkaar te vergelijken omdat iedereen over grafisch ontwerp mee kan praten. Het wordt soms gevoeld als uitkomst omdat het beoordelen technische details van wensen en eisen ingewikkeld is.

Als je wil weten wat een bureau grafisch wel en niet kan, kun je beter naar eerder uitgevoerd werk kijken. Vraag een kandidaatbureau om in een salespresentatie een paar projecten toe te lichten: op grafisch ontwerp, maar ook op ux-keuzes, proces, resultaten en techniek. Het voordeel daarvan is dat je beter weet wat je koopt en zo meteen niet de oorlog hoeft te winnen met een bureau dat een keer een pistoolschot gunstig mikte maar geen tank besturen kan.

Laten we elkaar over en weer de hand reiken om projecten te realiseren die niet te veel, niet te weinig, maar precies goed aansluiten bij wat nodig is.

5. Geld: hoeveel wil je uitgeven aan wat?

Geld is gezeik stelde ik in het vorige artikel al. Voor opdrachtgevers is het vaak lastig om zich een voorstelling te maken van waar de euro’s in gaan zitten.

Een probleem dat zich voordoet, is dat geld nogal eens een helder punt van vergelijking bij meerdere aanbiedingen lijkt te zijn, net zoals een grafisch ontwerp. Het komt zomaar voor dat de ene offerte twee keer zo hoog is als de andere. Als je dan niet kunt beoordelen wat er precies aangeboden wordt, kun je eigenlijk geen goede beslissing nemen. Uurtarieven ontlopen elkaar niet veel. En als je ervan uitgaat dat er voor al die uren gewerkt wordt, is ene aanbieding dus echt iets anders dan de andere.

Marja Doedens van Goldmund, Wyldebeast & Wunderliebe glimlacht: “Waarom het bij ons zoveel moet kosten. De buurjongen kan het ook, voor weinig. Met een paar uurtjes en een template kom je snel een eind. Tja. Een muurtje sauzen kan de buurjongen ook, maar je laat hem ook niet de hele buitenboel professioneel in de lak zetten.” Rooijens legt uit: “Klant wil een paar veldjes in een formulier toevoegen. Hij brieft mij, ik brief programmeur, programmeur voert uit, designer en ux’er kijken mee, er wordt getest en gecheckt op AVG. De wijziging gaat live en administratie maakt een factuur. Technisch misschien maar een kwartiertje werk, maar in totaal zijn we er als team toch al gauw een paar uur mee bezig.” Degelijk werk, maar niet voor weinig.

René van Klaveren van Hands on: “En dan heb je nog zoiets als onderhoud van software. Die kosten zijn helemaal moeilijk te begrijpen. Je betaalt voor iets wat je al had. De grote beurt in de garage is net zoiets. Je hebt een auto die gewoon lekker rijdt, je smijt er een hoop geld tegenaan en hij rijdt nog steeds lekker. En bij een auto zie je tenminste nog een motorblok waarvan je je kunt voorstellen dat als je er nooit iets aan doet, dat het een keer in de soep loopt. Maar software roest en slijt niet.”

Ook op het punt van geld helpt het als je geduldig uitpluist hoe het zit. Waarom al die uren nodig zijn, moet een bureau uit kunnen leggen en dan is het uiteindelijk ook te begrijpen.

Een 9 voor wiskunde én meer lol

Kortom: bij zowel opdrachtgevers als bureaus zorgt het verschil in technische kennis voor ergernis en wantrouwen. Terwijl de intenties van beide partijen deugen. “Als bureau wil je maximaal bijdragen aan het doel en opdrachtgevers willen hetzelfde. In feite sta je schouder aan schouder,” zegt Doedens. Ook Rooijens verwoordt een positieve tendens: “Het wordt wel beter, het technisch kennisniveau van opdrachtgevers stijgt.”

Om online-ict-internetprojecten beter te sturen en betere eindproducten te krijgen, zit er dus maar één ding op: bij UX, HTML, PHP, SEO, SSL of OTAP af en toe denken “Oké, kom maar op dan.” Laten we elkaar over en weer de hand reiken om projecten te realiseren die niet te veel, niet te weinig, maar precies goed aansluiten bij wat nodig is. Je af en toe vastbijten in iets ingewikkelds levert betere producten. Dat alleen is al superfijn. Maar voor mij persoonlijk blijft het mooiste toch het plezier dat het me – soms na wat grommen en zuchten – oplevert. Op een borrel kunnen uitleggen wat blockchain is, je moet ze zien kijken. Binnenkort onze projectmanagers maar eens outsmarten met een paar onbekende maar o-zo-handige features van het CRM…