02

Apr

Bimodal IT, vergeet het belangrijkste niet!

IT management is een trendgevoelig vak. Om de zoveel tijd is er een nieuw thema dat hét hot topic van IT managementwereld wordt. Bimodal IT is tegenwoordig hét nieuwe buzzword in de wereld van IT management en -consultancy. Iedere zichzelf respecterende adviseur stort zich vol overgave op dit hip & trendy thema. Governance- en procesoptimalisatie, architectuur, agile, devops, pace layers en zelfs creatieve varianten als trimodal IT worden uit de kast getrokken om bimodal IT problematieken op te lossen. Ik ben sceptisch, ik zie de oplossingen voor de eerdere hot topics te vaak in de praktijk net niet écht uit de verf komen. Datzelfde verwacht ik voor bimodal IT. Hoe kan dat toch, en wat is er dan nodig om het wel te laten werken? Mijn stelling: het begint met de mindset.


Al vele jaren begeleid ik IT organisaties naar vruchtbare samenwerking die daadwerkelijk resulteert in een betere dienstverlening voor hun klanten. Al die tijd was er al een continue wrijving tussen de progressieve en de conservatieve IT’ers. IT organisaties worden geacht hun informatiesystemen “het gewoon doen”, laten we dat “Rock solid IT” noemen. Tegelijkertijd word IT geacht op hoog tempo business innovaties te ondersteunen met innovatieve IT oplossingen, er wordt gedacht in dagen of weken in plaats van maanden of jaren. Laten we dit “fluid IT” noemen.

Wij consultants doen ook bij bimodal IT waar we goed in zijn, we zetten er processen, governancestructuren en tools tegenaan. Is nodig, dekt de lading, sluit aan bij de behoefte en, laten we eerlijk zijn, het verkoopt lekker. En toch ben ik bang dat dit ook nu weer net niet genoeg is om het écht goed uit de verf te laten komen.

Kijk eens terug naar wat eerdere IT management hot topics: CobIT, CMM, regie, BITA  etc. Niets dan goeds daarover. Maar zeg eens eerlijk, hoe groot is de focus op die toenmalige hot topics nu nog? En in welke mate hebben ze uw toenmalige problemen daadwerkelijk opgelost? Wat gebeurt er nu met de stukjes van dat probleem die nog steeds bestaan? Ik zie te vaak de aandacht op geïmplementeerde oplossingen verzwakken zodra er weer een nieuw hot topic is, met als resultaat: terugvallen in oude patronen.

Zo zie ik het ook met bimodal IT nog wel gebeuren. We gaan en masse agile, devops, pace layers, transitiemanagement en wat al niet meer invoeren. Ik denk dat het nodig is, maar niet genoeg.

Ik denk dat als de focus straks van bimodal IT af gaat de oplossing niet geborgd is omdat er steeds maar weer dat ene onderdeel verwaarloosd wordt, de factor mens. Die ene factor die niet in modellen te passen is. Die factor die er met zijn zelfdenkend vermogen, eigen inzichten en belangen telkens weer voor zorgt dat de mooiste papieren oplossingen in de praktijk steeds weer teleurstellen.

Hoe dit dan aan te pakken? Laten we eens beginnen met de twee belangrijkste stappen: erkennen van het gezamenlijk doel en onderlinge afhankelijkheden van de betrokken teams en eens kritisch kijken naar de houding en gedrag die we richting elkaar vertonen.

Stap 1: Erkennen één gezamenlijke doelstelling en onderlinge afhankelijkheid
Als we het zo plat mogelijk slaan is de essentie van een team terug te brengen naar twee noodzakelijke ingrediënten: een gezamenlijk doel en een onderlinge afhankelijkheid. Als een van die ingrediënten mist ontbreekt de intrinsieke drive van de betrokken medewerkers om écht als een team te werken en ontstaat het gevaar voor denken vanuit de eigen verantwoordelijkheden en belangen.

Een IT organisatie die bimodal IT wil leveren heeft één taak: leveren van passende IT diensten die de klant in staat stellen hun business te doen. Eigenschappen van die dienstverlening zijn onder andere flexibiliteit, veiligheid en stabiliteit. Het zijn die eigenschappen die op gespannen voet met elkaar staan, het gezamenlijke doel blijft echter eenduidig.

Waarom zien we dan steeds weer dat onderdelen van die IT organisatie toch hun eigen taak verkleinen? De projectorganisatie blijft zich richten op flexibiliteit en de beheerorganisatie blijft zich richten op veiligheid en stabiliteit. Niet zo raar, daar worden de teams immers op aangestuurd en afgerekend, de kloof blijft in stand. De klant blijft ondertussen zowel “rock solid IT” als “Fluid IT” verwachten, en de CIO dient dat maar te realiseren. De CIO dient zijn verschillende teams in lijn te krijgen met de bimodal IT uitdagingen.

Denk eens na over de gevolgen van verschillende teams die allen hun eigen heldere, afgebakende, opdracht met rollen, taken, bevoegdheden en verantwoordelijkheden hebben zonder op elk moment van de dag te beseffen dat hun taak pas goed volbracht als er zowel rock solid als fluid IT geleverd is aan de klant? Wat gebeurt er als deze teams niet volmondig erkennen dat ze afhankelijk zijn van elkaar om de klus goed te klaren? Wat doet dat met de drive om daadwerkelijk samen te werken met de andere teams die een ander taakgebied hebben? Juist, teams gaan hun eigen verantwoordelijkheden nog strakker afkaderen, doen wat zij zelf moeten doen en vooral de vinger te wijzen naar de andere teams die de zaak vertragen of anderszins in de war sturen.

Dit besef zie ik vaak naar de achtergrond verdwijnen. Teams focussen op wat ze binnen hun eigen directe invloedssferen kunnen realiseren, en de rest gaat minder soepel. Herkenbaar?

Als we hebben erkend dat de verschillende teams bij dienen te dragen aan één gezamenlijke doelstelling en dat ze daarvoor van elkaar afhankelijk zijn, zijn we klaar voor de volgende uitdaging: houding en gedrag.

Stap 2: Aanpassen houding en gedrag

Project: “Beheer, deze projectwijziging moet met spoed geïmplementeerd worden”

Beheer: “Je komt er weer rijkelijk laat mee aanzetten project, maar goed. Ik heb wel complete changedocumentatie nodig, ik zie geen risico- en impactanalyse en ook de implementatiescripts heb je niet meegeleverd”.

Project: “Dit soort changes hebben we al honderd keer gedaan, dat gaat ook deze keer wel goed. Kom op, voer hem nu maar gewoon door, het is belangrijk anders loopt het project uit!”

Beheer: “Sorry, eerst de formaliteiten, dan kijk ik verder”.

Project: “Dat is onacceptabel, ik ga escaleren!”

Directeur: “Kom beheer, die change is nu echt nodig, implementeer hem maar gewoon!”

Beheer: “OK….”

Directeur: “Het systeem doet het niet!”

Beheer: “Ja, dat kan ik me voorstellen, die projectwijziging klopte voor geen meter, die heeft nogal wat  fouten veroorzaakt”

Directeur: “Los het snel op, de business ligt alweer stil, ik wil van mijn IT op aan kunnen, daar ben jij verantwoordelijk voor!”

Beheer: “OK…”

 

Herkenbaar? Hoe zou dit zijn?

Project: “Beheer, we dreigen uit te lopen met het project, maar de business heeft die nieuwe functionaliteit per sé morgen nodig anders kan die marketingcampagne niet op tijd live. Wat heb je van mij nodig om deze wijziging vanavond nog zo goed mogelijk te kunnen implementeren?”.”.

Beheer: “Even kijken, de documentatie is bijna compleet, alleen nog de risico- en impactanalyse en de implementatiescripts nog”. Wacht even, van die laatste heb ik nog wel een voorbeeld uit het vorige project, heb je daar wat aan? En o ja, we zien het “spoedje-gebak” morgen wel tegemoet hè?! J”.

Project: “Dank je beheer, doe ik meteen even, houd jij vanavond wat mensen stand-by? Het gebak komt eraan J

Beheer: “Tuurlijk, komt goed.”

Project: “Beheer, we hebben een probleem met dit risico, wil je even meedenken hoe dat te tackelen?”

Beheer: “Ja hoor. Die hebben we eerder al eens gehad, met dit servicepack is dat geen probleem meer”.

Project: “Dank je, als we die erbij doen kunnen we live, toch?”

Beheer: “Klopt, doen we!”

 

Een utopie? Laat ik zo’n idealist zijn die denkt van niet, en die dit in de praktijk al vaker gezien heeft. Wat maakt dat dit geen standaard gedrag is en dat de eerste conversatie herkenbaarder is?

Het begint zoals gezegd bij de beleving van “een team, één gezamenlijk doel en erkennen van de onderlinge afhankelijkheid.

Dan is er nog de aansturing van de teams. Zo lang projectteams alleen maar worden afgerekend en aangestuurd op doel, tijd en middelen, zullen ze hun focus richten op hun eigen verantwoordelijkheidsgebied. Beheer zal sneller in de valkuil van bureaucratie en remmende factor stappen.

Dit is redelijk eenvoudig aan te passen. Verbreed de opdracht en verantwoordelijkheid van beide teams. Stuur ze aan op hun verantwoordelijkheid voor stabiel en flexibel en reken daar ook op af in plaats van alleen op de huidige, afgekaderde team KPI’s.

Als laatste is het mogelijk dat niet iedereen de juiste competenties heeft om buiten hun eigen teamopdracht te denken en te handelen. Daar is training en eventueel coaching een probaat middel voor. Inzichten uit onder andere Lencioni, de roos van Leary, dramadriehoek / winnaardriehoek en transactionele analyse (google maar) kunnen hier een goede basis vormen voor de ontwikkeling van de teams en de teamleden.

Op deze manier leg je op een relatief eenvoudige wijze, en zelfs met beperkte tot geen investeringen een stevige fundering voor blijvend succesvolle bimodal IT.

Ik wens u veel rock solid en fluid IT toe!

Reacties (0)


Reageer




Toegestaande tags: <b><i><br>Voeg een nieuwe reactie toe:


Deel dit artikel: