Transkribering: Rolling Wave Planning och praktiska erfarenheter att driva projekt i en föränderlig miljö, Benny Nietsche berättar. (avsnitt 49)

Detta är en maskinell transkribering (KB-Whisper) av avsnittet som publicerades 2024-04-04. Fel kan förekomma.

Lyssna på avsnittet: 49: Rolling Wave Planning och praktiska erfarenheter att driva projekt i en föränderlig miljö, Benny Nietsche berättar. Läs sammanfattningen: Rolling Wave Planning – Benny Nietzsches praktiska guide för osäkra projekt (49)

Transkribering

Under promise and over deliver. Det är liksom vad vi projektledare måste göra. Den som pratar är Benenitje. Han kommer i dagens avsnitt prata om hur man planerar ett projekt och framför allt hur han använder rolling wave planning. Detta avsnitt är sponsrat av flyttenkelt.se. Vill du flyttenkelt så gå in på flyttenkelt.se för att få råd och tips och offerter.

Tack flyttenkelt för att ni sponsrar dagens avsnitt. Och jag som har podden. Jag heter Mattias Ejbe och nu kör vi. Du vill lyssna på Projektledarpodden. En podd för dig som gillar att leda projekt- och vill lära dig mer av andra om projektledare. Idag ska vi prata om planeringsteknik.

Det här ligger mig varmt om hjärtat. Jag har funderat mycket på det här och känner att jag aldrig blir riktigt bra på det. Förgivetvis planerar man långt fram som projektledare- och det blir inte riktigt som man har tänkt och då försöker man planera lite finare och så ändrar man det här. Det finns givetvis tekniker för det här. Och Benny, han tog kontakt med mig och vi pratade lite grann om det här så nu gör vi en podd om det. Så välkommen till podden, Benny Nietzsche.

Tack så mycket. Du kan väl berätta lite om din bakgrund och hur du kom in på det här. Jag försöker göra en lång historia kort. 80-talet, småföretagare, jag flyttade till USA på 90-talet för att plugga. I slutet av 90-talet hamnade jag på ett amerikanskt bolag som hette American Management Systems. Som Kravoanalytiker och Applärdesign inom telekombildning.

Där började det lilla frötsåskring. Projekthantering, projektplanering och jag har graviterat mot projektledningen helt enkelt från den tiden. Jag tror att jag blev av mig själv som projektledare förrän 2004-2005. börja känna vad det här här. Nu kan jag det här. Nu är det lite märkligt att jag är personlighet för det här. Det är lite så.

Planering i sig är ju jättespännande och du och jag kontaktar ju dig tack vare att jag känner att men varför pratar du folk om rolling och planning som jag har upptäckt som fungerar så jäkla bra. Och jag har ju googlat och jag använder chattyp i att jag ser jättemånga referenser till olika Men i verkligheten känns det som att inte så många använder det. Vad säger du, Mattias? Var åker jag kring det hela? När jag jobbade på bygge, då jobbade vi på det sättet. Det var…

Än fast vi inte kallade det det. Vi hade en ett och ett halvt eller tvåårig plan. Och sen så tittade vi tre månader framåt. Vi tittade en månad framåt. Vi tittade två veckor framåt. Och vi tittade en vecka framåt.

Och sen hade vi även dagtittning. Alla de olika dimensionerna jobbade vi med hela tiden. Sen var det olika personer. Det var lagbasen som jobbade en dag, det var arbetsledaren som jobbade en vecka. Det var… Arbetsledaren tittade även då en månad eller tre månader framåt tillsammans med projektledaren.

Och sen var det projektledaren som hade helheten i totalt två år. Lite så. Men som sagt, jag kan inte det här. Det ska bli jättekul att prata med dig om det här. Jag vill inte slå på stora trömmen och säga att jag kan det här. Jag kan bara berätta min erfarenhet kring det här.

För när man läser de andras erfarenheter kring Rollaway Plan så gör de en massa utfästelser om vad det är och inte är. Ibland så håller jag inte med vad de säger. En del säger att det är bara för stora projekt. En del säger att det är bara för små projekt. Och det är bara för agila projekt. Men jag håller inte med om det.

Jag tror det här passar den flesta projekten. Och hur jag halkat in på det här i stort sett är att jag jobbat på Tele2 som projektledare och insåg Hur den här hanteringen av projektplanering och sen små agila team som har egna agendor och egna tidplaneringssätt. Och jag såg ju det här en polarisering mellan vattenfall och agilt och jag kände att hur kan man då, hur kan man liksom komma över det här sättet och se på det hela. Och egentligen är det konceptet end in mind har verkligen blivit trummat in mig som projektledare av gråhårigare gubbar än mig.

Det är just det här att end in mind skapa ett fokus, att skapa en vision av vart vi vill vara. Det är det här intressanta i Kroksvägen. Oftast när man har ett stort, komplextprojekt ser man bara det man har framför sig idag. Det här går aldrig. Man blir som Örebroare. Här kommer vi inte fixa.

Det går inte. Och skapar man en vision om vad man vill vara om ett år eller två år. Då kan man ju ta det som är end in mind och sen ska man titta på vad är det första steg vi kan ta för att nå dit. Och det är det här som jag känner, rolling wave planning, det är precis vad det här handlar om. Det är att kunna ta de första enkla stegen och sedan kunna planera för hur vi ska möta visionen. Och vi vet ju Mattias att visionen ändrar sig ofta.

Okej. Jag har många projekt, jag kan inte dra exempel på kring det, men vi kommer till det förmodligen sen då. Och sen så frågar du mig när vi pratar hur skiljer det här sig från andra metoder? Alltså det skiljer sig inte, utan det här känner jag är som en add on till en befintlig här critical path och man ju brainstorming, man gör VBS och man gör worst, mid, best case. Allt det där hänger ihop med att det jag vill kalla det här för mer eller eller mindre. Det tror jag jag apar efter lite gärna Thomas Gustafsson tankar i handbok Agile projektlinjer från 2011.

Jag läste den första upplagaren när jag kom in på det här och det att man skapat initialt ett kunskaps skikt där man kan säga första skiktet. Det här vet vi detaljer på det andra är exempelvis. Vi har en hög nivå design på ett ungefär. Den tredje är att vi förstår vad det är och den tjärde nivån kan vara att det här är rubrik. Så de kunskapsskikten jobbar man med. Det gäller att få in den förståelsen hos beställaren, den som äger effektmålen.

För knyter man ihop visionen med effektmålen på det sättet kan man få en acceptans på det här arbetssättet som jag trodde aldrig skulle kunna få. Vad är rolling-way planning? Det är för mig en metod, en teknik till befintliga metoder, för att hantera osäkerhet i planeringen för att enklare kunna hantera förändringar när de inträffar. Utan att man behöver då spendera massa tid och att swagga och spekulera och göra massa utfästelser som inte kommer att funka. Så att vi har alla val att skriva change requests. Det gör vi inte i det här sättet att arbeta.

Utan man hanterar det här som en naturlig del av projektet, en förändring. Det tillåter det. Det skapar en väg för att slippa det här. Det här är ett tidsödande change request hanteringen som du känner till också antar jag. Vi ska gå in i detaljer. Hur du jobbar med det här.

Men om du på 30 sekunder ska beskriva hur du gör det här och sen dyker vi ner i ett exempel. Vad är det här? Hur jobbar man med det? Alltså hur man jobbar. Jag kan bara prata om hur jag jobbar med det här. Hur jag har jobbat med det här.

Och hur involverar man teammedlemmar i en planeringsprocess. Vi har alla våra egna tekniker. Vi har alla våra personligheter. Hur man då entusiasmerar människor. Och det här är ingen skillnad. Det här är ingen annorlunda metod.

Utan vad det handlar om är att kunna i stort sett göra den här end in mind resan. och förstå visionen, förstå effektmålen och krympa avståndet mellan utvecklare och effektmål. Som ofta man vill dra isär, nej, de är bara utvecklare. Det är det essensen är i det här tycker jag med rolling wave planning för att man får en gemensamhet. Initiala roadmap man skapar är verktyg och totempålen som alla samlas runt. När en effektmålägare säger att de har ändrat där borta, då kodar de och säger att de behöver ändra här nere också. Det blir en naturlig form för hur vi interagerar över tid.

Eftersom man kontinuerligen planerar. Man planerar inte bara först och sen springer man ut och gör saker. Man planerar medvetet kontinuerligt nya vågor, nya exekveringar, insikter från en exekvering. Det här var ju inget bra för det går i stick i stället mot det vi har planerat tidigare. Hur kan vi lösa det? Och det går in i nästa iterationsplanering.

För det är ju Scrum som jag har jobbat med till stor del. Och sen har det faktiskt Scrum gått in i Kanban. När vi väl har gjort den första MVP, en release till marknaden. Plötsligt så går man in i ett annat stadium. Där man inte behöver ha de här hårda releaser. Man kan gå in och göra en förbättring och förändring och deploya det.

Om man inte har gått ut till general populace, alltså stora marknader, då man har såna här friendly users i fokusgrupper, så kan man där få hjälp av andra förändringar också. Det tillåter ett så otroligt dynamiskt sätt att arbeta. Det viktigaste är att få med de effektmålvägarna på det här. Det har varit i mitt perspektiv ett av de största jobben som projektledare Att skapa det här ledarskapet, det krävs ett starkt ledarskap för att få det att funka. Skulle du kunna beskriva ett exempel om hur du använder det, kanske ett verkligt exempel, och så går vi igenom det.

Ja, det var ju så. Jag har ju pratat med en av effektmålseägarna så jag får prata om det här projektet på Telia. Och det här startade projektet. startade då inom Telemobile och det Telemobile projektet är det Mobile Office som skulle ersätta en mobiltjänst. Mitt i det hela så omorganiserade det hela sig. Slugg upp Mobile med bredband och var till Sverige fick helt nya effektmål. Vi fick helt nya erbjudanden beskrivna och jobba med.

I stort sett vad vi gjorde var att vi satt ner en månad med kärnteamet och gjorde den här resan med beroendeplanering. Worst case, best case gjorde VBS. Gjorde den här skickning av vad vi vet. Kunskaps skickningen och sen så kommer den här stora slägga ner. Nu ska vi ha en helt ny organisation att jobba med och det här ska heta touchpoint och inte mobile office. Och vi hade ju när Totem Polen och gått till.

Vi bara målar om Totem Polen och skrev och touchpoint. För resten var ju precis exakt. Vi kunde anpassa oss efter den framtiden. Vi hade ungefär fyra olika varianter av erbjudande spes under löpet av hela projektet. Vilket vi inte kunde ha haft på det här smidiga sättet. Som vi hade då.

Tack för att alla i teamet förstod vad rolling wheel planning handlar om. Det här planeringstekniken. Hur förklarar du det för dem vid första mötet? Det är just det här med kunskaps skikten. Det här med att kunna slippa skriva tjej som kvälls. Att vi kommer kunna jobba nära med CX och ju ex så i produktutveckling perspektivet.

Ett annat tips som jag vill lägga in i det här är att låta sex ju ex interagera oerhört mycket med med effekt måldrägarna med de som beställer det projektet eller vill ha den här tjänsten. För då låter de vara de i fred att leda projektet, leda teamet. Istället för att de ska komma in och säga, vad handlar det där om? Vad var det där för någonting? Då får de etablera sin vision. Gör refinement av visionen, gör den tydligare, klarare.

Med insikter från kunder och från fokusgrupper. Som CXUX handlar om då. Så det var på det sättet jag kände. Jag fick ett buy in från core-teamet jag jobbade med. Och även då teamledarna i leveranstimen. De förstod att det här är lite genomtänkt nu.

Nu kan vi faktiskt ta kreativa beslut om att vi provar det här i stället i den här sprinten. Får vi se om det funkar på det sättet. Rent praktiskt. Hur gjorde ni det här? Om jag säger så här under den här fotboll campstyle mötena vi hade uppe i Sundsvall i en månads tid så gick vi igenom den initiala erbjudande spesen och bröt ner de delarna till utvecklingsbara delar. För att vi hade då dels en säljprocess som skulle uppdateras i en befintlig läge i sin miljö.

Så vi gjorde den gapanalysen och satte det på vår skopelista i vår VBS. Samma sak då så insåg vi att nätverksdelarna här behövde uppdateras. Och då såg vi att en IN-plattform skulle byttas ut. Vilket är ganska enkelt för det här gänget. Så det satt vi som första milestoneen. så hade vi tid att titta på Milestone 2, vilket var att man gick som onda andar mellan ja, vi behöver nya appar, vi kan ta de här apparna som finns i Telepo. Man gick fram och tillbaka, man kunde inte bestämma sig.

Så jag sa att vi fick tillfälle till att säga, okej, nu går vi in och gör en prototyp på nya appar som bygger på att lägga sig i apparna eller apparna från Telepo. Vi presenterade efter tre veckor en fungerande app för själva slutanvändaren och fick ett godkännande av det. Det hade aldrig varit möjligt om vi hade jobbat i något annat format. Men jag springer iväg lite fort. Går vi tillbaka och tittar på hur vi skapar samsynen och att gå igenom lösningslandskapen. Vad är det oerhört viktigt?

Vi tittar på nätverk, vad är det för gap där, vad är det för gap, vad är det för telep på plattformen, vad har den för förmågor, inte förmågor. Och sen la vi upp ett antal förslag på hur vi skulle kunna implementera det här. Och det jag ofta gör i projekt är att också sätta mig ner och göra en gemensam riskanalys. Jag vet inte om den är unik, men riskanalysen blir alltid en action item-lista för mig. som folk får äga i projektet. Vi kollar av dem varje dag, varje vecka och ser är den fortfarande grön? Har den blivit gul?

Och märk väl, jag vet inte hur många som håller med, men det finns inga röda risker för mig. För de är issues. Och de ska ut ur risklistan och ska direkt hanteras. Och det är det här som också varit en framgångsfaktor när man tittar på de bronar man har och vilka risker som finns. Så att när vi satt ner efter det i månaden kan man ju säga att då såg vi att det här är… Easy, lågdhängande frukt.

Det här vet vi inte speciellt mycket om. Och det gjorde jag medbete för de andra skulle förstå att okej, det är de här kunskapsskikten vi kan jobba med. Och sen när jag fick dem att förstå kunskapsskikten och ville öppna mig milstolpar så gick jag direkt till styrgruppen. Kloka människor i styrgruppen som förstod att aha, det är så här vi ska försöka göra det. Så när ni har gjort det här, då gissar jag att TLS-ledning kommer säkert säga till er. Men hur lång tid kommer det här ta då?

Ja, absolut. Då får man anmända sig av den klassiska metoden– –som att titta på best case, worst case– –och vara mest anordnika, att saker kan hållas. Den här analysen som jag har gjort med det här teamet var att… Det var det mest kunniga teamet i det området som jag fick jobba med. Det förtroende kapitalet gick in och sa att vi ser på det vi vet idag och på all helst om det kunskapsskiktet vi vet minst om så tror vi med en marginal på 90% att så här lång tid tar det. När vi satt oss ner i mötet, när jag satt mig ner med mötet och min projektägare också för den delen från IT, PPH, så var det lite integration men det var lite förbannat att det skulle ta så lång tid.

För de själva har ju byggt det här på åtta månader, sa de då. Det visade sig att de hade byggt en plattform för en kund. En instans, en kund. Vi skulle bygga en instans för hur många kunder som helst. Och då förstod inte de att det är det här. Vi måste bygga upp ett otroligt flöde för sälj och order och leverans av det här.

Jag fick ett buy in från styrgruppen men styrgruppen sa att vi måste prata med ledningen. Så midsommarafton det här sommaren satt jag i en bil på väg in på en fest. Och pratade med vdn på Telia om varför det skulle ta 11 månader och inte 8 månader. Och mycket intressanta möten hade jag där. Och bland annat frågade de hur vi kan hjälpa till vid ledningen med det här. Det är att inte ha sådana här möten för det stör oss i planeringen.

Min projektledare satt nästan hjärtat i halsgropen om han hade ett migsejande. Men vi fick lugn och ro efter det. Man får hela tiden försöka ha någon slags finger topp känsla. Det var många som inte ville ha mig kvar som projektledare efter det här. Men de insåg att vi har kommit så pass långt och det här verkar ju funka. Så det gäller att ha lite fingerspitskefyl och att kunna veta när ska man sätta ner foten.

Visa ledarskap och förtroende för sitt eget team och det man har gjort. Det är en sak att ni kan hantera det som teamen kan göra, men ni har ju ordentligt med beroenden i en sån här organisation. Det är säkert integration, det är säkert andra agila team och säkert saker som ni inte ens känner till som ni har beroenden till. Hur hanterar ni det här? Vår designledare i projektet och tillsammans med min tekniska projektledare, vi tre satt oss ner och tittade på vad det är för tydliga beroende vi hade. Vi behöver sätta oss ner och design möta med specifikt både hög nivå och låg nivå möten.

Och titta även på de processer som påverkas. Mycket av supportprocesserna var tvungna att ändras på. Vi var till och med nere i Bergströmmet i Karlstad där, i det här övervakningscentret, och gick igenom vad det för skillnad det gav mellan dagen och framtiden när vi har implementerat den här lösningen. Så det var fysiska besök, fysiska möten. På den tiden var det inte alls Teams utan Skype, jag har använt det så att du av. Och ha de här mötena och planera det långt i förväg i ett schema.

Det är lite av framgångsfaktorerna. Och bjuda in till sådana här standouts. Både hos utvecklarna, de som testar och de som sitter och designar. Och ha regelbundamöten på det här sättet. Det är det jag förmodligen fick det här att fortsätta rulla på. Kan du beskriva lite grann om hur ni jobbar med milstolpeplan, sprintplan och sen det här med rolling wave planning?

Jag ska försöka beskriva det. Om ni tänker framför er en graf där vi har en inceptionfas, vi har en planeringsfas, vi har milstolpexecutionfas. Sen tänker du tre sådana milstolpar med föregående planeringsvågor. så kan man säga att man utgår hela tiden från inception. Och sen så ser man då, vad har vi planerat för att vara startade med? Och då så går man in och förfinar den leveransen. Man startar utvecklingen innan man är klar med planeringen givetvis.

För det finns saker som inträffar. Man försöker få in en cadence i det här så att man får en rytm i arbetet. Så att vi hade fyra sprintar på en milstolpe. På det sättet fick vi fram en tydlighet att en utveckling i andra sprinter, vad vi kanske tog med att parkera finns och det här kan vi inte lösa förrän nästa milstolpe. Vad kan vi då plocka in för för för features eller för för funktioner att förbättra och göra så att vi kan få en fungerande milestone. Det är jätteviktigt att man i alla fall i de projekter jag har jobbat med att man har den första milstolpen ska lansera någonting användbart.

Som som en kund kan använda eller en fokusgrupp kan använda. Det är det viktigaste för att det är inte förrän så då du verkligen kan kan börja få ett förtroende hos dina leverantörer och hos dina stakeholder så att det här är någonting som vi nu. Det här är verklighet. Det behöver man visa så fort som möjligt. Show en till är bland det viktigaste att försteg försteg visa bestyget att jag har sprintet. Nu har vi de här featurena funktioner på plats.

Sprint 2 kommer de här funktionerna på plats. Och de andra tre, två sprintarna kommer vi faktiskt kunna göra allt det vi har tänkt att kunna göra. Så att kommunicera, show and tell har varit superviktigt för att bygga upp de här vågorna utav arbete. En annan viktig sak är att planeringsvågorna är ju pågående under hela projektet. viktigt att poängtera för annars gör man inte det då tappar man nerven i projektet. Över tid så flyttas vad du fokuserar på, var är ni jobbar med detaljerna? Hur jobbar ni med det?

Är det sprintarna som har den kadensen som gör att ni nu är det dags att titta där? Om man säger så här eftersom vi har lagt upp VBS och Kombinationen av VBS, kadensen och kunskapsskiktningen, de tre aspekterna tillsammans, arbetar kontinuerligen. VBS bygger man upp baserat på att först måste vi bygga det här, för annars kommer vi inte kunna göra saker i efterföljande iterationer. Därför är det viktigt att man har fungerande etablerad plan för första milstolpen. Så som det funkar då är att du tittar på första milstolpen, gör en detaljerad plan för den.

Sen när du kommit en bit in där, då börjar du göra en detaljerad plan för den andra milstolpen. Är det lite så förenklat så vi skulle kunna säga att du jobbar? Ja, förenklat absolut på det sättet. Men jag vill ju också kunna säga så här, inför varje sprint har du samma planeringshorisont som du har för en milestone. Så att du går in och kanske inte vet allt i första sprinten. Men ju mer du arbetar igenom så vet du vad första sprinten hur den ska utforma sig.

Och du har ju kontinuerlig kontroll på vad är det för någonting i alla morgning standups. Det är alla då som ska leverera till den sprinten är med och ser det här kommer jag hålla det här kommer jag inte att hålla. Det gäller ju då att kunna göra kommittments på att De dina team leads i utvecklingsteamer kan göra commitment som de kan lita på själva och att jag kan lita på att det är korrekt att de gör det så att det krävs en viss senioritet hos utvecklings ledarna för att kunna veta allt allt blir så. Allt blir så specifikt till det svårt att generalisera.

Det här gör man först. Här gör man sedan att man får titta specifikt på hur CWB ser ut. Vad är uppdraget vi ska lösa? Mappare mot visioner. Det är hela tiden man kontrollerar. Om vi skulle utbygga milstolpen 1 i det här projektet, det är Touchpoint, var en enkel integrationslösning som skulle uppdateras.

Boom. Så den då vart ju bortanför, den första milstolpen i vår projektplan men i vår rolling wave planering så sköt vi den åt sidan. För det var en done deal redan. För den var klar. Då behövde vi inte använda den först när vi lanserade. Vi lyckades hantera den första milstoppet på det sättet.

Milstoppet 2 var den vi skulle gå ut och göra en lansering med. Då var det ett antal appar som skulle på plats. Mobilappar för både Android och iPhone. Och webbappar, en softphone skulle ut. Och sen konfigurerade vi upp. den här touchpoint plattformen med de produkt komponenterna vi hade köpt och då skulle konfigurera dem. Och sedan uppe på det hela så skulle det här in då i en produktionsmiljö i en acceptans testmiljö i en utvecklingsmiljö och en testmiljö.

En en sån här playground för för för timen då det här skulle också byggas. Så det gjorde vi under Malstom 2 och vissa delar var ju två skjutat i Malstom 3 För att okej, vi kanske inte behöver ha en acceptans-testmiljö på en gång. Vi kör produktionsmiljön som en acceptans i början med. Och så vidare. Sådana insikter kommer ju då baserat på karaktäristiken på projektet och vad du befinner dig. Medvet i kunskapsskiktet, om man säger så.

Det är svårt att generalisera och säga att så här brukar det vara. Det brukar kanske inte vara så för andra. Och vilka verktyg använder ni för att göra det här? Allt från kanbandtavla till MS-project? Alltså det jag har gjort och det jag är trygg med att använda det är vad kunden använder. Och det har varit allt från MS Project.

I mitt senaste uppdrag så var allting MS Project. Och sen så använde Jira eller DevOps från Azure. Confluence. Det är viktigt att alla i projektet och även då styrgruppen access till de här sidorna vi jobbar med och de här tavlarna vi jobbar med. Så man kan få en real time upplevelse av det som jag sa och har sagt tidigare i många många situationer att när när utvecklarna är nära effektmålen och när man kan se att en effektmål ägare sätts och pratar med en testare och de pratar om hur det ska funka. Det är liksom det.

Jag får gås utan att tänka på det för det är så fantastiskt. Då vet man då man på rätt väg. Man får engagemanget på rätt väg så att de här verktygen är superviktiga för att Enabla just den här delen. Vad uppdaterar du och uppdatera timen gällande planering? Alltså jag uppdaterar ingenting. Jag samlar informationen som de uppdaterat i verktygen vi har utsett till till de nyckelverktygen förlåtelse är ett utvecklingstid.

Test team och sedan så tar den informationen och presenterar den på en vecka-basis eller om det är två veckors basis, beroende på vad styrgruppen vill. Eller så har i många fall också sagt att om vi går in och tittar på den här vården i Gira så ser ni vad väg är den här milestoneen, den här sprinten. Och det har oftast skapat otroligt bra intresse hos utvecklar eller hos affärsägarna. Och affärsägarna, de tittar ju givetvis på milstolparna, Vi kör detaljfokuseringen då kommer en del middelsstolpar bli förskjutna i sig. Eller? Ja, det är historiskt för att det blir det i vissa fall, eftersom man inte vet tillräckligt mycket om en situation eller att marknaden har ändrat sig.

Men det fina i det här är att när man får det engagemanget hos de här nyckelstejkålds i sin PSC när de förstår vilka utmaningar man har när de är med i action. action. Det är då man får den acceptans att det kommer att ta lite längre tid som då nu skulle bygga våra test miljöer. Det kommer att ta lite längre tid eftersom de här hela IP hanteringen tar lång tid med brandvägs uppgångar och det förstod alla efter tag. Det var faktiskt så ganska kul efter projektet fick en av våra duktiga arkitekter gå upp och prata om det här på studieplan med högsta högsten om varför det tar lång tid och vilka saker vi behöver förbättra.

Så det är liksom att satt i ögat på en viktig punkt som som Telia var inte så bra på. Så att förståelsen finns där, när engagemanget finns där och när man är tydlig i kommunikationen till sin stakeholder. Så att när man har den här approachen, man får bättre buy in och slippa skriva seers. Snälla någon folk liksom. Det här är ju en jättebra sätt att jobba på tycker jag. Och när du säger slippa skriva seers då är det ju många i verksamheterna som tänker såhär, åh vad skönt.

Vi kan mata in vad vi vill ha. Men så tänker du inte. Nej, men så är det ju inte heller. Man håller ju koll på styrgruppen. Det är också en viktig poäng i det hela. Det är att etablera vilken ska vara medlem av styrgruppen din.

Man måste gå in och faktiskt sätta ner foten ifall en person inte är engagerad eller har nån skin in the game. Utan bara vill sitta av där och tycka och vara lite av en förstörande. för att mitt team gör mycket bättre. De sätter man i foten så att ni får inte vara med. Och då får man en fokuserad styrgrupp som gör exakt vad vi behöver göra och har buy-in för det. Och vad är det? Det är att nå visionen.

End in mind. För att ta ett exempel då. Vi har en vision att vi ska ha det bästa systemet för våra kunder på marknaden. Och då kommer en… i styrgruppen och säger till dig att jo, förresten, de här danska kunder, de har ju en speciellt bankID. Det vill jag att det funkar för er också. Ja, då går jag in och så säger det att jag har sett med, har du en bra idé om vem som kan det här, så kan jag kontakta den personen, få in och göra en analys.

Och sen så gör vi då ett estimat på hur lång tid det kommer att ta. Det här är liksom en klassisk förstudieanalys, en quick look assessment på vad är det för krav du vill ha in. Då gör man ofta så här i andra lägen också och det gör man även i rolling whip-lärning. Och sen när man väl fått tillbaks den här studien, då säger man till sin styrgrupp Okej, vill att vi ska göra det här först eller sen? För det finns inget in or out of scope utan det handlar om bara prioriteringar. Vad gör vi först?

Och det är det som också sätter ett mindset hos styrgruppen att okej, jag kan få vad jag vill men jag får faktiskt prioritera mig fram till det jag vill ha. Och på det sättet skapa ett förhandlingsytan för styrgruppen att agera på. Så det du försöker beskriva är att vi har en stor backlog. Vi tillåter att ta in nästan vad som helst i backloggen så länge det ligger i linje med visionen. Sen när vi sätter oss ner och tittar i den närmaste vågen då väljer vi ut vad är viktigast att få ut just nu. Ja, till en fungerande mjukvara till kudd.

Och det där är nyckeln då? Det här att det ska vara någonting fungerande? Yes. Ska in i produktionsmiljön och fungera. Vad skiljer det här då från vanlig sprintplanering? För det är så historiskt, Graham, att man ska jobba.

Ja, precis. Men det står ju ingenting om hur du bryter ner i kunskapsskikt. Och det här själva arbetssättet kring, för iterationer, det är ju, alltså det här är match made in heaven mellan Scrum och rolling away planning. Kan du Scrum så kan du Rolling Way Planning också. Då hanterar man kunskapsskikten transparent med styrgruppen. Och transparent med din team som du jobbar med.

Det är så pass enkelt att inpåhålla. Det är därför jag har varit så förvånad. Jag har inte hört någonting om det. Det här duktiga personerna som du har intervjuat i podden. Jag sitter och känner att de kör åttor kring mig i logik. Men jag har aldrig pratat om det här.

Vi bara, men så varför liksom? Kan du beskriva kunskapsskikten och ge exempel på vad du har i respektive kunskapsskikt? Det första kunskapsskiktet kronologiskt är vad du ska implementera direkt. Det är liksom vad du kan implementera direkt och saker du inte har direkt i tal. Kunderna kunde du inte kan slänga ut massa ljusestorier som hänger ihop någon slags ljuske informationsflöde. Har du inte det?

Då är du inte mogen för att sätta upp. Då får du förlänga din inception. Du måste ha fungerande en logik i lösningsarstrukturen som funkar och att gapen täcks. När du väl har satt upp den första kunskapsskiktet, för sen så har du då förmodligen då. Då får vi gå och titta på första milestoneet till exempel. Det har också ett kunskapsskikt.

Du behöver inte kunna allt när du ska starta första sprinter behöver inte kunna allt om sprint fyra om du har fyra sprintar utan den kunskapen får du till dig under loppet av arbetet. Är det så att man misslyckas med att då får man ju hitta ett sätt att mitigera sig fram och okej vi flyttar ett sprint två eller ursäkta till till sprint två och sedan flyttar vi till sprint tre och sedan får man göra ett exekutivt beslut att Vi kommer inte kunna lansera det här i första milestone som jag tänkt. Om vi inte lägger till det här, då får vi förlänga med en sprint innan vi gör en milestone. Den här dynamiskheten i kunskapsskikten gör att du aldrig kommer att misslyckas.

För du sätter alltid förväntningar på rätt sätt. Sikta in att kunna överleverera. Under promise and over deliver. Det är liksom vad vi projektledare måste göra hela tiden. Jag ser risken att man börjar med det enkla och låter det komplexa vänta. Ja, det är till syne så.

Det viktiga i just den här startappen, i din team. Det är därför vi i det här projektet som vi har berättat om till Alltouchpoint, det börjar vi med det svåra. Vilka appar ska vi ha? Hur ska produktskomponenterna se ut? Hur ska erbjuden se ut? Hade vi tagit det på slutet, var det försenade.

Men vi lyckades leverera 50 procent mer features. Vi tog tag vid tjuren i behovet direkt och löste de problemen. Och lite tur måste man också ha när man är skicklig. Femet jag hade var riktigt skickliga i det här, för de förstod hur det här tänket skulle vara. Så de tog med sig det här att vi. Vi löser vi de här initiala stora problemen så kommer vi kunna ha mer tid över att lösa saker vi lagt i sprint 2 där vi har rubriknivå kunnande om och det vi bara har en high level design om eller vi har bara en liten förståelse kring.

Då kommer vi kunna lösa de sakerna mycket enklare och faktiskt är det så mångt och mycket att man väl har löst de svåra problemen så ser man inte svårigheter inom andra problem man tyckte man hade svårt i sprint och var lagt i milestone 2 och 3. Då är inte de problemen lika stora. Det är någon. Jag tror det är en projektledamagik där det händer så. Så alla projekt jag jobbat med är fem sex stycken. Så har det alltid skett så börjar med de tuffa sakerna först.

För sedan så kommer de här. Man trodde var tuffa saker inte var lika tufft och då så kommer man kunna överleverera. Hur gick det i telja projektet. Ja, vi lanserade då Pilot, fokusgrupp och som sköttes av CX, UX-teamet var riktigt bra och vi fick jättemycket bra input. Det här levde sig tillsammans med våra våra ägare i projektet, vilket gjorde att blev det någon liksom försenning som var acceptabelt för att det var de som tyckte att det här var nödvändigt och prioriterat. Sen under maj månad året 2015 så börjar vi sälja.

Vi går till marknads. Så vi började sälja fast det inte riktigt plattform var klar för att för att säljflödet var färdigt först. Sedan var plattformen så vi sålde inför semestern massvis med de här. Sedan gjorde vi leveranserna på hösten av dem som de fick börja använda. Så vi gjorde en commitment till våra kunder att vi får köpa nu, men så levererar vi i höst. Och det var acceptabelt för ledning.

Du pratar om det med förtroende. Beskriv lite grann hur du jobbar med det gentemot team, nyckelintressenter, styrgrupp och så vidare. Grundläggande det som är är basic. Det är att respektera varandras discipliner och kunnande. Alltför många gånger har suttit som tvåsnavsa på varsin sida om korridoren och pissar på varandra. Jag sa du är bara CRM arkitekt, CRM är bara en outlook och så vidare.

Och det är det första jag brukar göra det är att se till att folk respekterar varandras discipliner och kundande. Det är då man kan börja lyssna på varandra och då man kan kommunicera med varandra. Och det gäller även runt alla designers alla olika ska man säga. Nätverkstekniker nätverks arkitekter när det gäller då solution arkitekt. Enterprises arkitekt som håller på med domän modeller. Alla måste respektera varandras discipliner för annars så det går att stå.

Samma sak med med affärs ägarna. Våra arkitekter måste förstå att affärs ägarna som som har beställt det här Det är de som ska hämta hem en ROI, en return of investment. Det är deras huvud som rullar. Får man de här rollsakerna på plats, att man respekterar manas roller, så när det gäller styrgruppen allra helst har jag använt och alltid inlett projektet med styrgruppen med en liten styrgruppsutbildning. Vad jag förväntar mig dem göra. Exempelvis då sitter det personer från en operations.

Då vill jag att den personen förstår att det är ditt ansvar att se till att vi har staffing där. Så att de inte kommer att säga att vi har inte tid med projektet nu. Det är den personen som har ansvars att se till att det ska lyckas. Det gäller alla de styrgruppsmedlemmarna att inte ha en styrgruppsmedlem där som sitter och tycker är jätteviktigt. En annan viktig sak, det kommer säkert många att bli jättearga på när de hör det här, men jag är helt övertygad att styrgrupp ska styra Projektledaren ska leda och det är så många gånger som jag har tvungen att sätta ner foten mot vissa styrelsemätare som går in och försöker projektleda.

Och då säger jag men din disciplin är bara affärsägare. Håll dig till din kant här. Jag ska projektleda. Annars så kan jag ta steg tillbaks och lyssna och lära mig från dig i sånt. Det är du som avgör i det läget där du äger initiativet. Och när det säger om projekt, ägaren säger någonting sånt.

Och när jag är tydlig, då skapar jag också ett förtroende för att de har händat inte tycka om mig, men de vet vad de har mig. Och hur jobbar du då med utvecklare som får hela den här visionen, blir insatt i den och blir orolig för att ingen egentligen jobbar med de stora sakerna? Ja, det är jättebra frågor. Det är ju en klassiker du tar upp här. Vad man måste försöka göra, vad jag försöker göra det är att få grabbarna och tjejerna att förstå att gräv där du står. På Tele2 lärde jag mig det.

Gräv där du står. Försök inte gå över till andra gruppen och gräv. Och när vi väl när du väl är klar i din grupp. Kolla ifall någon annan inte klarar sin grupp. Då kan du gå dit och hjälpa. Det är så vi alla ska lösa saker och ting.

Och är det så att du känner att du vill förstå bättre av ett större koncept. Men då kan vi ta en session kring det. Men ditt jobb är det här. Och sedan brukar jag också säga då både till styrgruppen och till core teamet. och när jag har lite all hands möte. Det här konceptet brukar jag säga och jag hör det faktiskt i dina tidiga podcast i gäster sade också att vi kan tillåta in konceptet. Operationen lyckades patienten dog.

Det finns inte i mitt projekt det jag ska driva utan är så att någon har problem. Hjälp den personen när du har tid. Sitter inte och säger ha ha. Jag lyckades i alla fall. Vi alla förlorar på det. Och när man väl inte bara säger det utan verkligen går in och sätter ner foten att det är så här vi jobbar och visar i praktiken, det är då man får respekt och förtroende.

Som sagt, man kanske inte är omtyckt. Jag är inte där för att bli omtyckt, jag är där för att lösa ett problem. Har du fler råd och tips med din erfarenhet? Att förstå projektets natur är jätteviktigt. Innan man börjar förstå effektmålen och de unika behoven och kunna tillsammans hitta blöa vision, det är jätteviktigt. Det är det som adresserar osäkerhetsgraden.

Det här med att vara några bror, vi har ju, kolla hur det ser ut idag, det här kan du ju inte. Men måla upp en vision och sen ta det första stegen. Dit till den visionen. Det är jätteviktigt att man får in det hos alla även från högt och lågt i organisationen. Sen är ju så att Walling Wave planering fungerar bäst när projektet är dynamiskt. Och ni inte har all information i början.

Det är de man kan ju make a difference. Och sen då så är jätteviktigt att min erfarenhet är att CXUX är viktig när man gör produktutveckling. Sitt inte och hogga dem till dig själv. Låt styrgruppen, nyckelperson i affären, jobba med dem. Då skapar du en vilja till att engagera sig i att förseningar och prioriteringar jobbas på ett mycket enklare sätt. Inledande plan, superviktigt, som i alla projekt.

Men det är där du skapar dina kunskapsskikter, där du bygger upp din skrumplanering. Lösningsdagsdirekturen bryter du ner där så du förstår vilka gap kommer när. Kunskapen om gapen handlar om kunskapsskikten. Italtivarbetet är superviktigt. Jag vill poängtera att första milestoneen, första leveransen, bör vara antingen pilot eller en most valuable product. Att inkluderat user community kan rekommendera eller de fokusgrupp till första lanseringen och att låta dem hjälpa dig med hjälp av UX-person att förbättra tjänsten över tid.

Det är då du kan gå in med kan band tänk och slippa de här tunga relisförnstren i fall det funkar med med legacy och sedan då så att kontinuerligen uppdatera din totum på den. Jag kallar det för totum på den här plan gemensamma planen visionen. Och så fort information är tillgänglig så är det ett jäkla jobb att se till att alla vet att det har ändrat sig så att man får förklara Niansera och visa ledarskap. Varför gör vi justeringen? Vad är källan till justeringen? Vad är nyttan?

Och så vidare. Hur påverkar kortsiktiga mål? Hur påverkar de långsiktiga målen? Och visionen? Och sen som jag nämnde tidigare kring det risker osäkerhet. Att lyssna lika mycket som du pratar minst.

Det är jätteviktigt. För att de här riskerna som många kan bara blubba ut sig. Se till att fråga kan du. Har du har du momentum att kunna förhindra det att hända. Nej men då parkerar vi den den saken i ditt Excel. Utan du ska ta risker det du kan påverka det du kan vara en.

En som är en contributor till att det inte blir en issue och det blir en action item lista. Det är jätteviktigt för det är så jag har proaktivt hanteliga risker. Alla frågar var är din risklista. Jag vet att jag har inte den i min bjudor låda för den ligger ute hos mina kolleger i projektet. Det är de som hanterar den. Och sedan så det här med att använda verktyg för att övervaka projektets framsteg nära realtid.

Jättesvårt idag. Jag vet inte finns säkert verktyg i dag med Tia som man kan använda sig av som direkt kan se när man deployat eller när man har klarskrivit en ny story och gått genom test och pengar är tillgänglig automatiskt. Giravård säkert finns. sånt idag men men men ofta så vill inte folk ha så mycket tid på det finns som en en add on i själva Gira. Så det är väl de som summerat jag ser att att lyckas i osäkra osäkra projekt använder rolling och planning och sedan måste jag bara säga att alla så är så här. Kaviar till allt det här. Ja det finns så många duktiga personer ute här som lyssnar på det här kanske lyssnar på det här och kanske stängt av efter fem minuter.

Så hon kan det här tio varv bättre än mig. Och jag kan bara ta min erfarenhet och mina upplevelser av det här. Men jag vill gärna lära mig mer av andra människor kring det här. Så vill någon komma med kommentarer med Benji, det här är helt galet. Jag vill höra dig, jag vill förstå. Men varför?

Och lära mig från det. Så jag är inte en specialist i det här, absolut inte. Jag har bara fem års eller fem projektserfarenhet av Rolling Wave Plan och jag tycker det funkar skitbra. Om man vill läsa mer, vad har du hittat fakta om det här? Är det någonstans vi kan lägga i vår antecknad till avsnittet? Absolut.

Det har jag samlat ihop på ett ställe. Jag ska skicka dem till dig. Det är bland annat då referenser till PMI, PMBOK som har uppdaterat med Rolling Wave en hel del. Jag har ett antal länkar som går till intressanta filurer som ser emot mig bland annat hur jag definierar det här. Jättebra. Så man måste förstå projektets natur och sen så jobbar man efter det.

Jag ställer alltid frågan om mina gäster har begått några misstag som de skulle vilja dela sig med. Har du begått några misstag som du skulle vilja dela med lyssnarna som de kan lära sig av? Ja, herregud, det är så många så jag vet inte vilka jag ska ta och hur jag ska börja. Men det viktigaste tror jag är att lyssna på din magkänsla. Den är så viktig. Jag vet inte om en magkänsla är så viktig för en person som…

Jag kan vara som har kanske ett litet uppdrag bakom sig. Och har inte den erfarenheten och kanske inte den interaktionen med människor. Men när man väl har några projekt under rocken så lyssna på magkänslan. För den är oftast rätt mer än vad den är fel. Och det jag inte gjorde vid tillfällelse jobb är som programledare konsult och skulle göra då var som en senior advisor till till en företags ledning. Där jag blev så skulle säga.

Enthusiasmerad av av otroligt duktiga människor men som hade en annan agenda än vad den jag gick in med skulle ha och övertygade mig att inte göra vissa saker som jag jag kände att jag behövde göra och det bara gick fel. Så det är inte först då, fyra, fem år senare, jag insåg liksom, ja men fan, så kan det. Så jag gick efter ett tag så att jag behöver göra en sån här ursäktresa. Så jag ringde upp en del och skrev mejl till en del så att jag ber mig ursäkt för det här är att jag så sent vaknar syndaren mejl och så. Men det är nog mest bara för mig själv jag gjorde det.

Men det är superviktigt att lyssna på sin magkänsla. Vad roligt. Vilka reaktioner fick du på de här mailen? En del svarade inte alls. Och en del sa att det där förstod jag. Jag förstod din ambition, men det var för stora krafter du jobbade emot.

Vad roligt. Det var ett av de större konsoldrakarna som hade sina stakeholder, de hade sina, får man säga, agenter, som jobbade i det här programmet och ville styra till att den företag skulle få all utveckling. Hade jag gått in och gjort mina saker enligt min magstjänst hade jag lyckats lösa de sakerna som hade gått i stå i så många år. Det ville inte de. Du ska bara vara programledare. Att vara programledare och projektledare är ett avsnitt i sig.

Men den primära skillnaden är att du jobbar inte aktivt i leverabler. Utan du tittar på vad det är för effektmålsuppfyllnad ett projekt ger. Det är det du ska jaga projektledare i kring. Men jag vill gå ner och ta tag i två projekt som inte hade levererat på tre, fyra år. Och hade då rackat upp ett antal miljoner och inte levererat. Och ja, så jäkla intressant.

Jag gick det från min svansamellan bena. Det var riktigt tråkigt. Bra lärdom. Om man skulle vilja ha tag på dig, hur gör man då? LinkedIn är det enklaste. Mitt efternamn är ganska svårt att låta bli och glömma.

Jag lägger in det i antecknet till avsnittet. Idag har vi fått jättemånga tips om hur man driver projekt med Scrum, Rolling Wave Planning och många andra tips. Stort tack för att du kunde ta dig tid att vara med, Benenitje. Tack! själv tack för att jag fick vara med. Tack 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 mail på Lyssnare, snabbelag, Projektledarpodden.se eller vid det sociala nätverk du föredrar.