reviews2

Sedan 1994 har Standish Group studerat hur väl mjukvaruprojekt lyckas i världen. Vart annat år sammanställer de resultaten i en rapport som kallas Chaos Report. I 2014 års Chaos Report var det endast 16,2 % av projekten som lyckades bli klara i tid, inom budget och med alla funktioner och ”features” som initialt specificerats. Ca 52% lyckades bli klara med projektet, men de var kraftigt försenade, långt över budget och mjukvaran hade färre funktioner än vad som specificerats. Studien visar att ca 30% av projekten läggs ned. På 70-talet var denna siffra exakt densamma. Det är skrämmande att se att det knappt har förbättrats på snart 50 år!

Man kan visserligen ha lite kritik till Chaos-studien eftersom den definierar ”lyckade projekt” med de tre kriterierna: projekten skall bli klara i tid, inom budget och med alla funktioner som initialt specificerats. Estimering är ett tufft jobb och det är svårt, kanske omöjligt, att i förväg specificera alla funktioner som skall vara med (det är ju några av anledningarna till att fler och fler övergår till Agila sätt att leda projekt).

Varför misslyckas projekten?

Oavsett om vi tittar på Chaos Report eller andra källor så är det ett faktum att mjukvarubranchen har stora problem med de metoder och projektledningsstandarder som används. Men vad beror det på? Standish Group har funnit tre huvudsakliga anledningarna till att projekt misslyckas. Dessa är att användarna inte är med, bristande support och engagemang från ledningen, otydliga och oförståerliga krav. Men det finns fler som undersökt och skrivit om varför mjukvaruprojekt misslyckas och jag vill här nedan diskutera några problem med de traditionella icke-agila projektplanerna.

Projekten är aktivitets- och milstolpebaserade

Ett första problem med de traditionella icke-agila projekten är att de är aktivitetsbaserade. Oftast innehåller planerna fina och ganska detaljerade Gantt-scheman med aktiviteter i olika steg och milstolpar. Gantt-schemat används sedan för att mäta teamets framsteg. I Pince2 t.ex. går det inte att gå vidare till nästa steg om planen för nästa steg inte godkänts av ledningen först. Att planerna är aktivitetsbaserade snarare än värde- och funktionsbaserade, för med sig ett antal problem som jag vill belysa nedan.

Kunden får inget av värde efter varje aktivitet eller milstolpe.

Det är inget värde för kunden att projektledaren har fått sin projektplan godkänd av ledningen vid ett visst datum, eller att alla testfall specificerats eller att databasdesignen fastslagits. Kunden får något av värde då han får en funktion levererad som han kan börja använda. Om du vore kund, skulle du vilja höra från projektledaren: ”Hej kära kund nu är mellanlagret ovanför databasen klar och om ytterligare två veckor kommer testplanen att vara klar” Jag tycker att det är mycket roligare att ringa till kunden och säga ”Hej, nu är första rapporten klar så nu kan du börja ta ut grafen över nyttjandegraden i din fabrik. Och om två veckor får du nästa funktion, då är vi nog klara med larmfunktionen”.

Genom att iterera och leverera små inkrement ofta så får kunden något av värde tidigt och ofta. En projektledare och systemarkitekt sade nyligen till mig att "det är viktigt att kunden ser nyttan med vad som levererats samtidigt med den feta fakturan..."

"Kunden skall se ett resultat. Det gör de inte om de bara får in mätvärden i databasen. Värdena måste bli ett konkret värde".
Vi fokuserar på glömda aktiviteter istället för glömda funktioner.

Ett annat problem med traditionella projektplaner, som är aktivitetsbaserade, är att när vi väl sätter igång med projektet så flyttas automatiskt fokus från kunden till att börja genomföra alla aktiviteter som måste göras. Vi checkar av aktiviteterna: samla in krav, definiera omfattning, definiera aktiviteter, bestämma aktivitetsordning, identifiera risker, bedöma kostnader, korsreferensmatriser, dokumentmallar framtagna, aktiviteterna upplagda i tidrapporteringssystemet osv. Vi är oroliga att vi glömt någon viktig aktivitet. Istället borde vi vara oroliga att vi ha glömt en viktig funktion som var viktig för kunden. Ett uttalande från en kollega jag nyss talade med om detta var:

""Endel har fokus på att göra klart aktiviteter för att kunna stänga projektet istället för att tänka på vilka funktioner som vi inte förutsåg, som glömdes, och som bör läggas till nästa fas för att göra kunden nöjd."
Aktiviteter kan manipuleras

Som alla vet är sannolikheten att projektet blir försenade ganska stor. Tiden glider snabbt iväg, vi ser milstolpen närma sig med stormsteg, kunden ringer allt oftare och vi inser tillslut att vi inte kommer att hinna leverera i tid. Vi blir stressade och börjar leta efter snabba lösningar, men oftast hittas allt för kreativa akuta kortsiktiga lösningar som bara ger ett sken av att planen hålls. Man bollar med siffrorna, fuskar, skär i kvaliteten, tar bort någon funktion, struntar i testning osv. Resultatet blir att man får en "skuld" som kommer tillbaks i ett senare stadie i projektet med en högre magnitud, som kanske kräver total ombyggnad av vissa funktioner. Man kan likna det med att endast testa i slutet och inte kontinuerligt. Jag var med i ett projekt där det beslutades om att vi skulle göra en statisk fejk-bild på en rapport för att hålla planen. ”Det står ingenting i kraven om att det skall vara en graf baserat på verkligt data, så vi gör en statisk bild”.

I ett annat projekt som var tidskritiskt redan från början sade ledningen till mig att jag skulle skippa att ta reda på kraven och börja koda direkt istället. Jag gjorde inte det eftersom jag självklart vill ta reda på vad kunden vill ha innan jag sätter igång att koda.

Endel projekt inför speciella ”change-request-regler” och policys för att stoppa nya och/eller förändrade krav och önskemål som inkommer från kunden. Även om kunden kommer med riktigt viktiga förändringar så kan dessa stoppas av policys för att hindra att planen blir försenad. (I vissa svårare fall kan man hoppas att det finns Agila avtal som reglerar dessa situationer, om det skulle bli ett stort problem).

En annan vanlig lösning för att hantera förseningar är att projektledaren tar in fler resurser. Man tar in en ytterligare teammedlem, vilket bara resulterar i ännu mer förseningar. En ny medlem kräver t.ex. upplärning, introduktion och tid från de andra i gruppen och det har visat sig inte alls vara en bra lösning. Det är inte så lätt för den nya resursen att bara slänga sig in i det nya jobbet och ta plats. Och det är inte så lätt för de gamla resurserna att släppa ifrån sig sina "darlings" till en ny.

Aktivitetsplanering är resurskrävande

Det tar enormt lång tid att planera aktivitetsdrivna projekt. Aktiviteterna skall planeras, prioriteras, följas upp, kontrolleras, justeras och rapporteras.

I de flesta traditionella icke-agila projektledningsmetoderna skall det produceras mängder av dokument.

Det skall tas fram projektledningsplan, plan för kravhantering, riskregister, lägesrapporter, dagliga loggar osv. Hur många sitter inte varje vecka i långa planerings- eller rapporteringsmöten och uppdaterar Excelark, Gantt-scheman, PowerPoint och rapporter?

Aktiviteter blir inte klara för tidigt

Om vi får en tidsbestämd uppgift säger "Parkinsons lag" att vi tenderar att fylla ut tiden som är satt för att göra uppgiften. Vi människor ligger på soffan och tycker att det är lååååång tid kvar till deadline. Står det i planen att en aktivitet skall vara klar på fem dagar så ser jag banne mig till att den blir klar på fem dagar eller mer, men inte färre dagar.

När ett Gantt-schema visar att en aktivitet beräknas ta fem dagar så ger detta tillåtelse att göra det på fem dagar.
Aktiviteterna är beroende av varandra

Aktiviteter är inte oberoende, vilket gör att om en aktivitet blir försenad så kan en eller flera efterföljande aktivitet inte påbörjas i tid och dessa blir då också försenade och påverkar sina efterföljande aktiviteter. De efterföljande aktiviteterna kommer troligtvis att bli ännu mer försenade till start än tiden den första aktiviteten drog över tiden. Till exempel, om en aktivitet blir försenad med 30 minuter och påverkar nästföljande aktivitet, så kan det innebära att nästa aktivitet blir försenad med 5 timmar (och inte bara 30 minuter) eftersom tid tillkommer till att börja om, planera om, byta personal, information, kontroller, dokumentation med mera. Det var precis vad som hände nyligen då en drönare åkte in på ett flygfält och orsakade flera timmars stopp i flygtrafiken. Trots att drönaren bara varit där och stört i ett par minuter så orsakade det förseningar på flera timmar.

Förseningarna sprider sig i schemat, men en annan effekt är att det går inte att starta en aktivitet tidigare än planerat då det existerar ett starkt aktivitetsberoende.

En annan effekt av beroenden mellan aktiviteter är att det inte går att starta en aktivitet för tidigt.
Många parallella aktiviteter allokeras till en person

I en ofta refererad studie av Clark & Wheelwright (1993) visas att tiden en individ spenderar på värdeskapande arbete sjunker då individen får fler än två samtida uppgifter. Att ha exakt två uppgifter är mest optimalt och det är logiskt eftersom om du kör fast i den ena uppgiften kan du fortsätta med den andra. Men att växla mellan tre, fyra eller fler uppgifter tar för mycket tid från oss och detta är inte värdeskapande tid. Till direkt värdeskapande arbete räknas t.ex. att koda, designa, driftsätta och andra aktiviteter som bygger upp mjukvaran, till en produkt eller tjänst. Den övriga tiden är inte direkt värdeskapande utan indirekt värdeskapande eller inte alls värdeskapande som till exempel koordinering, resor och förflyttningar, resultatlösa möten osv.

Att en individ får fler saker än två att göra samtidigt brukar speciellt ofta uppstå i slutet av projekt som är aktivitetsbaserade och där flera av aktiviteterna har ett slutdatum i slutet av projektet. Vid den tidpunkten brukar beroendena mellan aktiviteterna också vara som allra störst. Det är problematiskt att man fokuserar på att maximera utnyttjandet av varje individ i projekt. Att belasta alla till 100% funkar helt enkelt inte.

Ett problem med aktivitetsbaserade projekt är att man i början av projekt brukar planera in aktiviteter, sedan sätter man slutdatum för varje aktivitet. Slutligen allokerar man en resurs till varje aktivitet. Men i praktiken är det helt omöjligt att i förväg allokera resurser till aktiviteter som skall göras om ett halvår. Resurser kommer och går. De blir sjuka, vabbar, tar tjänstledigt, går kurser och slutar. Jag har spenderat timmar sittandes på möten med Excel-ark där vi vecka efter vecka allokerat om resurser, strukturerat om, flyttat aktiviteter och strykt aktiviteter och det blev aldrig som vi tänkte. Det var nog egentligen ingen som riktigt trodde på att aktivitetsallokeringsschemat skulle hålla, men det var en aktivitet som skulle göras.

Allokera aktiviteter till ett team och inte till en individ.
Aktivitetsplaner gör teamet mindre flexibla

De traditionella aktivitetsbaserade planerna, som oftast är många och detaljerade, skall följas upp och granskas och kontrolleras och jämföras med verkligt utfall vid bestämda tidpunkter. Men om förutsättningarna ändras, nya krav tillkommer, så är risken stor att man fokuserar på att fundera på hur man nu skall kunna hålla planen istället för att diskutera möjligheter kring den nya situationen. Risken är stor att man fokuserar på att försvara och hålla sin framtagna plan istället för att vara öppen, transparent och diskutera hur man skall lösa den nya situationen på bästa sätt.

Funktioner utvecklas inte i prioritetsordning

Många traditionella planer skapas med tron om att vi från början exakt vet vilka funktioner som produkten/tjänsten skall innehålla samt att vi exakt vet vilka aktiviteter vi behöver göra och när dessa måste göras. Projekten prioriteras i första hand för projektteamet och inte för kunden. När vi i slutet märker att projektet håller på att bli försenat skippar vi vissa funktioner, även om dessa var viktiga eller har blivit viktiga just nu.

Exempel: i ett funktionsbaserat projekt prioriterar vi utvecklingen av funktionerna i prioritetsordning och i någon form av värdeordning för kunden (t.ex sker så i Scrum), medan i traditionella projekt prioriterar vi och planerar vi aktiviteterna. Om vi måste skära i ett funktionsbaserat projekt så skär vi från botten bort de minst prioriterade funktionerna medan i ett aktivitetsbaserat projekt så är risken stor att vi skär i de besvärligaste och kanske mest värdefulla funktionerna för kunden för att hålla oss inom ramen för aktiviteten.

Ignorerar osäkerheter, risker och problem

Vi erkänner inte osäkerheter och problem. Vi antar att det vi planerat är rätt och att det kunden sagt är skrivet i sten. I planen står det ”Leverans 15:e Juli”, fast att vi vet att vi tidigt i projektstarten inte kan säga det med någon stor säkerhet alls. Vi skulle lika gärna kunna skrivit ”Leverans någon gång i Juli eller slutet av Augusti”.

Det bästa sättet att hantera osäkertheter är att iterera och leverera ofta. För att minska risken att vi utvecklar fel produkt eller att produkten inte kommer att uppfylla kundens krav så är det ganska självklart att vi skall leverera små funktionsbitar ofta till kunden. Kunden kan då titta på det, känna, klämma, provköra, ha synpunkter och säga ”stopp, ni har totalt missuppfattat” eller ”åhja, bättre än förväntat!” tidigt. På så vis fås ständig feedback och vi kan styra projektet rätt i små steg. Det blir lättare att lägga till missade funktioner, nya funktioner, enklare att rätta till dåliga estimeringar osv. Det blir enklare att planera och vi kan planera om ofta.

Vi bör planera om hela tiden och låta fokus flyttas från en stor projektplan med aktiviteter, till att planera om istället.
Estimeringarna blir åtaganden

Man kan inte skriva ett avtal med en kund där det står att "Vi skall leverera dessa funktioner till denna kostnad vid denna tidpunkt med sannolikheten p%". Det man gör istället är att man skriver att "Det skall finnas dessa funktioner till denna kostnad vid denna tidpunkt, därefter blir det vite om...". Konsekvenserna kan bli att när vi närmar oss slutdatum och vi ser att vi missar leveransdatum och vitet börjar ticka på så är det de kalkurerade juridiska processerna som bestämmer vad vi skall leverera.

Ett annat problem är att en enskild individ inte kan åta sig aktiviteter med en sannolikhet. Exempel: Säg att jag som projektledare tillsammans med en utvecklare uppskattat en uppgift till 2-5 dagar. Utvecklaren åtar sig uppgiften men det visar sig att det tar 3 veckor att utföra uppgiften. Vad gör han? Vad händer? Är risken att chefen tycker han presterat dåligt, vad händer på utvecklingssamtalet med chefen? "Du lyckas inte så mycket med dina uppgifter". Vad kan man göra om man åtar sig en uppgift som kan lyckas med en sannolikhet på mellan 0 och 100%? Jag har själv varit med i situationer där vi varit fyra projektledare som ensamma tidsuppskattade och prioriterade olika projektaktiviteter. Vi tilldelade varje aktivitet en programmerare. Individen själv fick inte välja. Vad hände?

REFERENSLISTA

  • Mike Cohn, 2006. Agile Estimating and Planning
  • Anthony C. Mersino, 2015. Agile Projekt Management: A Nuts and Bolts Guide to Success
  • Standish Group, Chaos Study
  • Ulla Sebestyén, 2006. Multiprojektledning: skapa puls i produktutveckling med lean tänkande.