På tal om projekt ...

Det finns olika definitioner på vad ett projekt är, men i definitionen ingår ofta att man sätter samman en tillfällig organisation av människor med olika kompetenser som normalt inte jobbar tillsammans, för att lösa en uppgift av engångskaraktär. Både den tillfälliga organisationen och uppgiftens engångskaraktär gör förstås målgången mera osäker. Att leda ett projekt är att leda under risk!

För att ändå lyckas med projekt, trots de större riskerna, använder vi oss av extra kraftfulla verktyg, som normalt kostar lite extra tid och kraft men ger oss kontroll över arbetet. Vi inför t ex styr- och referensgrupper, milstolpebaserade projektmetoder, Earned Value-uppföljning, riskanalyser osv. Vi tillför helt enkelt en del extra administration för att det låter oss driva projektet mer kontrollerat och under mindre risk.

På lunchen igår diskuterade jag med en branschkollega kring linjearbete som bedrivs i projektform, t ex kompletterande leveranser i förvaltningen av ett produktionssatt IT-system. Vi kom in på hur sådana aktiviteter bör föras in i organisationens projektmodell.

Självklart kan det finnas många bra verktyg och arbetssätt från projektvärlden, som är värda att utnyttja även för återkommande linjeuppgifter. Det som däremot är viktigt att komma ihåg är att dessa linjeuppgifter oftast inte utförs av tillfälligt sammansatta organisationer, att uppgiften ofta inte är lika komplex, okänd och riskabel och att man därför inte bör stoppa in linjeuppgiften i organisationens projektmaskineri med hull och hår.

Eller med andra ord: använd inte mer administration och byråkrati än som behövs för den uppgift du har – men heller inte mindre.

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.

Outsourcingtrenden har varit rätt stark senaste decennierna, inte minst inom IT-drift men på senare tid även IT-utveckling och andra områden. Låt proffsen sköta sitt och koncentrera dig på din egen kärnverksamhet!

Jag har funderat på när denna trend ska svepa fram även över projektledningsområdet. Vågar man outsourca sina projektledare, sitt projektkontor, sin portföljhantering osv och koncentrera sig på de övergripande affärsbesluten i stället?

Och så dök den upp, självklart inte den första, men en organisation som är tidigt ute. Region Skåne outsourcar all projektledningskompetens som beställs av projektkontoret inklusive 15 personer ur den egna personalen:

Upphandlingen avser:

• tillhandahållande av all projektledningskompetens för Region Skåne som beställs genom Projektkontoret,
• övertagande av ansvar i utförarandefasen enligt Region Skånes projektmodell, gällande projekthantering, projektledning, projektrapportering, administration & utbildning,
• övertagande av personal från projektledningsenheten (ca 15 pers.) inom Region Skånes IT-förvaltning (RSIT) samt aktuell projektportfölj.