Aftonbladet eller Expressen? Kommer du ihåg den gamla sketchen från Hasse & Tage? Lika stor vånda som Gösta Ekman har i sitt val av kvällstidning har många av oss samma beslutsångest idag inför olika val.  Är det inte val av elbolag så är det val av skola eller telefonoperatör. IT-avdelningens vardag består av återkommer val och beslut gällande uppgraderingar av operativsystem, val av sourcinglösningar (insourcing, outsousing, offshoring, multisourcing, etc), inköp av nya system, avveckling av gamla system, införa ny projektstyrningsmetodik, förvaltningsmodell, och så vidare. Listan kan göras oändlig.

Att välja och att fatta beslut, hur går det till? Rationellt genom noga övervägda alternativ, plus- och minuslistor, magkänsla eller får tärningen bestämma? De flesta skulle nog svara: det beror på vad som ska beslutas. Och de flesta skulle säkerligen också svara att vid ett systemköp eller uppgradering eller i sourcingfrågor krävs bra underbyggda beslutsunderlag. Till detta ska vi också komma ihåg att beslutet kan bli olika beroende på om det fattas i grupp eller enskilt av en individ.

Min erfarenhet från olika organisationer är att de flesta beslut som ska fattas avseende en omfattande förändring i IT-miljön grundar sig på någon typ av beslutsunderlag. Beslutsunderlaget innehåller oftast beskrivningar av alternativ, risker, lösningar, hypoteser om tidplaner och kostnader och en rekommendation. Så långt är allt frid och fröjd och det ser bra ut utifrån beslutsunderlaget. Alla inblandade är glada och har ambitionen att göra en fantastisk övergång till den nya IT-lösningen. Men sedan ska ett beslut fattas och någon ska ytterst stå ansvarig för beslutet. Då finns det risk att beslutsvåndan slår till och stoppar hela förändringen. Som jag ser det kan det vara nyttigt att reflektera ytterligare en gång över beslutet men också att reflektera över vad som händer om man väljer att inte besluta. Det är också ett val. Och att inte besluta kostar också pengar, tid och kraft. Oavsett beslut så kom ihåg att kommunicera både internt och till eventuella externa leverantörer om status för beslutet. Alla är engagerade och vill veta vad som händer, eller inte händer.

Från det ena beslutet till det andra så ska vi inte glömma de beslut som många gånger är av stor vikt för delaktigheten på en arbetsplats men som kan ta oproportionerligt mycket tid och energi. Det är de så kallade cykelställsfrågorna.  Tips från coachen: lyssna och ägna viss tid åt frågorna och fatta sedan ett beslut så att energin kan läggas på det som är kul; att möjliggöra mer affär.

Från stora beslut till mindre beslut, dock ej oviktiga i sitt sammanhang. Hur väljer du öl på krogen? Carlsberg har undersökt köpbeteendet hos ett antal konsumenter på krogen. Kolla in resultatet!
Nästa gång blir det fokus på halvårsbokslut, vad det nu kan betyda?

Dagens tema är policys, riktlinjer, regler och compliance. Et ständigt återkommande ämne i en CIO:s årskalender. Området är brett och omfattar både skrivna och oskrivna regler. Jag vill börja med att belysa några områden utanför IT-området som ger perspektiv och är högst relevanta för oss alla på ett eller annat sätt.

Till exempel finns det, nedskrivet eller inte, regler och riktlinjer i varje hem. Någon (ibland kan det vara flera) bestämmer hur saker och ting ska vara och övriga följer detta (eller inte). Det kan handla om vilken tid man ska gå upp på morgonen, hur länge man får se på tv, vilken mat som ska inhandlas och tillagas, hur det ska vara möblerat och hur julen eller födelsedagen ska firas.
Om vi sedan förflyttar oss från hemmet till offentliga miljöer finns där ytterligare regler, policys och riktlinjer som reglerar vad som får göras och inte. Till exempel att vi har högertrafik i Sverige, att man ska vara 20 år för att få handla på Systembolaget, att man ska ha cykelhjälm om man är under 15 år, att det finns en allemansrätt, etc.
Ett helt annat område med många regler som är nedskrivna och som deltagarna följer strikt men som ändå leder till många känsloyttringar hos svenska folket är Melodifestivalen. Årets melodifestival är ett praktexemplar där framföranden, som genomförts helt enligt regelboken, fått oerhört många reaktioner av tv-tittarna. Framförallt gäller detta Björn Ranelids bidrag i tävlingen. Åsikter har lyfts fram som ”diska Ranelid, han sjöng ju knappt” och ”hur kan en gubbe slå ut en ung kille”.  Det här är kanske ett exempel på i-landsproblem men det engagerar uppenbarligen.

Från de mer allmänna och vardagliga reglerna till de som är mer specifika för IT-området. Det kan låta tråkigt och byråkratiskt med riktlinjer, policys och compliance men jag skulle vilja vända på frågan; skriver vi riktlinjer för att vi måste eller gör vi det för att det är kul och engagerar? De flesta av oss känner måste-oket på axlarna men hur gör man för att få bort det och känner mer glädje i att till exempel arbeta fram riktlinjer? En fundamental fråga som jag brukar ställa mig är varför riktlinjerna ska skrivas, till vilken nytta? Svaret landar oftast i att det handlar om förebyggande säkerhetsarbete för att undvika och minska risken för datorhaverier, bedrägerier och andra obehagligheter som till syvende och sist drabbar kunden. Och det vill vi inte ska hända. Däremot vill vi uppnå kundnytta och om policys och riktlinjer kan hjälpa till med det blir det genast roligare.

Ta till exempel ISO 9000 som tidigare utgick från att följa upp processer och kvalitetsledningssystem. Nu har de som utgångspunkt att ett företag utan nöjda kunder är ett företag i fara och för att ha nöjda kunder måste organisationen möta kundernas krav och förväntningar. Ett sätt att uppnå detta är att använda ISO9001:2008-ramverket för att hantera organisationens processer med målet att nå hög kundnöjdhet och att göra goda affärer.

När det gäller regler och lagar så ökar graden av regelverk att följa. Det handlar om allt från rutiner för att spara data likaväl som att rensa data, ta backuper, ha katastrofplaner på plats, nedskriven och förankrad IT-policy, IT-säkerhetspolicy och inte minst lösenordspolicyn.

Vad skulle jag som chef över IT göra utan dessa policys och riktlinjer?  Som jag ser det handlar det om normsäkring (eller compliance), att ha beskrivit vad vi gör och inte gör, hur olika delar hanteras och av vem och hur vi följer upp att vi efterlever våra beskrivningar. Och återigen får jag påminna mig om för vems skull skapar vi dessa policys och riktlinjer? Jo, för att säkerställa affären och allt runt omkring den hanteringen. Compliancearbetet innebär att företaget på ett aktivt sätt verkar för god kvalitet i sina tjänster och inte minst att vi arbetar för att kunden ska känna sig trygg och ha förtroende för företaget.

Här kommer några tips som kan hjälpa till med att göra jobbet med riktlinjer och policys mer inspirerande och skapa engagemang.

-          Förankra både i ledningsgruppen, styrelsen, hos chefer och medarbetare. Berätta varför policys och riktlinjer finns och vad som kan hända om de inte finns. Kom ihåg kundnyttan och ge exempel på vad som skulle kunna hända om vi inte följer en särskild riktlinje.

-          Ta inte för stora delar på en gång. Står du i startblocken och ska skapa IT-policy, IT-säkerhetspolicy, Lösenordspolicy, BCP-plan och ytterligare riktlinjer? Ta en sak i taget, prioritera den som är viktigast först. Ta reda på exempel från andra som skrivit liknande dokument och låt dig inspireras.

-          Repetera riktlinjerna i olika forum och i olika kanaler regelbundet. Använd en klassisk kommunikationsplan för att beskriva hur du ska nå ut med budskapet via intranät, avdelningsmöten, stormöten, utvecklingssamtal, mail, etc.

-          Passa på att använda IT-revisorerna för att granska dina policyers och riktlinjer för att på så sätt hålla dokumenten aktiva.

-          Ta med medarbetarna i arbetet för att lättare få förankring och förståelse för varför riktlinjerna finns och varför de ska följas.

-          Tänk på att riktlinjerna ska kunna användas och förstås. Gör de inte för krångliga och teoretiska, de ska kunna följas enkelt av alla anställda.

Arbete med riktlinjer börjar med förståelse för att det finns en kund i slutänden som vi ska se till är nöjd. Att IT är möjliggörare för affären gäller också för olika policys och riktlinjer.

Nästa gång blir det fokus på att välja och beslutsångest. Vad ligger till exempel till grund för ett systemköp eller ett val av en viss metodik eller om så ”enkla” saker som om vi ska sitta i kontorslandskap eller i egna rum?

Test är något som pågår hela tiden utan att vi tänker på det. I vardagen testar vi till exempel nya maträtter, ett par nya skor, test av den nya chefen eller den nya rutinen för löneadministration, syntest, konditionstest, test av ny bil, och så vidare.
Vad skulle hända om vi slutade testa? Tänk dig scenariot att små barn skulle sluta resa sig varje gång de ramlar medan de lär sig gå eller att du aldrig skulle testa ett nytt resmål eller en ny biograf eller en ny drink eller ett nytt bröd eller en ny tidning eller en ny arbetsplats. Det skulle vara ganska tråkigt och framförallt bli ett ganska stillastående liv. 

Varför är det så viktigt med test? Svaret skulle kunna sammanfattas i två ord: säkerhet och kvalitet.

Vad hände med JAS Gripen på Långholmen1993? Hade det kunnat undvikas med fler tester? Farkosten Forbos-Grant hamnade i november 2011 utanför omloppsbanan och störtade mot jorden. Hade det kunnat undvikas med mer test? Och sist men inte minst så minns många av oss fortfarande Tietohaveriet i höstas som gav driftproblem i stora mått och som eventuellt skulle kunnat undvikas med katastrofövningar och test.

Test är också en viktig del av IT-projekt. Alla som arbetar med IT och affärsutveckling vet hur viktigt det är att rätt funktionalitet levereras vid rätt tidpunkt. Komplexiteten uppstår när projektet börjar få problem med att hålla tidplanen och man börjar knapra på testtiden för att nå uppsatt mål.

Testledaren skriker högt och meddelar vilka risker vi står om vi produktionssätter med minskade tester och med underlag från de redan bantade testerna. Styrgruppen säger ”vi hör vad du säger men vi måste får ut den här funktionaliteten nu. Vi står risken!”
Så släpps releasen och funktionaliteten börjar användas. Ibland går det bra, ibland går det inte bra. Och rättningar av buggar får göras. Vem som tar ansvaret och vem som får skulden när det går bra respektive inte går så bra med kvaliteten i leveransen går jag inte in på i den här texten. Däremot kan man ställa sig frågan varför test prioriteras ned så ofta och varför vi inte vågar stoppa eller försena projekt i högre grad och landa testerna ordentligt för att säkerställa kvaliteten?

Ur ett affärsmässigt perspektiv är det naturligtvis viktigt att komma ut med nya produkter. Men det är minst lika viktigt att produkterna håller hög kvalitet, både funktionellt, administrativt och servicemässigt. Fixar vi inte hela kedjan spelar det ingen roll hur fina produkter vi har.

Utifrån mina erfarenheter som IT-projektledare, beställare, styrgruppsmedlem och ansvarig för IT-systemleveranser skulle jag vilja lyfta testområdet som en nyckel till hög kvalitet i leveransen av IT-system, releaser och buggrättningar. Det handlar om att testa, hitta fel och att hinna rätta felen.  Se test som en naturlig del i hela kedjan, avdramatisera men se också till att höja statusen för testområdet och testarbetet.

Metodmässigt finns det som vanligt ett antal metoder att välja mellan, även när det gäller test. Vattenfallsmodellen med sekventiella steg lätt att förstå och ganska enkel att rita upp. Men verkligheten med dagens integrerade och komplexa IT-miljöer ställer krav på en iterativ och agil metodik och synsätt där test tas med tidigt i processen. Testdriven utveckling, TDD, är ett annat sätt att se på testarbetet där du utgår från att du först skapar dina enhetstester, för att sedan skriva kod som får dessa tester att passera. En tredje variant är utforskande testning som är en stil för programvarutestning som bygger på erfarenhetsbaserad testdesignteknik utan skriftliga testfall. Testerna skapas samtidigt som testarna lär sig systemet.

 Oavsett metod för testningen så är målet med hela testarbetet och dess optimering att leverera tillförlitliga affärskritiska system.  Och IT-system i all ära men glöm inte att ta hand om de verksamhetskunniga användarna i acceptanstesterna!

Nästa gång blir det fokus på riktlinjer och policys – ett nödvändigt ont eller lustfyllt och inspirerande?

Vi är alla omgivna av krav och förväntningar. Både på oss själva och på andra. I min roll som chef och ansvarig för IT-området ställer jag en hel del krav på såväl leverantörer och medarbetare som på projektleveranser och IT-beställare.  
Fokus för det här inlägget är förväntningar och krav inom IT-området. I bästa fall är kraven klara, tydliga och rätt prioriterade. I värsta fall blir kravhanteringen till en enda viskningslek eller som en vandringssägen.

Här kommer tre IT-relaterade vandringssägner från nutid. Är de sanna eller falska? Svaret finner du längst ned i detta inlägg:
1. Ipod fungerar som åskledare. Läkare i The New England Journal of Medicine har studerat skadorna hos två män som blivit träffade av blixten samtidigt som de lyssnat på sina Ipods. Skadorna bestod av skadade trumhinnor, förlorad hörsel och brännskador

2. Microsofts trådlösa och portabla toalett. Microsofts håller på och utvecklar den nya portabla toalett iLoo med trådlöst tangentbord, plasmaskärm och extern Hotmail-station för de som står i kö utanför toaletten.

3. Saddam Hussein köper 4000 Playstation 2 för att utveckla massförstörelsevapen. Den 19 december 2000 pumpade nyhetssajten Worldnetdaily.com upp nyheten. Anonyma millitära källor uppgav att datakraften i PS2:an skulle kunna användas till att bygga en enorm superdator. Bara genom att koppla ihop några få PS2:or skulle Irak enligt experterna kunna bygga system för en obemannad raket eller liknande.

Finns det nöjda IT-användare och beställare?
När är en beställare eller användare nöjd med en IT-leverans? Är det när kraven verkligen är uppfyllda eller när användaren upplever att kraven är uppfyllda? Eller är det när den som skriker högst får igenom sina krav? Att ha en väl fungerande kravprocess är lika med att involvera de olika kompetenserna (kravställare) som ska delta i processen för en effektiv kravhantering.  Kravprocessen ska, som jag ser det, omfatta aktiviteter och de kompetenser som vet vad som förväntas och som kan prioritera mellan vad som är måsten och vad som är trevligt att ha. Till sin hjälp ska det finnas beskrivningar (gärna i form av GUI-bilder), mallar, checklistor m.m. Och, ja, det finns nöjda beställare och användare. I de lyckade exempel jag tänker på handlar det om utveckling av funktionalitet som varit ganska liten men som gett stor effekt för användaren och som dessutom levererats förhållandevis snabbt. Förväntningar stiger ofta i samband med att det blir längre leveranstider.

Varför är det så viktigt med en bra kravhantering?
Framförallt för att det kostar så oändligt mycket tid och kraft med missnöjda användare och kunder och det kostar tid, kraft och pengar att rätta fel i efterhand i ställe för att göra rätt från början. Felaktiga krav är enligt flera undersökningar en av de stora felkällorna vid systemutvecklingsprojekt. Anledningarna är många, t.ex. utveckling av funktioner som inte används (felaktig ambitionsnivå) och för stort fokus på omfattande kravdokument som tas fram för tidigt. Detta är ett mycket kostsamt arbete och när lösningen senare levereras så motsvarar den ofta inte förväntningarna.
Utan bra krav blir det inget bra IT-stöd. Vad som är bra krav kan diskuteras. Som jag ser det gäller det att formulera kraven rätt, och det gäller att formulera rätt krav. För att undvika viskingsleken och att det blir en vandringssägen av kravarbetet ska det finnas en transparens genom hela arbetet. Från analysfas till leverans och från kravanalytiker till styrgrupp.

Några kritiska framgångsfaktorer som jag skulle vilja lyfta fram för att lyckas med kravarbetet är följande.
Verksamhetsanalys – Det är viktigt att formulera kraven rätt men det är ännu viktigare är att formulera rätt krav. För att veta att det är just ”rätt krav” krävs en bra problembeskrivning eller målbild för utveckling, där behovet och sammanhanget framgår.

Prioritera – Kraven är ofta många och omfattande. Utöver att formulera rätt krav är det också viktigt att välja de krav som ger mest nytta. Vad ska kraven uppnå för funktioner? Olika studier visar att 80 % av värdet i de flesta system levereras av 20 % av funktionerna. Och, upp till 2/3 av funktionerna används sällan eller aldrig. Och vem är med och prioriterar kraven? Är det den som hörs mest eller den som vet mest om hur systemet ska användas i praktiken?  

Kravens utformning – Placera inte kravet i ett specifikt system för tidigt och arbeta iterativt. Detaljera tillräckligt det vill säga varken mer eller mindre än nödvändigt och använd gärna grafiska bilder för att exemplifiera kraven. Att krav förändras efter vägen i ett projekt är en naturlig del av utvecklingen och det är därför viktigt att inblandade kravställare är involverade hela tiden och tar ansvar för de krav som slutgiltigt ska gälla. Ingen blir nöjd av att hålla fast vid en kravbild som efter hand visar sig vara felaktig.  
Eller enkelt beskrivet, det handlar om hantering av förväntningar.

Och svaren på de tre IT-relaterade vandringssägnerna, hur var det med dem? Sanna eller falska? Här är svaren:

1. I juli förra året berättade en rad nyhetssajter att Ipods lockade till sig blixtar vid åskväder Rubrikerna var falska och syftade på upptäckter i The New England Journal of Medicine där läkare studerat skadorna hos två män som blivit träffade av blixten samtidigt som de lyssnat på sina Ipods. Skadorna – skadade trumhinnor, förlorad hörsel och brännskador – uppstod visserligen på grund av Ipoden.
2. I maj 2003 exploderade nyheten om att Microsofts nya portabla toalett iLoo var under utveckling. Självklart handlade det om ett skämt, men både AP och Wall Street Journal körde nyheten. PR-tricket var signerat Microsofts brittiska kontor.
3. Så här i efterhand kan vi ju konstatera att Irak inte hade några massförstörelsevapen – kanske använde de sina PS2:or till att spela spel?

Nästa gång blir det fokus på test och testområdet. Hur mycket ska man testa ett IT-system egentligen, varför minskar alltid tiden till test. Och hur skulle världen se ut om alla små barn slutade testa sig fram.

Vart tog förra året vägen?

”Det finns en stor men ändå helt alldaglig hemlighet. Den delas av alla människor, alla känner den, men få ger den någon eftertanke. De flesta tar den för självklar och funderar inte alls på den. Denna hemlighet är tiden.” Michael Ende

Ett nytt år har startat och det gamla avslutats. Dörrar har stängts och nya öppnas. Det är dags att reflektera över vad som hände under förra året? Vart tog tiden vägen? Och vad åstadkom vi egentligen?
Sammanfattningsvis har mitt IT-år 2011 gett mig mycket att reflektera över när det gäller att landa ett omfattande systembyte, förankra och förändra rutiner och processer avseende IT-relaterad utveckling och att få samarbeten såväl internt som med externa leverantörer att rulla på för att i slutänden nå våra affärsmässiga mål. Vissa saker har gått rikrigt bra, som till exempel uppgraderingen till Win7 och Office 2010. Något som är svårt och som vi borde landat bättre är att prioritera tydligt bland allt som vi vill göra. En sak är i alla fall säker, konkret har vi levererat en hel del fundamentala IT-relaterade grundstenar som möjliggör tillväxt och affärsutveckling. Det har varit ett roligt, lärorikt och tufft år och nu känns det riktigt bra att gå in i ett nytt år med fokus på innovation och utveckling.

Förväntningar inför 2012?

”Tiden är en illusion, och lunchtid i dubbel grad.” – Douglas Adams, Liftarens guide till galaxen

En uppmaning till alla er som lägger nya måsten på axlarna vid varje nyårsafton: Ge dig själv nyårslöften som består av att göra fler roliga saker och inte att lägga till fler måsten i livet. Skapa nyårslöften som ger livsglädje!

Apropå roliga saker så har jag noterat att många av de IT-trender som lyfts fram inför 2012 ska bestå av nätet, mobilt, cloud, kostnader och säkerhet. Det stämmer säkert som allmänna trender och det mesta av dessa delar finns även med på min lista över aktiviteter för året. Det jag vill lägga till och som jag ser som en framgångsfaktor för mitt område är dock att ta ytterligare kliv framåt när det gäller att koppla ihop IT-utvecklingen med produkt(affärs)utvecklingen. Där ska vi ligga i framkant och vara snabba och ha hög kvalitet i det vi utvecklar. Det blir det absolut högsta fokuset och förväntningarna för mig och det område som jag ansvarar för.

Förutom mina yrkesmässiga förväntningar på 2012 så har jag också några personliga. Jag återknyter till min inledning om att ha nyårslöften som ger livsglädje och för mig handlar det om att dansa mer argentinsk tango, njuta av fler skaldjursplatåer och att få så mycket sol och värme som jag kan under året.

Jag avslutar med en filosofisk fråga: Går tiden snabbare när vi blir äldre? Kanske, om vi ska tro Illustrerad Vetenskap.

Nästa gång kommer jag att skriva om krav: IT-krav, verksamhetskrav, krav på sig själv och på andra och är någon någonsin nöjd utifrån de krav som ställs? Det är ett spännande område att fundera över!

Att överhöra en konversation, eller tjuvlyssna om man så vill, tycker jag är spännande. Det som väcker mest nyfikenhet är när jag hör människor prata i mobiltelefon och jag enbart får ta del av den ena partens ord i samtalet. Det sätter igång fantasier och funderingar. Jag får höra delar av samtalet men inte hela och av det jag hör kan jag dra vissa slutsatser och resten får jag gissa.

Att tjuvlyssna på det här sättet är lite som att sätta IT-budgeten för kommande år; jag känner till stora delar av kostnaderna, vissa delar kan jag få ihop genom input från andra delar av organisationen och en del får jag gissa mig till. 

Kända faktorer
Överhört i Stockholms tunnelbana. Två personer som talar om julen, julklappar och julfirande:
- I vår familj har vi valt att lägga ned det där med julklappar.
- Vi också. Vi ger bara till barnen.
- Samma här. Vi ger också bara till barnen. Men sedan brukar jag ge något litet till min man också. Och till svärmor. Hon blir så besviken annars. Men vi har bestämt att det får kosta max 500:- per julklapp.
En klassiker när det gäller julklappar, inte helt konsekvent men vad spelar det för roll?

Från julklappar till IT-budgeten. Att lägga en IT-budget är hur enkelt som helst om jag skulle få göra allt det jag vill göra och ha hur höga kostnader som helst. Men nu är det ju inte så i verkligheten. IT-budgeten är inte som önskelistan till tomten. Och den måste dessutom vara konsekvent.

En ekonomisk värdering utifrån vilka IT-kostnader jag ser framför mig börjar med att jag gör en tillbakablick och utgår från nedlagda utgifter för föregående år. Jag börjar med att titta på vilka kostnader vi haft i år eftersom kända saker är lättast att budgetera. Saker som hårdvara, support, licenser och sådant vi leasar är inte så mycket att göra åt från ett år till etta annat. Men även för sådana kostnader behöver vi en strategi för att med jämna mellanrum utvärdera och optimera.

Att välja och att prioritera
Tjuvlyssnat en höstkväll när jag passerade förbi en parkbänk på Långholmen i Stockholm. En sorgsen ung kvinna pratar i mobiltelefon och säger ”Det fungerade bra mellan oss tills han aktivt valde bort kärleken”.
Vilken replik! För en tjuvlyssnare som jag är det här en av de mest fantasieggande delar av ett samtal på länge.

Från tjuvlyssningen på Långholmen till de val jag måste göra när jag lägger min IT-budget. Jag vet att jag alltid får tillbaka mitt budgetförslag med krav på att sänka kostnaderna ytterligare. Då handlar det om att välja och att prioritera. Förutom de kända kostnaderna som jag redogjorde för ovan så gäller det att fundera på de övriga kostnaderna som hör till IT-området och som är mer av satsningar som jag vill genomföra men som definitivt inte kan stoltsera med att det är satsningar som direkt kommer att synas på försäljningssiffrorna eller för kunderna. Det kan till exempel vara att göra en rejäl genomgång av databaser, servrar och säkerhet för att skapa en bättre och mer kostnadseffektiv plattform för vår utveckling av produkter. Kort och gott effektiv IT. I slutänden leder detta till lägre kostnader för IT-infrastrukturer och en bättre plattform för framtida affärsutveckling.

Gissningar och samordning

Hört i Stockholms tunnelbana. Konversation mellan tonåringen och föräldern. Föräldern frågar lite trött:
- Vad gör du när du träffar på människor i din skola som bara tar energi?
- Jag sätter på mig mina hörlurar.
- Ok, men det kanske inte är så lämpligt för mig att göra så på jobbet.
- Du kan ju ta små lurar som inte syns. Det har jag alltid på lektionerna, de syns inte under håret.

Så enkelt var det med det!
Det som tar mest energi avseende IT-budgeten är att sätta siffror på de utvecklingsprojekt som planeras till kommande år.  Det är lite som att leka ”rita, gissa, spring” där jag till viss del får göra kvalificerade gissningar utifrån vad jag tror ska levereras. Det finns ett flertal olika modeller för att räkna ut IT-investeringar i ett projekt men det spelar ingen roll hur fina modeller man än använder om innehållet är okänt.
Oavsett svårigheten att gissa rätt eller fel så utgår jag från affärsplanen och de affärsutvecklingar som planeras inför kommande år. IT är ett konkurrensmedel och det är vårt ansvar att skapa förutsättningar för innovationer i IT-baserade produkter, tjänster och affärsidéer.
Utifrån den information kopplad till IT-budgeten som jag har brukar jag fundera igenom ungefär vilka områden/system som berörs för respektive satsning och vilken typ av kompetens som kommer att behövas. Inga glädjekalkyler. Min erfarenhet säger mig att allt tar längre tid eller är mer komplext än vad vi tror från början. Med det som utgångsläge skapas en översiktlig kalkyl som i grova drag bygger på interna kostnader, externa konsulttjänster, inköp hård- och mjukvara och kommande förvaltningskostnader. Ett business case ligger oftast till grund för hela utvecklingsprojektet och efter beslut om genomförande sker kravställning och det är först då vi kan börja se hela bilden av vad som ska göras och kostnader kan kartläggas mer i detalj.

Avslutningsvis vill jag kommentera en återkommande diskussion som brukar dyka upp i budget- och affärsplanearbete och det är kostnader för utveckling kontra förvaltning (oftast med syftet att förvaltningskostnaderna ska minska och utvecklingskostnaderna ska öka).  Frågan brukar vara: vad är utveckling och vad är förvaltning? Efter det sker det vanligtvis en lång diskussion i ämnet och slutligen landar vi nästan alltid i samma slutsats: att rätta en bugg är förvaltning, men att utveckla en ny funktionalitet som tidigare inte funnits är utveckling. Jag vill slå ett slag för förvaltningen då området ofta behandlas styvmoderligt. En väl fungerande förvaltning av ett förvaltningsobjekt där man ser till både tekniken och affären är en grundbult för både kvalitet och kostnadseffektivitet i en verksamhet.

Sammanfattningsvis skulle jag vilja säga att jag tycker det är kul att budgetera och det är lika tillfredsställande när utfallet följer budgetramar som det är frustrerande när kostnaderna sticker iväg. Och du, glöm inte att sätta upp rättvisande KPI:er!

Ha en underbar adventstid och njut av julbord, glögg, julkonserter, saffransbullar och pepparkakor med kristyr. Nästa månad skriver jag om reflektioner från året som gått och förhoppningar inför kommande år.

Oktober har passerat och för min del har det varit en månad fylld av leveranser och att hantera rädslor.

Alla är vi rädda för olika saker. Det kan vara allt från ormar, tandläkare, höjder, att åka hiss, att drabbas av sjukdomar eller att tala inför andra människor. Personligen är jag extremt rädd för spindlar men jag håller sakta men säkert på att bearbetar den rädslan genom att regelbundet klappa spindeln på Skansenakvariet.

Från spindlar till mer yrkesrelaterade saker att vara rädd för. Något som jag vet att många är nervösa inför är att bli granskad av IT-revisorer, en annan sak som lätt kan generera rysningar och svettpärlor är att migrera data från ett system till ett annat och ett tredje område som kan utsöndra adrenalin är att få på plats och enas kring en gemensam metod för IT-utveckling. Man kan bli svettig för mindre.

Under oktober har jag fokuserat på dessa tre områden: IT-revisorerna har gjort den årliga granskningen, vi har genomfört den sista delen i en rad av migreringar av data från vårt gamla system till ett nytt och på metodsidan har vi lanserat en gemensam process för prioritering och arbete med IT-utveckling.

IT-revisionen gick förhållandevis bra. Rädslan som fanns hos mig innan revisorerna kom på besök härstammar mest utifrån funderingar på huruvida vi har åtgärdat det vi fick synpunkter på förra året eller om vi inte gjort det eller, ve o fasa, om vi försämrat ordningen och redan. Det är alltid lite jobbigt innan revisorerna trots att jag vet att de har bra åsikter och att resultatet leder till kvalitetshöjande åtgärder men ändå är det lite smånervöst inför dessa möten.
Så, hur blev resultatet? Återigen fick vi veta att vi kan förbättra användaradministrationen och kontohanteringen, processerna kring ändringhantering kan förbättras ytterligare och IT-säkerhetspolicyn kan förankras mer.  Vi har kommit ett steg längre i förbättringen men det finns alltid saker att förbättra ytterligare. Till nästa år ska vi väl ha kunnat åtgärda de flesta av punkterna. Men det betyder ju å andra sidan att det kommer att finnas andra områden för revisorerna att ge synpunkter på. Hm… nya rädslor att hantera.

Migrering av data från ett system till ett annat. Sammanfattningsvis handlar det om att trycka ned runda bollar i fyrkantiga hål. Det är en rysare som kräver koll på informationen som ska över, koll på diverse olika miljöer, tester och transaktioner. Det kräver också mycket is i magen och nitiska projektledare. Det är spännande och ja, det har varit en resa. Men nu har vi fått ned de runda bollarna i de fyrkantiga hålen och lagt över de sista delarna i det nya systemet. Det här tredje och sista steget av migreringen gick som en dans. Alla steg under migreringshelgen genomfördes enligt tidplan och utan problem. Vi kunde verifiera helt enligt planen och öppna systemen som planerat. Så enkelt har inte alla steg innan dess varit. Vi har tidigare kämpat med problem i miljöer, med svarstider, beräkningar som inte gått igenom, körningar som kraschar och människor som har fått jobba dygnet för att få allt på plats. Så var det inte nu, sista steget genomfördes precis som det ska. Underbart!

Ordet process kan skapa alla möjliga reaktioner som jag ofta märkt härstammar från någon typ av rädsla för byråkratisering, ineffektivitet och en massa onödigt dokumenterande istället för att leverera. Jag vill inte heller överbyråkratisera men jag vill ha ordning och reda och definitivt ha krav beskrivna och dokumenterade. Det har hänt allt för många gånger att en kreativ systemutvecklare tillsammans med en kreativ produktutvecklare kommit överens vid kaffemaskinen om hur en funktion bör utvecklas eller se ut eller fungera.

Jag har tyvärr också för många exempel på sådan utveckling som gått snett kvalitetsmässigt eller funktionalitet som ingen känner till hur den ser ut eller varför den är utvecklad på ett visst sätt på grund av att ingenting dokumenterats. Utmaningen som jag ser det har varit att nå en medelväg av ordning och reda utan att kväva kreativiteten eller bli ineffektiva. I mitt fall har stort fokus lagts på att sy ihop releaseprocessen med produktutvecklingsprocessen, det vill säga IT och produktutveckling möts i några gemensamma steg. Målet är att ha en sammanhållen arbetsmodell för att kunna bibehålla en snabb produktutveckling men med struktur och ordning och reda. Klassisk prioritering alltså och samsyn mellan affärsutvecklingen och IT. Processpöket och rädslan för detta är borta, nu kör vi vidare och implementerar metoderna och anpassar allteftersom.

Från rädslor till leveranser till resultat, så skulle jag vilja sammanfatta oktober månad. Dessutom är oktober en skön höstmånad med vackra färger på löven, krispig luft och det är helt ok att krypa inomhus, tända ljus och kura skymning.

Nästa månad skriver jag om tjuvlyssning och budgetprocessen inför 2012. Var ska vi sänka kostnaderna, vilka investeringar ska göras och hur stora ska de vara. Hur ska jag som CIO tänka taktiskt för att få igenom så mycket som möjligt av det som jag anser är viktigt ur ett IT- och verksamhetsutvecklingsperspektiv. Hur mycket ska läggas på förvaltning kontra utveckling? Mer om detta kommer i novemberbloggen men tankearbetet har börjat.