Agilt eller vattenfall i ert projekt?
Skillnaden mellan agilt och vattenfall handlar om pengar och risk, inte ideologi. Vattenfall passar fast pris men flyttar risken till kravfasen – blir kraven fel blir hela bygget fel. Agilt kopplas till löpande prismodeller, levererar värde tidigt och sprider risken, men kräver aktiv styrning. Vattenfall är rätt vid upphandlingar och hårda certifieringskrav.
Diskussionen om agilt kontra vattenfall förs oftast som en metodstrid, där den ena sidan är modern och den andra föråldrad. Det är fel lins. För en beställare handlar valet inte om ideologi utan om två konkreta saker: hur ni betalar och var risken hamnar. Byt ut trosfrågan mot pengar och risk, så blir beslutet plötsligt hanterbart – och ofta ganska självklart.
Två sätt att fördela pengar och risk
I grunden är skillnaden enkel. Vattenfall bestämmer allt i förväg, sätter ett pris och bygger sedan mot specifikationen i en följd. Agilt bygger i korta cykler, levererar värde längs vägen och justerar riktning efter hand.
Den skillnaden får direkta konsekvenser för ekonomin. Vattenfall ger ett förutsägbart pris men lägger all risk i att kraven är rätt. Agilt sprider både betalning och risk över tid men kräver att någon styr aktivt. Det är den avvägningen – förutsägbarhet mot flexibilitet – som avgör, inte vilken metod som låter finast.
Vattenfall och det fasta priset
Ett fast pris förutsätter ett låst scope, och det är precis vad vattenfall levererar. Kraven specificeras i en fas innan bygget börjar, leverantören räknar på en definierad mängd arbete och sätter en siffra. För en beställare som behöver veta kostnaden i förväg – för att få ett investeringsbeslut godkänt, till exempel – är det en verklig styrka.
Priset för förutsägbarheten är var risken hamnar: i kravfasen, hos er. Allt vilar på att specifikationen är rätt. Blir den fel byggs fel sak, och det upptäcks ofta först vid leverans, när det är som dyrast att ändra. Ni betalar ett känt pris för risken att ni specificerade fel innan ni visste bättre.
Agilt och de löpande modellerna
Agilt hänger ihop med andra prismodeller: löpande räkning eller en fast budgetram med flexibelt innehåll. I stället för allt-på-slutet får ni användbart värde tidigt, cykel för cykel. Det gör två saker för ekonomin – det sprider risken, eftersom ni ser resultat och kan korrigera innan hela summan är spenderad, och det låter er börja få nytta av produkten innan den är helt färdig.
Motprestationen är styrning. Agilt utan en aktiv beställare som prioriterar varje vecka kan förvandlas till ett öppet konto där kostnaden växer utan att någon håller i rodret. Flexibiliteten är ett verktyg, och verktyget kräver en hand.
En jämförelse i pengar och risk
| Aspekt | Vattenfall |
|---|---|
| Prismodell | Passar fast pris |
| Var risken hamnar | I kravfasen – rätt specifikation avgör allt |
| När värde levereras | På slutet, som en färdig helhet |
| Kräver av er | En genomtänkt kravspec i förväg |
Agilt vänder på raderna: löpande eller rambaserad prismodell, risk spridd över tid, värde levererat tidigt och löpande, och ett krav på er att styra scopet aktivt hela vägen.
Ett scenario
Säg att ni ska bygga ett system och kraven är genuint osäkra – ni gissar er till vad användarna behöver. Väljer ni vattenfall och fast pris låser ni en specifikation ni inte är säkra på, och när verkligheten visar sig blir ändringarna tillägg ovanpå priset. Väljer ni agilt ser ni tidiga versioner, upptäcker vad som faktiskt behövs och styr om medan det är billigt. Här sprider agilt risken. Vänd på det: är kraven glasklara och oföränderliga ger vattenfallets fasta pris er förutsägbarhet utan att ni offrar något, eftersom det inte finns någon osäkerhet att flexibiliteten kunde ha fångat.
När vattenfall är rätt val
Trots det dåliga ryktet finns lägen där vattenfall är det förnuftiga. Offentliga upphandlingar och hårda certifieringskrav kräver ofta att allt specificeras och dokumenteras i förväg – där är formen given. Och när kraven verkligen är stabila och väl kända är mycket av agilitetens värde borta ändå.
Problemet är inte vattenfall i sig, utan att tvinga in oklara krav i en modell byggd för klara. Matcha metoden mot hur säker kravbilden är, så matchar ni samtidigt risk och prismodell mot verkligheten.
Vi på Weapp anpassar prismodell och arbetssätt efter projektets osäkerhet, och lutar ofta åt en fast ram med agil leverans. Vill du resonera kring vad som ger bäst kontroll över just er ekonomi? Titta på våra tjänster eller hör av dig.
Vanliga frågor
Varför kopplas vattenfall till fast pris?
För att ett fast pris kräver ett låst scope, och vattenfall låser scopet i en kravfas innan bygget börjar. Leverantören kan räkna på en definierad mängd arbete och sätta en fast siffra. Priset är förutsägbart – men bara så länge kraven håller. Ändras de kommer tilläggen ovanpå det fasta priset.
Var hamnar risken i ett vattenfallsprojekt?
I kravfasen, hos er. Allt vilar på att specifikationen är rätt från början. Blir den fel byggs fel sak, och felet upptäcks ofta först vid leverans när det är dyrast att rätta. Ni betalar ett förutsägbart pris, men för risken att ni specificerade fel innan ni visste bättre.
Hur påverkar agilt prismodellen och kassaflödet?
Agilt passar löpande räkning eller en fast budgetram med flexibelt innehåll, och levererar användbart värde tidigt i stället för allt på slutet. Det sprider både risk och betalning över tid. I gengäld krävs att ni styr scopet aktivt varje vecka – utan det kan löpande räkning bli ett öppet konto.
Är agilt alltid billigare än vattenfall?
Nej. Agilt kan ge lägre total risk och tidigare värde, men utan aktiv styrning kan kostnaden växa okontrollerat. Vattenfall ger ett förutsägbart pris men bär risken att ni betalar för fel specifikation. Vilket som blir billigast beror på hur säkra kraven är och hur väl ni styr – inte på metoden i sig.
När är vattenfall faktiskt det rätta valet?
Vid offentliga upphandlingar och hårda certifieringskrav där allt måste specificeras och dokumenteras i förväg, och när kraven är stabila och väl kända. I de lägena är vattenfallets förutsägbarhet en styrka, inte en svaghet. Problemet uppstår bara när man tvingar in oklara krav i en modell som förutsätter klara.