12 manieren waarop de IT-afdeling faalt

14-06-2017

IT-organisaties gaan soms flink op hun smoel, maar hoe komt dat nu? Dat ligt vooral aan de best practises die iedereen wil volgen, maar die slechts wegen zijn naar gigantisch falen.

Hier 12 voorbeelden.

Waardoor falen IT-organisaties? Vaak is de oorzaak het gebruik van (zoals het wordt genoemd) "industry best practises" door mensen die beter zouden moeten weten, maar dat blijkbaar niet doen. Waarschijnlijk omdat ze er zelf nooit mee aan de slag zijn gegaan.

Het benoemen van interne klanten, het formaliseren van een intern verdienmodel (interne ROI): het klinkt allemaal plausibel als je zelf mijlenver afstaat van de praktijk. Maar als je zelfs maar ietsje beter nadenkt weet je dat dergelijke (theoretische) praktijken niet het recept vormen voor succes, maar een formule voor je falen.

We geven op de volgende pagina's een aantal voorbeelden uit de theoretische 'best practises' die voor de insider duidelijk de weg naar mislukking inslaan. Dus leer hiervan en verban dit uit je dagelijkse praktijk.

1. Vertel iedereen dat zij jouw klant zijn

Je wilt graag op je bek gaan? Zorg er dan voor dat iedereen van IT aan iedereen buiten IT vertelt: "Jij bent mijn klant. Mijn taak is jouw verwachtingen te overtreffen." (of erger: "jou gelukkig te maken").

Werknemers buiten de IT zijn niet de klanten van IT. Ze zijn jullie collega's, met wie je samenwerkt als gelijken, als je wilt dat er iets gaat gebeuren dat goed is voor het bedrijf als geheel.

Het legitimeren van het idee van 'interne klanten' zet IT in een ondergeschikte en dienende positie, waar iedereen binnen IT zijn collega's blij moet maken, of dat nu goed is voor het bedrijf of niet, en of het nu de echte klanten van het bedrijf aanmoedigt om meer producten of diensten af te nemen.

2. Stel SLA's vast en behandel deze als contracten

Wil je wat schade aanrichten? Stel dan formele SLA's vast, sta erop dat je 'interne klanten' die ondertekenen en behandel deze SLA's als contracten.

En als je echt wil dat IT onderuit gaat, ga dan de discussie aan of je voldoet aan je SLA's op het moment dat een 'interne klant' (daar heb je dat woord weer) klaagt dat IT niet doet wat het moet doen. Dat is een uitstekende manier om de relatie koud te houden.

Als je een voorkeur hebt voor succes, dan realiseer je je dat relaties gebouwd zijn op vertrouwen, en dat dat vertrouwen er niet is voordat je je collega's echt ziet als echte mensen, die als ze je mogen met je willen samenwerken om te repareren wat er stuk is, en dat de bedoeling van contracten niet ligt in het vaststellen van relaties - maar om te defini√ęren wat er gebeurt als er geen vertrouwen is en er iets flink mis gaat.

3. Lachen om domme gebruikers

Je kent ze wel. De klassieke verhalen over typex op het beeldscherm, of "Hoor ik dat nu goed, jullie hebben een stroomstoring en je begrijpt niet waarom je PC niet opstart?".

Lach lekker mee als andere IT-medewerkers zulke verhalen vertellen, vooral als man en paard worden genoemd. Of als je zeker wilt weten dat het voor IT helemaal mis gaat, vertel ze dan zelf. Op die manier gaat het verhaal de ronde doen dat jij of wie dan ook in IT totaal geen respect hebt voor anderen. Dat zal ze leren.

4. Hanteer kostendoorberekening

Hier is een geweldige manier om het gebruik van IT te ontmoedigen: hanteer kostendoorberekening. En niet zomaar een doorberekening, maar zorgvuldig samengestelde die facturen opleveren waarin elke kostencategorie gedetailleerd wordt benoemd, zoals CPU-cycles, SAN- en NAS-opslag (apart vermelden natuurlijk), ontwikkeluren en helpdeskhulp.

Niets moedigt samenwerking meer aan dan twisten over de juistheid van de rekeningen die moeten bepalen welk interne potje het geld moet herbergen.

5. Sta op ROI

Wil je ervoor zorgen dat belangrijke projecten geen investering meer krijgen? Sta er dan op dat het IT-governanceproces een duidelijke, haalbare financi√ęle ROI vereist. Door dat te doen zullen alle verbetertrajecten smoren. Technologie die de commerci√ęle afdelingen sneller betere resultaten laten behalen krijgt geen funding en projecten die de klanttevredenheid versterken (waardoor de omzet stijgt en de verkoopkosten dalen - alleen niet op zo'n manier dat IT het kan bewijzen) worden geridiculiseerd bij de koffieautomaat, samen met degene die dat heeft voorgesteld.

6. Kaap IT-projecten

Wil je een formule voor het disfunctioneren van de IT/business-relatie? Definieer dan projecten als zijnde software-oplevering zodat de taak van IT gedaan is als de software tegemoet komt aan de vooraf gestelde requirements en de specificaties.

Op die manier kun je, als het zakelijk management klaagt dat de software niet doet wat zij willen dat het doet, altijd terugvallen op het argument dat het precies doet wat het zou moeten doen, omdat het aan de specificaties voldoet. En als dat niet werkt, en het project komt niet tegemoet aan de requirements, kun je tegenwerpen dat de requirements verkeerd waren. En wiens schuld is dat? De zakelijke manager die die requirements heeft goedgekeurd, natuurlijk.

Of je kan doen wat wel werkt: begin met hoe je je project gaat noemen en definieer elkeen in hetgeen het resultaat moet zijn ("verhoog de effectiviteit van sales") in plaats van welke software het moet zijn ("implementeer Salesforce.com").

7. Stel projectondersteuners aan

Het is algemeen bekend in de kringen van projectmanagers dat elk project een ondersteuner van de business moet hebben, want anders is er weinig kans op succes. Maar wil je dat een project faalt? Stel er dan eentje aan.

Ondersteuners - echte ondersteuners, geen papieren - willen hun project tot in het diepste van hun hart succesvol afronden, en zijn bereid risico's te nemen om dat succes te behalen, en zetten hun naam en reputatie op het spel. Denk je dat iemand die wordt aangewezen als ondersteuner die dingen gaat doen? Dat denk ik ook niet.

8. Stel een cloudstrategie vast

Hier is een mooie manier om tot IT-falen te komen - stel een cloudstrategie vast. Je kan dan namelijk al direct het einddoel vaststellen. Je weet dat je in de cloud moet zijn, dus het doel van de strategie is om dat voor elkaar te krijgen.

Wat je ook doet, denk niet verder dan dat. Overweeg geen gemanaged technische architectuur, gedefinieerd in het leveren van diensten. Immers, als je dat doet dan ga je wellicht geloven dat het die diensten zijn die je nodig hebt, en dat de cloud mogelijk een manier is om enkele van die diensten te leveren.

Het is een oude wet: vorm volgt functie. Diensten zijn de functies. De cloud is één vorm die sommige van de diensten kunnen aannemen. Probeer die denkrichting te vermijden, behalve als je IT succesvol wilt laten zijn. In dat geval is het verplicht.

9. Word agile. Offshore. Doe beide tegelijk

Agile methodologie√ęn hebben veel voordelen. Een voorwaarde is een hoge mate van informele betrokkenheid van gebruikers zodat koerswijzigingen veel, klein en snel worden toegepast, ontwikkelaars elke dag vooruitgang zien en het testen van de gebruikersacceptatie dagelijks wordt gedaan.

Offshoring heeft één voordeel: lagere arbeidskosten per werkuur. Wat het niet brengt is elke mogelijkheid om een hoge mate van informele betrokkenheid van de gebruikers, waar agile afhankelijk van is, te bereiken. Combineer het enorme tijdsverschil, de taalbarrière, cultuurkloof en interacties die beperkt zijn vanwege de limieten van webconferentie, en je weet dat agile nogal uitdagend kan zijn.

Het is mogelijk om het te laten werken, maar je moet geen zwak hart hebben, en het is zeker niets voor IT-organisaties die nieuw zijn in agile. Je wilt agile zijn? Je wilt offshoren? Kies er één.

10. Onderbreek onderbrekingen met onderbrekingen

De volgende stap in het versnellen van het falen van IT is erop te staan dat iedereen aan het multitasken gaat. Dat is immers een graag geziene eigenschap, niet waar? Wat het echt betekent is dat je de productiviteit en de kwaliteit vermindert terwijl je de stress verhoogd doordat iedereen van alles en nog wat probeert te doen en af te maken.

Als je de neiging voelt opkomen iemand te vragen te stoppen met hetgeen ze aan het doen zijn en iets anders aan te pakken, onthoud dan: mensen kunnen niet multitasken. Het beste wat ze kunnen doen is heen en weer schuiven tussen de ene en de andere taak. En elke keer verkwisten ze tijd doordat ze zich geestelijk weer moeten herinrichten, en hoe meer concentratie een taak vergt, des te meer tijd wordt er verkwist. Wil je succes met IT? Laat mensen dan afmaken waar ze aan werken voordat ze naar de volgende taak gaan.

11. Veel projecten om handen

IT heeft nooit genoeg medewerkers om ieders wensen in te willigen, dus is het logisch om dat toch te proberen door het starten van een heleboel projecten en medewerkers continu te verschuiven daarin. Als je tenminste wilt dat al die projecten een stuk ;langer duren, veel meer kosten en ondermaatse resultaten opleveren. Als je wilt dat IT een goede reputatie opbouwt, volg dan deze regel: elk project dat wordt opgestart wordt volledig bemenst, en dat betekent dat het project nooit hoeft te wachten totdat een teamlid beschikbaar komt om eraan te werken. Doe dat en elk project zal afgerond zijn voordat elk ander project zou zijn afgerond als je al die ballen tegelijk in de lucht wilt houden.

12. Zeg nee of ja, ongeacht de vraag

De laatste en beste manier om ervoor te zorgen dat IT faalt is door ja of nee te zeggen, ongeacht de vraag. Zeg nee, en je beschadigt je relaties. Zeg ja, en je maakt beloften waaraan je je niet kan houden omdat jij en ieder ander jouw agenda al volledig hebben ingevuld. Het juiste antwoord als je succesvol wilt zijn is, "Dat kunnen we doen en daarvoor is dit nodig." Er is een onschendbare regel in het omgaan met verzoeken, of dat verzoek nu een verandering in de scope van een project is, een verbetering van software of het leveren van een laptop aan iemand die daarvoor niet in aanmerking komt: niets is ooit gratis. Zeg geen nee. Zeg geen ja. Leg uit wat je moet doen om aan het verzoek te kunnen voldoen. Wat daarop volgt is eerder een gesprek dan een discussie of twist. Veel beter.

CIO.NL  Bob Lewis

Index