Alla inlägg i Kategorin “Förstasida

Att hålla effektiva statusmöten

Många möten där man ska diskutera status på aktiviteter blir alldeles för långa. Genom att följa en enkel ordningsföljd kan mötena effektiviseras avsevärt samtidigt som den generella kvaliteten på statusrapporteringen höjs.

Kan inte någon ringa så jag kan få gå ifrån?

Ingen av deltagarna var särskilt nöjda med avstämningsmötena med utvecklingsteamet. Jag som chef och beställare tyckte att det tog eoner av tid, mötet hamnade hela tiden i detaljdiskussioner och avvek ofta från ämnet. Verksamhetsrepresentanterna såg det som ett tillfälle att komma med nya krav och idéer och utvecklarna tyckte mest att det var rörigt. Men alla var överens om att det var superviktigt att vi hade mötena. Det som var planerat en halvtimme kunde ta upp till en och en halv timme. Vecka ut och vecka in. Vid något tillfälle var jag så frustrerad att jag önskade att någon skulle ringa på mobiltelefonen så att jag kunde säga “ursäkta, men jag måste faktiskt ta det här samtalet”. Bara för att få slippa ifrån mötet. Moget? Nej. Mänskligt. Ja.

Genom att införa en ny dagordning och ett nytt flöde i mötena kunde vi minska tiden till omkring 25 minuter. Det är var förbättring på 70%. Vad är magin bakom detta?

En enhetlig definition av status

Det första steget handlade om att vi var överens om vilka olika status ett ärenden kan ha:

  • Inkorg (nya ärenden, idéer, krav)
  • Att göra (aktiviteter som beställaren, verksamheten och utförarna beslutat att genomföra)
  • Pågår (ärenden som utförarna har tagit på sig att göra)
  • Hinder/Problem (ärenden där utförarna flaggar för att de inte kan leverera enligt de ramar som givits)
  • Utfört (ärenden som utförarna anser vara färdiga)
  • Klart (ärenden som verifierats vara klara av verksamheten)

En tydlig definition av “klart” och “grönt”

Det krävs givetvis inte mycket till raketforskning för att komma fram till dessa status-flaggor på ärenden. Drillade i Lean som vi är, var självklart vår tanke att kunna lägga fokus på att diskutera avvikelser, det som är “rött”, samt försöka undvika diskutera det som är “grönt”. Här behövdes det införas ett arbetssätt som tydligt definierade vad klart betyder för en uppgift samt vilka ramar i form av funktionalitet, tid, kostnad, resurser etc. som uppgiften har. Ramarna användes för att definiera vad “rött” och “grönt” betyder: så länge en uppgift håller sig inom ramarna är den grön. Men så fort en utförare ser att uppgiften riskerar att hamna utanför ramarna flaggas den som röd. Detta görs genom att sätta status till “Hinder/Problem”. Läs gärna tidigare blogginlägg: “Vad betyder klart?” respektive “Vad betyder grönt?” för en djupare beskrivning av dessa tankesätt.

Fokusera på nytta

Alla uppgifter syftar till att skapa någon form av nytta för de som ska ta emot det färdiga resultatet. Men det är ju först när resultatet verkligen används som det ju faktiskt genererar nytta. Därför ska ärendeflöden fokusera på att få ut så mycket nytta som möjligt, så fort som möjligt.

Det första steget bör därför avhandla det som har flaggats som klart. Det är ju sådant som utförarna anser vara färdigt att användas. Därför ställs frågan: “Det som är markerat som klart, är det användbart och kan det börja användas?”. Här får mottagarna uppgiften att verifiera att klart verkligen betyder klart och i så fall sätts ärendets status till “Klart”. Om det inte är klart ska ärendet gå tillbaka till “Att göra” efter det att definitionen av vad klart betyder har uppdaterats.

Det andra steget är att titta på det som är flaggat som “hinder”. Det är sådant som hindrar utförarna på att få saker färdiga. Genom att undanröja hinder, uppdatera definitionen av klart eller grönt kan sedan status sättas till “pågår” (eller möjligen “att göra” eller till och med “inkorg” om det rör sig om större förändringar). Här är det viktigt att inte fastna i detaljdiskussioner. Se till att föra diskussionen kring “vad behöver vi göra för att komma vidare“, inte “hur löser vi problemen”. Ofta handlar det om att identifiera vilka personer som behöver ta en separat diskussion för att undanröja hindren.

Det trejde steget är att titta på inkorgen. Tänk på inkorgen som beställarens “backlogg”. Vad har tillkommit? Är det något som är så viktigt just nu att det måste flyttas till “att göra”? En inkorg är ett bra sätt att ta till vara på alla idéer, krav, förbättringar, frågor etc. Tanken är att vem som helst, när som helst kan lägga saker i inkorgen. Viktigt är att kommunicera att bara för att något ligger i inkorgen betyder det inte att det ska göras så skyndsamt som möjligt, det kanske inte ens kommer att göras alls. Men det har i alla fall noterats och kommer att övervägas. Om det kommer många ärenden i inkorgen, kan det vara bättre att i detalj titta på ärendena vid separata möten. Varje möte bör dock skumma inkorgen för att se om någonting uppenbart bör göras nu. När inkorgen blir ohanterligt lång bör det bokas ett separat möte för att se över allt som ligger där. Det kan finnas dubbletter, en del ärenden kan vara inaktuella, kanske är de inte ett problem längre eller har redan lösts på något annat sätt. Då kan dessa ärenden arkiveras på lämpligt sätt. Viktigt är att inte bara ignorera eller kasta ärenden. Varje statusbyte bör kommuniceras med den som har skapat ärendet (eller som har utpekats som ansvarig för dem).

Det fjärde steget är att avhandla alla ärenden som har status “att göra”. Tänk på att-göra-listan som utförarnas “backlogg”. För att något ska kunna liggs här behöver det finnas en tydlig definition av vad klart betyder samt tydliga ramar för utförarna, vad grönt betyder. Detta är ett jobb som utförarna, användarna och beställaren behöver göra tillsammans och det kan ibland ta lång tid. Ett effektivt sätt att jobba på är att sätta ett datum när klart och grönt ska vara på plats och utse en ansvarig som ska leda ärendet dit. Listan måste också vara sorterad i prioritetsordning med avseende på nytta: 1, 2, 3, 4, osv. På detta sätt vet utförarna i vad som är viktigast för mottagarna och vad som önskas utfört först. Dessutom kan utförarna, i stället för att vänta på att de ärenden som är flaggade som hinder/problem, påbörja nästa uppgift. En sak till att tänka på är att ärendena inte får vara för stora. Då behöver de delas upp i flera självständiga ärenden, vart och ett med någon form av tydlig nytta för mottagaren.

Det femte steget är att i mån av tid diskutera ärenden som ligger i “pågår”. Men grundidén är egentligen att så länge utförarna håller sig inom ramarna, inom för vad som har definierats som grönt, så behöver saken inte diskuteras. Finns det viktiga frågor eller hinder, så ska ju ärendet redan varit avhandlat under det andra steget, “hinder”.

Dagliga teammöten

Utförar-teamet behöver förmodligen stämma av framdriften på daglig basis. Det kan lätt göras inom ramen för strukturen ovan, men med fokus på de delar av ärendekatalogen som utförarna ansvarar för.

Förslagsvis drar varje teammedlem kort status på det som han/hon arbetar med:

  1. Vad har jag blivit klar med? Dessa ärenden har fått status “klart” efter det att utföraren har verifierat att allt är levererat enligt definitionen av klart.
  2. Vilka hinder/problem har jag? Om man som utförare har fastnat eller ser risken att uppgiften hamnar utanför vad som definierats som grönt ska detta flaggas så fort som möjligt. Viktigt är att vara kortfattad i beskrivningen av vilka hinder/problem som har uppkommit. Det är oftast bättre att detaljerna avhandlas separat med berörda parter efter teammötet. De hinder/problem som identifieras ska noteras och status på ärendet ska sättas till “Hinder/problem”.
  3. Vad i “att göra” kommer jag jobba på idag? Här finns det möjligheter för teamet eller teamledaren att prioritera samt att säkerställa att utföraren förstår vad som ska göras (vad klart betyder)

Sammanfattning

Nedanstående arbetssätt är baserat på en kombination av metodik från Kanban, Scrum och Prince2

Agenda för statusmöten

Deltagare: beställare, representanter för mottagarna (verksamheten) samt utförarna

  1. Vad har blivit utfört? Är det klart?
  2. Hur undanröjer vi hinder/problem så att arbetet kan fortsätta?
  3. Har det inkommit något nytt vi måste ta hand om?
  4. Är alla aktiviteter på att-göra-listan lagom stora, är det tydligt definierat vad klart betyder samt finns det tydligt definierade ramar för vad grönt betyder? Är listan i prioritetsordning?
  5. Om tid finns: behöver vi diskutera något av det där arbete pågår?

Kom ihåg att kommunicera förändringar av ärenden och dess status till berörda parter. Säkerställ att det alltid finns en ansvarig för att kommunikationen blir av.

Agenda för dagliga teammöten

Deltagare: Beställaren, utförarna, ledare för utförare-teamet (samt övriga åhörare vid behov)

  1. Vad har jag flyttat till “klart”?
  2. Vad har jag flyttat till “hinder/problem” och kortfattat varför?
  3. Vad i listan “att göra” kommer jag jobba på idag?

Detaljdiskussioner kring hinder/problem tas utanför mötet med berörda parter.

Verktyg

Ärendekatalogen, eller teamets backlogg, kan med den här metoden hanteras i många verktyg. Det kan göras i Excel, på post-it-lappar, på en whiteboard-tavla eller i verktyg som exempelvis Trello.

Användningsområden

Detta kan användas för många olika typer av möten där det handlar om att hantera och prioritera ärendeköer. Det kan vara projektmöten, avvikelsemöten, ledningsgruppsmöten, säljmöten, uppföljning av säkerhetsfrågor, förbättringsmöten, pulsmöten osv.

Skriv gärna ett mail med hur du ser på denna process, vilka sammanhang du skulle kunna tänka dig att tillämpa den, eller dina erfarenheter med att prova på den.

Skrivet av: Björn Tångeberg, En Riktig Hävert AB
(C)opyright 2021, En Riktig Hävert AB

Vad är ett projekt… egentligen?

Ordet “projekt” används ofta ganska slarvigt för “ett stycke större arbete” och många projekt misslyckas därför att det inte har skapats de förutsättningar som behövs för att driva projekt. Genom en tydlig definition av vad ett projekt är, vilka förutsättningar som behövs, vilka roller som bör finnas och vilka beslut som fattas ökas chansen att lyckas med projekten.

Ett vanligt svar på frågan “vad är ett projekt” är att det är något som måste planeras och att det är flera utförare inblandade. Det är inte en så dum startpunkt, i alla fall inte med tanke på ordets bakgrund. Ordet projekt härstammar från latinets “projicere” som helt enkelt betyder utkast eller plan. Sedan industrialismen kom ordet att betyda “arbete av engångskaraktär”, eller sådant som i alla fall är utanför ett ordinarie linjearbete.

Dagens stora projektmodeller har ungefär samma andemening i följande definition:

Ett projekt är: en tillfälligt sammansatt organisation, vars syfte är att leverera lösningen på ett specifikt problem enligt en överenskommen nyttokalkyl.

Tillfälligt sammansatt organisation

För att kunna skapa en lösning på ett specifik/unikt problem behöver ett team sättas samman av rätt kompetens och de måste ges rätt resurser för att kunna genomföra projektet. Det lämpar sig dåligt att driva projekt inom ramen för ordinarie linjearbete, då man ju i linjeorganisationen försöker hitta standardiserade sätt att arbeta på för att lösa standardiserade problem. Ofta är en linjeorganisation kompetensindelad och oftast är projekt i behov av tvärfunktionell kunskap. Det är inte ovanligt att kunskap behövs från flera olika organisationer. Projektet behöver bara finnas från punkt A till punkt B, sedan löses projektorganisationen upp.

Lösningen på ett specifikt problem

Man tillsätter projekt för att lösa ett specifikt eller unikt problem som beställarorganisationen inte har löst förut. Med specifikt problem avses att ta sig från “A” till “B”, att på något sätt åstadkomma en förändring.

Det här med förändring är centralt. Tänk dig motsatsen: projektet levererar någonting, men dess resultat leder inte till någon förändring. Var det då värt att genomföra projektet?

Många projekt misslyckas på grund av just detta: projektet fokuserar för mycket på det egna projektarbetet, men inte tillräckligt på att resultatet ska användas, skapa nytta för mottagaren och borga för en förändring.

En överenskommen nyttokalkyl

Ett projekt måste således skapa nytta för mottagaren. Kostnaden för projektet måste kunna motiveras för den som betalar. I och med att projektet löser ett specifikt/unikt problem måste arbetet planeras i någon form. Och det måste finnans någon form av beslutsunderlag för att starta projektet, och för att vägleda projektbesluten. Den eftersökta nyttan måste vara större än kostnaden. Ett projekt bör löpande ställa sig frågan om det är värt att fullfölja projektet; levereras den efterfrågade nyttan? Nyttokalkylen behövs även för att i efterhand kunna följa upp att den nyttan verkligen uppnåddes. Annars kan ju organisationen inte lära sig och bli bättre på framtida beslut.

Några intressenter som finns i alla projekt

Varje projekt har en beställare som representeras av en sponsor som står för att säkerställa de ekonomiska medel och resurser som behövs för att genomföra projektet. Varje projekt har mottagare som ska ta emot projektets leverans, använda det projektet har levererat och därigenom uppnå den eftersökta nyttan. Varje projekt har en projektledare som är ansvarig för den dagliga framdriften av projektet. Sen finns även utförare i projektet, som bistår med arbete och kunskap.

På senare tid brukar man allt oftare, ur ett hållbarhetsperspektiv, prata om ytterligare två intressentgrupper: samhället och miljön.

Projektets styrgrupp, som leds av sponsorn, fattar (de övergripande) projektbesluten och har det yttersta ansvaret för att projektet går i mål och levererar en efterfrågad lösning på problemet i linje med den överenskomna nyttokalkylen. Projektets styrgrupp måste balansera behoven av projektets intressenter; beställare, mottagare och utförare, samt göra det möjligt för projektledaren och utförarna att genomföra projektet.

Projektledaren leder det dagliga arbetet för projektteamet. Projektledaren förser styrgruppen med status, information och beslutsunderlag så att styrgruppen kan fatta de övergripande projektbesluten.

Vilka beslut fattas i ett projekt?

Det finns projektbeslut som ingår i alla projekt. Ibland är besluten ganska enkla, så att man kanske inte ens reflekterar över att de tas. Ibland krävs det ett omfattande underlag och en beslutsprocess med många inblandade för att fatta besluten.

Här är de projekt och faser som i någon form finns i alla projekt:

Standardprocesser och beslutspunkter i ett projekt
(C)copyright En Riktig Hävert AB
  • Före projektet
  • Beslutspunkt 1: Kan vi påbörja förberedandet av projektet?
  • Förberedelsefas
  • Beslutspunkt 2: Kan vi påbörja planeringen av projektet?
  • Planeringsfas
  • Beslutspunkt 3: Visar projektets nyttokalkyl att vi kan starta leveransen av projektet?
  • Leveransfas
  • Beslutspunkt 4: Kan vi påbörja nästa leveransfas? (upprepas för varje leveransfas av projektet)
  • Beslutspunkt 5: Kan vi påbörja stängning av projektet?
  • Efter projektet
  • Beslutspunkt 6: Var projektet lyckosamt?

I större projekt skiljer vi på förberedelser och planering. Förberedelser är sådana ting som att utse och tilldela nyckelrollerna i projektet, göra en grov nyttokalkyl och formulera projektets övergripande mål och syfte. Detta behöver vara på plats för att man ska kunna börja planera projektet på ett effektivt sätt och att det är säkerställt att det är värt att spendera tid och pengar på planeringen. I komplexa projekt kan planeringsfasen vara ganska omfattande, ta lång tid och medföra stora kostnader.

Inför varje fas och vid varje beslutspunkt är den aktuellt uppdaterade nyttokalkylen samt planen för nästa fas det huvudsakliga beslutsunderlaget. Om man vid ett beslutstillfälle ser att nyttokalkylen inte håller, och således konstaterar att projektet inte är lönsamt, kanske projektet måste planeras om, förändras på något sätt eller till och med läggas ner.

Genom att dela in projektet i etapper/leveransfaser ger man styrgruppen möjligheten att återkomma till en uppdaterad nyttokalkylen för att säkerställa att det fortfarande är lönsamt att fortsätta med projektet.

Sju grundläggande principer

Prince2, som är en av världens mest använda projektmodeller, har sju principer som bygger på lärdomar från tusentals lyckade och misslyckade projekt. De här principerna är så allmängiltiga att de bör tillämpas på alla projekt, även om man inte använder just Prince2 som projektmetodik. Faktum är att principerna är så allmängiltiga att de kan användas i många andra sammanhang än inom projektområdet.

Grundläggande principer för projektledning (Prince2)
(C)copyright, en Riktig Hävert AB (baserat på Prince2)
PrincipEn kort förklaring
Fokusera på produkterna
projektet levererar.
Jag brukar tänka på det projektet levererar som produkter. Ordet “produkt” för mina mot något som är konkret, ska användas av någon och som har ett värde.

Se även tidigare blogg-inlägg “Vad betyder klart? / Definition of Done” .
Säkerställ att projektet
alltid levererar mer värde
än det kostar.
Genom att ha en uppdaterad nyttokalkyl som visar att nyttan av projektets “produkter” överstiger kostnaden för projektet, kan man säkerställa att projektet är lönsamt. Detta är det viktigaste beslutsunderlaget för samtliga projektbeslut.
Ha tydligt definierade
roller och ansvar
Tydligt definierade roller och ansvar är nödvändigt för en effektiv leverans så att alla förstår vad de ska göra i projektet.

Det är också viktigt att alla intressenters intressen säkerställs av styrgruppen, så att rätt beslut kan fattas.
Lär av erfarenheter
innan, under och efter.
Eftersom ett projekt är en tillfällig organisation är det viktigt att hämta lärdomar utanför projektet. Kanske finns det liknande projekt som det går att ta lärdom av?

Under projektets gång görs lärdomar som dels behöver hanteras i projektet för att få till en ständig förbättring, dels också dokumenteras så de kan överföras till kommande projekt.

En organisation som är bra på att ta tillvara på och nyttja tidigare lärdomar är mer effektiv än en organisation som ständigt “uppfinner hjulet på nytt”.
Led och styr avvikelsebaseratGenom att leda och styra på avvikelser (snarare än detaljstyrning av alla aktiviteter) används alla resurser i projektet på ett effektiv sätt.

Se tidigare blogg-inlägg “Vad betyder grönt?/Definition of Green“.
Led och styr i etapperGenom att dela upp planer i etapper, minskar planeringshorisonten och risken för att planen är för stor eller felaktig. Planeringsarbetet blir också effektivare. Det är också viktigt att ge styrgruppen tillräckligt med beslutstillfällen att säkerställa att projektet är på rätt köl och kommer att leverera efterfrågad nytta.

Se även här tidigare blogg-inlägg “Vad betyder grönt?/Definition of Green“.
Anpassa arbetssätt till
projektets förutsättningar
Ett vanligt fel i projektsammanhang är att ha bristfällig eller till och med obefintlig metodik. Men lika vanligt är att projektmetodiken som används är omständlig, stel och byråkratisk.

Det är viktigt att anpassa arbetssätten utifrån det enskilda projektets behov av struktur i form av beslutsunderlag och projektdokumentation samt hur många etapper man delar in projektets leveranser i.

Några exempel på varför projekt inte lyckas

Under mina 30+ år med projektarbete har jag gått på många minor. Här är några exempel på varför projekt har misslyckats. Samtliga fall som jag personligen upplevt i någon form av projektroll, som beställare, projektledare eller utförare. Listan är lång och smått deprimerande…

  • Det fanns ingen tydlig beställare som fattade de övergripande/ekonomiska besluten i projektet. Projektet fick leva sitt eget liv och självständigt fatta sina beslut efter bästa förmåga.
  • Beställaren hade ett för snävt intresse, saknade förankring i beställarorganisationen och förstod inte förutsättningarna för mottagarna/användarna. Beställaren “tryckte” igenom beslut för att komma vidare med projektet, snarare än att säkerställa att projektet skulle lyckas.
  • Projektet startades utan att ha tänkts igenom från början. Det fanns en idé eller vision, men ingen nyttokalkyl. I efterhand kunde man inte motivera varför man genomförde projektet, då det kostade mer än den nyttan som levererades.
  • Projektet startade utan förberedelser och utan planering. “Kör bara” var budskapet från beställaren.
  • Projektet var ett “restprojekt” för att hantera bristerna och uteblivna leveranser från föregående projekt.
  • Projektet spenderade ohemult med tid och pengar på planering och beslut för att klara av att navigera besluten i en stor och komplex organisation.
  • Sponsorn saknade mandat för att fatta projektbesluten, de ville företagets koncernledning ta. Men i koncernledningen hade man inte hela bilden av behovet och problemen. Besluten blev snarare politiska än nyttobaserade.
  • Förutsättningarna för projektet ändrades hela tiden. Ena dagen var en sak viktig, andra dagen en annan.
  • Projektet fick inte tillräckligt med resurser för att kunna genomföras på ett effektivt sätt. Beställaren ville använda interna resurser av kostnadsskäl, men dessa hade varken tid, kunskap eller lust att bidra till projektet.
  • Projektet var politiskt styrt av företagets IT-organisation som ville trycka ut en standardprogramvara i stället för att lyssna på användarnas behov och designa en lösning utifrån det. Resultatet blev dyrt och oanvändbart.
  • Projektet fick fortlöpa under en lång tid, trots att alla visste att det egentligen inte var lönsamt.
  • Projektet fokuserade på komplicerad projektmetodik och byggde upp en byråkrati som ingen ville ha och ingen förstod.
  • Projektet var alldeles för komplext och bestod egentligen av flera, bara delvis sammanlänkade projekt. Men eftersom projekten hade samma sponsor tyckte denne att det var mer effektivt att köra alla projekten i samma organisation. Det ledde till att varje delprojekt till stor del fick sitta och vänta på beslut och inte kunde röra sig framåt på ett effektivt sätt.
  • Projektledaren var ung och oerfaren och visste inte vad projektledning innebar.
  • Projektet var nästan helt drivet av konsulter, som hade större intresse i att tjäna pengar än att leverera nytta till beställaren. I alla fall drog konsultföretaget i nödbromsen när de insåg att det kostade mer än vad det skulle ge i nytta.
  • Projektet saknade helt styrning, projektledaren var snarare utförare än projektledare
  • Man drog inte (rätt) lärdomar av tidigare projekt, trots att liknande projekt hade genomförts i organisationen och misslyckats. Projektet fick gå på samma minor som alla andra.
  • Projektet var naivt inställt till teknik och ville prova en massa spännande ny teknik, i stället för att hitta de enkla och fungerande lösningarna. Resultatet blev ett IT-system som aldrig fungerade.
  • På styrgruppsmötena fattades inte de övergripande besluten, det saknades helt beslutsunderlag. Däremot försökte styrgruppen fatta praktiska projektbeslut som egentligen projektledaren skulle ha fattat om denne hade fått tillräckligt mandat att leda projektet.
  • Beställaren tvingade in resurser i projektteamet som inte fungerade interpersonellt. Det fanns konflikter och motsättningar i projektteamet som gjorde att det fokuserade på interna problem och stridigheter istället för att leverera nytta till beställaren.
  • Man säkerställde inte en bra överlämning av projektet till mottagarna/användarna, vilket resulterade i att de inte kunde använda projektets resultat, varpå nyttan uteblev.
  • Det saknades kravspecifikationer, projektet visste egentligen inte vilket problem de skulle lösa.
  • Man fortsatte med projektet, trots att det inte var lönsamt, men försvarare det med att “vi har redan plöjt ner så mycket pengar i det här, vi kan inte sluta nu”.
  • Projektet var egentligen inte ett projekt utan en linjeaktivitet.
  • Projektet, som köptes in av en konsultfirma påtvingandes metodik för att passa in i konsultfirmans mallar. Det som togs fram i projektet var för komplext, teoretiskt och kunde inte användas i verkligheten.

Du har säkert egna erfarenheter av varför projekt misslyckas? Skriv mig gärna ett mail med din historia, men var noggrann med att inte peka ut specifika organisationer och personer.

Vi sammanfattar

Ett projekt är en tillfälligt sammansatt organisation, vars syfte är att leverera lösningen på ett specifikt problem enligt en överenskommen nyttokalkyl.

Varje projekt har beställare (representerade av en sponsor), mottagare, utförare samt en projektledare som står för den dagliga framdriften av projektet. Ett projekt bör ha en styrgrupp som representerar de olika projektintressenternas intressen.

Sponsorn ska säkerställa att projektet levererar en nyttokalkyl där projektets nytta överstiger dess kostnader.

Varje projekt har ett antal beslutspunkter för att starta upp förberedelser, planering, leverans samt stängning av projektet. Varje projekt bör följas upp efteråt för att se att det varit lyckat.

Lärdomar ska tillvaratas före, under och efter projektet.

Sju grundläggande principer för att lyckas med ett projekt bör alltid följas:

  • Fokusera på produkterna projektet levererar
  • Säkerställ att projektet alltid levererar mer värde än det kostar
  • Ha tydligt definierade roller och ansvar
  • Lär av erfarenheter innan, under och efter
  • Led och styr avvikelsebaserat
  • Led och styr i etapper
  • Anpassa arbetssätt till projektets förutsättningar

Har du synpunkter på inlägget? Tycker du det är bra? Skriv mig gärna ett mail med dina kommentarer.

Skrivet av: Björn Tångeberg, En Riktig Hävert AB
(C)opyright 2021, En Riktig Hävert AB

Vad betyder “grönt”?

När ansvar för en aktivitet delegeras, bör tydligt definierade ramar beskriva befogenheterna. Detta är nyckeln till att lyckas med avvikelsebaserad rapportering. Ett klargörande av vad “grönt” betyder (eng: definition of green) gör att du kan delegera uppgifter så att “så länge du håller dig inom de här ramarna är det grönt. Misstänker du att du kommer att hamna utanför, ska du kontakta mig.”

En mästare i detaljstyrning

En av de mest kompetenta projektledarna jag har arbetat med hade stenkoll på precis allting. Jag har aldrig senare i livet träffat en människa som kunde ha mer koll på detaljer och outtröttligt, som en spårande jakthund, hitta avvikelser och anomalier i pågående leverans. Hon fick saker att hända, genom att inte lämna någonting som helst åt slumpen. The Devil is in the details, You know.

Men den ledarstilen har en stor brist. Genom att vara detaljstyrande, tar man oavsiktligt på sig ett alldeles för stort ansvar och lämnar inget utrymme för medarbetarna i projektet att ta eget ansvar och egna initiativ. Detaljstyrande ledarskap kväver. Det absolut motsatta, en slags icke-ledarskap, där man helt och till fullo förlitar sig på medarbetarnas egna förmåga är svårt att få effektivt. I alla fall om det är ett nytt sammansatt team eller om projektmedlemmarna inte har en lång erfarenhet av det de ska göra. Hur tar vi oss fram i den här snåriga terrängen?

Ett fundament att stå på

Vi ska bygga vidare på två tidigare blogg-inlägg. I inlägget “Om planering och omplanering” inför vi tanken att ett projekt kan betraktas som en produkt som kan brytas ner i ett träd av underprodukter. Lägger vi till vikten av att tydligt definiera vad klart betyder, som beskrivet i inlägget “Vad betyder klart (Definition of Done)“, kan vi koppla hela värdekedjan i projektet till fristående (del-)produkter, var och en med en tydlig definition av vad som ska åstadkommas. Planeringen i projektet rör sedan när och hur vi delegerar arbetspaket, där varje arbetspaket består av en uppgift att producera en eller flera (del-)produkter enligt definitionen av “klart“.

Leveransen av ett projekt kan betraktas som en produkt. Produkten ska användas av någon, i syfte att uppnå en önskad nytta. Allt arbete som utförs i projektet, syftar till att färdigställa projektprodukten.

Produkter bryts ner i (del-)produkter. Varje produkt har en produktbeskrivning som tydligt beskriver vad “klart” betyder i termer av funktion, effektmål, scope och kvalitet.

Arbete delegeras i arbetspaket. Ett arbetspaket består av en eller flera produkter. Storleken på ett arbetspaket är så pass stor att utföraren självständigt kan utföra arbetet, men inte större än att du som projektledare vågar släppa detaljkontrollen.

Att leda och styra baserat på avvikelser

Om du, som jag, har ett utpräglat kontrollbehov ska du läsa följande stycke ett par gånger. Om du delegerar en arbetsuppgift, men inte litar på utförarens förmåga att självständigt kunna leverera arbetspaketet, har du delegerat fel uppgift. Om du på allvar tror att utföraren inte kan utföra arbetet utan dina detaljerade instruktioner, har du givit uppgiften till fel person. Genom att ständigt övervaka och peta i detaljerna kväver du initiativförmåga, kreativitet och du förpassar utföraren att “hugga sten”, i stället för att “bygga katedraler”. Du behöver jobba med ditt kontrollbehov, som förmodligen bottnar i en oro att misslyckas eller att du har för rigorösa kvalitetskrav. Lösningen är inte mer kontroll utan att etablera ett förtroende mellan dig och den du delegerar till, så att ni har överenskomna avstämningspunkter. Ni behöver en definition av “klart” och av vad “grönt” betyder. Du behöver etablera avvikelserapportering.

Basen för en fungerande avvikelserapportering innebär att du talar om vad “klart” betyder, samt att du talar om vilka ramar uppgiften ska hålla sig inom för att du ska kunna betrakta den som “grön“. Ramarna kan röra att man kommer hinna klart till en viss deadline, att man ska hålla sig inom vissa kostnadsramar, att kvaliteten inte får avvika för mycket och att funktionaliteten blir den rätta. Kan du tydligt beskriva vad “grönt” betyder, för varje arbetspaket, samt komma överens med utföraren om att kontakta dig så fort denne ser att arbetet riskerar att röra sig utanför de givna ramarna, så har du byggt ett robust arbetssätt som är effektivt för alla parter. Du delegerar ansvar med befogenheter och din tid som ledare går åt till att lösa upp knutar och hantera avvikelser, istället för att bara kontrollera och följa upp.

Se ramarna – definitionen av “grönt” – som att köra på en väg. Så länge som föraren håller sig på vägen och inte riskerar att köra i diket, låter du föraren självständigt vara förare. Bara om bilen riskerar att åka i diket ska du agera. Och om föraren, vid ett vägval, inte vet om färden ska fortsätta till höger eller vänster ska du hjälpa till att navigera.

Det handlar om att bygga förtroende

I en industri jag arbetat inom, fanns en märklig kultur där det var ok att inte hinna med att utföra sina uppgifter. Jag som ledare kunde fråga: “har du förstått vad som ska göras?”. Svaret blev ja. “Är vi överens om att det ska vara gjort till i morgon?” Svaret blev ja. “Ser du några problem med att slutföra uppgiften?” Svaret blev nej. Ändå hände det gång på gång att uppgiften inte blev utförd. När jag frågade: “varför?” blev svaret “jag hann inte, det kom annat emellan.” Här fungerade uppenbarligen inte delegeringen – jag hade inte lyckats att etablera avvikelserapportering. Som ledare vill du inte höra “jag hann inte”, utan du vill höra “det finns en risk att jag inte kommer att hinna”. För då har du chansen att göra något proaktivt: det kanske går att flytta deadline? Det kanske går att minska uppgiften? Eller det kanske går att prioritera bort något annat?

För att etablera avvikelsehanterat ledarskap behöver du vara tydlig med definitionen av “klart” och definitionen av “grönt” samt bygga upp ett förtroende och en fungerande kommunikation. Du behöver situationsanpassa ditt ledarskap på tre sätt: 1) genom storleken på arbetspaketet du delegerar. 2) genom detaljeringsgraden av vad “klart” och “grönt” betyder samt 3) genom hur tydligt du kommunicerar dina förväntningar på överenskommet arbetssätt.

Storleken på arbetspaket

Om du ger en matematikprofessor uppgiften att summera tio enkla tal, kommer du förmodligen möta en kränkt person som känner sig gravt undervärderad. Om du ger en tioåring uppgiften att avverka en skog, kommer uppgiften knappas att lösas på ett lyckosamt sätt.

Storleken på arbetsuppgifter måste bygga på utförarens kunskap och förmåga. Du behöver delegera ansvar och befogenheter som är i paritet med individens förmåga att lyckas.

Detaljeringsgrad av instruktioner

En av mina stora passioner är matlagning. Jag har i princip lagat mat varje dag i mitt vuxna liv, till vardag och till fest. Jag sätter en stor ära i att behärska kokkonsten och vågar mig på att laga maträtter från världens alla hörn. Jag tycker inte om detaljerade recept. De får mig att känna mig bakbunden och gör att jag inte kan lägga min personliga touch på det jag lagar. Ändå, om jag ska laga någonting nytt brukar jag läsa recepten för att få en grov uppfattning av i vilken ordning saker ska göras, samt för att se vilka råvaror jag kommer att behöva. Däremot följer jag aldrig recepten steg för steg under själva matlagningen. Det är förmodligen därför jag är bra på att laga mat, men är usel på att baka.

Skulle du däremot sätta mig på att göra någonting helt nytt, till exempel snickra ett hus, behöver jag detaljerade instruktioner. Jag har inte kunskapen eller intuitionen för att veta hur konstruktionen ska se ut, vilket material som ska användas eller hur arbetsmomenten ska gå till.

Detaljeringsgraden i vad “klart” respektive “grönt” betyder behöver anpassas till förutsättningarna hos utföraren av arbetspaketet, så att ramar och målbild blir tydliga, men inte kvävande.

Mottagaranpassad kommunikation

Jag ledde en gång ett internationellt projektteam där den ansvarige för att förstå och dokumentera kraven kom från en annan världsdel och därigenom från en helt annan affärskultur. Vi satt i två veckor med fullspäckade workshops tillsammans med den mottagande organisationens chefer och gick igenom processer, legala krav och funktionalitet i det IT-system som skulle införas. En bit in i kravarbetet upptäckte vi att systemet i flera fall inte kunde möta kraven, trots att vi hade markerat kraven som gröna. Det visade sig att den kravansvariga, på grund av kulturella skäl, inte kände sig bemyndigad att ifrågasätta de höga chefer som deltog i workshoparna. Det var fult att gå emot auktoritet. Trots att rätt personer samarbetade och att de inblandade personerna hade hög kunskap och motivation, fungerade inte kommunikationen.

Det är så lätt att falla i fällan att andra uppfattar tillvaron som du själv gör. Tänk på att effektiv kommunikation alltid sker på mottagarens villkor. Ofta behövs kommunikation i flera parallella kanaler, såväl muntligt som skriftligt. Och underskatta inte bilder. Det är inte för intet man säger att en bild säger mer än tusen ord. Och låt kommunikation ta den tid den behöver.

Så, hur definierar man “grönt”?

Här är en enkel checklista

  • Produkterna i arbetspaketet är tydligt beskrivna, att det finns en tydlig defintion av “klart“.
  • Storleken på arbetspaketet är anpassad till utförarens kunskap och erfarenhet
  • Ramar för scope: vad måste vara på plats? Vad kan vara på plats? Hur ser prioritetsordning ut?
  • Ramar för tid: när är det vettigt att arbetet tidigast är klart och när behöver det senast vara klart?
  • Ramar för kostnader: vilka resurser får förbrukas i form av material, inköp, tidsåtgång etc.
  • Ramar för kvalitet: Vilket kvalitetsspann är acceptabelt för produkterna?
  • Ramar för risk: Vilka risker är acceptabla för genomförandet av arbetspaketet?
  • Det är överenskommet med utföraren hur och när avvikelser ska rapporteras
  • Storleken på arbetspaketet är anpassad till projektledarens behov av uppföljning och kontroll

Vad tycker du om det här? Kom gärna med synpunkter i ett mail!

Skrivet av: Björn Tångeberg, En Riktig Hävert AB
(C)opyright 2021, En Riktig Hävert AB

Om planering och omplanering

Mycket av planering och omplanering i ett projekt kan göras effektivare genom att ha rätt planeringshorisont, se på projektet som ett träd av produkter/byggstenar samt att planera projektet i etapper.

Som en gud i mitt eget universum

Första gången jag var projektledare, jag var nog inte mer än 20 år fyllda, planerade jag ett projekt med Microsoft Project. Jag var jag nästan berusad av känslan av kontroll. Jag planerade ombyggnad av ett datornätverk på ett kontor: ett antal PC skulle uppgraderas med mer minne och hårddisk samt att några nätverkskablar skulle dras om. Jag har för mig att det skulle installeras en skrivare också. Jag bröt ner aktiviteterna till minsta detalj, satte tidsestimat och definierade beroenden. Inget skulle lämnas åt slumpen. Efter många timmar hade jag ett Gantt-schema som täckte väggen på mitt kontor, ihopsatt av sammanfogade A4-utskrifter, 8 gånger 5 stycken. Timmen hade blivit sen, alla på kontoret hade gått hem, men jag stod stolt och betraktade mitt verk.

Jag var gud i mitt eget universum: jag hade planerat projektet själv och var den enda utförande resursen. Graden av förberedelse var nitisk. Några kollegor låtsades vara imponerade vid morgonfikat dagen därpå. Någon kom med det uppmuntrande tillropet: “bra planering”. Sen fanns där även en sån där krass och rationell typ (som brukar finnas i alla grupper) som kyligt konstaterade: “Behövs verkligen så där mycket papper för att fixa till våra datorer på kontoret?” Jag lät svarande kommentar bero, men tänkte i mitt stilla sinne: “Vänta du bara. Du ska få se på planernas plan in action.” Kaffekoppen dracks upp. En sista avkopplande cigarett, och så skred jag till verket.

Redan efter första timmen kollapsade planen. Det var något löjligt litet jag hade förbisett, som tvingade mig att göra saker i en annan ordning än jag hade planerat. Nåväl; inte svårare än att uppdatera planen, göra små justeringar och så skriva ut de pappersark som hade ändrats. Vilket visade sig vara allihopa. Planen försköt aktiviteterna över pappersgränserna så det var bara att skriva ut hela väggen på nytt. Efter ytterligare någon timme insåg jag att jag tvungen att överge min fina projektplan helt.

Henry Gantt (källa: Wikipedia)

Jag slutförde helt enkelt uppgifterna och lyckades med projektet, trots (men inte tack vare) min plan. Efter det tog det rätt många år innan jag ville ta i Microsoft Project igen, och ska jag vara helt ärlig är jag fortfarande, vid femtio års ålder, fortfarande väldigt tveksam till att använda Gantt-scheman i projektplanering.

Ha rätt planeringshorisont

Det är lätt att såväl överplanera som underplanera projekt. I ett överplanerat projekt, som i min anekdot ovan, är planen för rigorös och lämnar inte något spelrum för oförutsägbara händelser. I bästa fall, om nu planen mot förmodan skulle fungera, har du ändå kastat bort för mycket tid och energi på planering. Tid som skulle kanske kunnat användas på ett bättre sätt för att skapa nytta. I ett underplanerat projekt är planen dålig eller saknas helt. Här kan man bara förlita sig på utförarnas förmåga att helt självständigt lösa problemen. Inget av dessa är särdeles lyckosamma vägar att gå. Och i inget av dessa scenarion kan det finnas särskilt stort förtroende för projektledaren, eller hur? Men hjälp! Hur ska man då tänka?

Se projektet som ett träd av produkter

Jag gillar att se på ett projekt som om det vore en produkt. En produkt är något fysiskt, något färdigt, något… användbart. Att se projektet som en produkt får mig att fokusera på projektets resultat snarare än aktiviteterna på vägen dit. Projektprodukten blir då något konkret som någon ska ta emot, någon ska använda i syfte att uppnå någonting. Alltså tätt kopplat till nyttan, projektets effektmål, ja själva syftet med projektet.

Projektprodukten i mitt nätverksprojekt kanske kunde ha beskrivits som en uppgraderad kontorsinfrastruktur som gör kontorsarbetet smidigare och gör det möjligt att installera nästa version av Windows: Ett framtidssäkrat nätverk.

En produkt kan i sin tur brytas ner i komponenter, byggstenar som i sin tur är egna produkter. En bil består av ett chassi, en motor, dörrar, styrning, säten, lack, en instruktionsbok osv. Varje byggsten kan ses som en fristående produkt, som i sin tur kan brytas ner i sina komponenter. Genom att se på projektet som ett träd av produkter, där det är tydligt beskrivet för varje delprodukt vad klart betyder, skapar du en ryggrad för projektets planering. (Vill du läsa mer, se detta blogginlägg: “Definition of done / Vad betyder klart?)

Jag hade kunna brutit ner mitt första projekt i enkla produkter, exempelvis: uppgraderade datorer, installerat nätverk och ny skrivare. Produkten “uppgraderade datorer” hade jag kunnat bryta ner ytterligare i underprodukter, exempelvis Fias dator, Bosses dator, Matz dator och SQL-servern osv.

Planera i etapper

Det första steget i att planera tidslinjen i ett projekt bör vara att dela in projektet i etapper. Varje etapp ska ge mening för mottagaren av projektet, ge ett tydligt värde. En etapp kan enkelt beskrivas som leveransen av en samling produkter, enligt tankegångarna ovan.

Låt oss säga att vi ska bygga ett hus. Den första etappen vara markarbete, nästa etapp vara gjutning av grund, därefter resa ytterväggar och tak och så vidare. Varje etapp kan tydligt beskrivas med en definition av klart betyder . Att planera i etapper gör att det kan finnas planer på olika nivåer, det är bara innevarande etapp som behöver ha en mer detaljerad planering. Visst måste man tänka på hur väggarna ska resas när man gjuter grunden, men det kanske inte är så väsentligt att veta exakt vilken dag det behöver komma en kranbil för att lyfta upp takstolarna än. Det finns alltid behov av omplanering i ett projekt, därför är det bra att bara ha en grov planering för framtida etapper. När man närmar sig etappen kan dess detaljer planeras utifrån förutsättningarna som råder just då.

I mitt exempelprojekt kanske man kunde dela in det i två etapper: förberedelser (när vi skaffar allt material) och installation (när vi utför den fysiska förändringen).

Delegera i arbetspaket

Det arbete du som projektledare delegerar till dina projektmedlemmar kallas arbetspaket. Ett arbetspaket är helt enkelt en eller flera produkter som hänger ihop och lämpar sig för att delegeras i klump. Storleken på ett arbetspaket ska vara så stor så att den som utför arbetet inte känner sig detaljstyrd (då har du överplanerat) men inte större än att du vågar delegera ansvaret (annars har du underplanerat). Arbetspaketet ska innehålla en tydlig definition av vad klart betyder samt ramarna som utföraren ska hålla sig inom (exempelvis tid, mått, material, kostnader eller vad som är relevant för just det arbetspaketet). Arbetspaketet blir som ett kontrakt mellan dig som projektledare och utföraren/utförarna.

I mitt exempelprojekt skulle det till exempel kunna finnas arbetespaketen “beställ hårddiskar och minne”, “installera skrivaren”, “dra nätverkskabel” samt “uppgradera, testa och driftsätt PC”.

Bra projektledning är uppåt väggarna

Instinkten jag hade i början av min karriär som projektledare, att vilja visualisera projektet, var helt rätt. Det är alltid bra att kommunicera och göra projektet synligt och närvarande. Men istället för att sätta upp ett Gantt-schema (eller någon annan form av tidsschema) föreslår jag att du sätter upp en bild av den trädstruktur av produkter som bygger upp ditt projekt. Visst, projektträdet kanske också behöver uppdateras, under resans gång kan det uppstå behov av ytterligare produkter eller ytterligare nedbrytning, men du kommer bli förvånad över hur väl den kommer att stämma genom hela ditt projekt.

Som det borde ha sett ut 🙂

Sammanfattning

Teorin bakom detta sätt att arbeta på kommer från projektmetodiken Prince2.

Att tänka på projektet som ett träd av produkter får dig att fokusera på nytta, funktion, kvalitetsaspekter och beroenden innan du tänker på aktiviteter, resurser och tidsåtgång. Du börjar planera vad och varför före hur, vem och när.

  • Ett projekt är en produkt, som bryts ner i byggstenar/(del-)produkter
  • Varje (del-)produkt ska ha en tydlig definition av vad klart betyder
  • Projektet delas in i etapper, där bara en etapp i taget detaljplaneras
  • Delegera (del-)produkter i arbetspaket

Planeringsnivåer i ett projekt
1. Projektplanen (den grova planen över alla etapper i ett projekt)
2. Respektive etapps plan (en plan för hur etappens produkter ska levereras)
3. Arbetspaket (planen för hur ett eller flera produkter ska levereras)

Känner du igen dig? Tycker du att inlägget var relevant? Maila mig gärna.

Skrivet av: Björn Tångeberg, En Riktig Hävert AB
(C)opyright 2021, En Riktig Hävert AB

Vad betyder klart?

Ett centralt problem för att hålla koll på status av aktiviteter är något så banalt som att man ofta har olika uppfattning om vad “klart” betyder (eng: definition of done). Genom att vara tydlig med att specificera vad “klart” verkligen betyder, kan många missuppfattningar och fel undvikas.

Hur svårt kan det vara att göra en gunga?

Du kanske har sett den gamla skämtteckningen som har stor spridning i ledarskapslitteratur, över hur beställningen av en gunga i ett träd kan misstolkas och missuppfattas. Visst har den en humoristiskt träffsäker igenkänningsfaktor? Vi har nog alla varit med om någonting liknande i projektsammanhang.

Bilden är hämtad från businessballs.com

Vad som är lite deprimerande är att bilden har varit med sedan 1970-talet, kanske är den ännu äldre. Och vi begår fortfarande den här sortens fel. På daglig basis.

Det här handlar givetvis om att förstå beställarens och användarnas krav och behov och säkerställa att varje led i ett projekt verkligen skapar nytta för mottagaren av projektet. Det gäller att tänka i värdeflöde – vad är slutprodukten som ska åstadkommas? Genom att förstå hur någonting ska användas och varför – vad de sökta effektmålen är – minskar man risken att någonting tas fram som inte är den rätta lösningen på det ursprungliga problemet.

Men det finns mer i den här djupa brunnen att ösa ur. Ofta finns det också olika perspektiv beroende av vilken del av värdekedjan man tillhör. För någon som är utförare av en uppgift betyder “klart” oftast att “mina” arbetsuppgifter är slutförd. Men för en användare betyder det att det ska vara användbart. Det innebär också att det som levereras ska vara testat, driftsatt och överlämnat. Men det finns också andra roller och perspektiv. För en beställare, till exempel, betyder nog “klart” dessutom att arbetet är dokumenterat, att det har överlämnats till de som ska drifta och att det är korrekt avrapporterat.

Nyckeln till effektivt ledarskap

Genom att i en organisation bli bra på att definiera och följa definitionen av “klart”, i stort och smått, ökas effektiviteten och risken minskas för onödigt arbete. Att delegera tydliga uppgifter ökar den enskilda medarbetarens möjlighet till självständighet och minskar behovet av detaljstyrande ledarskap. En tydlig definition av vad som förväntas blir som ett kontrakt mellan den som delegerar och den som uppgiften delegerats till.

Givetvis räcker det inte att bara definiera “klart” på pappret. Du måste även kommunicera och säkerställa att den du delegerar till verkligen har förstått uppgiften. Mänsklig kommunikation sker alltid på mottagarens villkor. Därför är det viktigt att du stämmer av att du och den som ska utföra uppgiften har samma bild av vad “klart” betyder.

Till sist: en checklista och en minnesregel

Som ledare är det en av de viktigaste uppgifterna att var tydlig med vad en uppgift innebär, att säkerställa vad “klart” betyder.

Checklista
1) Har jag tydligt beskrivit hur det som levereras ska användas? (Funktion)
2) Har jag tydligt beskrivit syftet, vad beställaren vill uppnå? (Effektmål)
3) Har jag tydligt beskrivit vad arbetspaketet innehåller? (Scope)
4) Har jag tydligt beskrivit vad “användbart” betyder? (Kvalitetskrav)

Minnesregel
Om du inte tydligt har kommunicerat uppgiften, blir det bara FESK av alltihop!
(F)funktion, (E)ffektmål, (S)cope, (K)valitetskrav

Kvalitetssäkring
Låt den du delegerat till få berätta för dig hur uppgiften uppfattats: Varför är uppgiften viktig? Hur ska mottagaren använda den? Vad ska utföras? Vilka är kvalitetskraven? Ibland kanske du även ska ställa frågan hur den som ska utföra uppgiften tänker att utförandet ska ske.

Tycker du att detta var relevant? Skriv mig gärna ett e-mail med dina synpunkter!

Skrivet av: Björn Tångeberg, En Riktig Hävert AB
(C)opyright 2021, En Riktig Hävert AB