Transkribering: Projektledning och magkänsla - Tommy Olin berättar om (avsnitt 56)

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

Lyssna på avsnittet: 56: Projektledning och magkänsla - Tommy Olin berättar om Läs sammanfattningen: Vinnells projektmodell – Balans mellan struktur och flexibilitet (56)

Transkribering

Jag och en till var praktiserande projektledare. Och så sa jag, jag tycker vi ska ha den här frågan. Vad är projektledarens gut feeling? Alltså magkänsla. Och då skrattade alla. Utom den andra praktiserande projektledaren.

Då sa han, det var en bra fråga. Va? Vad menar du? Så kan man ju inte fråga. Jo, så gör det. Det kan man ju fråga.

För om projektledare inte tror på det här projektet. Tror ni att det kommer lyckas då? Nä. Antingen är det fel på projektet eller så är det fel på projektledaren. Så är det den viktigaste frågan vi har. Den du hör prata är Tommy Olin.

I dagens avsnitt berättar han om Venell’s projektmodell och framför allt om vad de försöker lösa med den. Dagens avsnitt sponsras av kursen Så använder du AI som projektledare. Daniel från avsnitt 50 och jag som har kursen är riktigt stolta över att ha 4,9 i genomsnittspetyg från alla de kursen överhållit. Om du vill gå den så gå in på Projektledarpodden.se-ai. Men nu kör vi! Du lyssnar på Projektledarpodden.

En podd för dig som gillar att leda projekt- och vill lära dig mer av andra om projektledning. I dag har vi med oss Tommy Olin. Han kan väldigt mycket om projektledning och ledarskap. Han är civilinjör i datateknik. Han är disputerad med en special riktning på projektledning. Han är certifierad, Prins 2, allt sånt där.

Scrum, Agile Master, Safe, Agilist. Det finns nog ingenting vi inte kan fråga och hålla om idag. Så välkommen till podden, Tommy Olin. Tackar så mycket. Det är trevligt att vara här. Ja, vi har haft ett tag när jag ville ha dig med här, men nu har du äntligen kommit.

Så det är kanonbra. Jag vill ju prata om Vinnels projektmodell, där jag vill prata mycket. Men om vi börjar där, kan du ge oss en liten översikt över vad ni har för projektmodell? Och kanske berätta lite om Vinella också på den delen. Det blir väl bra. Projektmodellen är en viktig del i vår verksamhet.

Den bygger ju på internationella standarder, ISO, PMI, HIPMA. Men det vi har gjort och som vi har sett är framgången med den här modellen– –är att den är så enkel och tydlig. Vi har… Einstein sa en gång, gör det så enkelt som möjligt, men inte enklare. Det ligger mycket i det, för vi har med allt som måste vara med. I Adyert brukar man prata om must-go-prioritering, alltså vilka must finns.

De finns med här. Men vi har försökt skala bort… I den grundversionen har vi skalat bort allt som inte måste vara med. Det blir lätt att komma igång, det är lätt att förstå. Sen är den skalbar och man kan bygga på den med kundspecifika saker som behövs. Då kopplar den till de befintliga processerna som finns hos kunderna.

En gång i tiden startade Tobias Vennel Management 67. Han var med och jobbade med Ericsson och tog fram Propp och den modellen. Men han insåg till slut att det inte finns så många jättestora bolag. Det finns väldigt många mindre bolag som har nytta av en enklare modell. Därför tog vi fram en egen modell som vi använder nu. Behövs det verkligen en modell till?

Det måste finnas nån annan som har tagit fram den i hela världen. Det finns ju hur många modell som helst. Det är fråga, behövs det en modell till? Vi tycker ju det. Därför att vi tycker att med tiden blir de flesta modellerna mer och mer komplicerade. Man lägger till, man kommer, ja, men det här måste vara med, och det här måste vara med.

Men måste du verkligen ha med det? Eller är det så att vi kanske bör ha med det, eller till och med är det bra att ha? Och vi försöker att hålla oss till det här, ja, men det här är måste. Och de ska vara med då. Så det kan man alltid frågasätta då. Och det är som du säger, det finns ju jättemånga olika modeller.

Och modellen i sig är ju inget rocket science egentligen. Det finns ju många standarder och de är väldigt lika varandra. Hemligheten är att man använder den. Där ser vi att, i och med att den är så enkel, så använder man den. Hur hjälper er modell att skapa balansen mellan styrning och enkelhet? Det finns alla de här måste.

Vi har de här olika faserna. Vi har grindar, vi har milstolpar. Vi har hela flödesbilden. Vi har tydliga befogenheter och ansvar tillkopplat till alla roller. Det finns en verktygslåda, och verktyg är inte hammare och skrubmejsel. Det är inte it-verktyg, utan det är tekniker.

Hur gör jag en intressenta analys? Hur gör jag en riskanalys? Det finns beskrivet och korta checklister som man övar på när vi håller kurs. Och så finns det dokument. Det gör ju att du får strukturen, men det lämnar också väldigt mycket fritt bild. Du har ju tre varianter, uppgift, uppdrag och projekt.

Men om du skulle guida oss igenom en ny projektledare som du ska göra en introduktion på i fem minuter. Stegen i projektmodellen och kanske vad som skiljer sig mot props eller någon annan känd modell. Men framför allt de här stegen så att man kan lära sig någonting. Vad är det ni har tänkt på från början av projekt ända till slutet? Det stämmer, som du säger, att den är skalbar. Och tittar vi på projekt som är det stora, eller det större.

Det måste inte vara jättestort, men där har vi alla fasen och alla grindarna. Och det finns, alla modeller har olika antal faser och grindar, men standard brukar det vara att du har någon slags förstudie, du har en förberedelse, planeringsfas, du har ett genomförare, du har ett avslut. Det har vi här när man använder projektmodellen eller projektgränssnittet. Om man väljer att göra ett uppdrag som ett lite mindre projekt, då bakar vi upp förstudien och förbrydelsen. Man separerar inte det med någon formell grindare. Vi har också genomförande avslut som en fas.

Man tar bort några grindar för att göra det mindre formellt och göra det enklare. och göra det här. Har man då uppgifter som är det minsta, då finns det inga grindar alls, alltså formella grindar, utan då har man en dialog mellan uppgiftbeställaren och uppgiftsledaren. Det handlar ju om att det är olika komplexitet i projekten. Hur mäter man komplexiteten då och hur bestämmer man sig? Ja, det är en väldigt intressant fråga och det finns inget svar. Jo, det finns ett svar naturligtvis.

Det beror på. Så där har vi då en liten guide i våra modell också när vi implementerar hos kunderna. Hur ska man ta fram den här? Hur ska vi avgöra om det är ett projekt, ett uppdrag eller en uppgift? En kund till oss. Vi höll på i över två år och försöka få fram ett Excel formulär, alltså ett frågeformulär med Excel i Excel som som automatiskt talar om vad det var för någonting.

Men det funkar liksom inte. Det är inte så så enkelt, utan det handlar om vilken projektmognad har organisationen, storlek på projektet och hur mäter du storlek? Är det är det pengar eller är det arbetstimmar eller är det antalet inblandade? Det brukar säga att komplexiteten kommer med antal kommunikationsvägar. För det är, även om du har det mest avancerade forskningsprojektet, det är jättesvårt, stora tekniska utmaningar, så är det kommunikationen som är avgörande för hur du ska lyckas eller inte. Så att ju mer kommunikationsvägar du har, desto större, eller mer komplext är projektet och då behöver du också använda projektmodellen till större del så att ta mer stöd i den.

Det finns inget rakt svar, men antal personer och intressenter som är involverade ger en liten guidning. Kan du ge några exempel på en projekt, verkliga eller någonting du hittar på här nu? Jo, men som jag sa, det beror lite på hur projektmogen organisationen är. Men att ta fram en ny produkt från början är definitivt ett projekt. uppgradera en produkt, det kanske är ett uppdrag. Men lite beroende på hur mogen organisationen är. Jag jobbade jättemånga år på Ericsson.

Där var det många stora projekt. Jag blev headhunted till ett annat bolag och så satt vi där och pratade. Just nu har jag ett ganska litet projekt. Det är kanske 15 personer, 30 miljoner. Det är en liten grej. Hela det företagets R&D-budget var 22 miljoner.

Allting är relativt. Men grunden och botten är densamma. Men utveckla en ny produkt är naturligtvis ett projekt att uppdatera. Det kanske är ett uppdrag. Att ordna julfesten kan också vara ett uppdrag. Vi är några stycken här på bolaget och chefen har sagt att vi får ordna en julfest här.

Då behöver man lite struktur och så vidare. Medan uppgift är att det har kommit en ny lag här så vi behöver uppdatera de här mallarna eller de här instruktionerna. Det är fortfarande ett projektarbete, för det är inget som jag brukar göra till vardags. Även om jag gör det så är det alltid unikt vad som händer nu med den här lagen och vilka berörs av den och så vidare. Ja, men lite så. Jag har varit med och tvingat in motsvarande uppgift i vanliga projektmodeller för att behovet finns oftast hos uppdragsgivarna.

Ja, men det är precis det. Det som är uppgift i en organisation kanske är uppdrag eller till och med projekt i en annan organisation. Det behöver alltid skräddasys. Hur fungerar det då med ett program eller där det pågår projekt som påverkar varandra inom samma organisation? Finns det i den här modellen eller ligger det utanför? Just programtänket ligger utanför.

Men om du tänker att du har ett större projekt som består av delprojekt så kan du mycket väl använda vår projektmodell som den är. För då har du det på olika nivåer. Så huvudprojektet använder projektmodellen som den är. Och istället för att man då pratar om arbetsuppgifter så är det delprojekten som man styr och leder och synkroniserar. Medan varje delprojekt då, men där har du som består av olika team Då använder de tänket i sin verksamhet och så blir huvudprojektet beställaren. Så det är väldigt skalbart på det sättet.

Men just när det kommer till program, för då har du projekt som kanske inte har så mycket beröringar förutom att de har ett gemensamt effektmål. Och då krävs det lite annat. Det finns inte med i grundversionen, men det har vi också. Och jag vill säga att Vinell sponsrar inte den här podden. Det är jag mer intresserad av. Är du intresserad av hur olika modeller funkar och det ni har gjort genom att skala ner nånting?

Är det nånting ni har lagt till som inte finns i vanliga modeller, eller är det bara att ni har skalat ner? Nej, jag vet inte om det är nåt unikt som vi har lagt till. Men vi trycker väldigt mycket på att det är kommunikation. Det handlar om människor. Tittar man på historiken, hur projektledning har utvecklats, rent som en vetenskap eller som en egen disciplin, så för drygt hundra år sedan så fanns det inte. Daniel Defoe, som skrev, Robinson Kruse skrev en essay på en project.

Man kan ana likhet i det. För ungefär 100 år sen kom Henry Gant med sitt planering och uppföljning. Henri Fayol tog fram fem discipliner för hur man ska driva ett bolag. Det är väldigt applicerbart på ett projekt. Sen utvecklades det. Det var mycket fokus på struktur, struktur, struktur.

Projektet blev större. Manhattanprojektet, som man initierade 1942, var 130 000 människor. i tre olika länder. Ja, det krävde sin struktur. Men det har kommit en också på att det inte räcker för det är människor. Vi måste ha den här mjuka sidan och kommunikationen är så avgörande. Så det som är unikt kanske inte är själva modellen, utan det är vårt synsätt just på att du måste kombinera modellen med ett handhavande och du måste kombinera metodiken och ledarskapet.

Sen har vi också inkluderat mycket agila influenser, vilket också är en naturlig del. Du nämnde att jag är disputerad och avhandlingen heter Managereal Techniques for Flexibility and Structure in your Product Development. Jättelång titel. Hade jag skrivit den några år senare, hade jag hetat Agile. Jag skrev den lite för tidigt. Men det handlar ju om att de här agila principerna, att du öppnar upp för mer flexibilitet eller du är beredd på förändringar eller att du är beredd på att ta olika vägar.

Där har vi lagt mycket krut på att få in det på ett enkelt sätt, utan att det ska vara rent agilt eller rent vattenfall. Hur får man människor att kommunicera med varandra via en modell? Det gör man inte. Då måste det gå utbildning. I modellen finns det också de här verktygen som vi pratar om. Man trycker mycket på det.

Det är kanske det som är den största aha-upplevelsen. Det hjälper inte att vi har all strukturen på plats. Om vi missförstår varandra blir det fel. Berätta om några verktyg så våra lyssnare får tips och tricks. Jag tittar faktiskt och gör en effektutvärdering. de som går vår utbildning. Efter två år frågar vi vad de har haft för nytta av det.

Det verktyget eller den tekniken de använder mest är faktiskt just projektmöten. Alltså att man får effektfulla, inte bara effektiva, för de kan vara jätteeffektiva. Men det ska ju bli effekt av dem också. Det och planering, det är väl det som sticker ut så att säga. Och då finns det olika sätt att planera. Du kan ha riktiga Gantt-scheman, milstolpeplaner eller aktivitetslistor.

Det varierar. Aktivitetslistan är en uppskattad sak för individen. Men för projektet behöver man nog mer Gantt-schemat. I er modell nämner ni nånting som heter målstyd eller målsökande. Berätta lite mer om det här. Ja, det är ett nytt, ska jag inte säga, men relativt nytt begrepp.

Två forskare, Svenska Carbo och Mahalin, som skrev artiklar och en bok om det här med målstyd och målsökande. Jag tyckte det var så bra när de skrev det här, för det är lite det som min avhandling handlar om också. Hela den energila rörelsen handlar om att från början trodde vi att allt var målstyrt. Vi kunde skriva det perfekta spesen, ta fram de perfekta målen, ta fram en perfekt plan och så följer vi den. Ju färre avsteg desto bättre är vi. Det funkar inte.

Därför att vi oftast inte vet vad målet är. Vi kan tro att vi vet det men vi vet inte. Det finns en studie från 90-talet där man visar att cirka 45 % av alla funktioner i IT-produkter används inte. Det är waste. Varför blir det så? De två största orsakerna var att vi inte förstod behovet när vi startade.

Och det andra var förutsättningarna förändrade sig under projektets gång. Har man det med sig, att vi vet inte allt och det kommer att förändras under projektets gång, då är det kanske dömt att ha målstyrt. Men då får man ha målsökande. Man får vara lite mygg och säga att nu tror vi att målen ser ut så här. Men vi behöver faktiskt forma målen under projektets gång också. Så det trycker vi jättemycket på i den senaste versionen här.

Det tror jag är jätteviktigt. Många projekt har fallerat för att man tror att det är målstyrt, fast det är målsökande. Hur hanterar man då att omfattningen av projektet helt ökar när man har rörligt mål? Det är en risk att omfattningen ökar. Det har alltid varit en risk även när man hade målstyda projekt. Det kommer till saker hela tiden.

Så lägger man på och så lägger man på. Jag tror att hemligheten här och tricket med målstyda är att du inte ska lägga till. du ska förändra. Och måste du lägga till en funktion, då får du ta bort en annan funktion. Och tittar man tillbaks på den här studien då, där 45% är waste av det vi trodde från början, så ja, det är klart att vissa saker kan skopas ut och så skopar vi in andra saker. Det är jätteviktigt där med scope creep. Det får inte scope change, ja, men inte scope creep.

För då är det okontrollerat. Där är hemligheten att ha kontroll över förändringen hela tiden. Det är hela den agila rörelsen. Du bestämmer en massa saker i början, men du bestämmer inte allt i början. Du låter det vara öppet. Bygger jag ett nytt hus.

Jag vet ju vad trappuppgången är. Jag vet vad hissarna är. Jag vet var vatten och avlopp går någonstans. Men jag behöver inte planera våning sex i detalj. Utan jag kan vänta tills jag får en hyresgäst. Och så kan vi tillsammans planera den.

Medan huset håller på att byggas. Så det är ju hemligheten där. Det målstyrda blir det. Vi vet ungefär vad vi vill ha men vi har inte alla detaljer utan de bygger vi på efterhand. Hur övertygar du en styrgrupp om att det är ett helt bra sätt att jobba? Det är en utmaning.

Det är ju så, det säger ju den agila rörelsen också. Har du inte en beställare som har det här mindsetet, då är det en riktig uppförspacke. Det är samma kund som inte förstår att ska man jobba agilt så kräver det jättemycket av kunden. För de måste engagera sig i projektet och kan inte bara sitta och vänta på att det ska komma ett resultat. Så det är en utmaning. Jag har ingen bra svar på hur man hanterar det, mer än att dialog, kommunikation.

Och ekonomi, har du den låst även i den här typen av projekt? Eller hur tänker du? Tittar man på grundtanken i De Agila, så traditionellt sett så låser vi ju projektmålen, och sen låter vi tid och pengar variera för att nå de målen. I De Agila brukar man säga att nu vänder vi det upp och ner. Vi låser tid och kostnad. Det får kosta så här mycket och det ska vara klart.

Sen blir det vad det blir. Där kan man fundera på hur man övertygar en beställare, kund eller styrgrupp för hur det går. Men det funkar ofta väldigt bra. Med tanke på att 45 % av det vi tror i början kanske är waste, då är det ganska sunt egentligen. Det finns en skola som säger att du låser tid och kostnad och så blir det vad det blir. Sen finns det en skola som är mer ödmjuk och säger att vi har en tidplan och budget.

Vi har ett mål. som är väldigt rörligt, skulle det vara så att man kommer på att oj, vi behöver spräcka tid och kostnad. Därför att nu har vi insett omfattningen av hela det här scoopet. Då får man ju ta det. Men då blir det ju ett nytt beslut därför att jag tycker fördelen med att man använder projektmetodiken det är ju att vi har en ram, vi sätter en ram för projekter från början. Vi har en tidsfrån, vi har en budget, det finns en viss flexibilitet. Men ser vi att vi spränger detta, då är det inte upp till projektet.

Då måste vi lyfta till beställaren eller hela vägen upp till ledningen och säga att oj, det här kommer att kosta mer eller det kommer att ta längre tid. Hur ska vi göra? Därför är det jättemånga exempel, inte nu senast i våras på Eredenhopp, utan förra gången var Eredenhopp en forskarkonferensförprojekt. Där hade man tittat på projekt som faktiskt har sprängt både tid och kostnad, men ändå anses vara jättelyckade. Därför att man under resans gång har kommit på att vi måste göra det här, annars blir det inte bra. Man kunde ju kört vidare med den fasta kostnaden och tidplanen, men då hade man inte fått det resultat som verkligen ger effekt.

Så det är en balansgång mellan vad det får kosta i tid och pengar och vad vi faktiskt vill få för effekt. Och om man är ny som projektledare, hur ska man då tänka kring den här balansgången? Ja, jag tror man ska, om man är ny och färsk så ska man bara vara medveten om att den finns. Kanske inte tro att man kan behärska den, men vara nyfiken, diskutera och ifrågasätta. Jag har ju alltid varit en mästare på att ta perspektiv som jag kanske inte alltid står för, just för att utmana. Sitter jag med en grupp människor och alla säger ja, så säger hon nej.

Fast jag kanske tycker ja. För att jag vill veta varför säger alla ja. Så att, ja, man får nog vara lite så, lite nyfiken tror jag. Intressant. Jobbade nere i Holland och hade en styrgrupp där jag som svensk, då givetvis hade förankrat innan jag skulle få mitt beslut, gick till styrgruppen, person, kärrigt, satt och sa nej. Och så sa de, men vi hade gjort upp dem där innan.

Ni svenskar är så konstiga som har stygruppsmöt med innan. Jag vill att vi har en diskussion här. Där kan jag tycka att det är bra att ha stygruppsmötet informellt innan. Absolut, men det är olika kulturer. Ja, så är det. I er modell kombinerar ni agilt och vattenfallmodell.

Vilka metoder har ni tagit från det ena och det andra? Jag tycker inte att man kan säga att vi har tagit det ena eller det andra. Utan vattenfall är en filosofi som säger att du ska göra alla sakerna i tur och ordning. Jag vet när den agila rörelsen kom för 20 år sen, då var det ju Stagegate-modellen, blev ju dödsförklarad. Den var ju vansinnig. Det intressanta är att jag skrev en artikel där någon gång om ryktet om min död är betydligt överdrivet.

Om du söker på den frasen så får du författaren först och sen så kommer min artikel som 2a på Google. Det är ganska kul. Därför att det agila är så jättemycket stagegate. För att du planerar inte hela projektet utan du har en sprint. Och sen efter sprinten så gör du en utvärdering och sen tar du nya beslut. Och det är precis så stagegate-modellen funkar.

Att du gör en fas, du stannar, du reflekterar. Är det här bra? Är det här nyttigt? Och så vidare. Om du då vill jobba vattenfall, då börjar du med att skriva spesen först. Sen implementerar du allting.

Sen testar du allting och integrerar allting. Har du ett komplext projekt, så smäller det. Då blir det the big bang på slutet. Men har du låg osäkerhet, då är det jättebra. Det är väldigt effektivt att jobba vattenfall. För du gör en sak ett taget.

Men har du osäkerhet så är det farligt. Då ska du hellre jobba integrationslivet så att du tar fram en spes. Ett ungefär. Sen börjar du utveckla. Sen sätter du ihop det och testar. Sen uppdaterar du spesen och utvecklingen.

Sen sätter du ihop det och testar igen. Du jobbar integrationslivet. Du integrerar helheten i olika steg. och till slut har du ett projekt och så slipper du den här big bang på slutet där du måste gå tillbaka från början och börja om. Så det är där det kommer in. Modellen är som den är oavsett om du jobbar vattenfall eller om du jobbar väldigt agilt. Vi pratar ju om de här utvecklingsfilosofier där vattenfall är en och den funkar jättebra.

Framför allt om du har uppgifter med låg osäkerhet och låg komplexitet, då kan man köra rakt på. Har du mer osäkerhet, då rekommenderar vi integrationsdrivet. Du försöker sätta ihop någonting. Jag kanske inte kan ha allting färdigt, men jag kan ha en modell, en datomodell eller en tidig prototyp. Ingenting är fullt färdigt så jag kan inte leverera någonting till kunden, men jag lär mig under resans gång. Och sedan den tredje är det som många säger, det agila eller det incrementella.

Istället för att jobba med allting så tar jag en del av systemet. Så gör jag det färdigt. Det är färdigutvecklat, färdigdokumenterat. Det är klart att leverera. Jag kanske inte levererar, men levererar. Sen bygger jag nästa del av systemet.

Då har jag möjlighet att få ut ett resultat tidigare. Och få nytta av det resultatet. Ska jag bygga en e-handelsplats, till exempel? Jag måste ha min produktlista där. Och så behöver jag ha en shoppingbasket där jag kan stoppa i saker. Och sen måste jag ha en checkout där jag talar om vart jag ska leverera, så hur jag betalar.

Då bygger jag det. Och så kan jag börja använda det. Och så ser jag att när de stoppar saker i karien så kanske de ångrar sig. De vill kunna ta bort saker eller de vill kunna ändra antal och så vidare. De kanske vill betala på olika sätt. Det är så att jag kan börja använda det, men jag kan också förvina det hela tiden.

Det här handlar väldigt mycket om ett förhållningssätt. Den fjärde utvecklingsfilosofin är utforskande. Om du har ett forskningsprojekt, oftast är resultatet ny kunskap. Där jobbar man väldigt iterativt. Man gör om, man gör om, man förfinar. Men det är samma sak hela tiden.

Det handlar om vilket angreppssätt man tar när man har projektet. Det beror lite på graden av osäkerhet och komplexitet. Du är ute bland många olika typer av företag med din erfarenhet. Vad skulle du säga är de största utmaningarna i dag? Du var inne på det. Kravbilden är otydlig.

Beställaren förstår inte vilken viktig roll henne har. Att man faktiskt är aktiv. Styrgrupper också. Många tror att de sitter i en styrgrupp. Det gör man inte. Man arbetar i en styrgrupp.

Inte så vanligt nu längre, men förr var det vanligt förekommande att man förväxlade ledningsgruppen med styrgruppen. Det vill säga att ledningsgruppen var styrgrupp åt alla projekt. Det hinner de inte. Då får man utse en person som blir beställare och den personen avgör om henne vill ha någon mer med sig i styrgruppen. Det är inte oftast räcker det med en beställare om det inte är större projekt. Hur upplever du det agila och projekt motsvarande vattenfall och mognad ute i projekt Sverige?

Jag tycker att mognaden blir bättre och bättre. Jag ser också en tendens att det här med det agila var väldigt hett. Jag har för femton år sen varit extremt hett. Idag är det inte lika hett, utan idag är det lite mer, ja men så bör man väl jobba oavsett vilken bransch det är. Agila springer ur systemutveckling, IT-sidan, men har också spritt sig mer och mer. Vi ser också kunder som har infört både Safe och Agila metoder som nu går tillbaks och kör projekt.

Det är väl som alltid. Det går. Pendeln svänger fram och tillbaka. Jag tror att en gyllene medelväg någonstans finns ingen patentlösning. Vi på VNL tror att använd en projektmodell för att få stödet, men sen måste du ha ett mindset med dig. Men om du är tillbaka till de största utmaningarna, det är väl det att kravbilden är otydlig.

Det får den inte vara. Den kan vara ospecifik. Det vill säga att jag vet inte allting, men då får jag vara tydlig med det. De här sakerna vet vi inte. Det här tror vi. Tydlighet är jätteviktigt.

Då kan man ha ett målsökande projekt. Då lägger man upp det på det sättet. Sen är det resursbrist. Det beror på att man startar för många projekt samtidigt. Man använder inte grindarna på rätt sätt. Jag är väldigt tydlig med det.

En grind är per definition stängd. Du måste komma med väldigt goda argument för att den ska öppnas. Jag ser ute i verkligheten att många tror att grindarna står öppna. och det är bara de dåliga projekten så stänger vi grinden. Tänk om du inte hittar några riktigt bra argument för att stänga. Då fortsätter du med ett projekt som inte borde få fortsätta. Om du tänker att den är stängd, då måste du hitta bra argument för att öppna.

Och hittar du inte det, då är den för stängd. Så tror jag man skulle få ner antalet onödiga projekter. som man får uttrycka sig som. Har du sett några företag som idag är så mogna att de faktiskt stänger projekt som nästan som en regel? Ja men det finns, och jag skulle nästan vilja säga det finns vissa branscher som är duktigare på detta, som startar väldigt många förstudier med vetskapen om att de flesta kommer att stänga. Men vi behöver göra detta. Vi behöver ta fram någonting för att lära oss mer.

Och vilka branscher? Pharmaceftiskt är det kanske den mest tydliga. Där kör man mycket parallellt i början, och så smalnar man ner det här. Det är också en av principerna inom det agila. Man tänker att det agila har lånat mycket från lin. Lin går ju ut på att få bort all waste.

Men det finns en princip i det agila som faktiskt är tvärtom. Man bygger in waste. Det vill säga att jag vet inte om den här produkten ska vara röd eller grön. Så jag börjar utveckla både en röd och en grön med vetskapen om att den ena kommer att börja stänga. Men startar jag inte nu så hinner jag inte till marknadsfönstret. Så där gör man faktiskt att man introducerar Waste för att vara säker på att få en affär, att få nytta av det på slutet.

Det börjar fler och fler börja tänka så. Man kör parallella spår med vetskapen om att man ska stänga ner. Sen går det att förfina. Man kan jobba väldigt mycket med modul. Att man har allting moduluppbyggt och så vidare. Ofta blir det ju inte waste i det långa loppet.

Man använder vissa moduler. I en förlängning använder man andra. Hur ser du på Safe? Safe är ett fantastiskt sätt att jobba. När jag gick den här Safe-kursen och certifierade mig kände jag i princip igen allt från hur vi jobbade på Ericsson med Japansystemet Entity Rockamo. Alla de här forer hette inte samma sak, men strukturen var väldigt…

Safe är jättebra om du har en befintlig produkt ute på marknaden som behöver underhållas och utvecklas. Det är det Safer tillför. Men ska du ta fram en ny plattform, då tycker jag projekt är mycket bättre. Där har du ingenting som du måste förvalta hela tiden, utan där kan du jobba i projektet på ett annat sätt. Och där ser vi att en del av våra kunder har insett detta, så man väljer hur man vill jobba. Jag har sett stora företag som kombinerar det här och kallar det Safer.

Ja, och Tomas Gustafsson tror jag har varit med i din podd för länge sedan. Ja, han tittade ju på tre olika organisationer. En offentlig bank och ett industriföretag då. Där de införde safe. Med olika mindset egentligen. Och där de som såg det som de måste vilja följa, de fick minst nytta av det.

De som såg att det här är ett ramverk, de fick mer nytta av det. Men de som såg att det här är en verktygslåda. Här kan vi plocka verktyg och bygga någonting som passar oss. Kallar man det safefish, ja kanske. Men då blir det ju bra till slut. Man kommer tillbaka till att det är ett hantverk där med projektlederi.

Det är ett hantverk, så är det. Det finns ingen silver bullet. Jag vet att du är engagerad i projektnäring. Kan du berätta lite mer om det? Projektnäring är ett initiativ som vi var med och tog för 2011 tror jag vi startade första gången. Det är ett event för projektledare.

Fredag förmiddag, där det är intressanta föreläsare. Även Svenska Projektakademin delar ut pris till årets projektledare. Det brukar vara väldigt uppskattat. Förra året var det 140 deltagare. Det är den 22 november, en förmiddag. Man får lite fika när man kommer och lyssnar.

Det är mycket mingeltid för vi tycker det är jätteviktigt att projektproffsen får träffas och prata med varandra. Var det här någonstans? Den här podden kommer ut 4 november så det finns ändå lite tid kvar när den kommer ut. Ja, det är på Quality Hotel Globe, ute vid Globen där. I Stockholm? I Stockholm, ja.

Precis. Om man vill vara med på det här, hur gör man då? Då googlar man. Vi kan lägga en länk i anteckningarna. Projektnäring, där finns en hemsida och där kan man anmäla sig också. Det är väldigt uppskattat.

Det är många av våra kunder och många andra som försöker det här eventet. Vi tog fram det här för vi kände att det inte finns nåt för projektledare. Det finns jättemånga event för chefer. Men ingenting specifikt… eller fanns inte då, idag finns det nog mer och det finns mycket man kan gå upp med. Men just de här föreläsningsserierna. Du berättade om att även det delas ut pris till årets projektledare.

Även fast det inte är själva projektnäringen som gör det, men berätta lite om det. Det är Svenska Projektakademin. Det är en förening, Billedas 1995 tror jag den Billedas. De hade första mötet 1994. Bestående av både forskare och praktiker. De bland annat utser årets projektledare, delar pris till årets projektuppsats inom akademin.

Värnar om det här och försöker knyta banden mellan praktiken och akademin. Det är de som tar emot nomineringen till årets projektledare. Den är stängd, så det är för sent att nominera nu. De väljer ut och sen delar de pris på projektnäring. Det är inte projektnäring som utser det här, utan det är ju svenska projektakalemin. Men vi har ett tätt samarbete med dem också.

Vi tycker om att försöka vara bryggan mellan teori och praktik. Några av dem som har varit ordsprojektgärder har faktiskt varit med i podden också. De är väldigt duktiga personer. Det är roligt att se att det är olika branscher och olika typer av projekt. Men de har gemensamt den här komplexiteten, skulle jag säga, och det är oftast intressenter som finns där på något sätt. En av de häftigaste jag kommer ihåg det var ju, vad hette hon?

World Scout Jamboree. Vilket event, alltså du bygger upp en stad utför en åker för 40 000 människor i en vecka som ska transporteras in, som ska leva där. Utmaning. Det var häftigt. Jag vet, jag lyssnade på henne. Fantastiskt.

Jag brukar alltid ställa en fråga i de här poddarna, det gör man själv och gjort någon misstag som någon annan kan lära sig av inom projekt. Har du gjort några misstag i ditt liv? Ja. Något du ville berätta? Ja, men faktiskt någonting som jag ångrar är att jag vek ner mig. Jag hade varit 15 år på Ericsson.

Jag nämnde att bli häddhantat i ett annat bolag. Jag var ganska ny där. Vi skulle dra igång ett nytt projekt. Jag kände att förstudien inte är klar. Vi är inte mogna att ta beslut att köra igång det här. Men beställaren och ledningskruppen låg på mig och jag pratade med de andra som var gamla i GM.

Och så sa han att vi inte är klara. Nej, det brukar vara sig. Det brukar lösa sig. Så jag sa, okej, vi kör vidare då. Några veckor efter det fick jag tag i de resurser jag inte hade fått tag i. Vi kunde planera projektet på riktigt och inse att det kommer att ta tre månader till.

Nästa styrgruppsmöte, en månad efter att vi hade sagt att nu sparkar vi igång projektet, då fick jag tala om att vi inte kan vara klara i april, utan vi är klara strax till semestern i bästa fall. Va? Har du lyckats försena projektet tre månader på bara en månad? Nej, det var redan försenat, fast det var ingen som såg det. Men när har du en magkänsla, gå på den. Jätteviktigt.

Magkänslan är nån slags samlad erfarenhet som du har, som du inte kan sätta ner i bokstäver och siffror, men lita på den. –Grinden var öppen. –Grinden var öppen. Jajamän, så var det. Ingen ville stänga den. Det var kul att jag var med i en arbetsgrupp. Vi skulle ta fram checklister för de olika grindarna. generiska checklister. Det var ett intressant arbete.

Vi var ett gäng i den här gruppen. De flesta var inte praktiserande projektledare. Jag och en till var praktiserande projektledare. Jag sa att vi skulle ha den här frågan. Vad är projektledarens gut feeling? Då skrattade alla.

Utom den andra praktiserande projektledaren sa han att det var en bra fråga. –Va? Vad menar du? Så kan man ju inte fråga. –Jo, så gör man. Det kan man ju fråga. För om projektledaren inte tror på det här projektet, tror ni att det kommer att lyckas då? –Nej. –Antingen är det fel på projektet eller så är det fel på projektledaren. Så är det den viktigaste frågan vi har.

Så att ja, magkänsla… Jag ska inte styra allt, men man ska verkligen lyssna på det. –Känner du igen du där, en beställare som alltid ställde frågan När allting var redovisat, var det dags att öppna grinden, man ställde alltid frågan Känner du dig trygg med det här? Och som tittade på hur man reagerade snarare än vad man sa Ja, det är viktigt Om man skulle vilja få kontakt på dig eller Venell, hur gör man då? Då googlar man igen, venell.se Där finns kontaktuppgifter till mig och alla mina kolleger Och ni är hjärtligt välkomna att ta kontakt Mail är ju företrädesvis Vi håller ofta kurs och då har vi stängt av tillvånen.

Är det nånting vi inte har pratat om idag som du tycker att vi borde ha pratat om? Ja, men egentligen… Om man nu vill införa en projektmodell eller man vill bli bättre… Man kanske har en modell, men man vill bli bättre och så vidare. Då brukar vi ju alltid säga att ta ett steg i taget. Bestäm dig för nånting.

Börja göra det. När du känner att du tar nästa steg och inför det. Har du gått kurs, oavsett om det är hos oss eller nån annan, så kommer du tillbaka. Nu vet jag hur vi ska göra allt det. Det blir bara nej, nej, nej. Har du varit på kurs eller?

Smyg in det. Ta en sak i taget. Gör nån planeringsworkshop, gör nån riskworkshop och så vidare. Det tror jag är nyckeln till framgång. Att man börjar i det lilla och så tar man steg för steg. –för att visa på framgången. –Jättebra. I dag har vi haft med oss Tommy och Lin och har berättat om Venellas projektmodell– –och om det agila och mycket annat.

Tack för att du tog det tid. Tack för att jag fick vara med. Spännande. Tack för att du har lyssnat på Projektledarpodden. Höj gärna av dig till oss med idéer, tips och förbättringsförslag. Det gör du enklast via mail på– Lyssnare, snabla, Projektledarpodden.se eller vid det sociala nätverk du föredrar.