Nee.

VEENENDAAL - ‘Nee?’
‘Nee.’
‘Dat snap ik niet. Dit heeft iedereen toch nodig?’
‘Tja.’
‘En wanneer komt het er dan in?’
‘Dat weet ik niet.’
‘Maar… jullie hebben toch een planning?’
‘Tuurlijk.’
‘Dan kun je toch zo zeggen wanneer het beschikbaar is?’
‘Nee, dat niet.’

Een gesprek om kromme tenen van te krijgen, toch? We houden niet van ‘nee’. Niet als softwareleverancier en niet als klant. ‘Sorry seems to be the hardest word’ concludeerde Elton John. Hij zat duidelijk niet in de software. Daar is mijn ervaring dat je veel vaker ‘sorry’ hoort dan ‘nee’. Dat vind ik niet slim en ik zal uitleggen waarom.

Klantvriendelijk?

Er is een tamelijk hardnekkig misverstand dat ‘klantvriendelijkheid’ verwart met ‘ja’ zeggen. ‘Nee’ is niet klantvriendelijk. We willen het elkaar maximaal naar de zin maken dus ‘kan niet’ is geen optie. En hoe vervelend is het om een opdracht te verliezen? Dat risico wil je niet lopen.

Gelukkig kan alles en we gaan als goede vrienden uit elkaar.

Niet veel later begint het echter te kriebelen. Als verkoper of consultant vind je weinig gehoor bij de ontwikkelafdeling want daar hebben ze hun prioriteiten voor de komende tijd allang vast staan. Als klant bel je nog maar eens om te horen wanneer je de besproken functionaliteit eindelijk kunt verwachten want je rekent er immers op.

Nog weer wat later wordt het echt vervelend. Als klant moet je verder en je ontkomt er onderhand niet meer aan om je processen dan maar anders te gaan inrichten. Onverwachte kosten, tijdverlies, teleurstelling.

Je belt nog weer eens een keer naar je accountmanager, die gaat het hoog spelen en de prioriteiten bij de ontwikkelafdeling moeten worden aangepast. Reguliere ontwikkelingen die waren gepland, moeten worden uitgesteld.

En zo heb je elkaar in de houdgreep, een situatie die voor niemand iets oplevert. Uiteindelijk haak je als klant ook boos en teleurgesteld af.

Hoe het komt

Maar het is toch logisch dat je als (potentiële) klant informeert naar wat je mag verwachten? Een software-ontwikkelaar heeft toch een roadmap en een planning? Wat is het probleem?

Zeker.

Maar het gaat op een paar punten mis:

1. we denken dat software-ontwikkeling voorspelbaar is
2. als softwareleverancier stellen we het belang van 1 prospect of klant soms boven dat van de hele community
3. als klant maken we regelmatig onze beslissingen en ons proces op voorhand afhankelijk van de toezeggingen van een leverancier

Als we in staat zijn om deze drie dingen aan te pakken, komt er meer rust in de communicatie en kunnen we allemaal ons ding doen op een manier die voor iedereen beter is.

Onvoorspelbaar

Het bouwen van software is helaas niet erg voorspelbaar gebleken. Dat was het al niet in de jaren ‘80 toen we begonnen met dikke beschrijvingen waar iedereen het mee eens moest zijn voordat de ontwikkeling startte (‘waterfall model’). Wat er van tevoren op papier zo goed uitzag, bleek tijdens de bouw toch anders uit te vallen. Aanpassingen kostten veel tijd en geld. Bovendien voldeed het eindresultaat lang niet altijd aan de verwachtigen.

Tegenwoordig is ‘Agile’ het toverwoord. En terecht, vind ik. Korte slagen, tussenstanden opleveren en gaandeweg bijsturen naar optimaal resultaat. Een dergelijk proces is echter inherent onplanbaar. Niemand kan je vertellen wat je onderweg tegenkomt want niemand heeft alle details van tevoren doordacht. De totale doorlooptijd is vrijwel zeker korter en het resultaat beter. Alleen: hoelang het precies duurt, weet niemand. Bovendien geeft Agile development de ruimte om op het laatste moment prioriteiten bij te stellen als de situatie daarom vraagt. Die flexibiliteit verlies je wanneer je probeert toezeggingen te doen aan klanten of prospects.

Beter accepteren we de onvoorspelbaarheid en verspillen we geen energie aan ons ertegen te verzetten.

Belang van de gemeenschap

Als softwareleverancier heb je te maken met een grote groep klanten die je gelukkig wilt maken. Op enig moment ben je in actief contact met, laten we zeggen, 30-60 prospects en klanten die je traint of waar je consultancy aan verleent. Daarnaast zijn er (in het geval van Visionplanner cloud) nog 2.300 klanten die je software vrijwel dagelijks gebruiken maar die je niet dagelijks spreekt.

Dan is het eigenlijk raar als een groot deel van de ontwikkelagenda zou worden gewijd aan het tevreden stellen van die 30-60 kantoren. Er is immers een veel grotere gebruikersgroep die ook belangen heeft en die bovendien al actief met de software werkt.

De markt geeft duidelijk aan waar de prioriteiten liggen. Ontwikkelingen bij banken, SBR, risoico-gericht samenstellen. Allemaal zaken waar we als softwareleverancier mee aan de slag gaan in het belang van de hele markt.

Afhankelijk

Wat we tenslotte zien, is dat kantoren gaan wachten op het beschikbaar komen van bepaalde functionaliteit. Daarmee doe je je eigen organisatie tekort. Je weet niet hoe lang het duurt, maar al die tijd werk je sub-optimaal en steek je (negatieve) energie in het blijven navragen bij je leverancier en het rustig houden van je medewerkers. Afwachten en niets doen is geen verstandige houding. Je bent niet meer in control over je eigen processen. 

Hoe dan wel?

Als softwareleverancier kiezen wij ervoor om alleen te verkopen wat we vandaag kunnen leveren. Wat er niet is, is er niet. Dat geeft ons de ruimte om onze eigen prioriteiten te stellen en zonder onrealistische tijdsdruk kwalitatief hoogwaardige software te leveren.

Als kantoor moet je je beslissingen nemen op basis van beschikbare functionaliteit. Voor de processen die niet (of niet goed genoeg) worden ondersteund, steun je niet meer op toezeggingen, maar zoek je direct beschikbare alternatieve processen. Dat is lastig. Maar tenzij je kiest voor het laten ontwikkelen van maatwerkoplossingen, zul je altijd concessies moeten doen. Je beslist op basis van de 80/20 regel: als je een oplossing kunt vinden waarmee je 80% van je probleem oplost, dan kun je voor de laatste 20% genoegen nemen met een minder optimale oplossing. En: wat voor ruim 10.000 collega’s goed genoeg is, moet voor jou toch ook op z’n minst werkbaar zijn?

Dit klinkt misschien arrogant uit de mond van een softwareboer. Toch zijn de samenwerkingsverbanden die op deze manier zijn ingestoken, in de praktijk de beste en voor beide partijen de meest bevredigende. Je moet niet op zo’n beklemmende manier van elkaar afhankelijk willen zijn.

We luisteren

Om te waarborgen dat wij als softwareleverancier wel degelijk die zaken bouwen die gebruikers nodig hebben, maken we gebruik van een forum. Iedere klant kan hier terecht met goede ideeën en wensen voor de software. Onze product managers houden deze lijst in de gaten en bij het bepalen van de prioriteiten, gebruiken we deze input.

Wanneer je als klant niet afhankelijk bent van de oplevering van features, zit je veel minder in spanning. Je hebt je processen immers al onder controle. Misschien niet optimaal, maar wel werkbaar. Wanneer wij als softwareleverancier rustig kunnen werken aan uitbreidingen en verbeteringen waar iedereen baat bij heeft, kunnen we kwaliteit leveren waar alle gebruikers meteen iets aan hebben.

We doen wat we kunnen

Wees niet bang dat zonder ‘druk’ vanuit de markt de vaart uit onze ontwikkelingen gaat. Integendeel. We hebben een prachtige roadmap en het kan ons allemaal niet snel genoeg gaan. Daarnaast zijn er de al eerder genoemde ontwikkelingen in de markt. Het gezamenlijk belang van 2.300 klanten vormt een directe aansturing van onze prioriteiten.

We houden je op de hoogte

Natuurlijk hebben we een planning. Dus we laten je weten waar we dit jaar aan werken en wat daarvan de huidige status is. Zo blijf je geïnformeerd en kun je inspelen op nieuwe, beschikbare ontwikkelingen. Ondertussen kun je zelf verder met het standaardiseren van je processen.

Volgens mij is dat een situatie met alleen winnaars.