Någonting känns fel
Med återkommande mellanrum, lite grann som bantningstips i dagstidningarna, ser vi braskande rubriker i IT-pressen: 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"
Alla sansade och kloka människor som läser detta suckar och skakar säkert på huvudet. Troligen svär de på att aldrig arbeta med IT-folk om de kan undvika det, vem skulle inte det? Jag tycker att Cegrell, professor som han må vara, helt missar poängen. Är det inte på tiden att vi begraver den här myten om lyckade eller misslyckade projekt och börjar diskutera väsentligheterna i stället?
Anledningen till min njugga inställning är standarddefinitionen av ett "lyckat projekt". 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 på något eller några av de effekter som de flesta tänker på: Att vi infriade det vi ville uppnå med projektet. Kanske tänkte du att projektet ledde till något positivt, att världen blev litet bättre än den var tidigare? Att nyttan var större än kostnaden? Bra och värdiga mål, allihop. 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...!? Ingen av de punkter som de flesta känner i magen är rätt finns med. Den känslan är för mig berättigad. Den här definitionen är baserad på det som enkelt går att mäta - inte på vad som är viktigt.
Nyttan ingår inte
För det första, nyttan med projektet ingår inte i definitionen. Det betyder att vi kan ha projekt som anses lyckade utan att leverera något som helst värde för kunderna. Jag undrar om de kunderna håller med om att projektet var lyckat...? Och tvärtom kan vi ha ett projekt som alla experter anser som vara misslyckat, men som senare visar sig vara extremt lyckat på andra sätt.
Ett exempel, som jag hämtat från ett föredrag av Jesper Blomberg, ek. dr på Handelshögskolan, är Globen. 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 där bedrog man sig. Vad händer? Den marknadsföring och dragkraft som skapades blir en magnet för hela området. Köpmännen och människor flockas i drivor runt den stora golfbollen. Evenemangen i Globen lockar löjliga 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.
Definitionen är alltså inte tillräcklig. Men det är värre än så, den är faktiskt felaktig. Många riktigt lyckade projekt har nämligen en tendens att dra över både tid och budget. Ja, du läste rätt. Egentligen är detta helt naturligt om vi bara tänker efter. Om något går bra, varför sluta? Varför ändra ett vinnande lag?
Start- och slutpunkter är godtyckligt valda
Nästa problem med definitionen härrör sig till en intressant egenskap hos projekt: Egentligen är start- och slutpunkt för ett projekt helt godtyckligt valda. Nu hör jag alla PL där ute skrika att deras projekt visst har naturliga start- och slutpunkter. Låt oss därför se på ett exempel, återigen inspirerat av Jesper Blomberg.
Tag projektet att skriva det här blogginlägget, 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? Var det en vecka sedan eller 10 år sedan? Jag kan inte säga det. Och när är det slut? När inlägget är publicerat? När jag har fått betalt? Vad gör jag om jag sa att det var 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.
Förutom godtyckets diktatur lider slutdatumet av ett annat problem: Det är mest 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å? 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? Varför ha med något så godtyckligt och osäkert som ett slutdatum i definitionen?
Vi jämför med gissade värden
Det tredje, och riktigt barocka, i den här soppan är detta: Graden av hur lyckat ett projekt ska anses bestäms av de värden på tid, pris och omfattning som vi uppskattade i början av projektet.
Låt oss resonera litet kring detta. Ordet "uppskatta", det betyder ungefär "att göra en kvalificerad gissning". Vi gissar alltså. Och när gissar vi? I början. Nu är tyvärr "i början" en synnerligen illa vald referens. Det är nämligen den tidpunkt när vi vet som allra minst av vad som väntar oss. Slutsatsen är alltså att vi gissar precis då vi vet som minst! Ursäkta en rak och ärlig fråga, men vad har detta överhuvudtaget att göra med om projektet är lyckat eller inte?
Hur ska vi tolka det om vi estimerade projektet till 4 månader och det tog 6 månader? Betyder det verkligen att vi gjort ett dåligt jobb? Troligen inte. Om värdena skiljer sig från de ursprungliga (gissade) är det är mer troligt att det är (ännu) ett vittnesmål för vår erkänt begränsade förmåga att göra korrekta utfästelser om framtiden än ett bevis på projektets eventuellt uselhet.
"Det är svårt att sia, i synnerhet om framtiden." (Markus M. Ronner)
Speciellt problematisk förefaller den här jämförelsen i fråga om kombinationen "överenskommet innehåll" samt utvecklingsprojekt inom IT. 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 iterativt. Det går till så här: Vi tar ett litet steg, mäter var vi står, får feedback och utvärderar. Sedan tar vi nästa lilla steg framåt baserat på vår nyvunna kunskap. Vi styr försiktigt och försöker så gott vi kan rätta oss efter den feedback som vi erhåller. Det är så man kontrollerar empiriska (erfarenhetsbaserade) 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 i hjärtat vet är översållad med fel? (En följdfråga till detta som ni kan fundera på: Varför ska vi i så fall ens försöka att i detalj beskriva (specificera) omfattningen av ett utvecklingsprojekt?)
Projekt är en social uppfinning
Låt mig vara tydlig, jag har inget emot projekt. De är varken goda eller onda. Projekt är organisatoriska verktyg. De passar för vissa situationer, inte till andra. Till långsiktigt tänkande och produktutveckling passar de sällsynt illa, vill jag påstå.
Projekt är för mig mer en social konvention som vi kan ta till för att entusiasmera människor och skaffa medel för speciella jobb; något viktigt som människor kan samlas kring. Inget annat.
Men vi måste ta oss ur villfarelsen som standarddefinitionen manifesterar. Den är skadlig. Vi verkar fortsätta att basera vårt tänkande på den utan att ifrågasätta. Utan att tänka. Är det inte dags att sluta sprida det här tramset? Allvarligt.
Lycka eller olycka för projekt är lite som sanningen: Förvånansvärt subjektiv i närbild.
Joakim Holm