Vattenfallsmetodiken en kostsam myt

Om du skulle göra en gissa hur det gick till när vattenfallsmodellen blev världens mest använda modell vad skulle du gissa:

• a) Det var en grupp av forskare rekommenderade vattenfallsmodellen som bästa alternativ (dåvarande)
• b) En industrigrupp innoverade fram en produktutvecklingsmodell som blev adopterad i världen
• c) En för arbetet inkompetent person valde en bild på en utvecklingsmodell som han kunde förklara och denna bild blev adopterad i världen.

Du kanske har redan gissat att varken a eller b är rätt svar?

Vad som hände var att Winston Royce skrev en rekommendation på hur stora mjukvaruprojekt borde sätta upp sin utvecklingsprocess. Royce publicerade artikeln 1970 i IEEE PROCEEDINGS WESCON. I dokumentet så beskriver Royce hur utvecklingsarbetet sker först genom att visualisera de två huvuddelarna Analys och sedan till Kodning vilket kunde fungera för små rutiner men inte stora system. För att utveckla stora system och att leverera dem till slutkunden behövdes det flera steg som Systemkrav => Detaljerade krav => Analys => Design => Kodning => Testning. Där har ni vattenfallsmodellen. I Royce papper dock är det så att Royce själv inte kallar det för vattenfallsmodellen eftersom han säger följande:

”I believe in this concept, but the implementation described above is risky and invites failure.” -Royce

Vad Royce rekommenderar beskrivs på sidorna efter  den s.k. ”Vattenfallsmodellen” och är en iterativ process som först skapar en eller flera prototyper som kastas bort innan den riktiga utvecklingen påbörjas. Allt för att skapa och utveckla kunskap så snabbt som möjligt. (Se bilden nedan för Royce rekommenderade modell).

The sw development model recommended by Royce

Vattenfallsmodellen blir till 1985

Royce papper lever ett ganska tynande liv tills Department of Defence inser att de behöver en standardisera leveranserna till amerikanska försvaret och påbörjar arbetet med MIL-STD-2167.     1985 är året när MIL-STD-2167 kommer ut och standarden slår fast att bild nummer 2 från Royce papper är standarden som alla företag måste följa om de vill leverera mjukvara till amerikanska försvaret. Nu exploderar adoptionen av vattenfallsmodellen, i tyskland så skapas V-modellen som baserar sig på vattenfallsmodellen.

See googles Ngram över vattenfallsmodellen => Länk till google

Det dröjer dock inte länge innan amerikanska försvaret uppdaterar MIL-STD-2167 att innehålla en mer iterativ eller evolutionär modell men skadan är skedd, hundra eller tusentals företag använder sig av vattenfallsmodellen och en arme av konsultbolag utbildar företag och hjälper företag på att använda modellen.  Idag så rekommenderar försvaret en helt iterativ och inkrementell modell (Följ länken).

En av författarna bakom MIL-STD-2167 har själv gått ut och sagt att han inte förstod iterativ utveckling eller evolutionär utveckling därav så fastnade han för den enklare av bilderna i Royce papper. Detta kallar han för det största misstag han begått i sin karriär.  Nu är det dock så att jag har inte själv hittat denna intervju utan hörde detta berättas under flera tillfällen när jag var i Washington DC på 90-talet så jag berättar det som en anekdot som inte är lika fastställd som de övriga detaljerna här.

Varför spred sig vattenfallsmetodiken så snabbt?

Andra områden använde sig av liknande modeller – exempelvis inom hårdvarukonstruktion, byggnation mm. Så steget var inte stort till att applicera det till mjukvara med, dessutom har det en känsla av logik i sig.

Det är förföriskt logisk och lockande -tankesättet vi använder är nu har vi fått en enkel och stringent process och om vi ALLA följer den så kommer vi att lyckas bra.

Används vattenfallsmodellen verkligen idag?

Om ingen ens trodde på modellen på 80-talet och till och med standarden där den namngavs och spred sig ändrade den till en för situationen mer anpassad modell så är det väl ingen som använder den idag?
Olyckligtvis är det så att stora delar av projektlitteraturen fortfarande driver vattenfallsmodellen framåt och idag har den cementeras som Stage-Gate modell för projektkontroll inom portföljhantering. Många projektledare kanske säger att de använder RUP eller andra projektmodeller men oftast driver de projekten som vattenfallsprojekt. Många projektmodeller cementerar vattenfallsmodellen via explicita krav på leveranser som måste följas för fasen (stage gate varianter)

Antagandet bakom vattenfallsmodellen är att vi kan göra Big-Design-Up-Front (BDUF) och sedan fortsätta men frågan är när kan man göra det i verkligheten. Om vi tittar på omvärlden som projekten kan finnas och tar Cynefin Modellen av Dave Snowden till hjälp för att förklara detta.

Om projektet befinner sig i det enkla ”Simple” området där vi känner till allt om vår omvärld och teknologin då skulle vattenfallsprojekt kanske kunna fungera effektivt där med. Jag säger bara kanske för det som driver kostnaden och tidsåtgången är beroende på kvalitén som vi arbetar med.

Om det är så att projektet opererar i områdena komplicerar eller komplext så vet vi väldigt lite om de olika faktorerna inom området: produkten, kundens behov, teknologin och hur allt hänger ihop. Här måste vi iterera, prototypa och undersöka en massa för att skapa något som genererar nytta för slutkunden. All produktutveckling betyder någon slags innovation och nyskapande för att det är just de två sakerna som skapar värde för användaren. Om vi skulle göra exakt samma produkt vi gjorde för tre år sedan så skulle inte kunden köpa det.

Komplicerade-Komplexa områdena

De flesta projekt som försöker skapa värde för kunden på någon marknad. Antingen skapar vi en ny produkt/tjänst där vi inte vet hur kundens sammanlagda behov ser ut eller om summan av alla saker i vår produkt/tjänst fungerar tillsammans på ett bra sätt eller ej. (Läs Jävla Skitsystem av Jonas Söderström om hur ofta kunden eller slutanvändaren blir missnöjd med systemet som vi skapar)

Det finns en konsensus hos både forskare och praktiker som arbetar med hur organisationer blir bättre och effektivare på produktutveckling och hantering av komplexa miljöer och det är att man måste bygga kunskap snabbare än tidigare. När man påbörjar ett arbetet projektutveckling eller effektivisering av sjukvårdssystemet så är det just i startögonblicket man vet minst om sin omvärld och vad som händer när man påbörjar arbetet. Vattenfalls metoden är en dålig modell att använda när det gäller att bygga kunskap i komplexa eller komplicerade fall.  Man behöver både top-down och bottom-up arbete, varje sak man genomför kanske gör att man ställer flera nya frågor som gör att man behöver göra kursändringar.

Bra saker med Vattenfallsmodellen – finns sådana?

I diskussioner eller i dokument så brukar följande argument användas för vattenfallmodellens överlevnad:

• Vi behöver struktur för att kunna förklara för intressentgrupperna hur långt vi har kommit och se vad för status vi har
• Vi behöver någon mekanism för att kunna avsluta projekt i vår projektportfölj. (Närbesläktat med behovet för Stage-Gate) Dvs vi omvärderar affärsbehovet för projektet från ett helheltsperspektiv för att kanske stoppa ett projekt och ge de resurserna till ett annat viktigare projekt.
• Vi behöver någon mekanism för att hantera finansieringen av projekt. För varje gate eller fas så släpper vi ytterligare finanser till projektet.

Alla saker som listas ovan behövs, ingen tvekan om det. Det finns inget bolag idag som inte har bra kontroll över sina finanser och hur pengarna används.

Hur hanterar super agila startups de här frågorna?

Jag träffade Bill Aulet (@BillAulet) (Specialist på Entreprenörskap) på MIT i våras och hade möjligheten att diskutera frågan med honom samt ett antal grundare till tech startups och olika Venture Capital finansörer. Till och med snabbrörliga startups har en stenhård kontroll över sina finanser och sätt att förklara för finansiärerna hur långt man kommit i arbetet men som en av finansiärerna sa ”If a company uses waterfall or traditional stage gate processes we do not finance it or we bring in our own experts to change the way they work” .  Eller som produktutvecklings experten Eleine Chen (@chenelaine) uttryckte det ”Waterfall? Nobody uses waterfall anymore, the costs are too high”. Hennes kontext var just företag i Boston området, hon är medveten om att företag runt om i världen använder vattenfallsmodellen.

If your company is in market that has status quo and none of the competitors improve their product delivery process nor their innovation process then you will probably not need to improve. But for all other companies if you do not improve on both counts you will be roadkill

Kort och gott – startup företagen måste hålla sina finansiärer uppdaterade med status för att fortsätta få finansiering, de behöver se vilka projekt, delprojekt eller experiment som skall fortsätta få finansiering samt vilka som skall läggas ned.  Behoven är samma men de snabba startup företagen hanterar inte det genom vattenfallsmodellen eller stage gate som det oftast defineras.  Är det så att startup företagen är så pass annorlunda att deras erfarenheter inte går att applicera på etablerade företag? En skillnad är att nästan alla startups är begränsade av hur mycket pengar de har så varje krona, dollar eller euro måste användas optimalt. Dvs dessa bolag är på den vassa sidan där varje beslut kan ha riktigt ödesdigra konsekvenser för bolaget eller ägarna.

Problemet med vattenfallsmodellen

Bara så vi slår fast en sak alla projekt kan köras med vattenfallsmodellen, dock till en betydligt större kostnad både i tid och pengar. Oftast märker vi först i sluttampen att projektet drar över sin budget och tidsram – varför är det så?

Enkelt uttryckt så är pga följande saker:

• Att skriva kravbilden låter sig göras eftersom vi inte testar var problemen finns förrän vi börjar utvecklingen
• Att göra Specifikationer/Design går bra eftersom vi inte upptäcker problemen förrän utveckling/testning
• Vi väntar med testning till sist av allt

Så vi skriver kraven när vår kunskap är minst samt att vår lärande loop är så lång att vi har i praktiken inget sätt att lära oss hur vår produkt/tjänst fungerar i verkligheten. När vi väl får de lärdomarna så är det för sent att göra något åt det utan att försena hela projektet.

Låt oss se hur väl vattenfallsmodellen verkligen möter de tre grundkrav som vi har på den.

1. Vi behöver förklara vad vår projektstatus är för våra intressenter. Det som händer oftast är att kraven skrivs och kanske är några frågor ej besvarade och styrgruppen godkänner att man går över till nästa fas med anmärkningen att projektet måste svara på frågorna till nästa fas/gate review eller någon milestone. I de första faserna så kan inte intressenterna säga om kvalitén på kraven och specifikationerna är tillräckligt bra för att projektet inte skall få problem under utveckling eller integration.  Om du inte tror mig undersök själv hur ofta projekt som gick över tid och budget i din organisation flaggades som riskprojekt pga undermåliga krav eller specifikationer under fas granskningen. Jag tror att du inte kommer att hitta någon statistisk korrelation mellan projekt som ”misslyckades” komma i tid och budget och projekt som godkändes/icke godkändes under tidigt fas-granskning. Snarare är det så att vattenfallsprojekt lider mycket mer av 90% syndromet. Du känner igen att man rapporterar att man är nästan klar under en längre tid.
2. Vi behöver någon mekanism för att avsluta projekt i vår projektportfölj. Om det är en strategisk fråga om resurser så borde beslutet tas snarast och inte vänta på någon fas eller gate. Om det är en fråga om att stoppa projekt som inte kommer att möta kraven på avkastning eller marknadsfördelar så är det tyvärr så att de tidiga faserna sällan ger tillräckligt kunskap om hur de senare faserna kommer att kosta i tid eller pengar så där faller vattenfallsmodellen. Om det är så att omvärlden ändras så att projektets förutsättningar ändras så borde beslutet fattas snarast oavsätt om man kommit till en fas granskning eller gate.
3. Vi behöver en mekanism för att finansiera projektet. Detta handlar om att balansera projektrisk dvs vi kastar inte in mer pengar om inte projektet kan leverera i tid för att nå effekten på marknaden. Det är samma resonemang här som i punkt 1. Vi vet inte förrän vi startar testning hur mycket problem vi har och vad den slutgiltiga kostnaden blir. Här finns gott om exempel från både fordonsindustrin och flygindustrin på komplexa projekt som drar ut på tiden 300-400%. Ett exempel är från flygindustrin där nya generationens transportplan skulle ta ca 6år men i efterhand tog projektet 21år.

 Hemligheten bakom 300-400% förbättring – droppa vattenfallsmetoden

Systemtänkande säger att störst hävstångseffekt får man om man kan ändra sitt sätt att tänka. Alternativ till vattenfallsmodellen kräver ändring i hur våra egna mentala modeller ser på produktutveckling och innovation.

Integrationspunkter som pull-events är den huvudsakliga ändringen men det finns ytterligare flera tekniker man använder för att bygga kunskap än snabbare beroende på vilken industri man befinner sig i.  En viktig sådan metod är Set-based design där man skapar flera olika alternativ till en början. (kom i håg att vi vet minst när vi startar projektet) Sedan hittar man sätt att snabbt avsluta konceptalternativen och detta skapar snabb kunskapsinhämtning i projektet. För varje integrationspunkt har man dödat av flera alternativ och demonstrerat både kvaliten och statusen hos slutprodukten/tjänsten. En av våra Nordiska banker använde delar av konceptet för att skapa en av deras mer innovativa tjänster.

I Sverige är det flera företag inom industrin som har kommit olika långt med detta bland dessa har vi Scania, Volvo, Ericsson och det är mycket tack vare Lean Product Development (LDP) rörelsen i Sverige som dessa metoder kommit hit på hårdvarusidan. Inom mjukvarusidan har Agila metoder drivit fram utvecklingen just inom projekten men programhanteringen på mjukvarusidan har inte kommit lika långt som inom LDP rörelsen.

Testa själv – simulera

Här nedan har du en länk till en projektsimulator som bygger på vetenskapen och metodiken System Dynamik. Modellen bygger på arbetet som forskare på MIT gjorde under 80-talet och grunden till modellen användes i domstolen för att bestämma hur stor del av ansvaret var beställarens jämfört med leverantörens när ett av amerikanska försvarets jätteprojekt blev försenat.  Nyligen används denna modell  av ett teknikbolag för att ändra hur man leder projekt med en besparing för bolaget i storleksordningen Nio Miljarder svenska kronor.  Modellen är väl testad och använd internationellt, detta nämner jag så att du har någon bakgrundsinformation innan du använder simulatorn.  Observera att du kan inte använda simulatorn för att bestämma exakt vad för resultat ditt bolag skulle få om ni ändrar ert sätt att arbeta.  Detta eftersom jag har låst fast ett antal av parametrarna men relationerna och storleksordningar för olika case är vad som är intressant här. Vi använder denna och andra mer avancerade simulator i just masterclass utbildningar om projektdynamik och hur man förbättrar sin produktutvecklingsprocess.

Länk till simulatorn

Simulera själv, du behöver endast påverka en variabel vi håller allt annat på standardvärdena.  För att reflektera vilken effekt integrationspunkterna har på ett projekt så ändrar vi ”Maximum Time To Discover rework” detta symboliserar att vi genomför iterationer med samma längd som vi sätter på Maximum Time to Discover Rework. (Dvs vi genomför krav, design, specifikation, utveckling och testning inom den tiden)

Step 1 – Project Setup Only change ”Time to Discover Rework”

Step 2 – Dashboard run the project and check results

Run the experiment with these three cases;

1. Max Time to Discover rework = 12 månader (symboliserar vattenfallsmodellen)
2. Max Time to Discover rework = 6 månader (vi sätter upp frekventare integrationspunkter)
3. Max Time to Discover rework = 3 månader (än frekventare integrationspunkter)

Om du inte vill köra simulationerna själv så kan du hitta resultaten i tabellen nedan.

Att notera:  Harley Davidson – bolaget där många av dessa erfarenheter kommer ifrån gick från Time to Market på +72 Månader (2001) till 28månader (2006)

Med simulationen så vill jag påvisa vilken effekt man kan uppnå i projekt genom att ha integrations event istället för normala vattenfalls faser, självklart är att projektet skulle försöka påverka resultatet genom andra mekanismer när man upptäcker att man håller på och skrider över budget eller tid men det var inte den dynamiken och effekten vi försöker förstå nu.

 Nya tankebanor

Min förhoppning är att du har upptäckt att det finns alternativ till vattenfallsmodellen oavsett vilken branch du befinner dig i. Att du nu förstår varför vattenfallsmodellen bidrar till en ökad kostnadsbild inom produktutveckling och hur du kan spara massor åt din organisation. Framför allt att du börjar fundera och frågasätta varför saker görs som de görs – ibland har vi fått felaktig information som vi baserar våra mentala modeller på.