Varför IT- och säkerhetsprojekt kör fast – fem problem som sällan är tekniska

Publicerad 5 oktober 2026

Sammanfattning: IT- och säkerhetsprojekt misslyckas sällan för att projektgruppen inte kan skapa fler aktiviteter i projektplanen. Problemen börjar ofta tidigare: otydligt mandat, oklar målbild, bristande verksamhetsägarskap, beroenden som inte hanteras och ett projekt som aldrig övergår till fungerande förvaltning. Det gäller särskilt säkerhets- och regelverksprojekt där IT, ledning, juridik, risk, inköp och verksamhet behöver arbeta tillsammans.

Ett projekt kan ha projektplan, styrgrupp, egen samarbetsyta, risklogg och hundratals aktiviteter. Och ändå stå nästan still.

Statusrapporten säger att projektet är 72 procent klart. Men ingen kan riktigt svara på vad som faktiskt blivit bättre i verksamheten.

Det är ett problem vi tycker är särskilt vanligt i komplexa IT-, informationssäkerhets- och regelverksprojekt. Tekniken är ofta lösbar. Det svåra är organisationen runt omkring.

ISO 21502:2020 ger vägledning för projektledning och är medvetet metodneutral. Den beskriver koncept, praktiker och ansvar för att initiera, planera, styra, kontrollera och avsluta ett projekt oavsett storlek, bransch och leveransmodell, och kan användas tillsammans med både traditionella, agila och hybrida arbetssätt. Men ingen metod ersätter behovet av fungerande styrning.

Här är fem problem som ofta skapar betydligt mer friktion än den tekniska lösningen.

1. Projektet saknar en riktig ägare

Det står ett namn under rubriken sponsor. Men när projektledaren behöver beslut är sponsorn aldrig tillgänglig. Eller så finns en styrgrupp med åtta personer där ingen riktigt har mandat att bestämma.

Det leder till väntan, eskalering, nya möten och omtag. Ett projekt behöver någon som kan prioritera, ta beslut, lösa konflikter och säkerställa resurser.

ISO 21505:2017 om styrning av projekt, program och portföljer riktar sig uttryckligen till styrande organ och till högsta ledningen, alltså de som påverkar eller fattar beslut om styrningen, och ger även vägledning till dem som leder projekt, som sponsorer, styrgrupper, portföljägare och projektkontor.

Det är alltså inte bara projektledarens problem. Projektet behöver styrning ovanifrån. PMI pekade i samma riktning i en studie från 2014: aktivt engagerade sponsorer beskrevs som den enskilt viktigaste faktorn för att projekt och program ska lyckas, samtidigt som färre än två tredjedelar av projekten hade en utsedd sponsor. Siffran är inte ny, men poängen gäller fortfarande: projektet behöver en beslutsfattare med mandat och faktisk möjlighet att agera.

En enkel kontrollfråga

Fråga sponsorn: vilka tre beslut får bara du fatta i det här projektet? Om svaret är oklart behöver mandatet förtydligas.

2. Ingen är överens om vad klart betyder

Projektet börjar med att vi ska anpassa verksamheten till cybersäkerhetslagen. Vad betyder det i praktiken? Att alla policyer är klara? Att alla identifierade risker är åtgärdade? Att ledningen är utbildad? Att incidentprocessen är etablerad? Att leverantörerna är bedömda? Att organisationen är redo för tillsyn? Eller bara att en gap-analys är genomförd?

Samma problem finns i IT-projekt. Migrera till Microsoft 365. Är projektet klart när licenserna är köpta? När postlådorna är flyttade? När villkorlig åtkomst är införd? När användarna är utbildade? När den gamla miljön är avvecklad?

En otydlig målbild skapar nästan alltid diskussioner om omfattning senare. Därför behöver projektet tidigt definiera:

• Vad ska förändras?
• Hur ser vi att förändringen fungerar?
• Vad ingår inte?

Det är mer användbart än ett långt aktivitetsregister.

3. Verksamheten har inte tid att delta

Det här är kanske det vanligaste praktiska problemet. Projektplanen säger workshop med systemägare vecka 3. Systemägaren säger att det är bokslut. Projektet behöver HR, som har ett annat systemprojekt. Projektet behöver inköp, som har upphandlingar.

Alla tycker projektet är viktigt. Men ingen har avsatt tid.

Särskilt säkerhets- och regelverksprojekt kräver ofta människor som inte arbetar i projektet på heltid: IT, juridik, dataskydd, risk, inköp, systemägare, HR, verksamhet och ledning.

Därför behöver resursbehovet göras konkret. Inte att verksamheten behöver delta, utan att systemägaren behöver avsätta två timmar för intervju, tre timmar för workshop och godkänna resultatet senast fredag. Det gör resurskonflikten synlig innan den stoppar projektet.

4. Beroendena upptäcks för sent

Ett projekt består nästan aldrig bara av sina egna aktiviteter.

• Microsoft 365-projektet är beroende av nätverket.
• Cybersäkerhetslagsprojektet är beroende av leverantörsinventeringen.
• ISO 27001-projektet är beroende av informationsklassningen.
• DORA-projektet är beroende av avtal.
• Backup-projektet är beroende av lagring och nätkapacitet.
• Incidentprojektet är beroende av HR, juridik och kommunikation.

Problemet är att aktivitetslistan ofta fokuserar på vad vi ska göra och för lite på vad som måste vara sant för att vi ska kunna göra det.

Fråga för varje huvudaktivitet:

• Vad väntar vi på?
• Vem väntar vi på?
• Vad händer om detta blir två månader sent?
• Kan vi göra något parallellt?

Beroenden behöver vara en del av projektstyrningen, inte en överraskning.

5. Projektet levererar, men ingen tar över

Det här är det mest frustrerande utfallet. Projektet genomförs. Slutrapporten skrivs. Styrgruppen tackar projektgruppen. Projektet stängs.

Sex månader senare uppdaterar ingen riskregistret. Ingen följer upp leverantörerna. Ingen äger processen. Kontrollen som implementerades används inte längre. Dokumentationen är inaktuell.

Projektet levererade alltså. Men förändringen överlevde inte projektet.

Därför behöver förvaltning planeras långt innan avslut. För varje ny förmåga behöver organisationen veta:

• Vem äger den efter projektet?
• Hur ofta ska den genomföras?
• Vilken budget finns?
• Hur följs den upp?
• Vilka nyckeltal eller kontroller används?
• Vilket forum fattar framtida beslut?

Det är först då projektets resultat blir en del av verksamheten.

Säkerhetsprojekt är ofta transformationsprojekt

Ett projekt kring cybersäkerhetslagen kan se ut som ett regelverksprojekt. Men i praktiken kan organisationen behöva förändra riskprocesser, leverantörsstyrning, incidenthantering, backup, ledningsrapportering och tekniska kontroller. Det är verksamhetsförändring.

Ett ISO 27001-projekt är inte bara att skriva dokument för ledningssystemet. Organisationen behöver etablera ett ledningssystem som fortsätter fungera. Vi har skrivit om skillnaden mellan olika granskningsformer i vår insikt om gap-analys, internrevision och förrevision.

På samma sätt är ett Microsoft 365-projekt inte bara en migrering om det samtidigt förändrar identiteter, enheter, samarbete, informationsdelning och säkerhetsmodell.

Därför behöver projektledaren förstå mer än tidplanen. Projektledaren behöver förstå vilken verksamhetsförmåga projektet försöker skapa.

Projektstyrningen behöver vara proportionerlig

Mer styrning är inte automatiskt bättre. Ett treveckorsprojekt behöver inte fem styrgruppsmöten, tre statusrapporter och ett åttiosidigt projektdirektiv. Men ett komplext transformationsprogram behöver mer än ett möte på fredagar.

ISO 21502 är metodneutral och kan användas med olika angreppssätt. Det tycker vi är en bra princip: metoden ska passa projektet, inte tvärtom.

Vad behöver styrgruppen egentligen veta?

En bra statusrapport bör inte bara säga grön, gul eller röd. Styrgruppen behöver kunna förstå:

• Vad har levererats?
• Vilka beslut behövs?
• Vilka risker hotar målet?
• Vilka beroenden ligger efter?
• Behövs mer resurser?
• Har omfattningen förändrats?
• Är den förväntade nyttan fortfarande realistisk?

Styrgruppens jobb är inte att lyssna på projektledaren läsa statusrapporten. Det är att styra projektet.

Mät effekt, inte bara aktivitet

Ett projekt kan rapportera 14 genomförda workshops, 22 skrivna policyer och 160 migrerade användare. Det är relevant. Men det säger inte alltid om projektet lyckats.

Ett säkerhetsprojekt kan exempelvis även följa:

• Har identifierade högriskgap stängts?
• Vet processägarna vad de ansvarar för?
• Kan incidentorganisationen använda den nya processen?
• Har kritiska leverantörer bedömts?
• Fungerar den tekniska kontrollen?

Det flyttar fokus från vad projektet producerade till vad projektet förändrade.

Fem frågor innan projektet startar

1. Vem äger resultatet? Inte projektplanen, resultatet.
2. Vad betyder klart? Definiera konkret.
3. Vilka verksamhetsresurser behövs? Och finns tiden faktiskt avsatt?
4. Vilka är våra viktigaste beroenden? Internt och externt.
5. Vem tar över när projektet stängs? Om den frågan inte har ett svar har projektet ett framtida problem redan innan det börjat.

Så kan Kristensson i Skåne stödja

Kristensson i Skåne arbetar med projektledning inom IT, informationssäkerhet, cybersäkerhet, dataskydd, ISO 27001, cybersäkerhetslagen, DORA, tekniska implementationer och regulatoriska program.

Stödet kan omfatta:

• projektstart och avgränsning
• projekt- och programledning
• styrgruppsarbete
• risk- och beroendehantering
• färdplan
• leverantörsstyrning
• delprojekt och arbetsströmmar
• ledningsrapportering
• implementering
• överlämning till förvaltning

Vår utgångspunkt är att ett projekt inte är lyckat för att projektplanen blev grön. Det är lyckat när verksamheten kan använda det som projektet skulle skapa.

För större regelverksprogram med flera arbetsströmmar har vi ett särskilt erbjudande inom projektledning för regelverksprogram.

Vanliga frågor

Har ni ett projekt som inte rör sig framåt? Läs mer om vår projektledning inom IT, säkerhet och regelefterlevnad eller kontakta oss för ett förutsättningslöst samtal.

Källor: ISO 21502:2020, Project, programme and portfolio management – Guidance on project management (gällande utgåva; en ny utgåva är under arbete); ISO 21505:2017, Guidance on governance; Project Management Institute (PMI), Pulse of the Profession om sponsorers engagemang som främsta framgångsfaktor (2014). Verifierat 2026-09-09; PMI och ISO 21502 kontrollerade igen 2026-10-03.

Den här texten är allmän information. Vilken projektstyrning som passar beror alltid på projektets storlek, risk och komplexitet.