Det finns en rad vanliga misstag i IT-projekt och när Västra Götalandsregionen skulle införa Millenium så betade man av de flesta. Här är fem lärdomar som du som sitter i en styrgrupp kan ta fram när det hettar till i ditt projekt.
Boken ”Milleniumskandalen – Journalsystemet som havererade” av Simon Campanello (Bonniers 2026) är som en skräckroman för alla som arbetar med digital utveckling. Men det som skildras är inte unikt – IT-projekt som havererar förekommer i både offentlig och privat sektor. Skillnaden är att haverier i näringslivet sällan omfattas av offentlighetsprincipen. Det här är en väldigt välskriven och välgrundad bok, men mitt syfte är inte att recensera den. Jag vill framförallt lyfta fram de fem viktigaste misstagen i Milleniumprojektet – så att du som är projektledare, processansvarig eller medlem i styrgruppen aldrig ska behöva upprepa dem.
Det ska understrykas att det går tretton experter på dussinet som kan berätta hur de egentligen borde ha gjort. Det ska vi inte diskutera här. Jag plockar helt enkelt fram de tydligaste misstagen som jag – med omkring trettio års erfarenhet – ser som tydligaste signaler på att projektet varit på fel väg (och mår som sämst av att läsa skildringen av).
Vad var Milleniumprojektet?
Med Millenium ville Västra Götalandsregionen ersätta sina uttjänta system med ett nytt sjukvårdssystem – ”världens mest moderna vårdinformationsmiljö”. Initiativet kom från regionpolitiken och presenterades redan i maj 2013. Många år och flera miljarder kronor senare sjösattes en fallfärdig pilotversion av systemet. Projektet stoppades efter tre dagars drift och i februari 2026 fattade regionens politiker beslutet att skrota Millenium för gott.
Det är inte svårt att förstå varför det kallas en skandal.
De 5 största misstagen – och hur du undviker dem
1. Färdigt system + tusentals anpassningar = dålig idé
En av de mest uppenbara bristerna var ambitionen att köpa in ett befintligt system. Tanken var god: om det redan fungerar i andra verksamheter av samma storlek, så borde man vinna mycket på att anpassa sig till det. Men här blandades två oförenliga saker ihop.
Man köpte en färdig produkt som man sedan inte bara ville konfigurera, utan förändra med tusentals egna krav. Utöver att det är en dålig kombination, så accepterade projektledningen att de anpassningar som byggdes specifikt för Västra Götalandsregionen inte behövde vara lika intuitiva och lättanvända som systemet i övrigt. Det är ett vanligt misstag att man på beställarsidan ägnar oproportionerligt mycket tid åt att hämta in krav från verksamheten, men avsätter för lite tid för att sätta sig och leverantören in i vad de innebär och får för konsekvenser.
Om beställaren inte förstår sina krav, så kommer inte leverantören att göra det heller. Det var precis vad som hände här.
Om du köper ett standardsystem, se till att anpassningar inte förstör dess grundläggande funktion. Ett system med 1256 anpassningar som fungerar sämre än originalet är ingen lösning.
2. Kvalitetssäkring? ”Vi hinner inte.”
I utvecklingsprojekt sätter man ofta upp en stegvis process, där alla punkter i en delleverans ska godkännas innan man går vidare till nästa fas. Det är ju seriöst och genomtänkt. Men då måste man också hålla sig till den processen. I Milleniumprojektet åsidosattes denna process konsekvent – och detta är häpnadsväckande – med motiveringen att man annars inte skulle hinna bli färdig i tid. Att sätta upp rigida processer som man sedan struntar i är en mycket kraftig varningssignal.
Ett angränsande område är riskanalys. Svårigheter tycks ha viftats bort med argumentet att ”det löser sig när leverantören lever upp till sina åtaganden”. Så kan man inte hantera risk. En riskanalys som inte tar hänsyn till riskernas allvar är ingen riskanalys alls.
Om du som sitter i en styrgrupp ser att den överenskomna processen ignoreras, så måste du reagera. Om problemet är tidsplanen, ändra då den – inte kvalitetssäkringen.
3. Förankring som bara finns på pappret
Under hela projekttiden var verksamheten inblandad. Medarbetarna ”på golvet” fick komma med förslag, testade tidiga prototyper och dokumentera sina arbetsrutiner i workshops. Men ledde det till något? Det verkar tvärtom som att denna del av projektet aldrig fick någon effekt. Man samlade in underlaget, men ingen tycks ha tagit hand om det.
När det började närma sig lansering, så skulle naturligtvis medarbetarna få utbildning i systemet. Men systemet var inte ens halvfärdigt och utbildningsmomentet kortades, försenades och genomfördes inte i den miljö som senare skulle driftsättas. ”Du får lära dig på det här sättet, men det kommer inte att se ut så här när du ska jobba med det.”
Förankring som inte har någon innebörd är inte bara slöseri med tid, resurser och förtroende – det är ett säkert sätt att få allvarliga problem i ett senare skede.
4. När tid blir viktigare än kvalitet
Inom projektledning talar man ofta om scope creep – problemet med att hålla sig till projektets bestämda omfattning. I Milleniumprojektet kan man tala om ett strategiskt scope creep.
Det viktigaste målet var förstås att skaffa ett bra system för regionens sjukvård. Med tiden blev det istället – outtalat – att leverera i tid som var viktigast.
Vi diskuterar inte att skjuta upp. Vi ska ha ett patientsäkert driftsättande och har en beslutsprocess på plats för hur vi ska fatta de besluten. Vi är fullt fokuserade på driftsättningsdatumet och allt arbete nu handlar om att allt ska fungera bra då, säger regionens hälso- och sjukvårdsutvecklingsdirektör till Borås Tidning, citerad i boken.
Det är förståeligt att man vill bli klar i tid, men att offra kvalitet för tid är ett allvarligt avsteg från både planen och intentionen bakom projektet.
5. Mörka läget och skylla på andra
Ju närmare det planerade lanseringsdatumet kom, desto mer mörkade de ansvariga situationen. För politiken, för beslutande delar högre upp i organisationen, för verksamheten. ”Det är i princip färdigt”. Det är kanske en mänsklig reaktion när det du är satt att sköta rinner dig ur händerna. De kan mycket väl ha mörkat också för sig själva, för att slippa se katastrofen i vitögat. Till slut inleddes nästa fas i förnekelsen: Man började skylla på andra och varandra.
Det här vet alla som har varit med i hetluften är en mycket dålig lösning.
Mörka aldrig hur det går. Det kommer du att få äta upp senare.
De viktigaste lärdomarna av vanliga misstag i IT-projekt
För att sammanfatta det viktigaste vi kan ta med oss från ”Milleniumskandalen”:
- Köp gärna ett färdigt system. Bygg gärna ett eget. Men försök inte göra båda sakerna samtidigt.
- Följ processen. Om tidspress hotar kvalitetssäkring och utbildning, justera tidsplanen – inte processen.
- Förankra på riktigt – involvering måste leda till handling och påverkan, inte bara dokumentation.
- Håll fast i det viktigaste målet – syftet med projektet måste alltid vara viktigare än att leverera det ett visst datum.
- Var transparent – Mörka aldrig problem. De kommer bara att växa sig starkare och svårare att hantera.
Milleniumprojektet är ett extremt exempel, men misstagen är inte unika. Genom att lära av dem kan du undvika att hamna i samma fälla. Tack till Simon Campanello, som tog sig tid och energi att ge sig in i detta djupt nedslående haveri – ett viktigt arbete.
Foto
Veronika Ljung-Nielsen, pressfoto från Bonniers.
