De flesta IT-projekt startar inte med en dålig idé.
Tvärtom. Det finns ofta ett tydligt behov: ett affärssystem ska bytas, manuella processer ska automatiseras, flera system ska integreras eller en gammal lösning behöver ersättas.
Ändå händer det att projekt drar över tiden, kostar mer än planerat eller levererar något som verksamheten inte riktigt kan använda.
Det är lätt att skylla på tekniken.
Men många problem i IT-projekt börjar långt innan någon utvecklare skriver den första raden kod eller någon konsult konfigurerar det första systemet.
De börjar i sena beslut, otydliga mål, bristande ansvar, otillräcklig verksamhetsinvolvering eller en plan som bygger på att allt ska gå exakt som tänkt.
I den här artikeln går vi igenom några av de vanligaste orsakerna till att IT-projekt hamnar fel – och vad ni kan göra för att minska risken.
Vill ni ha en bredare genomgång av hur ett IT-projekt kan struktureras från start till mål kan ni även läsa vår kompletta guide om IT-projektledning.
1. Projektet startar med en lösning istället för ett problem
Ett vanligt misstag är att projektet börjar ungefär så här:
Vi behöver införa system X.
eller:
Vi behöver bygga en integration mellan system A och B.
Det kan mycket väl vara rätt lösning. Problemet är att organisationen ibland hoppar över frågan som borde komma först:
Vad försöker vi egentligen förbättra?
Kanske är det verkliga problemet att order registreras manuellt i flera system. Kanske är rapporteringen för långsam. Kanske behöver ekonomiavdelningen bättre kontroll över en process.
Om projektet inte är tydligt med problemet blir det svårt att avgöra vilka krav som faktiskt är viktiga.
Projektgruppen riskerar då att optimera själva lösningen istället för verksamhetsresultatet.
Så minskar ni risken
Formulera projektets mål i verksamhetstermer innan lösningen definieras i detalj.
Istället för:
”Implementera ett nytt orderhanteringssystem.”
kan målet exempelvis vara:
”Minska den manuella hanteringen av kundorder och skapa ett mer tillförlitligt informationsflöde från order till leverans.”
Det ger projektet en bättre kompass när prioriteringar senare behöver göras.
2. Kraven är tydliga på papperet – men inte i verkligheten
Ett långt kravdokument är inte samma sak som tydliga krav.
Det går att dokumentera hundratals funktioner utan att projektgruppen egentligen har en gemensam förståelse för hur verksamheten ska arbeta.
Problemet märks ofta sent.
En lösning har byggts enligt specifikationen, men när användarna börjar testa visar det sig att viktiga undantag saknas, att två avdelningar arbetar på olika sätt eller att ett krav tolkats olika av beställaren och leverantören.
Då blir frågan inte längre vad som ska byggas.
Frågan blir vem som har “rätt”.
Det är sällan ett bra läge för ett projekt.
Så minskar ni risken
Koppla krav till konkreta verksamhetsscenarier.
Fråga exempelvis:
- Vem använder funktionen?
- När används den?
- Vilken information behövs?
- Vad händer före och efter steget?
- Vad händer om något går fel?
- Vilka undantag finns?
Det gör kraven lättare att förstå, prioritera och testa.
Det viktigaste är inte att dokumentera mest. Det är att skapa samma bild av vad som faktiskt ska fungera när projektet är klart.
3. Ingen vet riktigt vem som får fatta beslut
Ett IT-projekt kan ha en styrgrupp, en projektledare, en systemägare, flera verksamhetsrepresentanter och ett antal leverantörer.
Ändå kan viktiga beslut bli liggande.
Det händer exempelvis när två avdelningar vill olika saker och ingen har mandat att prioritera, eller när projektgruppen väntar på ett verksamhetsbeslut som inte har någon tydlig ägare.
Under tiden fortsätter projektet.
Utvecklare arbetar vidare med antaganden. Andra aktiviteter skjuts fram. En liten försening skapar nya förseningar längre fram.
Det här är ett av de tydligaste exemplen på att ett projekt kan vara fullt av aktivitet utan att faktiskt komma framåt.
Så minskar ni risken
Bestäm tidigt:
- vem som äger projektets affärsmål
- vem som får prioritera mellan krav
- vem som fattar beslut om budget och omfattning
- vilka beslut projektledaren kan ta själv
- vilka frågor som måste lyftas vidare
- hur snabbt viktiga beslut behöver fattas
Projektets beslutsvägar är minst lika viktiga som projektplanen.
4. Verksamheten är involverad – men har egentligen inte tid
På projektplanen kan det stå att verksamheten ska delta i workshops, kravarbete och testning.
I verkligheten har samma personer fortfarande sina vanliga roller.
Månadsbokslut ska genomföras. Kunder ska hanteras. Leveranser ska gå ut. Den dagliga verksamheten stannar inte för att ett IT-projekt pågår.
Resultatet blir lätt att de personer som bäst förstår processen inte deltar tillräckligt tidigt.
Istället får de se lösningen när stora delar redan är klara.
Då blir återkopplingen dyr.
Så minskar ni risken
Behandla verksamhetens tid som en faktisk projektresurs.
Om en nyckelperson behöver lägga en dag i veckan på projektet behöver den tiden planeras på riktigt.
Det innebär också att chefer och projektägare behöver förstå konsekvensen av att projektarbete hela tiden prioriteras bort till förmån för linjearbetet.
Verksamhetsinvolvering är inte bara en punkt i projektorganisationen. Det är en kapacitetsfråga.
5. Projektet underskattar sina beroenden
IT-system lever sällan isolerade.
Ett affärssystem kan vara kopplat till CRM, e-handel, lager, fakturering, rapportering och externa partners. Data som förändras på ett ställe kan påverka flera processer längre fram.
Det gör att en relativt enkel förändring ibland får oväntat stora konsekvenser.
Ett nytt fält kanske behöver skickas genom tre integrationer. Ett systembyte påverkar rapporter som ingen tänkte på under förstudien. En process som såg enkel ut visar sig vara beroende av data från ett gammalt system.
Beroenden som upptäcks sent är ofta dyra eftersom flera delar av projektet redan hunnit anpassas efter den ursprungliga bilden.
Så minskar ni risken
Kartlägg systemlandskapet och informationsflödena tidigt.
För varje berörd process är det värt att fråga:
- Var uppstår informationen?
- Vilket system är källa?
- Vilka andra system använder informationen?
- Hur överförs den idag?
- Vilka integrationer påverkas?
- Vem äger respektive system?
- Vilka andra projekt pågår samtidigt?
Det behöver inte innebära månader av analys.
Men projektgruppen behöver förstå helheten innan förändringar börjar göras i enskilda delar.
6. Projektets omfattning växer utan att något annat förändras
Ett vanligt IT-projekt börjar med en definierad omfattning.
Sedan dyker det upp nya önskemål.
“När vi ändå gör det här…”
“Det borde inte vara så svårt att lägga till…”
“Kan vi inte passa på att…”
Varje enskilt önskemål kan låta rimligt. Problemet uppstår när de tillsammans förändrar projektet utan att tidplan, budget eller resurser justeras.
Projektet får mer att göra men förväntas fortfarande leverera på samma datum.
Till slut är förseningar nästan oundvikliga.
Så minskar ni risken
Gör förändring till en synlig del av projektstyrningen.
När ett nytt krav kommer in bör projektet kunna svara på:
- Vilket värde skapar förändringen?
- Hur mycket arbete innebär den?
- Påverkar den andra delar?
- Vad händer med tidplanen?
- Behöver något annat prioriteras bort?
Det betyder inte att projektet ska säga nej till förändring.
Det betyder att förändringar ska vara medvetna beslut.
7. Projektplanen blir ett facit istället för ett styrverktyg
En projektplan behövs.
Men den blir problematisk när organisationen börjar behandla den som ett löfte om hur verkligheten ska utvecklas.
I komplexa IT-projekt finns alltid sådant som inte går att veta från början.
Tekniska frågor upptäcks. Krav förändras. Leverantörer blir sena. Testning visar problem som behöver lösas.
En plan som aldrig får ändras blir därför snabbt mindre användbar.
Samtidigt fungerar det inte att helt släppa planeringen.
Bra projektledning behöver balansera båda.
Så minskar ni risken
Använd planen för att upptäcka avvikelser, inte för att dölja dem.
Om en aktivitet tar längre tid än väntat är den viktiga frågan inte:
Hur får vi planen att fortfarande se grön ut?
utan:
Vad innebär det här för projektet, och vad behöver vi göra nu?
En uppdaterad realistisk plan är betydligt mer värdefull än en ursprunglig plan som ingen längre tror på.
8. Testningen kommer för sent
Testning är en av de delar som ofta komprimeras när ett projekt börjar få ont om tid.
Det är förståeligt.
När utveckling eller konfigurering är sen finns ett fast lanseringsdatum kvar. Någonstans måste tiden tas ifrån.
Problemet är att sen eller otillräcklig testning flyttar risken från projektet till verksamheten.
Det är särskilt farligt när flera system ska fungera tillsammans.
En order kan fungera korrekt i affärssystemet och integrationen kan fungera tekniskt, men hela processen från kundorder till leverans och fakturering kan ändå innehålla problem.
Så minskar ni risken
Planera testningen samtidigt som resten av projektet.
Tänk i flera nivåer:
Fungerar funktionen?
Fungerar integrationen?
Fungerar hela verksamhetsprocessen?
Fungerar de viktigaste undantagen och felsituationerna?
Det sista är lätt att glömma.
System fungerar sällan exakt som tänkt varje gång. Projektet behöver också veta vad som händer när data saknas, en tjänst ligger nere eller en användare gör något oväntat.
9. Alla rapporterar status – men ingen pratar om verkligheten
Statusrapportering kan bli märkligt i projekt.
Aktiviteter markeras gröna. Procent färdigställande rapporteras. Presentationer uppdateras.
Samtidigt vet projektgruppen att ett tekniskt problem kan påverka lanseringen om två veckor.
Problemet behöver inte vara att någon försöker dölja något.
Ofta finns en mänsklig tendens att vilja lösa problemet innan det eskaleras.
“Vi jobbar på det.”
“Vi tror att det går att lösa.”
“Vi behöver bara några dagar till.”
Plötsligt finns det inte längre några dagar kvar.
Så minskar ni risken
Skapa en projektkultur där problem får synas tidigt.
Projektledningen behöver kunna skilja mellan:
- något som har gått fel
- någon som har gjort fel
Om varje problem automatiskt blir en skuldfråga kommer problem att rapporteras senare.
Om avvikelser istället används som beslutsunderlag får organisationen större chans att faktiskt agera.
Bra projektstyrning gör dåliga nyheter användbara.
10. Projektet fokuserar på go-live – inte på vad som händer efteråt
Det är lätt att se produktionssättningen som mållinjen.
Projektgruppen har arbetat i månader. Det nya systemet går live. Projektet firar.
Sedan börjar användarna arbeta i lösningen.
Frågor uppstår. Data behöver rättas. Integrationer behöver övervakas. Någon behöver ta emot supportärenden. Mindre förändringar behöver prioriteras.
Om förvaltningen inte är förberedd blir projektorganisationen snabbt kvar längre än planerat, samtidigt som det är oklart vem som egentligen ansvarar för lösningen.
Så minskar ni risken
Planera förvaltningen innan go-live.
Det bör vara tydligt:
- vem som äger lösningen efter projektet
- vem som tar emot supportfrågor
- hur fel och förbättringar ska prioriteras
- vilken dokumentation som behöver lämnas över
- hur integrationer och andra tekniska flöden ska övervakas
- vilka personer som behöver kunskap innan projektorganisationen upplöses
Ett lyckat IT-projekt levererar inte bara ett system.
Det lämnar efter sig en lösning som organisationen kan äga och vidareutveckla.
Så ser ett välstyrt IT-projekt ut i praktiken
Det finns ingen modell som garanterar att ett IT-projekt lyckas.
Men välstyrda projekt har ofta några gemensamma egenskaper.
Projektgruppen vet vilket verksamhetsproblem den försöker lösa.
Ansvar och beslutsvägar är tydliga.
Verksamheten är faktiskt involverad, inte bara representerad i organisationsschemat.
Risker och problem lyfts innan de blir akuta.
Förändringar får konsekvenser för planeringen istället för att bara läggas ovanpå befintligt arbete.
Testning och förvaltning behandlas som delar av projektet, inte som aktiviteter som kommer sist om det finns tid kvar.
Och kanske viktigast:
Projektplanen används för att hjälpa människor fatta bättre beslut, inte för att skapa intrycket av att allt går enligt plan.
En enkel kontrollfråga för projektägare
Om ni redan driver ett IT-projekt kan det vara värt att stanna upp och försöka svara på följande utan att öppna projektplanen:
- Vilket verksamhetsresultat ska projektet skapa?
- Vilka tre största risker har vi just nu?
- Vilka beslut väntar projektgruppen på?
- Vilka personer är mest kritiska för att projektet ska komma framåt?
- Vilka andra system eller projekt är vi beroende av?
- Vilka krav har tillkommit sedan projektstart?
- Vad är den största osäkerheten inför go-live?
- Vem tar över ansvaret när projektet avslutas?
Om svaren är tydliga har ni sannolikt bra kontroll över projektets viktigaste delar.
Om flera svar är oklara är det inte nödvändigtvis ett tecken på att projektet håller på att misslyckas.
Men det är ett bra tillfälle att reda ut dem innan osäkerheten blir dyrare.
Projektmetoden är sällan huvudproblemet
Det är lätt att tro att ett projekt hade gått bättre om organisationen bara arbetat mer agilt, haft en tydligare vattenfallsmodell eller valt ett bättre ramverk.
Ibland ligger det något i det.
Men metodvalet löser sällan de grundläggande problemen.
Otydliga mål blir inte tydligare av sprintar.
Bristande beslutsvägar löses inte av en ny projektmall.
Och en styrgrupp som inte fattar beslut blir inte effektivare för att projektet använder en annan metod.
Projektmetoden behöver passa situationen, men den måste kombineras med fungerande projektledning.
Vill ni fördjupa er i metodvalet kan ni läsa vår guide Agilt, vattenfall eller hybrid – vilken projektmetod passar ert IT-projekt?
Vanliga frågor om varför IT-projekt misslyckas
Varför misslyckas IT-projekt?
IT-projekt kan hamna fel av många orsaker, men vanliga problem är otydliga mål, svag kravställning, oklara beslutsvägar, bristande verksamhetsinvolvering, underskattade systemberoenden och förändringar som inte hanteras på ett strukturerat sätt.
Är dålig teknik den vanligaste orsaken till problem i IT-projekt?
Tekniska problem kan självklart påverka ett projekt, men dem flesta svårigheter uppstår i samspelet mellan organisation, krav, beslut, resurser och teknik. Därför behöver projektstyrningen fokusera på att hantera både tekniska och verksamhetsmässiga frågor.
Hur vet man om ett IT-projekt håller på att gå fel?
Varningssignaler kan vara återkommande förskjutningar i tidplanen, många oklara beslut, ökande omfattning, låg verksamhetsmedverkan, problem som upptäcks sent och en statusrapportering som inte stämmer överens med projektgruppens bild av läget. Tystnad på projektmöten är en annan indikator.
Hur kan man minska risken i ett IT-projekt?
Börja med tydliga verksamhetsmål, definierat ansvar och realistisk planering. Kartlägg beroenden, involvera verksamheten, följ upp risker kontinuerligt och testa viktiga delar tidigt. Sätt SMARTA mål (mätbart).
Vad ska man göra om ett IT-projekt redan är försenat?
Försök först förstå orsaken istället för att enbart komprimera återstående tidplan. Gå igenom omfattning, kritiska beroenden, beslut, resurser och risker och skapa därefter en uppdaterad realistisk plan. Teorin säger att man inte tar ikapp tiden i ett försenat IT-projekt, så förändring är alltså statiskt sätt nödvändig.
Vem ansvarar för att ett IT-projekt lyckas?
Projektledaren har en central samordnande roll, men projektets resultat är sällan en persons ansvar. Projektägare, verksamhet, IT, leverantörer och andra nyckelroller behöver ha tydliga ansvar medans jag tycker att fungerande beslutsvägar även kan vara avgörande.
Sammanfattning – problemen börjar ofta innan de syns
IT-projekt misslyckas sällan på en enda dag.
Problemen byggs ofta upp gradvis.
Ett beslut skjuts fram. Ett krav förblir oklart. En ny funktion läggs till. En nyckelperson har inte tid att testa. Ett tekniskt beroende upptäcks senare än planerat.
Var för sig behöver inget av detta vara särskilt allvarligt.
Men tillsammans kan de förändra projektets förutsättningar betydligt.
Därför handlar bra IT-projektledning inte om att skapa ett projekt där inget går fel.
Det handlar om att skapa tillräckligt bra insyn, ansvar och beslutsförmåga för att upptäcka problem medan det fortfarande finns rimliga alternativ.
Vill ni fördjupa er i hur ett IT-projekt kan struktureras från förstudie till förvaltning kan ni läsa vår kompletta guide om IT-projektledning.
Behöver ni stöd i ett pågående eller kommande ERP- eller integrationsprojekt? Läs mer om hur Konfigo arbetar med projektledning inom ERP och IT-projekt, eller kontakta oss så tittar vi på era förutsättningar.