Projektledaren måste ta ansvar för verksamhetsnyttan

Joakim Holm ifrågasätter den traditionella synen på lyckade projekt och ber läsaren att själv tänka efter: "fundera på vad du tycker att det borde innebära om någon säger att ett projekt blev lyckat. Och stopp! Försök att komma förbi den där inlärda definitionen. Vad känner du i magen vore rätt?"

Självklart har han rätt: Ett lyckat projekt kan inte bara definieras till "klart i tid, klart i budget, projektmålen uppfyllda". Det handlar istället om nyttan man åstadkommer i verksamheten, av effekten som uppstår av den satsning man gör. Får vi ökad försäljning tack vare införandet av nytt CRM-system? Blir vårt arbete effektivare tack vare nytt system för processtyrning? Blir sjukvården och Socialtjänsten i Sverige säkrare tack vare bättre information online?

De mätningar som görs utgår generellt från övertrasserad budget eller tidsplan, eller underleverans av funktionalitet. När jag läser den här typen av studier slås jag ofta av att man har så bakvänd syn på vad projektet ska leverera. Chaos Manifesto, som är den största undersökningen av lyckade och misslyckade IT-projekt, nämner bland annat att i genomsnitt 33% av funktionerna som ska produceras, aldrig blir levererade. Här bör man förstås direkt fråga sig: Vad spelar det för roll? Huvudsaken är väl att man levererade de funktioner som faktiskt skapar nytta? Det finns ju inget egenvärde i att leverera funktioner bara för att man en gång trodde att de behövdes. Sannolikheten för att man behöver allt man trodde är i praktiken till och med extremt låg.

Men ändå: Essensen av de undersökningar som görs, hur man än vrider och vänder på det, är faktiskt korrekt. KTH-professorn Torsten Cegrell som uttalar sig i en artikel i Computer Sweden har rätt: Det är fruktansvärt frustrerande att miljarder och åter miljarder i IT-investeringar är bortkastade pengar. Oavsett om studierna har märkliga utvärderingskriterier, så kvarstår det faktum att man kastar bort enorma summor pengar på projekt som inte ger önskad nytta.

Ofta finns också andra mätpunkter med i studierna, men de får inte lika stort genomslag i media. Chaos Manifesto till exempel har också uppgifter som mer närmar sig en mätning av nyttan. Som jag skrivit tidigare angående Chaos Manifesto:

Här finns dock en annan mycket viktig faktor att tänka på. Av de levererade funktionerna kommer bara 20% nånsin till användning. Det pekar på ett annat och egentligen ännu djupare problem: Man mäter fel saker. Projekt mäts vanligen genom att utvärdera om de levererats i tid, inom budget och med förväntat resultat. Resultat i sin tur mäts i vad som levereras "inom projektet", vilket nästan alltid är en viss mängd funktioner. Att de funktionerna sen inte används, blir sällan en belastning för projektet.

Problemet är som jag ser det ligger djupare än studiernas utvärderingskriterier. Det är djupt rotat i den grundläggande teori och praxis som finns kring projekt. "Projektledaren ansvarar för att uppnå projektmålen" är det första (och vissa skulle säga det viktigaste) man lär sig på projektledningskurser. Verksamhetsnyttan är inte projektledarens ansvar, det är beställarens ansvar eller styrgruppens ansvar. Det kan tyckas vara en sund princip, eftersom den gör det väldigt tydligt vad projektledaren ska göra. Och ju tydligare det är vad som ska göras, desto bättre chanser att lyckas. Projektmålen kan man definiera och skriva ner precist i ett projektdirektiv.

Men jag tror att det här är grunden till svårigheterna att lyckas med IT-projekt. IT-projekt är förändringsprojekt som av sin natur är väldigt komplexa och ofta innefattar förändrade arbetssätt, nya processer, behov av ny kompetens med mera. Att projektledaren inte har ansvar för den faktiska verksamhetsnyttan borgar för problem. En projektledare är en förändringsledare och att driva kritisk verksamhetsutveckling utan ansvar för verksamhetsnyttan är en absurditet!