ProjektledarDetta är en maskinell transkribering (KB-Whisper) av avsnittet som publicerades 2025-09-04. Fel kan förekomma.
Lyssna på avsnittet: 66: Traditionell projektledning tillsammans med agilt, Anders Miller berättar om SEB projektstyrningsmodell Läs sammanfattningen: Från Agilt till Projektstyrmodell – SEBs Väg mot Effektiv Projektstyrning (66)
Transkribering
När man väl kommer in i nästa steg, planering osv. då har man ofta byggt upp en struktur som är ganska lätt att omvandla in där vissa delar omvandlas in i den agila strukturen med pix och features. Och då rullar det på i den strukturen vi har. Den du har hört Anders Miller, han är otroligt givmild i det här avsnittet och delar hans erfarenheter av utvecklingen av banken SEB:s nuvarande projektmodell. Du kommer bland annat höra hur de kombinerar traditionell projektledning med det agila. De har kommit långt i den här resan, faktiskt en av dem Som jag känner till det har de kommit längst.
Så lite reklam. Höstens AI-kurser börjar fyllas på. Vi har tre olika typer av kursdagar. Grund, fortsättning och sedan en specifik för Microsofts Copilot. Du kan spara hundratals timmar av misslyckanden genom att gå på en eller två dagar av våra kursdagar. Vi har öppna kurser i Stockholm, Göteborg, Malmö, Uppsala, Örebro och Västerås och de bokar på Projektledarpodden.se.
Det vi gör mest då, företagsinterna kurser, de kör vi där ni vill, vare sig det är i Sverige eller utomlands. Där kan ni antingen höra av er på Projektledarpodden.se eller bara mejla mig. Jag som har podden heter Mattias Ejebe och nu kör vi! Du lyssnar på Projektledarpodden. En podd för dig som gillar att leda projekt och vill lära dig mer av andra, om projektledning. Idag har vi med oss Anders Miller från banken SEB.
Han och jag kommer idag prata om traditionell projektledning, agil projektledning. När ska man använda det ena? Och när ska man använda det andra? Välkommen till podden! Anders Miller. Tack så mycket!
Det här blir spännande! Ja, det blir jättespännande. Berätta, vad har du för roll idag på banken SEB? Idag ingår jag i ett team med projektledare som arbetar med de lite mer övergripande initiativen inom banken. Och det kan vara sånt som går kort flera dagar. direktioner, större transformationer och större förändringar. Och samverka med de projektledare som driver de här projekten och våra andra ägare till olika typer av processer och uppföljningar och annat som vi jobbar med inom banken.
Du och jag kom in på det här när vi pratade lite grann om den här hybridprojektstyrning som modell. Berätta lite grann. Hur blev du involverad i det här? Ja, till att börja med är det så att banken, precis som förvaltningen, Många andra håll gick ganska all in kring agilt och agilt arbetssätt. Och naturligtvis via safe som en start. Under en lång tid så gällde det.
Sen har man successivt börjat arbeta med och då inkorporerat flera delar av det som är lite speciellt för hur vi arbetar i den komplexa och det blir ju en organisation som man ofta har i stora organisationer. Det innebär att man skapar ett agilt arbetssätt eller agilt ramverk som man kallar för Lean Agila Framework eller populärt Det här fungerade jättebra och gör fortfarande. Det vi såg också var dock ett ganska stort initiativ och transformationer som man behöver jobba med inom en bank och många andra företag antagligen också behövde få lite mer styrning och koordinering på en högre nivå. Det innebar att vi jobbade vidare och tog fram en projektstyrmodell som var, inte traditionell, men innehåller traditionella delar, mycket marknadsstandard men också en väldigt tydlig koppling. till vårt interna arbetssätt när det gäller rena utvecklingsarbeten eller affärsutveckling inom ramen för det agila.
Så det är en kombination helt enkelt. En hybrid? En hybrid ja. Vi försöker undvika det begreppet lite grann även om det är väldigt populärt För vår tanke och det sätt vi har insett som är mest effektivt är att du funderar väldigt noga när du startar ett initiativ huruvida du faktiskt kan bedriva det rent agilt i det värdeflöde där man har människor som arbetar med just det. Eller om man behöver koordinera på en hög nivå. Det blir en hybrid men samtidigt är det väldigt tydligt att det är lite olika beroende på vad du behöver göra.
Hur skulle du beskriva SCB:s nuvarande sätt att styra initiativ? Delvis har vi naturligtvis en linjeorganisation som alla andra. Men vi har också lagt mer virtuell organisation uppe på den. Det är egentligen där Agila kommer in med olika domäner, Times Arch och så vidare. Syftet med den är att kunna anpassa oss smidigt till det arbete man har framför sig och inte nödvändigtvis göra förändringar i organisationen beroende på de olika delar man behöver genomföra. Styrningen av initiativ ligger inom det vi kallar för domäner som har ett ansvar och en försmak för vad som ska göras inom olika områden.
På toppen ligger naturligtvis, som alltid, våra exekutiva organ och en del andra beslutsorgan för att styra initiativ och kanske specifikt prioritering mellan olika initiativ. sekvensering och när och hur det är något som landar väldigt tydligt i den agila strukturen. Men också på våra projektledare att samordna på bästa sätt. Du beskrev det här att ni har två ramverk som samverkar. Beskriv lite mer. Först har vi vår projektstyrmodell naturligtvis som jag nämnde. Den är ganska standardiserad.
Det är ingen överraskning för projektledaren som kommer in. Vi har försökt anpassa vissa delar som är lite specifika för oss, arbetssätt och annat. också gjort ganska mycket ansträngningar i att vara tydliga med vad som gäller när vi arbetar mot den lite mer agila strukturen. Hur jobbar vi med fex och features osv. inom ramen för det agila? Så det är två samverkande ramverk som också är väldigt tydligt utpekade i våra instruktioner för hur vi ska bedriva vårt arbete. Vi har instruktioner för det mesta precis som alla andra stora företag som vi följer på ett noggrant sätt.
De här två i kombination tror jag har gett oss möjlighet att få den bästa möjligheten effekter än att bara införa till exempel en renodlad Vattenfallbaserad styrmodell för projekt, det har vi haft tidigare. Men vi försöker anpassa oss och få in det bästa av båda världarna. Historiskt har ni jobbat traditionellt och sen gick ni över till agil. Kan du berätta om hur den historiken ser ut? Banken startade 1856 och vad som hände på den tiden kan inte riktigt svara på. Men jag vet att i olika svängar fram och tillbaka, beroende på hur metoder och annat utvecklas så kan jag säga fram till 2019 i alla fall under den tid jag varit med, så hade vi en tämligen vattenfallsbaserad modell med ganska mycket dokumentation i förväg, ganska mycket detaljerade krav och så vidare.
När vi efter 2019 växlade in på det agila så blev det inte det man ibland pratar negativt om att nu behöver vi inte dokumentera någonting. Vi har fortfarande väldigt tydliga krav på det och det görs väldigt mycket sånt i den agila strukturen också. Men fram till 2019 så var det Vattenfall 2019 framåt i ungefär fem år var det väldigt mycket agilt. Vi hade även då en projektstyrmodell som talade om vilka delar som var viktiga t ex kommunikation, riskhantering, allt som har att göra med traditionell projektledning. Men 2024 någonstans, eller förra året, kanske tidigare också så började vi inse att vi behövde hitta en kombination.
För vi hade ganska stora pågående initiativ som behövde ha en mer omfattande koordinering, sådant som gick kors hela banken, Och det är där vi tittade på vad vi behöver göra för att stötta de som arbetar med den här så att man verkligen får både en form av obligatoriska delar men mycket mer support och stöd i det dagliga arbetet även för projektledare. Och där föddes den här versionen av vår projektstyrd modell. Så vilken typ av initiativ kör ni helt agilt och vilken kör ni med i kombination? Och hur går det till rent praktiskt när det är Bevis?
Man kan säga så här att det vi kör helt agilt eller åtminstone i den agila strukturen, det är sådant som handlar om att vidareutveckla det vi har ganska mycket. Det kan vara tjänster som man äger i den lokala kontexten t.ex. inom en tribe eller för den delen en domän. På sina håll beroende på var vi befinner oss och vilken typ av struktur man har så är det så att ganska stora saker sker också helt inom ramen för den agila strukturen. När vi kommer in på att vi behöver köra lite mer enligt projekt eller kanske till och med enligt ganska omfattande program är när saker går väldigt mycket cross.
När vi har väldigt mycket deadlines internt eller ännu viktigare kanske för en bank med de regulatoriska krav vi har externa deadlines som är jätteviktiga att vi håller. Ganska mycket saker som behöver kapacitet från samma håll när det blir fråga om en väldigt tydlig prioritering och hantering av det dagliga. Vad gör vi först osv. Rent praktiskt skulle jag säga att rent praktiskt fungerar det nog så att en projektledare eller den som får ansvaret börjar med att göra en traditionell plan med en struktur. Vi kan nämna massor med termer från projektledningen det kanske är ingenting jag behöver ta här.
Men när man väl har gjort det så börjar man titta på vad är det vi behöver göra och varför och ungefär var kommer det slå i form av kapacitet och behov. Det är vad vi kallar för initiation-face och det är inget nytt heller för en projektledare. Men vi försöker också undvika att ta ytterligare steg innan vi har gjort det här arbetet i grunden väldigt bra. Så när man väl kommer in i nästa steg, planering osv då har man ofta byggt upp en struktur som är ganska lätt att omvandla, där vissa delar omvandlas in i den agila strukturen. Och då rullar det på, i den strukturen vi har.
Vi har totalt sett vissa PI-planeringar, där vi totalt sett tror att det är närmare två tusen personer i olika roller som är med och planerar samtidigt samma vecka, fyra gånger per år. Där sker mycket av arbetet rent praktiskt att säkra att rätt saker och ting kommer i rätt tid från rätt område. Du sa att de var kvartalsvisa, vad för något? PI-planeringar. Och vad är det? Berätta!
En PI-planering det handlar helt enkelt om, låt oss kalla det för en… Det har hetat program increment. Nu tror jag att det kanske fått ett nytt namn. Men i alla fall så handlar det om att man samlar sig, man tittar på vad är det vi har gjort, man jobbar med insikter i så kallade inspekten och tittar på: vad har vi gjort rätt, vad har vi gjort fel, vad har blivit Var blir det sämre, hur ska vi jobba? Men sen går man också in och gör en planering som handlar om vad vi ser framåt. I bästa fallet vad ser vi framåt på lång sikt som vi behöver hantera.
Men också i ett kortare perspektiv, vad är det vi behöver göra hos oss just då? Sedan koordineras det här löpande under den här läktaren mellan de olika teamen inom en art, mellan de olika arterna, och ibland ännu högre nivå för att hitta vad som är viktigast att göra just nu. Det är ett ganska traditionellt arbetssätt enligt det agila. det är här också våra projektledare har en väldigt viktig roll att tillsammans med den rollen vi har i Chief Product Oner att titta på hur ska vi se på prioritering och sekvensering av de saker som behöver ske också ur ett projekts perspektiv. Väldigt viktigt att få med det.
Jag är så imponerad över hur ni får till det här att under en vecka få ihop allt det här. Jag har inte sett det på så många företag. Det är en intressant och ganska omfattande koordination faktiskt, men jag skulle nog säga Verkligen credit till de som jobbar med det här och även våra Agila Chiefs master osv. Som oftast är de som håller ihop det här praktiskt. Man får till det här, man får till lokaler, möten och arbetet på ett väldigt bra sätt. Och givet också vår projektstyrmodell där vi har lagt ner mycket tid.
Så kan jag också säga att våra Agila coacher har lagt ner väldigt mycket tid på att få till en bra struktur kring det här. Och vi försöker också vara tydliga med, inom Agila, vilken typ av event man behöver ha. Inte bara att planera den här veckan för tre månader utan man också jobbar med strategiskt långsiktiga planeringssessioner. Men just den så kallade PI-planeringen den ligger samma vecka och har faktiskt legat samma veckor under ett par år nu. Så folk börjar bli ganska vana vid det. Ja men just det att det inte bara är det agila utan att ni får ihop projekt, det agila, och verksamhet och det strategiska att under en vecka återbesöka det här.
Jag är imponerad. Hur förhåller sig styrgrupper, beslutspunkter, projektkontroll till de här agila teamens arbete i de här initiativen om vi går ner lite mer praktiskt? Det är lite olika faktiskt. På vissa områden är man otroligt integrerad hela vägen. Från affärslinjens yttersta spets ner till minsta tekniker och utvecklare. Och det beror också lite på vilka produkter och tjänster man arbetar med.
I många fall är det också så att det är väldigt självgående tribes som inom sig har flera Man jobbar ganska intensivt med de värdesströmmar som man ansvarar för och ser till att det blir så bra som möjligt. Våra projektledare deltar i det här och har tydliggjort i en mer översiktlig plan vad är det för större saker som respektive område behöver leverera. Sedan kommunicerar man kring det och försöker planera in det så gott det går. Jag skulle säga att även om våra givna strukturer jobbar med en kvartalsvis PI-planering så tror jag nog att våra projektledare jobbar med betydligt tätare justeringar av plan, anpassning av plan, ta hänsyn och ta höjd och hantera effekter av minsta försening eller för den delen positiva leveranser.
Så det är hela tiden en löpande koordinering från våra projekts sida. Det är ju inte så att man gör en planering för kvartal och så stänger man dörrarna och låser in sig utan det är hela tiden. Och på sina håll kan jag säga upplevelsen är nog att man planerar om betydligt oftare därför att saker och ting händer och behöver hanteras. Skulle ingenting hända skulle det kanske inte behövas som projektledare tänker jag. Men de här två ramverken ni har då risken är ju att vi dubblerar administrationen. Hur undviker ni det här?
Ja, det är egentligen ingen dubblering av administration därför att de saker som projekten behöver koordinera och få utförda vi kan säga att de består av två delar. Den ena kan vara helt interna projektdelar eller sådant som inte berör den agila strukturen. De hanterar man på olika sätt enligt normal standard projektledning. De delar som är tydliga leveranser från vår agila leveransorganisation där jobbar man ju mer eller mindre hela tiden med fiktures ochoton så det blir en naturlig koppling till det arbetssättet som gäller för det agila. Så det finns ingen motsats.
Ibland pratar man om projekt versus agile eller nåt sånt och jag gillar inte den termen därför att det här är verkligen nånting som hänger ihop. Bara man är tydlig och hittar sätt att beskriva saker och ting så att alla förstår så är det inga stora konstigheter. Jag upplever ibland att Den största utmaningen man har i stora organisationer är när man börjar prata om samma sak fast med olika namn. Det har vi försökt undvika vi jobbar med samma terminologi. Även om det projektet kallas för en work-night-structure eller ett work-itemp så blir det någonstans ändå kopplat till en Epic och en feature i den agila strukturen.
Vad var det som gjorde att det inte dög eller inte räckte att bara jobba agilt? På sina håll gör det det ska jag tillägga. Men väldigt ofta är det så att speciellt för finansvärlden men regulatoriska krav, stora transformationer i form av kärnsystem som ska förändras. Det sker ganska mycket saker på marknaden utanför oss. Jag menar inte bara affärsmässigt utan regelverk som styr hur man arbetar med produkter och vad man behöver göra för att stötta så man verkligen fungerar i den viktiga världen av finansiella tjänster. Då krävs det ibland att man koordinerar ganska mycket människor och på ganska många olika håll.
Där saker och ting hänger ihop på ett sätt som gör att man måste vara tydlig med att den här leveransen om inte vi får den här då kommer de här två andra leveranserna inte kunna användas. Det innebär i sin tur att vi kommer att missa ett specifikt datum där vi t ex har ett regulatoriskt krav att någonting ska fungera eller det kanske är en marknadseffekt man är ute efter. Kundanpassningar som har önskats osv. Så det kräver ibland och ganska ofta mer koordination än att vi på ganska små medel justerar saker och ting i den agila strukturen. Som sagt, återigen, en hel del av de större sakerna som sker inom ett område där man inte behöver så mycket hjälp över hela banken så rullar de här stora sakerna ändå.
Ni har ju programstyrning och projektportföljer och ni har regelverk som förändras. Det kan slå mot allt av det här. Hur lyckas ni hålla reda på att det inte finns en liten flaskhals längst borta som håller på med integration eller liknande och får den här balansen? Delvis jobbar vi med en del verktyg. Jag tänker inte gå in på dem i detalj för det är inte min hemmahand. Men en sak som är viktig är att jobba med både feaciability och doability.
Feaciability handlar väldigt mycket om att titta på initiativen. Är det läge att köra det här nu? Finns det förutsättningar? Vet vi vad vi ska göra? Sen har vi också väldigt mycket kring doability. Alltså där vi samlar in människor specifikt och då menar jag inte kvartalsvis som vi pratade om tidigare.
Utan specifikt för att titta på kan det här initiativet rulla? Vad är förutsättningarna inom de områden eller de arts, tribes eller till och med teams som ska bidra till det här? I några fall kanske man flaggar väldigt tydligt att nej det här är inte möjligt för nu jobbar vi med de här viktigare sakerna. Då blir det naturligtvis så att antingen får man titta på prioriteringen och då kanske det är en signal som går upp till högre nivå. för beslut eller så får man helt enkelt titta på sekvensieringen och säga att vi förstår, det där är viktigare.
Då gör vi om vår plan och ser hur det slår och sen kommunicerar vi och är tydliga med det. Men det finns inga genvägar kring det här, du måste fråga de som ska leverera, har ni tid och möjlighet? Då ska jag tillägga också att precis som många andra organisationer eller företag, vi har en del gemensamma plattformar där alla ofta ska in. sådana här saker som kunden kanske inte tänker på så mycket i det dagliga. Låt oss säga signerat avtal eller låt oss säga öppnat konto eller de här dagliga finansiella tjänsterna som man tar som självklart. Det kan ibland vara ganska omfattande saker att justera och förändra, enligt de önskemål och krav som finns.
Antingen från marknad, från kunder direkt eller från absolut regulatoriska krav. Det finns många sådana exempel. Om vi tar det exemplet som du hade där det kommer ett regelverk, det tillsätts någon typ av projekt och sen kommer ner till produktägaren som säger att du måste ändra det här, vem är det egentligen som styr det här? Är det projektledaren eller produktägaren, eller hur går det till? Det är ett samarbete naturligtvis. När det blir stora saker som slår väldigt brett då lägger vi oftast upp det i form av ett program.
Därför att vi vet att det gäller först att analysera vad vi får för effekter på organisation, IT-system, processer och allt annat. Och sen kommer vi generera ett antal mindre eller större projekt som behöver leverera olika delar. Allting handlar om hur stort det blir. När man väl kommer hela vägen ner är det så att banken själv behöver prioritera och tala om vad som är viktigast. Då har vi en lista på prioriterade områden, vi är tydliga med vad de innebär. Vilka saker som behöver ske.
Så när man gör sin planering till exempel PI-planering då är det vissa saker som med automatik går före annat. Sen är det en kombination. Bara för att du har ett viktigt projekt så är det naturligtvis en viktig leverans. Men det kan mycket väl vara så att du samtidigt av tekniska eller andra skäl måste uppgradera ett system som håller på och stänger kanske en licens som tar slut eller en version som behöver uppgraderas. Det handlar om att kombinera det här. Det gör man alltså i ett arbete där man tittar på hela paketet, vad är det just vi behöver jobba med under de närmaste tre månaderna eller det närmaste året.
Projektledare tillsammans med Chief Product of tillsammans med Chief Speed Masters tillsammans med produktägare och hela vägen ner i kedjan. Samarbete, det är det som gäller. Du får det att låta så enkelt. Det är så många företag som har utmaningar med. Det är jättekomplext och det är väldigt svårt. Men jag tror med en öppen dialog och en tydlighet och som jag nämnde tidigare, så länge vi talar samma språk så blir det enklare och det tror jag att vi har lyckats med ganska bra.
Det har lagts ner väldigt mycket kraft på det faktiskt. Har ni behövt omdefiniera roller eller mandat för vårt produktägarskap eller andra roller att förändra sen ni infört det här? Inte så mycket ur projektaspekten utan vi nyttjar de roller som finns inom banken. Men i den agila strukturen finns det tydliga rollbeskrivningar för vissa specifika roller. En del är virtuella eller agila roller. Det kanske är uppdrag man har förutom sin linjeroll.
Men deras ansvar och vad de ska göra på olika ställen det är väldigt tydligt definierat. det gör ju naturligtvis att kontexten, var är jag som Chief Product Onie till exempel? Jag kan ju vara ansvarig för ett område som bara har supporterande plattformar. Jag skulle kunna vara Chief Product One i ett område som bara jobbar med vissa produkter gentemot kund. Så det är lite olika beroenden mellan varandra men det är väldigt tydligt vilka roller som finns och vilka som ska samarbeta. Det försöker vi undvika och det är väl ett tips till de som börjar jobba med hybrid projektledning samtidigt som agil att hitta på en massa nya roller.
Ibland kan det vara enklare. Vi slänger ur oss någonting och så låter det bra. Men oftast är det så att det blir en motverkande effekt och då skapar det ytterligare en nivå eller förvirring vem det egentligen är som håller i det hela. Jag tror väldigt mycket på att använda de roller och de strukturer vi bestämt. Ni har ju en projektledare. Den, kan man säga, väljer om den går till product donal eller product doner eller till Epic owner för att påverka och få igenom sitt.
Det är rätt uppfattat? Ja, beror det lite på. på var man befinner sig. Men jag tror att samordning mellan större saker då behöver man nog prata med det vi kallar för Chief Product Over. Är det en detalj eller mindre justering då kan det ofta vara så att det hänskjuts ner till en product oner som antagligen ligger och jobbar närmare ett team som ansvarar för en viss del. Men du nämner Epic Owner. Jag tycker det är ganska intressant för det har vi sett också Epic Owner är ju personer som ska driva ett större satsning.
Det behöver inte vara projekt men väldigt tydligt driva lite större förändring inom ramen för den agila utvecklingsmodellen. Där har vi faktiskt jobbat en hel del och tittat på hur ska de få projektledarkunskap? Inte vara experter på projektledning men att förstå vissa delar som handlar om vad man behöver tänka på. Det här tycker jag har gett väldigt bra resultat och det är också något som är väldigt uppskattat för att många är duktiga från början. Men det kan också vara så att du är ansvarig för området och helt plötsligt ska du också ansvara för att driva något utvecklingsmässigt.
Då kan det bli lite utmanande. Jag tror att vi på alla nivåer behöver också stötta de som kliver in i sådana här roller eller tillfälliga uppdrag att driva eller organisera eller koordinera något. Och lite grann av det finns i projektstyrmodellen. Den tar upp och ger mycket support till den typen av personer som kanske har fått ett uppdrag att göra någonting. Att förstå hur man ska navigera. Plus naturligtvis att om det kommer in en ny projektledare till HS som absolut är duktig på projektledning men inte riktigt förstår: Hur tänker ni eller hur jobbar ni?
Så har vi också jobbat mycket i vår projektstyrmodell att tydliggöra de delarna så att man ska hitta lätt. Hitta lätt i hur man bör göra och inte minst hitta rätt kopplat till de andra regulatoriska krav vi har som styr hur våra interna processer behöver fungera. Till exempel risk, kvalitet, kostnadskontroll naturligtvis och så vidare. Den gamla TKC eller vad du nu vill, vilka bokstäver vi nu använder. Ser du några konflikter som finns kvar i det här mellan projektledare, PEO:er och så vidare eller känns det som att allting går att lösa bara man pratar med varandra?
Det finns säkert områden där man har utmaningar men jag skulle nog tro att Det finns ingenting i våra instruktioner, metoder eller modeller som skapar den typen av konflikt. Sen kan det naturligtvis finnas Det är ju människor som arbetar. Det måste man ha förståelse för. Man kan vara mer eller mindre stressad. Men jag tror att det uppstår nog inga större konflikter. Utan det handlar nog mer bara om att de enda konflikterna som kan uppstå är prioritering: Det här är viktigare eller det här är viktigare. och vem ska fatta det beslutet? överens på ett sätt som fungerar i den tid man har, eller kapacitet så får man naturligtvis eskalera det som vi kallar en våning upp.
Och då finns en struktur på plats för att göra det. Svaret på frågan är nej. Jag tror nog att det är ganska mänskligt ibland att vara oense när jag tror att man kan lösa det på många bra sätt. Finns det någon typ av hierarki mellan de här personerna som produktägare, projektledare, agilt kontra projekt och så vidare? Inte formellt. mellan projektledare och den agila strukturen. Inom den agila strukturen finns det en viss hierarki.
Men det finns ju ingenting egentligen som säger att en projektledare är över eller under någon annan i sammanhanget. Men tittar man på den agila strukturen, ja då finns det en hierarki. Tittar man, det är ju mer än en beslutshierarki kanske, och en planeringshierarki. Tittar man på projektstyrmodellen så kan man säga, ja, i och med ett program så kommer man ju ha projektledare eller strömledare eller vad man nu vill kalla under sig. Men hur de arbetar tror jag nog att man får nog vända sig tillbaka till att titta på sponsorer och styrgrupper och andra.
Det är där mandatet att påverka mandatet att tillsätta resurser, mandat att ta strategiska beslut som ligger på en hög nivå. Det är där det är viktigt att man har rätt människor. Men det finns ingen omedelbar att säga att ett projekt går alltid före någon annan. Så är det inte. Det mesta är viktigt. Hur säkrar ni förändringarna?
Vi jobbar ganska intensivt med vår portfölj och med det menar vi att vi säkrar alla typer av förändringar. Att de flaggas upp och diskuteras ur ett vad vi kallar för prioriteringsperspektiv för jag tror det är viktigt att påpeka att även om man kanske på andra företag ofta delar upp sig i IT, affär, operation osv. så är det hos oss på SEB i de så kallade agila domänerna som vi har kombinerat personerna eller rollerna och organisationerna som samverkar och levererar kopplat till portföljplaneringen. kapacitet vi har. För ur projektledarens aspekt så finns det sällan eller aldrig en separat organisation för projektet utöver en styrgrupp och möjligtvis projektledningen. Det är inte så att vi tar in väldigt massa människor i ett rum och så kör vi projekten inlåsta utan vi jobbar tillsammans med den levererande organisationen.
På SEB är det faktiskt så att för ganska stora delar av affärsutvecklingen så är det bara så att vi har en enda reell sådan organisation och det är domänerna Men sen görs det också en portföljplanering på högsta nivå som innebär att vissa större initiativ ses som mest prioriterade och har förtur. Och det här rör sig oftast om ganska stora transformationer som kräver prioriteringar i den planering som sker på alla nivåer. Och du nämnde det här med prioriteringar. Och då tänker jag att man kanske får skicka upp det i organisationen du har en styrgrupp med sponsor och i den här agila organisationen så har du en linjeorganisation.
Och de här möts antar jag någonstans. Det är det som vi hos oss kallar för domäner, domäns. Och även tripes det är den som är vår governance-struktur. Det är en struktur som bygger på att det kan vara lite olika. Det kan vara produktområden, det kan vara plattformar, det kan vara lite olika delar. Det är lite olika på olika håll i banken.
Det är en väldigt stor organisation. Men huvudsaken är att den ska innefatta tre roller. Det är en roll från technology eller IT. Det är en roll från business eller affären. Och det är en roll från våra operationer. alltså våra business services. Att de tre samordnar sig på en hög nivå governance-mässigt i det vi kallar för domänerna i domänledningen.
Sen har vi också på tribe en motsvarande nivå och underliggande dessa arts. Men man ska också komma ihåg att förutom att vi har en governant struktur i domänen så har vi också en väldigt omfattande portfolio management, alltså portföljhantering på flera nivåer. Det är både på gruppnivå där vi tittar på vad som är strategiskt viktigast just nu vår roll, inte gå in i detalj utan bara på en hög nivå. Går man ner på domännivå så kan man säga att inom vårt område så måste vi prioritera det här och det arbetet har vi också portfolio managers inom varje område som vi jobbar väldigt effektivt kring.
Och där kommer också projekten och satsningarna in, liksom alla andra delar. Till exempel system som behöver bytas ut. Life cycle management. Det kan vara operativa delar. Det kan vara alla andra saker som behöver göras. samordning, ja. Och hur hanterar ni leveransdatum om ni är mer praktiska?
Att projektledare tar på sig att jag ska leverera det här till 1 januari 2026 men är beroende av agilt team. Och de kanske har en annan prioritering rent praktiskt. Hur kan en projektledare lova någonting? Jag tror inte att en projektledares största ansvar och viktigaste uppgift är att lova saker. Men jag tror att en projektledares största och viktigaste uppgift är att koordinera, vara väldigt transparent med planer, planer, risker, de “issues” eller hinder som vi ser och i det innefattas också att inom vissa områden där man behöver viktiga leveranser så kan det finnas ett prioriteringsproblem.
Och det behöver man flagga upp till styrgrupp och andra som kan hjälpa till att se vad kan vi göra för att undanröja det här hindret? Sen finns det ju deadlines naturligtvis och det är någonting där styrgrupperna kommer in och sponsrar på ett väldigt viktigt uppgift att verkligen vara med i det här och förstå. Vi har en deadline som skulle kunna vara Vi vill ha någonting vid en viss tidpunkt. Det kan också vara att vi måste ha nånting vid en viss tidpunkt. Berätta mer om det traditionella jämfört med agilt. När vi jobbar i projekt så jobbar vi med en traditionell work breakdown structure och försöker jobba med strukturen och sekvenseringen här i ett network diagram eller vad man nu vill kalla det.
Men många av de här insatserna som vi kräver, arbetsinsatser eller leveranser. De utmynnar också i lite mer agila epics och features där man använder sig av Weightless Shorters Job First tänket som är den väldigt agila termen för det. Men det är fortfarande viktigt för våra projektledare att jobba tillsammans med de som sitter och jobbar agilt så att vi säkrar att prioriteringen som finns för projektets helhet, en kedja av insatser, att det ska leda till ett visst resultat. Och det innebär det att vikten, the weight i sammanhanget inkluderar den övergripande planen för det här projektet och inte bara vad vi gör precis just nu därför att det passar bäst. ett väldigt tydligt arbetssätt här för att vi ska kunna kombinera projektledningen enligt traditionella mått mätt med tänket i den agila strukturen.
Hur löser ni skillnaden i synsätt mellan agint, vi vet inte allt i förväg och projektsynen på budgets tids-scope att projektledaren vill att det agila teamet ska veta allting från början så att projektledaren kan lägga in det i sin plan. Vi har gjort så här att tid i form av resurser och timmar är nånting som man i den här gula strukturen egentligen inte jobbar med. Naturligtvis för vissa specifika områden eller specifika omständigheter. Men normalt sett är det så att vi flyttar arbeten till teamen och vi drar inte ihop 25 personer som låser in dem i ett rum och sedan tidrapporterar dem.
Utan tittar man på budget till exempel så är det så att det handlar väldigt mycket mer om kapacitet i allmänhet och naturligtvis hur mycket människor vi räknar med att vi behöver ha hjälp av i olika tillfällen. Så att, kostnad Det finns en väldigt tydlig kostnadskontroll, det är en back. Men den bygger mer på kostnader kring externa kostnader till exempel konsulter som man behöver plocka in det kan vara inköp av saker och annat som kostar utanför den redan existerande organisationen. Men en projektledares behov av att sätta en tydlig plan den kommer komma så långt ner där man har kunnat specificera kraven på en sådan tydlig nivå.
Vi har försökt gå lite grann från att istället för att lämna in en kravspecifikation på 150 sidor så är det väldigt mycket så att teamen eller kanske arten, våra artar har ett ansvar för att implementera de förändringar som behöver ske på bästa möjliga sätt givet det som de idag behöver underhålla. Då kan det vara så att ett krav är mer en beskrivning av vad vi vill uppnå eller vad är det för funktionalitet vi behöver. Inte specifikt hur ska vi lösa den tekniskt eller programmeringsmässigt? Vi kan jobba med en tidsaspekt och säga att vi behöver den här saken vid det tillfället.
Då blir det tyvärr så i den agila världen men också i verkligheten tror jag. Ju närmare man kommer desto mer eller mindre säkert blir det. Titta på väderprognoserna nu för sommaren. De har börjat jobba med procentuell sannolikhet i väderprognoserna. I alla fall när det gäller nederbörd. Jag gillar det.
Men det innebär att jag har egentligen ingen aning. om det kommer regna eller inte. Ju närmare man kommer desto tydligare blir det. Det är samma sak när man jobbar med projektledning. Definiera kraven, få in den agila strukturen. Vi kommer att bolla saker fram och tillbaka. Men återigen, projektstyrmodellmässigt så har vi sagt att innan du går in och börjar detaljplanera tillsammans med en massa andra människor och ta deras tid i anspråk för att göra detaljerade planer.
Då ska du ha väldigt tydligt för ditt projekt, vad är det vi ska göra? Vad är det vårt scope är? Vad har vi för ungefärlig tidplan? Sätter du den tidigt på en hög nivå, då kommer resten vara anpassningar. Sen, iterativt, då kommer det hända saker. Det kan ju teoretiskt vara så att en regulatoriskt krav kanske skjuts fram mot två år, ja då kanske det blir ett helt annat scope.
I projekt-styrmodellen har vi lagt in väldigt tydliga obligatoriska vad vi kallar för progress check, och den innefattar inte bara att kolla läget utan innefattar också att ta ett aktivt beslut: Ja vi går vidare. Titta tillbaka kanske på vårt business case. Titta tillbaka på vad var det vi tänkte, hur såg planen ut? Och det är någonting som du jobbar med iterativt. I vissa fall väldigt ofta, i andra fall kanske kvartalsvis kopplat till den agila P-planeringen. Vad lyckades vi få in i den här planeringen eller inte?
Och i vissa fall kanske långt tidigare, kanske över några år. Vi har en hel del stora initiativ och transformationer. som kommer jobba som program under många år framåt. Det är en löpande iterativ förändring av plan, scope allting. Det innebär också att sätta en budget exakt vad det kommer kosta när vi kör det. Det blir uppskattningar, det blir prognoser och på annat sätt en löpande iterativ förändring. Upplever du att ni har fått bättre prognossäkerhet eller sämre prognossäkerhet med den här modellen?
Det är nog väldigt svårt att säga. Bra svar på den frågan. Jag skulle säga att i vissa områden, ja där man har väldigt tydligt mandat och kontroll över sina resurser och det är ganska lite krossberoende. Man klarar de bitarna själv. Där tror jag att man har blivit bra på att göra en väldigt tydlig plan. Sen jobbar man mycket inom den agila strukturen och via våra agila coacher och uppföljning av olika typer av system där man tittar på traditionella agila termer som productability.
Hur lång tid tar saker och ting för att rulla igenom ett flöde. Hur mycket levereras. vi och så vidare och hittar olika modeller för att mäta det här. Inte för att vi på en central nivå talar om huruvida vi är bra eller dåliga utan för att lära oss någonting lokalt. Det gör att projektledare till exempel som ger sig in i ett område eller behöver få hjälp från ett område teoretiskt sett där predictability är väldigt låg. Ni har inte lyckats leverera mer än 10% av det ni planerade då innebär det för mig som projektledare att precis som SMHI då kanske jag jag ska förvänta mig att det är lite mer osäkert.
Och på andra områden skulle jag nog säga att här är det ganska säkert, vi är överens och det är inte vi har tydlighet, vi är överens, det kommer att levereras. Anpassning, ha koll på de saker som behöver göras och sedan jobba med sannolikhet och transparens. Var tydliga med hur det ser ut, var tydliga med hur vi ligger till, var tydliga med de hinder som finns och hur vi ska försöka hindra dem. Vad har ni lärt er om styrningen i det här gränslandet mellan projekt och agils? som du tycker att fler borde känna till när de går in i det här? Till att börja med är det svårt, det tar tid.
Men det handlar om att samverka mellan väldigt många olika delar av banken. Vi har haft under en lång tid det som vi kallar för adgialt SEB som är ett program med rullande gruppering under vår Group CIO där man har jobbat väldigt mycket med utbildningar, när man har jobbat mycket med metoder, processer och på samma sida där vi har jobbat med projekt så har vi också jobbat med motsvarande information Och sen synkar vi det tillsammans. Det är också kopplat till vår finansiella struktur, det jag nämnde är en agil struktur. Det handlar om att det är möjligt att följa den virtuella strukturen också.
Hur den ser ut och vad den kostar osv. Allting rullar ju tillbaka. Nu är jag ingen finansperson men allting rullar ju tillbaka, det är pengar in och pengar ut för alla verksamheter. Det innebär att det gäller att ha kontroll. Men finanser, planering ramverk, samarbete även på de funktioner och processer som stöttar de som faktiskt gör jobbet. Det är liksom A och O.
Men det är jobbigt det tar tid. Det var någon som sa en gång att det var som att flytta en oljetank med en liten bogserbåt. Det tar tid att vända skeppet. Jag tycker nog att SCB har lyckats väldigt bra. Vi har ett väldigt stort skepp som vi har lyckats vända på ett bra sätt. Det är möjligt att många tycker att vi har vänt för långt eller för kort.
Men det finns saker vi har gjort rätt och gjort fel med. Men jag skulle nog säga att man får nog vara beredd på att det är en slingrig väg. Det kräver insatser och det är ingenting man gör bara genom att bestämma sig någonstans. Man måste också genomföra det och det är en utmaning och det tror jag alla organisationer ser. Är det någonting du ser är nära framtid som ni ska justera? Inte omedelbart tror jag.
Det sker ju alltid organisationsförändringar i stora organisationer men det är ingenting som jag tycker slår så svårt eller hårt på på våra projekt eller liknande styrmodeller. Vi har börjat lägga väldigt mycket mer fokus på att väldigt tidigt bedöma saker och ting gemensamt. Är det här möjligt givet alla andra stora saker som sker? Det tycker jag är väldigt viktigt arbete med många samverkande parter. Och kanske ibland förmågan att våga säga nej precis som att våga säga ja. Nej, vi gör inte det därför att, men ta fram mycket mer fakta kring besluten som man behöver fatta.
Och i projektstyrmodellen så har vi inte jobbat så mycket med: Använd den här mallen eller det här dokumentet eller den här Powerpointen eller Excelen. Vi har jobbat mycket mer med det här. Beslut som behöver vara förankrade, det här är beslut som behöver tydliggöras, det här är beslut som behöver dokumenteras. Mycket mer fokus på det än att säga att ni ska använda en viss mall eller någon annan dokumentationsform. Sen naturligtvis är det bra om alla använder liknande och det har vi lagt upp väldigt mycket förslag på men vi vet att beroende på kontext och beroende på komplexitet så krävs det lite olika men grunderna ska finnas där.
Well informed decision tror jag någon kallade det och det är det som är A och O. Och det gäller på alla nivåer. Varför har vi fattat ett visst beslut? Det tror jag är den viktigaste delen som jag ser framför mig att vi jobbar ännu hårdare och ännu tydligare hela vägen från en utvecklare som ser en utmaning med någonting upp till högsta ledningen som på en hög nivå förstår var vi behöver säga ja eller nej. Det är en stödjande modell med väldigt lite krav som du säger men vi måste väl ha några krav som får projektledarna och andra att följa det här.
Någonting är väl obligatoriskt ändå, eller? Absolut, det finns det. Det vi har sagt är att vissa punkter är obligatoriska för projektledare eller sponsorer och styrgrupp. Men vi har valt att inte säga att just det här forumet formatet är viktigt eller måste användas. Ett sånt viktig punkt är att när du fattar ett beslut och startar projekt då är det vissa förutsättningar som ska finnas på plats. Business case, varför vi gör det.
Det finns mängder olika sådana attribut. Exakt format för dom har vi sagt att det är inte så viktigt men informationen ska finnas där. Vi har sagt att det är obligatoriskt att fatta formella beslut i styrgruppen när vi lämnar eller går in i planeringsfasen, Därför att det är där vi börjar engagera väldigt många människor på många fronter för att kunna få ihop en detaljerad plan och doabilitys eller försöka se om vi kan göra saker och ting och planera in det. Det är också viktigt att fatta ett formellt beslut om nu går vi in i exekvering på den här delen, eller hela delen.
Och sen löpande att man gör en progress check som också innefattar att man går tillbaka och tittar på vissa artefakter. business case, business impact analys och allt sånt som är bra material att ta fram. Och naturligtvis en väldigt viktig del för projektledaren att man fattar ett beslut att nu ska vi stänga projektet. Vi är färdiga. Det här har tagits över, inte lämnats över. Jag brukar använda tagits över av vår agerande verksamhet eller vår linje. Och göra en väldigt tydlig avlämning när det gäller effekter t ex.
Vi har gjort 10 leveranser. Vad skulle de leda till? Det leda till en besparing eller kanske leda till högre vinst eller nåt annat, högre intäkter kan vara vad som helst eller att vi blir compliant med ett regulatoriskt krav. Jag blandar lite svenska och engelska så man blir ju lite hemmablind. Det är beslut som är väldigt viktiga och där har vi också tagit upp exempel på och mallar för hur man ska göra en closure report alltså en projektanslutningsrapport och vad ska den innehålla? För det är ju väldigt ofta så att projekt levererar en massa viktiga saker men effekterna kommer ganska långt senare.
Det har vi också. väldigt tydliga med och också då kopplat ihop det här med vår controller community. Alltså de finansiella controller så att de ska faktiskt kunna ha koll på det här även lång tid efter att projektet i sig har rullat ihop och försvunnit och projektledaren har lämnat rummet så att säga. Så det är de delar som är obligatoriska. Och det är inget konstigt, men jag tror att man ofta eller för ofta fokuserar på exakt format. Det här dokumentet, mallen, den här PowerPoint-presentationen presentationen: den här excelfilen. Jag tror att det är viktigare att fokusera på att man faktiskt gör rätt saker på rätt sätt utan att fastna så mycket i format.
Men, vi har väldigt mycket goda exempel och goda mallar man kan använda om man vill. Som vad vi kallar för inspirationsmaterial. Är det något vi inte har pratat om som du hade trott att vi skulle prata om i dag? Jag har pratat mycket om vår projektstyrmodell inom banken och så har vi presenterat den och så vidare, eftersom vi faktiskt gjorde en ganska stor uppdatering här tidigt i våras. Vi har jobbat väldigt länge men tidigt i våras släppte vi och formellt sett inom banken. Det är kopplat till en del instruktioner.
Den sista punkten jag brukar säga till projektledare som man inte får glömma är att fira. Det är viktigt att fira framgångar på samma sätt som vi kan tycka är jobbigt och misslyckas. Men jag tycker vi är lite dåliga på att fira när vi gör bra saker. Och det tycker jag man ska ta med sig i alla projekt hela tiden. Det är roligt. Jättebra.
Jag gillar inte riktigt ordet misstag tycker jag om, för det kan man lära sig av. Har du gjort några projektmisstag som du kan dela med dig av som någon annan kan lära sig av? Ja, det kanske andra borde bedöma egentligen. Nu har jag inte jobbat som projektledare de senaste åren men jag tror att det största misstaget jag har gjort någon gång och då vill jag citera en kollega, en engelsman på ett projekt när jag frågade honom berättade han om samma sak, vad var det för misstag tag det gjorde i projektet. Och då sa han så här, I should have taken longer walks.
Och med det menade han skapa utrymme för att tänka. Jag tror att det är jätteviktigt. Och det enda misslyckandet jag kanske själv någon gång har gjort det är att jag inte bevakat Scope tillräckligt bra. Saker har fått växa okontrollerat och då blir det till slut övermäktigt. Och då, om man tar på sig kanske för mycket ansvar själv. Jag tror det är väldigt viktigt att förstå att det här är ett delat ansvar mellan dig som projektledare, din sponsor, och din styrgrupp.
Så var transparent, fira mycket och take longer walks. Jättebra! Och om man vill komma i kontakt med dig hur gör man då? Jag finns naturligtvis på LinkedIn även om jag kanske inte är så där hyperaktiv. Annars så är det inte så svårt att gissa min mejladress. Den tänker jag inte säga.
Men jag jobbar på SEB så det går att gissa sig till den också. Vi försöker också som projektledare och inom ramen för det vi gör att samverka i olika typer av nätverk. Så det är säkert Det är så att jag springer på en och annan någon gång. Så ni vet var det finns, var jag finns. B: Jättebra det också. Jag har fått nöjet att titta igenom den här modellen och jag tycker verkligen att det är riktigt bra.
Ni är någonting riktigt bra på spåren med att få ihop det här. Ni har gjort en enkelhet och det här är bara min personliga syn. Ni har tagit bort mycket fluff fluff och ni har haft, precis som du säger, att det är en frivillighet att använda men en möjlighet och följa. Och det finns några få obligatoriska och de obligatoriska sakerna är väldigt viktiga. själva formen på hur man levererar det är inte lika viktigt. Det här gillar jag. Det får…man fokuserar på det som är viktigt i ett projekt, helt enligt min syn.
Så därför var det kul att du idag, Anders Miller från Banken SEB, så givmilt har berättat om det här och delar med dig av era erfarenheter. Stort tack för att du var med i Projektledarpodden idag. Tack ska du ha. för att du har lyssnat på Projektledarpodden? Hör gärna av dig till oss med idéer, tips och förbättringsförslag. Det gör du enklast via mejl på lyssnare@Projektledarpodden.se eller via det sociala nätverk du föredrar.