En CIO med positiv självbild tror sig styra över en it-verksamhet som är i synk med verksamheten, att it-säkerheten är vattentät och att alla pågående projekt kommer att avslutas i tid. Risken är stor att personen ljuger för sig själv.

Det är mänskligt att göra det, eftersom det är enklare att se på världen i ett rosenskimrande ljus, skriver CIO.com.

Här nio vanliga lögner som CIO:er berättar för sig själva.

Lögn 1: It är anpassat till verksamheten

I verkligheten är det få företag som är anpassade till sig själva. Det som ses som anpassning är ofta ett politiskt spel eller i bästa fall en anpassning till en budget. Frågan är om budgeten är anpassad till verksamheten.

Lögn 2: Enda anledning att uppgradera en mjukvara är att en ny version ger mer affärsvärde

Den förklaringen kanske låter övertygande. En CIO som tänker så kan inte bli anklagad för att investera i teknik för teknikens egen skull. Dessutom sparar man pengar.

Men CIO:er som resonerar så har knappast genomlevt några tekniska generationsskiften. Eller så har de blivit skickliga på att skylla ifrån sig. Mjukvaruuppgraderingar ska ses som förebyggande underhåll. Man får betala nu eller betala mycket mer vid ett senare tillfälle.

Läs också: 7 tecken på att affärssystemprojektet går åt pipsvängen

Lögn 3: Vi tar igen förseningarna i det verksamhetskritiska projektet

Så här brukar det gå till: När affärsvärdet för ett projekt är lågt så gör chefer som de gjort sedan kalkylprogrammet uppfanns. De trixar med siffror tills kalkylen går ihop och övertygar sig själva om att de nya antagandena är rimliga. Åtminstone med en rejäl medvind i projektet och en rejäl dos tur.

Men verkligheten är att ju större ett projekt är, desto svårare är det att få grepp om kraven på det. Men det spelar ingen roll att det tar tid att specificera kraven. Det tar man igen senare eftersom kodningen kommer att gå snabbare tack vare ett bra kravarbete. Eller hur?

När det är dags att planera utgår man sedan ifrån avslutningsdatumet för projektet och formulerar en tidsplan som gör att det blir möjligt att klara det. Nu är det projektledaren som trixar med tidsåtgång för olika aktiviteter, tills tidsplanen ser bra ut.

När man till slut förstår att tidsplanen inte kommer att hålla går man in i en förnekelsefas. Smarta projektledare gör två saker nu. Först hoppar de över tester. Sedan söker de ett nytt jobb.

Nu är det dags för en nytillsatt CIO att få stopp på katastrofprojektet. Företrädaren skyller på projektledaren.

Lögn 4: Vi är agila

Många företag har övergett vattenfallsmodellen för systemutveckling, för att i stället använda någon agil metod, eller är på väg att göra det. Men för alla företag som verkligen blivit agila finns det troligtvis ett dussintal som anammat ett arbetssätt som kan beskrivas som ”agilfall”.

Man följer till exempel varje formell punkt i den agila metoden Scrum, men struntar helt i ett agilt tankesätt. Det är skillnad på att bocka av en punkt på en checklista och att faktiskt jobba på det sätt som den punkten beskriver.

En annan variant är att man verkligen har övergett vattenfallsmodellen, men i stället infört kaos i systemutvecklingen. Till glädje för anhängaren av vattenfallsmodellen som tycker sig ha fått vatten på sin kvarn, och som för övrigt ansträngt sig för att sabotera den agila transformationen.

Lögn 5: Vi kör devops

Nej det gör ni inte. Ni är inte ens agila. Kan du inte läsa?

OK, allvarligt talat: Trots all hajp kring devops så vad det inte det arbetssättets förespråkare som uppfann samarbete. Det agila arbetssättet framhävde samarbete långt innan devops tog form, även om det oftast inte innefattade driftspersonal.

Det devops tillför till agila arbetssätt är för det första att utvecklingsteam innefattar driftspersonal, renodlad sådan eller folk som kombinerar olika uppgifter, av rent själviska orsaker. Utvecklare vill inte vänta på att applikationer ska byggas och distribueras.

För det andra att automatisering överallt är en bra idé. Det blir bara dumt att utföra alla steg i en mjukvaruleverans manuellt. För det tredje ska devops innebära att mjukvara alltid kan tas i drift. Det betyder, tyvärr, att den agila metoden Scrum inte alltid passar så bra ihop med devops. Kanban passar bättre.

Lögn 6: Vi kör Itil

Det är kanske petigt att påpeka det, men man kan inte ”köra Itil”. Itil är ett ramverk, vilket de som förstår det förklarar för en apatisk åhörarskara som inte inkluderar företagets CIO.

Itil är en förteckning över arbetsuppgifter som it-folk bör vara bra på. Det beskriver inte hur man ska utföra de arbetsuppgifterna. Det är klokt, eftersom det aldrig finns ett enda rätt sätt att utföra någon av dem.

Lögn 7: Vi har en användarcentrerad kultur

Hör du att de som jobbar med teknisk support pratar med varandra? De utbyter antagligen historier om dumma användare. Det bidrar inte till en användarcentrerad kultur. Det vore bättre med respekt för användarna.

Men det spelar inte så stor roll om det faktiskt finns respekt för användarna. I så fall tror en CIO antagligen att det är hela företaget som är användare. Det är inte så smart, eftersom det leder till tjänster och gentjänster. Och det innebär slöseri med tid och energi, och gräl om it-budgetar.

Det här gäller även om man pratar om ”kunder” i stället för ”användare”. Man borde prata om ”service” i stället. Hur vet man har man har en servicekultur? Om man berättar historier om dumma användare har man det i alla fall inte.

Lögn 8: Vår it-säkerhet är vattentät

Kommer du ihåg det där med agila metoder och checklistor? Problemet med checklistor är att avbockandet av punkter på sådana blir hela jobbet, i stället för ett sätt att kontrollera att jobbet faktiskt blir gjort. Det här gäller inte minst it-säkerhet, när regelefterlevnad (compliance) ofta finns med i bilden.

Den CIO som tror att man har en säker it-miljö har troligtvis fel. Det är troligare att man har en hyfsad säkerhetsnivå om man har en CIO som känner sig osäker på den.

Läs också: Gör inte så här när du byter affärssystem – 5 avskräckande exempel

Lögn 9: Vår styrprocess för it säkerställer att vi bara kör projekt som ger högt affärsvärde

Låt oss titta på det där med anpassning av it till verksamheten igen. Vitsen med en styrprocess (governance) för it är att se till att man bara satsar på värdefulla projekt och aktiviteter. Men styrprocessen i sig har införts av samma personer som inte är anpassade till varandra, till att börja med.

Så förutom att man ska värdera varandras projekt så finns det politik och utbyte av tjänster med i bilden. Dessutom kommer projekt som innebär kostnadsbesparingar att prioriteras framför dem som ger ökade intäkter. Det beror på att man har mer kontroll över kostnadsbesparingar.

Ökade intäkter kräver också att kunder bidrar, vilket de ofta inte gör. De måste övertalas. Det är förstås vettigt att ägna sig åt att göra det, men det är inte alla som gör det.

Slutsatsen

Om du är säker, på någonting överhuvudtaget, så har du antagligen fel. Om du jobbar som CIO och är säker på någon av de här nio punkterna så ska ställa följande fråga till dig själv: Varför?