Varför IT-strategier misslyckas eller i bästa fall är meningslösa

Handen på hjärtat, har inte de flesta IT-strategier som du sett fokuserat helt på fel saker eller upprepat meningslösa plattityder? Många IT-avdelningar har förblivit just det, IT-avdelningar och inte hängt med när omvärld och affär har förändrats. Då är det inte konstigt om de missar målet… Här kommer några av de vanligaste misstagen vi har sett i vanliga svenska organisationers IT-strategier.

old and new technology.jpg

De underskattar takten tekniken förändras. Förr gick teknikskiften långsamt, det tog flera årtionden för TV att etablera sig i de flesta hem och övergången till färg-TV pågick hela 70-talet. Likaså tog det årtionden för mobiltelefonen att hamna i var mans ficka men sen dagens smartphones med en stor pekskärm introducerades tog det inte alls många år innan avancerade tjänster blev vanliga. Nuförtiden är det till och med enklare att betala en räkning på mobilen än på hemdatorn (om du ens har någon). Tekniken rör sig fort och genomslagskraften kanske ännu fortare idag.

De outsourcar fel saker eller av fel orsaker. Nu är outsourcing en av dessa strömningar som pendlar från ytterlighet till ytterlighet. Dock har inte alla klart för sig varför de idag sourcar selektivt. Tänk noga igenom vad som är kritiskt för affären och kan ge konkurrensfördelar, detta ska du inte outsourca. I alla fall inte utveckling och innovation. På samma sätt fundera på vad som är lika överallt i just din bransch, kanske just detta borde outsourcas?

De tänker gamla tiders IT-funktion. Det är inte bara teknik som utvecklas snabbt, även organisationers lust och förmåga att experimentera med nya angrepp har nått oanade höjder. Gamla tiders reaktiva IT-funktion hamnar obönhörligen på efterkälken och riskerar bli omsprungna av externa leverantörer som är mer lyhörda för de nya kraven på dynamik och samarbete. Att transformera en IT-organisation från passiv/reaktiv till aktiv/proaktiv är inte gjort i en handvändning, men att tydligt uttrycka det i IT-strategin är en bra början.

De lär inte organisationen var de kan om innovation. Många företag experimenterar idag med innovation i många former. Ibland är de lätta offer för ”innovationskonsulter” som kommer in och håller workshops. Vad många glömmer bort är att det agila arbetssätt som många IT-funktioner har tillämpat i många år kan skalas upp och transformeras till en innovationsprocess. Här finns mycket på att vinna på samarbete mellan verksamheten och IT-specialister som förstår att tänka affär.

De försörjer inte organisationen med rätt kompetens. Budgetering och affärsplanering är kanske inte de roligaste av aktiviteter. Därför är det lätt att halka in på spåret att bara uppdatera förra årets planer. Men skapar vi då utrymme för lärande och utveckling? I takt med att teknik och arbetssätt utvecklas måste också IT-enheten utvecklas. Gör en plan för att skaffa kompetens på nya områden, utveckla personalen aktivt och kanske ta in en extern part som hjälper till att identifiera vilka områden som är värda en satsning.

Det är dags att tänka nytt och uppdatera IT-strategi och verksamhetsplaner för IT-funktionen. Jobbet behöver inte göras stort eller krångligt för att göra stor skillnad i din organisation.

Är du nyfiken på vilka vi är och vårt erbjudande? Besök vår hemsida.

Agilt arbetssätt ger din organisation konkurrensfördelar

Ett agilt arbetssätt går att applicera på de flesta verksamheter då det finns massor med principer och verktyg som kan appliceras. Arbetssättet passar bra då det kan spegla de snabba förändringar som vårt samhälle genomgår genom att utgå ifrån behov/funktion, med en kravhantering som tar hänsyn till förändringar och effektivare processer. Det uppmanar till och föder dialog i tvärfunktionella team vars mål är att utvecklas, vilket ger ökad kompetens samt skapar en brygga mellan IT och olika delar av verksamheten.

shutterstock_133198406_.jpg

Ett agilt arbetssätt ställer nya krav på ledning och styrning samt på nya roller och ansvar. Ledarna skall se till att teamen har rätt förutsättningar och förmågor samt följa upp progress och leveranskapaciteten som de får av teamen. Själva styrningen av teamens arbete är den lista av behov/funktioner i prioriterad ordning som teamen arbetar efter. Teamen arbetar självständigt och målet är att de utvecklas och tar ansvar för att de levererar på ett effektivt sätt som ett team. Självledarskap och förmågan att arbeta i team ligger på medarbetarna.

Det finns flera agila metoder, med olika principer och artefakter, så välj det som passar er organisation bäst och ger störst effekt. Sätt era ramar och finjustera ert arbetssätt. Så länge som den agila metoden ni valt uppnår sitt syfte och ger resultat så utvecklas vidare med den. Mot de mer traditionella metoderna så representerar agilt ett mer flexibelt sätt att arbeta. Den grundläggande idén med agilt arbetssätt är baserad på att göra kunden/användaren nöjd, med frekventa och återkommande möten mellan utveckling/leverans och köpare/mottagare. Det som är gemensamt för de olika agila arbetsmetoderna är att arbetet sker inkrementellt och iterativt vilket innebär mindre men mer frekventa leveranser. Leveranserna utvärderas kontinuerligt och kan förändras för att möta upp nya behov och krav.

Vill ni börja arbeta agilt? Här är 5 råd för att börja arbeta agilt i er organisation:

  1. Sätt ramarna gemensamt och välj den agila metod som passar bäst för organisationen. Sätt ert eget ramverk.
  2. Besluta gemensamt i verksamheten och IT om att införa ett agilt arbetssätt. Det är en stark framgångsfaktor och det som ger mest effekt.
  3. Ta hjälp av extern part som har arbetat med agilt införande. Plocka det bästa från metoderna till ert ramverk.
  4. Ge det tid – Att arbeta agilt är ett nytt tankesätt.
  5. Våga misslyckas, utvärdera och gör om – det är helt naturligt och ni blir kontinuerligt bättre.

Vill du lära dig mer om agila arbetssätt, läs gärna våra inlägg Agilt ledarskap - våga släpp kontrollen och 5 myter om agile som lurar organisationer.

Är du nyfiken på vilka vi är och vårt erbjudande? Besök vår hemsida.

5 myter om Agile som lurar organisationer

Det sista du ska göra är att misstolka vad Agile egentligen står för. Ju längre bort från Agiles ramverk desto mer leder det riktigt fel och negativa effekter uppstår. Den populära versionen är att satsning på Agile utveckling leder till att vi blir av med de misslyckade projekten, kan hantera det oförutsedda, hantera osäkerheter, bli mer flexibla och effektiva samt släppa projektformen så att inga planer och tidsestimeringar behövs. Detta är en misstolkning och går man på den kan det stå den egna organisationen dyrt!

shutterstock_381401455.jpg

Det som gör mig bekymrad är att vi möter många organisationer som har problem med sin projekteffektivitet och då blandar in Agile i sammanhanget i tron att det är en enkel lösning.

Mognaden i många organisationer är påfallande låg rörande projektkulturen, verksamhets- och IT-utvecklingsförmågorna. När det gäller sökandet efter effektiva arbetssätt för att hantera osäkerheter, komplexitet, flexibilitet och tidspress i sin affärs- och integrerade IT-utveckling, är det lätt att tro att Agile är miraklet som ska lösa allt.

Agile innebär att vara flexibla på det vi vill ska kunna ändra och ha disciplin på, sådant vi inte vill tumma på. Just balansen mellan effektivitet och flexibilitet är alltid ett dilemma oavsett utvecklingsapproach - det okända låter sig inte planeras och flexibilitet behövs för att anpassa och hantera det okända.

Det är faktiskt sant, men jag trodde inte att detta skulle behövas förklaras idag – men här kommer fem myter som måste avväpnas för att skapa framgång i Agile likväl som i ”traditionella projekt” där verksamhet och IT måste samverka. 

Myt 1: Kör vi bara SCRUM är vi Agile

Agile är en uppsättning värderingar, attityder och principer. Det räcker inte att IT-utvecklingsprocessen är Agile. Hela processen måste omfatta aktiviteter relaterade till affärs- och verksamhetsutveckling och vara integrerad med IT-utvecklingsaktiviteter, dvs täcka hela kedjan från idé till IT-lösning. Det viktiga är, oavsett i vilken utvecklingsfas vi verkar i, bygger Agile på korta cykler med täta leveranser och kontinuerliga feedbackloopar. Det ger möjlighet att snabbt kunna reagera på förändringar och fånga upp det man lär sig under utvecklingsprocessens gång. Agila metoder handlar om att utveckla en strukturerad förmåga att skapa och svara på förändringar och att ständigt balansera mellan flexibilitet och stabilitet. Struktur krävs i många sammanhang för att flexibilitet ska vara möjlig.

Myt 2: för Agile behövs ingen tidsplan

Agile värderar nytta, styrning och utveckling utifrån timebox-principer. Utifrån känd kostnad (resursinsats) och tidsfönster som ram, leverera största möjligt värde i form av affärsnytta. Det är projektteamet som ska medverka att planera projektet för att få den kunskap som behövs för ”lagom” genomarbetade och realiserbara projektplaner. Det behövs både en övergripande långsikt plan och en som i närtid arbetar fram detaljplaner där arbetet bryts ner i korta aktiviteter. Självklart behövs också regelbunden uppföljning där korrigerande åtgärder sker under projektets gång för att säkra och effektivisera projektets leveranser. Planen är ett verktyg som ger projektteamet förutsättningar att nå målet. Att hantera osäkerheter, nya förutsättningar och nya kunskaper handlar om ett förhållningssätt och lyhördhet i ledarskap och i teamet.

Myt 3: Verksamheten ska bara tänka krav, inte lösning

Agile värderar samarbete, interaktion och tillit mellan individer och grupper. Nära samverkan måste ske mellan verksamhet och IT i team. Det går heller inte att ha skarpa skiljelinjer att verksamheten bara får diskutera behov och krav – och inte lösningar. Vi måste ha strukturer som stödjer interaktioner, som åstadkommer samverkan mellan individer och deras olika kompetenser. Verksamhetskunniga och utvecklare ska arbeta tillsammans, kommunikation ansikte mot ansikte, i samma projekt. Att tänka och göra tillsammans skapar samhörighet, snabb och rak återkoppling. Teamet gör varandra bra! Detta ökar effektivitet och tar samtidigt tillvara medarbetarnas önskan att ta ansvar och utvecklas.

Myt 4: bara verksamheten har något att säga om kraven

Agile välkomnar decentraliserad beslutsgång, succesivt lärande och ansvarstagande. Självorganisering är det optimala arbetssättet som bygger på att stödja varandra och hålla varandra ansvariga i med- och motgång. Ett team arbetar som bäst när de har stor möjlighet att påverka och känner ägande över sina uppgifter inom givna ramar. Allt ansvar delas av alla medlemmar i gruppen som ett team. Det ger dem möjlighet att snabbt kunna reagera på förändringar i bl.a. krav eller lösningar och, framför allt, fånga upp det man lär sig under projektets gång. Beslut bör tas av de som är närmast informationen och därmed mest insatta. Därför ska beslutsfattandet vara decentraliserat till teamet och beslut bör tas så sent som möjligt, eftersom kunskapen då är större. Bäst arkitektur, krav och design växer fram med det självorganiserande teamets ökade förståelse för vad det är de håller på att utveckla. Med jämna mellanrum reflekterar teamet över hur det kan bli mer effektivt och justerar sitt beteende därefter.

Myt 5: projekten klarar sig med bara deltidsresurser från verksamheten och IT

Agile värderar effektivitet, lärande och dynamik. Allt för många projekt måste ta höjd för deltidsresurser som hastigast gör sin grej, och drar sedan vidare till något annat. Det blir ingen dynamik, det blir inget naturligt lärande och därmed tappas projekteffektiviteten. Den kunskap projektet byggt upp måste återskapas när nya resurser ansluter. Att sätta av heltidsresurser för projektarbete är en framgångsfaktor, det kan vara en viktig del i att professionalisera projektarbetet. Genom att planera projekten med heltidsmedlemmar (eller åtminstone huvuddelen av sin tid) redan från dag ett, går det att korta ledtiderna, öka leveranskvaliteten och leveranseffektiviteten.

Slutligen, framgångsrika Agile transformationer måste adressera hela organisationen för att få önskad effekt. Det är inte bara teknik, SCRUM, IT-organisationen som berörs. En omvandling till Agile approach berör alla delar av organisation, Governance-strukturer, processer, ansvar, kompetens och inte minst synsättet på ledare och medarbetare.

Känner du igen dig och är det något att ta med sig? Jag hoppas att du fått reflektioner som kommer till användning. Är du nyfiken på vilka vi är och vårt erbjudande? Besök vår hemsida www.xlent.se.

Frågor ledningsgruppen bör ställa och förstå när det gäller sourcing.

I många ledningsgrupper och styrelser är IT-kompetensen eftersatt och ibland leder det till spektakulära misslyckanden som de vi har sett i sommar. Nu går det oftast inte så illa, men det betyder inte att det brukar bli som man tänkt. Oavsett vilken sourcingmodell man än väljer finns det en rad viktiga frågor som VD, COO, CFO, CIO och andra i företagsledningen bör ställa sig inför en förändring. Här tillhandahåller vi en checklista med några av de viktigaste frågorna att ställa sig.

VARFÖR? Varför funderar vi på att ändra vårt nuvarande sätt att utföra eller köpa tjänsten? Vad förväntas uppnås av ett förändrat förhållningssätt? Det finns olika skäl att outsourca, inget mindre bra än något annat. Allt är beroende på verksamhetens mål och kompetens. Men svaren på varför måste definieras så att alla nyckelpersoner förstår och köper in  på den valda vägen

Exempel på Varför:
1. Komma åt kompetens som man saknar/har för lite av.
2. Komma åt resurser som man saknar/har för lite av.
3. Minska antalet resurser man har för mycket av (FTE:er)
4. Outsourca för att spara pengar– men se upp! Kvaliteten minskar ofta också när det vankas kostnadsbesparingar – kvalitet kostar!
5. Ökad flexibilitet –  ej styrda av anställningsformer m.m

Exempel på mindre bra Varför:
1. Bli av med problem. Många organisationer tror att de kan outsourca problemen, ”Ship and fix”, vilket sällan fungerar i realiteten eftersom hela organisationen då ska ställa om sig på nya processer om är generiska och inte fit for purpose. Men behöver organisationen något som skakar om den ordentligt är detta månne vägen att gå. Man skall också vara medveten om att ens sourcingpartner förmodligen tar rejält betalt för att lösa problemen man vill bli av med, med andra ord: det kan bli dyrt.
2. Bli av med ansvar. Ett av de sämsta motiven, främst för att det är självbedrägeri. Du blir inte av med ansvaret, du blandar bara in ytterligare en part vilket skapar större oreda…

VAD? Vilka tjänster överväger vi att lägga ut? Är verksamheten är lämpad för outsourcing? Beroende på vilka mål en given organisation har eller hur avancerad verksamheten är lämpar den sig mer eller mindre att outsourca. Även om det för de flesta organisationer inte finns lagkrav som förhindrar outsourcing kan det vara olämpligt av konkurrensskäl.

VEM? Är intern leverans vårt bästa alternativ, eller ska vi se på marknaden? Ta alltid med en intern leverans i räknesnurrorna och diskussionerna. Kan en intern leverans skapa mer dynamik och flexibilitet (och kanske minska på konsultberoendet)? Är säkerheten mer rigid med en intern leverans? Kan vi göra en hybridlösning där vi sourcar en del och behåller en del internt?

HUR? Hur ska tjänsten sourcas för maximalt värde? Ska den vara skräddarsydd för er, eller räcker det med standardförfarande?

VART? Spelar det någon roll var tjänsten utförs? Var ska den INTE utföras? Kan det vara relevant att det i landet går att göra en säkerhetskontroll på konsulterna som ska arbeta med er data?

När ni står i sourcingdiskussioner föreslår vi att ni börjar med att besvara ovanstående frågor och säkerställ att svaren är förankrade hos alla i företagsledningen. Då är ni väl förberedda för att skapa en plan och påbörja resan.

Läs gärna också vår post ”Håller din sourcingstrategi måttet?"

Våga avsluta misslyckade projekt i tid

Projekt som inte håller tidplan, överstiger budget eller inte uppnår förväntad kvalitet är tyvärr vardag för många organisationer. Ofta försöker man in i det sista rädda projekten genom att ändra scope, tillföra mer pengar eller skjuta på leveranserna. Men vissa projekt kanske inte bör räddas, och ett bättre agerande vore att avsluta i så god tid som möjligt för att frigöra resurserna till annat.

Dominoeffekt.jpg

Projekt är dynamiska ting som förändras över tid, i takt med att projektgruppen lär sig mer om det som ska göras. Att hålla fast vid grova estimat som sattes då ett business case togs fram i inledningen av projektet är således inte heller en bra taktik. Många organisationer följer någon av de etablerade projektstyrningsmetodikerna, t.ex. PPS eller PROPS. Tricket är att faktiskt använda beslutspunkterna till det de är till för; besluta om projektet är redo att gå vidare till nästa fas eller inte och att de satta ramarna för projektet fortfarande gäller. Ändå tas väldigt sällan chansen att avsluta projekt i "förtid".

Det finns många anledningar till det. Den emotsedda verksamhetsnyttan lockar förstås mycket, man vill nå det där utlovade guldet i slutet av regnbågen. Det kan vara prestige involverat från flera parter, eller så anser några att det redan investerats så mycket tid och pengar i projektet att det måste få löpa linan ut. Här är det inom ekonomin välspridda begreppet "sunk cost" applicerbart. Kortfattat innebär det pengar som redan investerats och inte går att återfå. Dessa bör inte ligga till grund för rationella beslut om fortsatta aktiviteter. I det läget är det bättre att fokusera på alla potentiella framtida kostnader som ett beslut om att fortsätta ett projekt medför medan de fortfarande kan undvikas.

Varför projekt misslyckas är en helt annan fråga, som får avhandlas i en egen bloggpost. Likaså hur man vänder på projekt som är på väg åt fel håll. Här fokuserar vi istället på vad man bör göra när man börjar märka att ett projekt har kört i diket totalt.

1. Känn igen varningstecknen tidigt

Varningstecknen är många. Det kan vara orealistiska tidplaner, avsaknad av identifierade risker eller långa listor på risker som inte åtgärdats. Ständiga förseningar av leveranser, som dessutom inte möter uppsatta kriterier eller är otydligt definierade med en obefintlig "definition of done". Projektmedlemmar som inte kan samarbeta eller styrgrupper och intressenter som trots beslutad projektplan inte har samsyn på vad projektet ska uppnå.

Det finns många fler varningstecken och med tiden lär sig en bra projektledare att känna igen när inte allt står rätt till i ett projekt. Det viktiga då är att agera, och inte bara fokusera på att passera beslutspunkter oavsett vilken kvalitet projektet uppnår.

2. Samla styrgrupp och intressenter

Ett givet första steg är att samla styrgruppen och huvudintressenterna i projektet för att gå igenom vilka problemen är, hur de har uppstått och vad det går att göra åt dem. Fokus bör vara på att skapa samsyn kring vad som inte fungerar i projektet.

3. Omvärdera och omformulera projektet

Utifrån den identifierade problembilden är det lämpligt att ta ett steg tillbaka och be om tid för att utvärdera projektet. Formulera om ramarna för projektet, innehåll och mål. Strukturera om styr- och projektgrupp vid behov. När en gemensam plan för att gå vidare finns är det dags att omvärdera om ditt business case fortfarande håller. Jämför även med helt andra projektidéer; är det verkligen det bästa alternativet att lägga resurserna på utifrån de nya förutsättningarna? Här underlättar en välfungerande portföljhantering den avvägningen väldigt mycket.

Var noga med att undvika den klassiska fällan att modifiera en aspekt av tid, kvalitet och kostnad utan att ge utrymme för faktisk förändring.  Ett projekt som får mer tid och pengar men fortfarande inte är på rätt riktning lär bli en fortsatt besvikelse.

4. Fortsätt inte om ni inte tror på projektet

Den viktigaste, och egentligen mest uppenbara punkten är att inte fortsätta med något ni inte tror på. Känns det inte rimligt att det omformulerade projektet uppnår sina effektmål och den efterfrågade verksamhetsnyttan? Vad är det då för poäng att fortsätta i samma spår?

Här har styrgruppen och projektledningen ett stort ansvar. Att genomföra ett projekt från start till mål är inte att lyckas med ett projekt. Ibland är det korrekta och modiga beslutet att avsluta ett projekt i "förtid".

5. Ta tid till att omgruppera

Efter att ha pausat eller avslutat ett bångstyrigt projekt dröjer det sällan länge innan samma behov lyfts från verksamheten igen. Bara för att projektet misslyckats har ju inte verksamhetsbehovet försvunnit. Värdera då behovet i förhållande till andra projektidéer, våga säga nej om andra alternativ är viktigare och kräv att få den tid som behövs för att gå till botten med verksamhetsbehovet innan en omstart kan bli aktuell.

Att genomföra ett projekt från start till mål är inte detsamma som ett lyckat projekt

Tyvärr kommer man i många organisationer allt för sällan fram till punkt 4 och 5. Att fortsätta slänga pengar på projekt som inte levererar kostar inte bara pengar under projektets livstid. Låter man ett projekt fortlöpa och slutligen stänger det med resultat som inte uppnår målen på långa vägar slutar det inte kosta pengar för det. Att hantera projektets restlista, korrigera fel och förvalta ett undermåligt resultat kostar mycket pengar, ofta under flera år framöver.

Så, nästa gång du står inför ett misslyckat projekt, våga utvärdera, överväga och besluta om att avsluta projektet. Det frigör resurser i form av både anställda och pengar som kan läggas på aktiviteter som faktiskt ger avkastning och skapar verksamhetsnytta.

 

Är du nyfiken på vilka vi är och vårt erbjudande? Besök vår hemsida.