Vad är ett lyckat projekt?

Återigen braskande rubriker: Bara en tredjedel av IT-projekten lyckas. “…så har det sett ut i 40 år” säger prof. Torsten Cegrell i Computer Sweden 18/10 2009. Cegrell menar att det nästan alltid är i beställarkompetensen som det brister och att kravspecifikationerna är alldeles för stora. Jag håller med Cegrell om det, men han missar ju helt poängen. Jag tycker faktiskt att det är på tiden att vi begraver den här myten om vad som utgör lyckade eller misslyckade projekt. Diskussionen är alldeles för viktig för att vara baserad på en meningslös definition.

Anledningen till min njugga inställning är definitionen av vad ett “lyckat projekt” innebär. Är du intresserad av agila metoder är du säkert inte förvånad. Innan du läser vidare, tag gärna 10 sek och 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?

Klar? OK. Min gissning är att du tänkte det som de flesta tänker: Att det man ville uppnå med projektet infriades. Kanske tänkte du att det ledde till något positivt? Att världen är bättre än den var tidigare? Att folk trivdes och att det blev en långsiktigt bra lösning? Att nyttan var större än kostnaden? Alla bra och värdiga mål. Men hur ser den vanliga definitionen ut, den som alla blivande PL får lära sig?

I tid. På budget. Med överenskommet innehåll.

Men vad i själva…!? Men oj, vad galet det här är! Och alla verkar använda den här definitionen. Utan att ifrågasätta. Utan att tänka. Är det inte dags att sluta sprida det här tramset? Allvarligt… sluta. Snälla…?

För det första, nyttan med projekt är inte med i definitionen alls. Det betyder att vi kan ha projekt som anses lyckade som inte levererade någon som helst nytta eller värde för kunderna till projektet. Undrar om kunderna håller med om att projektet var lyckat? Eller tvärtom så kan vi ha ett projekt som alla experter anser misslyckat men som senare visar sig vara extremt lyckat på andra sätt.

Ett exempel, som jag hämtat från Jesper Blomberg, ek.dr på Handelshögskolan. När bygget av Globen stod klart räknades det som en total katastrof. Man hade kraftigt underskattat kostnaden av bygget och blev klara på tok för sent. Eländes elände. Globen var ett fiasko och ett åtlöje. Men se, vad händer? Den marknadsföring och dragkraft som skapades blir en magnet för hela området. Köpmännen och människor dras i drivor mot den stora bollen. Evenemangen i Globen lockar sjuka mängder turister (och pengar). Globen blir en symbol för hela Stockholm. Man hade nämligen underskattat en annan sak också: Nyttan! Globen räknades 10 år senare som ett av Sveriges mest lyckade byggprojekt. Någonsin.

Sanningen är faktiskt den omvända. Många av de riktigt lyckade projekten drar över både tid och budget. Det är helt naturligt. Om något går bra, varför sluta? Varför ändra ett vinnande lag?

Nästa problem: Start- och slutpunkter för ett projekt är helt godtyckligt valda. När börjar vi egentligen? Slutdatum är lika godtyckligt och dessutom helt taget ur luften baserat på hypoteser och gissningar om framtiden. Vad är det som säger att vi ska utvärdera projektet just där och då? Det är helt godtyckligt. Och som vi såg i globenfallet kan omvärldens syn på projektet variera över tiden. Så hur ska vi veta när vi ska utvärdera?

Ta projektet att skriva det här blogginlägget som exempel. När började det? När jag skrev det första tecknet? När jag fick idén till inlägget? Eller när jag första gången funderade på frågan? En vecka sedan eller 10 år sedan. Det går inte att säga. Är det slut när inlägget är publicerat? Eller när jag har fått pengar? Vad gör jag om jag sa att det är slut, men sedan vill någon annan publicera det? Vad händer om jag gör en ny version?

Ni hör, det blir löjligt. Varför ha med något så godtyckligt som ett slutdatum i definitionen?

Det tredje och riktigt bisarra i det här är detta: Graden av hur lyckat ett projekt anses vara ska tydligen bestämmas av de värden på tid, pris och omfattning som vi uppskattade (det betyder “gissade”, gott folk) i början av projektet. I början är en synnerligen illa vald referens. Det är den tidpunkt när vi vet som allra minst av vad som väntar. Ursäkta en ärlig fråga men vad har detta överhuvudtaget att göra med om projektet är lyckat eller inte? Om värdena skiljer sig från de ursprungliga (gissade) är det är väl kanske snarare ett vittnesmål för vår välkänt, begränsade förmåga att göra korrekta utfästelser om framtiden än ett bevis på projektets eventuellt uselhet?

Speciellt svår förefaller den här jämförelsen i fråga om kombinationen överenskommet innehåll och IT-utvecklingsprojekt. Användare och beställare av IT-system har nämligen notoriskt svårt att veta vad de vill ha. IKIWISI kallas den här effekten; “I Know It When I See It”. Det är därför vi har uppfunnit iterativa metoder. En process med hög grad av förändring kan inte styras på annat sätt än genom att ta små steg, mäta och utvärdera. Vi styr försiktigt framåt och försöker så gott vi kan rätta oss efter den feedback som vi erhåller under tiden. Det är så man styr empiriska processer. Punkt. Så varför i all världen skulle vi tillmäta något värde till en jämförelse mot en ursprunglig beskrivning som vi vet är fel? Eller ännu hellre, varför skulle vi ens ge oss på att i detalj beskriva (specificera) omfattningen av ett utvecklingsprojekt? Det är bara fel. Fel och missledande.

Till sist vill jag säga det här: Jag har inget emot projekt. De är varken goda eller onda. Projekt är verktyg. De passar för vissa situationer, inte till andra. Till långsiktig, kontinuerlig produktutveckling passar de sällsynt illa. Projekt är en social konvention som vi kan ta till då och då för att entusiasmera människor och skaffa medel för speciella jobb. Något viktigt som människor kan samlas kring. Inget annat.

Lycka eller olycka kring projekt är lite som sanningen; förvånansvärt subjektiv när man ser närmare på det.

11 thoughts on “Vad är ett lyckat projekt?

    • Just det! Tack, Christian!

      Det skulle vara intressant att hitta några liknande IT-projekt. Där man visserligen gick över både utsprunglig tid och budget och där omfattningen inte blev den som vi hade tänkt, men där resultatet var så lyckat att allt det där andra inte spelade den minsta roll på lite sikt. Någon som har något exempel?

  1. Amen, Brother!

    Ett exempellöst lyckat projekt är ju faktiskt ett projekt som levererar långt mindre än vad som specificerats, på halva tiden, till 75% av budget, helt enkelt därför att kunden fått se flera levererade versioner av mjukvaran, och vid ett tillfälle bestämt att det faktiskt räckte. De features som levererats var de viktigaste, och att systemet uppfyllde det som krävdes fastän det inte hade alla features som man trodde när man gissade vid projektstart.

    Man blir ju lite mörkrädd när man hör den där Torsten Cegrell. Har de ingen kunnigare att sätta som chefer på våra universitet?

    Mats

    • Helt rätt, Mats! Definitionen är absurd redan utan att tänka lite mer “lättrörligt”, men med agila tankesätt blir den till och med motverkande ett gott resultat.

    • Tack, Morgan! 🙂

      Jag vet att många “vet” att definitionen är knäpp, men utvecklingen står ju helt still ändå. Jag har tröttnat på det.

      Vi måste sluta sprida den här myten eftersom den motverkar våra syften.

  2. Jag tror att många tyvärr fortfarande lever i projektillusionen. Ett “projekttänk” var säkerligen revolutionärt på sin tid men som du skriver leder det idag ibland till absurda diskussioner och felaktigt dragna slutsatser. När jag i våras läste på Mitt”universitet” tycktes litteratur och lärare seriöst tro att mjukvara utvecklas som man bygger hus. Man planerar, bygger och flyttar in. Sen är det klart. Inte ett ord om förvaltning, uppgraderingar och underhåll. Projekt levererar bara de första versionerna av mjukvaran.

    I en enterprisemiljö med många samtidiga projekt blir frågan om framgångsrika projekt extra intressanta. I våras och somras bedrev vi ett antal projekt som vi i linjen insåg berörde samma områden. Vi försökte låta bli att suboptimera och istället leverera största möjliga nytta till systemet. Med den följd att våra projekt kanske inte räknades som lika lyckade som de annars skulle ha gjort. Jag väntade t ex med leveransen av mitt projekt för att det andra skulle avslutas så vi kunde säkerställa att båda leveranserna funkade. Så projektet blev “misslyckat” då vi genom att validera vårt projekt skulle fungera även efter det andra projektets leverans översteg budget och tidsplan.

    Jag tycker man ska prata mer om misslyckade system än misslyckade projekt. Hade jag och den andra projektledaren siktat på lyckade projekt hade systemet i sig blivit lidande.

    • Hej Anna!

      Tack för ett jättebra exempel på hur projekt är en suboptimerande verksamhet. Starkt av er att ta smällen av att få ett “misslyckat” projekt för helhetens bästa. Gissar att inte alla i omgivningen förstod att det var så det hängde ihop.

      “Misslyckade system”… intressant! Ja, det blir en helt annan vinkling på det hela. Vad är ett misslyckat system? Kanske ett som dör i förtid för att det är för dyrt att förvalta? Eller en produkt som inte säljer för att marknaden inte vill ha den?

      Bara man är medveten om att det fortfarande kommer att vara subjektivt och en gråskala (inte binärt).

  3. Härligt att se terriern in action. Befriande utbrott 🙂 jag instämmer helt med det du känner.

    Men vad i själva…!? Men oj, vad galet det här är! Och alla verkar använda den här definitionen. Utan att ifrågasätta. Utan att tänka. Är det inte dags att sluta sprida det här tramset? Allvarligt… sluta. Snälla…?

    Ett till byggexempel i stan är ju bygget av Stadshuset, drog tokmycket över budget, tog toklång tid att bygga, dessutom rev de en flygel tror jag för att Ragnar såg att det vart inte så bra vinkel som han tänkt sig när han såg det.. ikiwisi även då. Jag borde läsa på om siffrorna..

  4. Det du skriver är helt sant. Men projekt finns inte till enbart för utvecklare. I många organisationer så måste man eska pengar genom att skapa och driva projekt. Människorna i sådana organisationer har arbetat på samma sätt hur länge som helst, kanske lika länge som organisationen har existerat. Och människor har svårt att ända på sina vanor – goda som dåliga.

    Du skrev så här:
    “Om något går bra, varför sluta? Varför ändra ett vinnande lag?”
    Du vill att kan skall köra vidare när det går bra. Det kan vara en bra idé om det finns mer att utveckla som verksamheten behöver. Även om det kanske är tråkigt att ändra ett vinnande lag så finns det en annan attityd som är mycket värre och har kostat enorma belopp (främst inom offentlig verksamhet) och ändå bara producerat begränsad eller ingen nytta alls:
    “Visserligen har vi inte producerat något värde än, men nu har vi lagt ner så mycket tid och pengar på detta att vi bara inte kan sluta!”

    Kanske ett ämne för ett eget blogginlägg….

    /Herbjörn

  5. Jag tror att problemet är väldigt djupt rotat i grundläggande teori och praxis kring projekt. Projektledaren ska ju enligt skolboken inte ta ansvar för verksamhetsnyttan, utan enbart för projektmålen. Därmed reduceras ett projekt i praktiken till projektmål och frikopplas från verksamhetsnytta (att projektbeställaren ska ha ansvaret för verksamhetsnyttan har inte någon praktisk betydelse). Läs min kommentar till inlägget: http://definitionofdone.blogspot.com/2010/01/projektledaren-maste-ta-ansvar-for.html

Comments are closed.