Communicatie & ICT: 5 tips hoe het beter kan.

Heb jij dat nou ook wel eens? Dat je met een architect of ontwikkelaar zit te praten en dat je na 15 minuten denkt: “Waar GAAT dit over?”. Veel terminologie, en veel uitstapjes. Geef het maar toe, veel IT-gesprekken zijn niet de meest duidelijke, en al helemaal niet voor not-IT stakeholders.

We weten allemaal dat door gebrekkige communicatie veel IT projecten in de problemen raken en zelfs faliekant mislukken. Toch slagen we er telkens weer in om architectuur plaatjes, nieuwe IT projecten of de aankoop van nieuwe technologie te onderbouwen met argumenten die niet door iedereen goed begrepen worden. Sterker nog, [JH2] hoe slechter het gaat met een project, hoe vaker we woorden gaan gebruiken die mensen op het verkeerde been zetten. Combineer dat dan ook nog eens met het dreigement: “Maar we zijn nu al zo ver gevorderd, als we NU de stekker er uit trekken is alles voor niks geweest!” en de volgende IT ramp staat op het punt om uit te barsten…

Ik heb een theorie: Als je het niet goed kunt uitleggen, dan is het geen goed plan.

Dus, een ingewikkeld verhaal gekoppeld aan een complexe architectuur waar alleen collega IT’ers blij van worden ‘voelt’ niet goed. Daarom 5 tips van een IT’er die er zijn beroep van heeft gemaakt om moeilijke dingen simpel uit te leggen. Herhaling is de beste leermeester, dus als de punten je bekend voorkomen dan ongetwijfeld zul je sommigen al eerder langs hebben zien komen.

1. Maak geen complexe zaken. Deze klinkt als een inkoppertje, maar de simpelste oplossingen zijn vaak de beste. Ze zijn meestal niet simpel te MAKEN, maar zijn wel de oplossingen die tevreden gebruikers, het minste onderhoud en de langste levensduur garanderen. En je hoeft geen moeilijke woorden te gebruiken om het uit te leggen. Blijf versimpelen!
   
   
2. Begin met uit te leggen WAAROM je iets doet, dan kun je veel IT terminologie vermijden en spreek je de taak van de gebruiker. We vergeten dat nogal eens en vertellen meteen HOE het gaat werken. Als mensen snappen WAAROM je iets doet kunnen ze zelf veel van de ontbrekende puzzelstukjes invullen, mocht je die vergeten.
   
   
3. Besteed 80% van je energie aan je verhaal en 20% aan de slides of het opmaken van je rapport. Helaas doen we het meestal andersom en vermoeien we onze lezers / toehoorders met veel te veel volle slides en tientallen pagina’s rapport zonder een management samenvatting. Gebruik de defaults van Powerpoint en zet vooral de optie “tekst kleiner maken” niet aan. Jij kunt het echt niet beter dan de vormgevers van Microsoft, LibreOffice, Apple of Prezzi. Bedenk bij iedere IT term of hij echt nodig is.
   
   
4. Gebruik eens een whiteboard in plaats van een slide met een plaatje waar je uren op hebt zitten zwoegen. Oefen je tekening minimaal 10 keer en laat het er uitzien alsof je het voor het eerst, maar foutloos, op papier zet. Dat spoort mensen aan om vragen te stellen en om feedback te geven. Iemand die iets tekent is veel toegankelijker dan iemand die 20 keer klikt om een mooi plaatje op te bouwen.
   
   
5. Dit is misschien wel de moeilijkste van allemaal: Ook al ben jij de beste, slimste en knapste IT Manager, Architect, Ontwikkelaar of Program Manager dan ben je niet automatisch de beste persoon om je plan/voorstel te presenteren. Iedereen heeft zo zijn talenten en de combinatie van briljante IT’er en master presenter zijn zelden in 1 persoon verenigd. Als jij echt wilt dat jouw plan omarmd wordt, moet je misschien wel beslissen dat iemand anders het “verkoop” gedeelte voor zijn of haar rekening neemt. Een stapje opzij doen is vaak een teken van kracht.

Een voorbeeld: Het goed duiden van de noodzaak van een integratie strategie en de daarbij behorende investeringen is voor veel IT’ers in de praktijk nogal ingewikkeld. Al snel verzanden we in gesprekken waar termen als RestAPI, GraphQL, Legacy, koppelingen, integraties, protocollen en iPaaS veel gebruikt worden.
Het WAAROM sneeuwt al snel onder.

Een leeg whiteboard waar je een plaatje tekent waar 1 of twee koppelingen uitgelegd worden zegt vaak meer dan duizend woorden. Want de mensen aan de andere kant van de tafel zien dan meteen dat de 8 velden die nodig zijn om het plaatje Y volledig te krijgen uit 3 verschillende applicaties (waarvan 1 in de cloud en 1 van een externe source) moeten komen. Dat het verkeer tussen die applicaties veilig moet zijn en dat je dus soms gebruik kunt maken van een API (om iets uit de cloud op te halen) en soms van een maatwerk koppeling omdat er aan “de andere kant”  een legacy applicatie staat.

Vergeet alle terminologie en tech-speak en spreek de taal van managers en gebruikers. Verdiep je in hun zorgen en waar zij van wakker liggen en los DIE problemen op. Je zult zien dat er meer begrip, en dus ook meer budget komt.