In de afgelopen jaren heb ik de best veel internet projecten van dichtbij meegemaakt, vooral in de rol als product owner. Zo eind jaren 90, was er nog niet zo heel veel ontwikkeld. Eigenlijk waren er ook niet veel referentieprojecten die goed of slecht gingen. Er werd veel geëxperimenteerd.
Nu zijn we jaren verder, en ook de ervaring met het doen van internet projecten is een stuk verder. De projecten zijn echter ook complexer. Plus opdrachtgevers zijn wat gewend.
Helaas, het gaat toch zeer regelmatig verkeerd. Om nu toch een succes te behalen bij een e-commerce project of webproject, heb ik de drie meest voorkomende problemen naast elkaar gezet, zodat je meteen weet welke valkuilen je moet vermijden (en hoe) om je webproject te laten slagen.
Tip 1, heb ik al in een voorgaand artikel beschreven, hieronder volgt tip nummer 2: gebrek aan scope of onduidelijke specificaties.
TIP 2: Gebrek aan Scope bij E-Commerce projecten
Op het moment dat je iets bestelt, dan moet het wel duidelijk zijn wat je krijgt. Hoe vager omschreven – en hoe minder scherp de scope van het e-commerce project is -, hoe verder het product zal afwijken van de verwachting die je had. Uiteraard is het zo dat wat er in de offerte wordt aangegeven niet te vergelijken is met het uiteindelijke product. Daarvoor biedt een offerte geen ruimte. Het is ook niet het document dat daarvoor bedoelt is.
Je kunt ervan uit gaan dat een bureau altijd een aanbod doet dat in hun ogen aansluit bij hetgeen er gevraagd wordt. Alleen als hetgeen dat gevraagd wordt niet scherp genoeg omschreven staat, dan zal de offerte uiteindelijk ook niet al te veel aansluiten bij de verwachtingen. Het product, bijvoorbeeld de webshop, zal dan wel een webshop zijn. Echter, misschien niet helemaal zoals verwacht.
Conclusie: Om het gebrek aan scope te voorkomen zijn er meerdere oplossingen.
- eerst begin je met een goede bureau selectie aan de hand van referenties. Die referenties bel je ook na.
- nadat je een bureau hebt geselecteerd, dan doe je eerst een product definitie, waarbij je gebruik maakt van de kennis van het bureau om te komen tot een functionele ontwerp. Is het bureau niet in staat om dat te doen, dan kun je altijd deze fase overslaan met het bureau door het inhuren van een externe consultant die dit kan doen.
- de inhoud uit dit onderzoek, kan je vervolgens gebruiken als basis voor je RFP (Request For Proposal). Daarmee kun je heel specifiek geselecteerde bureau’s voorzien van duidelijke informatie wat je specifiek wil bereiken, en wat ze moeten maken.
- dit zelfde document vormt tijdens de bouwfase je referentiekader. Het is dan wel mijn advies om de schrijver van dat stuk bij het project betrokken te laten, omdat hij als geen ander kan aangeven wat hij specifiek bedoelt. In feite is die persoon ideaal in te zetten als product owner.
Dit was Tip 2 uit een reeks van 3. Tip 1 is terug te lezen in het artikel over Overschatting of slecht opdrachtgeverschap.
Tip 3 zal gaan over het gebrek aan mandaat.
