Transkribering: Flöden, förmågor och varför vissa organisationer levererar mer än andra med Torbjörn Dahlström (avsnitt 73)

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

Lyssna på avsnittet: 73: Flöden, förmågor och varför vissa organisationer levererar mer än andra med Torbjörn Dahlström Läs sammanfattningen: Varför Roadmaps Trillar Igenom – Flödeseffektivitet och Systemkapacitet (73)

Transkribering

Det kan ske något vi är produktiva när vi startar saker istället för att titta på vad vi avslutar. För det är det som är någonstans räcker på att man faktiskt är produktiv. Det kommer ut någonting i andra anledning. Den du pratar är Torbjörn Dahlström. Idag kommer han prata om flöden och förmågor och hur vi egentligen ska tänka kring det här med att få saker och ting gjorda i vår organisation. Det kan låta lite flummet, vi pratar lite lin och andra saker, men lyssna igenom det här och tänk efter lite grann.

Vad är det egentligen som gör att vissa organisationer kan leverera mer andra? Många organisationer har många projekt igång, men levererar de verkligen så mycket? Det pratar vi om idag. Lite sponsoring har vi idag också. Vårt eget Projektledarpodden kurser. Gå gärna in på Projektledarpodden och gå in på AI-kurser.

Där har vi AI-kurser som sagt. De flesta kurserna sker företagsinternt numera. Men vi har några öppna som man kan klickas på. Och är det så att du önskar ha på din ort så kan du faktiskt nu klicka in. Så att du kan klicka. Nej men jag skulle vilja ha det här i Kiruna.

Då försöker vi få ihop lite folk i Kiruna så att vi kan köra där. Så gå in gärna på försökerledapodden.se och anmäla dig om du vill gå kurs. Jag heter Mattias Eibes med podden och nu kör vi! projekt och vi lärde mer av andra om projektled. Idag har vi med oss Torbjörn Dahlström. Han har varit med här tidigare. Idag ska vi prata om styrning och vad passar bättre då att du jobbar som konsult med styrningsfrågor.

Välkommen igen till projektleddapotten. Drammen tack. Kul att vara här. Vad kul. Vi pratade lite här innan och sedan började vi prata om det här med vilka problem det finns med styrning och liknande. Du jobbar rätt tätt med organisationen som försöker leverera sina roadmaps.

Vad är den vanligaste frustrationen som du hör? Ja, men precis. Det är en bra fråga. Det beror lite på vem som är frustrerad. Om jag frågar en projektledare eller en ledningsgrupp. Projektledare brukar uppleva ett maningar att få pre- och för sitt projekt i roadmapen.

De vill få igenom sina grejer. Det är kul. Det visar på ett engagemang och det visar på att ätta i. Med ledningen där mot. Där är det lite olika saker som jag har. Selvvis har man den här, och det kanske inte på allra högsta nivån, att den kanske är ett steg ner från CIO.

Det är lite så här, nu har det trillat ner en väldig massa, hur sjutton ska vi få ihop det här? Och vi vet ju hur det gick förra året och så vidare. Men jag träffar också CIO’er som… Jag är lite fascinerad av hur ofta jag har den här. De uttrycker frustration över att de koncernen prioriterade initiativen, de går liksom inte igenom systemet. De förstår inte riktigt varför det är så svårt att prioritera.

Det är jätteenkelt. Vi har bara tre prioriterade projekt. Varför kan inte de få fokus? Det där är en vanligt återkommande frustration. Varför kan de inte få fokus? Det är som alltid, så det är inte bara ett svar på den enkla frågan.

Men delvis finns det ett gap mellan strategi och roadmaps och vad som finns i den operativa verkligheten i Tivens backlogs. Det är rätt uppenbart. Det är enkelt, vi kommer säkert att prata mer om det. Det andra är att man jobbar gärna med att bygga roadmaps som ser väldigt rationella ut och som kanske också till och med grundar sig på någon slags erfarenhetsmassa. Det här är ungefär vad vi historiskt har klarat av och sådär. Men sen saknar man kanske de mekanismer som behövs för att få en rimlig feedback och kunna löpa och justera på sin roadmap.

Det tenderar att bli att man justerar i varje projekt, men kanske inte på den övergripande roadmapen. Den är på något sätt satt. Den är godkänd av någon styrelse eller någon väldigt viktig styregrupp. Och så tenderar den att bli en verklighet. Och man tycker att nu har vi kommunicerat det här. Vad är problemet?

Och problemet är multifacisterat. En av dem som jag sa är att den operativa verkligheten motsvarar inte vad som händer i det stora hela. Och en annan del som vi ser är att det är en hårt när omöjlig uppgift att kunna förstå exakt hur alla de här projekter kommer slå ut i organisationer och mot våra leverantörer vid exakt givet ögonblick. Det går inte att bedöma det när man sitter med de här tio initiativen. Så då försöker man att jobba med bättre. Vi ska verkligen vara noggrannare med vilka initiativ vi väljer ut.

Och vi ska verkligen ha bra R&I-er och det ska vara bra genomtänkt och det ska finnas en tydlig nytta. Men då blir det också bara ännu mer visualisering snarare än att man faktiskt förstår och styr och anpassar löpande på det som händer. Så nu pratar jag på jättemycket på det. Och det är jättebra. Och det jag ser är att ofta de strategiska initiativen är rätt så stora. De innehåller väldigt mycket. väldigt många olika delar och garanterat så stöter de på en eller två flaskhalsar som finns i organisationen.

Det må vara integrationer eller det må vara någon liten enhet någonstans som ofta kanske inte prioriterar de här stora initiativen vilket gör att alla andra kan bli klara men två år senare så kan initiativet totalt bli klar. Tänker du det här? Ja, så är det ju. Det är definitivt så att vi har några problem med både äkta och falska flaskhalsar beroende på hur nördig man vill bli på flödes teorin. Men där kan jag uppleva att man kanske startar i fel ände lite så där. För när man jobbar med ett initiat projekt så jobbar man gärna med att tilldela resurser till det här projektet. med nån slags allokering av de här kompetenserna behöver i de här givna tillfällen.

Och det är rimligt, rationellt. Vi vill komma åt den här kompetensen och använda den i projekten. Problemet är att det är vad vi kallat utgår från nominell kapacitet och inte faktiskt kapacitet. Och då kommer vi att drabbas utav de här flaskhalsarna. För att nominell kapacitet… Min enkla liknelse brukar vara så här, okej, du har tre pizzabagare.

Hur många pizzer kan du baka? Ja, ganska många säger nån sådär. Hur många pizza kommer normalt ut ur de här pizza-bagarna på en kväll- om de jobbar åtta till 60-12 eller vad de jobbar? Det är att förstå den faktiska kapaciteten. Vad händer om vi adderar ytterligare en pizza-bagare till det här? Kommer vi då att öka det med 33 procent?

Nej, det kommer vi inte att göra. Då drabbas vi av utrymmetsproblem. Vi drabbas av överlämningar och så vidare. Så gäller det att förstå vilken är den faktiska kapaciteten som systemet- som jag verkar leverera innan. Hur mycket brukar vi normalt producera? Där är det till samtidigt.

Jämför man med vilken tillverkningsindustri som helst så kommer de ju svåra på en gång. Det är skitenkelt, det vet vi precis. Vi vet exakt hur många paketer packningsrobotten kan sätta ihop eller hur många meter tunn plåt som valsen kan skicka ut. Där vet man exakt. Det vet vi inte exakt inom IT och vi döljer gärna bakom det faktum att det är en högre komplexitet för vi har inte 30 sekunders intervaller på vårt arbete. Men det går att titta på den faktiska systemkapaciteten.

Det går att ta ut den här datan genom att titta bakåt och förstå hur systemet producerar. Då skulle vi kunna titta på ett annat sätt än att jobba med nominell kapacitet utan att jobba med det faktiska. Blir det där förståeligt eller försvardig? Definitivt. Jag tror att man kan likna IT-arbete om det vi pratar om nu Det är väldigt mycket mer renoveringar eller ombyggnader av hus. Där kanske du saknar lite ritningar.

Du vet inte om det sitter asbest i väggarna. Du har inte koll på allting, men ändå måste du göra estimeringar. Då kan du titta på tidigare jobb. Då får du välja vilka risker du har och liknande. Men tumreglumetod, vad använder du för att sätta en plan? Titta på MPRI, vad finns det för data som pekar på det här?

Jobbar man mot Agila-team eller utvecklings- team som har en anteringssystem av något slag, om det är Jira eller DevOps eller nåt annat, då finns det ofta ganska mycket data att hämta där. Det andra är att försöka identifiera var de kompetensmässiga flaskhalsarna finns. Här finns det också stöd att få utifrån de här verktygen. Vi håller på att bygga en lösning där vi tittar på hur vi ska kunna expontera ut den här datan på ett bättre sätt för kunder så att de ska kunna få tillbaka den och själva använda frilöntifierade. För det finns alltid flaskansar.

Sen är det så här, jag har suttit med flera styrgrupper där de har suttit med linportforter och kanban och liknande sånt där. De har jobbat safebaserat. Och så har de sagt så här, ja nu har vi gjort vår prioritet utifrån WisChift. Det ser jättebra ut, fast jag vet att det inte kommer att funka. För det där initiativet, det där initiativet, det där initiativet kommer allihopa att behöva gå igenomgörande, det där torkande, det vad den kan heta. Någon djupt engagerad trotjänare som har jobbat länge i företaget som är en nyckelresurs som allting flyter igenom.

Den där kan man faktiskt redan på personnivå identifiera. Den sista grejen som jag brukar titta på är ju att om man jobbar med tilldelad kapacitet Säg att man har fått en resurs till 50 procent. Då ska du betrakta det som 25 procent. För i realiteten kommer du inte få ut den där 50 procenten jämnt vid något tillfälle ändå. Utan det kommer att vara ställtider om att flytta fram och tillbaka och så vidare. Då kommer den här resursen inte vara 50 procent effektiv.

Det är dessutom ingen som faktiskt jobbar 100 procent på sin tid ändå. Vi är ju människor. Ibland måste man gå på brydonesan och kanske ta en kopp kaffe. Då vet jag att man postar något brev eller vad det kan vara. Så de där tre grejerna. Titta på emperin, identifiera flaskhalsarna och halvera den kapacitet du tror att du har fått.

Och när du pratar om emperin, då kommer du… sådana här saker fram som att man kanske inte levererar till 100 procent, man kan skilja i bort eller 70 procent. Då behöver man inte ta hänsyn till det om man vet hur mycket de har levererat eller hur mycket tid de har haft. Vad ser du för symptom om man jobbar med en numera eller katastrof? Ja, men de är ganska tydliga. Det första är omstater och omplaneringar för att man är överbelastad. Det är rätt tydligt då.

Det andra är att man får ganska snabbt förseningar i leveranserna. Det man tror ska hända på vecka tre, det händer inte på en vecka sju. Och inte sällan så uppstår det helt plötsligt nya flaskhalsar. Så man säger, det där har vi inte räknat med, det där borde inte vara en flaskhals. Ja, det beror ju på att vi skapat den flaskhalsen genom att vi haft många andra som samtidigt har skickat över arbetet till den här resursen. När jag säger resurser så kan det vara ett team, en maskin, leverantör eller en individ.

Men på något sätt så skapar vi en illusion av att här har vi en flaskhals för att vi helt enkelt häller för mycket arbete på just den platsen i tillfället. Här brukar min likelse vara att när man är på flygplatser… Jag är gammal och kom ihåg hur det var när man alltid var tvungen att stå i en insäkningsdisk innan det fanns automation och disker och sånt där. Då var det sällan att göra till säkerhetskontrollerna. Det är säkerhetskontrollerna större idag än tidigare men de är också mycket mer utbyggda. Men idag blir det ju varje gång det kommer något tåg eller det kommer in en busslast eller någonting så blir det tvärstopp i säkerhetskontrollen för att då öser man in resurser eller man öser in arbete till den här resursen plötsligt.

Då ser det ut som att de är flasklanser när de egentligen har ett ganska jämnt genomlopstempo på sitt arbete. Så det är ganska exakt. Man kan roa sig med stor mät ungefär hur snabbt det kommer ut en person i taget från säkerhetskontrollen om man tycker så. Den som gillar flödeslära tycker sånt är roligt och då kan man titta på hur man kan bygga buffertar och liknande och låta folk gå lite vilse innan de får komma fram och sådana saker. Vi ska prata vidare om delade resurser och lånade resurser i ett vanligt upplägg. Det kan bli lite problem, sa du när vi pratade innan.

Ja, precis. Det är inget konstigt att man lånar resurser. Där finns kompetensen som man behöver komma åt i projekten eller i vissa privor. När man jobbar med all lokering av resurser lånar man dem från andra enheter. Kan man låna den fullt ut till projektet då är det jättebra för projektet. Det är superbra.

Det är inte lika bra för linjeverksamheten och kanske inte alltid som projektledare har det som sin första prioritet. Men problemställningen då när man lånar en resurs en del mängd av tid är ju framförallt att inflödet av arbete till den här resursen är aldrig i linje med den tänkta allokeringen. Har man avsatt sig 20% av sin tid hos någon resurs eller 25 eller vad det kan vara. Det betyder inte att det kommer exakt 25% arbete till den här personen, utan det kommer att variera väldigt mycket. Egentligen vad man gör, det är att man definierar med vilket tempo som projektet kan leverera baserat på vilken kapacitet man tilldelar på den lånade resursen.

Om man dessutom använder min tumregel från ovan då, det är det tidigare om att du får egentligen bara halva resursen och får 50% så har du egentligen bara 25% kapacitet tillgång att förlita dig på. Då har du ganska låg tempo mot vad du trodde att du skulle vara. Allra värst blir det här naturligtvis om det är någon som har en unik individuell kompetens. Det är bara Bengt, Lasse, Stin, Knut eller under kan vara som kan just den här beräkningssnurran i vårt försäkringssystem. Eller den här integrationen mellan säljstödet och marknadsstödet. Då sitter man ju fast där.

Då har man den där flaskhalsen som man slår små. Det jag har jobbat med i de där fallen är att jag faktiskt har tagit in en trinil eller liknande vars enda uppgift har varit att se till att minska friktionen för den här specialisten så att den personen bara kan fokusera på att svara på frågor. När den kommer på sin halvdag på tisdag och när den kommer på sin halvdag på torsdag ligger ett frågebatteri där, det dokumenteras och sen till på torsdag så kommer ett nytt frågebatteri och det här uppskattas väldigt ofta av de här experterna. De behöver inte gå på projektmöten, de behöver ingenting.

Allting blir bara koncentrerat. De får bara mata ur sig det de tycker är roligt. Har du jobbat på något annat sätt med friktioner och liknande? Ja, alltså det du pratar om är, och här igen då om man ska vara lite så här flödes-teoretiskt nörd. Så finns det ju något som heter serial constraint som du egentligen belyser ett steg i då. Det handlar ju om att man identifierar flaskhalsen.

Man underordrar allt arbete till flaskhalsen. och sen levererar man flaska, det vill säga man ser till att den ska aldrig någonsin behöva göra någonting annat. Den mest centrala, viktiga uppgifter som är det satt att göra. Det är ett jättebra sätt tycker jag. Den typen av backfill tycker jag är faktiskt väldigt bra. Man kan också fundera på varför sitter vi vid en organisation där vi har den här typen av flaskhalsar. Det här är ett långsiktigt arbete som man naturligtvis bör jobba med.

Att skapa ett läge där på inget sätt alla kan allt men där vi undviker att för centrala kompetenser eller områden eller funktioner, eller vad vi kallar för, att det är bara en person som kan det här. Och det här förutsätter ju en viss storlek någonstans i organisationen, det förlorar jag också. Så har man en IT-organisation bestående av, vad vet jag, fem, femton personer, då är det där svårt. Men har man en IT-organisation som kanske består ut till 200-250, då är det lite oförlåtligt att man har den typen av kompetensplats i Kalsland. Då har man inte skött sitt långsiktiga planeringsarbete, tycker jag, för kompetensförsörjningen.

Har du några roliga exempel på det här? Ja, men du nämnde ju själv integration. De brukar ju vara de första som kommer upp. Jag upplever faktiskt att arkitekter är väldigt mycket över en flaskhals. Och kanske allra mest i organisationer där man tycker att arkitekt är ett eget skrå och där väldigt mycket beslut ska gå igenom olika form av forum, råd och beslutsorgan. Jag hade ett uppdrag där det fanns en chefarsitekt som hade tagit fram någon modell kring arkitektur.

Det tyckte jag var väldigt bra, men sen slog det mig att någonstans mitt i texten över hur deras arkitektur styr modellen för arkitektur skulle se ut, så fanns det en skrivning av att chefarsitekten kunde vid varje tid vid ett tillfälle sätta veto på precis vilket beslut som helst. Det kan man ju inte tänka att det låter rationellt, för då fattar man ingen dåliga beslut. Problemet är att man fattar inget beslut alls, för han är givetvis uppdagen hela tiden och kommer inte fram till att ha tid med det här. Han i sin tur slungade sig in i möten till höger och vänster där han på fem sekunder skulle kunna fatta beslut om go-no-go på komplexa aktivitetsfrågor.

Han kanske behövde en vecka för att sätta sig in i, men han hade 20 minuter på sin mötet. Så det där var ju oålbart. Man lyckades hålla driften igång för att man höll på att rulla ut ett nytt inköpssystem. Det var inget problem att hålla. Man kunde skapa inköpsordrar och skicka dem. Men hela det flödet för att validera nya leverantörer, vilket var ganska centralt för organisationen för de jobbade med ett par tusen leverantörer och bytte ut ett par hundra varje år.

Det hade tvärnit det därför att en stackars utvecklare som satt i back-end och som hade ansvar för integrationen mot något det visst var ett personalvalideringssystem för behörigheter och delvis var det kopplat till er, predelen för logistikkedjan. Det var liksom hans jobb att sköta det där. Han var helt nedlusad i arbete och kunde inte på något sätt hantera det där. Han gjorde sitt bästa för att försöka hoppa mellan uppgifterna som han kunde. Det är väldigt sällan ett projektmetodproblem eller ett personalproblem. Det här är ett systemproblem som vi har.

Vi jobbar felaktigt i vårt arbetssystem. Med system menar jag inte mjukvara, utan den metodiska, etnologiska strukturer som vi satt upp för att kunna hantera. Ibland pratar man om förmågor och aktiviteter. Hur tänker du kring det här? Det här tycker jag är riktigt intressant. Ofta i projekt så blir det ju att man har ganska väl beskrivet projektdirektiv och projektbeskrivning.

I det finns ju projektmål och så finns det effektmål. Det är ju effektmålen som är viktiga. Det är ju inte projektmålen. De är ju medel för att uppnå det här. Och effektmålen brukar inte sällan, men inte alltid, men inte sällan så brukar de ju vara ganska väl beskrivna förmågor. Så efter det här så kommer vi kunna ha en kortare ledtid i kundtjänst, i hanteringen av ärenden.

Eller vi kommer kunna ha en ökad produktivitet i vår produktionsapparat tack vare bättre digital stöd. Och så har man kanske brutinerat det här. Där hade ett konkret exempel med kunder i strategin så fanns det ökad produktivitet till produktion genom bättre digital stöd. Och så hade man formulerat ut ett antal olika viktiga initiativ. Den ena förmågan var bättre korrekt produktionsdata. Den andra var minskad manuell rapportering.

Och sen hade man då översatt det till projektet. De hette nån sån här ypsilon. De hade några grekiska namn. Och det var det enda folk pratade om. Hur går det med projektet ypsilon? Det var ingen som pratade om hur det går med bättre.

Har vi mer? korrekt produktionsdata här ute nu. Och då ska man komma ihåg att organisationen styrs i en språk. Och om det språk vi använder är frikopplat från det resultat vi vill uppnå, då får vi ett beteende därefter liksom. Så det handlar ju om att försöka kunna göra den förflyttningen från att att liksom beskriva de här aktiviteterna och gå till förmågorna. Och det här är ju bedrägligt, för det är så väldigt mycket enklare att följa upp aktiviteter. Hur tycker du att man ska göra det i praktiken?

Ska man skriva om projektmålen så att de blir förmågemål? Ja, det tycker jag faktiskt. Hur låter det då? Ja, precis. Man tänker först och senare. En aktivitet är vad vi gör.

Vi implementerar det här systemet. En förmåga är vad organisationen kommer att kunna göra bättre efteråt. Så vårt projekt kanske är att implementera den nya ärenden till systemet. Men förmågan som vi har är till exempel minskad ledtid genom bättre självservice. Eller högre kundnöjdhet genom lättare använda gränsenhet. Eller bättre förmåga att planera och prioritera ärenden genom vad vi nu kommer fram till.

Sådär såg det ut i ett projekt som jag kom lite i närheten av och där vi jobbade med just att försöka identifiera vilka förmågor. För sen kunde vi bryta ut dem till vad som blev våra epics och features och stories. Jobbade ner i den modellen. För där finns ju också problemet att du har det strategi som kanske beskrivit de förmågorna som du vill uppnå. Men sen när du tittar i backloggen i den operativa verkligheten, då står det så här, Piraterapport B funkar inte. XL dump tack.

Justerar det här. Då har man ju tappat hela kopplingen till den förmågan som man går utöver. Men vi projektledare har alltid försökt undvika att ha de här effektmålen skrivna på oss. Vi vill ju ha, gör den där Excelen. Och då levererar vi Excelen och är alla glada och nöjda, i alla fall vi. Ja, eller hur.

För det är så mycket enklare att göra på det sättet. Det är bedrägligt lätt att trilla ner det där. När jag jobbar med chefer i det här, när jag säger att ni måste börja formulera förmågan, då blir de ju liksom, aha, hur gör man det? Det har vi inte gjort förut. Varför startar vi oss sådant? Även här tittar vi på att det finns utmärkt stöd.

Tänk om det bara kom någon ny spännande teknik som kunde hjälpa oss att omvandla det vi säger till något bättre. Så där i den här modellen som vi tittar på, som vi bygger nu, så jobbar vi också med en sådan sak. Hur skapar vi spårbarhet till språkligt mellan det som finns i strategin till rollmappen till den operativa verkligheten i backloggan. på renspråkig nivå, vilket också är en förutsättning för att vi ska kunna följa upp och se att de prioriterade aktiviteterna som vi ska ha i backloggen är faktiskt de som får uppmärksamhet. För det här är ju annars problemet att man när man är duktig, skäckledare, man ser till att det formuleras epik, så man bryter ner till features, stans med teamen och man får att trilla in i stories i backloggen.

Då vill man ju veta att de fortfarande prioriteras, att de faktiskt fortfarande är de som glider igenom. Här är det ju, kan man komma så långt där man har den kopplingen, då har vi ett utmärkt sätt att få mycket bättre feedback till både projektledare och styrgruppen. Vi kan se att vår initiativ är de som fastnar. Det är de som hamnar i sådana här paus-overs eller spel-overs. De flyttas mellan, rentar om och om igen. Man ser att unika individer, resurser har en jättehög vipp med alla de här viktiga, prioriterade objekten som inte blir klara.

Och inte sällan så ser vi ju att ledtiderna på de där är helt… De är inte alls i linje med ledtiderna på allting annat som motsvarande team levererar. Men Stories som jag förresten tar sju månader att leverera, och Team In-the-Wandafall levererar de där på kanske tre, fyra veckor. Det är en rätt tydlig varningssynabla önskan, att den flyter upp till ytan som man kan agera på. Men hur ska man agera på det när man oftast inte har koll på helheten när man börjar? utan man upptäcker de här vart efter och då har du satt igång kanske några agila teamar satt igång.

Du inser efter ett tag att vänta vi kommer få en leverans om ett och ett halvt år från flaskhalsteamet. Ska vi då köra vidare eller ska vi bara stoppa? Stoppa det brukar kännas jobbigt. Det tycker folk inte om. Vi ska vara lösningsorienterade och inte problemorienterade. Så här tänker jag på det.

Det heter ju styrgrupp. Styrgruppens jobb är att styra. Det handlar inte om att stoppa, det handlar om att fatta ett aktivt styrbeslut. Det handlar om att säga, ska vi rulla vidare med den osäkerheten vi har? Eller ska vi dra i handbromsen och skapa förutsättningar som vi upptäcker saknas? Eller ska vi helt enkelt planera om eller justera om i vår prioritering eller vad vi vill någonstans?

Att dra i snöret, att dra i… Det finns ju en lean term som heter Andon, det finns ju en massa andra som jag som känner till den. Den ska man inte vara rädd för att dra i, för den betyder att man faktiskt har hittat ett problem som man aktivt kan åtgärda istället för att vänta på att det här problemet till slut blir en katastrof. Ironiskt nog varför ett par timmar sen så ringer en kund till mig och säger att vi skulle behöva hjälp med att kika på en grej. Det har visat sig att det har gått käpprätt åt skogen. Vi har inte fått någon varningssignal på det där.

Vad ska jag göra? Var står jag någonstans? Och då tänker jag, för det första tycker jag att det är synd om de här stackarna. Det är massa människor som jobbar hårt och engagerat för att det här ska bli bra. Det är inte det. Det är inte att vi är dåliga människor. men att det inte kom en varningssignal mycket tidigare är naturligtvis en katastrof och ett tecken på att vi inte satt upp det system som vi behöver ha på plats igen.

Arbetssystem, inte frågan om JIR eller DevOps, som gör att man faktiskt kan agera på det här. Man kan fånga det, man kan göra någonting åt det och man kan fatta beslut som är enisierat och baserat på de riktiga fakta. Här är min tips till projektledare att man ska inte vara rädd för att komma upp och säga att vi behöver nu fatta ett aktivt styrbeslut. Här är tre alternativ. Där en utav dem är stanna, en utav dem är fortsätta, en utav dem är tänk om. Och då ska man helst ha relevant data på bordet så att man fattar beslutet ifrån.

Och då har man ju, jag brukar ju tipsa på projektledare, lär dig systemet. Förstå vad systemet producerar. då kommer du kunna komma tillbaka med det datat till din kund eller din beställargrupp. Ja, så det här är liksom, låt mig exemplifiera med verkligen data som förklarar varför det ser ut som det gör. Så att det inte blir, nu ska vi hugga huvudet av projektledaren för att vi har misslyckats. För det är sällan projektets fel på det sättet, utan det är någonting annat som är grundläggande fel. Sen kan man ju fundera på hur projektledare är lite fascinerade hur de så ofta ändå slänger sig ut i det här utan kunskap om det.

Och så tänker de att med rå kraft så kommer de att kunna backa igen. Det kan funka ganska bra, ibland kanske till och med genom hela projektet. Men jag har ju sett ganska många organisationer som är rätt trasiga under tiden och efteråt liksom. Det blir rätt mycket besvär efteråt. och så här efteråt. Jag var tydlig med det. Det är inte projektmetoden som är fel, utan det är styrmekanismerna som är fel.

Tittar vi på, du nämnde Lean här, och man brukar prata om 80 procent planerbar kapacitet och liknande för att få ett bra flöde. Och så tittar vi på, många organisationer sitter ju och startar betydligt fler initiativ De har inte det flödet, men det är heller ingen övergripande bild av hur mycket organisationen kan leverera. Och styrgruppen, de fattar bara beslut om sina resurser och har ingen kontroll över det lilla gila teamet längst bort till vänster, men som de är väldigt beroende på, där det plötsligt bara dina små PIs eller Features eller vad det nu är, de bara skjuts hela tiden. Hur tänker du?

Det är jättefascinerande. Jag har ställt frågan till så många CIO-jord genom åren. Hur många initiativ har ni igång? Alldeles för många. Hur känns det? Det är väl så det är.

Och så pratar man om det. Skulle vi inte vara mer flangomsrika om vi kunde dra ner på det här? Kunns det minska work in progress? Ja, absolut. Intellektuellt förstår alla det här. Men det är ingen som…

Det finns några stjärnor där ute som jag tycker lyckas med det. Jag pratade med en häromdagen eller häromveckan. Han är verksam i Petroleumindustrin. Han har med framgång lyckats få till det här att vi har ett tak. Max så här många initiativ kan pågå samtidigt. Vi startar inte upp någonting utan att först avsluta någonting.

Men det har han ju lyckats med delvis för en av sin egen kompetens naturligtvis, men också framför allt därför att han har en vd som förstår det här konceptet, som står bakom det liksom. Som är väldigt uttrycklig med att, det här är vår kapacitet. Och inte sällan så får man ju det här, det står ju min budget att jag har det här initiativet att jobba med, Då ska jag kunna dra igång det, för det har jag lagt i mina affärsplaner och så vidare. Då har man ju andra tecken på hur styrelsesystemet inte funkar. Man lägger affärsplaner som inte är linerade mot roadmaps.

Så om man har roadmaps som har löpande uppdateras, då måste ju också affärs- och verksamhetsplaner justeras på det sättet. Men så är det ju ofta inte, utan det blir en årlig aktivitet. Sen tittar man på det lite då och då, för att motivera beslut. Man kanske inte justerar det. det sättet som man borde göra. Det är ju väldigt mycket en fråga om att vi inom IT måste på ett pedagogiskt sätt kunna lyfta frågan tillbaka till verksamheten och påvisa vad som blir de negativa konsekvenserna av att vi drar igång för mycket samtidigt. Har du lyckats med det?

Jag tänker på det beskriver här med budget också att i stora organisationer så blir väldigt mycket planering. Januari, februari. Det blir påbörjande projekt innan sommaren och så ska allting levereras innan jul för att det som budget och det är bara att vi behöver exakt samma resurser eller förmågor vid varje givetillfälle i alla projekt samtidigt. Jo men jag tycker att jag kommit en bit på vägen med flera olika organisationer och framförallt några organisationer. Jag har inget specifikt anhängare att säga som skala agil modell men att de som har använt skala agila modeller de blir bättre på att faktiskt identifiera att de har kapacitetsbekymmer och de möter det oftare.

Det paradoxala är att de möter det vid PR-planning. Egentligen borde de ju möta redan vid lean portfolio-planeringen. Men lean portfolio-planeringen blir en övning i vilket vi tycker är mest prioriterat. Inte vilken kapacitet har vi. Och sen, även om jag ibland ger några negativa working roadmaps, så tycker jag att när roadmaps bara är visualisering, så tycker jag att det är ändå ett viktigt första steg att påvisa Hur mycket är faktiskt igång samtidigt? Här är det intressant att komma ihåg att man har en slags tratt och det går genom lite olika steg innan man initierar nånting.

Innan man initierar nånting har man oftast ätit ganska mycket interna resurser inte sällan utav de specifika kompetensplatskalserna som vi behöver för de varit med i förstudier eller uppstart eller analysarbete och så vidare. Man måste särskildera mellan när vi startat initiativet och när vi aktiverar arbete in i organisationen. Det är faktiskt två olika saker. Och kan man bli bättre på syn, då kan man styra systemet mycket bättre. Har du fler exempel på hur man i praktiken spårar Roadmap-initiativ som faktiskt genomförs och signaler kring det här?

Ja, men det är lite som jag sa tidigare. Det kan man ju… Roadmappen är ju inte ett statiskt dokument, utan det justeras löpande. Och då kan man ju titta på hur mycket det förändras eller förflyttas mellan de kontrolltillfällen man har. Alltså hur mycket det faktiskt ändras på vägen. Det enda som man kan titta på som jag nämnde och som vi tittar mycket på i vårt verktyg som vi jobbar med det är ju det här, får våra prioriterade PIs eller Stories eller PBI eller vad vi kallar dem för får de den kärlek och den fokus som vi förväntar oss kommer de igenom i flödet eller inte eller har de avvikande ledtider Där kan vi titta på, det finns ju, igen då om man lite rör det som jag gör, men det finns ju det här måttet som heter out of control eller process in or out of control.

Så det vill säga att en enhet helt plötsligt tar extremt lång tid i jämförelse med andra, då vet man att då är någonting fel i systemet. Så då måste man gå in och titta på det och försöka identifiera oss med felna. Så det kan man också titta på. Och jag tycker också att när man jobbar med någon form av skalad agil modell, som man faktiskt beskriver tydliga leveransenheter som man hålls rädd att leverera inom de kortare incrementen och 8-12 veckor eller vad det kan vara. Kan man ju bara räkna på dem? Hur ser genomflödet ut på dem?

Får vi igenom de saker som är tänkt här? Förra incrementen planerade vi upp 78 features, vi har levererat 12. Det är kanske en signal på att vi inte riktigt är i mål, utan att vi behöver samtidigt dra ner på vippen och få en tydligare koppling till den faktiska kapacitet som systemet har. Det här är väldigt lätt att säga och det är väldigt teoretiskt i vissa fall. I praktik har ju varje team sina egna utmaningar och givetvis skulle de behöva en bra Scrum Master eller en bra coach eller på liknande och gå igenom den verkligheten det har man inte tid med.

Nu måste vi köra spring. Jag såg att en av mina gamla bekanta, Ola Kjellgården, lade en jämförelse på LinkedIn. Han lade en jämförelse mellan hur mycket fotbollspelare tränar och hur mycket de spelar match. Sen hade han en ganska bra analys av att vi inte kan göra den jämförelsen med vår verklighet. Man kan inte gå omkring på kontoret 90 procent av tiden och sen jobba 10 procent av dagen. 90 procent planering, träning och förberedelse.

Det är ju någon annan situation. Jag tror inte så mycket på… Jag förstår att det ibland måste en organisation ta sig genom stora förändringar. Men de gör man bäst i väldigt många små steg. Det är en löpande aktivitet om man hela tiden tittar på den justeringen och förbättringen. Det finns en bok som jag ibland brukar referera till som heter Beste i världen.

En liten, tunn bok. Där pratar man om något som heter Svenska institutet för förslagsverksamhet som mäter… Antalet processförbättringar som en normal svensk medarbetare levererar på sin arbetsprocess per år. Det är då 0,46 eller 0,48 och sånt där. Tänk om vi kunde uppfå det där till två år. Vi skulle kunna leverera otroligt mycket mer, för den nyttan har vi hela tiden.

Att väva in det där i arbetssättet, att få till stoppen, få till reflektionen, få in justeringen, den löpande småstegnen. Det är kanske en av de bästa sakerna som Diagila har gett oss någonstans. Att det ska finnas en planerad aktivitet för det här. Man ska avsätta tid till att reflektera och justera. Vad jag tyvärr ser är att man lägger mycket tid på att ha bra samarbete. Det är trevlig stämning, men man tittar inte på datat.

Vad producerar vårt system? Det kan ibland bli sekundärt. Det får mer uppmärksamhet. Det låter lite grann som du vill införa förslagslådan igen som fanns för 35-40 år sedan. Absolut inte. Hemska tanke.

Då får man bara nya lappar och så kan vi få bättre kaffe i maskinen. Nej men man måste ju prata om det här. Jag har höll med Webinor för några år sen där vi har pratat mycket om vad vad lägger ledare sin tid på i organisationer? De lägger på tok för lite tid för att titta på hur systemet producerar. De lägger på tok för mycket tid på att sitta i styrgrupper, hålla utvecklingssamtal och att pänsela omkring resurser i Excel-like. Om vi i stället kunde ta den tiden för att titta på hur systemet producerar, då kommer vi att upptäcka de här sakerna som skulle hjälpa oss att faktiskt styra det på ett bättre sätt.

Då behöver vi data. Det är paradoxaliskt, datat finns ju nästan alltid där, men det används inte. Saker försvinner ju i backloggen, pratar du också om. Vad menar du med det? Jag såg något skämt den dagen att backlogs är ett utmärkt verktyg. Där kan vi lagra hur mycket som helst som vi aldrig tänker göra.

Det finns en massa olika problem med det. Enligt dem är backlogs naturligtvis alldeles för omfattande. Vi rensar inte, plockar inte bort saker. En annan är att vi jobbar med att så fort som möjligt försöka tilldela en backloggobjekt till någon individ för att vara säkra på att den någon gång kommer att hanteras. Då får individen en lång lista över saker som de aldrig tittar på. Vi märker kanske inte upp de här objekten eller identifierar dem– –som relaterar till de viktiga objekten eller de större enigheterna.

Ibland jobbar man med kostnadsstellen och tidiga apportering. Men det här datat finns där. Det ska användas. Då skulle vi kunna titta på hur systemet producerar. Då ska vi rensa i backloggen och plocka bortsaker. Vad är det som hindrar oss från att ta tag i det idag?

Ja, det är flera olika delar. En av dem är att man kanske inte betraktar IT som ett produktionssystem på det sättet. Jag var ju nästan bara utslutande med IT, jag fattar att det finns andra projekt än det också. En av dem är att man har skapat olika strukturer som ger en känsla eller en upplevelse av kontroll. Men som kanske inte riktigt mäter på de saker som vi borde mäta på det är ju vad systemet producerar igen. Inte vilka aktiviteter vi utför utan vad som faktiskt färdigställs och vad som produceras ut någonstans.

Så, och sen finns det någon problemställning i att… Och jag vet, jag kan inte svara på hur stor den här är men det är ju lite fint att starta projekt. Det är ju lite sådär, titta nu ska jag göra en jättestor och fin transformation. Och så drar man igång en massa saker som behövs göra för att vi ska bli digitalt redo och digitalt förberedd. Och så driver man igenom de där projekten och så går man vidare till nästa ställe och drar en mängd nya projekter. Och inte sällan behövs de projekten, inte det liksom.

Men det finns en problemställning i att det kan ge sken av att vi är produktiva när vi startar saker istället för att titta på vad vi avslutar. För det är det som är någonstans täcker på att man faktiskt är produktiv. Det kommer ut någonting annat. Kommer ut någonting som faktiskt ger den förmåga vi ville ha. Hur jobbar du med kvalitet i det här? För det är väl lätt att prata om hastighet genom systemet.

Men sen att du behöver reparera det där, målgångar, efteråt och liknande. Alla hör. Det här är lite intressant, och om man trillar ner i mitt och träsket av flödes teorier så finns det en lag som heter Littens Lå. Jag vet inte om du ser ut som du är bekant med den. Den säger att det finns en direkt korrelation mellan hur mycket samtidigt pågående arbete man har och vilken ledtid man har. Men vad den också säger är att det är intressant att inte nog om att ledtiden blir längre, Det är den totala arbetstiden som krävs för att utföra arbetet längre och kvaliteten med… vilket vi utför arbetet blir också sämre.

Det är inte så konstigt, för om du sitter med en komplex fråga och är tvungen att avbryta den frågan för att jobba med någonting annat ska du komma tillbaka till den. Då är det mycket större chans att du kommer att väva in fel och brister i den kodmassa eller den teknikkonfiguration eller vad det kan vara som du håller på med. Men likväl när du kanske sitter med någon kravarbete eller liknande och försöker göra någon form av värdeflödeskartläggning för att kunna beskriva hur det där ska fungera något system. Om du inte kan fokusera på det så ökar du samverkheten och du kommer att missa nån viktig aspekt eller att du kommer att göra något fel på vägen.

Så det finns en korrelation där emellan. I projekt sammanhang så pratar vi också gärna om och här tycker jag att man kanske tänker fel på projektdriaggen. För där pratar man ibland om tid, pengar och kvalitet. Men jag tycker inte att det är den tredje axeln. Jag tycker att den tredje axeln är funktion eller vad som produceras ut. Det finns en fjärde axel som jag tycker är projektkvalitet.

Men vilken kvalitet bedriver vi projektet? Men det är lätt hänt att vi betraktar kvalitet som att vi blandar mellan vad vi faktiskt producerar i projektet och vad vi gör i projektet. Vilket är två olika saker och så kallar vi det för kvalitet. Vi gör jättefina styrgudsmetokaler. Ja, men det är bra, men det är faktiskt inte tecken på kvalitet, utan det är tecken på projektkvalitet men inte produktionskvalitet. Så jag tror också att om vi kan fokusera mer på fåenhet, och det här är ju den nyttan och lärdomen som vi har fått från Agilum de senaste 20 åren, att jobba med många små justeringar är lättare att ha hög kvalitet.

Sen finns det en del intressanta invändningar som man kan få från utvecklar och arkitekter och annat om att det blir fragmenterat och man följer inte styrmodeller och så vidare. Det är absolut en risk som finns. Det finns gott någon team där du sitter och utvecklar och hittar på eget. Men det kanske inte beror på att det är dåliga utvecklar utan kanske beror på att man har tänkt knasigt i hur man bestämt sig för att samverka mellan arkitekturfunktioner och de som faktiskt gör jobbet. När projektledaren kommer till styrgruppen och talar om hur det ser ut, och styrgruppen svarar då att det är därför du är här.

Nej, den är bra. Jag jobbade i ett projekt en gång där organisationen var… Vanor betyder projekt väldigt traditionellt, men de hade en ambition att det skulle drivas mer agilt eller mer lättrörligt. En av sakerna som vi kom upp med och sa att vi skulle ha prövat jobba med att Vi inte tilldelar resurser till olika objekt som ska levereras utan vi försöker estimera värdet på våra objekt. Sen jobbar vi utifrån det värdet när tiden har tagit slut och då gör vi en utvärdering. Vem har du tänkt att ska göra den utvärderingen?

Jag tänkte att det var ni som skulle göra det. Hur menar du då att ska vi utvärdera värdet av det här? Det här, det kanske inte vi har kompetens i, då vet jag inte om ni är de som ska sitta i styrgruppen eller sa ja. Och inte så att det kanske inte var politiskt korrekt att stå. Men vi fick en rätt bra dialog kring det där att försöka hitta formen för att utgå från det perspektivet. Och det är styrgruppens jobb att styra projektet, det är projektledarens jobb att leda baserat på styrgruppens prioriteringar och beslut.

I det behöver projektledaren tillhandahålla till att styrgruppen den relevanta informationen som de behöver för att kunna styra på ett korrekt sätt. Då skulle jag ju komma upp med systemets kapacitet som är ett av mina viktigaste artefakter i den diskussionen. Jag ska vara väldigt tydlig med att jag menar inte tidrapporter och vad som är rapporterat i tid på projektet. Det är oftast väldigt dålig datakvalitet. Folk rapporterar ihop i slutet av månaden vad de tror att projektledaren kommer godkänna. Eller vad som finns i budgeten.

Det handlar igen om att försöka bryta ner projektet till de flödesenheter, de arbetsleveranser som ska bli färdigställda. Och sen använder de att mäta något. Där finns det stor nytta att jobba mot med de agila metoderna som princip. För de ska föreskriva att man bryter ner arbete på det sättet. Men jag upplever att det som inte syns där, det är ju saker som att Lisa behöver gå kurs eller Bosse måste hoppa in i det här projektet eller liknande. Men han eller hon ska fortsätta skriva på projektet för att vi har inte pengar någon annanstans.

Alltså när man sabbar datan på det här sättet. Den risken är uppenbar. Det finns en viss mått av overhead-tid som varje projekt eller linjeorganisation måste… att acceptera som handlar om att vi behöver investera i underhåll av våra resurser. De behöver ges förutsättningar för att kunna anta de nya utmaningar som kommer. Jag gillar att översätta det till fysisk verklighet för då kan man titta på det på ett annat sätt. Men liknande att Lisa behöver gå den här kursen betyder att vi behöver göra den här uppdateringen på robotarmen. eller vi behöver göra det där, bygga om det där produktionsbandet där tunnplåten trillar ut och ska rulla vidare på.

Det är jätteviktigt, det måste man göra, det är en del av arbetet. Sen kanske att tunnplåten går jättemycket snabbare på det bandet efteråt när man kanske har lite färre böjda kanter eller vad det kan vara som är motivert till det underhållsarbetet. Så det ska finnas en sådan del avsats tror jag även i ett projekt. Här kan det lätt bli mellan när projektet lånar resurser från linjoresurser då kan det lätt bli lite fight om vem tar den där smällen och den kostnaden av att gå någon kurs eller vad det kan vara. Och så kanske man tittar på varandra och hoppas att det andra ska lösa det.

Men man får ju hitta någon, antingen om vår resursion har en övergripande styrmodell eller om man helt enkelt bara får acceptera lite gummor och karuseller tillsammans mellan när man jobbar med de här resurserna tillsammans. Du har givet väldigt många tips och råd. Vilka fler skulle du kunna ge här till en projektledare som hamnar i de här situationerna och beskrivet? Ja, men mitt första är så här. Det är inte ett projektproblem, det är snarare ett ljuproblem. Det är ett systemproblem.

Och om du som projektledare kommer in och faktiskt tittar på systemet och vad systemet producerar. Du behöver inte vara expert på flödes effektivitet. Så, men du kan ju på minst gå runt och fråga hur det ser ut. Vi vet att arbete kommer till och med till det här teamet. Team Beta eller vad de kan heta. Hur ofta blir de klara med saker i tid som de har tänkt sig?

Det är ju ändå ingen dålig idé att ställa den här frågan till de resurser man har fått tilldelat. Hur ofta blir du klar med de saker? När du kommer in till jobbet på måndag morgon, hur ofta går du hem på fredag och kan säga att du har levererat de saker du tänkte göra den veckan? Om svaret är att det händer nästan aldrig, då vet du att du har ett systemproblem. Då måste du ta med dig in till diskussionen och säga att det här är kanske inte en stabil grund att stå på. Då måste vi titta på hur vi ska hantera det.

Så sluta med resursallokering och börja titta på systemkapaciteten och använd det datat som finns där och den information som faktiskt finns hos de här organisationsenheterna som man jobbar mot. Då kan man omfatta bättre beslut och ge styrgruppen ett bättre underlag för sina beslut. Ni håller på och bygger ett system. Vi vill berätta lite om era målsättningar. System är okej att kalla det. Vi har sett det här problemet en gång efter det andra.

Våra kunder producerar sina roadmaps och så trillar de inte igenom. Så blir man frustrerad. Så börjar vi titta på. Men allt det här datat finns nånstans. Vad kan man aggregera det på ett bättre sätt? Det är absolut att det finns inbyggt i de här olika det där vobsaliier eller vad det kan vara så finns det olika dashboards och widgets och så vidare och det finns ju en högmän.

Vi tror att det handlar om att vi behöver aggregera data från flera olika ställen och då finns det ju lyckligtvis idag en spännande ny teknikhörtal som hjälper oss att allokerat liksom kombinera information från en massa olika som är lite rå och oestrukturerande och sen bygga ihop det där till något vettigt som man kan få tillbaka ut i ett besluts underlag, inte att den här lösningen som har en AI-komponent i sig ska fatta några beslut, men att den ska kunna ge oss bättre information tillbaka. Vi håller på att bygga på den här just nu och vi tittar på tre olika nivåer. Vi har pratat om det på ett webbinar för några veckor sedan också. Det är delvis den del när vi tittar på systemets faktiska kapacitet, vad brukar systemet normalt producera.

Delvis är det en lösning för kopplingen mellan strategi, roadmap, epics features om man har det, eller PIA planning, och sen tillbaka till den operativa backloggen. Kan vi se att det finns en koppling här emellan över huvud taget, eller har vi tappat bort den? Det är ju en språklig fråga, där måste man läsa in jättemycket data från massa olika källor och sen kunna hitta ut det där. Och sen den sista delen är ju naturligtvis att, för om den första delen tittar bakåt så vill vi ju nu titta på vad som händer i det dagliga. Det vill säga kan vi få upp varningssignaler i realtid när våra prioriterade stories flyttas över till nästa sprint eller blir liggande för länge hos någon ena. på en gång kommer det flaggar som säger att det här behöver någon titta på.

Sen sagt vad det ska landa och så där om du ska använda oss som projektledare eller en spännmaster eller en agil coach eller en linjechef eller hur du nu ser ut. Det kan nog se lite olika ut men man vill ju få upp den informationen så att vi kan agera på den på ett vettigt sätt. Och det är där vi ser att det saknas den här mekanismen i styrningen av roadmap. Roadmast blir latenta placeringar, snarare än att det blir ett ständigt uppdaterat underlag över att prata om våra befinningar och sådant. Min liknelse med Roadmast brukar vara så här att om du ska segla över Atlanten då tar man liksom inte ut kursen sådär i Göteborgs hamn eller England eller om man startar, det är väl kanske Spanien de startar i det här programmet.

Och så tar man ut kursen och så surrar man roadrout, så går man och lägger sig i kojen och slaggar tills man är framme. Det krävs hela tiden anpassningar till avdrifter och sånt. Då blir det en konkret exempel att vi räknar med att producera artefakterna till det här tillfället. Vi ser att vi har producerat en tredjedel av det vi hade tänkt. Då är det osannolikt att vi kommer att bli klara enligt den ursprungligen tänkta övergripande tidplanen. Hur agerar vi på det?

Vad gör vi åt det? Då kan man göra en massa olika saker. Man kan tillföra resurser eller kanske plocka bort en mindre prioriterad projekt. Eller man kanske kan försöka idéer tillfära om det finns någon annan flask kalls någonstans som är förklaringen till varför saker inte fastnar. Och försöka elevera den på något sätt. Jag är ingen stor vän av att hälla in fler resurser.

Det brukar tendera att bli mer oreda än redan. Men det är klart att det ibland finns en situation där man behöver göra det. Det intressanta är när det är 70 procent som inte blir gjort, då blir det pris som du säger med de här formlerna och kunskap som finns att de där 70 procenten, de kommer ta kanske 30 procent av tiden att bara administrera och hantera. Så kan vi bara kapa dem så kommer vi få ut så otroligt mycket mer. Jätteintressant. Om man skulle lära sig mer av dig och ditt arbete eller få tag på dig, hur gör man då?

Ja, jag jobbar ju på företag som heter Onboard som sagt. Så där har vi lite information och så. Men framförallt är jag rätt aktiv på LinkedIn och jag gillar att folk knyter kontakt den vägen. Så det är jättekul om man vill höra av sådär. Och så där lägger jag ut lite saker då och så där och refererar till olika webinarer som jag håller. Vi lägger länken till ditt LinkedIn-konto eller jämntekningar till det här avsnittet.

Idag har vi lyssnat på flöden, förmågor och exekvering. Detta är detaljerat om hur man driver projekt och hur man kan se- att saker och ting inte går som man vill. Den som vill läsa mer om det här, det finns väldigt mycket gamla linböcker- som jag tycker fungerar väldigt bra även i it-sammanhang. Jag hör även att du har de tankarna. Stort tack för att du ville ta dig tid att vara med i Pseckardepodningen. Kul att du fick komma hit och slösa bort lite av din tid igen.