Agilt eller vattenfall?
Frågan dyker upp tidigt i många IT-projekt. Ibland behandlas valet av projektmetod nästan som ett ställningstagande: antingen arbetar man agilt och flexibelt, eller så arbetar man traditionellt med tydliga planer och fasta faser.
Verkligheten är sällan så enkel.
Ett systeminförande kan behöva en fast tidplan och tydliga beslutspunkter, samtidigt som delar av lösningen behöver utvecklas iterativt. Ett integrationsprojekt kan ha ett tydligt slutmål men innehålla tekniska frågor som inte går att besvara fullt ut innan arbetet börjar.
Därför är den viktigaste frågan inte vilken projektmetod som är bäst generellt.
Frågan är vilket arbetssätt som passar projektets förutsättningar, risker och mål.
I den här guiden går vi igenom skillnaderna mellan agil projektledning, vattenfallsmodellen och hybridprojekt – och vad ni bör tänka på när ni väljer arbetssätt för ert IT-projekt.
Vad är agil projektledning?
Agil projektledning bygger på att arbetet delas upp i mindre delar som planeras, genomförs och utvärderas stegvis.
Istället för att försöka definiera hela lösningen i detalj från början arbetar projektgruppen iterativt. Resultat och återkoppling från en del av arbetet kan påverka hur nästa del prioriteras.
Det gör det möjligt att lära sig under projektets gång.
Agila arbetssätt kan därför vara särskilt användbara när alla krav inte är kända från början eller när verksamhetens behov förväntas förändras under projektet.
Vanliga principer är:
- kortare planerings- och leveranscykler
- kontinuerlig prioritering
- nära samarbete med verksamheten
- regelbunden återkoppling
- möjlighet att förändra krav och prioriteringar
- stegvis leverans istället för en enda stor slutleverans
Agilt betyder däremot inte att projektet saknar plan.
Budget, ansvar, mål, resurser och tekniska beroenden behöver fortfarande hanteras. Skillnaden ligger framför allt i hur detaljerat arbetet planeras långt i förväg och hur projektet hanterar ny information.
Vad är vattenfallsmodellen?
Vattenfallsmodellen bygger på en mer sekventiell projektstruktur.
Projektet delas upp i tydliga faser som genomförs i en bestämd ordning. En förenklad modell kan exempelvis se ut så här:
- Förstudie och analys
- Kravställning
- Design
- Utveckling eller konfigurering
- Test
- Införande
- Överlämning
Tanken är att varje fas ska skapa ett tillräckligt stabilt underlag för nästa.
Det ger en tydlig struktur och gör det möjligt att tidigt planera aktiviteter, milstolpar och ansvar.
Vattenfallsmodellen passar därför bättre när projektets mål och krav är relativt väl definierade och när förändringar under genomförandet förväntas vara begränsade.
Utmaningen är att IT-projekt inte alltid utvecklas på det sättet.
Om ett viktigt verksamhetsbehov upptäcks först under testfasen kan det vara kostsamt att gå tillbaka och förändra något som redan har specificerats och byggts.
Ju större osäkerhet projektet innehåller, desto svårare blir det därför att planera hela vägen i detalj från början.
Vad är ett hybridprojekt?
Ett hybridprojekt kombinerar delar av traditionell och agil projektledning.
Det innebär exempelvis att projektet kan ha:
- en fast övergripande tidplan
- definierad budget
- tydliga beslutspunkter
- gemensamma milstolpar
samtidigt som vissa delar av genomförandet sker iterativt med:
- kortare arbetscykler
- löpande prioritering
- demonstrationer
- återkoppling från verksamheten
- justeringar av lösningen längs vägen
Det kan låta som en kompromiss, men i många IT-projekt är det snarare ett praktiskt sätt att hantera två olika behov samtidigt.
Organisationen behöver kontroll över projektets övergripande riktning och ekonomi, samtidigt som projektgruppen behöver kunna anpassa lösningen när ny kunskap uppstår.
Hybrid handlar därför inte om att använda lite av varje utan eftertanke. Ett fungerande hybridprojekt behöver vara tydligt med vilka delar som är fasta och vilka delar som får förändras.
Agilt vs vattenfall – vad är skillnaden?
Den största skillnaden ligger i hur projektet förhåller sig till planering och förändring.
| Agilt | Vattenfall | Hybrid | |
|---|---|---|---|
| Planering | Sker löpande och stegvis | Stor del görs tidigt | Övergripande tidigt, detaljer löpande |
| Krav | Kan utvecklas under projektet | Definieras i hög grad före genomförandet | Vissa fasta, andra utvecklas |
| Leverans | Mindre och återkommande leveranser | Större leverans mot slutet | Kombination |
| Verksamhetsinvolvering | Kontinuerlig | Ofta större vid krav och acceptans | Kontinuerlig i utvalda delar |
| Förändring | Förväntas och hanteras löpande | Hanteras mer formellt | Beror på vilken del som förändras |
| Styrning | Fokus på prioriteringar och resultat | Fokus på plan, faser och milstolpar | Kombination |
Det innebär inte att en agil modell alltid är flexibel eller att vattenfall alltid är stelbent.
Ett dåligt styrt agilt projekt kan snabbt tappa riktning. Ett välskött vattenfallsprojekt kan hantera förändringar på ett strukturerat sätt.
Metoden skapar förutsättningarna. Den ersätter inte bra projektledning.
När passar agil projektledning?
Ett agilt arbetssätt kan passa när projektet innehåller en hög grad av osäkerhet.
Det kan exempelvis vara när:
- verksamhetens behov behöver utforskas under projektet
- lösningen kan utvecklas och testas stegvis
- prioriteringar förväntas förändras
- användarna kan ge återkoppling kontinuerligt
- projektet kan leverera värde i mindre delar
- det finns ett dedikerat team som kan arbeta iterativt
Tänk exempelvis på utvecklingen av en ny intern applikation.
Verksamheten kanske vet vilket problem som ska lösas men inte exakt hur den bästa lösningen ska se ut.
Att då specificera varje funktion i detalj innan användarna har sett eller testat något kan skapa onödigt arbete.
Genom att istället utveckla en mindre del, låta användarna testa och därefter prioritera nästa steg kan projektet successivt närma sig rätt lösning.
När blir agilt svårare?
Agilt arbete kräver engagemang.
Om verksamheten inte har möjlighet att kontinuerligt prioritera, testa och ge återkoppling försvinner en stor del av nyttan.
Det blir också svårare om projektet har många fasta externa beroenden där leveranser måste ske vid specifika tidpunkter.
Agilt ska därför inte väljas enbart för att projektet förväntas förändras.
Organisationen behöver också ha förutsättningar att faktiskt arbeta på det sättet.
När passar vattenfallsmodellen?
Vattenfall kan vara lämpligt när projektet har tydliga förutsättningar och när ordningen mellan olika aktiviteter är viktig.
Det kan exempelvis vara när:
- kraven är relativt stabila
- slutresultatet går att definiera tidigt
- projektet har tydliga beroenden mellan faser
- omfattningen behöver fastställas i förväg
- dokumentation och formella godkännanden är viktiga
- förändringar under genomförandet förväntas vara begränsade
Ett projekt behöver alltså inte vara gammaldags för att använda ett sekventiellt arbetssätt.
I vissa situationer skapar tydliga faser precis den kontroll projektet behöver.
När blir vattenfall svårare?
Problemet uppstår framför allt när projektet försöker skapa säkerhet där det egentligen finns osäkerhet.
En detaljerad projektplan kan se trygg ut på papperet. Men om den bygger på antaganden som ännu inte har kunnat verifieras är planen inte nödvändigtvis realistisk.
Det är särskilt relevant i komplexa IT-projekt där tekniska beroenden eller verksamhetsbehov upptäcks först när projektgruppen börjar arbeta med lösningen.
Ju dyrare det blir att förändra ett beslut sent, desto viktigare är det att identifiera vilka delar som verkligen går att låsa tidigt.
När passar en hybridmodell?
Hybrid är ofta relevant när projektet behöver både förutsägbarhet och flexibilitet.
Ett systeminförande är ett bra exempel.
Organisationen kan behöva ett fast datum för produktionssättning. Budgeten kan vara beslutad. Utbildning, datamigrering och andra aktiviteter behöver samordnas inför samma datum.
Samtidigt kan konfigurering, integrationer och vissa verksamhetsprocesser behöva utvecklas och testas stegvis.
Då kan den övergripande projektstyrningen vara traditionell medan delar av leveransen sker iterativt.
Ett hybridupplägg kan exempelvis innebära:
Fast:
Projektmål, budgetram, övergripande tidplan, styrgrupp, beslutspunkter och datum för viktiga milstolpar.
Iterativt:
Konfigurering, utveckling, prioritering av funktioner, demonstrationer och återkoppling från användare.
På så sätt vet organisationen vart projektet är på väg utan att försöka bestämma varje detalj innan tillräcklig kunskap finns.
Vilken metod passar ett ERP-projekt?
ERP-projekt är ofta svåra att placera helt i en enda projektmodell.
Ett affärssystem påverkar vanligtvis flera verksamhetsprocesser samtidigt och kan involvera ekonomi, order, lager, inköp, rapportering, integrationer och andra områden.
Vissa delar kräver tydlig sekventiell planering.
Datamigrering behöver exempelvis vara klar inför produktionssättning. Integrationer behöver testas tillsammans med övriga system. Användarna behöver utbildas innan den nya lösningen tas i bruk.
Andra delar kan gynnas av ett mer iterativt arbetssätt.
Konfigurering och processdesign kan exempelvis demonstreras löpande så att verksamheten kan ge återkoppling innan för mycket har byggts.
Därför kan en hybridmodell vara relevant i många ERP-projekt.
Men det betyder inte att hybrid automatiskt är rätt. Projektets omfattning, organisation, system, leverantörer och verksamhetskrav behöver styra valet.
Vilken metod passar ett integrationsprojekt?
Integrationsprojekt har ofta ett tydligt önskat resultat: information ska flöda från ett system till ett annat enligt definierade regler.
Det kan göra projektet förhållandevis enkelt att avgränsa.
Samtidigt finns tekniska beroenden som inte alltid blir fullt synliga förrän systemen faktiskt börjar kommunicera.
Ett fält kanske saknas. Ett API fungerar annorlunda än förväntat. Datakvaliteten visar sig vara sämre än antaget. Ett verksamhetsundantag som ingen tänkt på behöver plötsligt hanteras.
Därför kan det vara värdefullt att dela upp integrationsarbetet i mindre flöden och testa dem stegvis.
Det ligger också nära en viktig princip för IT-projekt generellt: testa antaganden tidigt istället för att vänta till slutet av projektet med att upptäcka att något inte fungerar.
Fem frågor att ställa innan ni väljer projektmetod
Istället för att börja diskussionen med ”ska vi arbeta agilt eller med vattenfall?” kan det vara bättre att börja med projektets faktiska förutsättningar.
1. Hur tydliga är kraven?
Om verksamheten redan kan beskriva slutresultatet relativt exakt finns bättre förutsättningar för detaljerad planering.
Om behoven behöver utforskas längs vägen behövs större flexibilitet.
2. Hur mycket förväntas förändras?
Förändring är normalt i IT-projekt.
Frågan är hur mycket förändring som rimligen kan förväntas och hur dyrt det blir att hantera den senare.
3. Kan lösningen levereras och testas i mindre delar?
Om projektet går att dela upp kan iterativ leverans ge tidig återkoppling och minska risken för sena överraskningar.
Om hela lösningen måste fungera samtidigt innan något värde kan realiseras ser förutsättningarna annorlunda ut.
4. Hur tillgänglig är verksamheten?
Agila arbetssätt kräver ofta tätare verksamhetsinvolvering.
Om nyckelpersoner bara kan delta vid ett fåtal definierade tillfällen behöver projektupplägget ta hänsyn till det.
5. Vilka delar måste vara fasta?
Ett projekt kan behöva ett fast lanseringsdatum utan att varje funktion måste vara definierad från början.
Identifiera därför vad som faktiskt inte får förändras: budget, tid, regelkrav, tekniska beroenden eller något annat.
När de fasta ramarna är tydliga blir det lättare att avgöra var projektet kan vara flexibelt.
Vanliga misstag när projektmetod väljs
Att välja metod för att organisationen alltid gör så
Ett arbetssätt som fungerade i ett tidigare projekt behöver inte passa nästa.
Projektets förutsättningar bör styra metoden, inte traditionen.
Att kalla projektet agilt utan att förändra arbetssättet
Dagliga möten och en backlog gör inte automatiskt ett projekt agilt.
Om alla krav ändå låses från början, verksamheten inte kan prioritera och varje förändring måste genom en lång beslutsprocess är flexibiliteten begränsad oavsett vilka begrepp projektet använder.
Att tro att vattenfall eliminerar förändring
En detaljerad plan hindrar inte nya krav från att uppstå.
Skillnaden är hur förändringarna hanteras.
Att använda hybrid utan att definiera vad det betyder
”Vi arbetar hybrid” kan annars bli ett sätt att undvika själva metodbeslutet.
Var tydliga med vilka delar som styrs sekventiellt, vilka som genomförs iterativt och hur de två arbetssätten möts.
Att fokusera mer på metoden än på projektmålet
Metoden är ett verktyg.
Om diskussionen om Scrum, sprintar, styrgrupper eller projektfaser tar mer energi än frågan om vilket verksamhetsproblem projektet ska lösa har fokus hamnat fel.
Projektmetoden löser inte projektledningen åt er
Det är lätt att hoppas att rätt metod ska skapa kontroll.
Men inget ramverk kan kompensera för otydliga mål, dålig kravställning, oklara beslutsvägar eller bristande kommunikation.
Ett agilt projekt behöver fortfarande veta vart det är på väg.
Ett vattenfallsprojekt behöver fortfarande kunna hantera ny information.
Och ett hybridprojekt behöver fortfarande någon som håller ihop helheten.
Projektmetoden bestämmer hur arbetet organiseras. Projektledningen behöver se till att organisationen faktiskt kan fatta beslut, hantera risker och driva arbetet framåt.
Det är därför valet av metod bara är en del av en större fråga: hur skapar ni rätt förutsättningar för att IT-projektet ska nå sitt mål?
Läs gärna vår kompletta guide om IT-projektledning för en genomgång av projektets olika faser, riskhantering, kravställning, projektorganisation och projektledarens roll.
Vanliga frågor om agil projektledning, vattenfall och hybrid
Vad är skillnaden mellan agilt och vattenfall?
Den huvudsakliga skillnaden är hur projektet planeras och hanterar förändring. Vattenfall bygger på tydligare sekventiella faser och mer planering tidigt, medan agila arbetssätt bygger på kortare iterationer, återkoppling och löpande prioritering.
Är agilt bättre än vattenfall?
Inte generellt. Agilt passar bättre i vissa projekt och vattenfall i andra. Valet bör utgå från bland annat kravens stabilitet, projektets osäkerhet, beroenden och verksamhetens möjlighet att delta kontinuerligt.
Vad är hybrid projektledning?
Hybrid projektledning kombinerar traditionell och agil projektstyrning. Projektet kan exempelvis ha fast budget, tidplan och milstolpar samtidigt som utveckling och konfigurering genomförs iterativt.
Kan man använda agilt vid ERP-implementation?
Ja, delar av ett ERP-projekt kan genomföras iterativt. Samtidigt finns ofta beroenden, gemensamma milstolpar och aktiviteter inför produktionssättning som behöver planeras mer övergripande. Därför kan en kombination av arbetssätt vara relevant.
Vilken projektmetod passar integrationsprojekt?
Det beror på integrationens omfattning och osäkerhet. När flöden går att dela upp kan stegvis utveckling och testning vara värdefullt. Samtidigt behöver beroenden mellan system, data och produktionssättning planeras och styras.
Måste ett IT-projekt välja en enda projektmetod?
Nej. Olika delar av samma projekt kan ha olika behov. Det viktiga är att arbetssättet är tydligt och att projektgruppen vet hur planering, prioritering, förändringar och beslut ska hanteras.
Sammanfattning – välj metod efter projektet, inte projekt efter metod
Agilt, vattenfall och hybrid är olika sätt att organisera ett projekt. Ingen av modellerna är automatiskt bättre än de andra.
Vattenfall kan ge tydlighet när krav, beroenden och slutresultat går att definiera tidigt.
Agila arbetssätt kan ge större flexibilitet när projektet innehåller osäkerhet och lösningen behöver utvecklas stegvis.
Hybrid kan kombinera övergripande styrning med iterativ leverans när projektet behöver båda.
Det viktiga är därför inte vilken etikett projektet får.
Börja istället med att förstå vad ni ska åstadkomma, hur mycket ni faktiskt vet från början, vilka beroenden som finns och var projektet behöver kunna förändras.
Då kan projektmetoden bli vad den ska vara: ett stöd för projektet istället för ett mål i sig.
Behöver ni stöd med att strukturera eller leda ett IT-projekt? Konfigo arbetar med projektledning inom ERP, integrationer och systemrelaterade projekt. Kontakta oss så kan vi gå igenom projektets förutsättningar och vilket stöd som är relevant.