Därför floppade projekten: Tre svenska it-fiaskon under lupp

Skandalrubriker om misslyckade it-projekt dyker med jämna mellanrum upp i medierna – projekt som är kraftigt försenade och dyrare än planerat, nya system som skapar stora problem vid implementeringen, nya rutiner som driver användarna till vansinne...

Man kan lätt få uppfattningen att de flesta it-projekt misslyckas. Dessvärre verkar bilden stämma, åtminstone om vi får tro The Standish Group, ett amerikanskt företag som regelbundet granskar projekt från hela världen och ställer samman en rapport med det talande namnet ”The CHAOS Report”. I senaste upplagan (2009) konstaterar man att endast 32 procent av projekten var att betrakta som lyckade – definerat som att de avslutades inom utsatt tid, höll sig inom budget och ledde till de ursprungligen planerade resultaten (Se gul tabell). Oavsett om siffrorna stämmer eller ej vet nog de flesta CIO-läsare att det ­räcker med en enkel sökning på nätet för att hitta mängder av misslyckanden av närmast episka mått. Eller kanske finns de närmare än så, i den egna organisationen?

Varför går det så ofta så illa? Och hur ska man göra för att lyckas? Standish Group redovisar även tio framgångsfaktorer för lyckade projekt, där ”delaktiga användare” och ”ledningens stöd” ligger i topp (se ruta). Tipsen kan låta självklara, men ändå är det oftast här det brister.

– Inte minst den första faktorn, delaktiga slutanvändare, är oerhört betydelsefull, berkräftar Torsten Cegrell, professor vid Institutionen för Industriella Informations och Styrsystem på KTH med lång erfarenhet av it-projekt.

Nedan har vi tagit en titt på tre svenska projekt som inte har lyckats så bra för att man har slarvat med just detta. Verkliga exempel att begrunda – och dra lärdom av.

PRV: 300 miljoner – för ingenting

I slutet av 90-talet beslutade Patent- och Registreringsverket (PRV) att rationalisera och förnya arbetssättet på bolagsavdelningen. En stor och viktig del blev att utveckla ett nytt it-system för kundservice, ekonomi och administration. Projektet som fick namnet Bolit initierades på våren 1997 och beräknades slutföras i maj 1999. Projektbudgeten sattes till 175 miljoner kronor.
Nu gick det inte riktigt som man hade tänkt sig. Visserligen genomfördes en förstudie och en regelrätt upphandling, men det avtal PRV tecknade med den utvalda leverantören var ändå ospecifikt och på löpande räkning.

Leverantören sköt jobbiga beslut om övergripande arkitektur på framtiden och fördjupade sig istället i tekniskt intressanta lösningar. Utvecklingen blev en inveckling i komplicerade detaljer, vilket resulterade i att utförandet inte kunde leda till ett införande av systemet.

De första signalerna om att någonting var fel nådde PRV:s styrelse i november 1998. Leverantörerna meddelade att Bolit förväntades överskrida budgeten med cirka 10 miljoner kronor, och bli någon månad försenat. Styrelsen beslöt ändå att fortsätta, men i maj 1999 visade det sig att inget system alls fanns att ta i bruk. Avtalet förhandlades då om i försök att ställa mer konkreta systemkrav.

Den 30 juni 2000 levererades slutligen Bolit till PRV. Vid en första granskning såg allt bra ut, men efter hand upptäckte man att systemet fungerade så dåligt att det omöjligt gick att använda. PRV:s juridiska ombud konstaterade dock att en skadeståndstalan på grund av utebliven prestation var omöjlig – leverantören hade faktiskt uppfyllt allt som stod i kontraktet. Istället höjde PRV avgifterna på bolagsavdelningen för att få ekonomin i balans efter Bolits slutnota på 300 miljoner kronor, 71 procent över budget. Återbetalningsplanen fick budgeteras över tio år, och det utan att en enda del av Bolit kunde tas i bruk. PRV står ännu idag utan ett fungerande generiskt it-system som stöd för sina administrativa processer.

Var brast det? Enligt Torsten Cegrell är PRV-fallet ett typexempel på otydliga affärsmål och dålig upphandling. Kort sagt bristande beställarkompetens.
− Tyvärr är beställarkompetensen i många verksamheter näst intill obefintlig. Allt hänger på att man får fram en bra kravspecifikation, säger han.

Skenande kostnader, ett system som var oanvändbart för användarna – och slutligen – oförmågan att ställa leverantören till svars, eftersom felet låg i kravspecen och inte i leveransen. Det blev den dyrköpa läxan för PRV.

Allt hade kunnat undvikas med en tydlig kravspecifikation kopplad till slutanvändarnas verkliga behov. (Något som också hade underlättat för leverantören.)

Landstinget: en dyr säkerhetsrisk

Ett it-projekt som fått stor uppmärksamhet i media var när ett flertal landsting införde journalsystemet Cambio Cosmic. Tanken var god: ett gemensamt journalsystem för alla Sveriges sjukhus skulle minska mängden administrativt dubbelarbete – och öka patientsäkerheten. Men det gick inte alls som man hade tänkt sig. Inte inom något av de sju landsting som idag använder Cosmic. Systemet blev dyrt, försenat och utsatte patienter för risk.

En anledning till de stora ekonomiska problem som uppstod är att de flesta landsting saknade en totalbudget för införandet. I Östergötlands landsting, exempelvis, var budgeten på 130 miljoner tänkt att täcka kostnaderna för licenser, servrar och utbildning.

Andra hårdvarukostnader, som inköp av datorer, fick de respektive ­klinikerna belasta sina budgetar med. Och kostnaden för att personal på utbildning måste vara borta från sitt arbete var det ingen som tänkte på. I efterhand har implementeringskostnaderna bara i Östergötland uppskattats till 250 miljoner kronor – nästan dubbelt så mycket som beräknat.

Ett annat problem var att leverantören, Cambio, inte klarade av att införa de utlovade funktionerna enligt överenskommen tidsplan. En funktion som länge saknades var någon form av varning när felaktiga eller motsägelsefulla uppgifter matas in i systemet – en brist som kan få allvarliga konsekvenser för patientsäkerheten.

De ansvariga försvarade sig med att det faktiskt var säkerhetsproblem även med pappersjournalerna; alla dessa problem, och flera nya, verkar Cambio och den svenska sjukvården ha tagit med sig på datoriseringsresan.

En faktor som ofta nämns som huvudproblem är den dåliga kommunikationen med slutanvändarna. En bristande förståelse för de arbetsuppgifter som systemet skulle stödja ledde till att användarnas arbetsbelastning ökade istället för att minska. Samtliga landsting som infört Cosmic blev, åtminstone under en övergångsperiod, tvungna att dra ner på den tid personalen ägnade åt att faktiskt vårda patienter, eftersom administrationen tog så mycket tid. I vissa landsting drogs dessutom tjänster in för att bekosta det budgetöverskridande Cosmic.

− Det är väldigt vanligt att ett system inte alls underlättar för dem det är tänkt för. Det finns bara ett sätt att komma runt detta: upphandlingen måste ­göras av dem som ska ha systemet. Det är bara de som vet vad det behöver klara, säger Torsten Cegrell.

Något annat som är slående i Cosmic-projekten är oförmågan att lära sig av tidigare misstag. De problem som noterades i pilotprojekten återkom när systemet ­implementerades i full skala. Och de problem som noterades i Värmlands landsting 2003 uppstod också i Uppsala året därefter och i Östergötland så sent som 2008.

Med lite god vilja kan man förklara detta med att varje landsting faktiskt genomförde projektet för första gången, varje gång – att Cambio däremot motiverade sina sena och ofullständiga implementeringar med att sjukhusets verksamhet visade sig mer komplex än de hade trott är knappast försvarbart när det gäller tredje, fjärde eller sjunde införandet av samma system. En implementeringsprocess som misslyckats genomfördes ändå på ­exakt samma sätt om och om igen. Den flexibilitet som Standish Group efterlyser lyser med sin frånvaro.

En vanlig orsak till att it-projekt blir tungrodda är att orga­nisationer väljer system som är onödigt komplexa. Torsten Cegrell har träffat många företagsledningar som – felaktigt – trott att det mest avancerade systemet, med den nyaste tekniken är bäst för deras behov. Resultatet blir ofta att oproportionerligt mycket tid går till att lära sig hantera systemet. De onödiga finesserna kan också krångla till de enklare funktionerna, så att mer tid måste läggas på administration, som i fallet med Cambio Cosmic.

– De köper en Rolls-Royce, när de behöver en skottkärra. Det är mycket bättre att koncentrera sig på de funktioner som är nödvändiga och göra dem så bra och enkla som möjligt, säger Torsten Cegrell.

Även här är alltså tydlig kommunikation med slutanvändarna av systemet avgörande för utfallet.

AXE: 90-talets största it-flopp?

Det är lätt att tro att de största misslyckandena utspelar sig inom offentliga sektor – men det är inte riktigt sant.

Visserligen är det betydligt lättare att hitta konkreta exempel på misslyckade projekt som i någon form har varit skatte­finansierade, men det beror framför allt på att utrednin­garna om dessa projekt är offentliga handlingar. Privata företag har helt enkelt betydligt större möjligheter att dölja sina misslyckanden.
Ett av de projekt som sällan nämns annat än i förbi­farten är Axe-N, som genomfördes på Ericsson i slutet av 1980-talet och början av 90-talet – ett projekt som blev så misslyckat att det uppmärksammades i internationella medier och fick långtgående konsekvenser för företaget.

Under 70-talet hade Ericsson och Televerket tillsammans utvecklat telefonväxelsystemet Axe, som blev en stor framgång såväl tekniskt som ekonomiskt. Axe-N, eller Axe 2 som det ibland kallades, var tänkt att bli en vidareutveckling av Axe-växeln. Det talades om unika tekniska lösningar som skulle vara gångbara långt in i framtiden. Man siktade högt – men mer mätbara mål och framför allt konkreta strategier för att nå dit var det inte lika gott om.

Projektet fokuserade på programmering med C++, men man provade också olika komplement. Under en period arbetade man intensivt för att integrera programmeringsspråket Erlang, något som inte alls föll väl ut, och de experimenten avbröts. Men själva projektet fortsatte, trots att det växte och blev mer och mer komplext.

Mellan 1987 och 1995, när det till slut avbröts, arbetade tusentals konsulter med Axe-N. Projektet uppskattas ha kostat mer än 6 miljarder. Ericsson kunde bara återanvända smådelar av systemet, och med facit i hand kan man förstås fråga sig om det inte var en missbedömning av marknaden att satsa så stort på en digital telefonväxel, i en tid när andra slags plattformar redan hade börjat utvecklas. Trots samarbetet med Televerket, som ju var ett steg närmare slutanvändaren, tycks man ha misslyckats med att ta reda på kundernas faktiska behov.

I efterhand konstaterades dessutom att den omfattande användningen av programmering i C++ hade varit ­direkt olämpligt för Axe-N. Slutsatsen blev att det måste vara något fel på själva programmeringsspråket, en uppfattning som länge fanns kvar inom företaget.

Uppenbarligen hade man inte funderat närmare över den sista framgångsfaktorn på Standish Groups lista: det gäller att välja verktyg och hjälpmedel som är anpassade till den situation i vilken de ska användas. Rätt verktyg i fel situation kan skapa precis lika stora problem som ett dåligt verktyg.

Eller som Standish Group uttrycker det: ”a fool with a tool is still a fool”. Precis som många andra gör efter ett fiasko tog Ericsson ett krafttag för att styra upp sina projektstyrnings­rutiner. Det resulterade i Ericssons numera välkända projektstyrningsmodell PROPS, som lanserades i sin första version 1997, två år efter att Axe-N-projektet hade avbrutits.

Lyckade projekt ska bli vardagsmat

Raden av projekt som har misslyckats på ungefär samma sätt som de tre som beskrivs här är lång. Projekt med otydliga mål, ospecifika systemkrav och diffus budget. Projekt utan stöd i ledningen eller förankring hos användarna. Projekt som greppar om för mycket och klamrar sig fast vid en stelbent planering, utan att ­anpassa processen efter omständigheter som förändrar sig under gång.

Denna kollektiva erfarenhet av misstag kan kännas nedslående, men det går att göra rätt!

– Jag har sett många it-projekt som har varit oerhört framgångsrika, säger Torsten Cegrell – projekt som har varit både stora och komplexa.

Det du aldrig får underskatta är förarbetet. Gör en ordentlig kartläggning av vad systemet behöver klara. Och – lika viktigt, vad det inte behöver klara. Allt i samråd med slutanvändaren. Och säkerställ ledningens stöd.
− Det är helt och hållet en utbildningsfråga och en attitydfråga. Företagsledningen måste våga sätta sig in i it-frågor, ­säger Torsten Cegrell som i grunden är optimist och menar att det inte ens behöver vara särskilt svårt.

Den attityd som länge har varit rådande i svenska företag uppstod, enligt Torsten Cegrell, på 1980-talet. I takt med att it-systemen blev mer och mer komplexa blev allt färre personer i ledningsposition beredda att sätta sig in i hur de fungerade. Istället valde man att leja ut it-frågorna till externa konsulter, som visserligen var duktiga på it, men inte kunde den verksamhet som it-systemen skulle stödja. Detta beskriver Cegrell som ett fatalt misstag, som har kostat många företag och organisationer mångmiljonbelopp i misslyckade it-projekt. Nu ser han dock en ljusning.

− Allt fler företag har insett fördelarna med att ha CIO i ledningsgruppen, och att låta CIO rapportera direkt till vd. Och det är väldigt bra, säger han.

I takt med att företagsledningarna skaffar sig större insyn i hur it-systemen fungerar hoppas han att andelen lyckade it-projekt kommer att öka.
– Det finns ingen anledning till att det ska behöva se ut som det gör idag, säger han. Brist på kunskap, det är egentligen det allt beror på, konstaterar han.

Och kunskap om hur man ska göra finns att få. Det räcker med en enkel sökning på nätet för att hitta information om omfattande studier som undersöker hur man bör genomföra ett it-projekt, studier som den av Standish Group.

Dessutom finns det mängder av analyser av misslyckade projekt, komplett med slutsatser om hur man borde ha gått tillväga. Det är kunskap som har funnits tillgänglig i många år redan. Varför tycks företag och organisationer vara så ovilliga att lära av andras misstag?

En anledning kan vara känslan av att den egna verksamheten är unik. Ett projekt är per definition någonting som bara genomförs en enda gång – och dagens projekt är ofta mycket komplexa. Det kan i förstone kännas märkligt att jämföra sig med organisationer vars verksamhet är väsensskild från ens egen, men sistone är det ofta väldigt lärorikt.

Självklart kommer exempelvis kravspecifikationens innehåll och utseende att skilja sig radikalt mellan olika projekt – däremot är vikten av att ha en kravspecifikation som är konkret och begriplig, och formulerad i samråd med slutanvändaren, densamma oavesett verksamhet och bransch.

Vi behöver inte driva igenom fler överdrivet dyra projekt som drar ut på tiden för att lära oss hur man inte ska göra.

Om bara ledningsgrupper sätter sig in i sina företags it-lösningar, och prioriterar att genomföra it-projekt så som de är tänkta att genomföras, kommer några skandalrubriker snart inte vara nödvändiga. Som Torsten Cegrell brukar säga: lyckade it-projekt ska bli vardagsmat.

Liv Marcks von Würtemberg doktorerar i industriell information och kontrollsystem på KTH.