<<åter

Du borde få ut mer av Dina IT-investeringar

 (Conny Leinstedt, Kunskapsbrev Adera2000)

80 procent av alla IT-investeringar är direkt bortkastade. Efter två år används bara hälften av det som från början fungerade.

Siffrorna kommer från ett flertal amerikanska undersökningar och innebär att bara en tiondel av IT-investeringarna verkligen omsätts till nytta. Och även om undersökningarna är amerikanska så finns det väl ingen anledning att tro att det är annorlunda här, eller?

Försiktig matematik pekar då mot att du i vart fall borde få ut 2 till 3 gånger så mycket mer användbarhet ur dina IT-investeringar än vad som idag är fallet.

Varför blir det då så här? Ja, bland många orsaker tror jag mig speciellt kunna urskilja tre centrala:

bullet

Bristen på tillräckliga analyser i rätt tid.

bullet

Bristen på förmåga och insikt att i tid inse och bearbeta de naturliga attitydfrågor som alltid kretsar kring införandet av något nytt.

bullet

Drömmen om ett Utopia och möjligheten till den en gång för alla färdiga och kompletta ”Big Bang-leveransen”.

Rätt analys i rätt tid

”Här finns inga problem, det är bara att köra!”

Entusiasm och glädje över att äntligen få starta med ett nytt och rejält projekt leder inte sällan till misstag. Arbetet går snabbt in på detaljer och ingen har någon egentlig överblick, helt enkelt för att det inte finns någon struktur i projektet.

Detta är ett beteende som inte är så lyckat. Allt som oftast innebär det att man får tvärvända 180 grader och börja om ifrån början. Det lite märkliga i sammanhanget är att detta gör man inte bara en, utan ofta gång på gång – allt i tron att det är på detta sätt IT-utveckling går till.

 

Rätt Analyser underlättar möjligheten att i tid lägga ut rätt kurs.

Att genomföra analyser behöver inte vara komplicerat. Det finns ett antal enkla analyser som lätt och tydligt ger den eftertanke som behövs för att projektet skall kunna drivas på ett korrekt sätt:

bullet

Business Case. Vad är den förväntade nyttan med projektet? Gärna uttryckt i pengar, det verkar bli mycket tydligare då.

bullet

Processanalys. Vilka av verksamhetens processer kommer att vara berörda av pro­jektet, såväl ur ett givande som i ett mottagande perspektiv?

bullet

Målanalys. Vilka mål har vi satt upp för projektet, vilka framgångsfaktorer kräver dessa mål och vilka hinder ser vi på vägen, som vi i god tid måste tackla?

bullet

Begreppsanalys. Avgränsar området av begrepp och termer som projektet skall fokusera.

bullet

Analys av efterkalkyler från tidigare projekt. För du gör väl efterkalkyler, eller hur?

Detta är bara exempel ur ett axplock av möjliga analyser som kan vara vettiga att göra. Allt för att skapa trygghet inför beslut som skall leda till att gjorda IT-investeringar ger rimlig och önskvärd användbarhet.

 

Analyser behöver inte innebära vare sig utdragna eller långran­diga åthävor

”Analyser tar onödig tid, kostar pengar och försenar projektet. Dessutom ger den en massa resultat vi inte vill ha.”

I ren desperation och rädsla för onödiga kostnader väljer många att visa sin handlingskraft genom att helt sonika hoppa över analysfasen. Men, precis som talesättet lyder, är genvägar ofta senvägar. Allra tydligast blir detta när det är dags att dra i nödbromsen, ta ett rejält omtag och ge projektet en annan inriktning – eftersom den påbörjade visade sig vara fel eller otillräcklig. För att inte tala om när detta upprepas kanske både andra, tredje och fjärde gången i projektet, som i värsta fall kanske till och med läggs ner.

Varför nödvändiga analyser anses resurs- och tidskrävande har jag svårt att förstå. Tvärtom går det att med små, men rätta, medel nå oanade insikter på kort tid. Kanske en analysinvestering på ett par veckor kan korta ner projekten med månader, halvår, ja ibland till och med år. Vågar du verkligen låta bli att utnyttja en sådan häftig utväxling av investerade medel?

 

Bädda i tid för mottagandet

”Vad är det hör för skräp? Fungerar det inte bra som det är? Måste vi lära oss en massa nytt nu?”

Inget system, oberoende av hur funktionellt och tekniskt välbyggt det än är, kan kompensera en avog inställning och trist attityd från dem som skall använda det. En mottagaranalys kommer snabbt att visa både hur mycket och vilken typ av utbildning som behövs. Vad som kanske är ännu intressantare är att man också kan hitta de variationer i behov som finns. Det går då att separera den utbildning/information som är generellt nödvän­dig för alla i sina aktuella yrkesroller från den som är individbe­roende och behövs som beroende på individens enskilda bakgrund, förutsättningar, etc. Målet och meningen med förbättringen är ju att ALLA skall bli effektivare som individer i att utföra sina yrkesroller i verk­samhetens olika processer.

 

Börja i tid

Jag tycker det är mycket märkligt hur sent man i allmänhet börjar fundera över hur det så tekniskt väl genomtänkta och elegant byggda systemet skall implementeras mentalt. Ofta har man inte haft tid att börja tänka på detta förrän tiden drastiskt närmar sig för den tekniska implementationen. Att skapa rätt attityder tar tid – lång tid. Ett alltför snabbt och drastiskt införande av nyheter i en organisation bemöts nästan alltid negativt. Du har därför allting att vinna på att börja mottagar- eller införandeprocessen tidigt, mycket ti­digt. Jag tycker att man mycket väl kan börja redan i samband med projektets första initiala faser.

 

Inkrementell utveckling

Drömmen om the Big Bang delivery

”Det här systemet blev bra. Nu är vi klara med vår IT-utveckling.”

För många tycks det framstå som fullt möjligt att frysa världen i ett permanent status för all framtid (kanske efter en kraftigt genomgripande revolution). Till denna fulländade värld vill man skapa ett IT-system som vid leveransen en gång för alla kommer att vara så fixt och färdigt att det i fortsättningen kan leva oberört från begynnelsen och till evigheten. Varför skulle annars så många och så ofta fråga: ”När är systemet färdigt och vad kommer det att kosta när det är färdigt?”

Dessa kamerala frågor är ständigt återkommande i samband med IT-utveckling. Men eftersom vår värld, vår omvärld och vi med den ständigt utvecklas och förbättras kan det tyckas självklart att även IT-systemen behöver utvecklas. För mig är det då lite obegripligt att man har som mål att bli färdig med ett IT-system.

 

Evolutionärt synsätt

Det är egentligen ganska självklart att utvecklingsarbete skall bedrivas på samma naturliga sätt som världen i övrigt förbättras, dvs. evolutionärt. Och evolutio­nens motsvarighet i utvecklingsvärlden kan vi kalla inkrementell utveckling. Med detta menar jag ett utveck­lingsbeteende som handlar om att, snabbt, konsekvent och i små väl kontrollerade steg nå marknaden. Målet är att komma till effektiv och snabb användbarhet eftersom Tiden Till Marknaden (TTM) är så oerhört viktig. Hur genomgripande en förändring av systemet än skall bli så går det inte att vänta fyra till fem år på release. Vem vet vad som då har hänt? Verksamheten kan mycket väl ha bytt inriktning, blivit uppköpt både två och tre gånger eller kanske inte ens finns kvar. En annan viktig aspekt är att den snabba teknikutvecklingen gör att ett par år gamla teknikbeslut är överspelade flera gånger om.

 

Starta med den egentliga kärnan

Starta projektet med att som första inkrement leverera den egentliga kärnfunktionaliteten. För att hitta vad som skall ingå, det som är absolut nödvändigt, så prioriterar man alla önskade och begärda funktioner:

bullet

Vad är absolut nödvändigt?

bullet

Vad är viktigt?

bullet

Vad är bra-att-ha?

Koncentrera sedan arbetet framförallt på det som kategoriseras ”absolut nödvändigt”. Bygg och leverera detta och gör sedan en ny värdeprioritering: Vad är nu absolut nödvändigt, viktigt eller bra-att-ha? Bygg, leverera, värdeprioritera igen och så vidare i en ständig evolution.

 

Komplettera efterhand med ökad funktionalitet och teknik

Genom att bygga utvecklingen av nästa inkrement på återkommande värdeprioriteringar kan arbetet göras i takt och harmoni med användarnas ökande och ofta accelererande önskemål. Det blir också betydligt enklare att hålla jämna steg med teknikens ständiga landvinningar.

 

Tre releaser om året

Hur ofta är det då dags att släppa en ny release? Jag menar att en lämplig releasetakt kan vara tre per år, det vill säga en var fjärde månad. Det är ungefär så länge som en användare orkar vänta på att något skall hända, samtidigt som det är till­räckligt lång tid för att utvecklarna skall få något reellt gjort.

 

Till slut

Att göra rätt saker, på rätt sätt, i rätt tid och ordning är inte onödiga kostnader – det är nödvändiga investeringar, det är kvalitet!

Det är bristen på kvalitet, dvs. kostnaden för att korrigera felaktig hantering och felaktiga beslut, som är onödiga kostnader.

<<åter