The Standish Group är en organisation som sedan 1985 har kartlagt över 50 000 projekt för att analysera vad det är som gör att projekt lyckas eller misslyckas.  De sammanfattar erfarenheterna från projekten i en rapport som de kallar “Chaos Report” som ges ut med jämna mellanrum.

Där finns en hel del matnyttigt statistik och ledtrådar om vad man bör undvika om man vill lyckas med projektet (och det vill man ju).

Kategorisering av projekt

Traditionell projektledarteori definierar lyckade projekt (fortsättningsvis kallade Successful) som ”Inom tid och budget och där man uppnått målet”. Därmed inte sagt att de levererar värde utan i många fall att man levererat det som beställts enligt den plan man satt upp. The Standish group har tidigare använt samma definition för Successful men har på senare år övergått till att väga in flera parametrar, bland annat levererat värde och kundnöjdhet, för att benämna projekt som lyckade. Sunt kan jag tycka då det ändå är det som är relevant att mäta.

Projekt som kategoriseras som Challenged är över budget, försenade och/eller har en otillfredsställande implementering. Failed är projekt som antingen lagts ned i förtid eller där funktionaliteten inte används efter implementeringen

Storlek på projekt

Inte helt oväntat så har storleken på projektet en enorm inverkan på möjligheterna att lyckas. Endast 2% av de projekt som räknas som ”Grand” lyckas leverera inom tid, budget och med merparten av funktionaliteten.  Inte helt oväntat är det också mer sannolikt att komplexa projekt misslyckas helt eller delvis än mycket enkla projekt.  För små projekt är siffran för lyckade projekt hela 62% vilket talar för att arbeta agilt i små team med korta iterationer och releaser.

Typer av projekt

Projekt som använder en inköpt produkt utan några anpassningar har den högsta framgångsfaktorn (57%) vilket inte är så konstigt då riskerna och utmaningarna är relativt små. Projekt som utvecklar en lösning från scratch baserat på moderna metoder har de en misslyckandegrad på 23% vilket är den högsta andelen förutom kategorin övrigt.  Det man också kan notera att projekt som utvecklar lösningar från grunden baserat på traditionella metoder har högst andel projekt i kategorin Challenged (där de alltså över budget är försenade och/eller har en otillfredsställande implementering). Att utveckla lösningar från grunden är alltså en av de mest riskabla projekt som man kan ge sig in på. Denna typ av projekt blir ofta väldigt stora och innebär att man bygger mycket av arkitektur, plattform, integrationer, rutiner och processer innan man har kravbilden klar för sig. I värsta fall kan det innebära att man får göra stora förändringar eller anpassningar sent i projektet vilket blir enormt kostsamt.

Val av projektmetod

När man tittar på vilken projektmetod som är mest lyckosam (Agil eller vattenfall) så är det tydligt att vattenfall fungerar sämre ju större projekten är. Bara 3% av de stora projekten räknas som ”Successful” mot 18% för de som använder agila metoder.  Det här är nog också grunden för kritiken mot vattenfall som projektmetod. Man försöker skapa detaljerade krav för en stor del av projektet med mycket bristfälligt underlag och att dessa krav med tiden kommer att visa sig var bristfälliga eller direkt felaktiga. Huruvida affärsmålen är tydliga eller ej verkar enligt rapporten inte spela så stor roll för projektets framgång. Det är inte helt ovanligt att projektdeltagare känner sig ganska frikopplade från de övergripande affärsmålen, man har fullt upp med sina egna leveranser inom teamet och projektet. Jag upplever att det är ganska sällan man ser projekt som har en tydlig röd tråd mellan affärsplanen och sina egna leveranser.

Kompetensen i teamet

Inte helt oväntat har även de team som har de mest erfarna medarbetarna störst sannolikhet att lyckas och hela 38% av projekten hamnar i kategorin Successful.  Projekt med en hög andel oerfarna medarbetare riskerar i mycket hög grad att går över tid och/eller budget eller inte leverera önskad funktionalitet (60%) eller att till och med helt misslyckas (23%).  I verkligheten har man ju ofta begränsade möjligheter att välja vilka man skall jobba med eller hur teamet skall vara bemannat. Den kanske intressantare frågan är ju hur man snabbt skall få alla i teamet att gå från oerfaren till ”gifted”. En av de bärande principerna inom den agila världen är ju att experimentera och vara en lärande organisation. Att hela tiden utvärdera arbetsprocesser och metoder och kollektivt ifrågasätta HUR vi gör saker och ting skapar enorma möjligheter till kollektivt lärande.

Så hur ser receptet ut för att driva ett lyckat projekt?

Om vi ska tro ”The Standish Group” som ändå har följt 100 000 projekt i över 20 års tid så finns det ju ett antal ledtrådar till vad vi borde göra och vad vi borde undvika.

  • Undvik stora projekt med hög komplexitet, bryt ned i mindre projekt och bryt ned projekt i delleveranser releaser och sprintar. Använd mycket prototyper och MVP’s för att utvärdera koncept och dellösningar. Undvik ”Big bang delivery”
  • Undvik att bygga lösningar från scratch, om du ändå måste göra det se till att du kontinuerligt utvärderar arkitektur och teknisk skuld för att inte riskera att hamna i en teknisk återvändsgränd.
  • Använd agila metoder för att göra korta åtaganden och utvärdera resultatet inom teamet och med beställaren. Sannoliketen är stor att du inte kommer att träffa målet första gången så se till att du misslyckas tidigt ”Fail fast”
  • Se till att det finns rutiner för kontinuerligt lärande i organisationen och i teamet. Se till att ni har relevant data för att utvärdera era processer och arbetsmetoder.

Om du vill gräva ned dig ytterligare i statistik så kan du läsa mer i Chaos Report 2015