På tal om projekt ...

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.

Som PL får man ofta frågan från sina projektdeltagare om hur pass detaljerat man ska dokumentera, t ex kravspecifikationer och teknisk dokumentation.

Förutom det självklara i att undersöka det aktuella projektets förutsättningar (levererad produkts livslängd, antal användare och andra betingelser) finns det ytterligare en rätt självklar del som ofta glöms bort. Naturligtvis bör man dokumentera på en nivå som den förvaltande organisationen mäktar med att vidmakthålla. Om dokumentationen är så pass detaljerad att den tillåts bli inaktuell är det ju ofta lika illa, och dessutom ännu dyrare, än om den är ofullständigt och saknar nödvändiga detaljer.

Projektet Vår nya produkt är snart avslutat. De avslutande testerna pågår och många av projektmålen ser ut att till slut nås. Men det finns ett men: det ekonomiska utfallet blev ett budgetöverdrag på 140% och förseningen blev betydande. I bästa fall vill man lära av sina misstag för kommande projekt och i sämsta fall vill man hitta syndabockar. En projektgranskning beställs.

Varför granskar man efter budget- och tidsöverdrag i stället för före?

De flesta projektmodeller har en beslutspunkt efter den inledande projektplaneringen. Först efter denna beslutspunkt görst de riktigt stora investeringarna. Det är ju inför denna beslutspunkt en granskning verkligen kan göra stor nytta. Här kan projektledning och styrgrupp få tips om förbisedda områden i projektplanen, som att en pilot av slutanvändarutbildningen borde genomföras, skalbarhetstester av hårdvaran i ett IT-projekt saknas och att riskanalysen inte lett till reservposter i budgeten. Att få såna tips i förväg leder ju till att man slipper göra misstagen, slipper förlora pengarna och får möjlighet att vidta åtgärder innan projektet är fullt bemannat – då alla justeringar blir svårare att genomföra.

Hur gör ni i er organisation? Granskar ni före, efter eller inte alls?

Så var det dags igen: en ny undersökning som slår fast att bara vart tredje IT-projekt lyckas och att det sett likadant ut i 40 år. I dagens artikel i CS lägger KTH-professorn Torsten Cegrell en stor del av skulden på beställarsidan och alltför omfattande specifikationer med dålig koppling till verksamhetsnyttan som eftersträvas.

Det är svårt att inte hålla med om den kritik som kommer fram och det gör lika ont varje gång som de typiska nybörjarmisstagen görs om. Jag tycker ändå det finns skäl att notera att moderna IT-projekt inte nödvändigtvis bör drivas som beställningar via ett kontrakt där specifikationen är klar vid upphandlingstillfället.

Många projekt, oavsett hur väl verksamhetsnyttan/effektmålen är specificerade, stupar just därför att man trott att det varit möjligt att i detalj kravställa nödvändig funktionalitet i början av projektet. Vissa projekt kräver helt enkelt ett annorlunda angreppssätt och systemutvecklingsmetodiker som RUP (med iterativ detaljering av specifikationen) och olika agila metoder som t ex Scrum har vuxit fram för att möta behoven i den typen av projekt.

Är lösningen då att alltid välja Scrum, eller nästa metodikbuzzword som dyker upp? Absolut inte! Däremot är mycket vunnet om åtminstone en person i styrgruppen, och definitivt projektledaren, har förståelse för styrkan och svagheten i en vattenfallsmodell, styrkan och svagheten i RUP, styrkan och svagheten i agila metoder osv och sedan funderar lite över organisationens mognadsgrad, projektets mål och syfte och anpassar metodiken baserat på lång erfarenhet och med fingertoppskänsla.

Lyckas man med det – och dessutom har en beställare som vet vad han eller hon vill – då går det absolut att förändra de tråkiga siffrorna med två av tre IT-projekt som misslyckas.

Dagens CS Jobb (Computer Sweden) tittar idag lite närmare på projektledarrollen, bl a genom tre artiklar:

• Förändrad yrkesroll
• Man måste vara lite tusenkonstnär
• Projektet kräver en ny ledare