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.

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

Varför använder inte fler projektuppföljning delvis baserad på EVM?

Kanske för att man saknar kunskap om när EVM är lämpligt, och hur man gör några förenklingar i modellen som passar den mer ovana organisationen?

Ett enkelt sätt kan t ex vara att i ett RUP-projekt använda EVM-uppföljning i varje separat iteration, och bara räkna antalet mantimmar i stället för att värdera allt i kronor och ören.

Ett projekt som ska pågå i två år har sin första milstolpe efter fyra veckor. Man hinner nästan klart och efter sex veckor kan milstolpen till slut passeras. Visst är det märkligt att många då anser att projektet är två veckor försenat, när man egentligen borde konstatera att projektet hittills dragit över tiden med 50%? Om man har samma precision i resten av planeringen har man kanske ett treårsprojekt framför sig snarare än ett på två år och två veckor …

Exemplet är självklart mycket grovt – men ändå tänkvärt. För det första är det bra med milstolpar för att få tidiga mätbara signaler på hur man ligger till i förhållande till sin tidsplan (oavsett om de kallas milstolpar, beslutspunkter eller fasslut efter en iteration eller sprint). För det andra är det bra att redan från början i ett projekt skapa en mycket stor respekt för varje milstolpe.

Ibland ser man skräckexempel på projekt som passerar milstolpar med restpunkter som man utan större åtgärder tror sig hinna med “senare”. Men risken är ju snarare att nästa fas blir ännu värre – förmodligen blir man lika sen med det ursprungligen planerade arbetet, och dessutom har man alla restpunkter från tidigare faser att ta hänsyn till. En milstolpe med restpunkter bör i stället tas som en mycket allvarlig varningssignal för trovärdigheten i den återstående tidsplanen och en åtgärdsplan bör tas fram av projektet.

Ovanstående handlar mest om sunt förnuft och ledarskap, men det finns även metoder som ger lite process-stöd för tankarna. En sån är Earned Value Management (EVM) eller nuvärdesmetoden som den brukar kallas på svenska.