Traditionella vattenfallsprojekt

Traditionella vattenfallsprojekt har länge varit standard för hur vi bedriver våra projekt. Under den tiden har vi som bransch också presterat oroväckande dåligt, där projekt blir kraftigt försenade, kostar dubbelt så mycket och levererar drygt hälften av vad som efterfrågades. Agile är en motreaktion på de traditionella vattenfallsprojekten och dess oförmåga att hantera förändring samt stora och komplexa IT-projekt. Trots det finns det fortfarande tillfällen då vattenfallsmodellen lämpar sig för IT-projekt.

Vattenfallsmodellen bygger på ett logisk och sekventiellt genomförande av projektet. Varje steg i processen ska avslutas innan nästa påbörjas. Kontroll, planering, processer och uppföljning är nyckelord. Tillskillnad från agila projekt så ses ändringar som en risk för projektet. Leverans av slutprodukten sker i slutet av projektet efter tester av både leverantören och kunden.

Normalt tar ett vattenfallsprojekt 12-18 månader för att gå från efterfrågad funktionalitet till leverans. Det skapar många problem, så som att kravmängden växer, och att sannolikheten att något förändras under tiden ökar markant. Dokumentationen i vattenfallsprojekt tenderar att bli omfattande, primärt eftersom det är det främsta sättet att kommunicera mellan varje steg i processen.

Styrkan med vattenfallsmodellen

Fördelen med vattenfallsmodellen är i de projekt där slutprodukten är känd, leverantören vet hur produkten ska konstrueras och inga förändringar sker under tiden. Då finns det en erfarenhet hos leverantören hur lång tid varje steg i processen tar, det går att detaljplanera, optimera processer, utföra enligt specifikation – helt enkelt snabbt och effektivt genomförande.

Vattenfallsmodellen är helt enkelt ypperlig för leveranser av standarslösningar men en låg del konfiguration. IT projekt är däremot oftast komplexa projekt, med hög förändringsbenägenhet, unika lösningar där slutprodukten inledningsvis är okänd för både beställaren och leverantören. IT projekt är, med andra ord, oftast ett lärande projekt där produkten som växer fram genom kommunikation och reflektion.

Mer om skillnaden mellan vattenfallsmodellen och agile finns under Go Agile och artikeln Agile vs Vattenfall.

Processen

Vattenfallsmodellen (även V-modellen för de som är bekanta med den) kan utformas med lite olika processteg och definitioner, men grunden bygger på att varje steg ska avslutas och granskas innan nästa påbörjas. Det skapar en säker och trygg process där få misstag görs. För ett IT projekt omfattar stegen i regel kravbearbetning, analys och design, utveckling, test, acceptanstester och slutligen leverans.

Om någon ändring läggs till projektet behöver samtliga steg genomföras igen. I de fall där felaktigheter upptäcks i ett senare steg i processen så behöver projektet backa. Kostnaden för fel och ändringar ökar därmed drastiskt med tiden.

I grunden är processen användbar och stegen logiska. Problemet blir när varje steg tar lång tid eller där omfattningen ökar vilket ger en ökad komplexitet, vilket medför ökad sannolikhet för fel. Om projekten kan begränsas, exempelvis genom att delas in i faser, finns det en bättre möjlighet att leverera delar av slutprodukten framgångsrikt. Genom att dela in projektet i riktigt många faser, som inte är längre än 1-4 veckor, börjar man närma sig ett agilt projekt.

Långa leveranstider skapar problem

Problematiken med vattenfallsprojekt, speciellt när de växer i omfattning, är att leveranstiden blir väldigt lång. Traditionella vattenfallsprojekt har en ledtid, från beställning till leverans, på 12-18 månader och ibland mer än det. Kombinera det med att processen bygger på att alla krav ska specificeras i början av projektet så uppstår ett vanligt problem - kravmängden omfattar allt som målgruppen behöver i dag och kan tänka sig behöva i framtiden.

Det innebär att verksamheten, användarna och beställaren ska specificera vad de vill ha om 12-18 månader och hur det ska fungera. Kravbilden växer snabbt, eftersom målgruppen vill säkerställa att de får med allt de kan tänkas behöva i framtiden. För många projekt blir det bara en leverans så då gäller det verkligen att få med allt som går att önska sig.

Optimera processen för en känd leverans

Om slutprodukten är känd för beställaren och leverantören har levererat en liknande produkt tidigare så finns det alla möjligheter att använda vattenfallsmodellen. Genom att leverantören skapar tydliga processer för varje steg i projektet kan ett automatiserat genomförande skapas. Genom att arbeta med processförbättring kan därmed leverantören öka sina marginaler och minska sina risker.

Flexibiliteten i processerna gör det möjligt att konfigurera slutprodukten. Genom att tydligt definiera hur slutprodukten kan konfigureras kan beställaren också ta ställning till olika beslut. Liknande tillval när man beställer en bil. Om mängden konfiguration blir för stor är projektet inte längre en standardleverans, utan en unik leverans. Då lämpar sig inte vattenfallsmodellen eftersom projektet måste vara flexibelt och utvecklas tillsammans med produkten.

Uppdaterades: 2012-03-21 20:10:27