Customer Rollout Planning, dat doe je niet op eigen houtje

Reading Time: 4 minutes

In mijn carrière als IT-consultant ben ik snel terechtgekomen in een positie tussen Business en IT, dit in verschillende sectoren maar vooral met de focus op release management van webapplicaties en het begeleiden van de implementatie bij de eindklant. Hierbij komen steeds enkele gemeenschappelijke problemen naar boven die niet rechtstreeks verbonden zijn met technische of procesmatige tekortkomingen.

De uitdagingen bij het uitrollen van een nieuw product worden exponentieel groter met de schaal, complexiteit en geografie. Ik ben ervan overtuigd dat een goed samenwerkend cross functioneel team van business minded en technische vakmensen voor dit type projecten de sleutel is tot succes.

Helaas wringt hier vaak het schoentje, je kan namelijk de beste experten in hun domein inhuren, als deze niet efficiënt en respectvol met elkaar communiceren zal dit nog steeds uitdraaien op een mislukking.

Hoewel er verschillende project methodologieën zijn om deze problematiek aan te pakken, merk ik dat ze vaker aangewend worden om klanten te overtuigen dan dat ze effectief worden toegepast in de praktijk.

Waarom is een efficiënte customer rollout zo’n moeilijke klus om te klaren? Ik licht de pijnpunten hieronder verder toe.

Vele wegen leiden naar Rome

Het hart van de miscommunicatie tussen business en IT ligt bij het gebrek aan transparantie en kennis van elkaars processen. Wat niet weet, niet deert en hierdoor is er vaak ook weinig inzicht in elkaars standpunten. Iedereen werkt naar hetzelfde doel, maar geraakt soms verblind door zijn eigen prioriteiten.

Bij aanvang van een project richten businessprofielen zich meteen op de aard van een product en een succesvolle rollout. Hierbij worden processen en gesprekken opgestart tussen de business, sales en de klant in kwestie. Vragen zoals onderstaande zullen hier naar voren komen.

• Welke drijfveer zit er achter de nood van het product?
• Hoe gaat het product gebruikt worden?
• Wie zal voornamelijk in aanraking komen met het product?
• Wanneer moet het product opgeleverd worden?

Vanuit een andere invalshoek focust IT zich op het opleveren van de functionaliteit van het product en de constante verbetering hiervan in de vorm van user stories en bug reports.
Om tot een concrete product backlog te kunnen komen, stelt het IT-team zich volgende vragen:

• Zijn de requirements duidelijk omschreven zodat development kan opstarten?
• Wat is de prioriteit van iedere feature?
• Welke impact heeft een requirement op het team of op een functionaliteit?
• Wat is de capaciteit van het team?
• Hoe stellen we het test- en releaseplan op?

Het gat om te dichten

Zoals je ziet zijn beide perspectieven nauw gekoppeld en afhankelijk van elkaar. Toch worden ze niet altijd optimaal op elkaar afgestemd.

Assumptie is de grootste vijand van beide kampen. Het gebrek aan validatie en regelmatig afstemmen kan leiden tot vertragingen, ontevreden klanten en zelfs tot boetes voor het bedrijf als er afspraken zijn gemaakt die niet kunnen worden voldaan.

Vals commitment

Business is steeds zeer enthousiast om een product te promoten bij potentiële klanten, helaas houden ze hierbij niet altijd rekening met de achterliggende processen die de uitrol van dit product mogelijk maken. Er wordt hierbij vaak ‘vals’ commitment gegeven aan een potentiële klant om deze te overtuigen. Er wordt toegezegd op basis van vaag beschreven ‘Show Stoppers’, ‘Must Haves’ en ‘Release’ deadlines, zonder een voorgaande analyse van de gevraagde functionaliteit.

De haalbaarheid om bovenstaande commitment op te leveren, tegen de afgesproken datum, wordt vaak niet afgestemd met het IT-team dat de functionaliteit moet ontwikkelen, testen en releasen.

“Bizz: It’s only adding a field, how much work can it be?”

“IT: You wouldn’t even understand if I told you so”

Te lange feedbackloop

Bij IT worden de nieuw gevraagde functionaliteiten overigens eerst opgenomen door de Product Owner die deze functionaliteit high level bespreekt met degene die de aanvraag heeft ingediend. Hierbij wordt een prioriteit gegeven aan het ticket. Het is pas in een later stadium dat men een grondige technische analyse doet en alles tot in detail wordt beschreven. Hierbij vallen er maar al te vaak verrassingen uit de bus. De opleverdatum kan hierdoor in het gedrang komen alsook het contract dat is aangegaan met de klant.

Het is duidelijk dat de feedbackloop vanuit IT hierbij te lang is. Nochtans zijn er voldoende methodologieën die dit probleem in toom kunnen houden. Maar in situaties met een harde deadline worden deze technieken vaak niet aangewend en dat is vragen om problemen. Ieder proces heeft namelijk zijn breekpunt wanneer er te veel druk wordt gezet op een bepaalde schakel.

Communication before commitment

Communicatie kan hierbij de redding zijn. Zo ontstaat er inzicht vanuit de business op de IT-processen en omgekeerd. Door wederzijds begrip kan je ook meer rekenen op flexibiliteit vanuit beide afdelingen. Er bestaan verschillende functieprofielen in een organisatie die deze samenwerkingen kunnen faciliteren zoals:

• Release Manager
• Business Deployment Lead
• Customer Success Manager

Deze rollen missen echter hun doel wanneer ze geen best practices opstellen en het mandaat niet krijgen om deze op te leggen binnen de ganse organisatie. Enkel indien iedereen gealigneerd is, kan er commitment gegeven worden vanuit de verschillende domeinen binnen een organisatie. Op deze manier kunnen de verwachtingen en prioriteiten steeds in evenwicht worden gehouden en wordt de slaagkans om een topproduct op te leveren hoger.

De gouden regel die ik wou meegeven, is bij deze volgens mij ook duidelijk. Consulteer iedere betrokken partij over de haalbaarheid, complexiteit en afhankelijkheden van een product vooraleer er commitment gegeven wordt. Heb je nog vragen over dit artikel of wil je graag je mening geven? Contacteer me dan zeker via LinkedIn!