We kennen ze allemaal. ICT-projecten die aan het eind mijlenver verwijderd blijken van het geplande resultaat. Van overheid tot bedrijf, iedere organisatie heeft er vaak een fors aantal in de logboeken staan. Waarom gaat het zo vaak mis? Mijn antwoord: In veel ICT-projecten is geen rol weggelegd voor online marketeers.
ICT-bedrijven en -afdelingen zitten vol met knappe koppen. Slimme jongens en meiden met een technische opleiding waar je u tegen zegt. Toch krijgen ze het vaak níet voor elkaar een goede, succesvolle oplossing in elkaar te hacken waarmee de klant tevreden is. ICT-projecten kunnen op allerlei fronten mislopen. Dat begint met de verwachtingen van een opdrachtgever, die denkt dat hij met een beperkt budget een innovatieve, foutloze en complexe maatwerk oplossing krijgt. Aan het andere eind van het spectrum zitten de ICT-leveranciers die zich vergalopperen aan de complexiteit van een oplossing, die de opdracht te graag op zich nemen en dus veel te veel hooi op hun vork nemen. Uit ervaring weet ik dat tussen deze uiteinden een palet aan factoren zoals onwillige gebruikers, vage requirements of beperkende bestaande infrastructuur zit. Binnen de overheid deed de commissie Elias hier kortgeleden onderzoek naar.
Om de grote verscheidenheid aan valkuilen te illustreren, zie je vaak dit plaatje in kantoortuinen hangen:
Ondanks deze verscheidenheid aan angels en valkuilen, zie ik toch een rode draad in veel mislukte projecten. Het lijkt bij ICT-projecten vaak, eigenlijk bijna altijd, mis te gaan bij de Viewer. Voordat ik toelicht hoe ik tot die observatie kom, moet ik eerst iets toelichten aan niet-techneuten.
Design Patterns
Je bent vast bekend met een sjabloon of een template. Dergelijke sjablonen of templates gebruiken onze vrienden van de ICT ook. Zij noemen ze alleen Design Patterns. Leuk experiment: wil je een ontwikkelaar op de kast jagen, dan moet je eens voorstellen dat hij een decorator pattern om een bestaande applicatie bouwt, om zo een functioneel probleem op te lossen.
Design Patterns, ontwerppatronen of- richtlijnen dus, zijn een soort best practices voor ontwikkelaars. Zij gebruiken deze patronen bij het ontwerpen van oplossingen. Goede ICT’ers hebben vaak een boekenplank vol met boeken die ieder een set van patronen bespreken. Het MVC-model is zo’n alom tegenwoordig design pattern.
Het MVC-Model
Iedere ICT’er kent de term ‘MVC-Model’. Steek je hoofd maar om de deur bij de ICT-afdeling en vraag het aan willekeurig wie. Loopt er iemand die er niet mee bekend is, dan is het waarschijnlijk een manager.
Het MVC-Model is een template voor ICT’ers, waarmee zij oplossingen opdelen in drie elementen:
- Model
- Viewer
- Controller
Ieder element kent zijn eigen logica, de drie elementen samen vormen de oplossing zoals de gebruiker die ervaart. Met het element Model bedoelen ICT’ers de gegevens zoals die worden opgeslagen in bijvoorbeeld een database. Het element Controller, refereert aan het onderdeel in de oplossing die ervoor zorgt dat zaken in de juiste volgorde gebeuren. De Viewer is het element waarin de gebruiker informatie ziet en bewerkt.
Een voorbeeld:
Een gebruiker van een bankieren-app (Viewer) verstuurt een betalingsopdracht. Deze wordt gecontroleerd en verwerkt door de bank (Controller) en na goedkeuring worden de gegevens bijgewerkt in de administratie (Model).
Voor de puristen: Ja, ieder element uit het voorbeeld kun je zien als een mini-MVC. Maar die discussie laat ik even buiten beschouwing.
Het gaat mis bij de Viewer
Goed, met deze korte introductie van Design Patterns en het MVC-Model kom ik bij wat de bron van ellende in veel ICT-projecten lijkt te zijn: het schrikbarende verschil tussen wat een Viewer doet en wat het zou móeten doen.
Stel jezelf eens de volgende vragen. Hoeveel mislukte ICT-projecten ken je waarbij de oplossing structureel iets anders doet dan gepland? Hoeveel mislukte ICT-projecten ken je, waarbij benodigde informatie structureel niet opgeslagen en verwerkt kon worden? En hoeveel mislukte ICT-projecten ken je omdat je als gebruiker hopeloos verdwaalde in schermen waarmee je eigenlijk niks kon?
Het gaat in mijn ogen bij het gros van de ICT-projecten mis bij de Viewer. Het gaat mis op het snijvlak van gebruiker en ICT-oplossing. De gebruiker hééft gewoon niet zoveel aan de tool, het voegt simpelweg weinig toe of het zit zo complex in elkaar dat hij halverwege afhaakt. En ga het dan maar eens succesvol uitrollen in een organisatie.
Natuurlijk ben ik niet de eerste die dit opvalt. ICT’ers zien dit zelf ook en komen daarom met:
De foute ICT-aanpak
De oplossing vanuit de ICT-hoek voor deze moeizame projecten? Zij willen meer en betere ‘requirements’. Een duidelijker beschrijving van de wensen en eisen. Hiervoor hebben ze methoden en technieken zoals informatie analyse, user stories, UML, sequencediagrammen, swimlanes, requirement catalogs, non-functional requirements, enzovoort. Haak je al af?
De kracht van de ICT’er is tegelijkertijd zijn achilleshiel. De ICT’er is een automatiseerder. Zijn manier van denken is erop gericht een geautomatiseerde oplossing te leveren. Zijn manier van informatie verzamelen is hier een verlengde van. Gestructureerd, afgetikt. Hoeveelheden pixels, kleurcodes. De bèta-way, zeg maar. Dat werkt uitstekend bij het opstellen van de wensen en eisen aan de Controller en de Model. Daarom mislukt een ICT-project ook bijna nooit omdat “de applicatie een verkeerde berekening maakt’, of “omdat de verkeerde informatie wordt opgeslagen”. Maar een Viewer vraagt om ‘softe’ informatie. Menselijk gedrag, de invloed van kleuren en stijl op dat gedrag, de opbouw en locatie van tekst.
Hoe komt dan nog goed met die Viewer? Door deze te baseren op:
Conversie
Iedereen die zich een beetje bemoeit met website optimalisatie, streeft eigenlijk maar naar één ding: conversie (en ok, daarmee klanttevredenheid). Alle andere acties zijn hieraan ondersteunend. Je bedoeling met je site is immers dat bezoekers bepaalde acties uitvoeren, al is het maar contact leggen.
Laten we voor het gemak conversie omschrijven als een actie die een gebruiker van een website of app moet uitvoeren en die écht waardevol is, voor zowel de gebruiker als de organisatie. Ik hanteer bewust een omschrijving waarin in drie vereisten zitten:
- de handeling van de gebruiker is noodzakelijk;
- de handeling levert waarde op voor de gebruiker;
- de handeling levert waarde op voor de organisatie.
Simpel voorbeeldje:
Een klant boekt een reis via een website.
De klant wil op reis, die sense of urgency kunnen we niet of nauwelijks afleiden uit onze andere gegevens of applicaties. Het boeken is noodzakelijk om dat doel te behalen. De reis heeft waarde voor de klant, want hij is toe aan vakantie. De reis levert waarde op voor de organisatie, want het betekent omzet.
Hoe maak je dit zo eenvoudig mogelijk? Dit is het moment om de ICT-projectleider van de toekomst te introduceren.
De online marketeer
Een goede online marketeer helpt een organisatie aan betere conversie, ofwel aan een beter presterende website of app, door drie dingen helder te krijgen:
- Wat is de waarde die de klant zoekt?
- Wat is waardevol voor de organisatie?
- Wat staat de klant als gebruiker in de weg om de benodigde handeling te verrichten?
Om dit helder te krijgen werken online marketeers met analytics, klantpanels, NPS, customer journeys, persona’s, usability onderzoek, touch points, enzovoort.
ICT’er, ben je er nog? Of vraag je je inmiddels af:
Hoe krijgen we dan een succesvol ICT-project?
Simpel, door de online marketeer een cruciale plek te geven in de projectorganisatie en verantwoordelijk te maken voor de Viewer.
De online marketeer, eventueel bijgestaan door een team van UX experts, analytici en testers, is gewend om samen met de organisatie in kaart te brengen welke conversie gewenst is. Binnen de dynamiek van een ICT-project betekent dit, dat de online marketeer ervoor zorgt dat helder wordt wat nou precies de handelingen zijn die een gebruiker moet doen. Waardevol voor zowel de gebruiker als de organisatie.
Ook is de online marketeer uitstekend in staat door middel van diverse testen en methoden ervoor te zorgen dat gebruikers verleid worden de gewenste handelingen uit te voeren, mèt een glimlach. Daarbij maakt het niet veel uit of de Viewer nu een website, een app of een klassiek applicatiescherm is. Laat die keus maar aan de marketeer over.
Een goede online marketeer zet snel in de steigers waar het in de Viewer om gaat. Hij heeft snel helder welke handelingen echt waardevol zijn en hoe hij de gebruikers verleid deze handeling zo snel en soepel mogelijk uit te voeren. Dat is immers zijn expertise en waar het hem om gaat: hoe soepeler de klantreis, des te meer conversie. Hoe makkelijker de tool is, hoe beter die tool aansluit bij de behoeften, des te meer gebruikers die de Viewer omarmen, er graag mee werken en zelfs aanraden bij collega’s en bekenden.
Zet dat eens af tegen een gebruikersgroep die bij het zien van de applicatieschermen al begint te morren, na een eerste training afhaakt en na enkele weken de applicatie links laat liggen.
Kortom,
De online marketeer is cruciaal in je ICT-project
Ga als verantwoordelijke voor een ICT-project praten met deze specialisten, betrek ze in je projecten. Zoek ze op. Heb je ze niet in je organisatie? Huur ze in via één van de vele bureaus. Je hebt al klasse automatiseerders. Zorg nu ook voor een uitstekende aansluiting bij je gebruikers.
1 comment
Ik deel je mening over stelling dat alleen kijken naar de functionaliteit en requirements kijken onvoldoende is voor het slagen van een ICT-project. Ik vraag me wel af of (alleen) marketeers toevoegen zaligmakend is.
Marketeers (on- en offline) kijken naar de klant. Maar de klant is lang niet altijd de gebruiker. Dat geeft het verhaal in zekere zin zelf ook aan: halverwege verandert “klant” ineens in “gebruiker”. Naar mijn mening moet je nog dichter bij de gebruiker en zijn eisen en wensen zien uit te komen. Ik zie dan eerder (ook) een rol voor gebruikersonderzoek; laat ik nou nét iemand kennen die daar verstand van heeft. ;-)
Comments are closed.