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.”

Under många år har jag sett organisationer misslyckas med att skapa kontroll på sin projektportfölj genom att införa olika slags verktyg där man matar in diverse detaljerad data om varje projekt: business case, budget, tidsplan, resursplanering, ekonomisk uppföljning, EVM-tal, risker osv. Vid införandet var inte minst ledningen förväntansfull – nu skulle man få fram de fina bubbeldiagram som säljarna av verktyget hade utlovat.

Varför misslyckades det då? I många fall var det helt enkelt verktyget som synliggjorde vad som egentligen redan borde ha varit uppenbart: de flesta projekten saknade uppdaterade och relevanta business case, budget, … och inget verktyg i världen skapar i sig den kultur, projektmognad och beteende som behövs för effektiv portföljhantering.

Den här typen av implementation – samla ihop alla detaljer för att fatta bra övergripande beslut – brukar kallas för en bottom-up-implementation.

Senaste fyra-fem åren har det i stället blivit mycket populärt att välja så kallade top-down-implementationer, där man ges möjlighet att direkt gå in och göra prioriteringar mellan projekt, optimering mot strategiska mål och simuleringar av olika beslut – utan att först samla in alla detaljer. Microsofts köp av UMT (Office Portfolio Server) och IBMs köp av  FocalPoint är bra exempel på denna trend.

Inte heller top-down-verktygen ger någon automatisk framgång efter implementation, så vad ska man då välja?

Som så ofta handlar det om att börja i rätt ände:

1. Vilka verksamhetsmål har man med sin portföljhantering? Vilka effektmål finns?
2. Vilket arbetssätt behövs och vilken projektmognad har vi idag?
3. När vi bestämt oss för organisation och ansvarsområden, arbetssätt med mera – har vi en ledning som aktivt följer upp arbetet och därigenom successivt förändrar beteendet i organisationen? En ny process eller ett nytt verktyg går fort att formellt besluta om, men förändrade beteenden kräver tid och uthållighet.
4. Inför mer effektiva verktyg som stödjer det förändrade beteendet och effektiviserar arbetet.

Det är inte så konstigt om steg 4 inte ger de resultat man förväntat sig om steg 1-3 hoppas över.

I teorin är alla överens om vikten av att lära av tidigare misstag – och självklart framgångar. Det gäller sjävklart inte bara inom projektarbete. Alla som arbetat i ett kunskapsföretag har säkert varit med om försök att införa någon slags databas där alla löpande antecknar vem som kan vad, vad man jobbade med i sitt senaste uppdrag osv så att alla kan gå in och söka information vid behov. Nästan lika många har nog erfarenheten att sådana satsningar misslyckas och faller platt till marken. Orsakerna är flera:

• De som har mest att tillföra till databasen har oftast minst tid att dokumentera
• Man har ofta inte vanan att söka information där när det gäller att lära sig nya saker, och framförallt inte när det gäller att undvika misstag som man inte är medveten om att man håller på att göra
• Man gör av bara farten så som man gjorde senast

Visst kan tekniska förbättringar göra att det funkar bättre. Till exempel är säkert en Wiki-lösning och indexerade sökningar à la Google mycket bättre än en Excelfil. Men det är ändå inte där skon klämmer tror jag.

Motsvarande svårighet finns inom projektvärlden. PMIs PMBOK pratar på ett abstrakt plan om en så kallad knowledge base som ska uppdateras med all upptänklig information och lessons learned, varje gång projektet uträttat något. Men man får inte mycket hjälp på vägen när det gäller hur detta ska åstadkommas eller hur man på ett effektivt sätt drar nytta av all lagrad information. Följande citat från novembernumret av PMIs tidning PM Network sammanfattar problemet:

“To improve the probability of project success, you need a feedback loop, but in many cases companies are too focused on the next project to document, analyze and learn from what happened on the last one. – Steve Jovanovic, pmFAQtory LLC, Chicago, Illinois, USA”¨

Som så ofta handlar det om organisationer som inte alls försöker – eller som i sin överambition försöker med för mycket på en gång. Och som vanligt kan man komma en mycket lång bit på väg genom att verkligen anstränga sig, men anpassa ambitionen till vad organisationen orkar med att prestera – och återutnyttja. Här är tre enkla förslag till att praktiskt ersätta en allt omfattande knowledge base:

• Ta fram en bra mall för projektutvärdering/slutrapport och stäng inga projekt förrän detta dokument har producerats och godkänts. Slutrapporten ska förstås innehålla slutsatser om vad som gått bra och dåligt, mjuka och hårda faktorer, utfall i förhållande till plan osv. En slutrapport från ett projekt inom ett visst verksamhetsområde blir en självklar läsning för projektledaren för nästa projekt inom samma område.
• Se till att företagets projektprocess/metodik uppdateras med viktiga slutsatser från slutrapporten (men ha inga ambitioner att skapa en databas med samtliga projekts samtliga slutsatser).
• Ge varje projektledare en mentor. Det fanns en anledning till att det gamla skråväsendet hade både lärlingar, mästare och gesäller.

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.

För att ett projekt ska bli effektivt fordras det en lagom mängd administration, oavsett om det är i form av traditionell projektplanering, möten, budgetering etc eller sprintplaneringar och dagliga scrummöten. För lite eller för mycket administration ger sänkt effektivitet – fast av olika skäl. För lite ger otillräcklig kontroll och bristfällig informationsspridning och för mycket administration skapar byråkrati och stjäl tid från produktivt arbete i projektet.

Det finns ett nyckeltal som säger att ca 20% av projekttiden bör vara just administration, i ett traditionellt projekt projektledning, delprojektledning, möten, tidrapportering etc. Jag tycker att detta nyckeltal stämmer förvånansvärt bra på olika sorters projekt av alla storlekar.

Häromveckan uttryckte jag lite funderingar kring prissättning av konsulter, framförallt rörande att alla konsulter förväntas debitera ungefär lika högt arvode, trots att man för anställd personal ofta har en faktor 10, 25 eller 50 som skiljer.

Dagens artikel i Computer Sweden rörande att eWork vill byta strategi och vill tvätta bort lågprisstämpeln (som man i reklamkampanjer arbetat hårt för att nöta in) fick mig att tänka på något helt annat – en prislista som skickades ut i slutet av IT-bubblan på 90-talet. Då satt jag själv på beställarsidan och köpte bl a konsulter från en av de stora konsultdrakarna i Sverige. Jag fick då ett brev där man helt frankt konstaterade att “Det här är vår nya prislista”. Priserna började på 1.200 kr/h (för de totalt oerfarna nyutexaminerade konsulterna).

Det brevet fick mig kanske mer än något annat att inse hur oseriös IT-bubblan var och jag har fortfarande kvar brevet som påminnelse av en leverantör som gick alldeles för långt.

Det var också lätt att se att det fanns behov av en motvikt, någon som pressar priserna, vilket givetvis var det marknadsfönster som eWork utnyttjade.

Givet vad som hände i slutet av 90-talet och att eWork nu säger sig inte längre vilja framstå som lågprisleverantör har kanske marknaden fått några ramar att förhålla sig inom, eftersom affärerna utanför dessa ramar inte går så bra.

Och kunderna kan inom dessa ramar välja de konsulter som de anser har bäst pris/prestanda. Kanske ett sundare läge än i slutet av 90-talet?

Sponsorn/styrgruppen: ”Hur mycket kommer projektet att kosta?”

Projektledaren: ”Det är väldigt svårt att säga. Det är ju ingen som gjort något liknande tidigare och vi ska också testa en del nya tekniska lösningar under förstudien och se vilka konsekvenser dessa får. Vi behöver också göra en marknadsundersökning under förstudien för att se om det är rimligt att förvänta sig att vi kommer hinna före våra konkurrenter. Först efter förstudien kommer vi ha en någotsånär stabil kostnad att presentera.”

Sponsorn/styrgruppen: ”Ja, men mellan tummen och pekfingret?”

Projektledaren: ”Men förstår ni inte? Om jag höftar till med en siffra kommer den dyka upp på olika ställen i skriftlig form och sen tas för en sanning. Den som ser siffran kommer kanske inte ens förstå att förstudien inte ens var genomförd. Vi vet verkligen inte än vad projektet kommer kosta.”

Sponsorn/styrgruppen: ”Pratar vi 100 000 kr, 1 MSEK eller 50 MSEK?”

Projektledaren: ”Jag vet ju inte! Kanske 15-20 MSEK.”

20 månader senare levererar projektet den slutliga produkten, som mycket riktigt hinner lanseras före den ledande konkurrentens motsvarande produkt. Man tvingades dock ompröva en del tekniska lösningar under förstudien och dessutom designa om produkten något för att positionera den bättre mot konkurrenterna. Efter förstudien hade projektet en budget på totalt 26 MSEK och vid leverans hade man förbrukat 27,2 MSEK.

När projektutvärderingen tagits fram är det många som reagerar på att projektet anses ha levererat en bra produkt i rätt tid och med 4,6 % överdrag i kostnader. ”Vadå 4,6 %? Den skulle ju kosta 15-20 MSEK. Vi pratar om ett överdrag på någonstans 36-81 %. Man kan tydligen förvanska siffror hursomhelst!”

Jag har själv sett såna här diskussioner på nära håll ett flertal gånger. Precis som det finns projektledare som saknar tillräcklig erfarenhet och energinivå för att leverera när det faktiskt finns förutsättningar för det, finns det också beställare som saknar insikt i vad projektarbete ingår.

Sen finns det förstås många projektledare och beställare som klarar sina roller alldeles utmärkt!

Är det någon som känner igen sig och hur hanteras tidiga budgetskattningar i er organisation?

De flesta projektledare känner nog igen sig. Sponsorn, eller någon annan person med insikt i de ekonomiska förutsättningarna för projektet säger “nej, du behöver inte budgetera några kostnader för anställda/verksamhetspersoner/etc utan bara för konsulter” eller ibland “utan bara för IT-resurser”. Ibland får man tillägget “anställd verksamhetspersonal rapporterar för övrigt inte sin tid så det blir svårt att se hur mycket de jobbat”.

Som projektledare tycker jag alltid det här är lika märkligt och frågorna hopar sig:

• Är de andra resurserna verkligen gratis?
• Finns det inget annat nyttigt arbete de skulle göra om de inte var med i projektet?
• Om inte – varför minskar man inte personalen i så fall?
• Spelar det ingen roll om projektet drivs med ett stort eller litet antal timmar från anställd personal? Ibland kan man ju lösa projektets uppgift på olika sätt vilka är olika personalintensiva.
• Vad händer om flertalet roller i mitt projekt, budgeterade att bemannas med intern personal, måste bemannas med konsulter efter en intern omprioritering. Ger det en rättvisande bild av projektet att då avisera en kostnadsökning på ett par hundra procent?
• Hur sköter det aktuella företaget sin portföljprioritering och vad anser man egentligen att ett projekt kostar? Hur väger man en projektinvestering mot andra initiativ?
• Är man inte intresserad av att samla nyckeltal och statistik från sina genomförda projekt för att bättre kunna skatta tidsåtgång och kostnader för kommande projekt?

Man skulle kunna tro att det bara är mycket små och projektomogna organisationer som driver och budgeterar sina projekt på det här viset, men så är inte fallet. Även mycket stora och i övrigt metodiska och processtunga organisationer har ibland den här synen på projektbudgetering.

Som tur är går det med små medel att som projektledare förbättra situationen för just det aktuella projektet och planera och följa upp tid och kostnader för alla i projektet. Men det är sånt slöseri med resurser att i en mogen organisation inte göra det som standard.