Varför fastnar IT-projekt? Det är sällan tekniken

Kompetenta team kan arbeta länge utan att leverera. Oftast beror det inte på tekniken, utan på ägarskap, krav och en gemensam definition av klart.

Dotun Ogunkanmi · 2026-11-04 · 4 min läsning

När ett IT-projekt drar ut på tiden letar man nästan alltid efter felet i tekniken. Fel plattform, fel arkitektur, fel leverantör eller för lite kompetens i teamet. Ibland stämmer det. Men i de flesta försenade projekt jag har sett, och i de jag själv har stått mitt i, har tekniken sällan varit det egentliga problemet.

Ett mönster som går igen

Mönstret ser ofta ut ungefär så här. Ett kompetent utvecklingsteam ser verksamhetens problem och vill lösa dem. Teamet tar fram idéer, bygger under en längre period och visar resultatet när det känns färdigt. Då visar det sig att lösningen inte riktigt passar – behoven har ändrats, eller så gällde de aldrig mer än en del av verksamheten. Teamet bygger om, omfattningen växer och ingen kan säga exakt när något är klart.

Det svåra med mönstret är att alla gör sitt bästa. Utvecklarna arbetar hårt och vill göra skillnad. Verksamheten har fullt upp med att leverera till kunderna. Ledningen väntar på resultat. Ändå kommer man ingenstans, och efter ett tag uppstår en frustration på alla håll som gör det ännu svårare att samarbeta.

Egen utveckling kräver en beställare

Kärnan är nästan alltid densamma: organisationen förväntar sig samma sak av egen utveckling som av ett färdigt standardsystem – att något levereras och fungerar. Men när man bygger själv är verksamheten inte bara användare. Den är beställare och ägare. Den behöver vara med och formulera vilka behov som ska lösas, prioritera, testa och säga ifrån tidigt.

Den förmågan – att beställa och äga utveckling – finns sällan av sig själv. Det handlar inte om ovilja. Det är bara sällan någon har förklarat att den behövs, eller avsatt tid och mandat för den.

Tre principer som brukar lösa upp knuten

Det som hjälper är sällan tekniskt. Det börjar med ledningen och de chefer som äger verksamheten, och med tre principer:

Utveckling är en cykel, inte ett lopp med en mållinje. Man släpper något, lär sig av det och förbättrar. Det kräver att verksamheten är med hela vägen, inte bara i början och i slutet.
Verksamheten äger det som byggs. Varje lösning behöver en tydlig ägare i verksamheten som formulerar behoven, prioriterar och tar emot leveransen.
Standardisera innan ni digitaliserar. Det går inte att bygga bra mjukvara för en verksamhet där varje kund eller avdelning får sin egen variant. Det man vill digitalisera måste först vara definierat.

Det hjälper också att utveckling och IT-drift arbetar under ett gemensamt ansvar. När de som bygger och de som driftar har olika chefer och olika mål blir överlämningarna ofta det svagaste ledet.

En gemensam definition av klart

Det enskilt mest effektiva verktyg jag känner till är också det enklaste: att ledning, verksamhet och utveckling tillsammans skriver ner vad som måste fungera innan en lösning tas i bruk – och vad som kan vänta till nästa version. Vem godkänner leveransen? Hur vet vi att den fungerar? Vad räknas uttryckligen inte in?

När den överenskommelsen finns slutar diskussionen handla om vem som har rätt och börjar handla om vad som saknas. Jag har sett lösningar som stått still länge komma i drift inom några månader när den pusselbiten kom på plats.

Lanseringen är bara halva jobbet

Att en lösning är klar betyder inte att den används. Ofta ska många människor lära sig ett nytt arbetssätt – ibland även personer hos partner och underleverantörer som inte är anställda i bolaget. Det kräver en ansvarig chef i verksamheten, en plan för utbildning och uppföljning, och en kultur där man ger återkoppling i stället för att ge upp när något inte fungerar direkt. Det förtjänar en egen artikel.

Fem tecken på att ert projekt har fastnat av fel skäl

Teamet bygger lösningar som de själva har kommit fram till, och visar dem för verksamheten först när de är "klara".
Ingen i verksamheten kan svara på vem som äger lösningen och prioriterar nästa steg.
Det finns ingen gemensam, nedskriven definition av när en leverans är klar.
Varje kund eller avdelning förväntar sig en egen variant av lösningen.
Utveckling och drift har olika chefer och pratar sällan med varandra.

Känner ni igen två eller fler av dem hjälper det sällan med ny teknik, fler utvecklare eller en ny leverantör. Det som behövs är ägarskap, prioritering och ett gemensamt språk mellan verksamhet och IT.

Tekniken är oftast den lätta delen

När ett projekt har fastnat är det lätt att leta efter någon att skylla på. Men oftast handlar det inte om enskilda personer, utan om ett arbetssätt där ingen har fått tydligt ansvar för helheten. Med tydligt ägarskap, en gemensam definition av klart och en ledning som tar sin roll kan samma människor leverera på några månader det som tidigare tog år.