Snabbkurs i projektledning

Snabbkurs i projektledning

View more PowerPoint from Erik Fors-Andrée

Tre säkra tecken på att ditt projekt misslyckas

Jag hör ofta projektledare, beställare och leverantörer berätta med lättnad om sina nystartade projekt - äntligen är man igång! Beskrivningar kan tyckas självklara och låter väldigt bra när man berättar det för överordnade. Det känns tryggt och väl genomtänkt.

Ändå är det precis tvärtom. Redan i starten av ett IT-projekt finns det vissa mycket tydliga indikationer på att det kommer att bli ett problemprojekt.

Tre tillfällen då du direkt bör bli misstänksam

"Vi vet precis vad vi vill ha"

Det här är det största tecknet på att projektet inte kommer att lyckas. I ett IT-projekt vet man aldrig exakt vad man vill ha. Man kan ha en relativt tydlig bild av den nytta man vill uppnå, men bilden av hur den nyttan ska uppstå kommer hela tiden att förändras under projektets gång.

IT-utveckling är en innovationsprocess, det vill säga man tar ett steg, går tillbaka och utvärderar, tar ett nytt steg och utvärderar igen. Hela tiden måste man se till att det man skapar faktiskt löser de problem man vill lösa - och anpassa sig efter de följder det för med sig. Det är inte ovanligt att när man gjort en del av projektet blir det tydligt att det ursprungliga problemet har förflyttats och att projektet måste byta fokus.

"Vi vet precis vad vi vill ha" ger illusionen av att det vi ska skapa är något exakt förutsägbart. Men det kommer att förändras under projektets gång.

"Det ingår i produkten" eller "Allt går att lösa"

Alla IT-produkter innehåller en mängd funktionalitet och leverantörerna tävlar ofta om vem som har flest funktioner. Men det som avgör om det är rätt produkt är inte mängden funktioner, utan hur väl de svarar mot den verksamhetsnytta projektet ska leda till.

När man säger att "Det ingår i produkten" har man gjort något mycket farligt: Man har reducerat den verksamhetsnytta som projektet ska uppnå till att vara en bestämd funktion med ett bestämt utförande. Hur funktionen är utformad, hur den passar in i organisationens arbetsflöden och vilken användarnytta den skapar är helt avgörande för om den kommer att användas. Nyttan finns aldrig i produkten, den uppstår när produkten används.

"Vi får bygga tekniken först".

Nyttan av teknik uppstår när tekniken används. Av den anledningen måste nyttoperspektivet komma först och alltid vara tongivande. "Vi får bygga tekniken först" är ett tecken på att man inte tänkt tillräckligt på nyttan och på att man inte kommer att styra projektet med nyttan i fokus.

Tekniken får aldrig gå före - och i det ligger också att man inte kan börja med att bygga teknik och sen "lägga på" allt "det andra". Det gäller hela vägen: Från den tekniska infrastrukturen till slutresultatet av projektet. Ska man lyckas med projektet - det vill säga uppnå en nytta i verksamheten - så måste man jobba parallellt med teknik, innehåll, design och arbetssätt.


Har du fler exempel på indikationer på projekt som kommer att misslyckas?

En Definition of Done ska alltid ha en mottagare

En Definition of Done handlar om att ha en gemensam definition för när något är klart i ett projekt. En definition av klart specificerar vad som är en tillräcklig kvalitetsnivå och ser till att vi har samma bild av vad som ska uppnås. Utan en definition av klart kommer man alltför ofta att få missförstånd och scope creep, det vill säga att projektet växer okontrollerat.

5 januari
— Vi behöver ha produktionssättning i mars
— Ok, inga problem!
26 mars
— Nu är det klart!
— Bra, då lanserar vi om en vecka
— Naahh... Först måste vi installera och konfigurera servern. Och sätta upp brandväggen. Och lastbalanseraren.

Vad kan man lära sig av det här?
"Produktionssättning" kan betyda väldigt många saker. I det här fallet har det tolkats som att de fysiska servrarna finns på plats i serverhallen. Men de är inte konfigurerade och programvaran är inte installerad. Lastbalanserare och brandvägg som också måste installeras är inte heller på plats. Dessutom kan man fråga sig om själva webbplatsen som ska driftas på servern är färdigutvecklad? Testad?

Tips: Se till att din definition av klart alltid inkluderar den person som ska ta emot det ni skapat. Till exempel: "Produktionsklart för att externa användare ska kunna testa webbplatsen". Det tvingar alla inblandade att precisera sig och det leder samtidigt till att man får större koppling till verksamhetsnyttan. 

Hur man gör en intressentanalys för projekt

Definition: Intressenter är alla personer som på något sätt kommer i kontakt med projektet eller det resultat som projektet levererar

Intressentanalys (eller stakeholder analysis) behöver precis som riskanalys inte vara varken svårt eller tidskrävande. Det tar inte mer en halv till en dag men är ett underlag som du har användning av under hela projektet. 

Intressentanalys i fyra steg

1. Identifiera alla tänkbara intressenter.

Sätt dig som projektledare tillsammans med några andra personer (projektteamet, projektbeställaren eller andra) och brainstorma kring vilka personer och grupper som på något sätt kommer att vara i kontakt med projektet eller ta del av resultatet. Skriv upp alla intressenter på en whiteboard, det blir mer kreativt. Ju mer ni skriver desto bättre, analysen kommer sen. Så strunta i vad som är rätt och fel.

Vanligen hittar man intressenter inom följande områden:

1. Personer eller grupper av personer som kommer att jobba i projektet. 
2. Personer eller grupper av personer som har en ledande befattning och ett direkt ansvar för projektet.
3. Personer eller grupper av personer som föväntar sig att påverka projektet, men som inte har ett direkt ansvar för projektet (till exempel chefer på andra avdelningar).
4. Personer eller grupper av personer som kommer att använda resultatet av projektet. 
5. Informella ledare och nyckelpersoner som har stort inflytande över andra utan att själva vara i chefsbefattning.
6. Kunder som ska ta del av projektet eller dess resultat. 
7. Leverantörer som ska ta del av projektet eller dess resultat. 
8. Andra företag och myndigheter som har ett intresse av projektet eller dess resultat.

2. Gör en enkel analys av intressenterna.

Bedöm intressenterna utifrån exempelvis nedanstående frågeställningar. Hinner ni på workshopen så kan ni gör det tillsammans, annars gör du det själv och stämmer av med till exempel projektägaren så att ni har samma syn.

1. Hur stort inflytande har personen eller gruppen? Försök värdera intressenterna i förhållande till varandra, till exempel genom att skriva den som har störst inflytande längst upp.
2. Är det en person eller grupp som huvudsakligen påverkar projektet eller påverkas av projektet?
3. Vad har personen eller gruppen för inställning till projektet, är de positiva eller negativa? 

3. Fundera på hur ni ska nå intressenterna.

Börja med de intressenter som har störst inflytande. Fundera på följande två frågor:

1. Fundera på vad din roll som projektledare är gentemot intressenten. Ska du informera, rådfråga, involvera eller få beslut? 
2. När och hur ofta ska vi nå ut till denna intressent? Styrgruppen kanske vi når genom styrgruppsmöten en gång i månaden och statusrapporter en gång i veckan. VD kanske vi når till genom personliga avstämningsmöten varje kvartal. Andra intressenter kanske ska bjudas in till återkommande avstämningsmöten (till exempel scrum demo). 

4. Använd intressentanalysen

En intressentanalys är inget statiskt dokument. Den ska gås igenom och uppdateras med jämna mellanrum under projektet. Bestäm till exempel att du tittar igenom den en gång i månaden för att se om något förändrats: Är det någon person eller grupp som tillkommit eller fallit bort? Är det någon som vi behöver nå till oftare?Följ upp att de avstämningsmöten som ni kom fram till i intressentanalysen faktiskt genomförs.

Ansvar för intressentanalys

Det är projektledarens ansvar att se till att alla intressenter har tillräcklig information och är tillräckligt involverade i projektet. Projektledaren bör alltid själv sköta kontakterna med överordnade intressenter, medan andra intressenter kan vara ett mer gemensamt ansvar i projektgruppen.

Min uppfattning är att projektledaren själv måste kunna sköta eller i alla fall delta i kommunikationen hela vägen upp i organisationen, till exempel med projektägarens chefer.

Leverantörens vs. beställarens ansvar i webbprojekt - Svar till Per Vikström

Per Vikström tar upp ett otroligt intressant ämne: "Leverantör vs beställare i webbprojekt – vem ska leda och vems är ansvaret?" Det är en diskussion som är alldeles för underskattad!

Låt mig säga direkt: Det yttersta ansvaret för projektet ligger hos projektbeställaren. Det går inte att skylla ett misslyckat projekt på dåliga konsulter, för som projektbeställare är det ditt ansvar att ha bra konsulter. Allt annat är undanflykter och ansvarsflykt.

Dåliga projektbeställare är en mycket större orsak till misslyckade projekt än dåliga konsulter.

På engelska finns två ord: Responsibility och Accountability. Ska man hitta en vettig svensk motsvarighet så får det bli Ansvar och Yttersta ansvar. Teamet har ett gemensamt ansvar för att projektet lyckas, uppdragsgivaren och konsulten måste jobba ihop för att lyckas. Men det yttersta ansvaret ligger fortfarande på projektbeställaren. 

President Truman hade skylten "The Buck Stops Here" på sitt skrivbord. En Buck är en kniv som gamla poker-spelare stötte i bordet framför den som skulle blanda och ge, men som kunde skickas vidare om personen inte ville ta ansvaret. Trumans skylt är ett exempel på Accountability, härifrån skickas inte ansvaret vidare.


Jag gillar inte hierarkisering, utan tycker att man ska hitta så platta strukturer som möjligt och ha en ledare som är en del av teamet. Men det kvarstår alltid att det finns ett yttersta ansvar. Så här skulle jag vilja se det:

1. Projektbeställare (med stöd av styrgrupp)
2. Intern projektledare (beställare av konsulttjänster)
3. Kundansvarig hos konsultföretag (ofta konsultföretagets projektledare)

Gemensamt för alla parter tycker jag är att man måste ta ett ansvar för att förstå och sätta sig in i verksamhetsnyttan som projektet ska uppnå. Trots att man jobbar med olika specialiseringar och ska fokusera sin energi på det, så är verksamhetsnyttan som ska uppnås gemensam för alla parter.

Det här är konsulter väldigt ofta dåliga på. Självklart har konsulterna ett mycket stort ansvar för att projektet lyckas. En bra konsult ifrågasätter projektbeställaren, hjälper projektbeställaren att fatta rätt beslut och döljer inget för projektbeställaren. En bra konsult måste ha integriteten att säga till när projektbeställaren gör fel (ytterst till och med vara beredd att avsäga sig uppdraget).

Per, håller du med? Någon annan som vill dela med sig av sin syn, till exempel Erik Sjöberg, Raphael Sedin, Tobias Fors, Charlotte Grass eller Ulrika Park? Konsultchefer, beställare?

Hur man gör en riskanalys för projekt

Definition: Risk är allt som kan hindra oss från att nå projektets mål.

Riskanalys (eller riskvärdering, riskbedömning, riskstyrning) behöver inte vara så svårt och tråkigt som man kanske först tror. En bra riskanalys gör man på en halv till en dag och har sedan som stöd under hela projektet.

Riskanalys i fyra steg

1. Identifiera alla tänkbara risker.

För att identifiera risker, sätt dig som projektledare tillsammans med några andra personer (projektteamet, projektbeställaren eller andra) och brainstorma kring följande frågeställningar. Skriv upp alla idéer på en whiteboard, det blir mer kreativt. Ju mer ni skriver desto bättre, analysen kommer sen. Så strunta i vad som är rätt och fel. 

1. Vilka är förutsättningarna för att lyckas?
2. Vilka framgångsfaktorer finns?
3. Vad har vi för resurser idag?
4. Vad kan gå fel?
5. Vad har gått fel i liknande projekt tidigare i organisationen?
6. Vilka resurser saknar vi?

Punkt d, e och f är risker rakt av. Punkt a, b och c formulerar du om lite för att göra det till en risk. Om det till exempel är en framgångsfaktor att vi rekryterar en delprojektledare, så är risken det omvända: att vi inte lyckas rekrytera en delprojektledare. Eller om vi idag har Lisa i vårt projektteam, så är risken det omvända: Att Lisa slutar eller blir sjuk.

2. Bestäm vilka risker som är värst. 

Bedöm vilka risker som är värst. Hinner ni på workshopen så kan ni gör det tillsammans, annars gör du det själv och stämmer av med till exempel projektägaren så att ni har samma syn.

Ett tips för riskbedömningen är att skilja på två kriterier:

1. Sannoliketen att risken inträffar (till exempel att Lisa slutar)
2. Konsekvensen om risken inträffar (sitter Lisa på en unik kompetens i företaget så är konsekvensen större än om det finns andra personer som kan ta över hennes uppgifter)

Sätt ett värde 1-5 för sannolikheten på varje risk. Och ett värde 1-5 för konsekvensen. Multiplicera de två. Exempel: 

Risk: Lisa slutar
Sannolikhet: 2 (Lisa har en mycket bra profil och det finns andra arbetsgivare som gärna skulle anställa henne. Å andra sidan har hon uttryckt att hon trivs väldigt bra och inget pekar på att hon skulle sluta.)
Konsekvens: 4 (Den kompetens Lisa sitter på kommer att vara svår att ersätta. Och även om vi hittar en ersättare så kommer vi att förlora mycket värdefull tid i projektet om Lisa ska lämna över till någon annan.)
Riskbedömning: 2 x 4 = 8

3. Fundera på vad man kan göra åt riskerna

Börja med de risker som är värst, det vill säga fick högst värde i riskbedömningen. Fundera på lösningar för att minska sannolikheten och för att minska konsekvensen:

1. Vad kan vi göra som minskar sannolikheten för att Lisa slutar? Kan vi ge henne bättre lön och anställningsvillkor? Förbättra arbetsmiljön? Ge mer utmanande arbetsuppgifter? 
2. Vad kan vi göra som minskar konsekvensen av att Lisa slutar? Kan vi dokumenter Lisas arbete mer så en överlämning blir enklare? Kan vi påbörja kompetensutveckling av andra medarbetare?

Risker kan också hanteras på andra sätt.

4. Använd riskanalysen

En riskanalys är inget statiskt dokument. Den ska gås igenom och uppdateras med jämna mellanrum under projektet. Bestäm till exempel att du tittar igenom den en gång i månaden för att se om något förändrats: Är det något du måste agera på? Har sannolikhet eller konsekvens ökat på något område? Har någon risk tillkommit eller undanröjts?

Ansvar för att hantera risker

Risker som ligger utanför projektets ramar är styrgruppens ansvar. Det är dock projektledarens ansvar att följa upp och se till att det blir gjort. Mina tankar kring det kan du läsa mer om i Projektledarens och styrgruppens ansvar för riskhantering.

Tro inte att du kan förändra världen - uppfinn en ny!

Förra veckan var jag på workshop om en ny webbsatsning. Efter en heldag med mycket kreativitet och djupa analyser var hela gruppen helt överens om vikten av att genomföra satsningen. Man hade också en gemensam syn på de nya produkter och arbetssätt som detta skulle medföra.

Sista delen i workshopen handlade om prioriteringar av aktiviteter för att skapa den nya webblösningen. Snabbt var man överens om att första steget är att genomföra strukturförändringar. "Om vi inte förändrar personalstrukturen och prismodellen kommer vi inte att lyckas."

Förståelsen för webben har ökat enormt de senaste åren. Men det här ett exempel på att det är långt kvar. Det är visserligen sant att strukturfrågorna måste lösas, men problemet här är att webben förändrar förutsättningarna i grunden. Det är webben som ska lösa strukturfrågorna och prismodellen. Allt annat är att försöka klistra och lappa med det gamla, istället för att faktiskt jobba med det nya.

Jag tror att en framgångsrik väg för att verkligen lyckas ta en organisation in i webbåldern, är att sluta förändra det gamla och istället bygga nytt. Istället för att bryta upp alla befintliga strukturer, system och arbetssätt - bygg nya på sidan om. Fler och fler kommer att ansluta sig till det nya. Tänk förtrupp!

(Tips: Läs också om Alexander Bard på Webbdagarna.)

Webbstrategisk ABC

Väldigt grovt så finns det bara tre skäl till att en del webblösningar aldrig blir riktigt framgångsrika.

Web Strategy Basics on Prezi

1. Man lyckas inte få tillräckligt många besökare. Annonsboken är en köp-och-sälj-sajt som är väldigt lik marknadsledande Blocket. Upplägget är detsamma och utseendet rätt likt. Och Annonsboken är inte ensam, det finns en uppsjö Blocket-kopior. Skillnaden är att Blocket har användare, det har inte de andra. Annonsboken har just nu 83 annonser i Stockholm och det är nästan lite ironiskt att Blocket har exakt 100.083 i Stockholm.
2. Man lyckas inte tillfredsställa besökarnas behov. Google Wave var 2009 års största besvikelse för användarna. Tack vare Googles storlek och den hype man skapade inför lanseringen, så har Wave många användare. Affärsmodellen är annonsintäkter, och det kan nog fungera lika bra där som i till exempel Google Mail. Men tjänsten tillfredsställer inte avnändarnas behov. Bland de som provar, rapporterar en efter en att de inte förstår poängen.
3. Man lyckas inte hitta en affärsmodell som gör satsningen motiverad. Lulilab är en community för ungdomar. Sajten har över 350.000 sidvisningar i månaden och användarna är i stor utsträckning nöjda med tjänsten. Men intäkterna är i princip lika med noll. (Om någon som läser detta har en lysande intäktsmodell för Lulilab så hör av er, så förmedlar jag kontakten.)

Det är webbstrategins ABC. På ett sätt är det helt självklart. Men av någon anledning blir det ändå bortglömt.

Min egen YABA 2010

Idag annonserades vinnarna i YABA (Yet Another Blog Award). YABA arrangeras av webbyrån Daytona för att "uppmärksamma de bloggar som inspirerar oss mest inom marknadsföring, affärsutveckling och annat med digital anknytning".

Jag har inte haft nån blogroll på den här bloggen. Istället har jag aggregerat poster från de bloggar jag läser. Nu är det dags att utse de som får en fast plats i blogrollen istället. Här nedan är därför min egen Yaba 2010.

Gör din egen Yaba!

1. Bestäm 2-4 kategorier.
2. Gå igenom din Google Reader, Friendfeed, Feedburner, webbhistorik, blogroll etc. och placera bloggarna du läser i respektive kategori.
3. Utse en vinnare i varje kategori. Vad läser du oftast, vad kommenterar du oftast och vad är helt enkelt bäst?
4. Skicka länken till Din Yaba till mig (i en kommentar till det här inlägget, på Twitter eller på nåt annat sätt), så länkar jag till tillbaka till dig ;)

Min YABA 2010

 

Projektledning, IT-projekt, ledarskap

För att lyckas krävs ett mål, en plan och ledarskap. De här bloggarna ger verktygen och erfarenheten för att lyckas.

Vinnare, Sveriges bästa blogg:

• Erik Sjöberg, På tal om projekt...

Nominerade:

• Tobias Fors, Trying to Make Software Development Understandable 
• Ulrika Park, Projektledning och systemfilosofi 
• Raphael Sedin, Projektledare IT Bloggare 
• Charlotte Logra, Projektledning med affärsfokus
• Projektplatsen, Projektbloggen
• Lena Ahlström, Vinnande ledarskap
• Lars Hornborg, Ledarskap, förändring och personlig utveckling
• Per Vikström, @Internet
• Mats Henricsons blogg

Nätkultur och nätsamhället

En kultur är ett sammanhängande system av trosuppfattningar, beteenden och normer. Här är de bloggar som beskriver och diskuterar kulturen på och kring nätet.

Vinnare, Sveriges bästa blogg:

• Peter Forsman, Internet Sweden

Nominerade:

• Elza Dunkels, Nätkulturer
• Pontus Sundén, Lärande i vårt digitala samhälle
• Rättssocologiska enheten vid Lunds universitet, Cybernormer
• Vuxenkontraktet
• Marcin de Kaminski, Kring internet, nätkulturer och därtill relaterat
• Anders Millner, om nya medier, ny kultur
• Erik Johansson, Slowmove
• Waldemar Ingdahl
• Stefan Deak, strategi, affärsutveckling och kommunikation - online

The Two Governing Dynamics of Change

1. Change is difficult but necessary

We are all afraid of trying something new. It's just natural. We are creatures of habit, we do what we are used to and what we are good at. We want to get it right, we want to know what's coming up, we want to keep what we have. People in power want to keep their influence and will fight to preserve things how they are.

On the other hand we all strive for change. The essence of achieving anything is risk-taking, if we don't take a risk we cannot evolve, be it in business, in family or in society.

This is the First Governing Dynamic of change: We all need it, but we are afraid of it.

2. Change is personal, but most change is for a greater purpose

Change always occurs in a context. The management wants to change how we do our work, the authorities want to change how we pay our taxes, or our family wants to change what we do together. When someone wants something to change, it almost always involves others.

But we are all motivated by self-interest. Unless we see a personal winning we wont act. That personal winning may be anything from getting a pay-raise or learning semething, to being loved or just the feeling of having helped someone else.

This is the Second Governing Dynamic of Change: Unless the self-interest is greater than the common-good, change wont happen.

Så får du saker gjorda med Getting Things Done (GTD) i gMail

2005 läste jag en bok som kraftigt förändrade mitt sätt att tänka och jobba. Sedan dess har jag läst den igen ett flertal gånger, läst uppföljarna, läst ett tiotal relaterade böcker samt följer ett antal bloggar och författarens eget nyhetsbrev.

Den boken var Getting Things Done av David Allen.

Getting Things Done (GTD som det ofta förkortas) är en metod för att öka sin personliga produktivitet. Helt enkelt: Få saker gjorda. Getting Things Done utgår från hur mänskligt beteende faktiskt fungerar, till skillnad från de flesta andra handböcker i produktivetet som bygger upp onaturliga arbetssätt och teoriska idealkonstruktioner som inte fungerar i praktiken.

Googlar man på GTD får man över fem miljoner träffar. Och det har växt fram mängder av hjälpmedel för att jobba enligt GTD. Jag tycker tyvärr att många gör det mer komplicerat än det behöver vara. David Allen är pragmatisk och skriver att det fungerar lika bra med papper och penna som med webbaserade verktyg. Häromdagen ställde Mattias Östmar en fråga på Twitter om vilka verktyg folk använder. Jag kör GTD i gmail, då har jag det alltid tillgängligt, det är flexibelt, inga extra inloggningar och jag kan direkt flytta saker mellan GTD, mejlen och kalendern. Jag ska beskriva hur jag gör, men först försöka mig på att ge en mycket kort introduktion till GTD.

Grundprinciperna i GTD i fyra steg

 

1. Skriv ner allt. Och då menar jag ALLT, både det du ska göra, vill göra, har tänkt på att göra och inte gjort. Stress och svårigheter att koncentrera sig på en uppgift beror helt enkelt på att man har för mycket att tänka på, även om man kanske inte är medveten om det. Jag skulle ju köpa mjölk, jag måste skriva ett nytt blogginlägg, jag måste komma ihåg att boka tvättid, jag vill gå på bio, den där skivan kanske jag kan köpa, jag borde laga spisen, chefen ville ha ett möte, jag behöver få svar från Anna, när ringde jag mamma sist och så vidare och så vidare. När allt är nerskrivet kommer hjärnan att släppa taget och man kan fokusera på en sak i taget.
   
2. Bestäm om du ska agera. Många av de saker du skrivit ner kommer att vara sånt du inte direkt ska agera på.
   
   • Ska det göras "snarast" så sortera det i en hög.
   • Ska det göras på ett visst datum så ska det skrivas in i kalendern.
   • Väntar du på att någon annan ska göra något så sortera det under rubriken "Väntar på". Det kan till exempel vara "väntar på svar från chefen angående semester" eller "väntar på skivan jag beställde".
   • Är det mer en idé som egentligen inte behöver någon snar åtgärd så sortera det under rubriken "Nångång/kanske". Till exempel "den här skivan kanske jag ska köpa" eller "det vore kul att besöka Paris". 
   • Ska det inte göras alls så ska det slängas bort eller arkiveras.
3. Bestäm nästa konkreta steg för de saker som ska göras snarast. Den allra första saken du behöver göra, är det enda din hjärna verkligen kan förstå och agera på, men den behöver hjälp att hitta dit. Om du har "skriva mejl till chefen" på din att-göra-lista, men det aldrig blir gjort, så fundera på vad nästa steg egentligen är. Ändra benämningen på åtgärden till exempelvis "plocka fram papperet med uppgifterna som chefen ville ha". När du väl plockat fram papperet kommer du troligen inte att skjuta upp på att skriva mejlet. Och att ta fram papperet är greppbart för hjärnan.
   
4. Sortera efter kontext. Sortera de konkreta åtgärder du ska göra snarast, efter vilken kontext de ska göras i. Om du har "köp mjölk" på din att göra-lista, så ska du köpa mjölken när du ändå är i affären, även om du har 10 andra saker att göra som är "viktigare". Eller så här: Det spelar ingen roll hur hög prio det är på "skriva ut rapporten", så länge du inte är vid skrivaren kan du inte göra det. Så istället för att prioritera, sortera de saker du ska göra i listor som "Hemma", "På kontoret", "I affären", "Vid nästa möte med chefen". Här gäller det att du skapar en uppsättning kontexter som fungerar för just dig.

GTD i gMail

Jag har gjort enklast möjliga uppsättning av GTD i Google Mail. Jag använder gMails etiketter, färgmärkning samt filter. Det ser ut så här (i det här fallet visas kontexten "Läsning":

1. Inkorgen används på det sätt som David Allen beskriver för insamlingen av allt som ska göras. När något ska skrivas upp så mejlar jag till mig själv. En mycket stor del av de saker som ska göras har dessutom sitt ursprung i mejl från andra, då behöver de bara sorteras. I exemplet syns att jag har 7 olästa mejl i inkorgen, målet är att den ska tömmas hela tiden och det som ligger där fördelas ut enligt nedan.
2. De gröna etiketterna med namn som inleds med K är kontexter. I det här fallet har jag klickat på kontexten "Läsning", där jag har sånt som jag vill läsa när jag har lite tid över. (Bilden är redigerad och visar bara några av mina kontexter.)
3. De bruna etiketterna med namn som inleds med P är projekt. För David Allen är allt som omfattar mer än en åtgärd, i själva verket ett projekt. Jag använder inte riktigt den synen på projekt, utan definierar projekt lite smalare. En åtgärd kan ha både en grön kontext-etikett och en brun projekt-etikett. (Bilden är redigerad och visar bara några av mina projekt.)
4. Här syns de åtgärder som ligger i den aktuella vyn ("Läsning"). I det här fallet har samtliga åtgärder fått etiketten "Läsning" automatiskt genom ett filter i gMail (se nedan).

Så sätter du upp GTD i gMail

1. Skapa dina etiketter. Klicka på Inställning och därefter Etiketter (eller här) och skapa etiketter för de kontexter och projekt du vill ha.
2. Färgsätt etiketterna. Klicka på den lilla ytan framför etiketten där den visas till vänster i gMail. Du får en liten meny med färgval.
3. Börja sortera. Enklast är att dra-och-släppa. Klicka på den lilla prickade ytan längst till vänster om varje åtgärd/mejl. Det går också bra att öppna mejlet och välja i menyn "Etiketter".
   
   
   
   
4. Skapa filter. Vissa delar i flödet kan effektiviseras med hjälp av gMails filter. Jag använder det dels för kontexten "K/Läsning" och "K/Betalningar". Och dels för att sätta många av de bruna projekt-etiketterna. I båda fallen använder jag filter baserat på Från-adress. Mejl som är skickade från familjen hamnar i K/Fam och det som är relaterat till betalningar jag ska göra hamnar i K/Betalningar (här har jag faktiskt också ett filter på mejlets ämne). Och nyhetsbrev, prenumerationer och liknande hamar i K/Läsning. För att skapa ett filter, klicka på "Skapa ett filter" till höger i sökrutan och följ gMails instruktioner.
   
   
   
5. Ändra namn. Om du ska göra flera åtgärder efter varandra, ändra ämnet för mejlet genom att vidarebefordra det till dig själv (där finns ett fält för att ändra ämnesrad).
6. Tips: Du kan mejla direkt till en etikett. Om du skapar filter som fångar alla mejl vars ämnesrad innehåll till exempel #Betalningar så behöver du bara skriva in #Betalningar så får mejlet automatiskt rätt etikett när du skickar det.

Läs också
karatekoll.se, en blogg på svenska om GTD och personlig effektivitet
Fleecelabs.se, Kom igång med GTD på det nya året!
Macworld, Så ordnar du upp ditt liv med GTD-metoden

GTDinbox - GTD i gMail i Firefox
GTDinbox är en addon till Firefox för att köra GTD i gmail. Jag använde den under en kort period men tyckte att den tillförde mer komplexitet än värde - och jag blev beroende av just den webbläsaren.

Projektledningens fem dödssynder

Chaos Manifesto listar fem dödssynder och fem budord för projektledning. Att behärska dessa tio punkter är en av alla de framgångsfaktorer som enligt deras forskning ligger bakom lyckade projekt. Här kommer min version av de fem dödssynderna, budorden går jag inte in på just nu (själva punkterna kommer från Chaos Manifesto, medan beskrivningar och exempel är mina).

1. Överambition. Överambition handlar om att man som projektledare eller projektbeställare tar på sig för mycket på en gång. Man vill skapa mer än vad som egentligen är nödvändigt och man förblindas av allt som "går" att göra. Med teknik går i princip allt att göra. Men inte samtidigt, inom samma projekt och inte med en begränsad budget. 

2. Prestige. Prestige hänger ofta, men inte alltid, samman med överambition. Det handlar om att man som projektledare har en arrogant eller övermodig attityd gentemot projektmedlemmar, beställare och chefer i organisationen. 

Eftersom projekt ofta får en särställning i den traditionella linjeorganisationen är det förklarligt att en viss prestige-känsla ibland uppstår. Och många gånger kan det nog också vara en fördel, till exempel för att svetsa samman teamet för att effektivt jobba mot samma mål. Samtidigt får projektet förstås inte förlora verklighetsförankringen eller börja motverka linjeorganisationen. 

3. Okunskap. Okunskap kan finnas på alla håll i ett projekt: Hos projektledningen, hos projektmedlemmarna, hos projektbeställaren och hos linjeorganisationen. Dålig kunskap om projektets mål och verksamhetens övergripande mål leder snabbt till att projektet går i fel riktning eller havererar. 

Jag tror att det till exempel ofta finns en tendens hos projektägare och styrgrupp att inte informera projektledaren fullt ut. Framförallt i stora organisationer finns ofta många olika viljor och projektledaren får inte full insyn i högsta ledningens agenda, även om den i många fall påverkar projektet. 

Chaos Manifesto nämner också det omvända förhållandet, alltså att styrgrupp och projektägare inte informerar sig tillräckligt om projektet. De kallar det "rational ignorance", det vill säga man upplever att det kostar mer att hålla sig informerad än vad man själv får tillbaka av det. Båda dessa faktorer tycker jag är mycket viktiga att tänka på för projektledaren så att man kan undvika problemen. Själv ska jag i framtida projekt försöka att konkret räkna på projektägarens "kostnad" för för att ha tillräcklig information: Hur minskar man tiden som behöver läggas ner samtidigt som rätt information når fram? Hur ser kalkylen ut? 

4. Frånvaro. Frånvaro kan bero på en mängd faktorer. Frånvaro av projektmedlemmar blir väldigt synligt eftersom det blir ett direkt produktionsbortfall. Man upptäcker det snabbt och kan vidta åtgärder. Det som kan vara svårare att hantera är när viktiga beslutsfattare, projektbeställare eller styrgrupp är för frånvarande. Många personer kan ha ett intresse av projektets resultat, tyvärr är det inte alltid man kopplar det intresset till en insats i tid. Jag brukar säga att vill man vara med och påverka eller bestämma, så får man räkna med att det tar tid. Ger man det tid, så är det nästan alltid en fördel för projektet att fler är med. Men få saker kan skada ett projekt så mycket som när olika personer förväntar sig att påverka och vara med i de beslut som fattas utan att själva lägga ner någon tid på det. "Vi tittar när ni tagit fram en första version" eller "Här är våra guidelines, men vi kan inte vara med i arbetet" är två exempel på situationer som jag tycker man ska se upp med. Vill någon påverka så ska de vara med när besluten fattas, inte som en kontrollmaskin i efterhand. 

5. Oärlighet. Oärlighet i det här sammanhanget är till exempel att medvetet undanhålla fakta från projektägare eller projektmedlemmar. Det kan handla om att skapa fördelar för sig själv, men i många fall handlar det nog också om att man som projektledare helt enkelt inte vågar berätta hela sanningen.



Not: De sju ursprungliga bibliska dödssynderna är: Lättja/liknöjdhet, Högmod/arrogans, Avund, Frosseri, Girighet, Vrede, Liderlighet. Bilden: Hieronymus Bosch, De sju dödssynderna (cirka 1480, Pradomuseet, Madrid)

Projektledaren måste ta ansvar för verksamhetsnyttan

Joakim Holm ifrågasätter den traditionella synen på lyckade projekt och ber läsaren att själv tänka efter: "fundera på vad du tycker att det borde innebära om någon säger att ett projekt blev lyckat. Och stopp! Försök att komma förbi den där inlärda definitionen. Vad känner du i magen vore rätt?"

Självklart har han rätt: Ett lyckat projekt kan inte bara definieras till "klart i tid, klart i budget, projektmålen uppfyllda". Det handlar istället om nyttan man åstadkommer i verksamheten, av effekten som uppstår av den satsning man gör. Får vi ökad försäljning tack vare införandet av nytt CRM-system? Blir vårt arbete effektivare tack vare nytt system för processtyrning? Blir sjukvården och Socialtjänsten i Sverige säkrare tack vare bättre information online?

De mätningar som görs utgår generellt från övertrasserad budget eller tidsplan, eller underleverans av funktionalitet. När jag läser den här typen av studier slås jag ofta av att man har så bakvänd syn på vad projektet ska leverera. Chaos Manifesto, som är den största undersökningen av lyckade och misslyckade IT-projekt, nämner bland annat att i genomsnitt 33% av funktionerna som ska produceras, aldrig blir levererade. Här bör man förstås direkt fråga sig: Vad spelar det för roll? Huvudsaken är väl att man levererade de funktioner som faktiskt skapar nytta? Det finns ju inget egenvärde i att leverera funktioner bara för att man en gång trodde att de behövdes. Sannolikheten för att man behöver allt man trodde är i praktiken till och med extremt låg.

Men ändå: Essensen av de undersökningar som görs, hur man än vrider och vänder på det, är faktiskt korrekt. KTH-professorn Torsten Cegrell som uttalar sig i en artikel i Computer Sweden har rätt: Det är fruktansvärt frustrerande att miljarder och åter miljarder i IT-investeringar är bortkastade pengar. Oavsett om studierna har märkliga utvärderingskriterier, så kvarstår det faktum att man kastar bort enorma summor pengar på projekt som inte ger önskad nytta.

Ofta finns också andra mätpunkter med i studierna, men de får inte lika stort genomslag i media. Chaos Manifesto till exempel har också uppgifter som mer närmar sig en mätning av nyttan. Som jag skrivit tidigare angående Chaos Manifesto:

Här finns dock en annan mycket viktig faktor att tänka på. Av de levererade funktionerna kommer bara 20% nånsin till användning. Det pekar på ett annat och egentligen ännu djupare problem: Man mäter fel saker. Projekt mäts vanligen genom att utvärdera om de levererats i tid, inom budget och med förväntat resultat. Resultat i sin tur mäts i vad som levereras "inom projektet", vilket nästan alltid är en viss mängd funktioner. Att de funktionerna sen inte används, blir sällan en belastning för projektet.

Problemet är som jag ser det ligger djupare än studiernas utvärderingskriterier. Det är djupt rotat i den grundläggande teori och praxis som finns kring projekt. "Projektledaren ansvarar för att uppnå projektmålen" är det första (och vissa skulle säga det viktigaste) man lär sig på projektledningskurser. Verksamhetsnyttan är inte projektledarens ansvar, det är beställarens ansvar eller styrgruppens ansvar. Det kan tyckas vara en sund princip, eftersom den gör det väldigt tydligt vad projektledaren ska göra. Och ju tydligare det är vad som ska göras, desto bättre chanser att lyckas. Projektmålen kan man definiera och skriva ner precist i ett projektdirektiv.

Men jag tror att det här är grunden till svårigheterna att lyckas med IT-projekt. IT-projekt är förändringsprojekt som av sin natur är väldigt komplexa och ofta innefattar förändrade arbetssätt, nya processer, behov av ny kompetens med mera. Att projektledaren inte har ansvar för den faktiska verksamhetsnyttan borgar för problem. En projektledare är en förändringsledare och att driva kritisk verksamhetsutveckling utan ansvar för verksamhetsnyttan är en absurditet!

IT är världens mest misslyckade bransch? - Chaos Manifesto

70-80% av alla IT-projekt misslyckas. År efter år. Sedan 1980-talet.

Chaos Manifesto (tidigare Chaos Report) är den överlägset största studien om lyckade och missllyckade IT-projekt. Standish Group har samlat data från IT-projekt sedan 1985. Man har granskat över 70.000 projekt och genomfört över 500 workshops med projektledare, projektmedlemmar och chefer.

Chaos Manifesto innehåller ett utdrag av Standish Groups slutsatser. Det vill säga statistik kring vilka projekt som lyckas respektive misslyckas, de tio viktigaste framgångsfaktorerna för att lyckas med IT-projekt och mängder med råd kring vad man ska göra för att undvika problem.

Jag kommer att sammanfatta och kommentera Chaos Manifesto i ett antal inlägg framöver. Det här är det första, här börjar jag med själva statistiken om lyckade och misslyckade IT-projekt.

Statistiken är till 58% amerikansk, 24% europeisk och 18% från resten av världen. Även om det är övervikt åt USA så tyder liknande studier i Sverige på att siffrorna är desamma, i alla fall på övergripande nivå.

Bara tre av tio IT-projekt lyckas
32% av alla projekt lyckas, det vill säga levereras i tid, inom budget och med de nödvändiga funktionerna. 44% är försenade, över budget och/eller saknar väsentliga funktioner. Och 24% är helt misslyckade, genom att till exempel levereras men aldrig användas överhuvudtaget.

Misslyckanden gäller alla aspekter: Tid, budget och resultat
54% går över budget. Det har varit ungefär samma siffra genom åren, med en variation mellan 43% och 56% under 2000-talet. 79% går över tiden. Här har dock siffran pendlat lite mer, mellan 63% och 84% de senaste tio åren.

Vad gäller resultat slutligen så är det 33% av funktionerna som ska produceras som aldrig blir levererade. Det har varierat från 30% till 36% det senaste decenniet. Här finns dock en annan mycket viktig faktor att tänka på. Av de levererade funktionerna kommer bara 20% nånsin till användning. Det pekar på ett annat och egentligen ännu djupare problem: Man mäter fel saker. Projekt mäts vanligen genom att utvärdera om de levererats i tid, inom budget och med förväntat resultat. Resultat i sin tur mäts i vad som levereras "inom projektet", vilket nästan alltid är en viss mängd funktioner. Att de funktionerna sen inte används, blir sällan en belastning för projektet. "Projektledaren ansvarar för projektmålen, inte effekterna" är en huvudtes i traditionell projektledningsteori. Det ska jag försöka återkomma till ett senare inlägg.

Värst i stora projekt
Om man bryter upp siffrorna så finns en del intressanta skillnader mellan olika faktorer. I projekt med en budget över 60 miljoner kronor lyckas bara 2%! I projekt med budget under 4,5 miljoner kronor lyckas däremot "hela" 71%.

Själv har jag drivit projekt inom det intervall som Chaos Manifesto klassar till 4,5-18 miljoner kronor. Där lyckas 38%, kul att tillhöra den gruppen!

Man kan spontant tro att majoriteten projekt ligger i det undre spannet och att siffrorna därför inte ser så dåliga ut som vid första anblick (där misslyckas trots allt 3/10 jämfört med i princip 10/10 bland de största projekten). Men jag tror att man misstar i den slutsatsen. Mörkertalet bland de mindre projektet - framförallt de allra minsta - är troligen betydligt högre. Små projekt som misslyckas blir inte lika uppenbart och misslyckandena inte lika synliga. Sen ska man nog också tänka på att ett projekt med två personer på heltid och en projektledare på halvtid under ett år faktiskt kostar kring 4,5 miljoner (2000 timmar per år för två personer x 1000 kr/timme som schablon). Eller nio personer inblandade på halvtid under sex månader (500 timmar x 9 x 1000).

Och värre ju större organisationen är

Samma förhållande gäller om man ser till storleken på de organisationer där projekten bedrivs. 47% av projekten lyckas i små organisationer (vilket i USA generellt anses vara under 100 anställda), 31% i medelstora organisationer (100-500 anställda) och bara 27% i stora organisationer.

Offentlig sektor sämst
Det finns också branschskillnader. Detaljhandeln lyckas bäst, med 45% lyckade projekt. Medan statliga sektorn lyckas sämst, med bara 20% lyckade projekt.


Återkommer med fler sammanfattningar och kommentarer av Chaos Manifesto!

Projektledning enligt Sokrates

Sokrates använde en speciell metod i sina diskussioner med invånarna i Aten. Han visade sällan någon konkret åsikt själv, utan ställde små och öppna frågor till dem på ett sätt som utmanade andras åsikter och ställde olika uttalanden mot varandra. På så sätt tvingades folk resonera sig fram till bättre och bättre lösningar. Istället för att diskutera som motståndare, så tvingas alla inblandade försvara och utmana varandras åsikter. Om Sokrates fick en fråga, svarade han ofta med att anta att frågan var verklighet och låta motparten tänka vidare på konsekvenserna av detta.

Det är en typ av undersökande arbetssätt som jag tror är väldigt användbart i projektledning. Frågor och svar driver successivt arbetet framåt. Det leder till:

• bättre beslut eftersom man utforskat förslagen tillsammans, dragit dem till sin spets och sett var det kan finnas brister
• bättre förankring eftersom parterna som är inblandande också varit med och tillsammans resonerat kring alternativen och kommit fram till vad som är bäst (konsensusbeslut betyder inte att alla håller med, men att alla varit med och förstår resonemangen som lett fram till beslutet)
• mer pedagogiskt synsätt, deltagarna måste förklara varför de tänker som de gör och de blir successivt mer och mer pedagogiska när de tar upp saker (vilket är mycket postivit med tanke på mängden olika professioner som ofta är inblandade i webbprojekt)
• högre kreativitet, eftersom man inte direkt accepterar det någon säger utan utmanar idéerna och förbättrar dem
• mer struktur, eftersom frågetekniken hjälper till att splittra upp stora problem och idéer i små hanterbara enheter

Några nyckelord för att arbeta mer sokratiskt är samarbete, aktivt lyssnande, klarhet, tydlighet samt kritiskt tänkande.

• Fråga alltid varför, i minst två led. Exempel: "Vi tänkte lägga knappen till vänster", "Varför ska den ligga till vänster?", "Den får mer uppmärksamhet då", "Varför får den det?". På den nivån börjar man nå en intressant diskussion.
• Tänk högt, försök "förlänga" resonemangen. Exempel: "Och vi vill att den där knappen ska få mer uppmärksamhet för att den är en del av köpprocessen på sajten?".
• Uttryck dig hypotetiskt och prövande. Dels för att öppna för att andra ska komma med synpnukter, dels för att skapa ett klimat där det är okej att spekulera utan att först ha tänkt igenom allt i minsta detalj. Exempel: "Om vi antar att knappen vore en del av köpprocessen, hade vi placerat den annorlunda då?".
• Utgå från att andra har rätt. Även om du inte håller med, prova anta att de har rätt och för ett resonemang från den synvinkeln. Det är ofta lättare att utmana en idé från "insidan" än utifrån.

Sokrates utgick från förnuftets rätt att fritt och förutsättningslöst pröva alla frågor, och att den som har rätt insikt också handlar rätt. Ett - välvilligt - kritiskt ifrågasättande hjälper till att upptäcka bristerna i ett resonemang och på så sätt når man allt närmre en optimal lösning. Konfrontationen mellan människor, synsätt, och erfarenheter leder till allt bättre resultat.

En ledare är inte en person som alltid har rätt svar, utan en person som ställer rätt frågor.

5 skäl varför det är viktigt med projektrum eller scrum-rum

En av de första sakerna jag gjorde när jag tillträdde som projektledare för mitt nuvarande projekt var att skaffa ett projektrum. Det slutade med att vi byggde om delar av en hel våning ;)

Varför är det så viktigt med projektrum?

Jag har drivit projekt helt på distans (mot till exempel utvecklare i Indien), projekt där man bara träffats vid uppstart och avslut och projekt med regelbundna avstämningsmöten. Men oavsett omständigheter är det alltid helt oslagbart att sitta tillsammans, inte bara i samma hus, utan i samma rum.

1. I ett projektrum är det bara att fråga om man undrar något eller kommer att tänka på något. Man behöver inte anstränga sig för att boka möten, ringa telefonsamtal eller gå till nåt annat rum. Det är bara att prata. Spontaneitet är ovärderlig när det gäller att undvika missförstånd.
2. I ett projektrum kan man jobba mer visuellt. Väggarna ska tapetseras av whiteboards, postit-lappar, planer och skisser. Bara att kunna stå framför samma skiss och peka är oslagbart. Och man kan ta en penna och bara kladda på skissen när man förklarar något eller beslutar att ändra något.
3. Ett projektrum gör projektet mer synligt och greppbart för resten av organisationen. Det är lätt hänt att organisationen ser projekt (framförallt IT-projekt) som något man startar och sen bara får ett resultat från. Processen däremellan tänker man oftast inte på, vilket också leder till att man kommer med input för sent eller inte förstår "varför det blev så dyrt". Med ett projektrum får man möjlighet att träffa personerna som jobbar med projektet och man kan lättare förstå vad de gör.
4. Med ett projektrum vet man alltid var man ska gå för att få tag på de som jobbar med projektet. 
5. I ett projektrum få de som jobbar i projektet en gemenskap. De kan komma från olika delar av organisationen och från olika konsultföretag. Men när de har ett gemensamt projektrum, uppstår lättare även en gemensam kultur och det blir tydligare att man jobbar för samma mål.
   

Kulturen i projektrummet ska vara att det är okej att "störa". Det kan ibland vara jobbigt att bli avbruten när man håller på med något, men nyttan överväger av att få transparens mellan alla team-medlemmar och att kunna få frågor besvarade snabbt. Till en viss gräns förstås.

Ett annat sammanhang man använder projektrum i är i politiken.Bill Clinton upprättade ett war-room för att hantera mediefrågor.

Ha aldrig mer än dubbelt så många personer som snittet under hela projekttiden

Erik Sjöberg skrev ett blogginlägg häromdagen om nyttan av att lägga till fler personer mot slutet av ett projekt för att klara deadline. Alla projektledare vet att det är svårt med bedömningar om antal resurser och ännu svårare att bedömma hur mycket det lönar sig att tillsätta fler resurser mot slutet av ett projekt. Hinner de bli produktiva i tid för att tillföra något före deadline? Tar de istället värdefull kraft från de som redan är mest produktiva i teamet?

Han nämner en tumregel som säger att man aldrig under projektet ska ha mer än dubbelt så många personer som snittet under hela projekttiden. Min spontana tanke var att jag måste ha brutit mot den tumregeln i tidigare projekt. Men efter att ha räknat lite på det inser jag att vi hela tiden faktiskt höll oss inom detta nyckeltal.Och vid projektutvärderingarna var vi nog någorlunda överens om att det inte skulle ha funkat med så mycker fler personer.

Den första hälften av projektet var huvudsakligen en analysfas och antalet inblandade personer var då nio. I den andra fasen bestod projektet av åtta av de ursprungliga nio samt ytterligare mellan två och tio personer. Efter att ha räknat lite på det (vilket tyvärr blir rätt svårt med tanke på att resursfördelningen förändrats kontinuerligt) så visar det sig att snittet faktiskt var rätt högt, över 13 personer. Som mest var vi cirka 20, vilket skulle innebära att vi höll oss inom tumregeln.

Efter att ha gått igenom projektutvärderingar och projektdokumentationer kan jag också dra en del andra slutsatser:

• Var tydlig med att tidsåtgången i projektet kan variera. Försök att till exempel be linjeorganisationen om en person på "i genomsnitt 50%" snarare än konstant 50%. Pratar man om det i förväg så går det ofta att ordna, men om man inte pratar om det tidigt blir det svårt att senare öka eller minska en persons tidsåtgång.
  
• Om man har inhyrda resurser från konsultföretag kan det vara en idé att ha flera personer med samma kompetens på deltid, snarare än en person på heltid. Då kan deltidarna gå upp i tid och projektet får fler produktiva personer utan att någon ny behöver skolas in och sätta sig i allt.(Å andra sidan får vi större overhead generellt i projektet ju fler personer vi är, så det här blir en avvägning. Men 2x50% istället för 1x100% borde fungera i de flesta fall.)
• Skriv öppna avtal med externa leverantörer, där resursbehoven kan förändras med högst 1-2 månaders varsel.
• Dokumentera lagom mycket, så det inte tar tid från teamet, men ändå är ett underlag som hjälper nya team-medlemmar att komma in i jobbet.
• Ett team består av en mängd olika kompetenser. Det verkar vara svårare att tillsätta fler personer i samma kompetensområde än att tillsätta helt nya kompetensområden.

Nån som har liknande erfarenheter?

Projektledning är 80% ledarskap och 20% administration

Jag får ofta frågan om vilka kurser som är bra inom projektledning. Jag brukar svara att många är bra, men att nästan ingen lär ut rätt saker.

Av någon anledning fokuserar nästan all litteratur och alla kurser i projektledning på projektadministration. De handlar om att fylla i och skapa modeller för planering, work breakdown structure (wbs), projektfaser, resurshistogram och riskanalys. 

Mitt tips om du vill bli en bra projektledare (och inte projektadministratör) är att lägga fokuset i din utbildning på ledarskap. Gå ledarskapskurser, till exempel Utvecklande ledarskap. Vill du ha ett teoretiskt stöd och tips kring administrativa verktyg, så komplettera med en kort kurs (1-3 dagar) i det som i utbildningsvärlden kallas "projektledning" (men som alltså nästan uteslutande är projektadministration).

Projektledning som akademinskt ämne uppstod under kalla kriget, när USA och Sovjet tävlade om vem som var störst, bäst och starkast. Det handlade om att vara först på månen, bygga fullständigt nya vapensystem och göra jättelika infrastruktursatsningar. Verktygen man lär ut i projektledning är fortfarande i stor utsträckning utformade för den typen av gigantiska projekt. Men det är sällan man i vanliga projekt har en närmast obegränsad budget eller hundratusentals projektmedlemmar. I verkligen är verktygen sällan så viktiga, utan det operativa ledarskapet dominerar (se även tidigare kommentar kring gantt-scheman).

Man kan lyckas som projektledare om man är en bra ledare men inte kan nåt av de traditionella projektverktygen. Däremot finns det inte en chans att lyckas med ett projekt utan att utöva ett bra ledarskap.

Projektledarens önskelista till projektbeställaren

1. Ge mig mandat i alla personal- och budgetfrågor som rör projektet. Även om du har det formella ansvaret för budget och personal måste du låta mig ha en betydande del i detta arbete.  För dig är det självklart att inte någon annan utser dina medarbetare, det borde det vara för mig också. Jag arbetsleder personerna i mitt projekt, då måste jag vara med och utse dem. Det formella ansvaret får gärna ligga på dig, men ska jag driva projektet måste jag vara med i dina beslut.
2. Var ordentligt insatt i projektet eller ge mig det fulla förtroendet att sköta det. Stora projekt, framförallt webbprojekt, har ofta en mycket komplex kravbild och stora beroenden mellan en mängd aspekter. För att lyckas behövs överblick och tydlighet, och det krävs tid för att vara insatt i alla aspekter. Lägg tillräckligt mycket tid, även för detaljerna, eller låt mig sköta det.
3. Låt mig vara med och utse styrgruppen. I styrgruppen ska man inte sitta för att representera en avdelning, enhet eller specialitet. Man ska sitta där för att man har ett mandat över de resurser som finns i projektet, antingen i form av personalansvar över de inblandade eller i form av budgetansvar. Styrgruppen säkerställer att verksamhetsnyttan av projektet kan uppnås, det är mitt stöd i att leda projektet åt rätt håll. Det är min styrgrupp inte din!
4. Låt mig ha direktkontakt med ledningen och vid behov även med styrelsen. Stora webbprojekt medför kulturella och organisatoriska förändringar. Alla typer av omfattande förändringsprojekt behöver tydligt sanktioneras från högsta ledningen. Högsta ledningen behöver sätta sig in i de kulturella och psykologiska utmaningarna för att kunna stötta projektet hela vägen.
5. Förstå att jag driver ett förändringsprojekt eller affärsutvecklingsprojekt. Inte ett teknikprojekt. Tekniken är en möjliggörare och kräver ofta rätt stora resurser, men utmaningarna ligger i att implementera tekniken i verksamheten och hantera kulturella och personella frågor. Minst 80 % av projektet är människor och organisation, bara 20 % är teknik.
6. Låt mig sköta upphandling och avrop av konsulttjänster åt projektet. Jag behöver inte bara granska utan även driva arbetet med upphandling, eftersom det har så avgörande betydelse för projektet. Det är jag som ska bygga en affärsrelationen med konsultföretagen.

Styrning av webbprojekt: Projektstyrning, Effektstyrning, Scrum

Jag har hört några gånger att scrum eller andra agila metoder ersätter mer traditionella projektmetoder som rup, props, eller pps. Det stämmer nog till 90%, många delar i traditionell metodik går bort när man använder scrum. Men en övergripande projektstyrning utöver scrum behövs fortfarande. Jag ser tre nivåer av styrning av webbprojekt:

1. Projektstyrningen fokuserar på att definiera projektets ramar. Istället för en regelrätt projektplan handlar det mer om en "projektdefinition" eller ett "projektupplägg". Dels behöver milstolpar beslutas, som till exempel "Projektdirektiv godkänt", "Förstudie genomförd", "Teamet på plats", "Utvecklingsstopp" eller "Lansering". Dels behöver till exempel en riskanalys och intressentanalys tas fram. Inom projektstyrning lägger jag också att etablera arbetssätt gentemot projektets styrgrupp, det vill säga till exempel förankra att vi kommer att arbeta med effektstyrning och scrum.
2. Effektstyrning går ut på att styra projektet med ständigt fokus på verksamhetsnytta istället för "leverabler" eller "krav". Den nytta som projektet ska skapa kartläggs i en resonemangskedja från syftet med tjänsten som ska tas fram, till målgrupperna som ska använda tjänsten, deras användningsmål och slutligen åtgärder som behöver vidtas. Varje steg prioriteras så att kartan blir ett stöd för projektgruppen och för styrgruppen för att följa och styra projektet. (Exempel på effektkarta finns på Socialstyrelsens utvecklingsblogg).
3. Scrum (eller nån annan agil metod) är den operativa styrningen av projektet. Det handlar om att ha alla kompetenser samlade, planera för högst några veckor i taget och visualisera arbetet så mycket som möjligt. På så sätt uppstår verksamhetsnyttan inom de ramar som definierats för projektet.

Någon som har ett likande upplägg?