På tal om projekt ...

På LinkedIn finns en grupp som heter PMCode där en diskussion om hur man lyckas med projekt pågår. Ett mycket tänkvärt inlägg har gjorts av projektprofilen Kjell Rodenstedt, och med hans tillåtelse återger jag här inlägget så att fler kan läsa och tycka till. Inte minst intressant är betoningen av ledningens ansvar för de projekt som startas och drivs.

—

“Många tänkvärda saker har kommit fram i diskussionen. Med risk att upprepa en del vill jag lägga en annan aspekt på att lyckas med projekt.

För att starta ett projekt (eller program etc) måste initiativet medvetet väljas ut. Att välja ut innebär att initiativet granskas mot organisationens strategier. Ett initiativ som inte stödjer strategierna ska inte genomföras. Initiativet måste även ha ett business case som pekar på den strategiska nyttan, det ekonomiska innehållet för hela livscykeln, samt en riskanalys som visar att det är genomförbart och att nyttoeffekterna kan realiseras. Efter att väljas in i portföljen måste initiativet prioriteras mot andra initiativ. Det får inte finnas två ettor eller tvåor, utan prioriteringen ska vara strikt. Prioriteringen görs dels mot hela portföljen och dels med hänsyn till att portföljen ska ha en rimlig balans. Det sista steget är att ge starttillstånd. Här kommer initiativets resursbehov att ställas mot befintliga resurser och kan innebära att ett eller fler andra initiativ måste avslutas/senareläggas om detta initiativ ska komma upp på banan.

Ett business case måste inkludera vilka effekter som ska uppnås, hur dessa ska realiseras, vem som äger effekterna och ansvarar för att de realiseras samt när och hur effekterna ska mätas.

Uppföljning ska ske vid följande punkter:

• I samband med att projektet ska passera en beslutpunkt (tollgate eller liknande)
• I samband med större ändringar
• Periodiskt, oftast månadsvis

Det enskilda initiativet följs och styrs löpande av projektets ägare (beställare, sponsor) samt i förekommande fall av en styrgrupp. Om det finns en styrgrupp ska den bara innehålla viktiga intressenter, såsom effektägare, resursägare och eventuellt mottagare. Viktigt i styrgruppsarbetet är att man ska eftersträva konsensus, men vid skiljaktigheter är det projektägaren/sponsorn som är beslutsfattare. Det får bara finnas en beslutsfattare och som tar ansvaret. Här finns en viktig skillnad mot ett företags styrelse.
För övrigt är projektledaren eller programledaren ansvarig så som en verkställande direktör för sitt företag och rapporterar till styrgruppen. Projektledaren har ett ansvar för att hela tiden följa de riktlinjer och mål som styrgruppen sätter upp och ska klara sina målsättningar i form av omfattning, tid och kostnad (inom +/- 10 %).
Projekt som drar iväg skall granskas och, om de inte längre ger nytta för de resurser som det kräver, avslutas i förtid. Titta aldrig på redan nerlagda kostnader, utan se endast framåt: hur mycket återstår och får vi valuta för de nya pengar som måste tillföras?

För att lyckas måste företag och organisationer:

• Ha alla strukturer på plats, som processer för portföljhantering, programhantering (om man använder sig av program) och projekthantering
• En total styrprocess (governance) som inkluderar hela organisationen och hur projekt är en del av detta.
• Ha en medvetenhet om projekt och deras värde för organisationen i alla led i organisationen.
• Ha en utbildningsplan och –struktur för alla i styrgrupper, linjebefattningar, projektledare och projektdeltagare

Kontinuerligt fånga in och återanvända erfarenheter, sätta den lärande organisationen i fokus.
Det finns i kvalitetssammanhang en 85 % (eller 90 %)-regel som säger att 85 % av alla kvalitetsbrister är direkt hänförliga till organisationens ledning och de strukturer som ledningen har satt på plats. Endast 10-15 % av kvalitetsbristerna kan hänföras till den enskilda medarbetaren. Detta gäller även projekt. Ett misslyckat projekt är oftast ett organisatoriskt ledningsmisslyckande. Att skylla på projektledaren fungerar inte.”

Använder ni en statisk aktivitetslista i projektet? Dvs brukar ni ta fram en lista över aktiviteter, notera när de måste vara klara och sen inte följa upp listan? Förhoppningsvis svarar de flesta “Självklart inte!”. Listan skulle ju inte tillföra mycket om man inte sedan aktivt arbetade med den.

Nästan lika självklart som det verkar vara att arbeta med sina aktiviteter verkar det vara att inte arbeta med sina risker. Projekt som anses hyfsat välskötta brukar åtminstone genomföra en riskinventering under planeringsfasen och ta fram en lista med ett antal kolumner: vilka riskerna (inledningsvis) bedöms vara och konsekvenserna av om riskerna faller in, och sen kolumner för allvarlighetsgrad och sannolikhet som multipliceras så att riskerna kan graderas sinsemellan.

Men är inte det bra kanske vän av ordning undrar? Jovisst, en enkel riskhantering enligt ovan är fantastiskt bra om man kompletterar med följande tre saker:

• Åtgärder. Det kan låta uppenbart, men fördelen med risker är att de inte inträffat än, vilket ger oss tid att förebygga dem, vilket oftast är väsentligt billigare än att åtgärda ett redan inträffat problem. Men det kräver förstås att vi inte bara noterar vilka risker som kan inträffa, utan funderar över vad vi kan göra för att helt undvika att risken infaller, mildra effekterna av en infallen risk, ha reservplaner beredda osv.
• Kontinuerlig uppföljning. Riskarbetet behöver kontinuerligt följas upp ur åtminstone två aspekter. Dels behöver vi gå igenom själva riskerna. Har några tillkommit eller fallit bort? Är vår bedömning av riskernas prioritet densamma? Och dels behöver vi följa upp hur arbetet går med alla aktiviteter vi fattat beslut om för att minimera de negativa effekterna av riskerna.
• Kopplingar till styrgrupp och budget. Styrgruppen måste involveras i riskarbetet, eller snarare i de övergripande beslut/riskavvägningar som påverkar projektets övergripande ramar. Om till exempel komponenten A som ska byggas är förknippad med stora risker kanske man redan från början ska bygga en prototyp av den alternativa komponenten B för att tjäna tid om A visar sig inte hålla måttet. Det kommer vara tidseffektivt men påverka projektets budget. Tyngre beslut av detta slag ska självklart styrgruppen aktivt vara med och fatta, och den budget som styrgruppen fastställer ska också innehålla reservposter som är relevanta i förhållande till projektets risknivå och föreslagna åtgärder. Eller som PMI slår fast: en projektbudget utan reservposter är inte en budget.

Utan proaktiva åtgärder, en kontinuerlig uppföljning av såväl riskläget som vidtagna åtgärder samt aktiv medverkan av styrgruppen och diskussion om ekonomiska konsekvenser blir tyvärr riskhanteringen oftast en lista över hur ont olika saker förmodligen kommer att göra om de inträffar.

Jag har märkt att många PL har svårt att hålla isär problemlösning och riskhantering. Att blanda ihop dessa begrepp innebär inte bara att man använder fel termer, vilket spelar mindre roll. Betydligt allvarligare är att man mycket väl kraftigt kan fördyra sitt projekt.

Ett tydligt exempel på sammanblandning är när man i PLs statusrapport ser rubriken Risker och därefter en uppräkning av alla pågående, redan inträffade problem – och vad man gör för att komma tillrätta med dem. Allt som står i detta kapitel har självklart högsta tänkbara prioritet och det handlar oftast om reaktiv brandsläckning – eller som i SJs och SLs nuvarande sitatuation: om isröjning. Givetvis finns det inte med några risker i riskavsnittet (och därmed inte i resten av statusrapporten heller). Har man så grava och akuta problem har man ju inte tid att oroa sig för sånt som ännu inte ens hunnit inträffa.

Den klassiska bilden av en PL som drabbas av sitt projekt i stället för styr det börjar tona fram.

Hur bör man då göra i stället? Låt oss först konstatera att riskhantering är förhållandevis oerhört billigt, men måste göras i förväg. Problemlösning däremot är oftast dyrt, tvingande och görs när problem väl uppstått. Ett välskött projekt måste ha en aktiv riskhantering (oftast effektivast och bäst) och utrymme för reaktiv problemlösning (eftersom projekt löser uppgifter av engångskaraktär och alla risker inte kan förutses eller förebyggas).

SJs tågtrafik är en linjeuppgift och inte ett projekt. Men visst hade det varit trevligt med en riskhantering i somras där man förberedde sig för de trots allt ganska normala temperaturer och snömängder som finns i Stockholmsområdet just nu så att alla extraordinära problemlösande insatser kunde läggas i de områden i sydsverige där förhållandena kanske får anses vara exceptionellt ovanliga och ekonomiskt oförsvarliga att helt förebygga varje år?

Till sist en fråga till dig som sitter i en styrgrupp: Läser du din PLs statusrapport och säkerställer att det finns en lagom blandning av förebyggande riskhantering och reaktiv problemlösning, eller sitter du passivt och betraktar när din PL drabbas av sitt projekt?

Den 27 maj håller Projektforum sin årliga projektverktygsdag, den här gången på hotell Birger Jarl i Stockholm.

Förra torsdagkvällen skulle jag åka från Kastrup till Arlanda med SAS. Något flyg ställdes in, övriga SAS-flyg såg ut som om de skulle avgå. Beredskapen och förståelsen från passagerarna på att det kunde bli problem var förstås hög: problemet med askmolnet hade pågått en vecka redan.

Trots förståelsen blev stämningen på Kastrup ändå ganska irriterad. Varför? Jo, ingen kunde ge besked om varför alla andra flygbolag utom SAS flög, medan SAS-planen blev kvar på marken. Inget besked om varför de inte flög, inget besked om när man kunde förvänta sig mer information, ingen information om hur man skulle bete sig om flyget permanent skulle ställas in. Man hänvisades däremot till Transfer Desk, där ungefär 600 personer köade och endast en liten bråkdel fick någon hjälp.

Först dagen efter fick jag reda på att stilleståndet berott på att SAS inte hade sina papper i ordning för att flyga i den nydefinierade zon två. Uppenbarligen hade ansvariga på SAS prioriterat internt arbete framför att gå ut med information till passagerare och anställda på Kastrup under kvällen. Som passagerare och kund till SAS tycker jag det var ett mycket dåligt beslut, när det hade tagit så lite tid att åtminstone meddela “vårt flygtillstånd är inte klart – ny information väntas senast kl 22.00″ eller liknande.

Varför skriver jag då om detta på projektbloggen?

Jo, för att det nog inte är alltför ovanligt att projektledare gör samma misstag. Känner du igen dig i situationen där du tycker att du självklart måste få klart projektdirektivet och projektplanen och få “koll på läget” innan du börjar gå ut och informera – särskilt om du tagit över ett havererat projekt? Samtidigt kanske projektets intressenter får en mycket negativ bild av ditt projekt som kan ta lång tid att tvätta bort.

Ett tips är då att tänka på situationen på Kastrup som ett exempel på hur det inte får gå till och fundera på om du kan ta en kort paus från ditt planeringsarbete och tala om för dina intressenter att:

• Det här vet jag idag och det här har jag inte koll på ännu
• Så här gör jag för att få koll
• Jag återkommer med bättre information om x dagar

Jag har upprepade gånger hört att framgångsrik projektledning till 80-90 % består av effektiv kommunikation och det ligger mycket i det.

När jag granskar projekt ser jag ibland risklistor som innehåller formuleringar av typen

• Risk: Om vi blir av med våra resurser blir projektet försenat
• Åtgärd: Försök få hög prioritet på projektet

Den här sortens riskhantering är i princip helt meningslös och upplevs snarast som att projektledaren säger “det här är allt som kan gå fel och så här ont kommer det att göra” och “jag har i alla fall tagit upp många risker”. Det finns flera allvarliga brister med en sådan hantering av riskerna:

• För det första blir risklistan för lång, och full av självklarheter som gäller för samtliga projekt, vilket gör att de viktiga riskerna inte får tillräcklig uppmärksamhet. Självklart kan en resursrisk sticka ut och vara väldigt påtaglig för ett projekt, t ex kanske man är beroende av en nyckelperson som man har anledning att tro inte kommer finnas tillgänglig i den omfattning som behövs. Men då måste också åtgärderna vara betydligt mer fokuserade än att försöka få hög prioritet, t ex genom att man börjar lära upp en andraresurs, tar in en extern konsult i god tid, förändrar planeringen eller liknande.
• För det andra signalerar formuleringen att projektet leds av en projektledare som tror att syftet med risklistan är att påpeka allt som kan gå fel så att man har ryggen fri vid eventuella problem. Men det är inte det som är syftet med riskhantering. Syftet med riskhantering är att utnyttja tiden från nu fram till en potentiell skada skulle kunna inträffa genom att vidta åtgärder för att t ex undvika skadan helt, minimera konsekvenserna av den, förbereder alternativa handlingsplaner osv. Utan dessa åtgärder (innan skadan inträffat) finns ingen riskhantering. Vidtar man i stället korrigerande åtgärder efter skadan inträffat är det överhuvudtaget inte riskhantering vi pratar om – utan reaktiv problemlösning.

Följande faktorer anser jag vara viktiga i en framgångsrik riskhantering:

• De risker som tas upp ska vara relevanta och allvarliga för just det aktuella projektet
• Risklistan bör uppdateras regelbundet, t ex vid varje projektmöte
• Till varje risk måste det finnas en eller flera åtgärder, normalt tidssatta som i vilken aktivitetslista som helst, som gör att tiden fram till en eventuell skada utnyttjas för att minimera/eliminera skadans konsekvenser. Dessa åtgärder måste löpande följas upp så att man kan bedöma om de haft avsedd verkan på risken.
• Ju allvarligare en risk är, desto fler alternativa och kompletterande åtgärder bör man genomföra. Det är bättre att ha fem olika åtgärder för den största risken och helt hoppa över de minsta riskerna än att försöka ha “minst en åtgärd per risk”.
• Styrgruppen bör involveras i riskhanteringen. Det gäller särskilt risker vars hantering har stor påverkan på tid/kvalitet/leverans. Man kanske har en tekniskt tveksam lösning som om den inte håller kommer att medföra en stor försening. För att hantera det scenariot kan man i förväg arbeta på en alternativ lösning som medför väsentligt ökade kostnader. I det fallet måste styrgruppen involveras i beslutet så man får ett förankrat beslut på om tidsplanen är viktigast (bygg den alternativa lösningen parallellt) eller kostnaden (bygg den alternativa först när vi vet att huvudlösningen misslyckats).