IT-projektets faser börjar oftast innan den dag projektgruppen samlas för första gången.
Ofta har diskussionen pågått länge innan dess. Ett system fungerar inte längre tillräckligt bra. Manuella arbetssätt tar för mycket tid. En ny lösning behöver införas. Flera system behöver kopplas ihop.
På samma sätt slutar projektet inte nödvändigtvis när den nya lösningen går live.
Efter produktionssättningen börjar förvaltningen, supporten och vidareutvecklingen. Det är först då lösningen ska fungera i vardagen.
Därför är det användbart att se IT-projektet som en kedja av olika faser, från inledande planering och förstudie till överlämning och förvaltning.
I den här guiden går vi igenom de vanligaste faserna i ett IT-projekt, vad varje fas ska åstadkomma och vilka frågor som är viktiga att få svar på innan projektet går vidare.
Vilka faser ingår i ett IT-projekt?
Exakta namn varierar mellan organisationer och projektmetoder, men många IT-projekt kan förenklat delas in i följande faser:
- Planering
- Förstudie
- Kravställning och lösningsdesign
- Genomförande
- Test och kvalitetssäkring
- Införande
- Överlämning och förvaltning
I agila projekt kan flera av faserna överlappa varandra eller upprepas i mindre iterationer. I mer traditionella projekt genomförs de oftare sekventiellt.
Det viktiga är inte vad faserna kallas.
Det viktiga är att projektet vet vilka frågor som behöver vara besvarade innan nästa del av arbetet tar vid.
Fas 1: Planering – gör projektet genomförbart
För att organisationen ska veta vad projektet ska uppnå behöver arbetet organiseras och planeras.
I detta första steg planeras förstudien: vem som ansvarar, vilka som behöver delta och vilka frågor som ska undersökas. Den mer detaljerade planen för genomförandet tas fram när förstudien har gett ett bättre beslutsunderlag och först då kan vi definiera hur projektet ska fortsätta från idé och analys till konkret genomförande.
En projektplan behöver ge en gemensam bild av:
- mål och omfattning
- projektorganisation
- ansvar
- aktiviteter
- viktiga beroenden
- milstolpar
- resurser
- budget
- riskhantering
- kommunikation
- beslutsvägar
- uppföljning
Planeringen ska skapa tillräcklig struktur för att projektgruppen ska veta vad som förväntas i respektive fas.
Men planen bör inte behandlas som en exakt prognos över allt som kommer hända, utan i många projekt uppdateras planen löpande allt eftersom projektet utvecklas.
IT-projekt innehåller nästan alltid osäkerheter som först blir synliga under genomförandet.
En bra projektplan behöver därför både skapa riktning och ge möjlighet att hantera förändring.
Fas 2: Förstudie – förstå problemet innan ni väljer lösning
Förstudien ska ge organisationen ett tillräckligt bra underlag för att avgöra om projektet bör genomföras och hur det i så fall bör angripas.
Det är lätt att gå direkt till lösningen.
- “Vi behöver byta affärssystem.”
- “Vi behöver en ny integration.”
- “Vi behöver automatisera processen.”
Men en bra förstudie börjar ett steg tidigare:
Vilket verksamhetsproblem försöker vi lösa?
Om problemet inte är tydligt blir det svårt att bedöma om den föreslagna lösningen faktiskt är rätt.
Bara för att vi rent tekniskt kan bygga någonting, så betyder inte det att vi automatiskt ska göra det.
Vad bör en förstudie innehålla?
Beroende på projektets storlek kan förstudien vara allt från några workshops till ett omfattande analysarbete.
Vanliga delar är:
- nulägesanalys
- verksamhetsbehov
- övergripande krav
- berörda system och processer
- tekniska beroenden
- risker
- ungefärlig omfattning
- resursbehov
- möjliga lösningsalternativ
- preliminär kostnadsbild
- förväntad verksamhetsnytta
Målet är inte att lösa varje fråga.
Målet är att minska osäkerheten till en nivå där organisationen kan fatta ett medvetet beslut om nästa steg.
Frågor att kunna svara på innan ni går vidare
- Vilket problem ska projektet lösa?
- Vem påverkas av förändringen?
- Vilka system och processer berörs?
- Vilken effekt vill verksamheten uppnå?
- Finns tydliga tekniska eller organisatoriska risker?
- Vilka delar behöver undersökas närmare?
Om svaren fortfarande skiljer sig kraftigt mellan olika personer i organisationen är det ofta värt att lägga mer tid här.
Ett otydligt projekt blir sällan tydligare bara för att genomförandet startar.
Fas 3: Kravställning och lösningsdesign – översätt behov till något som går att bygga
När projektets riktning är tydlig behöver verksamhetsbehoven översättas till krav och en lösningsdesign.
Det är här projektet börjar svara mer konkret på frågan:
Hur ska den nya lösningen fungera?
Kravställning handlar inte bara om funktioner.
Ett bra kravarbete behöver också ta hänsyn till:
- verksamhetsprocesser
- användarbehov
- integrationer
- data
- säkerhet
- behörigheter
- rapportering
- prestanda
- förvaltning
- eventuella lag- och regelkrav
I ett ERP-projekt kan ett krav exempelvis påverka flera delar av systemet samtidigt.
I ett integrationsprojekt kan samma informationsfält behöva mappas, valideras och hanteras på olika sätt beroende på vilket system som skickar eller tar emot informationen.
Prioritera kraven
Alla krav är inte lika viktiga.
Därför behöver projektet kunna skilja på:
- sådant som måste finnas
- sådant som bör finnas
- sådant som är önskvärt
- sådant som kan vänta
Det blir särskilt viktigt när nya önskemål dyker upp under projektets gång.
Om allt behandlas som obligatoriskt finns det i praktiken ingen prioritering.
När är fasen klar?
Inte när varje tänkbar detalj är dokumenterad.
Den är tillräckligt klar när projektgruppen har en gemensam förståelse för vad som ska byggas, vilka viktigaste beroendena är och vilka frågor som kan hanteras senare utan att äventyra helheten.
Fas 4: Genomförande – när planeringen möter verkligheten
Nu börjar lösningen ta form.
Beroende på projekt kan det innebära utveckling, konfigurering, systeminstallation, integrationer, datamappning eller andra tekniska aktiviteter.
Det är också här många antaganden blir testade på riktigt.
En integration fungerar inte som förväntat.
Ett standardstöd visar sig inte täcka hela verksamhetsbehovet.
Ett gammalt system innehåller data på ett sätt ingen räknat med.
En process ser annorlunda ut i praktiken än den gjorde på whiteboarden.
Det betyder inte att förstudien eller planeringen varit dålig.
Det betyder att projektet nu har mer information.
Projektledningens roll under genomförandet
Här behöver projektledningen bland annat hålla ihop:
- aktiviteter
- prioriteringar
- resurser
- beroenden
- risker
- förändringar
- leverantörer
- beslut
- kommunikation med verksamheten
Det viktiga är att nya problem inte bara löses lokalt.
En teknisk förändring i en del av lösningen kan påverka tidplan, testning eller andra system.
Därför behöver konsekvenserna göras synliga för projektet som helhet.
Fas 5: Test och kvalitetssäkring – fungerar hela processen?
Att en funktion går att använda betyder inte automatiskt att lösningen fungerar.
Testningen behöver säkerställa både de enskilda delarna och helheten.
Det kan exempelvis handla om:
Funktionstest
Fungerar en enskild funktion enligt kravet?
Integrationstest
Kan systemen skicka och ta emot information på rätt sätt?
End-to-end-test
Fungerar hela verksamhetsprocessen från början till slut?
En order kanske behöver gå från e-handel till ERP, vidare till lager och slutligen till fakturering.
Alla enskilda delar kan fungera var för sig och processen kan ändå fallera när de används tillsammans.
Användartest
Fungerar lösningen för dem som faktiskt ska arbeta i den?
Användarna behöver få möjlighet att testa verkliga scenarier, inte bara se att enskilda skärmbilder fungerar.
Test av fel och undantag
Vad händer när något inte går enligt plan?
Till exempel:
- obligatorisk data saknas
- ett system är tillfälligt otillgängligt
- en integration misslyckas
- en användare anger fel information
- samma transaktion skickas två gånger
En robust lösning behöver hantera även dessa situationer.
Fas 6: Införande – när projektet möter verksamheten
Go-live är ofta den mest synliga delen av ett IT-projekt.
Men ett lyckat införande kräver betydligt mer än att tekniken är färdig.
Organisationen behöver vara redo.
Det kan innebära:
- datamigrering
- utbildning
- användardokumentation
- supportplanering
- kommunikation
- behörigheter
- produktionssättning
- reservplaner
- förstärkt bemanning under de första dagarna
I större projekt behöver införandet ofta planeras som ett eget delprojekt.
Vad kan gå fel vid go-live?
Ett vanligt problem är att projektet har fokuserat så mycket på att få lösningen tekniskt klar att verksamheten förberetts för sent.
Användare kanske inte vet hur nya processer fungerar.
Supporten saknar information.
Ansvarsfördelningen efter lansering är otydlig.
Det skapar onödig belastning precis när organisationen är som mest beroende av att lösningen fungerar.
Därför bör frågan inte bara vara:
Är systemet redo?
utan också:
Är organisationen redo?
Fas 7: Överlämning och förvaltning – projektet slutar men lösningen fortsätter
När projektet går live börjar nästa fas i lösningens liv.
Nu ska någon:
- övervaka
- supportera
- underhålla
- uppdatera
- prioritera förbättringar
- hantera nya behov
Om förvaltningen inte är tydlig riskerar projektgruppen att bli kvar som en informell supportorganisation långt efter att projektet egentligen skulle vara avslutat.
Vad behöver lämnas över?
Det kan bland annat vara:
- teknisk dokumentation
- processbeskrivningar
- systemägarskap
- supportvägar
- kontaktpersoner
- integrationsdokumentation
- kända begränsningar
- öppna frågor
- prioriterade förbättringar
- rutiner för incidenter och förändringar
Kunskapen behöver flyttas från projektet till den organisation som ska äga lösningen långsiktigt.
En bra överlämning är därför inte administration på slutet.
Den är en del av leveransen.
Faserna är inte alltid raka
Det är lätt att rita ett IT-projekt som en rak linje:
Planering → Förstudie → krav → utveckling → test → go-live → förvaltning.
Verkligheten är ofta mer rörlig.
Testning kan visa att ett krav behöver förändras.
Utvecklingen kan synliggöra ett beroende som kräver ny analys.
Verksamheten kan upptäcka ett behov som förändrar prioriteringen.
I agila projekt sker flera av stegen återkommande i mindre iterationer.
Det viktiga är därför inte att projektet aldrig går tillbaka.
Det viktiga är att förstå varför det gör det och vilken effekt förändringen får på resten av projektet.
Tre beslutspunkter som är värda att ta på allvar
Alla projekt har milstolpar, men vissa beslut är särskilt viktiga.
Ska vi starta projektet?
Efter förstudien bör organisationen kunna bedöma om nyttan, risken och kostnaden motiverar ett genomförande.
Det ska vara ett faktiskt beslut, inte bara nästa punkt i kalendern.
Är vi redo att börja bygga?
Innan genomförandet tar fart behöver projektet ha tillräcklig samsyn kring mål, prioriteringar och lösning.
Om de grundläggande frågorna fortfarande är öppna riskerar genomförandet att bli dyr problemlösning.
Är vi verkligen redo för go-live?
Det är lätt att låta ett beslutat datum styra.
Men om kritiska tester återstår, verksamheten inte är redo eller förvaltningen saknar ägare är det viktigt att konsekvenserna blir tydliga innan beslutet tas.
Go-live ska vara ett riskmedvetet beslut, inte en reflex.
Vem ansvarar för vad under projektets olika faser?
Rollerna varierar mellan projekt, men ansvaret behöver vara tydligt.
Projektägaren
Ansvarar normalt för projektets övergripande verksamhetsmål och för att projektet har rätt mandat.
Projektledaren
Håller ihop planering, uppföljning, risker, kommunikation och samordning mellan projektets olika parter.
Verksamheten
Bidrar med processkunskap, prioriterar behov och verifierar att lösningen faktiskt fungerar i verksamheten.
IT och tekniska specialister
Ansvarar för tekniska lösningar, arkitektur, integrationer, säkerhet och andra specialistområden.
Leverantörer
Levererar de delar som ingår i respektive uppdrag och behöver samordnas med projektets övriga arbete.
Otydligheten uppstår ofta i gränserna mellan rollerna.
Därför är det viktigt att inte bara beskriva vem som deltar, utan också vem som fattar vilka beslut.
Vanliga misstag mellan projektets faser
Många projektproblem uppstår inte inne i en fas utan i övergången till nästa. Läs mer om varför IT-projekt misslyckas här, och vad man kan göra för att förebygga.
Förstudien avslutas för tidigt
Projektet går vidare trots att mål, omfattning och viktigaste beroenden fortfarande är otydliga.
Krav går direkt till utveckling utan prioritering
Resultatet blir att projektgruppen bygger efter den ordning kraven kommer in istället för efter verksamhetsnytta.
Testning behandlas som något som kommer sist
När genomförandet blir försenat blir testperioden den första delen som krymper.
Go-live blir viktigare än beredskapen
Datumet hålls, men organisationen får hantera problemen efteråt.
Förvaltningen börjar planeras efter lansering
När projektet ska lämna över lösningen finns ingen tydlig mottagare.
Gemensamt för alla exemplen är att projektet går vidare utan att vara tillräckligt redo för nästa steg.
En enkel checklista inför nästa fas
Innan projektet går vidare kan det vara värdefullt att ställa fem frågor:
- Vad skulle den här fasen åstadkomma?
- Har vi faktiskt uppnått det?
- Vilka viktiga frågor är fortfarande öppna?
- Vilken risk tar vi om vi går vidare ändå?
- Vem fattar beslutet att gå vidare?
Det behöver inte innebära långa formella granskningsmöten.
Poängen är att projektet gör ett medvetet val istället för att bara fortsätta av gammal fart.
Projektets faser och val av projektmetod
Hur faserna används beror på projektets arbetssätt.
I ett vattenfallsprojekt är de ofta tydligt avgränsade och genomförs i större utsträckning i följd.
I ett agilt projekt sker analys, utveckling och test oftare i kortare återkommande cykler.
I hybridprojekt kan den övergripande styrningen följa tydliga faser samtidigt som genomförandet sker iterativt.
Vilken modell som passar beror på bland annat projektets osäkerhet, krav, beroenden och verksamhetens möjlighet att delta.
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 IT-projektets faser
Vilka är de vanligaste faserna i ett IT-projekt?
En vanlig indelning är planering, förstudie, kravställning och lösningsdesign, genomförande, test, införande samt överlämning och förvaltning. Exakt indelning varierar mellan projekt och projektmetoder.
Vad är viktigast i förstudien?
Det viktigaste är att förstå vilket problem projektet ska lösa, vilken verksamhetsnytta som eftersträvas och vilka viktigaste förutsättningarna och riskerna är.
När ska kravställningen göras?
Kravställning börjar ofta i förstudien och fördjupas under lösningsdesign men innan genomförande. I agila projekt kan krav dock utvecklas och prioriteras kontinuerligt under genomförandet.
När ska testningen börja planeras?
Så tidigt som möjligt. Testning påverkas av krav, systemberoenden, data, miljöer och verksamhetsresurser och bör därför inte planeras först när utvecklingen är färdig.
Är go-live slutet på IT-projektet?
Inte nödvändigtvis. Efter produktionssättning behövs ofta en stabiliseringsperiod och en strukturerad överlämning till förvaltning innan projektet kan avslutas.
Vad innebär förvaltning av en IT-lösning?
Förvaltning innebär att lösningen ägs och hanteras efter projektet. Det kan omfatta support, incidenter, uppdateringar, övervakning och prioritering av framtida förbättringar.
Sammanfattning – varje fas ska minska osäkerheten inför nästa
Ett IT-projekt handlar inte bara om att ta sig från start till go-live så snabbt som möjligt.
Varje fas har ett syfte.
Planeringen ska skapa struktur.
Förstudien ska skapa förståelse.
Kravställningen ska skapa samsyn om vad som behövs.
Genomförandet ska omsätta behovet till en fungerande lösning.
Testningen ska visa att lösningen håller.
Införandet ska göra organisationen redo.
Och förvaltningen ska säkerställa att lösningen fortsätter skapa värde efter att projektet är avslutat.
När en fas hoppas över försvinner inte frågorna som skulle ha hanterats där.
De dyker vanligtvis upp senare, när det är svårare och dyrare att lösa dem.
Vill ni få en bredare bild av hur mål, risker, organisation och projektledarens roll hänger ihop genom hela projektet kan ni läsa vår kompletta guide om IT-projektledning.
Behöver ni stöd med att planera eller leda ett ERP- eller integrationsprojekt? Konfigo arbetar med projektledning och hjälper till att skapa struktur, samordning och framdrift utifrån projektets förutsättningar.
