ProjektledarDetta är en maskinell transkribering (KB-Whisper) av avsnittet som publicerades 2020-12-04. Fel kan förekomma.
Lyssna på avsnittet: 12: Metoder, agilt, risker, roller och många fler tips från projektledningsförfattaren Bo Tonnquist Läs sammanfattningen: Agilt eller projekt? Bo Tönnquists vägledning genom projektledningens framtid (12)
Transkribering
Man kan göra den här tanke- experimenten. Man tänker sig att man ställer sig i slutet på projektet. Just när vi har levererat vårt resultat och fått det godkänt. Då tänker man så här, vad är det vi ska ha minst gjort? Den du hör är Botonqvist. Han berättar bland annat i dagens podd om hur viktigt det är med tydliga roller och riskhantering i projekt.
Jag som gör den här podden heter Mattias Ejbe. Och nu kör vi! Du lyssnar på Projektledarpodden. En podd för dig som gillar att leda projekt och vill lära dig mer av andra om projektledare. Idag har vi en projektledare, konsult, föreläsare och författare till den bästa svenska projektledningsboken med övningsbok, Bo Tornqvist, här. Välkommen!
Tack så mycket. Det ska bli spännande att få vara med på den här podden. Ja, du har ju skrivit fler böcker än den. Kan du berätta lite om vilka böcker du har skrivit? Jo, det kan jag gärna göra. Projektledningspoken, eller den som heter kortfattat projektledning, den har funnits ett tag.
Den har faktiskt 16 år på nacken och kommer ut med nya upplag med jämna mellanrum. Det kommer komma ut en ny version här vid årsskiftet som får rött omslag. Det är det som kommer uppe i våra skillnader. Men jag har också låtit den här, eller böckerna har blivit en hel familj. Nu har jag både de här projektledningsböckerna som vänder sig till…som läser på utbildningar, kurser ska certifiera sig och även till företag som behöver handböcker. Men så har jag också kommit ut med en bok som vänds mer till yrkeshögskolan som är lite lättare.
Och fokuserar mer på det enskilda projektet istället för projektledningsböckerna som kanske tittar mer på hela projektverksamheten. Och sen skrev jag en bok för chefer och ledningar för ett år sen där han försöker beskriva vad det är det ena och vad det är det andra när man pratar om projektbaserade verksamheter och agila flödesbaserade verksamheter. Så det var en mer managementbok som beskriver vad det ena och det andra är. Så det är ganska många böcker idag att hålla koll på och hålla liv i hela tiden men det är en väldigt kul sysselsättning.
Nämnde du Agila? Jag har nämnt det här boken, Agilt eller projekt. Men det agila har alltid funnits med i alla mina böcker, men det har haft lite mer eller mindre plats. Och det har med åren fått en mer fastare form. Där ser jag ganska tydligt att det är ju inte antingen eller. Det är inte antingen man jobbar med ett projekt eller man jobbar agilt, utan det är i de flesta fall både och. och det är en kombination och det är en mix av de arbetena.
För så fort man ska dra igång ett uppdrag som man kallar projekt, då behöver man en styrmodell. Sen är det ingenting som hindrar att man väljer arbetsmetoder som är agila inom ROM. Det här är någonting som faktiskt styrs ganska mycket av PMI. Om man får göra den vinklingen där. PMI gör ju om sina certifieringar utifrån årsskiftet. Från årsskiftet så ser jag deras PMP-certifieringen är annorlunda.
För de säger att om du vill certifiera som projektledare måste du kunna behärska flera metoder. Man förutsätter att man som projektledare både ska behärska det mer traditionella, klassiska projektmetodiken med tidplaner och kopplade aktiviteter. Man ska också kunna hantera agila arbetssätt och förstå när det passar det ena och andra. Så det är på något sätt, man är på väg mot en gemensam väg framåt tycker jag, där det inte handlar om antingen eller utan vilket är det bästa för det uppdraget och de förutsättningar vi har för stunden. Och du nämner orden metod, projektmetodik, styrmodell.
Kan du bara förklara hur du definierar dem här, för de används ju lite olika. Ja, de används olika. Styrmodell är egentligen är en, När man pratar om styrmodell i projektet så är det projektmodellen. Den heter jag om man skulle översätta det engelska namnet, Product Management Module, alltså det är projektledningsmodellen som är uppdelat i de flesta fall i ett antal faser med grindare emellan. Den är ju till för att skapa en styrning för hela projektet så att man verkligen vet att man siktar mot de önskade nyttorna syfterna som ligger efter projektet och styrmodellen är ju väldigt för mig också gränssnittet mellan det enskilda projektet och resten av verksamheten.
Och styrmodeller förutsätter ju oftast om man vill ha någon form av portföljstyrning i en organisation så behöver man en styrmodell och helt samma styrmodell för projektet. Om man pratar metoder och arbetssätt så är metoder ja det Det kan ju vara en metodiker hur man bryter ner ett projekt omfattning med VBS till exempel. eller att man gör en riskanalys med en miniriskmodell, det är metoder. Och sen arbetssätt, då är man mer kopplad med hur vi väljer att organisera och driva samarbetet in i projektgruppen eller i teamen. Där finns det olika arbetssätt att välja.
Jag upplever ibland att man blandar ihop de här olika nivåerna. Ja, det gör man. Man blandar ihop. Jag blir lika ledsen eller frustrerad varje gång när man jämför agila metoder med något som kallas vattenfallsmodellen. Då menar man projekt som använder en projektmodell och kanske har tidplaner, det kallar man för vattenfall. Då hävdar man att den är så styrd och den är så den är så inflexibel och allt det här och kan inte hantera fläckse ändringar och sådana saker medan så de här flexibla agila sätten och då pekar man till 90% på skram.
Så jämför man för mig en utvecklingsmetod med en styrmodell och det är jättekonstigt tycker jag. Jag får inte det riktigt gå ihop för det är egentligen två olika saker. Men de står ju inte emot varandra, utan det är mer att de kan jobba tillsammans om man bara medvetner om hur det fungerar. De står definitivt inte emot varandra, utan de kan komplettera varandra. Och i vissa sammanhang, beroende på förutsättningarna, både uppdraget förutsättningar, men framförallt de förutsättningar som finns hos det företaget och organisationen som ska driva utvecklingen, så passar kanske ett mer agilt förhållningssätt.
Och i andra fall så kanske det inte passar lika bra, utan ett mer styrt förhållningssätt. Men det har med ett antal förutsättningar idag. Du nämner ett antal olika projektmodeller här, eller att det finns att man ska veta när man ska använda vilken. Föredrar du någon, och kan du ge några exempel på när någonting passar bättre? För mig är ju… Det finns ju en jättestor mängd olika projektmodeller.
Det finns ett antal sådana här standardiserade eller licenserade modeller, typ PPS, XLPM, Payload, Prince och lite liknande. Som man då kan köpa en licens på så får man uppdateringar hela tiden i form av nya dokument och stöd med alla och sådana fall. Sen finns det jättemycket sådana här företags specifika modeller. Men om man tittar på nästan alla modeller med undantag av frinsk, så beskriver de samma sak. Så för mig spelar det absolut ingen roll vilket projektmodell man använder. De är i princip samma sak.
Det är bara att man är klar över vilka namn man har satt på olika begrepp. Det är det som skiljer. Jag har ingen direkt förkärlek för någon modell. Bara det följade logesam flöde att det finns en förstudie, att det finns en planering att genomföra någon form av avslut. Och att koppla till den är att det finns en beskrivning av roller med ansvar och befrorenheter. Så att man får det hela hänga ihop.
Sen kan den heta vad som helst. Det spelar med ingen roll. Du säger att det är lite skillnad mot Prins 2. Vad är det för skillnader? Ja, Prins 2 är lite större. Prins 2 ligger ju någonstans emellan en standard, typ PM-bok, amerikanska PM-bok eller ISO-standarden.
Den beskriver ju mycket mer, jag ser den mer som en stor verktygslåda, som beskriver processer, modeller, roller, olika saker på ett ganska övergripande sätt. och sedan upp till en själv att plocka ihop utifrån den hur jag vill bygga upp min styrmodell. Man kan ju licensera eller certifiera sig på print, vilket man kanske inte kan på en vanlig projektmodell. En projektmodell för mig, det är mer handgripig. Det är liksom att det är en flöde helt enkelt. Utan att nämna du företagsnamnen, har du sett något företag som verkligen har implementerat en projektmodell och använder den?
Eller är det som min erfarenhet är att man säger att man använder projektmodell och sen ser man det mer som en verktygslåda? Ja, det finns säkert jättemånga bra exempel. Jag kan inte… Jag vågar inte säga något rakt ut för jag har ju bara sett en begränsad del av olika företag och verksamheter. Men vad jag ser många gånger är ju att man har bestämt sig att vi ska ha den här modellen och så kör man igång mot större implementeringsprojekt. Och där stannar det tyvärr att så ofta.
De redan för äldsta som tycker att det här är en bra grej, som redan från början tyckte var bra grej, de använder det. Men de andra som har varit lite mer skeptiska och inte… förstått. Tycker det bara jobbigt att man ska lägga på ett ramverk och massa studieopplement. De kommer göra allt de kan för att slippa. Det här ser vi. Vi jobbar ju inom det bolaget som vi har varit med och dragit igång Baseline där vi jobbar med projektmoderns mätningar där vi använder då en metod eller som vi kallar SPI som vi har förkortat ned i Svensk projektindex som baseras på en engelsk mätmetod.
Man kan gå in och titta på vad tycker medarbetare, vad tycker chefer, vad tycker projektledare etc. om hur bra sitt företag eller organisation är på att hantera projekt som arbetsform. Och då finns det ett ramverk som internationaliseras hur man mäter det där. Men det är fortfarande självskattningsmätningar så allt bygger på vad jag som enskild medarbetare anser, tycker, ser. Men lägger man ihop det där, svar från många, då får man ofta en ganska bra bild. Och en sak som ofta kommer fram, det är lite det som du tog upp, det är just det här att man har vid några tillfälle bestämt sig att vi ska ha en metodik, men man följer den inte.
Det blir väldigt synligt på de här nätningarna. Och det är synd. För då missar man ju chansen att hitta någon form av gemensam språk som gör att det borde bli lite lättare att förstå varandra. Om man har samma begrepp, samma ordlista ungefär, om man kallar saker likadant och man vet att de projekt vi kör i gång följer ett huvudflöde som är hyfsat likt varandra. varandra. Då kan man ju också berätta det för varandra och då förstår man också om vad projekten är någonstans istället för att varje projekt. Hanteras på sitt sätt underlättar inte förvirringen om man säger så.
Erfarenhetsåtföring ser jag som nästan omöjligt att genomföra om man inte har en modell att följa upp i. Nej exakt. Visst det finns ju med nästan alla modeller någon form av erfarenhets återmatning men det är ju inte så himla lätt för dig att funka heller. Och jag vet att de flesta är ju glada att de är av med projektet. Och jag vet att du tycker det är väldigt viktigt med tydliga roller. Varför är det viktigt?
Ja, det har jag också att göra med det här med delat ansvaret, inget ansvar. Om det tydligt framgår, om jag säger att jag har fått förmånen att bli projektledare i ett projekt. Då är det ganska bra om jag vet vad det är som förväntas av mig. Vad är det viktigaste uppgiften? Vad kommer jag mäta sig mot hela tiden? Då brukar man säga att projektledande har det gärna sett till att resultatet uppnås.
Att man går i hamnen med projektet, helst inom önska tid och budget. Så det är det viktigaste, att mäta. Då är det ganska bra att koppla till det mandat. För ett ansvar utan mandat är ganska värdelöst. Om jag har tagit på mig ansvar att leverera ett projekt Med hjälp av de resurser som jag får låna. Då måste jag ju ha ett mandat att kunna inom projektets ramar få fatta vissa beslut och förfoga över vissa medel och budget.
Om jag inte får det då är det ju väldigt korkat att lova att leverera någonting. Så det hänger ihop. Många ställen där det brister, tyvärr är det ju nivån ovanför. Det är ju på beställarnivå. Att kompetensen på beställarnivån är tyvärr ganska låg, vilket gör att de flesta som kliver in i beställarrollen i projekt inte vet egentligen vad som förväntas av dem och vad de behöver göra för att de projekten de sitter som beställare för ska få rimliga förutsättningar. Och då liksom på något sätt siffrar ner hela vägen att det alltid blir otydligt.
Så det är någon roll som är viktig. Om man skulle säga den viktigaste rollen för mig, eller som jag tycker projektet är beställaren. Och hur får man beställaren förstå hur viktig den är och att den måste förstå det här? Ja, det är det som är så svårt. Du får sällan beställa att gå på kurser. För de har inte tid eller inte kan det, eller så vill de inte avslöja att man inte kan det.
Jag tror att det handlar om att koppla ihop beställarrollen med den som är ansvarig för det man kallar nyttorealiseringen eller effekthemtaganden efteråt. Det vet jag att organisationen som typ SE Banken för länge började med och även försäkringskassan för länge sedan när de hade deras projektkontor. Där gjorde man så att man såg till att den som kliver in och får projekt-ägarrollen, alltså beställaren, är också ansvarig för att säkerställa att Man följer upp och rapporterar nyttorna efteråt. På det sättet så fick man en lite mer rimlig nivå på det man lovade att projekten skulle göra.
Man var ju inte en skäl som skulle följa upp efteråt och rapportera upp till sin ledning i vad som verkligen hade blivit. Då framgår det väldigt tydligt om man har startat fel projekt eller man har startat projekt med felaktiga eller alldeles förluddiga förutsättningar. Det blev synligt på ett sätt. Så jag tror att det är viktigt att koppla ihop hela projektens mål och framförallt syften med verksamhetsmålen. Det är mycket tydligare på det här. Jag vet inte vad du har för erfarenhet av det här.
Vad då man ser vem som är ansvarig egentligen? Det är väl det som är tyvärr många gånger otydligt. Det finns för oss utsätt att bara vi har sett en projektledare och formulerat något form av mål och gett ett projektnummer. Då är halva problemet löst. Det är inte riktigt så. Det slår tillbaka på vad det är en riktig delegering.
Det är väldigt tydligt om man ser om ett Japanskt stort företag oavsett om det är Honda, Toyota, Sony eller vilka som helst. Om det händer någon skandal, om det blir problem på några produkter eller någonting att företaget någonstans för har man inte gjort rätt. Då står ju högst i chefen, till och med koncernchefen i tvn och blir de mer ursäkta när han gråter. För där har man ju fattat att den som sitter högst upp har ansvar för allting under. Som chef så ska ju jag, jag kan inte bara rekrytera medarbetare, jag måste också bedöma att de medarbetarna jag rekryterar och vill göra ett underchef, att de har rätt kompetens.
Och det är samma sak i ett projekt. Om jag ska utse någon till projektledare, då börjar jag ju checka upp att den här personen är kompetent. Och om jag missar det, det är inte den personens fel, så är det inte hon som har lurat mig. Men det är ju jag som har gjort en felbedömning. Så högst upp är man ansvarig för allting och så kan man liksom på något sätt delegera ner. Till slut kommer du till projektledaren och projektledaren i sin tur delegerar till projektmedlemmarna.
Och där måste det vara samma tydlighet också. Så du behöver ju hänga ihop och när det här blir otydligt vem som egentligen var ansvarig, Då blir det svårt att veta vem. Då kan man inte hänga någon om det går fel. Det är ju bra kanske, om man inte vill behänga. Det skapar ju en osäkerhet överallt. Det här är väl lite det som man kan, om man följer den allmänna debatten också kring stora saker som händer i samhället.
Just det här tydliga ansvaret för de som borde ta det är väl lite tveksamt. Och då kommer jag lätt in på teamet också, du nämner det här, hur viktigt är jag med alla de här rollerna? Ja. Vad tänker du kring projektteam, agila team? Jag tänker så här att frågan som jag ofta brukar ställa när jag är ute i företag, men även till kursdeltagare, de utbildningar som jag är med i ledare, har ni förutsättningar att skapa team? Och då säger vi att den har vi.
Sen går utifrån det igenom de bitar som jag tycker ett team ska innehålla. Man säger att teamet ska innehålla nödvändig kompetens. Man ska inte vara för många, man ska inte vara för få. Man får inte ändra sammansättningen i teamet för då helt plötsligt tappar man hela den här gruppprocessstrukturen. styrkan och då kan man inte vara självstyrande längre till att ända till att att man liksom ska faktiskt för att vi har ett valt team kunna lägga merparten av sin tid just på den uppgiften och inte hålla på med så mycket andra saker parallellt. Och det är där det faller många gånger för de flesta vet ju att nästan alla projekt som vi kör och jobbar ju med delade resurser Vilket innebär även man själv som projektledare Gör ett antal andra saker parallellt med projektet och man lägger oftast bara en mindre del av sin tid på projektet.
Så vidare man inte tillhör en stor utvecklingsorganisation inom Eriksson, SC Banken eller något större konsultföretag där vi jobbar med utveckling. Där kan man hitta det här permanenta. Men annars har man inte permanenta team utan man har i tillfället sammansatta grupper. Kan den tillfälligt sammansatta gruppen kännas som en samhörighet som man kan börja jobba med? Självstyrande eller självorganiserande som är en av nyckelbygdbitarna. enligt agila metodikens gram. Och då skulle jag vilja säga att de flesta skapar inte de förutsättningarna, vilket redan där faller många gånger.
Vi ger ju inte våra medarbetare möjlighet att föruttaget ingå och bli de här sammansvetsade effektiva teamen. Men ändå ska vi nu trycka på styrmodeller och arbetsstrukturer som förutsätter de här sammansvetsade teamen fast vi inte har dem. Och här tror jag att man biter sig i svansen jättemycket. Att man försöker införa ett sätt som många berättar. Det här är så flexibel, det är så bra. Vi behöver inte detaljplanera det, det sköter timers själva.
Men så har man inga tid. Man tror att man har det. Det här är det som många gånger jag blir mest upprörd kring. Att man går blindt bara sakta in i någonting som som ett nytt arbetssätt och tro att man blir frälst på det hela. När man själv inte skapar förutsättningarna. Så jag ser ett jätteproblem där.
För det är ju ännu viktigare med tydliga direktiv och tydlig delegering om man ska jobba med självstyrande team än om du jobbar med de här tillfälligt sammansatta grupperna som då har en projektledare som är där och kollar allting. För i de här teamen ska det inte vara en projektledare utan där ska hela teamet vara ansvarig för Resultatet medan i projektet så är projektledaren som ansvarig för resultatet. Så skippar man då projektledare. Vi behöver inte för teamen ska ta. Men man är dålig på att tydliggöra vad som ska göras utan man tror att teamen själva som kommer på det.
Nej. Och det här tror jag att man har missförfattat jättemycket. När man pratar om självstyrande eller självorganiserande till teamen. Att man tror att teamen själva ska kunna bestämma vad de ska göra. göra. Nej, det kan du inte, såväl inte de är ett eget team, ett eget bolag. Men de flesta ingår i ett större sammanhang så de kan inte bestämma själva.
Men de kan ju bestämma själva hur de ska göra saker, vem som ska göra vad, alltså hur de ska organisera och fördela arbetet. Men de kan inte få bestämma vad de ska göra. Så att införandet av ett mer agilt tänk och agila metoder kommer ställa ännu större krav på ledningen att vara tydlig. Så då kan vi inte ha en ledning och chef som abdikerar och bara delegerar ut allting och tror att det löser sig. Det funkar inte. Du har ju skrivit boken Agilt eller Projekt och jag antar att det här var en del av det behovet du såg.
Ja, det var ju det. Det var ju det som fick mig att skriva den boken för över ett år sedan. Det var ju att jag mötte ganska många, tycker jag, rätt så seniora personer som hade jobbat flera år i större organisationer som sa nu ska vi be Agila. Det har vår ledning sagt. Men ingen berättar hur det ska gå till och vad vi egentligen ska göra. Och det här mötte jag från flera håll och då inser jag att någonstans så är det slirare.
Och jag har ju mina egna idéer och teorier kring det hela och det är väl bland annat det här med att projektmetodiken, styrmodeller, Massa dokument med rubriket där man ska fylla i information om man ska rapportera och möta. Det känns väldigt tungt för många. Så kan man hitta ett arbetssätt som verkar lättare, mer flexibel och inte kräver all denna dokumentation och styrning. Tack för att man började bli nyfiken. Så då är det ju risk att man har övergärd sin studie och jag har sett flera som faktiskt har övergöt sin hela projektmetodik med styrning och med portföljhantering och gå in diagila.
Och som Sen har sagt efteråt, det har blivit total kaos hos oss. Vi har ingen kontroll längre på vad vi håller på med. Och det här gäller stora företag, stora ansedda internationellt och väldigt framgångsrika svenska företag som nu helt plötsligt befinner sig i en kaos när det gäller deras utveckling. Det här har jag hört från första källaren, hur det verkligen går till. Jag förstår att det inte är en stakafall utan det här ser jag på många ställen. Det kommer att kosta pengar.
Det kommer att kosta mycket annat också innan man hittar innan man backar tillbaka till gamla men innan man hittar ett förhållningssätt som ger den styrningen som det gamla metodiken skulle ha gett men man aldrig gav den chansen att ge. Och den här flexibiliteten som det nya kan ge. Jag tror att man överger gamla, det är därför att man aldrig har jobbat enligt det gamla. Man har sin projektmodell med sina allting men det är ingen som har förstått den eller brytt sig om att implementera den förut. De flesta har inte jobbat på det sättet utan man har sett det som något tungt och jobbigt som man inte har något hjälp på.
Man har ju ingen hjälp och stöd av det om man inte tillämpar det på avsett sätt. Så då kan man undra sig, vad dåligt på att jobba på det gamla sättet som man sa man skulle göra. Vad är det som säger att man kommer bli bättre på det nya? Jag är tveksam. Det låter jag väldigt negativt här säkert. Men jag är väldigt tveksam på att man helt plötsligt skulle bli jätteduktig. och disciplinera när man inte varit tidigare.
Hur skulle du rekommendera om du gick till något av de storföretagen nu, de sa det? Hjälp oss. Då skulle jag, när man utgår från första frågan, vad är det ni menar egentligen? Vad är det ni vill åstadkomma? Sen går man in och tittar på vilket man borde göra i vilket fall som helst. På vilket sätt skapas värde i organisationen?
Hur ser deras huvudprocesser ut där man skapar värdeförkunder? Och vilken arbetsmetod på vilket sätt stöder det bäst? Då kan man titta på hur jobbar man idag? Och vad är det man tycker inte fungerar idag? Om vi då tar exemplet att vi skapar en produkt i en enda av företaget, vi säljer den och implementerar den i en andra enda av företaget. För mig är projektledning och projektmetodiken ett arbetssätt.
Det är ett arbetssätt som är ett verktyg– –för att skapa de förändringar som du vill förändra. Det kan vara allt från att utveckla nya produkter till att göra förändringar i organisationen. Det är själva verktyget som ska leverera det här. Då är det tillbaka till att förstå projektets sammanhang. Vilket man är inne på i de här certifierande organisationerna också. Som projektledare räcker det inte med att du ska kunna enmetodika projektmodeller och leda och organisera.
Du måste förstå det sammanhanget som projektet finns inom. för att kunna bedöma om det du projektet du är satt att leda kommer att skapa någon nytta eller inte. Och om du bedömer att det inte skapar en nytta, då får du inte stoppa projektet, men då får du väl påtala till den som har beställt av dig. Hur står det? Jag tycker att mycket faller tillbaks till det här väldigt enkla saker som man pratade om när det gäller marknadsföring och sånt redan på 80-talet. Med en tydlig affärsidé så blir det ganska enkelt att prioritera och veta vad vi ska göra och inte göra.
Är det otydligt vår affärsidé? Jag brukar ofta i projektledningskursen börja med det. När jag pratar om projekt tillsammans här. Vad är det affärsidé och vilka tre komponenter består en affärsidé av? Då brukar det alltid bli lite diskussioner. Och så kommer upp våra att tjäna pengar.
Kommer upp våra produkter vi säljer och sånt. Vilket är intressant för det är nästan aldrig någon som förstår att det viktigaste i våra affärer är att förstå att det är vår målgrupp. Vilken är målgruppen? Vilka vänder vi oss till? Och vilka behov vill vi tillförställa oss målgruppen? Det är liksom kärnan för allting.
Och har man förstått det? Varför vi finns till? och vad är det vi vill hjälpa dem vi har identifierat i de som vi riktas till. Då kan man sedan börja formulera vad det är vi ska göra, vad ska vi erbjuda, vilka produkter ska vi ta fram. Och då, i det sammanhanget, kan man sedan börja prata om här kommer projekten in plötsligt. Projekten är de som ska leverera det som vi har bestämt på ett strategiskt nivå att vi ska göra. Projekt och projektledning handlar inte om att komma på smarta idéer.
Det är en genomförande kompetens, vilket kan låta lite tråkigt ibland. Det är en kompetens att det är bättre på att göra det vi har bestämt att vi ska göra eller vi vill göra. Det är hela vad projektmetodiken handlar om. Hitta ett metodiskt sätt att ta tag i definierade uppgift. Analysera förutsättningarna. Om vi fortfarande tror på det, ta fram en plan, genomföra, hantera en massa ändringar och saker.
Och sen så småning som möjligen leverera någonting. Och så stänger jag nu. Det är egentligen samma sak som den här kvalitetscykeln. PDC, om man säger plan, do check act. Fast vi kör den inte flera gånger utan vi kör den en gång. Och det är ju det det handlar om.
Är det otydligt i början, vad vi ska göra. Du rinner dig in i det och sätter sig på vad du planerar. Planera kan vi först göra när vi har lite bättre koll på vad vi ska göra. Och här kommer också det här grila in mycket många gånger tycker jag på ett ganska bra sätt att i vissa lägen samma kan vi inte få svar på alla frågor. Vi kan inte köra så lång förstudie så att vi utreda alla tänkbara scenarier och skriva en hundraprocent vatten till ett kravspes och ta fram en plan som inte kommer behöva ändras någonting. Det är orealistiskt.
Det är ingen som tror att det funkar. Det är en större eller mindre grad av osäkerhet. Om man vill titta på hur omfattande början i förstudier var, då bör man fråga sig vad vi behöver veta för att kunna börja planera. Det är det som styr hur mycket i förstudier. Och hur detaljerad plan vi ska ta fram, det styrs ju av vad det är det vi måste, vad måste våran planering Innehålla för att vi för ett tag ska kunna börja jobba Och sen har vi hela vägen till slutet. Och här tycker jag, och här kommer det Agila in, tycker jag i alla fall om man vill se mig jobba i de här Sprintar och de här sakerna, att det är ju ett arbetssätt som är Väldigt bra när det fortfarande råder ganska stor osäkerhet.
Vi har inte klart för oss exakt hur kravspesen eller hur funktionaliteten på det systemet eller eller det vi ska ta fram. Men vi kan inte vänta tills vi har bestämt alla detaljer. Vi måste börja jobba för annars kommer vi inte kunna möta någon dädla. Så då måste man veta vad måste vi ha koll på för att i taget kunna börja jobbet? Och vilka saker kan vi vänta och bet fatta beslut senare? Så det är ganska tilltalande det sättet, alltså grundtanken som till och med kommer Många gånger från Lyn, att fatta vad beslut om saker du måste.
Det är det du inte behöver fatta beslut om, vänta. Men man kan ju inte vänta hur länge som helst. Så det tankesättet tycker jag är jätte tilltalande, vilket innebär att du ska inte detaljplanera för mycket. Men du ska å andra sidan inte, du måste ändå ta fram någon form av grå övergripande roadmap, övergripande aktivitetsplan med saker som du vet behöver göras i en viss ordning för annars kommer ingenting funka. Det gäller kunskapen att förstå vad måste vi planera och vad måste vi göra i en viss ordning och när finns det deadlines för att visa saker.
Vilka saker kan vi faktiskt hantera på ett flexibel sätt. Så det är inte 100% antingen eller. Det är en mix i det här. Det är väl det som jag tror att De som är verkligen lyckosamma idag och framöver på att tillämpa det är att förstå de här bitarna. Att inte en metod kan lösa allting. Du kan inte planera till 100% allting.
Det finns inte en chans. Det kommer hända saker. Å andra sidan kan du inte starta helt utan en plan heller. Och säga att vi jobbar agilt, så vet du inte hur lång tid det kommer ta, vad det kommer kosta. Och vi tar fram användbara resultat i Biasprint. Men det gör man inte.
På fyra veckor kan du inte ta fram något du kan skicka till kund. Det handlar ju inte principligen om. Även om en del tror det. Du kan ta fram en viss funktionalitet som du sen kan lägga ihop med annat och skapa något. Som man på Ericsson kallar leveransobjekt. Tyvärr så tror jag att vi går just nu mot en riktning där vi har får mindre och mindre tid att verkligen Sätta oss ner och tänka igenom Vad vi ska göra Utan vi startar alldeles för snabbt idag med bristfälliga underlag Och man har en övertro till att en arbetssätt ska fixa en grundläggande analys.
Så där tror jag, men det kommer nog vända som småningom när man ser att det kostades för mycket. Så egentligen, alltså för korta perspektivet så ser jag tyvärr väldigt lite i att man skulle bli bättre. Och jag tror att det kan ha att göra med att de som representerar då med det traditionella, klassiska sättet, kanske har svårt att övertyga många yngre och de som då förespråkar de mer flexiva sättet varför det handlar är så bra. Och då kan det uppfattas som bakosträvande och tråkigt. Och många kanske inte då heller är tillräckligt öppna för det nya, men det är svårt att säga det.
Jag ser tyvärr inte att man tar det tillräckligt mycket på allvar där med projekten. Utan man kör igång förlöst. Projektet vet jag inte om. Places gamla projektplatsen, de gjorde ju någon undersökning i sin kunddatabas för ett par år sedan. Där man då i ett antal länder, jag tror var sex, ett par tusen svarande minst var det. Hur tillsätter vi ny projektledare?
Då kom det fram till att över hälften av projektledarna, tog till med två tredjedelar nästan, hade ingen utbildning eller certifieringar. Och 25% av de som hade blivit projektledare hade blivit emot sin vilja. Så på något sätt känns det inte helt seriöst hur man tar tag. Men då är det inte så konstigt att man tycker att en dålig arbetsmetod är det, eller? Jag tror att projekten har en jättejobb att göra, perjobb. Vad tycker du att en ny projektledare ska tänka på?
Vilka tips har du? Det är att lära sig en av de här modellerna, metodikerna, ganska ordentligt och sen bestämma sig för att vissa av de här metoderna, de ska alltid tillämpa till exempel att bryta ner projekten med VBS eller att säkerställa att jag gör en ordentlig intressant kartläggning innan jag börjar. Det finns ett antal sådana tycker jag som är De ger inte måste, men de ger väldigt mycket stöd och väldigt mycket hjälp. De får undvika många tråkiga situationer om man gör tidigt. Att man väldigt tidigt får klart för sig vad som ingår i mitt projekt och vad projektet inte ska göra och att man får det förankrat.
Det handlar väldigt mycket om sex. Att man hela tiden förankrar med beställare och hela tiden att det vi faktiskt tänker göra är det som de vill ha. och uppnå de effektmål man vill nå. Ja, visst är det så. Och det är inte projektet som levererar effektmålen. Nej. Projektet levererar ju bara förutsättningen för att det är effektmål.
Projektet levererar ett resultat som när det används, kanske, om man har tur, uppnår effektmålen. Om man har den insikt, om man förstår det, då förstår man att det här kommer att ske, själva effekthämtagningen ska ske efter projektet. Alltså kan inte projektledaren vara ansvarig för det. För projektledaren har redan slutat. Utan det är den som beställde som är ansvarig för det. Och du träffar ju många seniora projektledare.
Vad är det du ser att de skulle behöva utveckla och lära sig att tänka mer på? Jag blir ju…många gånger lite förvånad att…många seniora projektledare som uppenbarligen…har varit och är framgångsrika med att driva projekt…ändå… saknar kunskap om många av de här metoderna som finns inom projektmetodiken. Typ VBS, typ nätplan, alltså saker som innebär att de skulle kunna få fram mycket bättre tidplaner mycket enklare. Då kan jag tänka, de har ju lyckats ändå, så är det onödigt det som jag står och prudikar och pratar om med mina kollegor?
Nej, jag tror inte det är onödigt, för jag tror att de här personerna framgångsvika, de skulle kunna bli ännu mer framgångsvika. och då hade de med sig den här förståelsen för verktygslådan. Det är en verktygslåda. Att många projekt lyckas beror inte på att man har en bra projektmetodik som är förgankad i organisationen. Det beror på att man har eldsjälar. Alltså personer, individer som är jätteduktiga. Det är personer som skulle kunna lyckas i vilket sammanhang som helst.
De på något sätt i sitt skicklighet, sin drift och allt de har lyckas kompensera för den organisationens oförmåga som man är verksam inom. Så ger de ännu lite bättre redskap i ett ordet då skulle man kunna spara de här 30 procenten som vi idag kastar bort i snitt i varje projekt. I kvalitetsbristkostnader. För mellan 25 och 30 procent utan problem skulle man kunna spara i projekten. Och vilka vanliga misstag ser du då? Det är att man inte lär av sina misstag.
Man gör om samma typ av fel varje gång. Man har inte fått till den här mekanismen att när man avslutar ett projekt att man gör en utvärdering. Att man gör en lesson learned. Och att sedan ha en mekanism i organisationen där man återmatar den kunskapen in till andra nya projekt. Utan den kunskapen, det man lärde sig försvann med det projektet. Och sen när de gör projekt så jobbar de om samma sak.
Man är alltså inte en sån här lärandeorganisation. Man kanske inte vill påvisa sina misstag? Det kan det mycket väl vara. Och det kan ju vara så himla jobbigt som man är glad på om man blir av med projektet också. Jag tycker ingen vill höra talas om det. Nej visst är det så.
Har du själv gjort några misstag som projektledare? Ja det kan man säga. Ja det har varit lite… när jag själv var projektledare för massa år sedan, då skulle jag nog inte stått och undervisat och föreläsa i projektledning så mycket som jag gjorde. Då skulle jag nog vara projektledare. Det handlar så enkelt om att intressenter och kommunikation. Att inte förstå vilka som var de riktiga intressenterna till projektet och som verkligen jag hade behövt hantera på ett annat sätt.
Kan du beskriva närmare? Det är lätt om man inte förstår vilka som tycker att de behöver ha information från mitt projekt. Vilka som påverkas både i positiv och negativ riktning av att just mitt projekt får starta. För då kanske inte deras projekt fick starta. Då går resurserna till mig istället för till dem. Eller så finns det en intern maktkamp som ligger kanske på nivån ovanför.
Där man står och motarbetar varandra i samma organisator. För olika principiella preciskäl. Och att inte förstå den mekanismen, den politiska verklighet som finns kring projekten. Det gör det väldigt lätt att som projektledare tuffa på och tycka att det räcker. Det är det jag gjorde som unga och är oerfaren. Då tuffar man på att göra det man tror att man har blivit tillsagd att göra.
Och är ganska okänslig för att förstå det här spelet utanför. Och på det sättet lyckades jag göra mig ganska mycket ovän med några personer. Jag tyckte inte att de hade någonting med mitt projekt att göra, men det hade de tyckte jag. Så det är alltså, ja, man kle på tår som man inte visste. Så det är också en bra roll. Gör en intressant kartläggning så snabbt som möjligt. identifiera vilka som du tror kommer vara positiva för det ska göra och vilka som ser det som ett hot eller på något sätt ser det negativt som du ska göra.
Tycker du så viktigt att senare delen du säger det här också, vilka är det som är ett hot mot projektet? Och varför? Så man kan agera även mot dem. Ja, och det är ju inte logiska skäl, utan det kan vara en massa andra saker som spelar in. Och du sitter ju väldigt lös i rollen som projektledare. Så det krävs ju inte mycket för att någon skulle vilja bryta ut det om de inte gillar det.
En del av riskhanteringen är ju även intressentanalysen och att få koll på vilka risker vi har runt omkring. Ser du några som jobbar bra med projektrisker? Jag vet att han som blev… John Skollum var normaren, tyvärr är han död, men han jobbade på SAS för 10-15 år sedan. och bland annat med drog det stora projektet när man då skulle introducera de nya Airbus-maskinerna. Kabel Rebul då utsedd då året efter som årets projektledare av Svensk Projektorum. Och vad han lyfte fram som ett av hans absolut viktigaste verktyg det var riskhantering.
Att hela tiden hålla den uppdaterad, att ha mer riskanalyser på varje projektmöte, på varje styrgubbsmöte. När man hela tiden gick igenom, var det något som förändrats? Ska vi ta bort något, lägga till saker? Ska vi värdera om? Att hela tiden jobba med det som verktyg. Det tror jag också att det var någon artikel för något år sedan i någon sån här amerikansk management-tidning där man hade intervjuat ett antal stora amerikaner.
Eller amerikaner, chefer på stora amerikanska bolag. Vad som var också det här med nyckelfaktorer, alltså framgångsfaktorer i projekt. också kom fram till någon form av gemensam ståndpluk. Det var risk management. Har man koll på det hela tiden? Inte bara att det som gör en riskanalys vid ett tillfälle där man identifierar saker och sätter sannolikheter och konsekvenser på det och gör några åtgärder kanske, utan att man ser till att det här är någonting som är levande. Det här måste vi jobba med hela tiden.
Samma sak som planering gör man inte bara planering utan planering gör man under hela projekten. Fast man omplanerar. Jag ser ofta att det blandas ihop vad som är projektrisker och när man tar fram risker. Ja, det kan ju vara bra att man gör någon form av kategorisering. Att man delar upp. Och vem har ansvaret för att ha koll på vilka.
Jag brukar framhävda att man bör göra en nuläge analys tidigt i projekten där man gräver fram förutsättningarna och där man kan identifiera svagheter och hot till exempel och svagheter och hot det är saker som är konkreta, det är saker som finns som existerar, i och med att det är en nulägesanalys de svagheterna och hoten kan sedan leda till risker om de inte hanteras, om man inte gör någonting Men man kan aldrig flytta på ett hot. Och du kan eliminera svaghet genom att bli bättre på någonting. Men man blandar ihop risker och hot. Och det är samma sak som man blandar ihop egna instyrkor och externa möjligheter.
Ja, en riktig svårt analys. Det är för taget att jobba med de här verktygen. I början av projektet så borde man göra en risk-möjlighetsanalys. Om man tittar på olika tänkbara lösningsförslag, då tittar man på vilka möjligheter och vilka risker det innebär för projektet. Det är ganska naturligt att man gör det. Det gör man egentligen i alla beslutsituationer, men att man också gjorde det lite mer strukturerat.
Om man väl valt Lösning B av ABC, då gör man en nulägesanalys kring Lösning B. Vad är ni förutsättningarna kring den? Och sen så småningom så kommer det bli en riskanalys. Så det finns ett antal pusselbitar som har en viss koppling till varandra. Med det sättet att jobba som du och jag tänker, så när ska man egentligen börja jobba? Ja, det är en bra fråga.
Det är väl också att titta på, det kommer tillbaka lite här med att vilka saker kan vi börja jobba med tidigt? Utan att ha liksom hela situationen, hela problemställningen, alla krav utredda. Det kan man ju börja med tidigare. Men man kan inte börja jobba när det fortfarande är ett antal grundläggande faktorer som fortfarande är okända eller oklara. För då är det ju ett jättestor risk att man måste göra om. Det finns ju några som säger att man ser den amerikanska modellen och den japanska modellen och den amerikanska då behöver vi jobba igen direkt.
Och så gör vi om ett antal gånger. Japanska då väntar vi länge. Och analyserar och tittar. Och så gör vi det en gång. Och då går det ganska fort. Det är ju väldigt generaliserande.
Men själva genomförandet i projekten behöver vi inte ta så lång tid. om vi hade gjort ett bättre förarbete och om vi fick lite mer resurser samtidigt. Istället för att dra ut projekten så långt, för att de som ska ha mer projekt ska hålla på med så mycket andra saker samtidigt. Jag tror man ska tjäna jättemycket på att effektivt korta ner. Men det förutsätter ju att man vågar investera, att man vågar satsa och vågar avstå att göra andra saker. Vilket är liksom grunden i all prioritering. Det är ju inte att göra en lista av vilken ordning vi ska göra saker utan det är ju att bestämma vad vi inte ska göra.
Jag tycker man har sett när man jobbar med portföljehantering att det är det som är det svåra, att det blir tydliggjort och att vi inte kommer hinna med allting. Det är inte alltid ledningen vill se det. Nej, då måste ju någon, tycker man, någon borde ha den kuraget att fatta beslut vad det ska vi inte göra. Om man inte kan välja bort någonting, då kommer man att ha identifierat att vi inte har resurser för att göra allting. Då kan man ju inte tro något annat än att det blir problem. Det är ju bara önsketänkande.
Men vi kan ju försöka. vilken försöken. Och så någonstans så kommer det inte bli bra. Ja, en value var någonting som var uppe för nu ett antal år sedan och lite poppis och sen har man inte hört så mycket. Vad säger du om det? Jag tycker att det är en jättebra metod att visualisera och sätta värden på vad avvikelser tidigt i projektet kommer att leda till längre fram. Så själva tanken, metodiken är jättebra.
Men jag har inte sett särskilt många bra tillämpningar på det. För det förutsätter ju också att du har planerat projektet till en viss grad och framför allt att du har tydliga delleveranser i projektet som du går och mäter. Har du inte det då är det väldigt svårt att jobba med den metodiken. Men grundidén och den information, den ger det jättebra. Men det förutsätter ju då att du har koll, ganska bra koll på projekten från början. I många exempel så är det ju en målare som ska måla fyra väggar.
Det blir väldigt enkelt då. Ja exakt, det blir väldigt enkelt. Och så enkelt är det ju inte de flesta projekten. Framförallt inte när du har en sån där mjukvaruutveckling eller systemutveckling där du inte ser resultaten när de sitter och hackar kod. Om du inte kan få fram testobjekter lika gärna. Det är mycket svårare.
Och de flesta projekt, eller väldigt många projekt som genomförs i företag och organisationer i Sverige, det är ju projekt där man bara sitter i möten och pratar. Och så kommer man fram till saker som man inte planerar. Man kan inte veta hur lång tid det ska vara. Och så sitter man och pratar tills vi har kommit fram till någonting som är användbart. Det är mycket lättare att använda den här metodiken på fysiska projekt som handlar om att bygga saker. Det ser man i grejen.
Kan vi överens om att alla projekt skulle gå mycket bättre om man följde dina böcker? Ja, det kan man vara överens om. Hur ska man då hinna med allting du beskriver, att man borde göra? Jag tror att man kan tänka, vad man ska göra, det är att ställa sig i den här frågan, vad är det minsta vi måste göra för att kunna leverera kvalitet? Och då kan man göra den här tankeexperimenten, att man ställer sig, man tänker sig att man ställer sig i slutet på projektet. Just när vi har levererat vårt resultat och fått det godkänt.
Vad är det vi ska ha minst gjort för att det här ska kunna ske? Ja, vi måste ha utvecklat någonting och vi måste ha överlämnat och fått det godkänt. Och det ska ha testats. Vad krävs för att vi ska kunna utveckla de här sakerna? Då får man en insikt om vad kravspressen är och så steg man baklängelse på det sättet. Om man gör på det sättet fokuserar man mer på det absolut viktigaste.
I stället för att vända på det framifrån. Om man går framifrån kan man rösta på hur mycket bra att ha saker som helst. Om man ställer sig i slutet och gör någon form av backcasting på allting. Då kan man mer fokusera på vad det absolut viktigaste måste göras. för att vi skulle göra det här så att vi kommer att mäta och titta på sådana saker. Då tror jag att man kan få en bättre fokus. Och i alla fall öppna upp för en dialog om vad som är nödvändigt och vad som inte är nödvändigt.
Om man vill komma i kontakt med dig, hur gör man då? Om man vill komma i kontakt med mig, det enklaste är nog att googla på mitt namn. Då poppar det upp en antal länkar och det är det lättaste, tror jag. Tack för alla de tips vi har fått idag, den här genomgången. Jag hoppas kunna få återkomma till dig vid ett senare tillfälle. Det är massor med kunskap.
Jag tycker som sagt att din bokprojektledning med den arbetsboken som finns är det bästa man kan ha när man utbildar idag. Stort tack för att du kunde ta dig tiden idag. Tack så hemskt mycket Mattias att du kom med och dela lite av mina erfarenheter. Och jag tycker att det är mycket intressanta frågor. Och som sagt, vad jag jättegärna med någon gång i framtiden också. 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.