Ser kravmängden ut som en inköpslista?

Även om man är helt säker på att kravet är verifierbart som ett element i ett kontrakt, är det OMÖJLIGT att skriva ett ”korrekt krav” utan att känna till och dokumentera (representera) ett antal grundläggande kravelement som är direkt relaterade till själva kravtexten. Är det möjligt att göra ett bra kravarbete utan vetskap om alla intressenter (stakeholders), deras mål och drivkrafter (goals) i den specifika situationen?
Ett flertal undersökningar visar på återkommande och olösta problem inom kravområdet, som en direkt orsak till ett oacceptabelt antal misslyckade projekt1. Jag tror personligen att en möjlig grundorsak (Root Cause) till denna problematik är att alltför många tror att man kan fånga kravens alla aspekter i en lista av korta, mer eller mindre välformulerade, fraser.
Om vi byter vår interna metafor från ”lista” till ”nätverk”, kommer vi att se ett krav som en del av ett nätverk av sammanlänkade kravelement, som vi måste UPPTÄCKA och REPRESENTERA som en helhet, istället för enkla enskilda fraser. Nedan visas en enkel modell över de mest grundläggande kravelementen i ett sådant nätverk.
Diagramberättelsen (diagram narrative/story) är enligt följande:
Ett krav uppfyller ett MÅL som ägs och definieras av en eller flera (diagrammet visar inte på kardinalitet) intressenter. Kravtexten byggs upp av termer som definieras på ett sätt så att termen används med samma betydelse inom projektet. Krav ordnas utefter hur viktiga de anses vara genom prioritering och varje krav är definierat mätbart och intressenternas förväntan på kravet och vad som ska gälla för att intressenterna ska tycka att kravet är uppfyllt. Varje krav är en del av något möjligt scenario där användare eller aktörer interagerar. Alla krav kan delas in i tre olika typer:
  • Begränsningar på den verklighet vi kravställer (Constraints)
  • Funktionella krav och kvalitetsattribut på aktuella funktioner
  • Komponenter (Kvalitetskrav).
Olika projekt har olika behov av att fokusera på olika delar av modellen. Varje projekt är UNIKT och det finns ingen ”one size fits all”-teknik som passar allt och alla situationer. Försöken att få med ALLT i checklistor och templates gör de flesta till ”template zombies”; vi slutar tänka själva och kan inte se och förstå vad projektet VERKLIGEN behöver. Om en organisation redan har en välkänd och verifierat korrekt intressent-karta, behöver exempelvis inte en djuplodad intressentanalys genomföras.
Ett sätt att kommunicera kring anpassning av kravbehovet för specifika situationer, är att införa begreppet ”kravmognad”. Hur moget är kravet? Är det tillräckligt moget och väldefinierat för det specifika projektet utifrån de ovan angivna aspekterna?
Mer om kravmognad i en kommande bloggpost, men det viktiga är att vi börjar tänka på krav som ett nätverk av sammanlänkad information och att det är den aktuella situationen som avgör vad som är viktigt att upptäcka och representera!

1CHAOS report från the Standish Group är inte tillförlitlig med avseende på exakta siffror, eftersom deras metoder och analyser inte är offentliga, men de (tillsammans med flera andra liknande undersökningar) visar på kontinuerliga problem inom kravområdet som har en direkt eller indirekt påverkan på hur bra projekt utförs och hur nöjda kunderna blev efter leveransen av produkten eller tjänsten.

Om författaren
Stefan Eekenulv är en passionerad seniorkonsult inom kravhantering och förbättringsarbete, kreativ och visuell, alltid med fokus på att se saker med nya ögon och att få det att funka i verkligheten.