”Vattenfall” eller ”agilt” – eller båda?

Enligt många råder det ett motsatsförhållande mellan att jobba med förändring och IT-utveckling enligt ”vattenfallsprincipen” respektive ”agilt”. Personligen har jag svårt att se att dessa principer alltid står i motsatsförhållande till varandra. Eller att ett företag måste välja det ena eller det andra arbetssättet eller att den ena principen alltid är bättre än det andra. I detta blogginlägg försöker jag förklara varför baserat på min egna erfarenheter från 18 IT-tunga företag över en trettioårsperiod.

Min gissning är att du som läser detta inlägg kommer att falla in i en av två kategorier enligt följande:

1. Du känner igen dig och håller med.
2. Du tycker jag är helt mossig.

Jag accepterar du kanske tycker jag är mossig, men jag hoppas att du ändå läser färdigt inlägget. Jag tror nämligen att det är viktigt för svenska företag att få ordning på sin styrning av förändring och IT-utveckling om de ska kunna vara produktiva och attraktiva arbetsgivare i framtiden, kunna hantera större förändringsresor och därmed hänga med i konkurrensen. Och jag tror inte att det finns någon ”one size fits all”-lösning för alla företag i alla branscher och storlekar. Därmed menar jag inte att det är enkelt att hitta en optimal ”styrningsmix”.

Vad är ”vattenfall” respektive ”agilt”?

Men först; ”Vattenfallsprincipen” innebär kort sagt att man först tydligt bestämmer vad slutresultatet ska bli (typ ett hus) och sedan bryter man ned en plan för att stegvis ta fram det beslutade resultatet efter principen ”först gör vi A, sedan gör vi B, etc”. I bästa fall får man det man vill ha ungefär när man vill ha det till ungefär den kostnad som man estimerade när man satte igång. Vattenfall brukar likställas med ”projektstyrning”.

Den främsta kritiken mot vattenfallsprincipen är att planeringsfasen blir väldigt lång och det är ändå svårt att göra helt korrekta bedömningar av komplexiteten och därmed resurs- och tidsåtgång samt förutse alla typer av problem som kan dyka upp på vägen. Projekt riskerar därför ofta att bli både dyrare och mer långdragna än planerat.

”Agilt arbetssätt” innebär att man inte börjar med att definiera slutprodukten utan man jobbar istället iterativt med idéer och testar sig fram i små steg för att se vad som funkar (typ utveckling av ett digitalt kundgränssnitt). När det fungerar leder arbetssättet till snabbare och bättre lösningar till en relativt förutbestämd kostnad (de avsatta resurserna).

Främsta kritiken mot agila arbetssätt är exempelvis att principer för arkitektur kan ignoreras och att dokumentation blir lidande vilket kan leda till ökad komplexitet och teknisk skuld på sikt. Det är också svårt att jobba agilt när komplexiteten är hög och många beroenden finns till andra IT-komponenter.

Min erfarenhet av projektstyrningsmodeller

2024 har jag i tretton år jobbat som konsult i mitt eget bolag. Innan dess har jag dels jobbat som chef eller specialist och dels som anställd konsult i ytterligare ca 20 år. Jag har räknat ut att jag har varit på 18 olika företag under de drygt 30 år som jag har varit aktiv i arbetslivet och de allra flesta har varit stora företag.

Oavsett om jag har varit anställd eller konsult så har det alltid varit mitt uppdrag att driva förändring av något slag vilket innebär att jag i dessa 18 bolag har varit tvungen att försöka förstå och tillämpa företagets – ibland superluddiga och ibland totalt överbyråkratiserade – projektstyrningsprocess samt oftast även deras IT-förvaltnings- och utvecklingsprocess (om en sådan funnits).

Det har inte varit helt ovanligt att uppdragsgivare – ibland på företagsledningsnivå – har försökt säkerställa att vi ska kunna driva projektet ”i linjen” eller på något annat sätt ”under radarn” för att slippa den överbyråkratiserade projektprocessens alla formaliteter och krav på dokumentation.

Det har även förekommit att uppdragsgivaren verkligen försökt förstå och följa projektprocessen för att säkerställa att projektet verkligen drivs ”by the book”. Detta för att inte råka ut för oväntade snubbeltrådar under projektets gång. Det har dock ibland varit omöjligt då styrprocesser inte hänger ihop, i synnerhet inte avseende hur resurser (personal och budget) ska äskas och godkännas till projektet.

Vem eller vilket forum som slutligen bestämmer brukar också vara en gordisk knut att försöka lösa upp. Räcker det till exempel att projektets styrgrupp tar beslut eller måste även ”linjeforum” som flera avdelningars ledningsgrupper också ta beslut? Och i så fall – vad är styrgruppens mandat egentligen?

Kan en linjechef lägga in veto mot att en av hens underställda ska jobba med projektet trots att ett ”resursäskningsforum för projekt” har godkänt detta? Kan man verkligen köra projekt ”i linjen”? Är inte det en motsättning i sig själv egentligen? Och var går gränsen mellan projekt och ett mindre IT-utvecklingsuppdrag? Det är inte ovanligt att man får lika många olika svar på varje ovanstående fråga som personer man frågar. Ju äldre man blir, desto mindre förvånad blir man och desto mer känner man igen sig från företag till företag.

Är agilt arbetssätt räddningen?

Personligen tycker jag om struktur, ordning och reda varför jag brukar försöka sätta mig in i de beslutade styrprocesserna och oftast är det inget större fel på dem – annat än att de inte förstås, följs och/eller respekteras av chefer och medarbetare. Det vanligaste problemet är – enligt mig – att man inte har definierat tydliga gränser mellan just ”projekt” (vilket kan vara allt möjligt av storlek, betydelse och komplexitet men per definition inte behöver innehålla någon IT-utveckling överhuvudtaget) och ”IT-förvaltning och utveckling” (eftersom många projekt trots allt ofta innebär ganska stor IT-utveckling).

Eftersom projektprocesser som bygger på ”Vattenfallsmetoden” är hopplöst ute i vår digitala tidsålder och ingen riktigt har kläm på när något bör drivas som ett projekt och när något kan hanteras i enklare förändringsprocesser så är man övertygade om att lösningen oavsett problem stavas ”Agilt”. Därför köper många in på SAFe© ramverket nedan och tänker att ”nu blir allt mycket enklare och tydligare”.

För vår projektstyrningsmodell var lite för svår att förstå…

…och den gamla IT-förvaltningsmodellen var ju hopplöst byråkratisk och krånglig…

Ok, nu raljerar jag, men jag tror att många känner igen sig. Ingen modell är bättre än den andra om den inte tydliggörs, förstås, implementeras och används av alla. Dessutom underskattar nog många företag hur lång tid det tar att sätta ett nytt arbetssätt i en otålig organisation där ledningspersoner dessutom frekvent byts ut med allt vad det innebär avseende omorganisationer, fokus och trender.

Svårigheten med SAFe©

Jag tycker att SAFe© är bra – för jag gillar genomarbetade modeller, men jag har stor respekt för att det är många roller, arbetssätt och resurser som ska koordineras och beslutas i olika nivåer. Personligen ser jag inte heller att det är så vansinnigt stor skillnad från den svenska modellen PM³ annat än att SAFe© har coolare amerikanska namn och att PM³ har en starkare fokus på att sätta ekonomiska ramar även för drift och förvaltning förutom själva utvecklingen.

Den viktigaste aspekten som ibland gör det agila arbetssättet svårt tycker jag är att det i verkligheten ofta finns många beroenden mellan olika IT-system. Detta gör det svårt att enkelt avgränsa ”IT-produkterna” som de självstyrande agila teamen ska förvalta och utveckla. Min uppfattning är att teamen ofta inte känner sig så självstyrande och agila som de förväntar sig och detta beror på att en stor del av de uppgifter som faller ner i deras backlog har beroenden till andra IT-produkter eller projekt. Dessa måste de ändå måste koordinera med andra team och projektledare, så hur självstyrande är teamen egentligen…?

Som exempel deltog jag i ett projekt på ett företag där det slutligen krävdes dataexporter och/eller IT-utveckling i 13 olika agila team för att realisera lösningen efter att man nyligen omorganiserat arbetet efter SAFe-modellen. Eftersom den gamla projektsstyrningsprocessen dessutom avvecklades innan projektet var slutfört och innan man fick ordning på styrningen på ”Portfolio”-nivån (se SAFe-bilden ovan) blev det kaos och otroligt mycket administrativt merarbete då det inte längre var tydligt vem som ansvarade för att få ihop helhetslösningen tvärs alla teamen och vem som skulle betala för det då projektet upplöstes.

Hur ser ”linjen” ut egentligen?

Ett annat bekymmer som jag upplever blir tydligare med agila styrmodeller är att de utgår ifrån att det finns en tydlig och fungerande linjeorganisation (verksamhet) att ”installera” den agila styrmodellen i. Alltså att det finnas utpekade ”affärsägare” av system i verksamheten som har kompetens och mandat att ta beslut om beställningar och prioriteringar av krav på nyutveckling. IT-utveckling sker ju inte i ett vakuum eller för IT-avdelningens egen skull utan ska på kort eller lång sikt förbättra företagets konkurrensförmåga – antingen genom att driva mer försäljning eller skapa högre intern effektivitet och därmed sänka kostnaderna.

Agila styrmodeller utgår ifrån att en tydlig linjeorganisation är på plats och då är det enkelt att ”installera” det nya agila arbetssättet med fokus på IT-utvecklingen. Ungefär som när man ska implementera Microsoft365 så utgår man ifrån att det finns ett operativsystem på datorn som gör att applikationen kan installeras.

Min spaning är dock att operativsystemet ”linjen” i IT-tunga verksamheter idag snarare liknar MS-DOS eller helt saknas om vi ska vara ärliga… För det är vanligt att det är oklart vem som egentligen bestämmer och har vilket mandat även i ”linjen”. Oftast är det inte heller en chef som ses som ”affärsägare” utan det kan vara någon form av ”forum” (alltså ett möte) som anses ha mandat att ta verksamhetsbeslut. Ibland finns det inte heller ordentliga mötesprotokoll från dessa ”forum”, så deltagare kan komma ut från forumet med olika versioner av vilka beslut som faktiskt har tagits och vad det då innebär för fortsatt arbete. Håhåjaja.

Money talks

Så varför behövs de här styrmodellerna överhuvudtaget kan man fråga sig? Jo, det handlar ju om att företag vill allokera resurser för att driva utveckling och förändring så effektivt som möjligt och ha möjlighet att följa upp kostnaderna. I slutänden är det alltså en ekonomisk fråga, men tyvärr är inte ens ekonomiavdelningen med på tåget när omställningen till det agila arbetssättet sker.

Så då kommer vi till den spaning som jag tror gör att alla dessa styrmodeller är svåra att implementera – nämligen vem/vilka bestämmer och betalar för förvaltning och utveckling av IT-system vare sig det drivs i projekt eller agilt? Vem är affärsägare? Hur mycket får det kosta? Vem prioriterar? Hur ska kostnader bokföras? Vad får konstanta förbättringar på ”IT-produkt” X, Y och Z kosta? Hur mycket resurser ska därmed allokeras till varje agilt team? Vilka kostnadsställen ska teamen tidsskriva mot? Vilka kostnader ska tas ”i linjen” och vilka ska tas av ”IT-produkten” och är det någon skillnad? Vilken budget har ett projekt?

Här brukar det råda total förvirring och risk för överadministration – i synnerhet om teamen eller projekten behöver bemanning med externa konsulter.

Min spaning är dock att operativsystemet ”linjen” i IT-tunga verksamheter idag snarare liknar MS-DOS eller helt saknas om vi ska vara ärliga…

I grunden är det ofta så att det finns en IT-avdelning med anställda medarbetare som är organiserade i en traditionell hierarki med olika specialistavdelningar där alla medarbetare har en chef. Avdelningarna kan exempelvis vara ”Utveckling” eller ”Test” eller ”Arkitektur” där avdelningschefen har en budget för att kunna betala medarbetarnas löner varje månad – denna kostnad är relativt konstant och överblickbar.

Med agila styrformer är det dock så att IT-medarbetarna tillbringar sin tid i ett eller flera agila team inom definierade ”IT-produkter” (eller ”funktionsområden”) som t ex Business Intelligence, Webb/app, HR, Kundservice, etc och sedan tidsskriver mot dessa agila teams ”virtuella” kostnadsställen (om de finns). Detta innebär att en schabloniserad timkostnad för IT-medarbetarens tid belastar teamets cost center. Detta görs för att man ska kunna se vad kostnaden för ”IT-produkten” är. På detta sätt flyttas IT-medarbetarens lönekostnad från IT:s ”linjebudget” till ”IT-produktens” (antingen enbart på pappret eller så ligger det till grund för interndebitering gentemot verksamheten á la ITIL-tänk).

Vem äger budgeten?

Detta upplägg kräver ju dock att det görs en budget för ”IT-produkten” och kontinuerligt följer upp att kostnaderna inte överstiger planen. Detta brukar inte alltid göras utan ”affärsägaren” utgår ifrån att IT har budgeten eftersom 90% av det agila teamets kostnader oftast är IT-resurser. (Ibland tycker tyvärr IT också att de ”har ”äger” budgeten vilket skapar en ännu märkligare situation…)

Problem brukar därför ofta uppstå när ”affärsägaren” vill ta in ytterligare resurser – oftast extern konsult – och betala via ”IT-produktens” budget. Det är nämligen sällan HR-systemet är riggat så att affärsägaren kan vara den externa IT-konsultens ”chef” i systemet utan det måste oftast IT-avdelningschefen vara (för konsulten är ju en IT-resurs). IT-avdelningschefen har då inte pengar i sin linjebudget för den externa konsulten utan fakturan måste skickas till det agila teamet och attesteras av affärsägaren – som då kanske inte ens har attesträtt i systemet för att enligt ekonomisystemet så följer attesträtt med linjeorganisationen. Eller så säger IT helt enkelt nej för de har inga pengar för ytterligare en konsult. Ja, sedan är cirkusen igång.

Vem bestämmer? Vem har pengarna? Hur ska det bokföras och kostnadsföras? Om inte dessa ”tråkiga” delar är utredda innan det agila arbetssättet införs finns stor risk att grundtanken med ”affärsägare” och självsstyrande agila team fallerar då man inte har så mycket självbestämmande – annat än i teorin. Så hur mycket vi än pratar om samarbete, gemensamma mål och tvärfunktionalitet så kvarstår ett tråkigt faktum; Money talks.

Mina slutsatser

I slutänden handlar allt om hur ett företag vill styra över sina resurser för förändring och utveckling och det finns sannolikt inte en modell som passar för alla situationer, alla företag i alla skeden och storlekar och därför tänker jag att:

• alla företag behöver ha en projektstyrningsmodell á la vattenfall som kan användas för att driva stora övergripande komplexa förändringsinitiativ – oavsett hur mycket eller lite IT-utveckling projekten innebär. Dessa projekt bör finansieras och styras av högsta företagsledningen. Det bör inte pågå fler än fem sådana projekt samtidigt och de ska vara prioriterade från 1-5 så att alla i hela organisationen vet vilken prioritering som gäller när det uppstår resurskrockar i i diverse utvecklingsteam.
• alla företag behöver också ha en effektiv styrmodell för löpande drift, support, förvaltning- och utveckling av sina befintliga IT-system. Det kan vara SAFe©, PM³ eller en hemmasnickrad variant så länge den baseras på ett gemensamt ”ägande” mellan IT och berörd verksamhet. Samtliga krav mot ”IT-produkten” hamnar då i en och samma backlog för att sedan prioriteras och genomföras baserat på en gemensamt beslutad plan med hjälp av metodik som Kanban och/eller Scrum.
• slutligen måste kostnaderna och nyttan enkelt kunna budgeteras och följas samt det måste vara tydligt på vilket sätt och av vem projekt och ”IT-produkter” får sina resurser.