Fokus och förväntningar på IT-projekt har alltid varit höga även om få projekt infriat förväntningarna. Det finns studier som visar att mer än 75% av IT-projekten inte levererar förväntat resultat inom tids- och budgetramarna. Denna siffra har inte ändrats särskilt mycket över åren. Många projekt havererar, kastas på soptippen och hundratals miljoner investerade kronor dansar årligen iväg till ingen direkt nytta.

Vad som definierar lyckade projekt och en bra projektledare varierar. Det varierar från tid till annan och det varierar mellan olika typer av projekt och organisationer och beställare. För att få ett perspektiv på dagens diskussioner kring havererade projekt och ”nya” metoder tänkte jag bjuda på en liten tillbakablick. Kommer du ihåg eller känner du igen dig?

Under 80-talet, då IT kallades ADB, var de flesta beställare nöjda om ett projekt levererade något som var någorlunda nära det förväntade resultatet.

Nidbilden där man använde ett träd och en gunga som metafor för hur kravställning, konstruktion och resultat kunde se ut var farligt nära sanningen i många projekt.

Metoderna fokuserade på hur krav skulle beskrivas, hur systemerare skulle designa och hur programmerare skulle bygga applikationen. De flesta projekt var systemutvecklingsprojekt.

För att klassas som en bra projektledare krävdes förmågan att få alla inblandade att förstå vad som efterfrågades och även att säkerställa att det verkligen var det som kravställdes som sedan designades, konstruerades och levererades.

I början av 90-talet talades det mycket om BPR (Business Process Reenginering) och ”den nya ekonomin” som skulle förändra allt. IT-projekt vart affärspåverkande och jämställdes med vilken affärsinvestering som helst. Ett business case (eg. kostnads- och intäktsanalys) skulle föregå beslut om IT-projekt. Detta förutsatte att IT-projektet levererade rätt lösning i rätt tid till rätt kostnad så att beställaren fick R-O-I (Return-On-Investment) enligt kalkylen.

Här föddes behoven av snabbare realisering av affärsnytta. Metoderna byggde på time-boxing och iterationer, som senare kom att kallas Agila metoder.

Projektstyrmetoderna utrustades först med ”Business case” och beslutspunkter för att beställaren skulle kunna agera tidigare om projektprogressen inte gick åt rätt håll.

Kraven på projektledaren utökades. Från verksamhetskrav och tekniska realiseringsfrågor – till förmåga att realisera affärsvärden i en snabbt föränderlig värld.

Nu

På 2000-talet levereras fortfarande inte rätt lösning eller nytta i rätt tid. Kan det vara så att användarna inte använder lösningarna på rätt sätt? Kunde tidsvinsterna i nyttokalkylen verkligen realiseras? Hur fungerade egentligen tänkta roller och ansvar vs. arbetssättet efter senaste omorganisationen?

Det krävs istället helhetstänk, flexibilitet och gemensamma ansträngningar för att nå det som egentligen betyder något – nyttoeffekter i verksamheten.

Verksamhet och IT kopplas ihop. Organisationsförändringar, dvs roller, ansvar och arbetssätt kan förenklas, eller t.o.m. initieras av nya och bättre IT-lösningar. Stor vikt måste läggas på acceptans av nytt arbetssätt, nya verktyg och ny organisation vid införande för att nyttoeffekterna skall uppstå.

Framtid

Min slutsats är att syfte, mål och innehåll i projekten kommer att fortsätta att utökas i takt med att kraven på snabbare förändringar ökar. Den stora utmaningen är att möta dessa krav. Det krävs mer av beställare och projektägare för att styra större och komplexare projekt. Det krävs mer av mottagarna av projektresultatet – som ibland är både den egna verksamheten, kunder och/eller leverantörer. Det krävs självklart också en bredare och djupare kunskap hos projektledaren och projektdeltagarna för driva det nya, moderna helhetsprojektet – från ax till limpa, på kortare tid!

Just nu erbjuder ett seminarium om myndighetssamverkan i projekt och förvaltning, mer om det hittar du här.

Vi på Systemstrategerna är redo för framtiden!

Lars Simonsson, VD