Kravhantering – största orsaken till både framgång och misslyckande

Rullar dina projekt på utan problem, eller är det tvärtom så att dina projekt misslyckas med att leverera rätt saker i rätt tid till rätt kostnad? Sannolikheten är ganska stor att du har kravhantering att tacka för din framgång eller skylla på för dina misslyckanden.

Kravhantering – största orsaken till både framgång och misslyckande

1200 600 C.A.G
CHAOS-rapporten

Varje år publicerar ”The Standish Group” en rapport som tar tempen på mjukvaruindustrin genom att identifiera viktiga faktorer för framgångsrika projekt så väl som för misslyckade projekt. CHAOS-rapporten, som den kallas, pekar ut 10 faktorer i vardera kategori.

 

Faktorer för framgångsrika och misslyckade projekt (CHAOS-rapport 2014)

 

Majoriteten av faktorer visar på hur viktigt god kravhantering är. Sex av tio faktorer i rapporten, som är viktiga för ett projekts framgång har en stark koppling till kravhantering. Samma sak gäller misslyckande projekt. Men hur kan krav ha en sådan stor påverkan, kanske du frågar dig.

Kravkvaliteten – ett kvalitetstak för projektet

En produkt eller en tjänst kan aldrig uppnå en högre kvalitet än den ingående kvaliteten som kraven har. Det vill säga om du inte under projektets gång går tillbaka och åtgärdar kvalitetsproblemet med kraven. Orsaken är att alla efterföljande aktiviteter i projektet baseras på kraven.

 

Dåliga krav påverkar alla aktiviteter i projektet.

 

I slutändan kan det i värsta fall leda till att projektet läggs ner. Forskning visar att cirka 60% av alla nerlaggda projekt beror på dålig kravhantering (Software engineering economics , Barry Boehm, 1981). Mer aktuell forskning visar dock på att det skett förbättringar inom området sedan 1980-talet. 38% indikeras på webbsidan wrike.com (https://www.wrike.com/blog/complete-collection-project-management-statistics-2015/).

Kostnaden för att åtgärda ett felaktigt krav

Det är viktigt att du tar kravhantering på allvar. Grafen nedan presenterades 2007 av Barry Boehm (”Equity keytnote address, March 19th 2007”). Den visar hur kostnaden för att rätta ett fel i ett krav varierar beroende på i vilken fas felet upptäcks. Ju senare felet upptäcks desto dyrare är det att åtgärda felet.

Förklaringen till den exponentiella relationen ligger i att du behöver gå tillbaka och återupprepa allt fler aktiviteter desto senare du hittar felet. Hittar du ett fel i kravfasen behöver du enbart uppdatera kravet. Hittar du däremot ett fel när produkten befinner sig i produktion kan det bli väsentligt dyrare. Först måste du uppdatera kravet för att sedan ändra designen, uppdatera koden, uppdatera testfall och genomföra tester återigen för att tillslut kunna leverera den rättade produkten. Se till att ta fram rätt krav från början med hög kvalitet. Det lönar sig i längden.

Vanliga symptom

Det är inte ovanligt att jag hamnar på uppdrag där kunden indikerar att de har problem med att säkra kvaliteten och uppnå acceptans av produkten för att upptäcka att problemet istället bottnar i dålig kravkvalitet.

Dålig kravkvalitet leder ofta till symptom som:

  • felaktiga prioriteringar av behov
  • osäkra estimat
  • projektplaner som har en låg överensstämmelse med utfallet
  • riskfyllda kontrakt
  • undermålig design och arkitektur
  • och svårigheter att få acceptans

I slutändan påverkar det projektets medlemmar, som får betala priset i form av minskad trivsel, frustration och stress.

Orsaker

Men varför blir det så här? Frågan är i högsta grad relevant. Självklart finns det flera faktorer som kan spela in. Men jag skulle ändå vilja påstå att de tre vanligaste orsakerna är:

  • Kommunikationsproblem
    Om du någon gång lekt viskningsleken, så vet du hur lätt information kan förvanskas och feltolkas. Därtill är fallet ofta att verksamhet och IT inte förstår varandras termer fullt ut. Det råder språkförbistringar, samtidigt som kunskapen om varandras domäner är starkt begränsad.
  • Felaktiga antaganden om att kraven är självklara
    Hur svårt kan det vara? Det är väl bara att börja skriva kod! En inte allt för ovanlig inställning hos en oerfaren beställare är att man inte förstår hur mjukvaruutveckling går till, och hur ska man kunna kräva det när vi inte ens själva förstår nyttan av kravhantering ibland.
  • Tryck på projektet att leverera funktionalitet snabbt
    Det finns två saker man kan sluta göra om det är ont om tid i projektet. Det första alternativet är att strunta i att testa innan leverans och det andra är att strunta i att utveckla kraven och påbörja implementationen av systemet direkt. Båda är väldigt kostsamma om du ser till produktens hela livscykel. Men det är klart, projektet levererar ju i rätt tid och till rätt kostnad.
Vad gör jag nu?

Ofta räcker det med en mindre insats för att få en stor positiv effekt i verksamheten. Utbildning av relevant personal inom kravhantering för att skapa medvetenhet och införande av ett gemensamt arbetssätt för högnivåkrav under överseende av en krav-coach brukar räcka för att starta resan. Då  får du både en snabb och kraftfull effekt inom verksamheten.

Om du vill veta mer om kravhantering rekommenderar jag vår kurs IREB Certifierad Kravhanterare. Kursen är en bra första hållplats på din resa mot bättre krav. Det går även bra att kontakta mig direkt om du har frågeställningar och funderingar kring din organisations kravresa.

 

Kontaktperson

Johan Meivert

+46 70 532 71 90

johan.meivert@cag.se

X
X