Maak de business case voor je innovatie

Het is een aloud probleem voor veel developers: de kloof tussen ICT en business. Ze spreken verschillende talen, maar willen allebei innovatie. Mark Heckler (spreker op J-Fall 2016 en IoT Tech Day 2017) reikt de oplossing aan: benoem specifieke voordelen en kwantificeer.

Het lijkt zo simpel en veel developers zullen dan ook zeggen dat ze bedrijfsmanagers allang wijzen op wat er te winnen valt met technologie. Toch is het niet simpel, want de taal- en soms cultuurkloof tussen tech en business is groot. “Ga voorbij de algemene, conceptuele voordelen”, adviseert Mark Heckler. De technisch topman en developer advocate van Pivotal Software houdt developers voor dat ze de specifieke voordelen concreet moeten voorkauwen.

 

Hoe krijg je ze zover?

“Het gaat om business justification.” De specifieke voordelen moeten niet alleen genoemd worden; ze hebben ook uitleg nodig. “Kwantificeer!”, luidt de opdracht, die Heckler geeft. Breng je project in kaart en daarmee help je ook jezelf, legt hij uit. Heckler heeft op de drukbezochte 2016-editie van J-Fall zijn presentatie gegeven. Ondanks de zakelijke insteek is zijn verhaal getooid met een opvallende titel: ‘This stuff is cool, but HOW CAN I GET MY COMPANY TO DO IT? Businessing the S*** out of Transformative Development!’

“Ik heb deze presentatie al jaren willen geven”, geeft Heckler enthousiast aan. Hij liep al geruime tijd met dit idee rond en leurde er sinds begin 2016 mee. Tot voor kort kreeg hij echter maar weinig respons vanuit ICT-conferenties. “Misschien was het té anders?”, peinst Heckler. “Het is niet een tech-presentatie, maar het is wel tech-gerelateerd.” Het probleem was om mensen mee te krijgen. Eigenlijk een meta-zaak, want inhoudelijk gaat Hecklers presentatie ook over het meekrijgen van mensen en dan vooral business-mensen. “Mensen willen verandering, maar ze willen ook vertrouwdheid.”

Wat zijn presentatie betreft, vond afgelopen jaar de omslag plaats, met J-Fall 2016 als voorlopig hoogtepunt. Na de eerdere acceptatie voor een andere conferentie, volgde positieve feedback, en toen kwam het sneeuwbaleffect op gang. “Ik had het bijna opgegeven”, bekent Heckler. Aanvankelijk zaten conferenties kennelijk niet te wachten op zijn zakelijke boodschap voor developers. Terwijl dat toch een misvatting is. “Wie bezoekt er conferenties? De mensen, die willen innoveren”, meent hij.

 

Voor de goede zaak

Developers hebben het inzicht in de nieuwe mogelijkheden van nieuwe, coole technologie. Alleen moeten ze wel de rest van het bedrijf meekrijgen in het omarmen en benutten daarvan. Dit vereist méér dan traditioneel development werk. Het vereist ook ambassadeurschap, projectformulering en tolkwerk; voor business-speak. Dit alles is nodig om de goede zaak vooruit te helpen, pleit Heckler, de goede zaak van technische innovatie.

Want vroeg of laat (en meestal vroeg) zul je je project moeten uitleggen aan de baas. “En die ziet kosten, en hoort tech-babbel.” Aan de developer de opgave om ‘kosten’ te vertalen in ‘investeringen’ die x, y en z opleveren. Heckler geeft een eenvoudig voorbeeld uit zijn eigen ervaring. Een praktijkgeval waarin hij zelf het inzicht heeft opgedaan dat hij nu deelt met anderen.

 

Meten is weten

“Ik had jaren terug te maken met collaboration meetings, die telkens een korte tijd duurden maar wel erg inefficiënt waren.” Want zo kwam de ene collega net te laat, waardoor iedereen ‘even’ moest wachten. En zo was een andere collega wat langdradig, waardoor het korte overleg ietsje uitliep. “Ik ben toen de time-in en de time-out gaan registreren en heb ontdekt dat we ongeveer 9 uur per week eraan kwijt waren. Dat is 20 procent van onze tijd!”

Toen Heckler die harde cijfers aan zijn baas liet zien, was die zó om voor een andere aanpak. Dit was dus niet eens een technisch project, maar simpelweg een kwestie van tijdsbesteding. Natuurlijk is niet alle extra tijd rondom zo’n overleg te beschouwen als verloren tijd, erkent Heckler. “Een deel daarvan is wél nuttig.”

 

Onderbouwen en anticiperen

Het is dus de kunst om de berekening en daarmee de business case niet al te zwart-wit te maken. In wezen moet je anticiperen op mogelijke reacties (ja, ook kritiek), die je voorgestelde project zal krijgen. Denk dus aan tegenargumenten, nadelen en zelfs minder kwantificeerbare elementen, adviseert Heckler. Een minder kwantificeerbaar element is bijvoorbeeld de bonding-tijd tussen collega’s voorafgaand aan een geplande meeting, als je dus wacht op die ene collega, die te laat is.

Maar waarom eigenlijk al deze moeite nemen, om zo zakelijk over te komen en het nut van een project van tevoren uit te stippelen? “In de meeste organisaties is er geen tijd of ruimte om te experimenten”, weet Heckler. Hij doelt daarmee op het gebrek aan niet-toegewezen arbeidstijd, mankracht of bedrijfsmiddelen om onbekende dingen eens uit te proberen. En vergis je niet: een goed idee zónder gedegen onderbouwing komt maar al te vaak over als blinde gok. Zeker in de ogen van een buitenstaander, zoals een business manager, die de ‘tech-taal’ niet spreekt.

De principal technologist van Pivotal draagt twee opties aan, die developers dan hebben: “Óf je verandert van organisatie, óf je verandert je organisatie.” Optie één is ontslag nemen en een loopbaan elders zoeken, bij een bedrijf of instantie dat wel de door jou gewenste experimenteerruimte heeft. Optie twee is je eigen werkwijze wat aanpassen door in business-termen te denken, of in ieder geval in die taal te presenteren.

 

‘Let op je aannames’

Het is dus zaak om een kostenbaten-analyse te doen. Reken je project door. Tegelijkertijd – haast tegenstrijdig – moet je ervoor waken om daarin niet te ver door te slaan. “Pas op: je kunt natuurlijk eeuwig blijven analyseren. Dus je moet jezelf qua tijd inperken. Time-box jezelf op bijvoorbeeld een maand.” Hanteer dus een ontwikkelpijplijn: analyse, onderbouwing, pitch, ontwikkeling en implementatie.

“Let wel op je aannames”, waarschuwt Heckler bij de cruciale fase van analyse en onderbouwing. Zo kan een hogere efficiency, bijvoorbeeld door collaboration meetings te beperken, weliswaar x uur winst opleveren. Alleen valt dat niet regelrecht te koppelen aan het salaris van de betrokken medewerkers of aan de door hun gerealiseerde productiviteit. X uur tijdwinst voor developers ≠ 10 procent lagere salariskosten, of 10 procent meer functionaliteit per opgeleverde release.

Een praktische tip is het aanpassen van je aannames, door ze bijvoorbeeld te halveren. “Dan krijg je medewerking”, legt Heckler uit. Want zo voorkom je hooggespannen, overtrokken of zelfs onhaalbare verwachtingen. Bovendien kan uiteindelijk het geboekte resultaat wellicht nog beter uitpakken dan vooraf ingeschat.

 

Ronsel bondgenoten

Klinkt allemaal als veel werk? Extra werk waar drukbezette developers helemaal geen tijd voor hebben, zeker niet als ze werken in een organisatie waar niet eens tijd is voor experimenteren. Toch? Ook hiervoor heeft Heckler een praktische tip, wederom eentje, die business ten voeten uit is. Doe het niet in je eentje, maar zorg voor medestanders, die dan ook een deel van het onderbouwingswerk voor jou kunnen doen.

Het is geen eenmansactie. “Zelf doe ik het via of met iemand op de afdeling financiën”, vertelt Heckler. “De eerste keer is dat contact wat moeilijk. Maar je vraagt om hun inschatting, hun expertise.” Elke organisatie heeft verschillende manieren en verschillende redenen om te investeren in projecten, in coole technologie en in nieuwe mogelijkheden. De crux is om de investeringsmanier of -reden helder te krijgen en daar dan op in te spelen.

Bij de één gaat het om payback, de return-on-investment (ROI). Bij de ander gaat het om de waarde of meerwaarde, die valt te behalen. “Daarmee kan ik een bondgenoot krijgen in de finance-afdeling.” Zo iemand is niet alleen waardevol voor de initiële inschatting en onderbouwing. Hij of zij helpt ook om je inspanningen te legitimeren of zelfs te promoten. “Stel je voor dat iemand in de lift zegt: Heb je dat gekke IT-idee van Mark gehoord? En de ander zegt: Ja, dat heb ik doorgerekend en het is helemaal geen gek idee.”

 

‘Je moet een polyglot zijn’

Zo dring je dus door tot de business om jouw goede idee voor of met coole technologie te realiseren. Hierbij wil Heckler nog een hardnekkige misvatting ontkrachten. Het is niet zo dat business-mensen niet willen luisteren naar ideeën voor of met coole technologie. “De business luistert wel, maar naar een andere taal. Je moet dus een polyglot zijn, wat je eigenlijk al bent met programmeertalen.” Het is eigenlijk net als met development werk: kies de juiste taal voor de juiste toepassing.

“Uiteindelijk zijn we allemaal problem solvers”, zegt Heckler. Alleen lost de één technische problemen op en lost de ander business-problemen op. Een klassieke ICT-wijsheid is hier van toepassing, vertelt de developer advocate van Pivotal Software. “Ken je gebruiker” en richt je op zijn of haar wereld. Heckler relativeert zijn business-advies aan developers nog wel: “Er is geen magie, dit is geen silver bullet”, die alles oplost. “Maar het helpt wel.”