Smile
Terug naar hoofdmenu
Terug naar het overzicht

IT-projecten verlopen vrijwel nooit vlekkeloos. Sterker nog: ze zijn vaak een bron van veel ellende. Al meer dan twaalf jaar heb ik er dagelijks mee te maken, in het begin als klant en tegenwoording als leverancier. Inmiddels ben ik er wel achter dat het ei van columbus niet bestaat.

Bij Smile zijn we continu op zoek naar manieren om onze implementatiewerkwijze te verbeteren. Daarbij gebruiken we elementen van scrum als kader, maar betrachten we ook flexibiliteit. Want wat voor de ene klant werkt, kan voor een andere klant juist de verkeerde aanpak zijn.

Universele succesfactoren

We streven dus een gepersonaliseerde aanpak na om zo goed mogelijk een brug te slaan tussen de wensen en verwachtingen van de klant en de mogelijkheden van onze tooling binnen het beschikbaar gestelde budget. Toch zijn er – ondanks deze maatwerk aanpak – wel degelijk factoren te benoemen die ongeacht het type project en het type klant bijdragen aan een succesvolle implementatie:

1. Een duidelijke business case die is goedgekeurd en waaraan budget is toegekend.

Vaak wordt er al veel werk verzet in een project, terwijl het project feitelijk nog helemaal geen bestaansrecht heeft. Iemand heeft een geweldig idee of oplossing voor een probleem en begint voortvarend met het plannen en toewijzen van resources nog voordat er überhaupt een bussiness case richting het management is gegaan. Natuurlijk is het niet altijd mogelijk om aan het begin van het project de complete budgettering op orde te hebben, maar er moet wel een goedgekeurd budget beschikbaar zijn om te voorkomen dat er al veel werk wordt verzet en achteraf blijkt dat er helemaal geen budget beschikbaar is.

2. Heldere verwachtingen ten aanzien van de scope van het project, die continu scherp worden gehouden

Als je van tevoren een goed fundament legt voor het project en op een heldere manier de scope vastlegt, helpt dat enorm om het project op de rails te houden. Wees je er echter ook van bewust dat je niet alles vooraf duidelijk kunt maken: gedurende het project – als zaken ook echt gerealiseerd worden – zullen er altijd discussies volgen waaruit blijkt dat de verwachtingen uiteenlopen. Een goed project is een project waarbij de scope helder genoeg is om op grote lijnen overeenstemming te hebben over de beschikbaarheid van functionaliteit en waarbij gedurende het project in stappen overeenstemming wordt bereikt over de werking van die functionaliteit.

3. Een strenge doch rechtvaardige projectleider / productowner die een wij/zij sfeer tussen leverancier en klant voorkomt

Een goede projectleider / productowner is niet alleen in staat om mensen aan te zetten tot de juiste acties op het juiste moment, maar weet ook de natuurlijke kloof tussen leverancier en klant te overbruggen. Een project waarin leverancier en klant als één projectteam optreedt met een gezamenlijke drive om het project op de best mogelijk manier binnen de beschikbare tijd c.q. het beschikbare budget te realiseren heeft veel meer kans van slagen dan een project waarbij er duidelijk twee kampen zijn. Zorgen dat er niet teveel tijd wordt besteed aan welles-nietes spelletjes en dus een constructieve samenwerking stimuleren op basis van het uitgangspunt ‘geven en nemen’, is één van de belangrijkste – en misschien ook wel meest onderschatte – taken van de projectleider / productowner.

4. Beschikbaarheid en mandaat van de juiste sleutelfiguren op de juiste momenten

Het inzetten van de juiste resources met de juiste expertise blijkt in veel gevallen een onmogelijke opdracht. Deze sleutelfiguren zijn vaak niet voldoende beschikbaar met als gevolg dat er vervangers worden ingezet zonder mandaat.  Echter: als sleutelfiguren ontbreken op bijeenkomsten waar koppen met spijkers moeten worden geslagen, heeft dit grote gevolgen voor het project. De vervangers kunnen geen kant op, als ze zonder mandaat een besluit nemen hebben ze kans dat dit het verkeerde besluit blijkt (of in ieder geval een besluit waar de sleutelfiguren op een later moment niet achter blijken te staan) en als ze geen besluit nemen vertraagt het project. Het ontbreken van sleutelfiguren heeft ook nog eens een negatief effect op de andere projectleden: zij zullen al snel de conclusie trekken dat het project geen prioriteit heeft bij de leiding en dat komt hun eigen motivatie uiteraard niet ten goede.

5. Een iteratieve structuur die gebruikers op de juiste momenten betrekt

De tijd dat er uitgebreide functioneel – en technisch ontwerpen werden gemaakt, die vervolgens als één brok werden vertaald naar werkende tooling ligt achter ons. De kans dat er ergens in het begin een fout wordt gemaakt die later niet te herstellen is simpelweg te groot. Bovendien blijken op papier beschreven verwachtingen voor meerderlei uitleg vatbaar. Door het werk op te knippen in kleinere brokjes is er niet alleen minder kans op fouten en meer inzicht in de tussentijdse status, maar kun je ook op het juiste moment de juiste gebruikers betrekken en hun waardevolle feedback gebruiken voor volgende itteraties. Bovendien kun je het halen van tussentijdse mijlpalen gebruiken als moment om te vieren: het gevoel dat er (al) iets bereikt is geeft positieve energie aan het vervolg.

6. Voldoende ruimte voor testen en fine-tunen, zodat er ruimte is voor voortschrijdend inzicht

Tijd is geld en daardoor wordt er bij voorkeur krap gepland. Als er maar iets tegen zit, schiet voldoende tijd voor testen en finetunen er dan bij in. En omdat de wereld om ons heen blijft veranderen is het eindresultaat dan net niet wat de dagelijkse paktijk nodig heeft. Een gemiste kans die makkelijk kan worden voorkomen door realistisch te plannen.

7. Voldoende aandacht voor de juiste randvoorwaarden zoals hardware en training

Zeker in de huidige tijd wordt er vaak bezuinigd op projecten door uit te gaan van de minimale hardware specificaties en gebruikerstrainingen te schrappen. Het gevolg is een minimale performance en een gebruiker die niet weet wat er van hem verwacht wordt: geen ideaal klimaat voor het introduceren van een nieuwe tool. Bezuinig dus niet op de verkeerde zaken!