Varför misslyckas en it-avdelning? Ofta beror det på att den tillämpar något som kallas för ”etablerad praxis i branschen”, vanligtvis av personer som borde veta bättre men inte gör det – kanske för att de aldrig behövt göra jobbet själva.

Från att skaffa interna kunder till att införa interndebitering till att insistera på avkastning på investeringar – allt kan verka rimligt när man betraktar det från tio tusen meters höjd. Men om man tittar närmare upptäcker man att dessa recept för it-framgång snarare är vägar till A-kassan.

1. Kalla alla för ”kunder”

Vill du misslyckas? Se då till att alla på it-avdelningen säger till alla som inte jobbar på it-avdelningen att ”du är min kund. Mitt jobb är att överträffa dina förväntningar”. Eller, ännu värre: ”att göra dig nöjd”.

Anställda som inte jobbar på it-avdelningen är inte kunder. De är it-avdelningens kollegor. De ska behandlas som likställda, i varje fall om man vill att det ska gå bra för företaget som helhet.

Hela idén om interna kunder försätter it-avdelningen i en underordnad ställning. Det leder till att it-avdelningen måste hålla kollegorna på gott humör, vare sig detta är meningsfullt för verksamheten eller inte. För att inte tala om ifall det får företagets verkliga kunder att köpa fler produkter och tjänster.

2. Skriva tjänstenivåavtal och se dem som kontrakt

Vill du ställa till skada? Upprätta då formella tjänstenivåavtal, insistera på att dina ”interna kunder” skriver på dem och behandla sedan avtalen som kontrakt.

Och om du verkligen vill att it-avdelningen ska misslyckas, börja tvista om ifall du har uppfyllt tjänstenivåavtalet varje gång en ”intern kund” (det där ordet igen) antyder att it-avdelningen inte gör det den ska göra. Det är ett lysande sätt att hålla packet på avstånd.

Men om du i stället vill nå framgång bör du komma ihåg att relationer bygger på förtroende och att förtroende inte uppstår om du inte ser dina kollegor som riktiga människor. Om de gillar dig så kommer de att samarbeta med dig för att rätta till eventuella fel. Syftet med kontrakt är inte att definiera relationer – det är att definiera vad som ska hända när det saknas förtroende och något blir fel.

3. Skämta om dumma användare

Du har säkert hört dem. Historier med poänger som ”tippex på bildskärmen” eller ”vänta lite här – du har strömavbrott och du undrar varför datorn inte startar” eller ”han fattade inte att det fanns text nedanför kanten” (skrockande).

Skratta när andra på it-avdelningen berättar dem, särskilt om det görs med namns nämnande. Om du vill vara säker på att it-avdelningen misslyckas, berätta sådana skämt själv. Då blir det känt att varken du eller någon annan på it har respekt för andra människor.

4. Börja med interndebitering

Detta är ett förträffligt sätt att avskräcka från användning av it: inför interndebitering. Och inte vilken interndebitering som helst. Det ska vara utförliga räkningar som i detalj redovisar vad varje kostnadsställe har dragit på sig, från cpu-cykler till datalagring i serverhall respektive molnet (separat, givetvis – per kilobyte) till utvecklartimmar och samtal med hjälpdesken, räknat per påbörjad tiominutersperiod.

Inget befrämjar samarbete som att bråka om räkningar som handlar om vilket av företagets konton som ska bära en kostnad.

5. Insistera på avkastning

Vill du vara säker på att viktiga projekt inte blir finansierade? Insistera då på att it-styrningsprocessen ska förutsätta klar och tydlig ekonomisk avkastning på investeringen. På så sätt kommer it-systemet sakta men säkert att föråldras. Samtidigt får teknik som skulle kunna bidra till att verksamheten fick bättre resultat inga pengar. Projekt som skulle höja kundnöjdheten – sådant som ökad försäljning kombinerat med sänkta kostnader för försäljning, fast på sätt som it-avdelningen inte kan bevisa – blir utskrattade i hörnrummet, liksom den som la fram dem.

6. Skriva kontrakt för it-projekt

Vill du veta en formel för störda relationer mellan it-avdelningen och verksamheten? Definiera projekten i termer av mjukvaruleveranser så att it-avdelningen har gjort sitt jobb när mjukvaran uppfyller de uppställda kraven och motsvarar specifikationerna.

Så när några från verksamheten klagar på att mjukvaran inte gör vad de önskar att den ska göra så är du i din fulla rätt att hävda att mjukvaran gör exakt vad den ska göra – den motsvarar ju specifikationerna, eller hur? Och om det argumentet inte räcker, om projektet inte svarar mot kravspecen, så kan du hävda att kravspecen var fel. Och vilka beror det på? Verksamhetscheferna som skrev på, förstås.

Du kan också göra något som fungerar. När du namnger dina projekt definierar du vart och en av dem i termer av verksamheten (”högre effektivitet i försäljningen”), inte i termer av mjukvara (”installera Salesforce.com”).

7. Utse projektsponsorer

Det är allmänt känt bland projektledare att varje projekt måste ha en sponsor inom verksamheten för att det ska ha en chans att lyckas. Men vill du bli säker på att ett projekt misslyckas? Utse en.

Sponsorer – riktiga sponsorer, inte SINOer (”sponsors in name only”) vill från hjärtat att deras projekt ska lyckas, är beredda att ta risker om det behövs för att projekten ska lyckas och riskerar sina namn och sina anseenden när det gäller projektens affärsnytta. Tror du att någon som har UTSETTS till sponsor gör allt detta? Inte jag heller.

8. Spika en molnstrategi

Ett fantastiskt sätt att garantera it-fiasko: fastställ en strategi för molnet. På så sätt spänner du vagnen framför hästen. Du vet att du måste vara i molnet. Så målet för strategin är att se till att det händer.

Vad du än gör, tänk inte utanför den ramen. Överväg inte en teknisk funktionstjänst, definierad i termer av vad som ska utföras. För om du gör det så kan du förledas att tro att det är tjänster som du behöver, och att molnet KAN vara ett sätt att anskaffa några av dem.

Regeln är gammal: form följer av funktion. Tjänster är funktioner. Molnet är en av flera tänkbara former som de tjänster du behöver kan ta. Undvik att tänka i de banorna om du inte vill att it-avdelningen ska bli framgångsrik. Om du vill det är det obligatoriskt.

9. Köra agilt. Köra i låglöneländer. Göra båda på en gång

Agila metoder har mycket som talar för sig. Men en förutsättning för framgång är en hög nivå av informell medverkan av slutanvändare. Kurskorrigeringar ska vara små, men ske ofta. Utvecklarna ska se framsteg varje dag och användartestning ska ske dagligen.

Utkontraktering till låglöneländer har en sak som talar för sig: lägre timkostnad för arbetskraft. Men vad som inte talar för det är att det inte blir någon högre grad av medverkan av slutanvändare. Vilket är en grundförutsättning för agilt.

Lägg till det många timmars tidsskillnad, språkproblem, kulturskillnader och att alla dialog inskränks till vad som kan skötas med videokonferenser så blir det inte mycket kvar av agilt.

Man kan få det att fungera, men det är inget för nervöst lagda, och det är definitivt inget för it-avdelningar som är nybörjare på agilt.

Vill du köra agilt? Vill du köra i låglöneländer? Välj en.

10. Avbryta avbrott med avbrott

Nästa steg mot garanterat misslyckande för it-avdelningen är att insistera på att alla ska göra flera saker på en gång. Det är ju något bra, eller? Vad det verkligen innebär är att man sänker produktivitet och kvalitet samtidigt som man ökar stressen med att få mer uträttat.

Varje gång du frestas att be någon att sluta upp med vad de gör och i stället göra något annat, kom ihåg: människor kan inte göra flera saker på en gång. Det bästa de kan göra är att växla fram och tillbaka mellan olika arbetsuppgifter. Varje gång de gör det slösar de tid på den mentala omställningen, och ju mer koncentration som en uppgift kräver, desto mer tid slösar de på omställningen.

Om du vill att it-avdelningen ska gå bra? Låt folk avsluta det som de jobbar med innan de sätter igång med något annat.

11. Bolla med många projekt

It-avdelningen kommer aldrig att ha nog med personal för att klara allt som alla vill ha. Därför bör du göra allt du kan för att leverera det ändå. Sätt igång massor med projekt och flytta medarbetare fram och tillbaka mellan dem.

Gör så om du vill att projekten ska ta längre tid, kosta mycket mer och leverera undermåliga resultat.

Om du vill att din it-avdelning ska få gott rykte ska du etablera denna regel: Varje projekt som inleds ska vara fullt bemannat från start. ”Fullt bemannat” betyder att projekt aldrig ska vänta på att en medarbetare blir ledig för att delta.

Gör så, så kommer alla projekt att bli klara innan ett enda projekt hade blivit klart om du hade försökt bolla alla på en gång.

12. Utrota skugg-it

Det är helt klart att när verksamhetsavdelningar skaffar egen it så kan det hända dåliga saker. Det kan synas vara ett övertygande argument mot skugg-it, men det är bara en tredjedel av historien. Den andra tredjedelen: verksamheten börjar med gör-det-själv-it därför att it-avdelningen inte har nog mer personal för att lösa de (oftast) små problem som skugg-it löser. Vilket gör att it-avdelningen hamnar i den olyckliga situationen att behöva tvinga alla att göra allting i Excel, trots att det finns bättre alternativ.

Det var den andra tredjedelen. Den tredje? Lycka till med att utrota skugg-it. Det är oerhört svårt bara att upptäcka att verksamheten använder molnbaserade applikationer. Och om it-avdelningen ändå skulle lyckas med att utrota skugg-it? Då bllr it-avdelningen Dilberts Mordac: ”Jag är Mordac, förhindrare av informationstjänster, och jag är odödlig!”

13. Säg nej eller ja, vad det än gäller

Det sista, och bästa, sättet att förvissa sig om it-misslyckande är att svara ja eller nej, oavsett vad frågan gäller. Svara nej, så riskerar du en relation. Svara ja så har du gett löften som du inte kan hålla, eftersom du och alla andra redan är fullt upptagna inom överskådlig framtid.

Rätt svar om du vill ha framgång är i stället: ”Vi kan göra det. Det här är vad som krävs.”

Det finns en orubblig regel för önskemålshantering. Den gäller vare sig det gäller projektomfång, förbättring av program eller att skaffa en bärbar dator åt någon som egentligen inte ska ha någon. Regeln är: Ingenting är nånsin gratis.

Säg inte nej. Säg inte ja. Beskriv vad du måste göra för att uppfylla önskemålet. Då kommer det att följas av ett samtal, inte av ett gräl.

Mycket bättre.