teamgantt
Dela på facebook
Dela på google
Dela på twitter
Dela på linkedin

Vad är kravspecifikationer inom projektledning?

Man har kommit fram till att den största anledningen till att projekt misslyckas är dåliga kravspecifikationer. Detta beror på att de som jobbar på projektet inte vet vad de ska göra om de inte finns tydliga krav att jobba mot. Det är därför det är så viktigt att förstå vad Kravspecifikationer innebär innan du börjar arbeta med det. Otydliga krav gör nämligen ingen skillnad för dig eller för ditt företag. Därför ska vi nu lära oss lite mer om just kravspecifikationer. Kraven på produkter kan delas in i två grupper; de funktionella och de icke funktionella kraven.

Kravspecifikation vad måste projektet uppfylla

Icke funktionella krav:

De Icke funktionella kraven är krav som produkten inte klarar sig utan. Om inte dessa krav uppfylls kommer produkten inte att fungera. Därför är det viktigt att dessa krav är tydliga och lättförståeliga så att teamen kan jobba för att uppfylla dessa krav från dag ett. Dessa krav inkluderar bland annat säkerhetskrav och användarbarhetskrav.

 

Funktionella krav:

Detta är krav som produkten måste ha för att uppfylla specifika användare behov. Produkten fungerar utan dessa krav men de är ändå viktiga för att produkten ska bli så bra som möjligt.

 

I ett projekt så är det väldigt viktigt att man sätter upp tydliga krav som produkten måste uppfylla innan den är klar. Annars kan produkten bli oanvändbar eller farlig. Förutom dessa kravspecifikationer finns det ytterligare en sak som är viktig i ett sånt här projekt. Scope.

 

Scope:

Scope är omfattningen av projektet, vad som ska uppnås och hur lång tid det ska ta. Det är väldigt viktigt att man kommer överens om projektets omfattning innan man börjar jobba så att det är tydligt när projektet är klart.

 

Skillnad mellan kravspecifikationer och Scope:

Vid första anblick så kan Kravspecifikationer och Scope se ut som nästan samma sak men om man kollar lite djupare så ser man olikheterna. Scope är omfattning av projektet, hur den färdiga produkten ska se ut. Kravspecifikationer bryter ner Scope i lättförståeliga delar: krav. När alla saker i kravspecifikationen har blivit avklarade då är produkten klar för då ska man ha uppnått projektets omfattning. Det kan vara svårt att jobba med en produkt om man bara vet hur slutresultatet ska se ut. Därför finns kravspecifikationer.

 

Men även om man har ett tydligt Scope innan man börjar jobba kan man ändå drabbas av ett s.k. Scope Creep. För att lyckas med projektet måste du veta hur du ska förhindra dessa Scope Creeps.

 

 

 

 

Scope Creeps:

Innan vi pratar om hur du hindrar Scope Creeps kan det vara bra att känna till vad de är för något. Scope Creeps är för det mesta kunden, alltså den som vill ha slutprodukten. Vad som kan hända är att kunden börjar be om extra saker som inte ingick i det ursprungliga avtalet. Om detta händer är det viktigt att du tar hand om det. Vad många gör är att de gör som kunden vill och lägger in lite extra arbete gratis. Men vad de inte tänker på är att detta extra arbete kan tvinga dem att vänta med att implementera andra saker som tex vissa av de Icke funktionella kraven. Att göra som denne Scope Creep vill kommer kosta dig både tid och pengar. Men hur undviker man dessa problem?

 

Hur man undviker Scope Creeps:

Det finns inget bra sätt att undvika dem på. De kommer dyka upp för eller senare. Det enda man kan göra är att ta hand om dem på ett så bra sätt som möjligt. Här kommer några tips på hur du tar hand om Scope Creeps:

  • Se till att ha ett tydligt Scope innan du börjar på projektet. Då kan du visa personen vad ni kommit överens om från början.
  • Visa dem allt extra arbete du har gjort. Om du har gjort som personen ville och gjort lite extra arbete så kan du visa dem det så att de ser allt du har gjort som de inte har betalat för.
  • Om du gillar klienten som vill ha lite mer; testa att fråga om mer pengar och tid. Ofta är klienten villig att ge dig mer tid och pengar om du gör det extra arbete han vill.

 

Det där var några sätt att undvika Scope Creeps men hur märker du att en person är en s.k. Scope Creep? Det kan vara svårt att märka innan det har gått för långt och det är viktigt att stoppa dessa personer i början innan de blir vana vid att du gör extra arbete gratis.

 

Hur man upptäcker ett Scope Creep:

Det finns några sätt att upptäcka Scope Creeps och de kan vara viktiga att känna till så att du kan stoppa dem innan de blir vana vid ditt extra arbete. Ett varningstecken att kolla efter är om de säger saker som: ”När du ändå gör det så kan du kanske…” eller ”Medans du ändå håller på så…”. Detta är tydliga tecken då de tycker att när du ändå gör det så kan du väll lika gärna göra det också. I många fall är detta inte alls enkelt för dig utan kommer ta väldigt mycket extra tid. Redan här måste du göra klart för din kund att du antingen inte kommer göra detta extra arbete eller att det kommer kosta honom mer. Kunden kommer då antingen betala mer eller fortsätta fråga om gratis arbete. Om kunden fortsätter begär gratis jobb så bör du helt enkelt säga nej. Du kanske förlorar kunden men du slipper åtminstone jobba gratis.

 

Men om du nu har tydliga kravspecifikationer och ett tydligt scope kommer dit projekt automatiskt lyckas? Det är långt ifrån säkert. Även om du tycker att dina kravspecifikationer är tydliga så måste inte dina Teams tycka det. De kanske inte alls förstår kravspecifikationerna. Man måste upptäcka problem med kravspecifikationerna så tidigt som möjligt med projektet för att förhindra att det går åt helt fel håll. Om någon har missuppfattat kravspecifikationerna och jobbar som det tror är bäst kanske de gör helt fel och måste börja om när någon sedan förklarar vad kravet egentligen betyder. Du måste därför se till så att det inte finns något sätt att missuppfatta dina krav eller så måste du se till att alla medarbetare pratar med dig om de inte fattar något med kravspecifikationerna. För att se till att din kravspecifikation bli så bra som möjligt kan du följa Requirement Management Process. Detta är delarna i Requirement Management Process.

 

Requirement Management Process:

 

Krav planering:

Detta är det första stadiet i Requirement Management Process och det går ut på att planen för kravspecifikationen ska godkännas av alla involverade i projektet. De måste vara nöjda med planen innan man kan fortsätta.

 

Krav utveckling:

Det är här man utvecklar kraven som ska finnas på produkten. Detta stadie inkluderar Kravinsamling, Kravdefinering och Kravanalys.

 

Kravinsamling:

Detta är ett väldigt viktigt steg inom kravspecifikation. Det är här man samlar så många kända krav som möjligt. Detta kan vara väldigt svårt eftersom information kan komma i många olika format (email, telefon och interjuver) och det kan därför vara svårt att organisera all information.

 

Kravdefinering:

Det är här som man organiserar alla krav, definierar dem och förbättrar dem. Det är även här som man skapar RDD. Det står för Requirements Definition Documentation och är dokumentet där man listar alla krav på produkten. Kraven ska säga vad som förväntas av produkten men inte hur detta skall uppnås. Det är upp till de som utvecklar produkten.

 

Kravanalysering:

Meningen med kravanalysering är att hitta okända krav. Man ska alltså göra okända krav till kända. Det är bra om okända krav kan upptäckas så tidigt så möjligt så att man kan jobba mot dem redan i början av projektet. Annars kommer det kosta både tid och pengar att ändra på projektet om man hittar ett okänt krav i slutet.

 

Kravverifiering:

Det är här som man verifierar att alla krav uppfylls. Man kollar att alla krav som man känner till uppfylls och att kunderna är nöjda.

 

 

 

 

Krav förändring:

Om man vill införa någon förändring till kraven som är definierade så måste man göra det på ett bra sätt. Krav förändringen ser till så att förändringar till kraven gå enkelt och smidigt. Det här är en väldigt viktig del av Effektiv Krav styrelse.

 

Effektiv Krav Styrelse:

Denna process måste involvera de fyra tidigare stegen (Krav planering, Kravutveckling, Kravverifiering och Krav förändring). Ingen av dessa processer är valbar och de måste göras tidigt i produktens utveckling. Detta är för att garantera en bra produkt som uppfyller alla kravspecifikationer. För att veta när ett stadie i Requirement Management Process är klart så har man definierat vad resultatet ska vara.

 

Resultatet av Krav planering är en plan som är granskad och godkänd av alla involverade parter.

 

Resultatet av Krav utveckling är en förståelse av kraven. Man ska ha en bra RDD som alla kan läsa och förstå.

 

Resultatet av Kravverifiering är att användarna är nöjda med att alla krav är uppnådda.

 

Resultatet av Krav förändring är en bra hantering av alla förändringar till kraven. Det är väldigt sällan som man känner till alla kraven i början av projektet och man kommer därför behöva göra ändringar. Det är därför Krav förändring finns.

 

Roller inom Effektiv krav styrelse:

Inom Effektiv Krav Styrelse finns det flera olika roller som gör att det funkar. Utan dessa roller skulle det vara väldigt svårt att genomföra Kravspecificering och det kan därför vara bra att känna till dessa roller innan man börjar försöka införa kravspecificering inom sitt företag. Därför har jag nu gjort en lista över de olika rollerna som finns inom kravspecificering.

 

Requirement analyst:

Denna roll är väldigt viktig under Kravanalyserings stadiet. För att vara duktig på denna roll så måste Krav analysten vara duktig på att samla information och på att organisera den så att det blir lätt att snabbt få en översikt över kraven.

 

Change Control board:

Detta är inte bara en person utan en styrelse som består av många personer. Deras uppgift är att kontrollera alla förändringar som man vill göra till kraven. Alla förändringar oavsett varifrån de kommer eller hur stora de är måste godkännas av Change Control Board.

 

Inom de flesta metoder för att lättare utveckla produkter så använder man sig av s.k. artefakter. Kravspecificering är inte annorlunda.

 

 

Artefakter inom kravspecifikationer för projektledning:

Inom Kravspecifikationer för projektledning använder man sig av flera olika dokument för att hålla ordning på alla krav. Dessa kallas för artefakter.

 

Requirements Definition Document:

Detta dokument brukar man vanligtvis kallas för RDD. Det är i detta dokument som man listar alla krav på produkten som man har kommit fram till. Det är detta dokument som utvecklings Teamet följer när de utvecklar produkten efter kraven.

 

Tools:

Detta är inte riktigt ett dokument som håller koll på kraven men det är nära. Det är ett antal utvecklade system som hjälper dig att hålla koll på alla saker inom kravspecifikation och som hjälper dig att lyckas med det. Det finns hundratals av utvecklade system som man kan ladda ner, helt gratis i många fall. Se bara till inte föra in för många nya tools till dina Teams för då kommer mycket tid gå åt bara för att lära sig dem istället för att faktiskt jobba på projektet.

 

När används det?

Många tror att kravspecificering är något som man bara använder när man utvecklar fysiska produkter men det är helt fel. Kravspecificering kan användas till nästan alla produkter och projekt för att se till att dem lyckas oftare. Kravspecificering funkar lika bra på IT relaterade produkter som på fysiska, mer traditionella produkter. Det är det som gjort kravspecificering så populärt, man kan använda den till alla produkter och projekt oavsett vad man utvecklar. Kan du sätta krav på produkten kan du utveckla den med hjälp av kravspecificering.

 

Varför använda det?

Som vi nämnt tidigare så hjälper kraven ditt utvecklingsteam på flera sätt. De vet när projektet är klart eftersom det är när kraven är avklarade och de vet vad de ska göra eftersom kraven har prioriteringar. Detta kommer öka mängden av lyckade projekt vilket bara kommer vara bra för ert företag. Era teams kan jobba effektivare och leverera mer när de slipper fundera över vad de ska göra när de är klara med en sak. De vet att de bara ska gå vidare till nästa krav på listan. Detta kommer i princip göra era Teams självstyrande vilket gör att ni kanske kan anställa mer Teams och därmed klara av fler projekt? Man gjorde faktiskt en undersökning 2009 och kom fram till att 68% av företag har dåliga kravspecifikationer och deras projekt håller sig till budgeten mindre än 20% av gångerna. Om de planerar att ett projekt ska kosta $3 miljoner brukar det kosta runt $5.8 miljoner. Det är en enorm felbedömning. Enligt CHAOS Report så har de tre största anledningarna till att ett projekt misslyckas att göra med kravspecifikationer. Dessa anledningar är:

  1. Användarna är inte tillräckligt involverade i definitionen av krav.
  2. Kraven uppnås aldrig.
  3. Kraven ändras hela tiden och dessa förändringar sköts inte på ett bra sätt.

Om man använder kravspecifikationer på ett bra sätt kan man undvika alla dessa problem. Användarna involveras under kravdefinering när man definierar alla krav, man kan lätt se om ett krav har uppnåtts med RDD som berättar om kraven på ett lättförståeligt sätt och Change Control Board sköter alla förändringar av kraven på ett bra och smidigt sätt. Därför är kravspecifikationer ett bra sätt att undvika att ditt projekt misslyckas. Dock finns det självklart inte bara fördelar. Likt alla andra saker har även kravspecifikationer nackdelar.

Nackdelar med kravspecifikationer:

Kravspecifikationer har nästan inga nackdelar men vi har lyckats komma på två. Att ta fram dessa krav tar lång tid och på korta projekt är det helt enkelt inte värt det. Då är det istället bättre att färdigställa projektet och inte oroa sig över kraven. En annan nackdel är att det faktiskt inte passar för alla företag. De företagen är tex Äldrevård och Polis. De kan inte använda sig av kravspecifikationer eftersom det inte riktigt funkar inom deras yrke. Man kan i princip säga att det inte riktigt funkar i yrken som inte håller på att utveckla saker eftersom de då inte kan ställa några krav på den färdiga produkten. Detta då de inte utvecklar en produkt.

 

Den största anledningen till att projekt misslyckas är att man har en dålig kravspecificering eller att man inte har någon kravspecificering alls. Därför är kravspecificering väldigt viktig då det ger dina utvecklare något att jobba mot. Utan kravspecificering kan det vara väldigt svårt för utvecklarna att jobba och projektets chans till att misslyckas kommer därför att öka. Så om du vill att fler av dina projekt ska lyckas och att dina kunder ska bli nöjdare rekommenderar jag definitivt att du kollar om det vore möjligt att börja använda kravspecifikationer inom ditt företag. Forskning har visat att 68% av företag har dåliga kravspecifikationer och deras projekt håller sig sällan till budgeten. De misslyckas också mer ofta med projekt och får därmed färre nöjda kunder. Kravspecifikationer stoppar alla dessa problem på ett bra och effektivt sätt och jag kan därför definitivt rekommendera att du använder dig av kravspecifikationer i framtiden.