Kravhantering i systemutvecklingsprojekt - p

School of Mathematics and Systems Engineering

Reports from MSI - Rapporter från MSI

Kravhantering i

systemutvecklingsprojekt

- p

roblem i praktiken

K r a v h a n t e r in g i

s y s t e m u t v e c k lin g s p r o je k t

Problem i praktiken

C-uppsats inom informationslogistik Författare: Jessika Svensson Lärare: Jo Skåmedal Examinator: Linda Askenäs Ljungby: Januari 2008

J

Sammanfattning

Det är ett välkänt fenomen att kravhantering i systemutvecklingsprojekt har en kritisk på-verkan på resultatet. Kravhantering är dessutom betydligt mer mödosamt än för ett antal år sedan då tekniken idag är desto mer välutvecklad och avancerad. Få organisationer lyckas med kravhantering och intresset för att genomföra processen felfri växer sig allt starkare hos flera aktörer. Att särskilja problematiken och komma tillrätt med heltäckande lösningar är således en stor utmaning och inbjuder till ett hett forskningsområde.

Syftet med uppsatsen är att tolka kravhanteringsprocessen i organisation X med målet att skapa förståelse för vilka faktorer som utgör problem i praktiken. Resultatet ska generera ett bättre och generellt applicerbart fundament för effektivare kravhantering i systemut-vecklingsprojekt.

Det vetenskapliga synsättet som genomsyrar forskningen grundar sig på en hermeneutisk filosofi med intentionen att generera rikare, mer nyanserad kunskap. Metodiken bygger på två datasamlingsmetoder, litterära studier och kvalitativa intervjuer samt en databearbet-ningsmetod som karaktäriseras av en generell analysmodell.

Resultatet av undersökningen påvisar en påtaglig trend av specifika problemkällor som speglar forskningens inriktning. Kravhantering i systemutvecklingsprojekt påvisas vara mer komplext och detaljerat i jämförelse med ordinära verksamhetsprojekt och det mesta talar för att processen måste tilldelas mer eftertanke för att kunna drivas optimalt. Tiden har vi-sat sig var en problemfaktor av stor betydelse liksom bristfällig dokumentation, inkomplet-ta roller och otillfredsställande kommunikation. Det framgår också evideninkomplet-ta bevis för att kravhanteringsprocessens avancemang går hand i hand med hur väl projektteamet fungerar och förmåga till att kommunicera. Resultatet talar för att det i många fall är saker av tämli-gen enkel karaktär som utgör de mest påfallande problemen men det är viktigt att förstå hur de små skavankerna ofta grundar för större skador.

Resultatet speglar verkligt förhållande och översköljer oss med symtom på att kravhanter-ingsprocessen i systemutvecklingsprojekt i många fall inte resulterar i det som förväntas. Min förhoppning med uppsatsen är att föra forskningen inom ämnesområdet fram mot nya resultat som kan generera bättre förutsättning för att lyckas.

En trevlig lässtund tillönskas er alla!

Abstract

It is a well known fact that requirement engineering in system development project have a critical influence on the result. Requirement engineering is more demanding today then a few years ago as the information technology is highly more developed and complex. Few companies manage to handle requirement engineering successfully but the interest for a spotless result is growing as the impact of a well functioning process is overwhelming. It is a big challenge to create solutions for this specific matter and therefore a great challenging area to enter.

The purpose with the paper is to interpret requirement engineering within company X with the ambition to create understanding for which features that generate difficulty in the proc-ess. The result shall make a better foundation for more efficient requirement engineering in general within system development projects.

The scientific perspective is found on a hermeneutic philosophy with the intention to pro-duce richer and more distinct knowledge. The methodology represent two methods for gathering data, literature studies and qualitative interviews as well as one universal method for analysing the data collected.

The result from the research shows a evident trend of specific sources of problems. Re-quirement engineering in system development project seem to be more complex and de-tailed in addition to ordinary activity project and there is a obvious need for more consid-eration to be able to carry on the process in best possible manner. The time allocated the process is an unmistakable problem identified and with significance for the outcome ex-pected. Also insufficient documentation, incomplete occupational characters and unsatisfy-ing communication adds up to the source of inconvenient factors disturbunsatisfy-ing requirement engineering. The study also shows evident proof that the team and ability to communicate have a great deal of influence on whether to success or not. Most of the time the result in-sinuate that in fact it is small simple things that adds up and create the big disasters.

The result mirror reality and provide us with symptom that indicate on that requirement engineering in system development project rarely generate the result expected. With this paper I hope to be able to pave the way for further studies within the area that hopefully one day will lead to new and better conditions for successful requirement engineering. I wish you a pleasant reading!

Innehåll

1

Inledning ... 1

2

Metod val... 5

2.3.2 Reliabilitet och validitet ...8

2.3.3 Databearbetningsmetod...9

2.4 Praktiskt tillvägagångssätt...9

2.5 Relationen mellan teori och empiri ...11

2.6 Källkritik...12

3

Teoretisk referensram ... 15

3.1 Kravhanteringsprocessen...15

3.1.1 Bevisad problematik för kravsamling ...15

3.1.2 Vikten av att hitta rätt krav och att dokumentera ...17

3.1.3 Metoder för effektiv kravhantering...19

3.2 Teamet ...20

3.2.1 Grupputveckling enligt FIRO-modellen ...20

3.2.1.1 Tillhörafasen...20

3.2.1.2 Rollsökningsfasen ...21

3.2.1.3 Samhörighetsfasen ...21

3.2.1.4 Vad händer i övergången mellan faserna ...22

3.2.1.5 Gruppens energi...22

3.2.2 Teamets sammansättning...22

3.2.2.1 Normer ...23

3.2.2.2 Samhörighet ...23

3.2.2.3 Roller ...24

3.2.3 Ledaren och teamet ...24

3.3 Kommunikation...25

3.3.1 Ofullständiga och dubbla budskap ...27

5.1 Analysmodell ...40 5.2 Egna tankar...49 5.2.1 Block 1: Kravhanteringsprocessen...49 5.2.2 Block 2: Teamet ...50 5.2.3 Block 3: Kommunikation ...51

6

Slutsats ... 54

7

Reflektion ... 55

7.2 Förslag till fortsatt forskning ...56

7.3 Eftertanke...56

Litteraturförteckning... 57

Bilaga 1 Intervjuguide... 59

Figurförteckning

Figur 2:2 Analysmodell ...11 Figur 3:1 Flytzonmodellen...25 Figur 3:2 Kontextmodellen ...27 Figur 5:1 Analysmodell ...40

Tabellförteckning

Tabell 3:2 Det pedagogiska samspelet...27

Tabell 4:1 Intervjuagenda ...33

1 Inledning

”I det inledande kapitlet ges en allmän bild av uppsatsämnet och vad som ska undersökas diskuteras samt en djupare aspekt av ämnesområdet”.

”Systemutveckling sker idag under stor press och kräver att leverans sker i rätt tid, med rätt kvalitet och inom budget. För att kunna leverera i tid behövs en kravhanteringsprocess som gör det möjligt att arbeta ef-fektivt utan att behöva uppfinna hjulet på nytt varje gång” (Eriksson, 2007, s. 18).

I systemutvecklingsprojekt 1 _{hamnar följaktligen ofta fokus på den process i vilket}

dator-stödet plockas fram. Hur en kravhanteringsprocess ska avancera finns väl dokumenterat i både litteratur och olika projektmodeller men det verkar sällan som att resultatet i praktiken blir lika effektivt och framgångsrikt. Kravhanteringsprocessen brister ofta i sömmarna i samarbetet mellan IT-aktören och verksamheten då de i samverkan ska alstra en kravspeci-fikation som ska stämma överrens med de verkliga förväntningarna på systemet. ”Bristande krav är ofta den största felkällan vid utveckling av IT-system ” (Eriksson, 2007, s. 8).

I dagens informationsberikade samhälle och industriella struktur finns ett påtagligt behov av att hantera mängden information effektivt, framförallt för att kunna bibehålla en kon-kurrenskraftig position på marknaden. Effektiva informationsströmmar genererar fördelar och i de flesta organisationer är olika informationssystem väl tilltagna instrument för att kontrollera och styra dessa informationsflöden. Då ett informationssystem utvecklas är en omfattande del av projektarbetet själva kravhanteringsprocessen. Det finns många olika tekniker att tillämpa och det är bra att känna till några av dessa eftersom de lämpar sig olika bra för olika tillämpningsområden. Det primära i sakfrågan är att varje organisation bör skaffa sig en verktygslåda som innehåller praktiska delar och användbara tekniker för den typ av kravhanteringsprocess som karaktäriserar organisationen. I realiteten verkar procent-satsen av misslyckade IT-projekt vara enorm och flera faktorer pekar på en misslyckad kravhanteringsprocess.

Felaktigheter i processen leder till bristande kvalitet i det IT-system som utvecklas. Ofta är orsaken att arbetsprocessen fallerar vilket leder till att krav 2 _{samlas, dokumenteras och}

pri-oriteras på ett ineffektivt sätt. Konsekvenserna kan bli små men tyvärr är det mer vanligt att dessa felaktigheter leder till större och mer omfattande följder, exempelvis:

• Systemet blir färdigt senare än planerat

• Utvecklingen och systemförvaltningen kostar mer än beräknat

• Användbarheten missbedöms och leder till missnöje hos identifierad målgrupp Kravhantering blir också allt svårare för varje år. För ett antal år sedan var tekniken långt ifrån så välutvecklad som idag och ställde således också mindre krav på kravhanteringspro-cessen (Eriksson, 2007).

1 _{I uppsatsen omnämns vid flera tillfällen termen systemutvecklingsprojekt. Benämningen indikerar i}

sam-manhanget på applikationsutveckling.

Trots att medvetenheten är stor vad gäller vikten av en effektiv kravhanteringsprocess är det idag få organisationer som verkligen lyckas med det. Verktyg må finnas att tillämpa lika-så en dokumenterad process med det är trots allt någonting som brister i kvaliteten hos re-sultatet som i sin tur leder till tidigare omnämnda konsekvenser.

Komplexiteten i processen är ytterligare en aspekt som försvårar. Processen bör om möjligt ske i en iterativ arbetsform för att öka pålitligheten på resultatet. ”Grunden i iterativ utveckling är insikten att man inte kan göra rätt från första början” (Gulliksen & Göransson, 2002, s. 145). Det iterativa arbetssättet har under senare tid premierats och påvisar goda resultat. Processen inträder alltså flertalet loopar d.v.s. istället för att utvecklas enligt en traditionell vatten-fallsmodell 3 erbjuds större utrymme för projektgruppens aktörer att tillsammans skapa en fullständig kravspecifikation. Arbetssättet kräver dock mer resurser och flertalet företag ifrågasätter kostnad mot nytta. Det bör därför omnämnas att varje iteration leder till större möjlighet att förbättra och utveckla givet resultat till att bättre överrensstämma med vad som egentligen efterfrågas. Risken för feltolkning bedöms minska markant (Gulliksen & Göransson, 2002).

En effektiv och väl fungerande kravhanteringsprocess är grunden för ett lyckat systemut-vecklingsprojekt. Det är centralt att processen framträder tydligt och tilldelas de resurser som krävs för att undvika ovälkomna bakslag längre fram i projektet. Intresseområdet för ämnet växer och allt fler inser vikten av att genomföra processen felfri.

1.1 Problemställning

Det ämne som uppsatsen ska behandla är vad som orsakar att kravhanteringsprocessen många gånger brister i systemutvecklingsprojekt. Kravhanteringsprocessen är ett komplext förlopp som kräver ett omfattande samarbetet mellan IT-aktör och verksamhet för att rätt resultat i slutändand ska genereras. Målet är att starta ett projekt på rätt sätt med strävan mot ett entydigt mål där inget lämnas som tillfälligheter. Kraven är ofta många och växer samt förändras successivt under processen.

Enligt James Martin är den absolut största felkällan vid utveckling av IT-system kraven, hela 56 % (Eriksson, 2007). När kravhanteringsprocessen ska genomföras krävs ett nära och gediget samarbete mellan IT-aktör och verksamhet. Ofta är den varierande begrepps-apparaten ett hinder i processen och orsakar misstolkningar vilket i senare skede framgår då resultatet inte överrensstämmer med de förväntningar som finns. Just problematiken i framtagningsprocessen av en kravspecifikation går att relatera till brister i kommunika-tionsprocessen. Även det varierande intresset hos IT-aktör och verksamhet leder i flertalet fall till att kravhanteringsprocessen inte sker homogent i den utsträckning som är önskvärt. Likaså grundar olika förförståelse till att projektteamet tolkar önskvärt resultat olika under processens avancemang.

Jag har valt att fokusera uppsatsen kring följande två problemformuleringar:

• De dokumenterade processer som återfinns i de flesta företags projektmodeller åskådliggör en konkret process för att hantera krav men varför motsvarar sällan re-sultatet de förväntningar som finns?

• Vad är det som brister i praktiken då det rent teoretiskt är påvisat och möjligt att nå ett fullständigt resultat?

Valt problemområde kommer att undersökas ur ett systemutvecklingsperspektiv på fallfö-retaget. Det är ur IT-aktörens samt verksamhetens inställning till problematiken som resul-tatet kommer att analyseras för att identifiera kravhanteringsproblem och faktorer som på-verkar resultatet i processen. Abstraktionsnivån kommer vara hög för att kunna överblicka alla delar av processen och bedöma vilka faktorer som är av avgörande karaktär för slutre-sultatet.

1.2 Syfte

Syftet med uppsatsen är således att tolka kravhanteringsprocessen i organisation X med målet att skapa förståelse för vilka faktorer som utgör problem i praktiken. Resultatet ska generera ett bättre och generellt applicerbart fundament för effektivare kravhantering.

1.3 Avgränsning

Tolkningen av kravhanteringsprocessen avgränsas till enbart systemutvecklingsprojekt och den empiriska studien kommer att genomföras i relation till medelstora till större systemut-vecklingsprojekt på ett fallföretag även benämnt organisation X. Själva undersökningen av kravhanteringsprocessen sträcker sig dock utanför det formella avslutet, traditionellt i form av en godkänd kravspecifikation. Anledningen till detta är att inkludera den problematik som ofta uppstår i senare faser då beställaren inte är nöjd med vad som ska/har levererats. Det finns dock ett tydlig stopp i undersökningen som begränsar den empiriska studien till intervjuer med olika IT-aktörer, främst tekniska projektledare samt verksamhetsrepresen-tanter, i första hand aktörer i beställarrollen. De olika IT-aktörer som konsulteras i under-sökningen är avgränsade till fallföretagets interna IT-funktion och verksamhetsrepresentan-terna till någon del av organisationen. Jag kommer i undersökningen utgå från fallföretagets egen ”verktygslåda” för att studera processen.

Det finns i litteraturen ett stort fokus på användarens engagemang i kravhanteringsproces-sen. Jag har dock valt att inte inkludera användaren som en aktör i den empiriska studien men är väl medveten om dess betydelse för resultatet. Anledningen till mitt val är det är mer trovärdigt att tolka två aktörsgrupper där det finns ett tydligt samarbetet att urskilja i processen.

I förhållande till uppsatsens omfång och bestämda resurser har jag valt ovan nämnd priori-tet.

1.4 Målgrupp

Framförallt är det organisation X som är målgruppen för uppsatsens resultat men även andra medelstora företaget som bedriver interna systemutvecklingsprojekt kan ha stor nytta av resultatet då problematiken som behandlas är av generell karaktär.

1.5 Disposition

I följande del redovisas hur texten i uppsatsen planeras och disponeras. Syftet är att förbe-reda läsaren på vad som komma skall.

Kapitel 1 – Inledning

Kapitel 2 – Metodval

Läsaren introduceras för det metodval som är aktuellt för genomförd studie. Innehållet presenteras i en logisk följd där läsaren successivt erbjuds nya, djupare aspekter av tilläm-pad metodik.

Kapitel 3 – Teoretisk referensram

I referensramen presenteras aktuella teorier för uppsatsämnet. Samtliga teorier återfinnes inom följande ämnesområden, kravhantering, teamutveckling och kommunikation. Mixen av vetenskapliga lärobyggnader syftar till att nyansera undersökningen samt utgör de ett komplement till varandra.

Kapitel 4 – Empirisk undersökning

Den empiriska undersökningen innehåller material från studien genomförd i förhållande till uppsatsämnet. Informationen presenteras med utgångspunkt i samma ämnesområden pre-senterade i den teoretiska referensramen. Från varje intervju genomförd speglar kapitlet de reaktioner med hög svarsfrekvens samt omfattande citat från vederbörande respondent. Kapitel 5 – Analys

I det femte kapitlet presenteras analysen. Analysen är genomförd i förhållande till resultatet samt teoretisk referensram med syfte att lyfta fram egna tankar. Kapitlet inleds med en ana-lysmodell som används för att analysera de fyra tillsynes vanligaste kravhanteringsproble-men utifrån undersökningens resultat. Därefter introduceras läsaren för en djupare diskus-sion med egna tankar och reflektioner i anknytning till för studien kända ämnesområden. Koppling mot teori sker kontinuerligt i sammanhanget där tydliga paralleller, skillnader eller analogier går att urskilja.

Kapitel 6 – Slutsats

I uppsatsens näst sista kapitel sammanfattas det som kommit fram ur analysen i ett antal slutsatser. Slutsatserna är väl komprimerade och presenteras för läsaren i punktform. Kapitel 7 – Reflektion

2 Metod val

”I metodkapitlet ges en bred och djup bakgrund till aktuell metod för studien. Den vetenskapliga ansatsen speglar således innehållet och sätter karaktär på bestämt vägval”.

2.1 Vetenskapligt förhållningssätt

Det vetenskapliga förhållningssättet har stor betydelse för hur information samlas in och bearbeta samt vilka slutsatser som dras.

Hermeneutisk ansats

Uppsatsen präglas av en hermeneutisk ansats som påverkar grundläggande antaganden och tillvägagångssättet. Den hermeneutiska ansatsen öppnar upp till kunskap som är stängd för positivisten, alltså anses det att rikare, mer nyanserad kunskap kan uppnås om än mer osä-ker. Enligt Thurén (1991) försummar positivisten en viktig kunskapskälla nämligen förstå-elsen för andras känslor, tankar och upplevelser genom introspektion 4_{. Tolkningen av}

för-ståelsen är hermeneutisk, d.v.s. just tolkningslära. Det som hermeneutikern gör är alltså att använda egna minnen, upplevelser och förförståelse för att tolka. Det finns dock en bestå-ende nackdel: Hur vet andra att jag har tolkat rätt? Det är ett gåtfullt resonemang men det vet man faktiskt inte. Ännu en fallgrop för den oerfarna hermeneutikern är att denne pres-sar sina tolkningar så att de paspres-sar teorin (Thurén, 1991).

Trots vissa brister i den hermeneutiska ansatsen passar forskningsmetoden syftet och ska generera en ny infallsvinkel inom ämnesområdet med förhoppning om en djupare förståel-se för problematiken för att i sin tur skapa nya förutsättningar att arbeta fläckfritt.

Hermeneutikern närmar sig forskningsobjektet subjektivt utifrån sin egen förförståelse. Till skillnad från positivisten som gärna studerar forskningsobjektet bit för bit försöker den hermeneutiska forskaren att se helheten i forskningsproblemet. Hermeneutikern ställer allt-så helheten i relation till delarna och pendlar mellan del och helhet för att nå en allt-så fullstän-dig förståelse som möjligt. Hela tiden använder forskaren sin egen förförståelse som ett verktyg för att tolka (Patel & Davidson, 2003).

Förförståelsen är central inom hermeneutiken och påverkas av våra värderingar. ”Värde-ringar är den energi, det bränsle som driver alla människor” (Thurén, 1991, s. 41). Värderingen ska inte påverka forskningen, d.v.s. värderingsfri forskning är eftersträvansvärt där resultatet inte är manipulerat. Hermeneutikern hävdar att betraktaren inte kan särskiljas från det un-dersökta fenomenet. Kunskapen genereras genom att skapa förståelse och det är inte bara fenomenet som är intressant utan även dess omgivning (Björklund & Paulsson, 2003). För-förståelsen går emellertid att revidera genom erfarenhet. Den hermeneutiska spiralen eller cirkeln som den också brukar kallas, illustrerar växelspelet mellan förförståelse och erfaren-het.

Hermeneutiska cirkeln

Alla människor bär egna antaganden om hur saker och ting förhåller sig. När vi jämför hur väl den egen konstruerade hypotesen överrensstämmer med verkligheten bekräftas eller motbevisas hypotesen. Vi inträder då en iterativ process, den hermeneutiska cirkeln. Jag ställer upp en ny hypotes för att se om den passar in bättre och reviderar alltså min förförs-tåelse med hjälp av erfarenhet. När jag kommer fram till en hypotes som stämmer överrens

med verkligheten, upplever jag förståelse för materialet.

Cirkeln beskriver på ett bra sätt hur jag med hjälp av erfarenhet omarbetar min förförståel-se. ”…En större erfarenhet ger en bättre förförståelse som i sin tur gör att man uppfattar finare nyanser.” (Thurén, 1991, s. 60).

Min förförståelse

I förhållande till uppsatsämnet har jag en förförståelse som baseras på olika erfarenheter, minnen och upplevelser. Grunden till min förförståelse som är relevant för uppsatsämnet är genomförda studier inom ämnet informatik samt tidigare erfarenhet från fallföretaget, organisation X. Jag har således i ett tidigare skede haft anknytning till initieringsfasen av ett systemutvecklingsprojekt varav jag hade möjligheten att bekanta mig med kravhanterings-processen överskådligt. Erfarenheten har genererat en bättre förförståelse för ämnet som är relevant för undersökningen och mitt sätt att tolka i senare fas. Även mitt intresse för äm-nesområdet påverkar min förförståelse och sättet jag kommer att tolka resultatet på. Jag känner en iver för att kunna tillföra en djupare förståelse för processen och på så vis gene-rerar en godare grund för effektivitet och framgång. Jag upplever kravhantering som något av primäraste betydelse för att systemutveckling ska fungera och resultera i det som förvän-tas. Därav styr mitt intresse för uppgiften också mitt engagemang för att leverera ett väl ge-nomtänkt resultat.

Jag har läst både litterära verk och vetenskapliga artiklar som förhåller sig till uppsatsämnet för att öppna upp mina sinnen och förebereda mig för analysen. Jag har dessutom valt att tillämpa kunskaper och erfarenheter inom teamutveckling och kommunikation då jag tror dessa aspekter har en betydelsefull roll för kravhanteringsprocessen framgång. Det är följ-aktligen min förförståelse för samtliga tre ämnesområden, kravhantering, teamutveckling samt kommunikation som utgör stommen för hur jag kommer att tolka resultatet. Studier-na av de två sistnämnda vetenskapsområden är framförallt genomförda i förhållande till studier inom ämnesområdet ledarskap varav även denna aspekt utgör en förutsättning för hur jag tolkar. Jag har ett stort intresse för alla omnämnda ämnen vilket också påverkar min förförståelse och val av hur jag tolkar problematiken i uppsatsämnet. Konklusionen är att det är mina personliga preferenser som styr hur jag kommer att tolka resultatet. Det är ur dessa infallsvinklar som jag tror att det finns en lösning att hämta varv det faller naturligt att tolka problematiken utifrån den förförståelse jag redogör för.

2.2 Metodik

Metodiken, eller med ett annat ord undersökningsdesignen, är det kapitel som jag kommer att använda för att bestämma upplägget för undersökningen. Metodiken anger alltså den metodmässiga helheten i uppsatsen genom att fastställa de metoder för datainsamling och databearbetning som används samt relationen mellan dessa (Björklund & Paulsson, 2003). För att belysa vad jag menar med metodik har jag valt att återge följande illustration enligt Björklund och Paulsson (2003).

Figur 2:1: Grafisk illustration av vald metodik (Björklund & Paulsson, 2003).

Jag har valt att använd två olika metoder för datainsamling, litteraturstudier (datainsam-lingsmetod A) och intervjuer (datainsam(datainsam-lingsmetod B). För att bearbeta insamlad data har jag valt en allmän metod, en analysmodell (databearbetningsmetod 1). Analysmodellen är av generell karaktär men jag ämnar att sätta egen prägel på den för att bättre passa sakläget i uppsatsen.

2.3 Metod

I följande del kommer jag att i detalj skildra de metoder som jag valt för att genomföra un-dersökningen. Varför dessa är relevanta för uppsatsen beskrivs också samt i relation till kri-tisk granskning, d.v.s. styrkor kontra svagheter.

2.3.1 Datainsamlingsmetod

Valet av metod är ställt i relation till metodens lämplighet för att samla den data/information relevant för undersökningen. Följande metoder har jag valt för att samla information till studien:

Litteraturstudie

Intervjuer

En kvalitativt inriktad forskning syftar till att datasamlingsmetoden fokuserar på ”mjuka” data, tex. i form av kvalitativa intervjuer och tolkande analyser. Syftet med en kvalitativ in-tervju är att upptäcka och identifiera egenskaper hos något, förslagsvis uppfattning om nå-got fenomen. Detta innebär att jag aldrig i förväg kan formulera svarsalternativen för re-spondenten eller avgöra vad som är det ”sanna” svaret på frågan. I denna betydelse är en kvalitativ intervju riktad mot ett induktivt eller abduktivt arbetssätt i forskningen (Patel & Davidson, 2003).

Ur en intervju genereras information av typen primärdata. Primärdata är data/information som utmärkande har samlats in för den egna undersökningen.

Det finns olika typer av intervjuer, de som jag har genomfört har skett genom personlig di-rektkontakt. Det har varit intervjuer av både ostrukturerad och strukturerad karaktär bero-ende på vilken fas i undersökningen intervjun genomförts.

Intervjuer är ofta väldigt tidskrävande men styrkorna är desto fler. I intervjuer ges tillgång till information som är av direkt relevans för studiens syfte och möjlighet till en djupare förståelse. Det ges också möjlighet att tolka andra signaler så som t.ex. kroppsspråk (Björk-lund & Paulsson, 2003).

2.3.2 Reliabilitet och validitet

Begreppen validitet och reliabilitet står för forskningens kvalitet. Reliabilitet syftar till av-saknad av slumpmässiga mätfel, d.v.s. pålitlighet. Det handlar alltså om stabilitet och repli-kerbarhet i genomförd studie. Begreppet validitet står för giltighet, generaliserbarhet av re-sultatet till andra kontexter än den undersökta (Svenska Handelshögskolan, 2007).

Reliabilitet och validitet står i relation till varandra vilket gör att vi inte bara kan koncentre-ra oss på det ena eller det andkoncentre-ra. Fullständig reliabilitet är en förutsättning för fullständig validitet, d.v.s. för att veta vad jag mäter måste min mätning vara tillförlitlig (Patel & Da-vidson, 2003).

Reliabilitet

I en kvalitativ forskning är det väsentligt att mäta om den information jag samlat är pålitlig. Hög reliabilitet har undersökningen om olika och oberoende mätningar av ett och samma fenomen ger jämförligt resultat (Holme & Solvang, 1997).

Genom datatriangulering, d.v.s. genomförandet av undersökningen med olika respondenter och olika böcker i referensramen, ämnar jag att pröva reliabiliteten och framlägga bevis för den. Tillförlitligheten är dock relaterad till min egen förmåga att bedöma. Att använda fas-ta och strukturerade rutiner för dafas-tasamlingen är en hjälp för att skapa relativt god reliabili-tet.

Enligt Patel & Davidson (2003) är begreppen reliabilitet och validitet så sammanflätade att kvalitativa forskare sällan använder begreppet reliabilitet. Istället får begreppet validitet en bredare innebörd.

Validitet

ras begreppet validitet till om jag som forskare lyckas skaffa underlag för att göra en tro-värdig tolkning av det studerade fenomenet. Validiteten kopplas också till om jag lyckas att fånga det som är svårtolkat och kanske motsägelsefullt (Patel & Davidson, 2003). Genom att argumentera för de tolkningar jag gör hoppas jag på att tillföra undersökningen god va-liditet.

I vilken utsträckning kan jag mäta det jag avser att mäta? Genom att använda mig utav strukturerade intervjuer har jag för avsikt att prägla insamlad information med hög validitet. Alltså genom att använda gemensamma variabler i undersökningen säkerställs innehållsva-liditeten. Jag kommer likväl att använda olika tekniker för att undersöka samma fenomen, ostrukturerade kontra strukturerade intervjuer.

Trots att jag har förutbestämda kriterium för att mäta undersökningens reliabilitet och vali-ditet är det svårt att övertyga att mätningarna är fullständiga. Eftersom jag dessutom an-vänder mig utav en hermeneutiska ansats försvårar detta ytterligare att påvisa dessa variab-lers fullständighet.

2.3.3 Databearbetningsmetod

Den äldsta formen av kvalitativ bearbetning av data är hermeneutisk. Huvuduppgiften är att lyfta texten ur den främlingskap den befinner sig i, tillbaka till den levande nuti-den.(Olsson & Sörensen, 2007).

GT, grounded theory, innebär att en mängd data systematiskt grupperas och omgrupperas genom en kontinuerlig, komparativ analys tilldess att en fullständig kartläggning av företeel-sen eller händelseförloppet är gjord. GT är allt så en bearbetningsmetod som används inom den kvalitativa ansatsen i forskningsarbetet och är övervägande induktiv (Olsson & Sören-sen, 2007). Det är centralt att planer för hur data ska bearbetas för att skapa bra struktur och formalia i uppsatsen. I och med valet av en hermeneutisk ansats har jag valt att bearbe-ta samlad information och dabearbe-ta med hjälp av en generell analysmodell. Att använda en ana-lysmodell underlättar för läsaren att följa resonemanget och skapar god förutsättning för att bearbeta all informationen unisont. Jag anser att mitt val av databearbetning går att jämföra med GT då jag eftersträvar att generera ett sannolikhetsbaserad slutprodukt. Mitt mål är jämförbart med intentionen inom GT, d.v.s. att hitta en modell för problemlösning som kan generera ett underlag som också förklarar problemlösningen inom studerat område.

2.4 Praktiskt tillvägagångssätt

Hur jag i praktiken har gått tillväga skildras i denna del av kapitlet. Jag återkopplar till samt-liga rubriker i föregående del, metoden.

Datasamlingsmetod

För att bygga upp en relevant referensram av sekundärdata i förhållande till uppsatsämnet har jag använt flera olika aspekter av teori. Primärt är det litterära verk som jag har samlat information ifrån men även vetenskapliga artiklar har använts samt sparsamt med komplet-terande information från Internet källor.

re-ferensram. Jag har valt att inte inkludera mer än vad som är behövligt för att förstå och analysera problematiken på ett överskådligt men absolut grundläggande vis. Förhållandet mellan respektive teori förhåller sig också det naturligt då de både kompletterar varandra och framhäver ett heltäckande perspektiv. Valet av teori har också grunden i vad jag upp-fattar som relevant för att föra diskussionen i uppsatsen på en saklig och tillförlitlig nivå. Intervjuerna är genomförda i olika etapper för att skapa struktur i inflödet av information kring valt problematikområdet. Tre olika nivåer ska genomarbetas innan intervjufasen be-traktas som avslutad. I nivå ett ska jag genomföra tre diskussionspunkter med tre aktörer ur IT-funktionen. Benämningen diskussionspunkt syftar till intervjuns karaktär som är av ostrukturerat slag. Funktionen som samtliga aktörer representerar är den interna IT-funktionen och deras specifika roll benämns som teknisk projektledare varav deras roll i processen är central. Diskussionspunkten genomförs enskilt med varje respondent och i re-lation till erfarenhet från olika systemutvecklingsprojekt som aktörerna medverkat eller medverkar i. Kravhanteringsprocessen i respektive systemutvecklingsprojekt är erkänd vil-ket skapade god förutsättning för att samla information med varierande förutsättning. Del två av nivå ett innefattar en andra intervjuomgång med samma tre aktörer men denna gången utifrån en strukturerad intervjuguide (se bilaga 1).

Nivå två inkluderar två nya aktörer i datasamlingsprocessen, nämligen två beställare ur verksamheten. Intervjun som ska genomföras är av strukturerad karaktär med öppna frågor för att inte skapa restriktioner och tappa nödvändig information. För att skapa ett sam-stämmigt analysunderlag använder jag samma intervjuguide som i föregående etapp . I nivå tre fullföljs datasamlingen genom kompletterande intervjuer med organisationens över-gripande IT-chef samt en av projektledarna ur verksamheten.

Informationen samlad i undersökningen kommer att dokumenteras digitalt med möjlighet för respektive respondent att läsa vad som sammanställts. På så vis hoppas jag att informa-tionen ska vara fläckfri vad gäller egna värderingar av vad som egentligen förmedlades, d.v.s. jag efterfrågar en kritisk granskning av att den information jag samlat är korrekt. Intervjuerna ska genomföras på respektive respondents kontor med möjlighet för den till-frågade att okomplicerat plocka fram relevanta underlag att relatera till. De deltagare som omfattas i studien är utvalda i samarbetet med organisationens IT-chef och i förhållande till de avgränsningar jag valt för uppsatsen..

Databearbetningsmetod

Figur 2:2: Analysmodell (Skolverket, 2007).

Analysmodellen kommer att användas för att analysera de mest frekvent omnämnda pro-blemen i underökningen. Modellen skapar struktur och utgör en formalia som passar un-dersökt fenomen. Modellen innehåller förutbestämda informationsbaser som ska fyllas med attribut som är karaktäristiska för problemet. Att visualisera problemet på det här viset gör det enkelt för läsaren att få ett övergripbart perspektiv utan grundligare insatser. Orsaker till problemet klargörs tydligt liksom de konsekvenser fenomenet resulterar i och därtill adde-ras lämpliga åtgärder. Alla fakta är ett resultat av analysen i respektive sakförhållande. För att förtydliga modellen ytterligare bör den tolkas på så vis att åtgärderna är tillämpbara både för att lösa orsakerna till problemet samt att motverka konsekvenserna. Genom att studera problemet utifrån valt synsätt finns det större möjlighet att klarlägga en realiserbar lösning som kontrollerar helheten istället för att analysera problemet i form av en cyklisk modell. Traditionellt sätt skulle det mest naturliga tillvägagångssättet alltså vara att läsa mo-dellen periodiskt i strikt följd, jag anser dock att vald analysmodell passar ändamålet desto bättre. Genom att ”peka” lämpliga åtgärder åt endera identifierade orsaker samt konse-kvenser indikerar på motivet till en komplett lösning som inte enbart fokuserar på källorna till problemet utan dessutom syftar till att förebygga symptomen.

Förutom att använda en analysmodell kommer jag också att bearbeta samlad data ”manu-ellt”. Jag kommer utifrån samtliga ämnesområden aktuella för studien att föra en djupare diskussion med egna tankar och synpunkter. Reflektionerna är i förhållande till resultatet från undersökningen. Dessutom kommer jag frekvent att motivera mitt sätt att tolka på med stöd från den teoretiska referensram som är aktuell för uppsatsen. I och med min hermeneutiska ansatts till ämnet är det också centralt att inkludera goda argument för att styrka min avvägning i respektive sakfråga.

2.5 Relationen mellan teori och empiri

på ett empiriskt underlag. Att jag inte utgår från en teori är inte detsamma som att jag arbe-tar helt förutsättningslöst. ”Även den induktivt arbetande forskaren har egna idéer och föreställningar som ofrånkomligt kommer att färga de teorier som produceras” (Patel & Davidson, 2003, s. 24). I uppsatsen karaktäriseras relationen mellan teori och empiri av ett induktivt arbetssätt. Jag har följaktligen startat i en empirisk studie som grundade för den teori som referensramen är byggd utav. Precis som Patel och Davidson (2003) nämner har jag inte arbetet helt förut-sättningslöst utan egna idéer och föreställningar ligger också till grund för de teorier som fabriceras i uppsatsen. Då jag valde att utgå från empirin föll valet av teori naturlig, studien speglade nämligen en tydlig referensram för mig att finna stöd i. Genom att inleda datasam-lingen tämligen ostrukturerat kunde jag formulera en tillämpbar referensram. Relationen mellan teori och empiri har utifrån detta tillvägagångssätt karaktären av ett induktivt arbets-sätt snarare än ett deduktivt. Jag vill dock tillägga det faktum att en induktiv slutledning ald-rig kan vara 100 % säker då den bygger på empiriskt material som ej kan beräknas som full-ständigt (Thurén, 1991). Enligt Thurén (1991) kan den induktiva ansatsen omkullkasts av erfarenhet men jag anser den vara mer tillämpbar än den deduktiv då jag inte riskerar att på grund av allt för logiska resonemang dra en felaktig slutledning då de helt enkelt inte alltid stämmer överrens med verkligheten. Jag har haft vissa funderingar över huruvida det möj-ligtvis kan vara en fråga om abduktion då jag vid tillfälle pendlat mellan teori och empiri likvärdigt båda koncepten men genom den utvärdering jag gjort anser jag att induktion lig-ger närmast tillhands och är det mest korrekta sättet att beskriva relationen mellan teori och empiri i denna uppsats.

2.6 Källkritik

I en Internet källa hittade jag följande historia som på ett enkelt sätt beskriver vad källkritik är och har följaktligen tänkt att inleda denna avslutande delen av kapitlet med ett citat från den:

”Om två personer ska beskriva en händelse gör de det med stor sannollikhet på olika sätt. Person A upp-fattade x medan person B uppfattande y. Båda har olika berättelser, de använder olika ord och återger oli-ka bilder – men ingen ljuger! Vad det handlar om är att olioli-ka människor uppfattar och beskriver samma verklighet på olika sätt. Vi ser världen med olika ”glasögon” och när vi återberättar verkligheten med hjälp av ord använder vi olika ”pennor”” (Luleå komvux, 2006).

Källkritik är alltså ett verktyg som vi kan använda oss utav för att avgöra om innehållet i en källa är sant eller falskt. Metoden generera också svar på om källan är användbar för denna fråga vi söker svar på. Vanligt är att tala om källkritiska principer eller krav. Nedan kommer jag att reflektera över de källor som jag har valt för uppsatsen, deras relevans och använd-barhet utifrån Thuréns (1997) sju kriterier för källkritik.

1. Äkthet

2. Distans

De primära källornas distans till händelsen är mycket aktuell vilket ökar att sanno-likheten att deras påstående är sant och användbara för undersökningen. De sekun-dära källorna varierar i distans till händelsen men min generella bedömning säger att de har relevans för uppsatsen så som tillämpade. I referensramen är samtliga källor som jag använt publicerade under 2000-talet. I metodkapitlet har jag däremot också brukat källor av äldre karaktär då jag inte anser att de har någon betydelse för resul-tatet. Metodologi är ett ämnesområde som det går att relatera till med distans utan att källan tillförlitlighet ska behöva ifrågasättas. Det är centralt att hitta rätt mix och mognad i litteraturen för att utvinna fakta med hög relevans.

3. Oberoende

De litterära källorna är med alla säkerhet inte en avskrift då flera av dem används som kurslitteratur på universitets nivå samt att de går att återfinna i andra litteratur-förteckningar av godkända uppsatser. Det är desto svårare att avgöra huruvida de vetenskapliga artiklar jag har använt uppfyller kriteriet. Min uppfattning är dock, då de finns publicerade i skolans databas att de är korrekta även i detta avseende. 4. Tendensfrihet

Jag kan inte tyda några dolda motiv eller avseenden som författare eller respondent haft förutom det som konkret har förmedlats. Det har klart och tydligt framgått syf-tet med informationen.

5. Urvalet

Detta kriterium ställer sig till huruvida urvalet kan betraktas som snedvridet, d.v.s. att jag har valt vissa källor framför andra för att skyla svagheter och stärka min ar-gumentation. Jag anser att vad gäller de primära källorna finns inte en sådan ten-dens då de dessutom har pekats ut i ett nära samarbetet med fallföretaget aktuellt i undersökningen. Vad gäller uppsatsen sekundär källor har jag inte medvetet valt nå-gon för att främja min egen forskning. De källor som är tillämpade är valda med principen att de passade uppsatsämnet. Vissa är det personliga preferenser som styrt valet med inte baserat på faktorer med syfte att hjälpa fram min forskning. 6. Tolkningen

Jag använder som bekant en hermeneutisk ansats i den här uppsatsen varv mitt sätt att tolka baseras på min förförståelse. Huruvida den är korrekt kan inte jag avgöra utan det ligger i betraktarens ögon. Jag kan bara argumentera för de faktorer som styr min förförståelse och på så vis upplysa läsaren utifrån vilka bedömningsgrunder min tolkning baseras.

7. Sannolikheten

3 Teoretisk referensram

”I referensramen finns teori som används för att tolka och förstå den empiriska observationen. Teorin har som syfte att skapa en mer heltäckande förståelse för det undersökta fenomenet”.

3.1 Kravhanteringsprocessen

Kravhanteringsarbetet blir allt svårare för varje år. Idag kommunicerar nästa alla system med flera andra system och utbyter information. När systemen blir allt mer komplexa blir de också allt svårare att bygga. Systemutveckling sker idag under stor press och kräver att resultatet levereras i rätt tid, med rätt kvalitet och inom budget. För att möta dessa villkor krävs en kravhanteringsprocessen som gör det möjligt att arbeta effektivt utan att uppfinna hjulet på nytt varje gång. Kontentan utav resonemanget är att felaktigheter i kravhanter-ingsprocessen leder till bristande kvalitet i de IT-system som utvecklas (Eriksson, 2007). Kraven på ett IT system ändras med största sannolikhet under ett projekts gång. Desto längre tid systemutvecklingsprojekt tar desto större är risken att det som levereras inte stämmer överrens med kundens krav. En av de största felkällorna vid utveckling av IT-system är just kraven, hela 56 %. Ofta är fallet att kraven samlas in med fel teknik och från fel intressenter. Därtill dokumenteras kraven ofta bristfälligt vilket medför att den som läser dem tolkar informationen annorlunda än författarens intention. Har man däremot en mo-gen kravhanteringsprocess där kraven kontinuerligt kvalitetssäkras är felkällan oftast mind-re (Eriksson, 2007).

Brister i kravspecifikationen leder till fel som kostar pengar att åtgärda. Felen blir desto dy-rare att åtgärda ju senare de påträffas. Det är därför billigare att åtgärda felen i ett tidigt skede. Enligt Barry W Boehm (Eriksson, 2007) ökar kostnaden för fel krav tiofalt med var-je led i processen. Ett fel som kostar 10 kr i kravfasen kostar 100 kr om det påträffas under designen, 1000 kr i implementeringsfasen och 10 000 kronor i drift. Baserat på Boehms tes kan vi dra slutsatsen att det är centralt att göra rätt från början och att hitta felen tidigt för att undvika att de multipliceras. Testfall bör skrivas tidigt i processen vilket genererar att kraven tidigt gås igenom. Många av felen kan då lokaliseras i ett tidigt skede och elimineras kostnadseffektivt.

En iterativ arbetsprocess

”Kravhanteringsarbetet är i många fall mycket omfattande, och att göra allt i en sekvens är som att försöka äta en hel elefant på endaste måltid. Det är istället mycket bättre att stycka upp elefanten i många små de-lar och att äta en bit i taget.” (Eriksson, 2007, s. 31).

Kravhantering är en integrerad del i systemutvecklingen. När man arbetar iterativt gör man till att börja med vissa delar av kravhanteringsarbetet och förfinar sedan kraven i ett antal varv som kallas iterationer. Fördelarna med att arbeta iterativt är att snabbare återkoppling kan ges och en bättre överblick serveras. Det iterativa arbetet medför även ett stöd för att driva andra aktiviteter parallellt, exempelvis testning.

3.1.1 Bevisad problematik för kravsamling

• Det är intressenterna som besitter kunskap om de olika behov systemet ska tillgo-dose. Ofta är det svårt att identifiera och få tillgång till alla berörda intressenter, även intressenternas behov motsätter ibland varandra och måste rangordnas vilket kan skapa motsättningar.

• Användaren har svårt för att konkret uttrycka sitt behov.

• Beställare och användare har svårt att förmedla de krav som önskas.

• Begreppsapparaten mellan IT-aktören och beställare varierar och grundar för tolk-ningssvårigheter. En pretention är följaktligen att beställaren måste känna igen sina krav för att förstå vad som ska levereras.

• Orutinerad och oengagerad beställare.

• Personer byts ut i pågående process och betydelsefull kunskap går förlorad. • Beställaren anser att det är leverantören som ska tala om hur systemet ska se ut. Typiska problemkällor

Problem som associeras till kravhantering är ofta erkända att påverka kvaliteten på systemet och kvaliteten i utvecklingen. Det har uppskattats att kravfel som korrigeras sent kan kosta upp till 200 gånger så mycket som det skulle kosta att rätta till bristerna i själva kravhanter-ingsfasen. Många systemutvecklingsprojekt brister eller misslyckas p.g.a. att de innehåller en mängd bristfälliga krav. Inget systemutvecklingsprojekt har möjlighet att hålla tilldelad bud-get, tidsram eller kvalitet under kontroll om kraven är dåligt definierade. För att utveckla system som matchar verksamhetsbehovet måste man vara mycket noggrann med att identi-fiera eventuella problem i kravhanteringsprocessen. Det primära resultatet som framgår i artikeln skriven av Niazi & Shastry (2003) är att kravhanteringsprocessen är en central fel-källa i systemutvecklingsprojekt. Syftet med studien är följaktligen att förstå hur man kan förbättra processen för att reducera problemnivån och på så vis förbättra systemkvaliteten. Vi måste således förstå kravhanteringsprocessen roll i systemutvecklingsprojekt.

I en organisation med en mogen kravhanteringsprocess har följande problemområden identifierats i omnämnd ordning, se tabellen:

Kravhanteringsproblem Frekvens %

Kraven eskalerar 50 %

Kraven är inkonsekventa och ofullständiga 43 %

Kommunikationen med användaren fungerar inte optimalt 43 %

Vagt formulerade, inledande krav 43 %

Applikationens komplexitet 36 %

Avsaknad av ledningsstöd i processen 36 %

Kraven reflekterade inte det verkliga behovet 36 %

Bristfällig förståelse för användarens behov 29 %

Olämpliga färdigheter 21 %

Avsaknad av tydligt ansvar 14 %

Verksamhetsbehovet övervägs inte 7%

Bristfällig spårbarhet i processen 7 %

Tabell 3:1: Kravhanteringsproblem (Niazi & Shastry, 2003).

För att undvika dessa problem är det centralt med ett holistiskt tillvägagångssätt för att uppnå god kvalitet. Det är alltså viktigt att verksamheten inte enbart fokuserar på processen i sig utan även kringliggande faktorer som påverkar (Niazi & Shastry, 2003).

3.1.2 Vikten av att hitta rätt krav och att dokumentera

Prioriteringen av ett krav ska baseras på kravets värde för verksamheten kombinerat med kunskap om vilka krav som innefattar störst risk och kostnad för utveckling. Så är ofta dock inte fallet. En tydlig fallgrop är att användaren prioriterar alla krav som ”viktiga” eller att ingen större hänsyn tas till prioriteringen utan man försöker bara rymma så många krav som möjlighet inom budget. Det är av central betydelse att prioritera rätt. Prioriteringen vi-sar vilka krav som är viktigast och rätt resurser kan därefter tilldelas, detta skapar också förutsättningar för att leverantören ska kunna lägger mer energi på högt prioriterade krav. Även krav med stor risk bör lösas tidigt för att undvika att hela projektet äventyras (Eriks-son, 2007).

Fokus på osäkerhet och komplexitet

Att hantera verksamhetskrav i systemutvecklingsprojekt ställer hårda krav och nya utma-ningar på kravhanteringsprocessen som ofta drivs av osäkerhet och komplexitet. I och med att behovet kontinuerligt utvecklas och förändras beroende på den ständigt föränderliga och dynamiska omvärld de samlas i är det omöjligt att samla alla krav i förväg. Traditionell kravhantering fokuserar många gånger primärt på om kravet är fullkomligt, konsistent och korrekt vilket gör det omöjligt att reagera på de förändringar som sker i dagens utveck-lingsmiljö. Teorin som följer redogör för ett tillvägagångssätt som istället fokuserar på verksamhetsbehovet och ett resultatinriktat samarbetet med IT aktören (Reynolds, 2006). Idag går det inte att samla krav under långa perioder då de kommer att motsvara ett inaktu-ellt behov. I de flesta systemutvecklingsprojekt är det också omöjligt att alla krav skulle vara kända i förväg Kraven bör stämma överens med aktuellt behovet och vara värdeadderande för den övergripande affärsstrategin. Idag räcker det sålunda inte att samla krav enligt gammal teknik utan vi är tvungen att börja fokusera på det verkliga behovet och verksam-heten måste alliera sig med IT aktören för att nå framgång i processen (Reynolds, 2006). Osäkerhet och komplexiteten i kravhanteringsprocessen är ett påtagligt problem vilket gör den nödvändig att utveckla. Osäkerheten representerar ofta att man har otillräckligt med in-formation för att beskriva behovet.. Ett typexempel för att beskriva scenariot är följande samtal mellan IT-aktören och verksamhetsrepresentanten:

IT-aktören: - Vilka är era affärsbehov för kommande 3-5 år? Verksamhetsrepresentanten: - Det vet jag inte.

IT-aktören (frustrerad): - Men hur ska jag då kunna bygga en IT applikation som stödjer er affärsverk-samhet?

Verksamhetsrepresentanten (frustrerad): - Det beror på kundens behov och hur dessa förändras.

Faktumet i berättelsen är att ”behovet beror på”. Traditionellt kravhanteringsarbete kräver att man gör en godtycklig gissning om framtidens behov man vet dock att kundens behov inte är säkra eller fastställda kriterium och detta stimulerar till att inkludera alla tänkbara krav i processen. Resultatet blir en stor mängd krav vilket resulterar i högre kostnader. Att kunna hantera osäkerheten kräver alltså en förståelse för att det inte är möjligt att känna till alla krav i förväg. Utmaningen är att kunna leverera de krav som är kända och samtidigt göra det möjligt att leverera övriga, framtida krav, i takt med att de avslöjas (Reynolds, 2006).

Komplexitet är ytterligare en faktor som försvårar kravhanteringsprocessen i systemutveck-lingsprojekt. Komplexiteten kan emellertid reduceras genom att minimera beroende mellan moduler vilket i sin tur skapar bättre förutsättning för att brister i en modul inte ska för-summar hela systemet. Komplexitet övervinns följaktligen genom att tillåta att projektet ut-vecklas i hanterbara komponenter.

Reynolds (2006) refererar i sin artikel till ett systemutvecklingsprojekt ur verkligheten där man valde att hantera kravhantering på ett nytt, situationsanpassat sätt. Kraven skulle an-nars vara inaktuella vid själva implementeringen. Systemet utvecklades därför i en iterativ process med prototyper och oberoende komponenter. För att utvärdera risken varje del av projektet utgjorde skrevs individuella business case 5 _{för varje iteration. Ett beslut fattas}

projek-ifrån underlaget varav om projektet ska utföras, skjutas fram eller förkastas. Genom att ar-beta iterativ slapp projektteamet att samla in och utveckla alla krav för hela projektet i för-hand. Hela kravhanteringsprocessen grundar sig således på att utifrån resultatet från före-gående iteration samla nya krav som motsvarar aktuellt behov, för att i slutändan inte riske-ra att levereriske-ra något som inte är aktuellt att implementeriske-ra. Tillvägagångssättet gjorde att projektteamet kunde hålla bestämd tidsram och effektivt leverera funktionalitet som stäm-de överens med behovet. Konceptet grundar sig följaktligen på att undvika samla alla krav i förväg och istället kontinuerligt, i takt med att projektet fortlöpor, leverera värde till verk-samheten. Det handlar alltså om att fokusera på faktorerna osäkerhet och komplexitet för att lyckas.

I praktiken är dagens systemutvecklingsmiljö mycket osäker, kraven otydliga och tiden till-delad för att samla dessa mycket kort. Att validera och samla krav utifrån en traditionell process är inte effektivt i denna typ av systemutvecklingsmiljö. Genom att strukturera kravhantering till en serie av mindre projekt, finns det istället möjlighet att leverera mellan-liggande behov då ytterligare krav samlas allteftersom individuella business case godkänns (Reynolds, 2006).

3.1.3 Metoder för effektiv kravhantering

Som nämnt står systemutvecklingsprojekt i nära relation till kravhanteringsprocessen. Det är således centralt att arbeta efter bra metoder, alt. best practices, för att bibehålla en effek-tiv infrastruktur för kravhantering, liksom för att identifiera, samla och för att hantera olika krav. Många gånger är det omfattande mängder med krav som måste tillfredställas för att kunna bygga ett kvalitativt system. Ett vanligt problem är att man inte är kapabel att defini-era och spåra krav. Ett annat påtagligt problem är att kraven ofta förändras under system-utvecklingen. Icke funktionella krav förbises ofta i processen då de inte anses lika betydel-sefulla som de funktionella. Dessa är dock lika viktiga eftersom ett systems funktionalitet måste utföras på en acceptabel nivå som definieras av de icke-funktionella kraven. Utan dessa krav blir resultatet inte användbart. Därför kan man inte förutsätta att en typ av krav är viktigare än en annan (Pozgaj, Sertic & Boban, 2003).

Krav bör användas i alla faser av systemutvecklingen som riktlinjer för vad som verkligen efterfrågas. Att använda best practices likt de metoder nämnda av Pozgaj, Sertic & Boban (2003) är ett bra sätt att gå tillväga för att utvecklingen ska kunna ske enligt kundens behov och ett lyckat resultat levereras.

3.2 Teamet

”Ett team består av enskilda individer men är samtidigt något annat och större än dessa. För att förstå ett team kan vi inte utesluta studier och förståelse av den enskilda individen, men vi kan inte heller nöja oss med bara detta” (Larsen, 2003, s. 14).

Det är centralt att ta hänsyn till den kontext teamet verkar i. Om vi endast skulle fokusera på teamet och ignorera kontexten är det många gånger inte ovanligt att problem uppstår. Det är alltså viktigt att balansera uppmärksamheten mellan inre och yttre faktorer. Vi bör studera både de enskilda individerna och gruppen parallellt som vi tar hänsyn till den kon-text som teamet uppträder inom (Larsen, 2003).

Det har i många och oberoende studier påvisats att teamet är viktigt för att ett projektet skall nå framgång. Oväntat är teamet en av de minst undersökta faktorerna i många studier som berör projektarbete. Ofta bortser vi från att det även finns psykologiska faktorer som påverkar de egenskaper man egentligen tar förgivet. Det har konstaterats att team och grupper kan vara såväl effektiva som ineffektiva . ”Det är inte ovanligt att vissa arbetare agerar egoistiskt och behåller kunskap för sig själv, eftersom detta kan vara av personlig konkurrensfördel i orga-nisationen….Det är heller inte säkert att experter vill ta del av andras kompetens. Det är tänkbart att stolthet, högmod och personligt ogillande hindrar professionella medarbetar från att erkänna andras kompe-tens som relevant eller viktig” (Ricciardi & Schaller, 2005, s. 42). Det är viktigt att inte glömma att team, tillskillnad från maskiner och teknologi, består av levande väsen. Vi bortser i många fall från gruppens inte liv. De inre processerna är betydelsefulla att studera för att öka för-ståelsen för den dynamik som utspelar sig i ett projektteam där arbetet bedrivs under stor tidspress (Ricciardi & Schaller, 2005).

3.2.1 Grupputveckling enligt FIRO-modellen

Den dynamiska grupputvecklingen gäller alla typer av grupper. Vi befinner oss oavbrutet i olika grupper och konstellationer där vi påverkas och upplever resan i FIRO-cirkeln. Will Schutz, en amerikans psykolog, har utvecklat teorin kring FIRO 6_{. Syftet var att ta reda}

på varför vissa grupper fungerar bättre än andra trots att de enskilda personernas skicklig-het och utbildning är den samma. I sin forskning fann han att en grupp genomgår tre hu-vudfaser under sin utveckling mot enighet och effektivitet, tillhörighet, rollsökning och samhö-righet.

En grupp som ska uppnå öppenhet och effektivitet måste genomgå samtliga tre faser i om-nämnd ordning för att lyckas. Grupprocessens utveckling karaktäriseras alltså för att vara cyklisk i sin natur.

3.2.1.1 Tillhörafasen

vilket i många fall karaktäriserar ett moget team, saknas. Medlemmarna spelar ofta en roll snarare än sig själva. Trots avsaknaden av sammanhang kan ett team som befinner sig i till-höra fasen fungera bra.

Vanliga beteenden i denna fas är att alla är mycket artiga mot varandra och visar ett stort behov av att bli accepterade av gruppen. Deltagaren kontrollerar gärna också behörighet och kompetens hos andra. Ledaren har en betydelsefull roll i tillhörafasen för att leda grup-pen vidare i processen. För att nå nästa fas i FIRO-cirkeln krävs det att man river de mel-lanmänskliga hinder som finns, bygger upp tillit och öppenhet gentemot varandra. Teamet måste öka sitt känslomässigengagemang och dela med sig av erfarenheter och upplevelser (Affektor Utveckling AB, 2007).

3.2.1.2 Rollsökningsfasen

Enligt Schutz är detta den fas som är mest svår och tidskrävande och som faktisk en del grupper aldrig tar sig ur (Eklund, 2002). Denna turbulenta period karaktäriseras av makt-fördelning och rollkonflikter. Det är en stormig fas eftersom starka känslor släpps lösa och resultatet kan bli dramatisk, t.o.m. destruktivt.

Det finns i gruppen en öppen konkurrens och det är inte ovanligt att subgrupper bildas. Ledarskapet är en aktuell fråga och antingen försöker respektive medlem ta ledarskapet el-ler undvika rollen. Det finns ett stort behov av struktur och ledarskap men det finns samti-digt en ovilja inom gruppen att tillåta någon att tillfredställa detta behov. Uppror mot gruppens formella ledare är inte ovanligt.

Det finns många frågor som ska tas ställning till under denna fas. Det kan röra underlig-gande områden som samhörighet, respekt, delade värderingar och tillit. Detta görs sällan på en medveten nivå men den är nödvändigt att var och en skapar ett personligt förhållande till alla övriga medlemmar för att nå vidare. Under rollsökningsfasen börjar följaktligen oli-ka typer av relationer att växa fram men för att nå den sista fasen i FIRO-modellen krävs det att gruppen inser att många uppgifter kväver lagarbete. Det ska vara möjligt att lyfta fram svårigheter och arbeta igenom dem samtidigt som det måste finnas respekt mot olik-heter. Alla roller och förväntningar måste vara glasklara för vederbörande part så att slutli-gen broar kan byggas mellan gruppens olika deltagare (Affektor Utveckling AB, 2007).

3.2.1.3 Samhörighetsfasen

I samhörighetsfasen är de flesta konflikter lösta och gruppen präglas av en stark känsla av tillfredställelse. Nu kan den mesta av gruppen energi läggas på effektivt arbete och gruppen omnämns ofta vara ömsesidigt beroende (Eklund, 2002). Många grupper når emellertid ald-rig denna fas. För att nå den öppenhet som utmärker samhöald-righetsfasen krävs ett visionärt ledarskap, både inom gruppen och inom organisationen.

Samhörighetsfasen speglas av nära relationer där gruppens medlemmar respekterar och uppskattar varandras olikheter. Det finns en klar och förankrad målbild och ”lagprocessen” möjliggör problemlösning samt effektivt utvecklingsarbete. Relationen mellan medlemmar-na utvecklas och atmosfären präglas av samarbete och ömsesidig support. ”Energi frigörs. Ti-digare osäkra medlemmar växer och stärker både sitt självförtroende och sin kapacitet. Djupare känslor av omtanke är typiska och man relaterar med lätthet och glädje med varandra” (Affektor Utveckling AB, s. 8, 2007). Beslut kan nu fattas både snabbare och mer effektivt. De tidskrävande diskussio-nerna om principer och värderingar har blivit onödiga nu när gruppens medlemmar vet hur de andra tänker och känner.

Gruppens medlemmar får heller inte känna hot eller avundsjuka mot parbildning och sub-grupper. Alla medlemmar ska istället stödja varandra aktivt, kunna handskas med relations-problem utan att eftersätta uppgiften och framförallt kunna kommunicera klart och tydligt med varandra. Inom gruppen får det absolut inte förkomma påhopp som nedvärderar nå-gon annan utan det ställs höga krav på grupplojalitet (Affektor Utveckling AB, 2007). Separationsfasen

I Schutz modell utelämnas s.k. separationsfasen men som ändå bör omnämnas för att för-stå hur en grupp reagerar vid själva upplösningen. Själva upplösningen av teamet sker näm-ligen inte utan vånda. Det är både en intressant uppgift och själva gemenskapen som läm-nas då en grupp löses upp och inför avskedet kan latent oror och olösta konflikter åter blossa upp. Desto mer sammansvetsad en grupp varit, desto svårare är det att upplösa den, gruppens medlemmar grips lätt av s.k. separationsångest. Ofta väljer man dock att lägga locket på enligt mottot ”slutet gott, allting gott” (Maltén, 1998).

3.2.1.4 Vad händer i övergången mellan faserna

Mellan FIRO-modellens tre faser går det att urskilja två övergångsfaser. Båda dessa karak-täriseras av konfliktlöshet och har fått benämningen gemytstadiet och idyllstadiet.

Gemytstadiet

Detta stadium kan guppen hamna i först då de känner att alla är med i gruppen, alltså mel-lan tillhörafasen och rollsökningsfasen. I gemytstadiet lägrar sig ett gemytligt lugn och en falsk vi-känsla. Gruppen utnyttjar denna fas, gemytkänsla, för att hämta kraft och så länge som möjligt undvika att ta tag i och lösa det som ligger framför dem (Affektor Utveckling AB, 2007).

Idyllstadiet

Idyllstadiet inträffar i övergången mellan rollsökningsfasen och samhörighetsfasen. Detta stadium föregås ofta av en intensiv konflikt eller kris i gruppen. Resultatet av att ta fram och lösa konflikten gör många gånger att gruppen känner sig befriad. När gruppen befinner sig i idyllstadiet är den ofta obenägen att ta sig an nya svåra uppgifter och det finns risk för att vissa grupper kan fastna här (Affektor Utveckling AB, 2007).

3.2.1.5 Gruppens energi

För att lösa de uppgifter som gruppen blivit tilldelad krävs en stor energiinsats av gruppdel-tagarna. Beroende på var i FIRO-cirkeln gruppen befinner sig riktas energin olika. Det är först i samhörighet som all energi kan riktas på den uppgift gruppen fått föreskriven att lösa. Kontinuerligt under fasen kan kraften nu koncentreras på att vidareutveckla positiva kommunikationssätt, förtroende och acceptans för varandra (Affektor Utveckling AB, 2007).

3.2.2 Teamets sammansättning

vation för arbetsuppgiften (Larsen, 2003). ”God människokännedom är viktigt för att kunna bygga upp en grupp med god sammanhållning” (Larsen, 2003, s. 20).

Ytterligare en aspekt vid gruppens sammansättning är huruvida det är lämpligt att sätta samman en relativt homogen gupp människor, ”lika barn leka bäst”, eller en mer heterogen grupp som kan stimulera varandra men med riks för oenighet och konflikter. Oberoende vad man väljer krävs det att de människor som teamet består av kommer överrens och kan hittar sätt att samarbeta på, så att de kompletterar istället för att bekämpa varandra.

Det är också viktigt att fundera över om det finns någon riks för att för många ”ja männi-skor” ingår i teamet, d.v.s. människor som sällan argumenterar mot eller vågar ifrågasätta. Det är av den anledningen centralt att inkludera kreativa människor och de som kritiskt vå-gar analysera och säga ifrån när det behövs. Detta är särskilt viktigt i ett team som ska fatta beslut med avgörande konsekvenser (Larsen, 2003).

Det finns olika typer av grupper. Den gruppkaraktär som är av positiv variant är den mog-na/flexibla gruppen. Teamet kännetecknas då utav att varje enskild medlem känner sig trygg och det blir just därför lättare att skapa samhörighet. I teamet förekommer både själv-ständighetstendenser och en strävan mot intimitet och samspel. Varje gruppmedlem bjuder på de resurser de förfogar över samtidigt som gruppen med jämna mellanrum utsätter sig själva för kritisk granskning samt utvärdering. Utvecklingsarbetet känns följaktligen natur-ligt och i linje med gruppkaraktären beskriven av Maltén (1998).

För att skapa effektiva gruppmedlemmar är det enligt Dimberly & Burton (1999) viktigt och nyttigt att uppmärksamma vad det är som motiverar människor att ansluta sig till en grupp. Även rollfördelningen inom gruppen är betydelsefull för dess effektivitet liksom re-lationen mellan teamets medlemmar. Även verbala och icke-verbala färdigheter spelar roll samt hur gruppens utveckling till en homogen sammanhängande kraft. Det bör också fin-nas en förståelse för gruppidentiteter och etikettering av människor efter gruppmedlemskap och roller.

3.2.2.1 Normer

Normer är gemensamma förväntningar på beteende. Det förväntas ofta att alla som tillhör en grupp följer dess normer och uppför sig på ett bestämt sätt. Normalt är det bara det som anses vara viktigt för gruppen som normregleras. Det är viktigt för ledaren att vara medveten om de normer som förekommer inom teamet eller som håller på att utvecklas för att kunna påverka processen och på ett effektivt sätt skapa önskvärda normer. Infor-mella normer av dålig karaktär är nämligen ofta svåra att kämpa emot och det är därför önskvärt att förekomma dessa genom att utveckla goda, konstruktiva och uppbyggande normer. För att teamet ska kunna fungera väl är det viktigt att utveckla generösa normer som tillåter viss avvikelse. Det ska vara en normkultur som uppmuntrar till aktivt och kon-struktivt meningsutbyte för att kunna producera bättre och mer välgrundande beslut ge-nom att låta skilda synsätt och värderingar träda fram (Larsen, 2003).

Det är betydelsefullt att gruppens normer kan diskuteras öppet så att alla förstår vad som förväntas. Normer ska gälla alla och måste upplevas som rättvisa för att generera ett gott resultat.

3.2.2.2 Samhörighet