School of Mathematics and Systems Engineering
Reports from MSI - Rapporter från MSI
Kravhantering i
systemutvecklingsprojekt
- problem i praktiken
Jessika Svensson
Feb
2008
MSI
Växjö University
SE-351 95 VÄXJÖ
Report 08006
ISSN 1650-2647
ISRN VXU/MSI/IV/E/--08006/--SE
Centrum för Informationslogistik
K ra v h an te rin g i
s y s te mu tv e cklin g sp ro je kt
Problem i praktiken
C-uppsats inom informationslogistik
Författare:
Jessika Svensson
Lärare:
Jo Skåmedal
Examinator:
Linda Askenäs
Ljungby:
Januari 2008
J
ag vill härmed rikta ett stort tack till alla respondenter som medverkat i studien,
min företagshandledare Susanna Frennemo samt skolhandledare Jo Skåmedal
för god support.
i
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 systemutvecklingsprojekt.
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 databearbetningsmetod 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 visat sig var en problemfaktor av stor betydelse liksom bristfällig dokumentation, inkompletta roller och otillfredsställande kommunikation. Det framgår också evidenta 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ämligen 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 kravhanteringsprocessen 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!
Jessika Svensson
ii
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 process. 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 produce 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. Requirement engineering in system development project seem to be more complex and detailed in addition to ordinary activity project and there is a obvious need for more consideration 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 expected. Also insufficient documentation, incomplete occupational characters and unsatisfying communication adds up to the source of inconvenient factors disturbing 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 insinuate 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!
Jessika Svensson
iii
Innehåll
1 Inledning ................................................................................... 1
1.1
1.2
1.3
1.4
1.5
Problemställning.................................................................................2
Syfte ...................................................................................................3
Avgränsning .......................................................................................3
Målgrupp ............................................................................................3
Disposition..........................................................................................3
2 Metod val................................................................................... 5
2.1
2.2
2.3
Vetenskapligt förhållningssätt.............................................................5
Metodik...............................................................................................7
Metod .................................................................................................7
2.3.1 Datainsamlingsmetod .................................................................7
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
3.2.1.2
3.2.1.3
3.2.1.4
3.2.1.5
Tillhörafasen.............................................................................................20
Rollsökningsfasen ....................................................................................21
Samhörighetsfasen ..................................................................................21
Vad händer i övergången mellan faserna ................................................22
Gruppens energi.......................................................................................22
3.2.2 Teamets sammansättning.........................................................22
3.2.2.1
3.2.2.2
3.2.2.3
Normer .....................................................................................................23
Samhörighet .............................................................................................23
Roller ........................................................................................................24
3.2.3 Ledaren och teamet ..................................................................24
3.3
Kommunikation.................................................................................25
3.3.1 Ofullständiga och dubbla budskap ............................................27
3.3.2 Motivation..................................................................................28
3.3.3 Kommunikationsfärdigheter i gruppen ......................................28
4 Empiri ...................................................................................... 30
4.1
Empiriska processen ........................................................................30
4.1.1 Respondentgrupp A ..................................................................31
4.1.2 Respondentgrupp B ..................................................................31
4.1.3 Respondentgrupp C..................................................................32
4.2
Block 1: Kravhanteringsprocessen ...................................................33
4.3
Block 2: Teamet ...............................................................................36
4.4
Block 3: Kommunikation...................................................................37
5 Analys ..................................................................................... 40
iv
5.1
5.2
Analysmodell....................................................................................40
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.1
7.2
7.3
Metodkritik........................................................................................55
Förslag till fortsatt forskning .............................................................56
Eftertanke.........................................................................................56
Litteraturförteckning.................................................................... 57
Bilaga 1 Intervjuguide.................................................................. 59
Figurförteckning
Figur 2:1 Grafisk illustration av vald metodik ................................................7
Figur 2:2 Analysmodell ...............................................................................11
Figur 3:1 Flytzonmodellen...........................................................................25
Figur 3:2 Kontextmodellen ..........................................................................27
Figur 5:1 Analysmodell ...............................................................................40
Tabellförteckning
Tabell 3:1 Kravhanteringsproblem ..............................................................17
Tabell 3:2 Det pedagogiska samspelet.......................................................27
Tabell 4:1 Intervjuagenda ...........................................................................33
Tabell 4:2 Kravhanteringsproblem ..............................................................36
v
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 effektivt 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 datorstö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 kravspecifikation 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 konkurrenskraftig 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 procentsatsen 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 prioriteras 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å kravhanteringsprocessen (Eriksson, 2007).
1
I uppsatsen omnämns vid flera tillfällen termen systemutvecklingsprojekt. Benämningen indikerar i sammanhanget på applikationsutveckling.
2
I uppsatsen hänvisar termen ”ett krav” till en önskvärd egenskap eller funktion hos ett IT-system.
1
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 likaså en dokumenterad process med det är trots allt någonting som brister i kvaliteten hos resultatet 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 vattenfallsmodell 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 systemutvecklingsprojekt. 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 begreppsapparaten 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 kommunikationsprocessen. Ä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:
3
•
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 resultatet 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?
Begreppet vattenfallsmodell används för att beskriva ett sekventiellt arbetssätt.
2
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 resultatet 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 slutresultatet.
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 systemutvecklingsprojekt 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 verksamhetsrepresentanter, i första hand aktörer i beställarrollen. De olika IT-aktörer som konsulteras i undersökningen är avgränsade till fallföretagets interna IT-funktion och verksamhetsrepresentanterna 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 kravhanteringsprocessen. 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 prioritet.
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örbereda läsaren på vad som komma skall.
Kapitel 1 – Inledning
En allmän bild av ämnet presenteras och syftet med uppsatsen markeras. Även aktuell avgränsning för forskningen samt potentiell målgrupp beskrivs.
3
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ämpad 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 presenterade 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 analysmodell som används för att analysera de fyra tillsynes vanligaste kravhanteringsproblemen utifrån undersökningens resultat. Därefter introduceras läsaren för en djupare diskussion 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
Det avslutande kapitlet innehåller tre delar, metodkritik, förslag till fortsatt forskning samt
en sista del som speglar min personliga eftertanke.
4
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örstå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 pressar sina tolkningar så att de passar 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åelse 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 alltså helheten i relation till delarna och pendlar mellan del och helhet för att nå en så fullständig 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ärderingar ä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 undersö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örfö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 erfarenhet.
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örståelse med hjälp av erfarenhet. När jag kommer fram till en hypotes som stämmer överrens
4
Själviakttagelse
5
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åelse. ”…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 kravhanteringsprocessen ö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 ämnesområ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 genererar 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äntas. Därav styr mitt intresse för uppgiften också mitt engagemang för att leverera ett väl genomtä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öljaktligen 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. Studierna 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.
I relation till min förförståelse bör det också omnämnas att jag känner några av de respondenter som ingår i undersökningen sedan tidigare samarbetsformer. Detta kan påverka hur
jag tolkar resultatet då jag har en djupare förståelse för deras kompetens och erfarenhet.
Även min personlighet utgör en faktor i hur jag väljer att tolka varav det kan vara intressant
att även kortfattat redogöra för min inställning till uppsatsämnet. Som nämnt har jag ett påtagligt intresse för att kunna bidra med nya kunskaper för att lösa de kravhanteringsproblem som finns. Därav har jag en starkt drivande kraft som påverka mitt arbetssätt. Att tolka kan man göra på flera olika nivåer, allt från att göra en relativ uppfattning som skulle
kunna stämma till att verkligen ta tag i problemet och gå på djupet med vad det kan finnas
för orsaker bakom. Min förförståelse präglas slutligen också utav en snabb tankeprocess
vilket även påverkar mitt sätt att tolka sakförhållandet.
6
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 (datainsamlingsmetod A) och intervjuer (datainsamlingsmetod 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 undersökningen. Varför dessa är relevanta för uppsatsen beskrivs också samt i relation till kritisk 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
Den typ av information som erhålls i litteraturstudien är s.k. sekundärdata. Sekundärdata är
data/information som inte är primärt insamlat/sammanställt för den egna studien utan för
ett annat ändamål. Det är av central betydelse att vara medveten om att all sekundärdata
kan vara vinklad och ofullständig varav det är viktigt att alltid ifrågasätta informationen. En
bra styrka med litteraturstudier är att jag, under kort tidsrymd och med knappa resurser,
kan ta del av mycket information. Studien är ofta en hjälp att kartlägga existerande kunskap
inom området och för att bygga upp en teoretiska referensram (Björklund & Paulsson,
2003).
7
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 intervju ä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 respondenten 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 direktkontakt. Det har varit intervjuer av både ostrukturerad och strukturerad karaktär beroende 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örklund & Paulsson, 2003).
2.3.2
Reliabilitet och validitet
Begreppen validitet och reliabilitet står för forskningens kvalitet. Reliabilitet syftar till avsaknad av slumpmässiga mätfel, d.v.s. pålitlighet. Det handlar alltså om stabilitet och replikerbarhet i genomförd studie. Begreppet validitet står för giltighet, generaliserbarhet av resultatet 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 koncentrera oss på det ena eller det andra. 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 & Davidson, 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 fasta och strukturerade rutiner för datasamlingen är en hjälp för att skapa relativt god reliabilitet.
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
Det är inte tillräckligt att ha reliabel information. Informationen måste också mäta det vi
vill och tror oss mäta. En nödvändig förutsättning för detta är att uppsatsen innehåller valid
information (Holme & Solvang, 1997). Begreppet validitet i en kvalitativ studie gäller enligt
Patel & Davidson (2003) hela forskningsprocessen. Vad gäller själva datasamlingen relate8
ras begreppet validitet till om jag som forskare lyckas skaffa underlag för att göra en trovä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 validitet.
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ållsvaliditeten. 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 validitet är det svårt att övertyga att mätningarna är fullständiga. Eftersom jag dessutom använder mig utav en hermeneutiska ansats försvårar detta ytterligare att påvisa dessa variablers 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 nutiden.(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öreteelsen 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örensen, 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 bearbeta samlad information och data med hjälp av en generell analysmodell. Att använda en analysmodell 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 samtliga 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 kompletterande information från Internet källor.
Referensramen har en bas i följande ämnesområden, kravhantering, teamutveckling och
kommunikationsteori. Det finns ett naturlig bakgrund till valet av dessa teorier då det som
ett resultat av undersökningen visade sig vara de som närmast speglade resonemanget. Teorin kring kravhantering föll naturlig utifrån konceptet som uppsatsen speglar. Både kommunikation och temautveckling går därtill också att härleda till resonemanget som genomsyrar undersökningen. Utifrån empirin har jag valt dessa teorier som skapar uppsatsens re9
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 uppfattar 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 betraktas 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 ITfunktionen 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 relation till erfarenhet från olika systemutvecklingsprojekt som aktörerna medverkat eller
medverkar i. Kravhanteringsprocessen i respektive systemutvecklingsprojekt är erkänd vilket 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 samstämmigt analysunderlag använder jag samma intervjuguide som i föregående etapp . I nivå
tre fullföljs datasamlingen genom kompletterande intervjuer med organisationens övergripande 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 informationen 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 tillfrå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
Den analysmodell som jag har valt att använda är ett välkänt verktyg från skolverket. Den
är enkel och det går att anpassa den efter egna preferenser. I bilden nedan illustreras modellen:
10
Figur 2:2: Analysmodell (Skolverket, 2007).
Analysmodellen kommer att användas för att analysera de mest frekvent omnämnda problemen i underökningen. Modellen skapar struktur och utgör en formalia som passar undersö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 adderas 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 modellen 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 konsekvenser 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 ”manuellt”. 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
Det finns alternativa sätt att arbeta för att relatera teori och empiri, induktion, deduktion eller abduktion som är en kombination av de båda tidigare nämnda. Ett deduktivt arbetssätt
karaktäriseras av att jag utifrån befintliga teorier och principer drar slutsatser om enskilda
företeelser. Ur redan befintlig teori härleds hypoteser som sedan empiriskt prövas i den aktuella studien. En forskare som istället arbetar induktivt studerar primärt forskningsobjektet, utan utgångspunkt i tidigare vedertagen teori och utifrån empirin formuleras en teori.
Risken är att jag inte vet hur generell och vilken omfattning teorin har eftersom den baseras
11
på ett empiriskt underlag. Att jag inte utgår från en teori är inte detsamma som att jag arbetar 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örutsä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 datasamlingen 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 arbetssätt snarare än ett deduktivt. Jag vill dock tillägga det faktum att en induktiv slutledning aldrig kan vara 100 % säker då den bygger på empiriskt material som ej kan beräknas som fullstä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öjligtvis 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 ligger 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 uppfattade x medan person B uppfattande y. Båda har olika berättelser, de använder olika ord och återger olika bilder – men ingen ljuger! Vad det handlar om är att olika 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ändbarhet utifrån Thuréns (1997) sju kriterier för källkritik.
1. Äkthet
De källor som jag har använt uppfattar jag som äkta. Framförallt är det studentlitteratur som jag har nyttjat för att bygga referensramen men även en minoritet av vetenskapliga artiklar har fått sätta sin prägel på teorin i uppsatsen. I och med att dessa artiklar är hämtade ur Växjö Universitets databas ELIN bedömer jag de som
äkta. Det primära källor som respondenterna i undersökningen utgör bedömer jag
även som äkta då de har utsetts i förtroende med min handledare på fallföretaget.
Därtill har jag tillgång till företagets intranät innehållande information om respektive respondent samt personliga kontakter inom företaget varav jag kan intyga deras
trovärdighet som relevanta källor i undersökningen.
12
2. Distans
De primära källornas distans till händelsen är mycket aktuell vilket ökar att sannolikheten att deras påstående är sant och användbara för undersökningen. De sekundä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 resultatet. 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 litteraturfö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 syftet 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 argumentation. Jag anser att vad gäller de primära källorna finns inte en sådan tendens 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
Samtliga källor tolkar jag som sannolika. Problematiken kring kravhanteringsprocessen har under senare år varit ett aktuellt forskningsämne och jag tror ämnet har
funnit tillförlitlighet som vetenskapligt undersökningsfenomen, d.v.s. det finns sannolikhet i den fakta som publiceras. Dessutom har jag valt att forska ur ett vad jag
skulle vilja kalla ”pessimistisk perspektiv”, istället för att beundra de familjära framgångsfaktorerna väljer jag att undersöka vad det är som utgör problem. Jag forskar
med andra glasögon och tror att det är mer uppenbart för mig, att ur detta perspektiv, uppfatta om källor är osannolika då jag ställer mig kritisk i mitt förhållningssätt
till ämnesområdet.
13
Utifrån ovan sju kriterier har jag kommit fram till att källorna jag använt i uppsatsen är av
god substans. Vissa är det svårare att avgöra tillförlitlighet på men ingen källa visar tendens
på att vara obrukbar i förhållandet till syftet med uppsatsen.
14
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 kravhanteringsprocessen 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 ITsystem ä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 mogen kravhanteringsprocess där kraven kontinuerligt kvalitetssäkras är felkällan oftast mindre (Eriksson, 2007).
Brister i kravspecifikationen leder till fel som kostar pengar att åtgärda. Felen blir desto dyrare 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 varje 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å delar 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
För beställaren är det svårt att veta vad verksamheten vill ha ut av ett systemutvecklingsprojekt. Utöver det finns många andra påtagliga problem i kravhanteringsprocessen. I
punktlistan nedan relaterar Eriksson (2007) till ett antal vanliga exempel på frekvent upplevd problematik:
15
•
Det är intressenterna som besitter kunskap om de olika behov systemet ska tillgodose. 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 tolkningssvå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 kravhanteringsfasen. 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 budget, 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 identifiera eventuella problem i kravhanteringsprocessen. Det primära resultatet som framgår i
artikeln skriven av Niazi & Shastry (2003) är att kravhanteringsprocessen är en central felkä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.
Kravhantering anses vara en mycket viktigt del i systemets livscykel. Det har dokumenterats flitigt i olika litterära verk att man kan uppnå bättre systemkvalitet och utvecklings potential om kravhanteringsprocessen är noggrant definierad och exekverad. Trots detta finns
det lite empiriskt material samlat som kan bevisa processen roll i systemutvecklingsprojekt.
Denna teori behandlar relationen mellan en mogen kravhanteringsprocess och reducerade
systemutvecklingsproblem. Forskningen är genomförd på 11 stycken företag i olika storlek
och med varierande kravhanteringsprocesser.
16
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 visar 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 (Eriksson, 2007).
Risken för konflikter minskar avsevärt då krav prioriteras. Det är viktigt att komma ihåg att
det aldrig finns tillräckligt med tid för att uppfylla samtliga krav. Kravspecifikationen fastställer slutligen vad det är beställaren vill ha och ligger till grund för en objektiv bedömning
av om utvecklingen är klar (Eriksson, 2007).
17
Fokus på osäkerhet och komplexitet
Att hantera verksamhetskrav i systemutvecklingsprojekt ställer hårda krav och nya utmaningar 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 utvecklingsmiljö. 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 inaktuellt 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 verksamheten 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 information 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ärsverksamhet?
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 systemutvecklingsprojekt. 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örsummar hela systemet. Komplexitet övervinns följaktligen genom att tillåta att projektet utvecklas 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 annars 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 ut5
Ett business case är ett underlag som innehåller relevant information att fatta beslut utifrån huruvida projektet i fråga ska initieras eller ej.
18
ifrån underlaget varav om projektet ska utföras, skjutas fram eller förkastas. Genom att arbeta iterativ slapp projektteamet att samla in och utveckla alla krav för hela projektet i förhand. Hela kravhanteringsprocessen grundar sig således på att utifrån resultatet från föregående iteration samla nya krav som motsvarar aktuellt behov, för att i slutändan inte riskera att leverera något som inte är aktuellt att implementera. Tillvägagångssättet gjorde att
projektteamet kunde hålla bestämd tidsram och effektivt leverera funktionalitet som stämde ö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 verksamheten. 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 tilldelad 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 mellanliggande 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 effektiv 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 definiera och spåra krav. Ett annat påtagligt problem är att kraven ofta förändras under systemutvecklingen. Icke funktionella krav förbises ofta i processen då de inte anses lika betydelsefulla 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).
Kravhanteringsprocessen i systemutvecklingsprojekt är lång och komplex och har stor betydelse för att kunna leverera en framgångsrik applikation. Kraven måste beskrivas på ett
sätt så att de är lätta att förstå och tillämpa. Likaså bör kraven illustreras i form av prototyper för att ytterligare underlätta förståelsen för kravet. Dålig definierade krav, fel urval och
förändringar i ett krav under processen är typiska felkällor som Pozgaj, Sertic & Boban
(2003) omnämner i sin artikel. Utöver dessa problem är ofta krav i systemutvecklingsprojekt dåligt organiserade och svåra att förstå. För att lösa dessa problem krävs effektiva metoder att följa i arbetsgången. För att på ett bra sätt samla och beskriva krav rekommenderas att alla gruppmedlemmar i projektteamet bör ha ansvar för uppgifter som är nära kopplade till deras kompetens. På så vis är varje medlem ansvarig för att samla och beskriva de
krav som ligger inom deras kompetensområde och då skapas struktur i arbetssättet. För att
effektiv kunna organisera och strukturera de krav som samlats är det centralt med analysmetoder för att avgöra vilka krav som utgör en stor risk och har förmåga att förändras. I
och med att kraven är tilldelade projektteamets olika medlemmar utifrån deras kompetensområde sker en naturlig och kontinuerlig övervakning. För att slutligen också kunna hantera de krav som är föränderliga är det centralt att identifiera konsekvenserna utav att ett krav
förändras för att kunna avgöra och ta ställning till huruvida det nya kravet ska förkastas eller implementeras. Att ett krav förändras kan få betydelse för andra krav och följaktligen
innebära konsekvenser för hela systemet som utvecklas.
19
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 kontext 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 organisationen….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 kompetens 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örstå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 skicklighet och utbildning är den samma. I sin forskning fann han att en grupp genomgår tre huvudfaser 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 omnä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
Den första fasen rör medlemskapet i gruppen. Under denna fas är relationerna ofta ytliga,
attityderna vaksamma och formella och de flesta känner sig reserverade. Nivån av det känslomässiga engagemanget är låg, både mot andra och uppgiften. Känslan av ömsesidigt stöd
6
FIRO står för Fundamental Interpersonal Relationsship Orientation
20
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 tillhö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 gruppen vidare i processen. För att nå nästa fas i FIRO-cirkeln krävs det att man river de mellanmä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 maktfö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 eller undvika rollen. Det finns ett stort behov av struktur och ledarskap men det finns samtidigt 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 underliggande 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 olika 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 olikheter. Alla roller och förväntningar måste vara glasklara för vederbörande part så att slutligen 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 aldrig denna fas. För att nå den öppenhet som utmärker samhö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 medlemmarna utvecklas och atmosfären präglas av samarbete och ömsesidig support. ”Energi frigörs. Tidigare 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 diskussionerna om principer och värderingar har blivit onödiga nu när gruppens medlemmar vet hur
de andra tänker och känner.
För att förbli i samhörighet är det centralt att gruppen uppfattar konflikter som gemensamma problem. Alla måste också känna trygghet och veta att de är uppskattade i gruppen.
21
Gruppens medlemmar får heller inte känna hot eller avundsjuka mot parbildning och subgrupper. Alla medlemmar ska istället stödja varandra aktivt, kunna handskas med relationsproblem 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örstå hur en grupp reagerar vid själva upplösningen. Själva upplösningen av teamet sker nämligen inte utan vånda. Det är både en intressant uppgift och själva gemenskapen som lämnas 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 karaktä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å mellan 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 gruppdeltagarna. 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
Det gäller att välja personer med rätt spetskompetens med tanke på målet men teamet behöver också individer som kan samarbeta. Den individuella spetskompetensen måste alltså
kunna utnyttjas i samspel med de andra i laget för att lyckas. Detta är grundidén med att
arbeta i ett team. Förutsättningen för att få den kompetens som efterfrågas i teamet är att
man tydligt kan beskriva de behov som måste tillgodoses. Det måste finnas tydliga riktlinjer
för vilka uppgifter det är som ska lösas, vilka roller som måste fyllas och vilka kunskaper
och erfarenheter detta kräver. De personer som rekryteras till teamet bör även känna moti-
22
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änniskor” 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 mogna/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älvstä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 naturligt 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 relationen 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å finnas 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. Informella 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 konstruktivt meningsutbyte för att kunna producera bättre och mer välgrundande beslut genom 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
Det är centralt att det finns en vi anda i teamet för att stärka samhörigheten. I den mindre
gruppen är det inte så enkelt som att bara skapa normer att samleva efter utan det kräva att
alla anstränger sig och tar sitt ansvar för att öka den vardagliga trivseln. Enligt Maltén
(1998) måste gruppens medlemmar kunna skratta ihop liksom de ska kunna för ett sakligt
23
resonemang. Det bör stå klart för gruppens medlemmar att de är beroende av varandra parallellt som de kompletterar varandra, med andra ord ska de uppfatta sig som en grupp, ett
team.
Det är viktigt att snabbt få gruppmedlemmarna att känna sig som en helhet och engagera
dem i problemlösning och beslutsfattande. För att teamet ska fungera tillfredställande måste gruppens medlemmar kunna prata med varandra, lära känna varandra, dela kunskaper
och erfarenhet, diskutera mål och tillvägagångssätt, d.v.s. samspela i gruppen.
3.2.2.3
Roller
Tillskillnad från normer som är generella och ska gälla alla är roller specifika, funktionsinriktade och gäller bara de/den som innehar den bestämda rollen. En roll kan tilldelas eller
så växer man in i den utifrån intresse eller tillfälligheter. Olika roller och ansvarsområden
måste betraktas utifrån hela teamet och dess behov. Det är mycket viktigt att ta reda på om
nödvändiga rollfunktioner tillfredställs annars måste något göras åt detta omgående då
teamet har vissa förväntningar. Roller kan vara av både formell och informell karaktär, i
båda fallen har gruppens medlemmar förväntningar på varandra och på rollen. Problem,
missförstånd, konflikter och stress beror ofta på rollproblem. Rollförtydliganden är därför
många gånger viktigt i temabyggande och utveckling. När rollerna är tydligt definierade blir
gruppen mekaniskt mer funktionsduglig. Då vet alla var de har varandra, vad som förväntas
och vem som gör vad.
3.2.3
Ledaren och teamet
Ledaren är en nyckelperson i ett väl fungerande team. Ett team kommer att uppleva stora
svårigheter att nå uppsatt mål om ledaren saknar ledarkompetens. En bra ledare bör vara
väl insatt i gruppdynamiken samt ha tillräckligt med yrkesmässig insikt för att förstå vad det
är som ska göras och därtill kunna kommunicera tillfredställande både inom teamet och
utåt. Enligt Larsen (2003) finns det tre mänskliga kvaliteter som man bör lägga vikt vid valet av ledare:
•
Mod: Vilja att ta i, kunna fatta beslut samt att verkställa dem
•
Emotionell mognad: Vilja att klara av och utforska obehagliga situationer för att kunna göra något åt sakläget och nå ett resultat
•
Personliga värderingar: En moralisk och personlig integritet är väsentligt för att inte
låta sig pressas, vackla eller utnyttja situationer till egen fördel
Det är viktigt att ledaren låter teamets medlemmar få inflytande på beslut som ska fattas.
Om gruppens medlemmar känner att de inte tas på allvar och att ledaren negligerar deras
åsikter kan detta påverka gruppen i negativ bemärkelse. Gruppmedlemmarna ska känna sig
värdefulla och att deras synpunkter beaktas, då går de också in för arbetet med större entusiasm. En bra ledare har följaktligen en tydlig vision om vad teamet kan klara av och kan
förmedla detta till gruppen på ett sådant sätt att de kan ta sig fram till målet. ”En bra ledare
utövar inflytande på teamet mer genom at fungera som en modell och ett exempel på en person som klara av
att själv ta ansvar, hitta riktningar och lösningar samt genomföra dessa, än en som måste dirigera och styra
andra. En bra ledare är en som skapar samarbete och samspel, en som stimulerar teamet att prestera mer
och bättre än de annars skulle göra. En bra ledare är en som tar hänsyn till gruppen och skapar förutsättningar istället för att gå bakom med piska och käpp för att driva motvilliga ”djur” framför sig” (Larsen,
2003, s. 49).
24
Teamets ledare måste även bli accepterad av gruppens medlemmar. Det är alltså centralt
för ledaren att arbeta upp en makt baserad på kompetens och goda vilja för att slippa stödja
sig på formell makt.
Flytzonmodellen
Ledaren bör göra allt för att hålla teamet i s.k. flytzonen, d.v.s. inom det område där utmaningar/krav och kunskaper/färdigheter är i balans. I denna zon kan teamet såväl som den
enskilda individen arbeta effektiv. Hamnar teamet utanför denna zon p.g.a. att utmaningarna blir större än färdigheterna kan oror utvecklas i gruppen, något som påverkas teamets
prestationer negativt. Det samma gäller då utmaningarna bli för små i förhållande till de
färdigheter som finns. Frustration uppstår oftast då teamet inte får utnyttja sin kapacitet
och förmåga (Larsen, 2003). I bilden illustreras flytzonen ur ett grafisk perspektiv.
Figur 3:1: Flytzonmodellen (Larsen, 2003).
3.3
Kommunikation
”Jag vet att du tror att du förstår vad du tror att jag sa, men jag är inte säker på att du har fattat att det
du hörde inte var det jag menade.” (Anonym källa, hämtad ur Maltén, 1998, s. 11).
Kommunikationsaktiviteter brukar delas upp i olika kategorier och vi ska i denna teoretiska
del framförallt titta närmare på den interpersonella kommunikationen, d.v.s. kommunikation mellan människor samt gruppkommunikation.
Vi kommunicerar för att tillfredställa olika behov och syften. I punktlistan nedan följer några av de vanligaste skälen till att vi kommunicerar enligt Dimbley & Burton (1999):
•
Samarbete. Vi kommunicerar för att samarbeta med andra. Det är i samarbetet mellan
människor som kommunikationsprocessen har sitt största behov och syfte. Vi använder kommunikation för att komma överens med andra och för att samarbeta med dem.
•
Personliga behov. Vi kommunicerar också för att tillgodose personliga behov. Kommunikation hjälper till att tillfredställa ett trygghetsbehov och det påvisar att kommunikation
inte bara handlar om fysiska ting utan även känslor, idéer och åsikter.
•
Relationer. Vi kommunicerar för att skapa relationer med andra människor.
25
•
Övertalning. Vi kommunicerar följaktligen också för att övertala människor att tycka eller
att handla som vi. Ordet övertalning har en avtryckning av manipulation, ”att få som
jag vill”. I den här betydelsen är vi alla manipulatörer, varje dag.
•
Makt. Vi kommunicerar även för att utöva makt över andra människor. Det antyder på
att kommunikatören tänker försätta motparten i en undergiven position.
•
Sociala behov. Vi kommunicerar för att hålla samman vårt samhälle och våra organisationer. Desto större organsituation desto mer kommunikation krävs. Det handlar om att
få hela systemet att arbeta för oss och vi är beroende av effektiva kommunikationsmedel för att det ska kunna fungera.
•
Information. Vi kommunicerar för att ge och ta emot information.
”Kommunikation handlar helt och hållet om att ge och ta emot tecken som har betydelser knutna till sig”
(Dimbley & Burton, 1999, s. 35). I samspelet mellan människor spel kommunikation en avgörande roll. I kommunikationsprocessen överför vi budskap samt mottager information från
andra. Då vi kommunicerar kan vi påverka andras tankar, åsikter, värderingar, attityder och
avsikter. Det finns dock en mängd felkällor i kommunikationsprocessen vilket antyder på
att verkligheten inte alls ser ut som vi förväntar oss. Ofta tror vi oss veta vad andra ser,
upplever, tänker och känner, likaså tror vi oss förstå innebörden av budskapet. Vi tror också att det vi själva förmedlar i form av ord ska räcka för att budskapet skall nå fram och
förstås av mottagaren men i många fall når budskapet helt enkelt inte fram så som sändaren
tänkt sig. Ofta bygger misslyckad kommunikation på missuppfattning eller feltolkning
(Maltén, 1998).
Feedback är en nyckelfunktion och förutsättning för tvåvägskommunikation. Vid all kommunikation finns det anledning att göra återkoppling, s.k. feedback för att kontrollera om budskapet uppfattats på rätt sätt (Maltén, 1998, s. 15). För att kommunicera väl krävs det också att parterna
kan pejla in varandra, d.v.s. använda samma kommunikationskanal, annars hamnar kommunikationsprocessen lätt på avvägar. Kommunikationsformerna bör således vara kongruenta, d.v.s. ord , kroppsspråk och känslobudskap måste överrensstämma.
Feedback kan förekomma både verbalt och icke-verbalt. De icke verbala signalerna sänds
ofta omedvetet. De signaler som sänds i en kommunikationsprocess säger således mycket
om kontraherarens kunskaper och erfarenheter men också attityder och värderingar. En
god kommunikatör är observant och medkännande (Maltén, 1998).
S.k. kontextmodellen erbjuder ett omfångsrikt sätt att beskriva kommunikationsprocessen
på. Budskapets pendling mellan sändare och mottagare samt kodning, avkodning, val av
kanal och feedback är beroende av den situation i vilket kommunikationen sker, d.v.s. kontexten. All kommunikation sker i ett sammanhang, en kontext. Man talar om tre typer av
kontexter, fysiska kontexten, social/emotionella kontexten och kulturella kontexten. Den
fysiska kontexten avser tid, plats och yttre omständigheter. Den social/emotionella avser
istället klimatatmosfär, makt- och status förhållande, rollfördelning, t.ex. ett möte med chefen eller ett sammanträde med kolleger. Den kulturella kontexten däremot avser livsfrågor,
nationella och internationella särdrag och värderingar (Maltén, 1998/Dimberly & Burton,
1999). Kontextmodellen illustreras nedan. Intentionen är att skapa en metafor som klargör
komplexiteten i kommunikationsprocessen.
26
Figur 3:2: Kontextmodellen (Maltén, 1998).
För att ytterligare öka kunskaperna kring vad det är som påverkar kommunikationsprocessen är det viktigt att också förstå hur det pedagogiska samspelet bör ske på många olika
plan. Det gynnar kommunikationsprocessen att få kontakt intellektuellt, psykiskt och fysiskt under samtalets gång. I tabellen nedan beskriver Maltén (1998) olika nivåer i den pedagogiska samtalsprocessen:
Verbalt
Med fraser
För allmänkontakt
Kognitivt
Med hjärnan
Ett djupare, mer principiellt
plan, t.ex. begrepp, principer
och kunskapssyn
Extra-verbalt
Med rösten
Röstens styrka och tonläge
för att marker engagemang,
ilska o.s.v.
Icke-verbalt
Med kroppsspråket
Gester, mimik, kroppshållning
Emotionellt
Med känslor
Ge och ta känslor
Ett ”jag/du” samspel
Tabell 3:2: Det pedagogiska samspelet (Maltén, 1998).
3.3.1
Ofullständiga och dubbla budskap
Typen av ofullständiga och dubbla budskap sätter i många fall käppar i samtalsmaskineriet.
Vi sänder ofta ofullständiga budskap där vi utelämnar viktiga delar av budskapet och avrundar med t.ex. ”ja, du vet”. Om mottagaren inte begär ett förtydligande så kan missförstånd kring vad som verkligen förmedlades byggas upp.
Budskapet blir ofta oklart då vi använder oss av ord som ”nog” eller ”förmodligen”. Vi gör
oss skyldiga till generalisering eftersom vi brukar ord som ”alltid/aldrig” och ”jämt”. Det
27
gäller även i dessa fallet att klargöra vad det är som egentligen menas, d.v.s. ställa sig kritiska till de budskap som förmedlas för att undvika onödiga missförstånd.
Vi människor är också mycket bra på att använda dubbla budskap. Ett tydligt exempel på
detta är hur vi ibland säger något argt och vresigt och därtill drämmer till med en motreplik
då vi konfronteras som ljuder; ”jag är inte arg” och gör dessutom detta med hög röst och
distinkt uttal (Maltén, 1998).
Du-budskap kontra jag-budskap
Ett du-budskap har ofta negativ effekt för den som utsätts för det, t.ex. ”Du får inte göra
så…; Det är bäst du gör det, annars…”. Budskapet fördömer, anklagar och etiketterar och
följden blir att motparten lätt går i försvar och därav försvåras en förändring av vederbörandes beteende. Ett jag-budskap erbjuder istället rak återkoppling. Motparten får istället
veta vilka effekter dess beteende får för andras. Därtill är det upp till vederbörande att själv
drar slutsatsen om sitt framtida agerande. Ett jag-budskap talar istället om hur vi upplever
det som hänt (händer); hur vi uppfattar vad den andre gjort, sagt eller helt enkelt inte valt
att göra; det beskriver den effekt som motpartens beteende får för oss och andra; det frågar
också vad den andre har menat med sitt handlande; det angriper inte utan ser till helheten i
situationen.
Ett jag-budskap består av tre delar:
1. Först beskriver vi beteendet som vi vill lyfta med motparten
2. Därefter talar vi om vilken effekt/konsekvens motpartens handling fått
3. Tillsist beskriver vi också de känslor som handlingen har väckt hos oss
Ett jag-budskap skadar inte motpartens självkänsla och kallas därav för ett ansvarsbudskap,
i och med att det bollar över ansvaret till den andre. ”En sorts ”pingpong” diplomati” (Maltén,
1998, s. 55).
3.3.2
Motivation
Hur ska man få alla berörda att ställa sig bakom målet? Genom att motivera såklart! Som
ledare finns ett stort ansvara att motivera sina medarbetare. Det handlar om att välja rätt
personer i teamet, d.v.s. dem som motiveras av den specifika uppgiften. Det handlar också
om att göra själva arbetet och teamets situation intressant och motiverande. Ingenting är så
motiverande som att lyckas med något. Själförtroendet ökar saftigt och man ser positivt på
både sig själv och teamets möjligheter. Det är på så vis enklare att sätta upp nya mål. Hög
motivation leder i många fall till en högre energinivå medan nederlag fungerar och ger motsatt effekt. ”Vi tar gärna åt oss äran för framgång men söker orsaken till nederlag hos
andra. Resultatet kan lätt bli en jakt på vem som är syndabock (Larsen, 2003).
Något som är relevant att titta närmare på är förhållandet mellan insats och utbyte.
Gruppmedlemmarna behöver då och då lite beröm och uppmuntran. En säker väg till
missbelåtenhet och sjunkande motivation är att köra över gruppen och diktatoriskt försöka
pressa prestationerna genom att sätta högre krav och ge sämre ackord (Larsen, 2003).
3.3.3
Kommunikationsfärdigheter i gruppen
Ofta beror svårigheter som teamet hamnar i på problem knutna till kommunikationen mellan gruppmedlemmarna (Larsen, 2003). Den som inte kommunicerar återför heller inget till
gruppen. Ofta handlar det om interpersonell förmåga, att kunna använda verbal samt icke-
28
verbal kommunikation. Exempelvis kännetecknas en god parrelation av att man erkänner
varandras värde och betydelse, samma sak gäller för teamet och dess medlemmar. Att ge
och ta emot beröm ökar den angenäma känslan av att vara medlem i teamet. Det är en betydelsefull kommunikationsfärdighet att kunna belöna.
Precis som med beröm kan en lagom nivå av skämtsamhet skapa harmoni inom gruppen.
Ytterligare en kommunikationsfärdighet är att kunna få gruppens medlemmar att slappna
av utan att distrahera dem. Ett beteende som fungera väl både på det personliga planet och
vid utförandet av praktiska uppgifter är att visa samtycke. Om en grupp ska fungera effektivt måste det hur som helst finnas en god portion enighet. Samtycke hjälper gruppen att
arbeta tillsammans (Dimberly & Burton, 1999).
I gruppen ska medlemmarna tillsammans planera, lösa problem och fatta beslut. För att
detta ska fungera måste gruppens medlemmarna komma med förslag eller lämna information varav förmåga att kunna bedöma och utvärdera förslag, egna som andras, också är en
nödvändig kommunikationsfärdighet. En bra gruppmedlem kan också icke-verbalt uppmuntra andra till engagemang och samtidigt få människor att känna sig uppskattade. Det är
också en färdighet att kunna föreslå ageranden som engagera gruppen likväl som att mana
fram åsikter. Det som Dimberly & Burton (1999) betonar är alltså vikten av kommunikationsfärdigheter för att generera gruppengagemang.
29
4
Empiri
”I följande kapitel redovisas den empiriska studie som genomförts för att samla basfakta från omgivningen.
Samtliga respondenter presenteras och deras input till uppsatsen redogörs för i ett logiskt sammanhang, utifrån gemensam struktur”.
4.1
Empiriska processen
Den empiriska processen utbredde sig från 10 oktober fram till 13 november 2007. Under
detta tidsperspektiv samlades fakta från relevanta respondenter på fallföretaget. Informationssamlingen har samband i konkreta referensramar i form av olika systemutvecklingsprojekt som presenteras nedan. Vederbörligt projekt introduceras enbart övergripligt då det
är helheten som är intressant för sammanhanget i undersökningen. Introduktionen till respektive projekt är skapad med intention att öka förståelsen till varför respektive respondent argumenterar som den gör i olika situationer.
Projekt Lime
Lime är ett pågående systemutvecklingsprojekt inom fallföretaget med komplext uttryck
och omfång. Projektet startade som en biuppgift till Compass som är företagets interna
webbportal. Flera olika system är berörda av förändringen och flera olika kravspecifikationer finns att tillgå för just detta specifika projekt. Projektets omfattnings har successivt
stegrat då det inte funnits några tydliga direktiv och avgränsningar. Idag har projektet varit
aktivt i ca 2 ½ år och målet med Lime är att skapa en primär informationskälla av produktinformation där all data ska hämtas från för att på så vis undvika redundant och inkonsistent information. Projektet initierades inte heller likt andra systemutvecklingsprojekt där
behovet oftast kommer från en beställare. I det här fallet utföll Lime som ett resultat av det
behov som framkom i pågående projekt Orange, d.v.s. projektet för driftsättningen av
Compass.
I och med att det inte fanns en klar beställare när projektet initierades samlades således inte
heller kraven i bemärkelse av denna roll. Likaså fanns ingen etablerad referensgrupp att
hämta stöd ifrån och samarbeta med för att samla rätt typ av krav. Att fel personer har varit
involverade i projektets kravhantering har fått konsekvenser under hela projektet gång, bekräftar Carina Holgersson, teknisk projektledare för Lime.
Till en början såg man Lime som ett relativt litet projekt men kan idag emellertid konstatera
allt att blivit väldigt stort då man misstolkat komplexiteten i uppdraget och beroendeförhållanden till andra faktorer med betydelse för ett fullständigt resultat.
Projekt Risk & Accident
Till skillnad från Lime är projekt Risk & Accident betydligt mer strukturerat och ett bra exempel på ett framgångsrikt, relativt problemfritt systemutvecklingsprojekt. Syftet med projektet är att skapa version III i en befintlig heltäckande applikation för tillbuds och olycksfallshantering. Arbetet kräver således förändring inom befintliga moduler samt nyskapande
vilket har resulterat i mer än en kravspecifikation. Bakgrunden till att Risk & Accident initierades var att rapportering av tillbud och olyckfall påvisats komplext och det finns misstankar om att rapporteringen försummas på grund av verktygets komplexitet.
Att samla och dokumentera kraven har inte uppfattats som ett problem då det är en relativt
mogen applikation som ska utvecklas. Generell problematik i projektet var istället att referensgruppen visade sig vara ofullständig i det avseende att nya krav tillkom i ett mycket sent
skede av applikationens utveckling. ”Tyvärr förstår man inte alltid referensgruppens betydelse förrän i
efterhand med facit i hand. Vi ville ha en smal input men konsekvensen blev möjligen att processen styrdes
30
för hårt. Detta är ställningstagande som måste fattas under projektet och som man i efterhand istället får
reflektera över och lära sig utav”, berättar Michael Bengtsson, beställare i Risk & Accident.
Hillevi Fransson, teknisk projektledare, bekräftar att projektet löper smidigt idag.
Projekt WIIL, Webb Input Interface Lime
WIIL är ett förprojekt till Lime och Limes projektgrupp stod som beställare. Projektet var
enligt Kim Lindborg mycket nyttigt då man insåg att dokumentationen för kravhantering i
hög grad är omfattande och tidskrävande gentemot den nytta som genereras.
4.1.1
Respondentgrupp A
Respondentgrupp A innehåller IT-aktörer i rollen tekniks projektledare varav deras primära
ansvar är som teknisk kravställare. Denna grupp av respondenter hör hemma i fallföretagets IT organisation varav de karaktäriseras som relevanta IT-aktörer för undersökningen.
Varje respondent i gruppen intervjuades två gånger. Första intervjun genomfördes i form
av en diskussionspunkt där frågeställningen var mycket öppen och respondenten kunde
ostört reflekterade över kravhantering i systemutvecklingsprojekt. Andra intervjun genomfördes utifrån en strukturerad intervjuguide uppbyggd kring tre block, kravhantering, teamet och kommunikation.
Nedan följer en grundligare beskrivning av varje enskild respondent tillhörande gruppen.
Respondent A1, Hillevi Fransson
Hillevi är strategiskt och operativt ansvarig för projekt rörande fallföretagets externa webbsiter. Hon är tekniska projektledare inom Online Marketing området samt för dotnetbaserade webbprojekt. Respektive intervju utförde Hillevi med projekt Risk & Accident
som referensram i vilket hon innehar rollen teknisk projektledare.
Respondent A2, Carina Holgersson
Carina är strategiskt och operativt ansvarig för samarbete- och informationsplattformar
inom fallföretaget och leder följaktligen projekt inom detta område. I båda intervjuerna
fördes diskussionen i relation till projekt Lime där Carina har rollen tekniks projektledare.
Respondent A3, Kim Lindborg
Kim är utbildad civilingenjör med inriktning mot Technology Management. På fallföretaget
arbetar han med fysisk implementering av applikationer, tester och systemutvecklingsprojekt. Kim använde projekt WIIL som referensram vid samtliga två intervjutillfällen.
4.1.2
Respondentgrupp B
I grupp B inkluderas två respondenter ur verksamheten med projektrollen beställare. Denna grupp karaktäriseras av ett övergripande ansvar för att samla verksamhetskrav gentemot
de förväntningar som finns på resultatet.
I studien skildras en väsentlig skillnad i beställarrollen varav respondenterna svara utifrån
en aktiv respektive passiv beställarroll.
Den enskilda respondenten intervjuades en gång utifrån samma strukturerad intervjuguide
som respondenterna i grupp A.
31
Respondent B1, Michael Bengtsson
Michael arbetar på fallföretaget i chefsposition med riskhantering. I intervjun svarade han
på frågorna i intervjuguiden med utgångspunkt i projekt Risk & Accident. Hans roll är beställare men även aktiv projektledare representerande verksamheten.
Respondent B2, Per-Erik Velin
Per-Erik är Business Manager för affärsverksamheten Special Polyoler inom fallföretaget
och har god erfarenhet av att driva projekt i rollen som beställare.
4.1.3
Respondentgrupp C
Respondenterna i grupp C utgör ett komplement i undersökningen då respektive roll har
en intressant prägling för forskningsresultatet ur ett heltäckande perspektiv.
Intervjun genomfördes en gång med respektive respondent och för att bibehålla god reliabilitet i undersökningen var basen för diskussionen återigen samma intervjuguide som användes i övriga undersökningar.
Respondent C1, Annelie Linhed
Annelie är i grund och botten examinerad kemiingenjör och jobbar på fallföretaget som
produktsäkerhets chef. I projekt Lime hade Annelie rollen som projektledare fram till att
hon blev så hårt belastad att detta ledde till en längre sjukskrivning. Det är utifrån detta
perspektiv som Annelie genomförde och diskuterade de frågor som ställdes i undersökningen. Intervjun med Annelie är ett komplement i undersökningen med syfte att höja validiteten på resultatet ytterligare p.g.a. den komplexitet och strukturella skillnad projekt Lime
förekommer andra likvärdiga systemutvecklingsprojekt.
Respondent C2, Susanna Frennemo
Susanna är IT-chef på fallföretaget och van medlem i olika styrgrupper för systemutvecklingsprojekt. I och med hennes nära relation till IT organisationen gör att hon har god förståelse för den detaljnivå och komplexitet som förekommer i kravhanteringsprocessen.
Tabellen nedan sammanfattar samtliga intervjuer genomförda.
32
Respondent
Projektroll
Datum
Längd
Intervju typ
A1
Teknisk
2007-10-10
1h
Ostrukturerad
Hillevi Fransson
projektledare
2007-10-26
1h
Strukturerad
2007-10-11
1h
Ostrukturerad
2007-10-22
1h
Strukturerad
2007-10-10
1h
Ostrukturerad
2007-11-01
1h
Strukturerad
Beställare
/projektledare
2007-11-01
1h
Strukturerad
Beställare
2007-11-12
1h
Strukturerad
Projektledare
2007-10-29
1h
Strukturerad
C2
Styrgrupps
2007-11-13
1h
Strukturerad
Susanna Frennemo
medlem
A2
Teknisk
Carina Holgersson
projektledare
A3
Teknisk
Kim Lindborg
projektledare
B1
Michael Bengtsson
B2
Per-Erik Velin
C1
Annelie Linhed
Tabell 4:1: Intervjuagenda (Källa, egen).
Härnäst kommer resultatet att presenteras utifrån samma formalia som intervjuguiden är
strukturerad på. Varje block presenteras och därefter följer åtskilliga uttalanden och konklusioner från samtliga respondentgruppen medverkande i undersökningen.
4.2
Block 1: Kravhanteringsprocessen
Systemutveckling sker idag under stor press och kräver ett resultat som levereras i
rätt tid, med rätt kravlitet och inom budget. För att möta dess krav krävs en effektiv
kravhanteringsprocess.
- Först och främst bad jag vederbörande respondent att berätta ifall de upplever någon generell problematik i kravhanteringsprocessen samt hur det påverkar arbetet. Alla ombads
att relatera till konkreta faktorer samtidigt som det var önskvärt för resultatet om de kunde
motivera orsak och samband. För att ytterligare belysa problematiken bad jag dessutom alla
respondenterna att reflektera över hur förhållandet mellan IT-aktör och verksamhet påverkar situationen.
33
- ”De flesta av oss människor har god möjlighet att visualisera de förväntningar vi har på resultatet men få av oss är så pass strukturerade och orkar arbeta på den detaljnivå som krävs i systemutvecklingsprojekt. Kravhanteringsprocessen i systemutvecklingsprojekt är jobbig och krävande då det krävs val på detaljnivå för att nå det resultat som förväntas”.
Så här inledde Susanna Frennemo, IT-chef på fallföretaget sin intervju vilket sannerligen
reflekterar det generellt utpekade problemkomplexet som idag karaktäriserar de flesta kravhanteringsprocesser i moderna systemutvecklingsprojekt.
I undersökningsstudien framgick mycket fakta av betydelse för hur kravhantering upplevs i
systemutvecklingsprojekt. Varje respondent anförde sina sypunkter och reflekterade väl
över upplevd problematik. Den absolut största felkällan identifierad av samtliga respondenter i undersökningen var tiden. Tiden är en kritisk framgångsfaktor med stor betydelse för
resultatet i kravhanteringsprocessen och det är ett påtagligt problem att balansera kravhantering mot tilldelad tidsram.
- ”Det läggs för lite tid i själva startgropen. Att tillsammans i projektgruppen planera grundligt
för vad det är som ska göras är A & O för ett lyckat resultat. För lite tid är alltså den största
felfaktorn till att ett kravarbete misslyckas och för att undvika denna negativa faktor bör mer
tid appliceras då projektet initieras” (Per-Erik Velin, respondent B2).
- ”Tiden är en kritisk faktor i utvecklingen av kravspecifikationen men det är centralt att påvisa hur en väl formulerad kravspecifikation leder till kortare ledtid för själva utvecklingsfasen
Att skapa förståelse för vad som är viktigt för kravarbetets framgång är således centralt för att
lyckas övertyga var tid bör prioriteras i processen. Det är en skyldighet att förklara detta på ett
tydligt vis för beställaren. Anser man att tiden inte räcker till för att genomföra ett gediget
kravarbete är risken mycket stor att man förbiser någon viktig aspekt” (Hillevi Fransson, respondent A1).
- ”Människan är av naturen lat och detta påverkar absolut kravhanteringsprocessens framfart
och resultat. Ofta behöver många olika delar av arbetet prioriteras mer tid än vad som egentligen avsätts. Tiden är alltså en grundläggande orsak för hur kravhanteringsarbetet bedrivs och
prioriteras” (Carina Holgersson, respondent A2).
Flera av respondenterna påpekade dessutom problematiken av en för hög respektive för låg
detaljeringsgrad i kravspecifikationen, även dokumentets tekniska framställning samt omfånget på handlingen som skapar svårigheter, framförallt för den icke tekniska parten. Det
framgick att olika kunskaper och erfarenheter grundar för misstolkningar av dokumentet,
även inom den homogena gruppen.
- ”Ur en tekniska aspekt är det sällan möjligt att genomföra kraven enligt beställarens förväntningar eftersom de sällan har den kompetens som krävs för att förstå den ”tekniska verkligheten” (Carina Holgersson, respondent A2).
- ”Första gången jag såg dokumentet var det som en stor tröskel att kliva över, man måste ställa om sig helt och verkligen försöka tyda vad det är som står dolt i programmeringsspråket”
(Annelie Linhed, respondent C1).
- En orsak till misslyckad kravhantering är att specifikationen utformas utan tanke på vem
det är som ska tolka innehållet. Dokumentet är ofta komplext och därmed svårt att hantera.
Likaså förlitar vi oss i många fall på tallang då metodiken brister.” (Kim Lindborg, respondent A3).
Istället för att bara diskutera påtagliga problemfaktorer identifierades även motsatsen, d.v.s.
framgångsfaktorer; en tydlig och aktiv beställare; rätt personer i projektgruppen; rätt kompetens; aktiv styrgrupp med mandat att fatta beslut; tydliga avgränsningar;
34
- ”Ett klassiskt problem är att kravspecifikationen eskalerar, man säger ofta: - Ska vi inte
bara göra det också…”. (Per-Erik Velin, respondent B1).
Andra framgångsfaktorer markerade av respondenterna var behovet av tydlig kommunikation; engagemang för uppgiften; kritiskt granskning av process och resultat, d.v.s. våga ifrågasätta;
- ”Att ingen vågar ta kritisk ställning till beslut p.g.a. att vederbörande anser sig sakna erfarenhet till den typ av ståndstagande är ännu en brist i kravhanteringsprocessen. Det är alltid
svårt att ge konstruktiv kritik till en ny ide. Beställaren känner också ofta stor tillit till ITaktören i samarbetet och ifrågasätter sällan kraven som dokumenteras vilket är en stor riskfaktor för resultatet” (Kim Lindborg, respondent A3).
Resultatet från block ett tyder på att det är otroligt viktigt att samarbetet i projektgruppen
fungerar väl under framställningen av en kravspecifikation. Att kraven stämmer överrens
med kundens förväntningar urskiljs i undersökningen som ett grundläggande argument för
att processen ska fortlöpa och resultera enligt förväntan. Det bekräftas av flera respondenter vikten av att frekvent träffa beställaren för att diskutera och stämma av krav.
- ”Då en bild säger mer än tusen ord använder jag mycket konkreta illustrationer, skärmdumprar o.s.v. för att precisera resultatet för beställaren. Ofta känns kravhanteringen komplext
och krångligt men man måste vara tuff och våga lägga tiden som krävs för ett bra resultat. Systemutvecklingsprojekt ställer höga krav på beställaren och det är ibland svårt att intyga beställaren varför en komplett kravspecifikation är ett så viktig dokument”(Hillevi Fransson, respondent A1).
- ”Det är synnerligen bra att ha en väl strukturerad process som genererar systematik i förfaringssättet. Framförallt är beställaren ovan och saknar erfarenhet och kompetens för vad som
verkligen krävs i ett äkta systemutvecklingsprojekt. Detaljnivån är sällan aktuell i ett ordinarie
beställningsförfarande och kan lätt skapa frustration mellan beställare och IT-aktören, levererande parten, då förståelsen för processen skiljer sig åt för dessa parter”. (Susanna Frennemo,
respondent C2).
- ”Då det gäller att skapa ett hälsosamt förhållande mellan IT-aktören och verksamhet är det
centralt att istället för att traditionellt informera aktuellt sakläge börja förhandla. Det borde
vara en öppen förhandling där båda parter känner sig nöjda med resultatet. Båda parter ska
alltså kunna ta hjälp av varandras expertis i en tydlig och väl fungerande tvåvägskommunikation”. (Kim Lindborg, respondent A3).
Ett annat intressant problem som uppdagades i undersökningen var huruvida man avgör
vem som är berättigad kravställare.
- ”Då krav ska samlad är det svårt att veta vilka källor som är den rätta inputen. Det går
helt enkelt inte att involvera alla, det måste bli ett urval. Att hitta rätt urval med rätt erfarenhet är inte alltid det enklaste” (Michael Bengtsson, respondent B2).
- ”Att fel personer är involverade i kravställningen kan få bestående konsekvenser för hela projektet”. (Carina Holgersson, respondent A2).
För att överskådligt sammanfatta första blocket i undersökningen har jag valt att avsluta
med en tabell som redogör för de mest frekventa kravhanteringsproblemen identifierade.
Problemen återges i förhållande till i hur ofta de omnämns i underökningen, se nedan.
35
Kravhanteringsproblem
Frekvens %
Tidsramen
71 %
Tiden räcker inte till för ett optimalt genomförande och resultat
Kravspecifikationen
71 %
Ofullständig utformning, komplext omfång, dåligt anpassad detaljnivå
och dåligt anpassat skriftspråk är alla faktorer som ger indikation på att
specifikationen är en bidragande orsak till defekter
Beställarens roll
71 %
Bristande erfarenhet, otillräcklig kompetens och oengagemang
Kommunikationsprocessen/begreppsapparaten
71 %
Komplex, ofullständig och illa anpassad för målgruppen
Erfarenhet och kunskapsnivån varierar i projektgruppen vilket påver- 57 %
kar avancemanget och resultatet i processen
Inga tydliga avgränsningar
43 %
Ofullständigt ansvar/ ofullständig projektorganisation
43 %
Oaktiva roller och bristande ansvarstagande
Fel personer involverade i kravsamlingen
29 %
Avsaknad av nyckelpersoner
29 %
Bristande granskning av krav och resultat
29 %
Kravens kvalitet utvärderas ej
14 %
Tabell 4:2: Kravhanteringsproblem (Källa, egen).
4.3
Block 2: Teamet
Projektgruppen har en väsentlig roll i kravhanteringsprocessen. Tillsammans ska
en grupp av enskilda individer med olika förutsättningar driva processen mot ett
specifikt mål. Teamets mognad har följaktligen stor betydelse för dess effektivitet.
- I intervjuns andra skede bad jag vederbörande respondent att återge sin generella tolkning
av teamets betydelse för kravhanteringsprocessen. Jag efterfrågade faktorer med betydelse
för processen framgång.
Alla respondenter i undersökningen visade stor medvetenhet för teamets betydelse i kravhanteringsprocessen. Jag har valt att inkludera flera uttalanden från alla respondentgrupper
för att belysa var fokus betonades i denna frågeställning.
- ” En tydlig projektledare och beställare; involverade medlemmar; explicit ansvarstagande för
tilldelad roll; rätt personer med rätt kompetens samt en involverad referensgrupp; är tydliga och
36
konkreta faktorer som jag anser påverkas teamets effektivitet och därtill processen framgång. ”
(Carina Holgersson, respondent A2).
- ”Det är viktigt att inkludera alla roller som behövs i teamet och att se till att alla som är med
har tid för sin roll. Det är viktigt att teamet förstår sin roll och vad som förväntas För teamets
mognad är mixen viktigt. Det är centralt att blanda både erfarna och mindre erfarna karaktärer i projektet för att dels få de nya sinneslagen som driver och dels de mer erfarna som bibehåller en viss balans och kontroll. Det är också viktigt att inse betydelsen av en referensgrupp i
kravhanteringsprocessen. Det ska vara en referensgrupp av rätt sammansättning, d.v.s. som
speglar verkligheten. Likaså är det centralt att ständigt förnya referensgrupperna för att få tillgång till nya synpunkter och perspektiv.” (Respondent A1, Hillevi Fransson).
- “Teamets sammansättning är jätteviktig för att lyckas med kravhanteringsarbetet, för att vara
effektiv och framgångsrik. Det måste också finnas dem som vågar att ställa de kritiska frågorna, d.v.s. de som vågar ifrågasätta. Många gånger sätts teamet samman av befintliga roller och
man glömmer bort att det även bör finnas en mix av rollinnehavare som är kritiska, analytiska, kreativa o.s.v. för att skapa dynamik i teamet” (Per-Erik Velin, respondent B1).
- ”Teamets sammansättning har stor betydelse för hur kravarbetet kommer att fungera. Framförallt är det avgörande att tydliggöra respektive gruppmedlems ansvar. Även olika aspekter
krävs och bör inkluderas för en optimal sammansättning. Ofta har man inte som primärt syfte
att inkludera olika människotyper utan det är istället kompetens och ansvar som styr sammansättningen. Processtänkt och struktur underlättar och hjälper teamet i sitt arbetet. Det är också
centralt att det finns en balans mellan rollerna för att processen ska fungera optimalt” (Susanna
Frennemo, respondent C2).
- ”Ett vanligt scenario då en projektgrupp ska blidas är att ett antal personer ”slängs ihop” för
att bilda ett team. Ibland faller det mer naturlig vem som bör ingå i teamet men i många fall är
det samma personer som sitter med i projektgruppen. Problematiken är då fel personer involveras tillförs inte gruppen rätt kompetens. Således är det viktigt att ha med rätt personer under
projektets olika delar, d.v.s. ta hänsyn till gruppens sammansättning över tiden” (Kim Lindborg, respondent A3).
- ”Teamets kompetens och sakkunskap i förhållande till projektmålet är mycket viktigt”.
(Michael Bengtsson, respondent B2).
- ”Det är viktigt att lyfta fram och fira när teamet har lyckats och inte omedelbart börja tackla
nästa problem. På så vis får teamet bekräftelse på att ”vi har lyckats, vi är på rätt väg, det här
fixar vi!””. (Carina Holgersson, respondent A2).
4.4
Block 3: Kommunikation
I samspelet mellan människor spelar kommunikation en avgörande roll varav sättet
vi kommunicerar på har en avgörande betydelse för kravhanteringsprocessens
framgång.
- I det sista blocket efterfrågade jag påverkande faktorer i relation till sättet vi kommunicerar på som har betydelse för kravhanteringsprocessen. Alla respondenter ombads även att
om möjligt även reflektera över vilka orsaker och samband som finns att urskilja i förhållande till identifierade faktorer.
37
Skiljaktigheter i språket, d.v.s. olika begreppsapparater är framförallt ett hinder i kommunikationsprocessen som påverkar kravhantering märkbart. Att kommunicera väl och eftertänksamt för att nå framgång i processen, var de flesta respondenterna överrens om.
- ”Att kunna beskriva konsekvenserna för ett visst beslut och göra dem explicita resulterar i
något som är lättare för alla parter att applicera i verkligheten. Struktur och formalia är två
centrala faktorer för att kommunikationsprocessen ska fungera väl i en komplex kontext.”
(Per-Erik Velin, respondent B1).
Per-Erik kompletterar sitt uttalande med följande argument:
- ”Olika begreppsapparater utgör också ett problem i kommunikationen. Då vi inte kan förstå
konsekvenserna av ett beslut eller agerande är det väsentligt att inkludera någon med rätt sorts
kompetens att vara kritisk och ställa ”de där frågorna” som verkligen ger ett grundligt och
igenkännbart svar” (Per-Erik Velin, respondent B1).
Även Michael Bengtsson gjorde ett intressant uttalande om hur han tycker det vore
lämpligt att arbeta med kravspecifikationens framställning för att lyckas övervinna
kommunikativa hinder:
- ”Att som beställare inte förstå tekniken och på så vis inte kunna översätta kravspecifikationen till vad den i realiteten betyder är ett stort problem men går att lösa genom att arbetat iterativt. Genom att arbeta iterativt kan beställare och IT-aktören tillsammans förtydliga dokumentet varav olika versioner på så vis successivt kan växa fram och förtydligar bilden” (Michael
Bengtsson, respondent B2).
Carina Holgersson anser att det finns ett stort ansvar att ta för att kommunikationsprocessen ska fungera önskvärt. Exempelvis bör det vid ett möte finnas en tydlig agenda för att
förmedla struktur. Även e-post som kommunikationsapparat kräver ett ansvar då det är lätt
att misstolka innehållet i ett mail; - ”Man måste nästintill vara överdrivet positiv för att motparten
inte ska känna sig trampad på tårna. I många fall kan en överdriven mailkontakt leda till komplicerade
diskussioner och ohållbara situationer. Betydelsen av personlig kontakt få inte negligeras”!
Carina fortsätter att belysa kommunikationens betydelse för kravhanteringsprocessens
framgång. - ”Det är viktigt att varje enskild aktör tar ansvar för att förankra sin åsikt. Vissa personer
tar dock inte detta ansvar på allvar och då är det inte alls ovanligt att ”luckor” uppstår i kravarbetet,
d.v.s. väsentliga krav utelämnas. Att begreppsapparaten heller inte är den samma för projektets olika aktörer är ingen nyhet men något som absolut inte får ignoreras. Det är viktigt att ta diskussionen tidigt, se
till att alla förstår vad som sker. Alla förstår nämligen inte hur viktigt det är att ha med sig alla aktörer
för att lyckas”.
Slutligen betonar också Carina betydelsen av tydligt förankrade och kommunicerad mål för
att undvika varierande målbilder. - ”Genom att tydlig kommunicera de mål som finns undviker vi att
det uppstår målbilder som står i motsättning till varandra”.
Det blev också uppenbart att man förstod problematikens olika sidor och flera bra aspekter
av problemområdet alstrades i undersökningen. Kim Lindborg delade med sig av sina kunskaper och erfarenheter i sakförhållandet:
- ”I och med att vi människor tolkar saker och ting olika är det viktigt att förklarar vad vi
verkligen menar. Att använda ett för komplicerat språk kan likväl som att använda ett för
banalt språk resultera i ren ”dynga”! Därför måste vi ta hänsyn till vem målgruppen är och
vilken effekt vi vill åstadkomma” (Kim Lindborg, respondent A3).
Kim tycker också att det är mycket viktigt att själva överlämningen av information fungerar
bra. - ”Ett omfattande processtänkt är gynnande och tillför förståelse för hela flödet. Ett tydligt driv ska38
pas då jag själv förstår hur mitt arbete tillför värde. För att återkoppla detta till vilken betydelse själva
överlämningen har är det således viktigt att feedbacken fungerar och utdelas optimalt. Att två personer tar i
hand och återkopplar direkt, alltså en dubbelriktad kommunikationsprocess. Alla måste ta sitt ansvar för
att det som förmedlas i överlämningen tas emot och att feedback ges direkt”.
Avslutningsvis har jag valt att även inkludera en kommentar som understryker att ”kommunikation är mer än bara ord”. Det är Hillevi Fransson från respondentgrupp A som förklarar hur hon löser problemet att få alla berörda aktörer att tolka saker och ting lika:
- ”En bild är ett mycket bra verktyg för att kommunicera och undvika missförstånd. Med en
bild är det betydligt lättare att förklara ett krav så att alla berörda parter förstår. Beroende på
om du har en tekniks bakgrund, ör användare eller beställare så har vi alla olika perspektiv,
kompetens och förståelse. Att alla ”ser samma sak” är en förutsättning för att resultatet ska
stämma överrens med de förväntningar som finns. Alla kan vara med och diskutera en bild.
Även för styrgruppen som i många fall inte har den bakgrund och förförståelse för uppgiften som
krävs, är en bild mycket användbar för att fatta korrekta beslut” (Hillevi Fransson, respondent A1).
Samtliga respondenter är väl medvetna om hur viktigt det är att vara tydlig. De flesta nämner i intervjun betydelsen av att uttrycka sig enkelt i skrift och språk så att alla parter involverade förstår och kan uppfatta saker och ting lika.
- ”För att kravhanteringsprocessen ska fungera krävs god kommunikationsförmåga från båda
parter. Kommunikationen är verkligen A & O för att lyckas med arbetet” (Susanna Frennemo, respondent C2).
Jag har valt att avsluta sammanfattningen av den empiriska studien med ännu ett uttalande.
Citatet speglar med ett fåtal ord vad det är som krävs för att nå framgång i kravhanteringsprocessen:
- ”Det är många mjuka värden som behöver vävas in, inte bara kod och hårda krav. Det är
viktigt att vidga sin vy och inte bara se till hårda fakta. Våga ta tid och plats för att försäkra
att alla berörda förstår” (Hillevi Fransson, respondent A1).
39
5
Analys
”I detta kapitel redogör författaren sina egna tankar och synpunkter om undersökningen. Strukturen följer
ett sådant mönster att det ska vara enkelt att anknyta till föregående kapitel. Startpunkten för analysen är
en generell analysmodell”.
5.1
Analysmodell
Innan jag påbörjar utvärderingen tänker jag på nytt gå igenom den generella analysmodell
jag beslutat att använda för att analysera ett urval av de kravhanteringsproblem identifierade
i undersökningen. Modellen bygger som tidigare nämnt på en enkel struktur hämtad från
skolverket och det går lätt att följa deklarerat resonemang utifrån den. I bilden nedan illustreras stommen till modellen.
Figur 5:1: Analysmodellen (Skolverket, 2007).
Förutom bestämda kriterium som framgår av modellen kommer jag även att ge egna kommentarer och reflektioner i respektive sakförhållande. I metoden finns modellen grundligt
förklarad men jag anser att det kan vara relevant att åter belysa ett par centrala aspekter
med betydelse för hur modellen bör tolkas. I analysmodellen pekar attributet åtgärder mot
både kolumnen för orsak samt konsekvens, vilket är helt korrekt. Min intention är att
komma fram till en realiserbar lösning som kontrollerar helheten och inte bara framförvarande element som skulle vara det självklara resultatet om jag istället använde en cyklisk
modell. Min motiveringen är följaktligen att med hjälp av modellen finna en komplett lösning som inte enbart fokuserar på källan till problemet utan dessutom avser att förekomma
symptomen.
De fyra mest frekvent omnämnda problemen hämtade från undersökningen kommer att
analyseras utifrån angiven analysmodell. Övriga delar av analysen sker utifrån en hermeneutisk ansats där min förförståelse spelar en väsentlig roll för hur jag tolkar resultatet
40
Problem I
Att tiden är ett stort problem i kravhanteringsprocessen är påtagligt utifrån givet resultat i
undersökningen. Med utgångspunkt i problemet har jag därför utvärderat tänkvärda orsaker, konsekvenser samt lämpliga åtgärder. Jag har således tolkat resultatet från den empiriska studien i relation till problemet och därtill adderat egna kommentarer i modellen som attribut under kategorin för åtgärder. Härnäst följer en tolkande diskussion hur jag kommit
fram till deklarerat resonemang samt några reflektioner i förhållande till teoretisk referensram vald för uppsatsämnet. (Följande tre problem kommer att bemötas på samma sätt,
d.v.s. i den typ av struktur jag tillämpar för att analysera problem I).
Samtliga respondenter uttryckte att tiden utgjorde ett kravhanteringsproblem med omfattande konsekvenser för fortsatt arbete. Utifrån deras resonemang förstod jag att dålig planering för kravhanteringsprocessen var en utav orsakerna till detta liksom att tiden allokerad prioriterades andra delar av projektet. Enligt Eriksson (2007) är kravhanteringsarbetet i
många fall mycket omfattande varav han i sin litteratur förespråkar ett iterativt arbetssätt.
Fördelarna med att arbeta iterativt är att snabbare återkoppling kan ges och bättre överblick
serveras. Utifrån Erikssons resonemang tolkar jag det som en lämplig åtgärd att arbeta iterativt för att kunna tidsoptimera kravhanteringsprocessen. Det iterativa arbetssättet medför
nämligen också ett stöd för att driva olika aktiviteter parallellt. På fallföretaget finns verktyg
för att bedriva processen iterativ dock tolkar jag det som att man inte tillämpar metodiken
till fullo, här finns således mer att ge. Även Reynolds (2006) kastar i sin artikel ljus på hur
ett systemutvecklingsprojekt som utvecklas iterativt har större chans att hålla bestämd tidsram och därtill dessutom leverera funktionalitet som stämmer överrens med behovet.
Niazi & Shastry (2003) omnämner i sin artikel att vi måste förstå kravhanteringsprocessen
roll i systemutvecklingsprojekt för att kunna förbättra och reducera problemnivån. I under41
sökningen var det framförallt de respondenter i rollen som teknisk projektledare som belyste betydelsen av att förstå kravhanteringsprocessens funktion. De förklarade vid flertal tillfällen hur viktigt det var att få beställaren och resterade delar av verksamheten införstådda
med processens relevans och kommande betydelse för utvecklingsfasen. Hos IT-aktören
kunde jag tyda en viss frustration över den begränsade förståelsen inom verksamheten.
I projektgruppen skiljer sig erfarenhet och kunskap åt vilket påverkar inställningen till hur
systemutvecklingsprojekt lämpligast bör drivas för ett framgångsrikt resultat. Inom IT
funktionen finns enligt min uppfattning större förståelse för varför kravhanteringsprocessen bör prioriteras mer tid. Inom verksamheten anser man emellertid också att den otillräckliga tidsramen utgör ett stort problem men jag tolkar det inte som att denna kategori
alla gånger är lika medvetna om varför det är viktigt att prioritera tid i denna fas. Olika erfarenheter, kunskap och förståelse för systemutveckling styr alltså hur vederbörande part
uppfattar problematiken i kravhanering. Alla parter är dock väl medvetna om de konsekvenser som följer som ett resultat av problemet angivet. Det faller sig troligtvis mer naturligt för vederbörande att relatera till konsekvenser som är explicita och tydliga.
Sammanfattningsvis har analysen av det första problemet resulterat i följande konklusioner:
•
Alla respondenter är väl medvetna om tidens betydelse för en framgångsrik kravhanteringsprocess dock upplever jag att de respondenter med teknisk bakgrund har
större förståelse för varför tiden är en avgörande faktor.
•
Jag anser att en iterativ arbetsform skulle gynna processen ur ett tidsperspektiv vilket är centralt för problemställningen.
•
Slutligen tolkar jag att det krävs att hela projektgruppen arbetar efter ett homogent
mönster för att komma tillrätta med upplevd problematik. Alla berörda parter måste förstå processens betydelse för att tillsammans kunna reducera problemnivån.
42
Problem II
Liksom att tiden är en karakteristisk felkälla i kravhanteringsprocessen var svarsfrekvensen
från undersökningen hög vad gällde kravhanteringsproblemet en bristande kravspecifikation. Att kravspecifikationen i de flesta fall brister i något avseende är ingen nyhet. Det intressanta i undersökningen är att medvetenheten kring detta specifika problem är hög men
trots det finns det en likgiltighet för dokumentet. Alla respondenter diskuterade flitigt problematiken, orsaker och konsekvenser men jag uppfattade aldrig att det fanns ett direkt engagemang för att göra en drastisk förändring. Det framgick flertalet bra åtgärder och idéer
för att komma tillrätta med problemet men återigen kände jag aldrig någon dynamik i ställningstagandet. Jag tror att de flesta är väl medvetna om hur problemet påverkar kravhanteringsprocessen samt resultatet men man är bekväm och orkar helt enkelt inte att finna en
lösning.
Som nämnt i föregående problemställning finns det sällan tid, tid att göra det som verkligen
krävs för att grundligt komma tillrätta med detaljer som är avgörande för helheten, för resultatet. Jag tror det krävs att disciplinen i systemutvecklingsprojekt mognar och att man inser att allt kan inte vara gjort igår då det är komplexa uppgifter med stor osäkerhet som ska
lösas. Reynolds (2006) talar i sin artikel om hur vi bör bemöta osäkerheten i kravhanteringsprocessen. Ofta finns inte all information tillgänglig vid en och samma tidpunkt för att
beskriva ett fullständigt behov. Utmaningen är som han nämner att kunna leverera de krav
43
som är kända och samtidigt göra det möjligt att leverera övriga i takt med att de framträder.
Jag tolkar det Reynolds föreskriver som ett lämpligt koncept för praktisk tillämpning som
skulle kunna generera goda förutsättningar att förhindra att dokumentet som skapas blir
ofullständigt eller irrelevant.
För att nå ett fullständigt resultat fodras att alla parter tar ett ansvar. Pozgaj, Sertic & Boban
(2003) skriver i sin artikel om en metod för effektiv kravhantering som syftar till hur ansvar
bör fördelas. De skriver så här; för att vi ska kunna samla och beskriva krav på ett bra sätt
rekommenderas att alla medlemmar i projektteamet bör ha ansvar för uppgifter nära kopplade till deras kompetens. På så vis blir alla deltagare ansvariga för att samla och beskriva de
krav som ligger inom deras kompetensområde Jag tolkar metoden som mycket inspirerande och som en frisk fläkt skänker den oss ett nytt perspektiv på hur ansvarstagande ska optimeras för att generera ett bättre underlag. Att använda en best practice likt den Pozgaj,
Sertic & Boban beskriver upplever jag som ett gott alternativ för att komma i ordning med
bestämt problem. Det finns en viss säkerhet i att bruka best practices då andra tidigare har
använt samma verktyg med god verkan.
Vidare anser jag att problemet måste lyftas till en strategisk nivå för att konsekvenserna ska
få fäste och verkligen uppdagas istället för att negligeras och fösas åt sidan. Jag anser att lyfter man problemet och skapar nya rutiner för att hantera kravspecifikationen finns det goda
möjligheter för att lyckas. Det är såldes centralt att alla är med och skapar förändring för att
förankra de nya rutinerna väl. Alla typer av förändringsarbete har en viss tendens till motstånd och det gäller därför att, som nämnt, först lyfta problemet och därefter skapa en
gemensam vision för en önskvärt framtidsbild. En uttalad vision är ett bra hjälpmedel för
att få alla engagerade för en och samma målbild. Målbilden ska vara konkret och det ska
vara explicit uttryckt vad som genereras respektive vad som förkastas för att öka förståelsen
och toleransen för en förändring.
Jag tror själva på att iterativ utveckling av dokumentet skapar förutsättning för ett bättre resultat. Att arbetat iterativ erbjuder kontinuerlig utvärdering av resultatet samt att kraven
som samlas är ajour med de förväntningar och behov som finns. Därtill har det stor betydelse att språket är anpassat efter de parter berörda av dokumentet. Det måste finnas logik i
det som dokumenteras för att informationen ska kunna tillämpas optimalt. När jag genomförde studien fanns det dem som inte omnämnde språket som ett hinder fastän det latent
framgick att det var ett problem. Jag tror att det är känslosamt att erkänna att det här förstår jag inte. Genom att arbeta med ett anpassat språk kompletterat med bilder finns det
möjlighet för alla parter att känna igen det som dokumenteras samtidigt som det öppnar
upp möjligheter för alla att kritisk granska de krav som dokumenteras. När alla parter har
förutsättning att förstå dokumentinnehållet ökar oddset för att resultatet ska stämma överrens med de förväntningar som finns. Först då kan vi betrakta kravhanteringsprocessen
som framgångsrik.
Analysen av problem två kan summeras i följande punkter:
•
Jag tolkar det som att systemutvecklingsprojekt behöver mogna för kravhanteringsprocessen ska få utrymme att utvecklas.
•
Därtill betonar jag betydelsen av ansvar för att förebygga en bristfällig kravspecifikation. Jag anser att Pozgaj, Sertic & Boban redogör för en tillämpningsbar metod
som skänker nytt perspektiv på hur ansvartagande kan optimera processen.
•
Slutligen betonar jag även nya rutiner, iterativ utveckling och ett anpassat språk för
att alla parter ska kunna känna igen sig och förstå innehållet. Att skapa förändring
tillsammans kan vara startpunkten för att komma till insikt med problemet.
44
Problem III
I förhållande till systemutvecklingsprojekt är beställarrollen i många fall inkomplett. Det
krävs andra typer av erfarenhet och kunskaper för att driva rollen optimalt tillskillnad från
ordinära verksamhetsprojekt. Det är som nämnt vid ett tillfälle i undersökningen ”ett beställningsförfarande på detaljnivå” som krävs. Jag tolkade samtliga respondenter som väl
medvetna om denna problematik och vilka orsakerna är. Även de respondenter med en
tydlig beställarroll markerade på hur deras okunskap och brist på erfarenhet i förhållande
till uppgiften ibland utgör ett hinder i processen. Respondenterna delade emellertid med sig
av färre åsikt för de konsekvenser som problemet resulterar i. Detta tolkar jag som en signal på att man ignorerar de åtgärder som finns att tillämpa och istället väljer att arbeta som
man alltid gjort. Fram tills att någon ifrågasätter handlingen kommer det att fortsätta på det
här sättet. Jag har förhoppningar om att lyfta detta till en relevant frågeställning för att förhoppningsvis kunna förebygga, eller bäst av allt eliminera detta problem som enligt min
mening är av relativt banal karaktär. Det handla egentligen bara om att orka arbeta på rätt
sätt med rätt roll för att få till stånd en lösning.
Vidare anser jag att det är otroligt viktigt att man delar med sig av kunskap och erfarenhet
inom gruppen så att alla parter kan dra nytta av den. Likaså ska tilldelad roll ske efter principen bäst lämpad för att undvika oengagemang. Med rollen ska det följa ett tydligt ansvar
som sätter prägel på vad som förväntas av rollinnehavaren. Det är mycket orättvist att tilldela en roll slumpmässigt, dels för vederbörande rolltagare, dels för projektgruppen men
framförallt för kunden. Att arbeta med tydliga roller skapar en bra bas för en effektiv arbetsprocess där alla är väl medvetna om vad de förvänts bidraga med. För att ytterligare
45
tolka situationen av rollens betydelse kontra arbetsprocessens effektivitet har jag valt att
tolka situationen utifrån FIRO-modellen. För att nå den slutliga och eftertraktade samhörigheten krävs det att alla roller och förväntningar är glasklara för vederbörande part så att
slutligen broar kan byggas mellan gruppens olika deltagare.
I undersökningen kände jag tendens till att många roller inte tillsätts utifrån de grundprinciper som egentligen borde styra. Det är därför viktigt att markera vilken betydelse beställarrollen har i ett systemutvecklingsprojekt. Beställaren måste vara väl medveten om vilket
ansvar rollen för med sig och själv avgöra om han eller hon är kapabel att fylla platsen optimalt. God självinsikt och ett mod att våga ta eller förkasta rollen är centralt för att komma
tillrätta med problemet. Rollen som beställare får inte påtvingas oavsett om rolltagaren är
kapabel eller ej. Kapacitet för rollen måste gå hand i hand med vilja att agera som beställare, annars är konsekvenserna de samma. Som Dimberly & Burton (1999) nämner är rollfördelningen inom gruppen betydelsefull för dess effektivitet.
Då jag tolkade respondenternas input i detta avseende tycker jag att alla delade en mogen
inställning till betydelsen av beställarens roll för en framgångsrik kravhanteringsprocess
men det fanns ingen märkbar benägenhet att förändra aktuell situation.
Det går att sammanfatta analysen av problem III i följande punkter:
•
Beställarerollen i ett systemutvecklingsprojekt betraktar jag som inkomplett i förhållande till ordinära verksamhetsprojekt. Framförallt är det avsaknad av kunskap och
erfarenhet som gör att jag tolkar situationen som ofullständig. Acceptansen för detaljnivån är otillräcklig och försvårar beställarrollen i kravhanteringen.
•
Jag tolkar det som att det finns en viss brist på förståelse för problemet. De flesta
väljer att arbeta kvar enligt gamla rutiner istället för att se till en ny lösning.
•
Det är centralt att arbeta med tydliga roller för att åstadkomma en effektiv arbetsprocess.
46
Problem IV
Att kommunikationsprocessen är en faktor av stor betydelse för kravarbetet klargjorde resultatet från undersökningen. Bristfällig kommunikation är ett kravhanteringsproblem som
tydligt präglar processens framgång. Att kommunicera effektivt kräver mer än vad man
tror. Det finns flera faktorer med stor betydelse för kommunikationsprocessens avancemang därav bland andra valet av kommunikationskanal, omgivningen och inte minst budskapet i sig.
Enligt Maltén (1998) är kontextmodellen ett bra verktyg för att beskriva kommunikationsbegreppet. I modellen framgår det hur budskapet pendlar mellan sändare och mottagare
samt betydelsen av aspekter som kodning, avkodning, val av kanal, feedback och kontext.
Jag tolkar likt Maltén att all kommunikation sker i ett sammanhang, en kontext, som har
betydelse för kommunikationsprocessen. Att förstå hur omgivningen påverkar sättet vi
kommunicerar på är en förutsättning för att komma tillrätta med processen.
Alla respondenter visade återigen god förståelse för problematiken och diskuterade flitigt
konsekvenserna av en mindre väl fungerande kommunikationsprocess. De respondenter
med större erfarenhet och kunskap av systemutveckling tolkade jag som något mer medvetna om orsakerna till problemet. De kunde framförallt relatera till konkreta källor tillskillnad från övriga respondenter som hellre diskuterade konsekvenserna av problemet.
Detta grundar sig troligtvis på skillnader i erfarenhet och kunskap men också personligt intresse för processen. Några i undersökningen visade ett gediget engagemang för syftet med
47
studien tillskillnad från andra som ”gärna ställde upp” men aldrig riktigt visade samma intensitet i intervjun.
Det finns som Dimberly och Burton (1999) nämner flera olika syften med att kommunicera. Ett av behoven vi vill tillgodose är förmågan att samarbeta. Vi kommunicerar följaktligen för att kunna samarbeta och det är just i samarbetet mellan människor som kommunikationsprocessen har sitt största behov och syfte. Teorin lyfter fram en centrala argument
för att förstå innebörden i att kommunicera. Att kommunicera rätt, effektivt och målmedvetet är en förutsättning för maximal framgång i kravhanteringsprocessen. Jag tolkar likt
Maltén (1998) att i samspelet mellan människor spelar sättet vi kommunicerar på en avgörande roll. Fungerar kommunikationen ökar premisserna för att kravhanteringsprocessen
ska fungera och resultera i det som förväntas. I och med att det är ett storartat samarbete
som sker mellan olika aktörer med olika erfarenhet, kompetens och kunskap är det centralt
att kunna kommunicera för att gå vidare i processen mot givet mål. Det gäller att alla är
medveten om och tar ansvar för sitt budskap. Är berörd sändare dessutom medveten om
att mottagaren påverkas av ytter omständigheter då den tolkar budskapet är också möjligheten större att sändaren tar ansvar och direkt återkopplar till att budskapet mottagits korrekt. För att kommunicera effektivt handlar det inte bara om att kunna föra fram ett budskap utan lika mycket om att lyssna effektivt. Genom att verkligen lyssna på det budskap
som sänds minskar risken för missförstånd betydligt. Alla parter måste vara aktiva i kommunikationsprocessen och dessutom vara medveten om vad det är som orsakar bristfällig
kommunikation.
Enligt min åsikt är förmågan att kommunicera avgörande för att nå ett gemensamt mål.
Kan vi inte kommunicera kommer vi heller inte framåt i processen. Vi måste lära oss att
skicka anpassade budskap, att lyssna och återkoppla för att inte fördröja avancemanget i
kravhanteringsprocessen. Alla måste förstå betydelsen av effektiv kommunikation för att
kunna tillämpa konceptet. När alla är medvetna är de också mottagliga på ett helt annat vis
och förhoppningsvis förändringsbenägna. Det finns kanske behov av att någon förmedlar
kunskapen för att alla ska få en rättfärdig chans att ta del av den och förstå hur mycket det
betyder för slutresultatet att kommunikationen fungerar. Idag pratas det mycket om lärande
organisationer, d.v.s. att alla ska dela kunskap med varandra för att på så vis snabbare utvecklas. För att lösa problemet med bristfällig kommunikation måste de som förstår hur
kommunikationsprocessen fungerar dela med sig av sina kunskaper till sina arbetskamraterna. Kontentan är att vi måste lära oss att kommunicera effektivt och det gör vi lättast
genom praktisk erfarenhet. Jag tror därför också att det är centralt att efter ett projektavslut
utvärdera hur kommunikationen påverkat processen för att kunna lära sig av det som hänt
och på så vis förändra situationen till den bättre. Kommunikation är inget ”gripbart” fenomen, det handlar istället om att ta vara på erfarenheter för att vid nästa tillfället kunna
förändra till det bättre.
Analysen kan sammanfattas i nedanstående punkter:
•
Jag tolkar det som att det krävs mycket mer än vad vi tror för att kommunikationen
ska fungera. Ofta är vi omedvetna om de faktorer som påverkar processen.
•
Sättet vi kommunicerar på har stor betydelse för vår förmåga att samarbeta med
andra människor.
•
Att kommunicera väl handlar inte enbart om att framföra ett budskap utan lika
mycket om att lyssna effektivt.
48
5.2
Egna tankar
I den avslutande delen kommer jag att utveckla mina egna tankar kring resultatet och gör
det i förhållande till de tre block som studien baseras på. Mina egna tankar utgör synpunkter och reflektioner baserat på hur jag har tolkat informationen genererad i undersökningen.
5.2.1
Block 1: Kravhanteringsprocessen
Syftet med uppsatsen var att tolka kravhanteringsprocessen i organisation X med målet att
skapa förståelse för vilka faktorer som utgör problem i praktiken. Jag tycker att syftet är infriat med motiveringen att studien har genererat ett antal konkreta kravhanteringsproblem.
I tidigare applicerad analysmodell valde jag att analysera de problem med störst svarsfrekvens. Jag kommer nu att diskutera samtliga problemdimensioner.
Resultatet från undersökningen motsvarar många av de förväntningar jag hade. Utifrån teori och praktisk erfarenhet går det att utläsa tydliga paralleller till faktorer i verkligheten med
explicit uttrycksform som grundar för problematik i kravhanteringsprocessen. Framförallt
är det tidsramen som inte räcker till, kommunikationsprocessen som vacklar, vaga roller
och en bristfällig kravspecifikationen som skapar problem och fundament för ytterligare
problematik. Tiden som är en påtaglig faktor har stor betydelse för processens framgång.
Räcker inte tiden till påverkar detta alla andra delar av processen obehindrat. Krav samlas,
dokumenteras och prioriteras under press, kommunikationen blir lidande då stressen kryper på liksom roller tilldelas utan eftertanke. Roller som tilldelas utan eftertanke leder i
många fall till att ansvar för rollen inte heller tas enligt förväntan likaså är chansen större att
engagemanget för uppgiften tryter. Att rätt erfarenhet och kunskap tillförs är lika centralt
som att rollen tilldelas efter principen bäst lämpad.
Teamets sammansättning anser jag har stor betydelse för hur kravhanteringsprocessen
avancerar. Teamet ska sättas samman med eftertanke, vem passar bäst rollen som beställare, vem har mandat och rätt kompetens att sitta med i styrguppen och vem är bäst lämpad
som den drivande projektledaren m.m. Alla dessa frågor måste vi få ett klart svar på och
inte bara chansa oss till en lämplig lösning. Konsekvenserna av att misslyckas med teamets
uppbyggnad är för stora och för att se genom fingrarna på. Det går inte längre att bedriva
kravhantering utan struktur och en tydlig strategi. Alla problem som uppdagades i undersökningen är behandlingsbara men det krävs emellertid att vi inte förnekar dem och dess
betydelse för helheten. Det går inte att chansa längre! Finns det underlag för att göra saker
och ting bättre måste lämpliga lösningar appliceras och testas. Det går inte att ignorera det
som är uppenbart. Jag tolkar nivån av medvetenhet för problematiken i kravhanteringsprocessen som hög men det krävs att vi vågar börja satsa på nya taktiker för att nå bättre resultat. Det är lämpligt att kontinuerligt utvärdera avslutade processer för att fortlöpande lära
av sina misstag och kontinuerligt fortsätta att förbättra. Kravhantering i systemutvecklingsprojekt är mer komplext, detaljerat och framförallt outforskat än i ordinära verksamhetsprojekt och måste tilldelas mer eftertanke för att kunna drivas optimalt. Det finns gott om
litteratur och vetenskapliga verk som belyser både problematik, lämplig metodik och tankar
kring kravhantering i systemutvecklingsprojekt. Min reflektion är; varför lär vi inte av
andras misstag och tar tillvara på de erfarenheter som ges. Visst kommer det att krävas resurser för att genomdriva en förändring men det behöver inte vara kopiösa kapital som
krävs för att förändra. Det som krävs är istället eftertanke för de behov som måste tillgodoses för att kravhanteringsprocessen ska kunna drivas effektivt och framgångsrikt. Tänk
noga efter hur teamet ska se ut, vilken kompetens, kunskap och erfarenhet som krävs, vilka
människotyper är relevant och hur bör roller lämpligast fördelas utifrån dessa aspekter.
Lägg till detta ansvar för att kommunikationen fungerar, använd en begreppsapparat som
49
alla parter är införstådda med och ge feedback i de situationer som kräver. Se framförallt
också till att kravhanteringsprocessen tilldelas en lämplig tidsram som passar ändamålet för
effektiv samling, prioritering och dokumentering av de krav som finns. Det är mycket som
ska klaffa för ett perfekt resultat. Jag tror därför att det är viktigt att alla som är delaktiga i
processen tar sitt ansvar för resultatet vilket medför att alla måste vara medvetna om de
förutsättningar som finns. Dela gärna kunskap, informera varandra om tidigare erfarenheter och försök att hitta nya vägar, våga starta om! Det krävs att alla är medvetna om orsakerna till problemen och dess konsekvenser för att förstå vad det är som krävs för att åtgärda eventuella brister. Att förstå är en förutsättning för att kunna förändra.
5.2.2
Block 2: Teamet
Jag har redan i föregående avsnitt berört teamets betydelse i kravhanteringsprocessen. I den
här delen kommer jag att föra en djupare diskussion kring teamet där egna reflektioner bär
tyngd i resonemanget.
Teamet har stor betydelse och väger tungt som framgångsfaktor i kravhanteringsprocessen.
Att sätta samman ett optimalt team är inte enkelt då det finns många behov och viljor som
styr. Det är dock viktigt att våga ställa sig kritisk till hur ett team sätts samman. Är det korrekta faktorer som styr eller är det ett lotteri? Utifrån genomförd studien tolkar jag situationen som benägen att förändras för att kunna prestera bättre resultat. Ett större fokus på
projektgruppens sammansättning är önskvärt för att finna nya vägar att förbättra kravhanteringsprocessen på. Det gäller att sätta samman teamet efter riktlinjer som passar ändamålet, d.v.s. situationsanpassa teamet efter behovet. Ett team kräver specifika roller, människotyper och befogenheter för att fungera optimalt. Det gäller såldes att vara medveten om
dessa kriterier och sätta samman teamet utifrån de krav som ställs. Det är också viktigt att
låta teamet utvecklas för att nå maximal effektivitet i arbetsprocessen. Idag finns det många
faktorer som påverkar gruppens utveckling och desto större kännedom vi har om dessa
desto bättre förutsättning har vi för att lyckas. Det gäller att arbeta målmedvetet med gruppen och fortlöpande stämma av faktiskt utfall mot önskvärt utfall. På fallföretag arbetar
man inte med optimala team utan är i många fall bekväm i valet utav gruppmedlemmar. De
som väljs, väljs i flera fall utav helt andra andledningar än vad som egentligen borde styra
teamets uppbyggnad. Troligtvis är det primärt budget och tillgänglighet som styr teamets
sammansättningen och man bortser från mer betydelsefulla attribut. Jag tolkar att situationen kräver mer kunskap och erfarenhet för att man ska förstå hur ett optimalt team skapas
men det är framförallt mandat och vilja som krävs för att genomföra konkreta åtgärder. Jag
tror också det är viktigt att förmedla betydelsen av ett väl fungerande team och verkligen
påvisa vilka effekter det medför för resultatet. Det som i början känns arbetsamt och motsträvigt kommer att löna sig i slutändan. Genom att starta med rätt grundförutsättningar
skapar vi underlag för en bättre process, resultat samt arbetsform.
Maltén (1998) skriver i sin bok att det bör stå klart för gruppens medlemmar att de är beroende av varandra parallellt som de kompletterar varandra, med andra ord ska de uppfatta
sig som ett team. Utifrån bl.a. Malténs teori tolkar jag det som oerhört centralt att gruppen
fungerar för att nå ett resultat. Det måste finnas medvetenhet hos gruppens medlemmar
om teamets betydelse, de måste förstå vad de kan tillföra gruppen och att gruppen tillsammans ska skapa förutsättning för att nå ett förutbestämt mål.
Teamets karaktärer ska tillsammans nå ett förutbestämt mål och för att detta ska ske effektivt är det viktigt att gruppen fungerar. Att skapa en grupp som fungerar väl är enklare om
vi tar hänsyn till vissa aspekter och har förståelse för vad som sker när gruppen ska utvecklas. Ledaren har en stor betydelse i en omogen grupp och har ansvar för att driva gruppen
vidare och framåt i utvecklingen. Det är centralt att ledaren kan stötta när så krävs men
50
också ta ett steg tillbaka och delegera ansvar till gruppen när tiden är mogen. Ledaren bör
tillämpa en ledarstil som passar ändamålet för att inte utgöra ett hinder i utvecklingsprocessen. I relation till gruppens utveckling går det att dra tydliga paralleller till lämpligt ledarskap
utifrån FIRO. Då gruppen befinner sig i tillhörafasen och framförallt i rollsökning har ledaren en framträdande roll än i samhörighet då ledaren intar en mer latent roll och delegerar
ansvaret till gruppen. Jag anser att det är av stor betydelse att ledarskapet fungerar för att
förse teamet med grundläggande förutsättningar för framgång. När vi ändå berör teorin
kring FIRO har jag också valt att tolka situationen de flesta grupper, team befinner sig i
under ett systemutvecklingsprojekt. Ofta hinner gruppen inte till samhörighet utan pendlar
fram och tillbaka mellan modellens främre faser. Detta betyder dock inte att teamet inte
kan arbetat effektivt. De grupper som befinner sig i tillhörafasen kan fungera mycket bra
och arbeta effektivt under kortare perioder. Ska jag dock vara riktig ärlig tycker jag det är
önskvärt att sträva mot samhörighet då fördelarna är så många fler. Jag tolkar följande
aspekter som betydelsefulla för att nå hit; ett bra ledarskap; tydliga mål; engagerade och
öppna gruppdeltagare samt ett utvecklande arbetsklimat.
Inom teamet finns det som nämnt olika roller som ska fyllas, dels uttalade roller i form av
beställare, projektledare o.s.v. men också informella roller som latent styr i gruppen. Det är
viktigt att de formellt uttalade rollerna tillsätts efter principen bäst lämpad och att de informella rollerna växer fram i takt med att gruppen utvecklas. Genom att ta hänsyn till vilka
människotyper som ingår i teamet underlättar vi för rollsökning av informella roller. En
grupp som bara består av analytiker kommer sällan eller aldrig att arbeta lika effektivt som
en grupp innehållande en mogen mix av exempelvis analytiker, kritiker och kreatörer. Larsen (2003) skriver i sin bok att en förutsättning för att få den kompetens som efterfrågas i
teamet är att vi på ett tydligt sätt kan beskriva de behov som ska tillgodoses. Utifrån resultatet av studien tolkar jag situationen som sådan att i många fall rivstartar man ett systemutvecklingsprojektprojektet och kravhanteringen kommer igång utan att det finns ett klarlagt eller fullständigt behov fastställt. På så vis försvåras situationen att skapa ett team med
den spetskompetens som egentligen är önskvärd för att driva processen med maximal verkan. Redan i starten måste det stå klart vilka uppgifter som ska lösas, vilka roller som ska
fyllas och vilken kunskap samt erfarenhet som krävs. För att driva en problemfri kravhanteringsprocess tror jag detta är en mycket central aspekt och därför inte värd att åsidosätta.
Det krävs att man lägger mer krut i startgropen och verkligen förankrar behovet grundligt
då det ligger till grund för så mycket mera.
Då jag genomförde studien kände jag att de flesta respondenter är väl medvetna om teamets betydelse för processens framgång. Det diskuterades flitigt hur roller måste fördelas
med omsorg och eftertanke för att underlätta arbetet. Alla påpekade hur viktigt det är att
samarbeta för att nå utsatt mål. Jag tolkar det som att driv för uppgiften är en eftertraktad
egenskap.
5.2.3
Block 3: Kommunikation
Det tredje och sista blocket handlar om kommunikationens betydelse för kravhanteringsprocessen. I undersökningen vara alla respondenter överrens om att en väl fungerande
kommunikationsprocess har stor inverkan på både arbetsprocess och resultat.
Att kommunikationen fungerar mer eller mindre bra är ett faktum. Det finns många faktorer som styr och jag har tidigare i analysen varit i kontakt med flera av dessa. Framförallt är
det viktigt att ta hänsyn till val av kommunikationskanal, omgivningens betydelse, hur budskapet kodas respektive avkodas samt om det finns möjlighet att ge feedback. Att ge feedback gör det möjligt att direkt bekräfta ett budskap och undvika missförstånd. Precis som
Maltén (1998) klarlägger i sin teori anser jag också att det vid all kommunikation finns an-
51
ledning att återkoppla för att kontrollera att budskapet uppfattas på rätt sätt. Det är emellertid också av stor betydelse att feedbacken tas emot på ett effektivt sätt. Det är inte önskvärt att mottagaren förnekar eller intar en försvarsställning istället bör/ska den vara välvillig
till att förändra. Mottagaren kan först när han har nått den insikten välja om han vill förkasta delgiven feedback. Jag tänker inte gå djupare in på de faktorer med betydelse för kommunikationen i och med att jag har berört samtliga tidigare utan tänker istället föra en diskussion kring varför sättet vi väljer att kommunicera på kan påverka kravhanteringsprocessen. Diskussionen förs naturligtvis utifrån en tolkande ställning till resultatet från studien.
När vi pratar med varandra spelar det stor roll huruvida vi känner varandra sedan innan för
att kunna tolka och pejla av budskapet rätt. I en projektgrupp är det inte självklart att alla
aktörer känner varandra vilket får konsekvenser för kommunikationen. Vissa blir naturligt
mer lyhörda för budskapet medan andra intar ett mera selektivt förhållningssätt. Oavsett
hur vi väljer att agera försvåras situationen av att vi inte har någon förförståelse för motsatt
part. Genom att utvecklas tillsammans, som ett team, utvecklar vi även förmågan att kommunicera bättre med varandra. Det tar tid att lära sig pejla av alla latenta signaler men successivt lär vi oss att hantera kommunikationsprocessen bättre och blir mer effektiva.
Jag tolkar det som att undersökningen genererade ett mycket gott underlag för att just diskutera kring kommunikation som en framgångsfaktor i kravhanteringsprocessen. Något jag
upplevde anmärkningsvärt i resultatet var att ingen var benägen att konkret diskutera andra
parters svagheter. Jag tycker det är viktig att även kunna konfrontera andra men det måste
göras på ett delikat och genomtänkt vis. Att ge feedback handlar inte alltid om att prisa och
belöna ibland måste vi också ställ oss ansikte mot ansikte i motsatt avseende. Då är det
centralt att vi vet hur vi ska agera för att göra detta på ett professionellt vis som ger resultat.
Att använda ett jag-budskap erbjuder som Maltén (1998) nämner i sin bok rak återkoppling. Ett jag-budskap talar som sagt om hur jag upplever situationen och de effekter beteendet fått och det beskriver också vilka känslor det väcker hos mig. Ett jag-budskap sårar
inte motpartens självkänsla. Det jag vill återkomma till är att vi får inte vara rädda för att
konfrontera andra då vi anser att det finns underlag för en sådan handling. Då vi diskuterar
påtaglig problematik tror jag det finns stunder då jag-budskapet kan komma till nytta för att
hantera och komma vidare i processen mot en lösning.
Självklart påverkat sättet vi väljer att kommunicera på kravhanteringsprocessen. Det är en
oundviklig faktor som måste hanteras och inte negligeras för att nå bättre, snabbare och
mer hållbara resultat. För att hantera kommunikationen i kravhanteringsprocessen tror jag
det är viktigt att alla känner till hur vi påverkas och vi kan bli påverkade av sättet vi väljer
att kommunicera på. Det måste finnas kunskap om hur vi kan påverka kommunikationsprocessen samt vad det är för yttre faktorer som inverkar. Först när vi är medvetna och berikade med de kunskaper som krävs finns det möjlighet att börja förändra ett beteende som
är felaktigt. Jag tror det ligger i allas natur att vilja förändra det som inte fungerar men det
är svårt är att skapa insikt om att det faktiskt finns ett problem. I många fall tycker vi att allt
fungerar som det ska, d.v.s. vi är självgoda till våra egna prestationer. Det krävs ofta en extern part som kritisk granskar situationen för att verkligen utvärdera nuvarande läge. I
många fall känner vi oss sårade då någon utomstående kritiserar det vi gör men ofta måste
så ske för att komma till botten med problemet. Det är då oerhört viktigt att ta emot feedback på rätt sätt och inte förneka givet faktum. I de fall den homogena gruppen öppnar
upp för nya perspektiv och idéer finns goda möjligheter att förbättra nuvarande situation
till det bättre. Att kunna kommunicera effektivt är så pass avgörande för att kravhanteringsprocessen ska fungera att det inte tål att ignoreras p.g.a. grupptänk, egoism eller andra
faktorer som bidrar till förnekelse.
Kommunikation är något som sker oavbrutet och har således stor inverkan på kravhanteringsprocessen avancemang. Exempelvis är det centralt att en tydlig målbild kommuniceras
52
för att alla ska få en likvärdig vision och förstå vart hän processen leder. Har vi inte förmåga att hantera kommunikationen på ett bra vis kommer garanterat målbilden att se annorlunda ut beroende på vem jag väljer att frågar i gruppen. I en sådan situation är det viktigt
att kommunicera tydligt och med åtanke på vem målgruppen är. Det är också viktigt att ta
ansvar för budskapet varav jag återigen belyser funktionen av feedback. I alla situationer
måste vi vara medvetna om att vi är alla individer med olika förförståelse, kunskap och erfarenhet vilket påverkar vår förmåga att kommunicera och tolka. En intressant teori skriven
av Maltén (1998) är huruvida ofullständiga och dubbla budskap inverkar på samtalet. Att
utelämnar väsentliga delar av ett budskap eller att kommunicera otydliga tolkar jag som två
inte ovanliga felkällor som leder till brister i kravhanteringsprocessen. Jag uppfattade i undersökningen att det finns förväntningar på motpartens kunskaper och erfarenhet. Tyvärr
stämmer inte alltid dessa förväntningar överrens med verkligheten och utelämnar vi då delar av budskapet eller kommunicerar på ett otydligt sätt p.g.a. att vi tror oss veta hur den
andra parten uppfattar ett budskapet är vi illa ute. Jag kan förstärka mitt resonemang genom följande exempel: Person A träffar person B för att diskutera ett ofullständigt krav.
Person A har vissa förväntningar på person B vad gäller kunskap och förståelse för kravet
och i diskussionen utelämnar därav person A information som han betraktar som ”onödig”
och tidsförödande. Person B har emellertid inte alls den förståelse för kravet som person A
tror och situationen sätter därmed käppar i samtalsmaskineriet. För att undvika onödiga
missförstånd av den typ beskriven är det viktigt att vara medveten om vilka konsekvenser
ett visst typ av agerande kan få. I situationer där budskapet som levereras har stor betydelse
är det viktigt att inte ta situationen förgiven eller åsidosätta betydelsefulla aspekter som direkt återkoppling för att säkerställa ett korrekt mottagande av budskapet.
Jag anser att det är oerhört viktigt, om inte i första hand mest betydelsefullt att kunna utnyttja kommunikationen optimalt i en kravhanteringsprocess. Framförallt måste vi kunna
kommunicera kraven mellan de olika aktörer som berörs så att alla uppfattar dem likgiltigt.
Kraven ligger till grund för det som ska utvecklas och måste vara korrekta. Kan vi inte
kommunicera med varandra inom gruppen kan vi heller inte hantera kraven så som krävs
för ett optimalt resultat. Olika krav kommuniceras flertalet gånger under pågående process,
de förändras ibland och ska förankras på nytt. Allt arbete med kravhantering har därav ett
stort beroende till ur väl kommunikationsprocessen fungerar. Det är följaktligen en grundläggande förutsättning att kommunikationen fungerar varav jag tror det är väsentligt att det
tilldelas både tid och resurser för ändamålet. Det är som Dimberly och Burton (1999) omnämner att den som inte kommunicerar återför heller inget till gruppen.
Då kommunikationen fungerar finns det underlag för effektiv kravhantering. Lägg där till
en passande tidsram och ett team sammansatt med eftertanke så har vi början till ett framgångskoncept. Det är i många fall enkla saker som utgör de största problemen och vi tror
helt enkelt att de inte har någon betydelse för processen men det är faktiskt så att de små
skavankerna grundar för de stora skadorna.
53
6
Slutsats
”Kapitlet innehållet en sammanfattning av det som kom fram i analysen och underlaget presenteras överskådligt i punktform för läsaren”.
Mycket talar för att kravhantering i systemutvecklingsprojekt kräver struktur och tydliga rutiner för att fungera. Idag finns flera explicit uttalade problem som antyder på att allt inte
fungera som tänkt varav det är betydelsefullt att omgående försöka hitta lämpliga lösningar.
Dessa bör fortlöpande appliceras, testas och utvärderas för att kontinuerligt nå bättre resultat och nya mål. Nedan följer en väl komprimerad resumé av de slutledningar som genererades i analysen.
•
Analysen talar för att de mest frekvent omnämnda problemen i kravhanteringsprocessen för systemutvecklingsprojekt är :
o En otillräcklig tidsram
o Bristfällig kravspecifikation
o Inkomplett beställarroll
o Bristfällig kommunikation
•
Rimlig tolkning är följaktligen att problem av ovan nämnd karaktär påverkar utfallet
av kravhanteringsprocessen. För att komma tillrätta med problematiken krävs
lämpliga åtgärder som kan kontrollera både orsak och konsekvens för att nå en heltäckande, optimal och bestående lösning utan risk för bakslag.
•
Det mesta talar dessutom för att kravhantering bör ske i ett iterativt arbetsmönster.
På så vis skulle det vara möjligt att tidsoptimera processen samtidigt som sannolikheten att kunna leverera funktionalitet som stämmer överrens med behovet skulle
öka.
•
Alla inblandade parter måste förstå kravhanteringsprocessens relevans och betydelse för resultatet för att kunna reducera befintlig problemnivå. Eftersom kunskap
och erfarenhet varierar inom den homogena gruppen är det rimligt att tolka nuvarande situation som ostabil men genom att arbeta fram unison förståelsen för problematiken ökar också chansen för att finna en eller flera bra lösningar.
•
Ännu en rimlig förklaring är att det är en alltför stor utmaning att beskriva behovet
korrekt under de bristfälliga förhållanden som råder idag. Mycket talar för att det
krävs tydligare ansvar för att generar bättre förutsättning att dokumentera och förvalta kraven optimalt. Nya rutiner som explicit uttrycker vad som förväntas är ett
eftersträvansvärt komplement till de riktlinjer som redan finns dokumenterade för
själva genomförandet.
•
Dessutom är en sannolik slutsats den att systemutvecklingsprojekt överlag behöver
mogna för att kravhanteringsprocessen ska få utrymme att utvecklas med full kapacitet.
•
Det mesta talar för att det är kommunikation som skapar förutsättning för samarbete. Därför är en rimlig tolkning att fungerar kommunikationen ökar premisserna
för att kravhanteringen ska resultera i det som förväntas. Förmågan att kunna
kommunicera inom teamet har stor betydelse och mycket indikerar på att det är
nödvändigt att kunna anpassa budskapet, lyssna aktivt och återkoppla för att inte
hindra avancemanget i kravhanteringsprocessen.
54
7
Reflektion
”Det avslutande kapitlet kastar ljus på uppsatsen i helhet och styr läsaren mot ett avslut i realiserad
forskning”.
7.1
Metodkritik
Så här i efterhand finns det en del tankar och funderingar kring metodiken som präglat
forskningsansatsen vilka jag kommer att dela med mig av i följande kapiteldel.
Vi tar allt från början och startar med valet av vetenskaplig ansats. Som bekant använde jag
ett hermeneutiskt vetenskapligt förhållningssätt som reflekterar uppsatsen. Jag känner mig
nu i efterhand fortfarande trygg med valet och anser att jag har funnit och kunna dokumentera en djupare förståelse för problematiken. Det känns heller inte som att min förförståelse för ämnesområdet har färgat uppsatsens olika delresultat på ett missgynnande sätt. Hade
jag istället valt att angripa problemet ur ett positivistisk perspektiv kanske mottagaren hade
upplevd resultatet mindre diffust då ett positivistiskt förhållningssättet speglar mer mätbar
och explicit fakta.
För att samla data till undersökningen använde jag två olika datasamlingsmetoder, litteraturstudier och kvalitativa intervjuer. Jag upplever att dessa metoder passade undersökning i
uppsatsen väl och genererade ett resultat enligt förväntan. Tidigt i processen då uppsatsen
tog form funderade jag en hel del på att även komplettera med en tredje datasamlingsmetod, nämligen observationer. Jag kände då att det kunde vara lämpligt att även iaktta kravhanteringsprocessen i ett reellt tillstånd för att samla kompletterande fakta att slutleda utifrån. Jag valde emellertid bort att observera med motiveringen att risken var för stor att
tolka fenomenet felaktigt då ingen direkt feedback skulle vara möjlig i den typen av datasamlingsmetod. Jag anser att det är viktigt att som hermeneutiker göra antagande i mer
kontrollerade förhållanden och valde slutligen enbart de två förstnämnda datasamlingsmetoderna.
Jag skulle istället vilja ställa mig granskande till hur resultatet skulle påverkats rent kvalitativt
om exempelvis strukturen på intervjuguiden varit mer strukturerad. Med facit i hand tror
jag det skulle ha genererat ett enklare resultat att analysera men inte högre reliabilitet då informationen som framgick faktisk var replikerbar om än mer personligt präglad i sin uttrycksform. Det finns även evidenta bevis i vald referensram för den fakta som framgick i
studien som påvisar resultatets reliabilitet. Dock visade det sig vara något enklare att mäta
resultatets validitet i och med att jag genomförde en kvalitativstudie. Genom att göra olika
intervjuer med ett urval av respondenter som representerar lämpliga källor för undersökt
fenomen påvisar forskningsprocessen en trovärdig tolkning av studerad problematik. Troligtvis hade jag kunnat göra analysen ännu mer valid genom att använda fler argument för
mitt sätt att tolka. Jag anser dock inte att detta har påverkat den slutliga produktens kvalitet
då jag har varit noga med att använda gemensamma variabler i undersökningen. En positivistisk ansats hade troligtvis underlättat för att demonstrera dessa två kvalitets begrepp då
den hermeneutiska ansatsen i många fall försvårar för att påvisa variablernas fullständighet.
Genomgående är jag nöjd med valet av metod men inser självklart att det mest optimala vägvalet inte är påträffat ännu. Att kontinuerligt överväga nya vägval är en viktig del för att nå
nya och kanske till och med bättre resultat. Uppsatsens framställning är enligt min mening en
iterativ process som sällan kan betraktas som ”klar” då det alltid finns möjlighet att prestera
bättre så länge det finns ett driv. Det resultat som jag levererar här och nu representerar så
långt som jag har kommit i forskningen och som vald metod tillåtit mig att gå. En annan metodik hade förmodligen lotsat oss en annan väg men sannolikt mot ett synonymt resultat.
55
7.2
Förslag till fortsatt forskning
Det finns goda förutsättningar till fortsatt forskning inom aktuellt ämnesområde för uppsatsen. Framförallt betraktar jag systemutveckling i sin helhet som ett hett forskningsobjekt
då det är påvisat mycket svårt att lyckas med denna genre av projekt. Kravhantering i systemutvecklingsprojekt har dessutom en märkbar roll för slutresultatet vilket gör det intressant att fortsätta forska inom. Just att hitta nya rutiner för processen för att undvika gamla
fällor tror jag är en inkörsport till fortsatt forskning liksom det är relevant att forska vidare
på åtgärder som både löser orsaken till problemet samt dess konsekvenser.
Det finns en hel del litteratur som behandlar hur kravhantering ska gå till men desto färre
litterära verk behandlar det faktum som råder. Att teori och praktik inte överrensstämmer
är ett verkligt förhållande men ingen har lyckat att dokumentera det som vi söker svar på.
Vad är det egentligen för faktorer som påverkar kravhanteringen i systemutvecklingsprojekt? Mitt bidrag till forskningen är bara början på ett otroligt intressant och absolut nödvändig forskningsinsatts. Det finns mängder av företag som ställer sig frågande till varför
deras systemutvecklingsprojekt sällan överrensstämmer med de förväntningar som finns.
Det finns således tonvis med fakta att undersöka och analysera för att lösa gåtan hur man
lyckas med kravhantering. Att applicera en bredare referensram för att utöka och bredda
analysen är förslagsvis ett steg i forskningsprocessen. Därtill är det intressant att involvera
fler respondenter, andra metoder m.m. för att fånga fler aspekter av undersökt fenomen.
För att driva forskningen vidare är det nödvändigt att arbeta iterativ och utnyttja tidigare
liknade erfarenheter för att nå nya bättre resultat. Jag tror framförallt att det är viktigt att
söka efter de mest grundläggande faktorer som styr kravhanteringen, förankra dessa och
utvärdera dess betydelse i sammanhanget. Att applicera elementära teorier öppnar sinnet
för nya tankar och idéer kring problematiken. Forskningen ska inte bygga på komplicerade
premisser då det sällan är dem som styr det verkliga utfallet. Förslagsvis bör vi fortsätta att
undersöka grundläggande orsaker och successivt arbeta fram heltäckande åtgärder som
medför total kontroll och ett fläckfritt resultat.
Det är svårt att ge konkreta förslag på var forskningen bör ta vid härnäst men jag hoppas
att utifrån diskussionen gett indikation på lämpliga idéer för efterforskning.
7.3
Eftertanke
Jag har fram tills nu fått dela med mig utav många tankar kring uppsatsämnet och önskar
egentligen bara att få göra ett kort komplement för att som det brukar heta ”knyta samman
säcken”.
Kravhantering i systemutvecklingsprojekt och problematiken upplevd där kring är ett ämnesområde som i hög grad har fångat mitt intresse. Jag anser att det finns stora möjligheter
att genom fortsatt forskning skapa nya och bättre förutsättningar för att lyckas. Jag känner
mig både trygg och stolt över resultatet som levereras och hoppas att mitt bidrag skall
komma till användning. Det har varit oerhört kul och lärorikt att skriva uppsatsen. Att få ta
del av så mycket ny kunskap har gett mersmak och jag kommer sannolikt när tillfälle ges
fortsätta att studera ämnet.
56
Litteraturförteckning
Litteratur referenser
Björklund, M. & Paulsson, U. (2003). Seminarieboken, att skriva, presentera och opponera. Lund:
Studentlitteratur
Dimberly, R. & Burton, G. (1999). Kommunikation är mer än bara ord. Lund: Studentlitteratur
Eklund, S. (2002). Arbeta i projekt. Lund: Studentlitteratur
Eriksson, U. (2007). Kravhanterings för IT-system. Lund: Studentlitteratur
Gulliksen, J. & Göransson, B. (2002). Användarcentrerad systemdesign. Lund: Studentlitteratur
Holme, I. M. & Solvang, B. K. (1997). Forskningsmetodlik. Om kvalitativa och kvantitativa metoder. Lund: Studentlitteratur
Larsen, R-P. (2003). Teamutveckling. Lund: Studentlitteratur
Maltén, A. (1998). Kommunikation och konflikthantering. Lund: Studentlitteratur
Olsson, H & Sörensen, S. (2007). Forskningsprocessen: Kvalitativa och kvantitativa perspektiv.
Stockholm: Liber
Patel, R. & Davidson, B. (2003). Forskningsmetodikens grunder. Att planera, genomföra och rapportera en undersökning. Lund: Studentlitteratur
Ricciardi, M. R. & Schaller, J. (2005). Projektpsykologi. Lund: Studentlitteratur
Thurén, T. (1991). Vetenskapsteori för nybörjare. Stockholm: Liber
Thurén, T. (2005). Källkritik. Stockholm: Liber
Vetenskapligartiklar
Reynolds, P. (2006). Managing requirements for a US$1bn IT-based business transformation: New
approaches and challenges. The Journal of systems and Software 80 (2007) p. 285-293.
Pozgaj, Z., Sertic, H. & Boban, M. (2003). Effective requirement specification as a precondition for
succesful software development project. 25th Int. Cont. Information Technology Interfaces ITI
(2003) p. 669 – 674.
Niazi, M. & Shastry, S. (2003). Role of Requirement Engineering in Software Development Process:
An Emperical Study. Proceedings IEEE INMIC (2003) p. 402 –407.
57
Internet referenser
Luleå Komvux (2006). Att vara källkritisk. Hämtad 2007-12-11,
http://www.edu.lulea.se/komvux/so/kunskap/att_vara_kallkritisk.htm
från
Skolverket
(2007).
Analysmodell.
Hämtad
2007-10-22,
http://www.skolverket.se/content/1/c4/21/71/analysmodell.pdf
från
Svenska Handelshögskolan (2007). Forskningsmetoder. Hämtad 2007-10-11, från
http://brunnen.shh.fi/portals/studymaterial/20062007/helsingfors/foretagsledningochorganisation/2235/material/handouts/fore9_2006_w
ille.ppt
Företagsmaterial
Affektor Utveckling AB (2007). FIRO (Gruppen och Ledaren, dokument 12:1). [Deltagarmateriel]. Halmstad: Affektor Utveckling AB
58
Bilaga 1 Intervjuguide
Strukturerad intervju med öppen frågeställning
Block 1: Kravhanteringsprocessen
Systemutveckling sker idag under stor press och kräver resultat som levereras i rätt tid, med
rätt kvalitet och inom budget. För att möta dess villkor krävs en effektiv kravhanteringsprocess.
1. Förklara den generella problematik du upplever i kravhanteringsprocessen och hur
den påverkar arbetet.
2. Vad är det som brister i praktiken då det rent teoretiskt är påvisat och möjligt att nå
ett fullständigt resultat?
a. Relatera till konkreta faktorer som du upplever i kravhanteringsprocessen.
b. Motivera orsak och samband
3. Resultatet av kravhanteringsprocessen motsvarar sällan de förväntningar som finns,
varför?
a. Relatera dessutom till hur förhållandet mellan IT-aktören och verksamheten
kan påverka situationen.
Block 2: Teamet
Teamet har en väsentlig roll i kravhanteringsprocessen. Tillsammans ska en grupp av individer med olika förutsättning driva processen mot ett specificerat mål varav teamets mognad har stor betydelse för dess effektivitet.
1. Återge din generella tolkning av teamets roll i kravhanteringsprocessen.
2. Teamet som påverkande faktor i kravhanteringsprocessen grundar för en djupare
förståelse. Har teamet enligt din mening någon betydelse för kravhanteringsprocessens framgång?
a. Redogöra för ditt svar i relation till konkreta faktorer som påverkar processen?
b. Motivera orsak och samband.
Block 3: Kommunikation
”Jag vet att du tror att du förstår vad du tror att jag sa, men jag är inte säker på att du har fattat att det
du hörde, inte var det jag menade” (Anonym källa).
I samspelet mellan människor spelar kommunikation en avgörande roll men det finns flera
felkällor i mänsklig kommunikation som påverkar resultatet. I kravhanteringsprocessen har
således kommunikation en avgörande betydelse för processens framgång.
59
1. Vad har du för generell tolkning av begreppet kommunikation som en påverkande
faktor i kravhanteringsprocessen.
2. Genom att kommunicera överför vi budskap och tar emot information. Har sättet
vi kommunicerar på någon betydelse för kravhanteringsprocessen?
a. Vad är det för kommunikationsaspekter som påverkar processen samt vilka
orsaker och samband finns att urskilja?
Ett stort tack för din medverkan i studien Din delaktighet ska skapa underlag för förändringsmöjligheter och bättre förutsättningar för effektivare kravhantering.
Väl mött
Jessika Svensson
60
Matematiska och systemtekniska institutionen
SE-351 95 Växjö
Tel. +46 (0)470 70 80 00, fax +46 (0)470 840 04
http://www.vxu.se/msi/
