Samspelet mellan projektledare och utvecklingsmetod – Interaction

Teknik och samhälle
Datavetenskap
Examensarbete
15 högskolepoäng, grundnivå
Samspelet mellan projektledare och utvecklingsmetod –
En litteraturstudie inom området mjukvaruutveckling
Interaction between project manager and development method A literature review in the area of software development
Författare: My Binh Vuong
Examen: Kandidatexamen 180 hp
Handledare: Kristina Allder
Huvudämne: Datavetenskap
Examinator: Mia Persson
Program: Data och telekom
Datum för slutseminarium: 2014-08-28
Sammanfattning
En stor del av mjukvaruutveckling sker idag i projektform och projektledaren spelar en viktig
roll i ett projekt. Projektledaren har det största ansvaret för projektet och leder sitt
utvecklingsteam mot målet för projektet. Inom området för mjukvaruutveckling har olika
utvecklingsmetoder skapats för att hantera projekt och projektledning. Inom området skiljer
man generellt mellan traditionella och agila utvecklingsmetoder. De agila
utvecklingsmetoderna introducerades för att eliminera brister hos de traditionella
utvecklingsmetoderna. I de traditionella utvecklingsmetoderna är det nödvändigt att vara
medveten om samtliga krav inom projektet från början medan de agila metoderna är mer
flexibla i förhållande till kravinsamling.
Ämnesområdena projektledning och utvecklingsmetoder inom projektarbete diskuteras
vanligen var för sig i skilda kontexter och betraktas därför ofta som oberoende av varandra.
Forskning påvisar att många mjukvaruprojekt misslyckas på grund av bristande
projektledning. Därför är det nödvändigt att projektledaren besitter ett antal egenskaper som
identifierats som avgörande för att leda framgångsrika projekt. Genom den litteraturstudie
som gjorts har fyra kritiska egenskaper hos projektledaren identifierats: relationsförmåga,
personlighet, kompetenser och kommunikationsförmåga. Även om projektledaren besitter
dessa beskaffenheter betyder det inte att projektet i sig lyckas. Utvecklingsmetoden för
projektet är också en avgörande faktor för att skapa framgångsrika projekt. Val av
utvecklingsmetod i samband med projektledarens egenskaper skapar således olika
förutsättningar för projektets framgång. Resultatet som framkommit av denna studie påvisar
att dessa två ämnen i hög grad är beroende av varandra. Studien visar också att
projektledarens beskaffenheter många gånger är helt avgörande vid tillämpning av
traditionella utvecklingsmetoder. Projektledarens egenskaper är också aktuella vid arbete
med agila utvecklingsmetoder men inte i samma utsträckning som för traditionella
utvecklingsmetoder.
Nyckelord: Projektledare, projektledning, utvecklingsmetoder, mjukvaruutveckling,
mjukvaruutvecklingsprojekt, utvecklingsteam.
Abstract
A large part of software development today is conducted in the form of projects and the project
manager plays an important role in a project. The project manager has the largest responsibility and leads the development team towards the goal of the project. In the area of software
development different development methodologies have been created for project management.
One generally distinguishes between traditional and agile development methodologies. The
agile development methods were originally introduced to eliminate the shortcomings of the
traditional development methods. With traditional methods it is necessary to be aware of all
the requirements for the project from the start while the agile methods are more flexible with
regard to requirements elicitation.
Disciplines of project management and development methodologies in a project are usually
discussed separately in different contexts, and are therefore often regarded as independent of
each other. Research shows that many software projects fail due to deficiencies in the project
management. It is consequently necessary that the manager possesses a number of properties
that have been identified as critical for managing successful projects. This study identified
four key characteristics of the project manager: relationship ability, personality, competence
and communication skills. Even if the project manager possesses these traits or capacities it
does not mean the project itself is or will be successful. The development methodology for the
project is also a crucial factor in the process of creating successful projects. The choice of development method in conjunction with the project manager’s characteristics creates different
conditions for success of the project. The results that emerged from this study demonstrates
that these two subjects are highly interdependent. The study also demonstrates that the project manager's characteristics are often crucial in the application of traditional development
methods. The project manager's characteristics are also relevant when working with agile development but not to the same extent as for traditional methods.
Keywords: Project manager, project management, development methods, software
development, software development project, development team.
Innehållsförteckning
1. Inledning ......................................................................................................................................... 1
1.1. Bakgrund ................................................................................................................................... 1
1.2. Problemdiskussion .................................................................................................................... 2
1.3. Syfte och identifierade frågeställningar .................................................................................... 3
1.4. Avgränsning .............................................................................................................................. 3
2. Metod............................................................................................................................................... 4
2.1. Hermeneutik .............................................................................................................................. 4
2.2. Forskningsstrategi och datainsamlingsmetod ........................................................................... 4
2.2.1. Litteraturstudie till frågeställning 1.................................................................................... 4
2.2.2. Litteraturstudie till frågeställning 2.................................................................................... 7
2.3. Källkritik ................................................................................................................................... 8
2.4. Metoddiskussion ....................................................................................................................... 8
3. Teoretisk referensram .................................................................................................................. 10
3.1. Projekt ..................................................................................................................................... 10
3.2. Introduktion till traditionella och agila utvecklingsmetoder ................................................... 11
3.3 Vattenfallsmodellen .................................................................................................................. 11
3.3. Rational Unified Process ......................................................................................................... 13
3.4. Spiralmodell ............................................................................................................................ 15
3.5. Scrum ...................................................................................................................................... 16
3.6. Extreme Programming ............................................................................................................ 18
3.7. Dynamic Systems Development Method ................................................................................ 19
4. Resultat ......................................................................................................................................... 22
4.1. Relationsförmåga .................................................................................................................... 22
4.2. Personlighet ............................................................................................................................. 23
4.3. Kompetens .............................................................................................................................. 24
4.4. Kommunikationsförmåga........................................................................................................ 25
4.5. Diskussion av resultatet .......................................................................................................... 26
5. Analys ............................................................................................................................................ 28
5.1. Vattenfallsmodellen ................................................................................................................. 28
5.1.1. Relationsförmåga ............................................................................................................. 28
5.1.2. Personlighet ...................................................................................................................... 28
5.1.3. Kompetens ....................................................................................................................... 28
5.1.4. Kommunikationsförmåga................................................................................................. 29
5.2. RUP ......................................................................................................................................... 29
5.2.1. Relationsförmåga ............................................................................................................. 29
5.2.2. Personlighet ...................................................................................................................... 29
5.2.3. Kompetens ....................................................................................................................... 29
5.2.4. Kommunikationsförmåga................................................................................................. 30
5.3. Spiralmodellen ........................................................................................................................ 30
5.3.1. Relationsförmåga ............................................................................................................. 30
5.3.2. Personlighet ...................................................................................................................... 30
5.3.3. Kompetens ....................................................................................................................... 30
5.3.4. Kommunikationsförmåga................................................................................................. 31
5.4. Scrum ...................................................................................................................................... 31
5.4.1. Relationsförmåga ............................................................................................................. 31
5.4.2. Personlighet ...................................................................................................................... 31
5.4.3. Kompetens ....................................................................................................................... 31
5.4.4. Kommunikationsförmåga................................................................................................. 32
5.5. XP............................................................................................................................................ 32
5.5.1. Relationsförmåga ............................................................................................................. 32
5.5.2. Personlighet ...................................................................................................................... 32
5.5.3. Kompetens ....................................................................................................................... 32
5.5.4. Kommunikationsförmåga................................................................................................. 33
5.6. DSDM ..................................................................................................................................... 33
5.6.1. Relationsförmåga ............................................................................................................. 33
5.6.2. Personlighet ...................................................................................................................... 33
5.6.3. Kompetens ....................................................................................................................... 33
5.6.4. Kommunikationsförmåga................................................................................................. 33
6. Slutsats .......................................................................................................................................... 35
7. Vidare forskning ........................................................................................................................... 37
Källförteckning................................................................................................................................. 38
Figurförteckning
Figur 1: Projektmodell som visar projektets livscykel ...................................................................... 11
Figur 2: Illustration på Vattenfallsmodellen faser .............................................................................. 13
Figur 3: RUPs olika faser och discipliner .......................................................................................... 15
Figur 4: Spiralmodellens olika varv och faser ................................................................................... 16
Figur 5: Scrum processen ................................................................................................................... 17
Figur 6: XPs tolv tillämpningar ......................................................................................................... 19
Figur 7: DSDM processen.................................................................................................................. 21
Figur 8: Dessa fyra egenskaper kännetecknar en framgångsrik projektledare .................................. 26
Tabellförteckning
Tabell 1: Sammanfattning av sökresultat och filtrering ACM ............................................................. 5
Tabell 2: Sammanfattning av sökresultat och filtrering IEEE ............................................................. 6
Tabell 3: Sammanfattning av sökresultat och filtrering ACM ............................................................. 7
Tabell 4: Sammanfattning av sökresultat och filtrering IEEE ............................................................. 7
Tabell 5: Visar om det är stor eller liten påverkan som framgångsrika projektledares egenskaper har
på de olika utvecklingsmetoderna ...................................................................................................... 35
1. Inledning
I detta inledande kapitel beskrivs bakgrunden till projektledning samt ett urval av
traditionella och agila utvecklingsmetoder. Därefter följer en problemdiskussion som mynnar
ut i två frågeställningar. Även syftet med uppsatsen och avgränsningen för denna presenteras.
1.1. Bakgrund
Projektledning är idag ett högaktuellt område som är under intensiv utveckling och som ofta
berör hela organisationen (Tonnquist 2007). I de flesta organisationer, oavsett bransch, finns
det någon form av projektledning. En allmänt vedertagen definition av begreppet
projektledning är:
”Tillämpningen av kunskaper, färdigheter, verktyg och metoder på projektaktiviteter i
syfte att motsvara projektkraven” (LTH, u.å, s 6).
Ett välbekant och aktuellt begrepp inom projektledning är den så kallade projektledarrollen.
Bakka, Fivelsdal & Lindkvist (2006) menar att projektledare ofta är en person som styr och
vägleder ett projektarbete. Enligt Hughes & Cotterell (2009) är projektledarskap inom
mjukvaruutveckling annorlunda än projektledarskap för andra projekt. Planering,
övervakning och kontroll är tre nyckelord för en projektledare inom mjukvaruprojekt. Ett
mjukvaruprojekt måste tillfredsställa riktiga behov och det är projektledares ansvar att
identifiera projektets intressenter och mål. En framgångsrik projektledare har ett autentiskt
intresse för människor och vet hur man får medarbetare att vilja komma till jobbet varje dag.
Detta innebär även att en projektledare behöver agera och fungera som en coach för
utvecklingsteamet och se varje individs styrkor och svagheter. Projektledaren tillsammans
med beställaren är de viktigaste rollerna i ett projekt, tillsammans utgör de projektets kärna.
Tonnquist (2007) menar att en projektledares huvuduppgift är att leda utvecklingsteamet som
ska leverera ett resultat till beställaren. Därför bör en projektledare känna till sina
arbetsuppgifter för att kunna effektivisera projektarbetet.
Genomförandet av ett mjukvaruprojekt tillämpar vanligtvis någon välkänd utvecklingsmetod.
Det finns huvudsakligen två grupper av utvecklingsmetoder som används inom
mjukvaruutveckling, de traditionella och de agila utvecklingsmetoderna (Rehman et al. 2010).
Traditionella utvecklingsmetoder och arbetsätt som används idag kommer från det kalla
krigets dagar. Syftet med metoderna var att nå försvarsprojekt innan motståndaren. De
verktyg som togs fram användes för att koordinera och minska ledtiden av ett projekt. Ledtid
är den tid det tar från att påbörja ett projekt till att avsluta det. Att administrera och
kordinera så många aktiviteter som möjligt var syftet. Ju fler aktiviter som kunde hanteras
desto kortare kunde ledtiden bli för projektet. Traditionella utvecklingsmetoder är
ofta ”dokumenttunga”, d.v.s. att projektet noga ska dokumenteras under projektets ledtid
(Gustavsson 2013).
Agile är det engelska ordet för smidig eller rörlig. Översättning av ordet agile till svenska har
blivit ”lättrörlig” (Gustavsson 2013). Mjukvaruutvecklingsarbete beskrivs ofta som ett
komplext arbetsområde, framförallt inom IT-projekt. Grundtankarna bakom agil utveckling
finns i det så kallade agil manifestot:




Individer och interaktion framför processer och verktyg.
Fungerande programvara framför omfattade dokumentation.
Kundsamarbete framför kontraktsförhandling.
Anpassning till förändring framför att följa en plan (Agilemanifestor, 2014).
1
Arbetet bedrivs inkrementellt och iterativt vilket innebär att regelbundna små leveranser
sker löpande till kunden. Ändringar kan snabbt ske för att möta nya krav och önskemål
(Gustavsson 2013). När man arbetar med agila metoder eftersträvar man att arbeta på ett
smidigt, flexibelt och lättrörligt sätt (Schwaber 2004). Gustavsson (2013) menar att det finns
tre argument för att arbeta agilt:

Nytta per krona - det viktigaste görs först. Att arbeta med det som ger störst nytta för
kunden ger också mest värde per krona. Leverans sker löpande så att kunden kan få
möjlighet att ändra och påverka sina krav.

Flexibilitet - förändringar är välkomna. Efter varje iteration får kunden resultatet
presenterat med möjlighet att ge återkoppling och möjlighet att ändra projektets
planering inom givna ramar.

Tydlighet - transparens finns genom hela projektet. Projektet följs upp dagligen vilket
gör att det kan följas och spåras på ett enkelt sätt. Detta skapar trygghet och
motivation för såväl kunden som projektledaren och utvecklingsteamet.
1.2. Problemdiskussion
Taylor & Woelfer (2009) menar att många företag investerar i utvecklingen av sina
projektledare med förväntan att projekt ska bli lyckade. I en rapport från Sveriges kommuner
och Landsting från 2008 är det färre än 10 % av alla mjukvaruutvecklingsprojekt som har
karakteriserats som lyckade (Kontract, 2013). En rapport från Standish Group som
undersöker trender i mjukvaruprojekt rapporterar upprepande oroande statistik för
branschen. Rapporten från 2011 visar att 37% av alla mjukvaruprojekt lyckades att leverera i
tid, inom budget och med alla nödvändliga funktioner. 42% av projekten levererades sent, gick
över budget och/eller levererades med mindre än begärda egenskaper och funktioner.
Resterande 21% ansågs vara fullständigt misslyckade på grund av annullering före leverans
eller att mjukvaran aldrig användes efter färdigställande (Quotient, 2012).
Sommerville (2010) menar att ett gott projektledarskap inom mjukvaruutveckling är särskilt
utmanade på grund av följande faktorer:



Produkter är immateriella. Produkter är inte synliga, det kan varken röras eller
ses.
Projektledare kan inte se framsteg genom att bara titta på den artefakt som är
under utveckling.
Lärdomar från tidigare projekt kan inte överföras till nya projekt eftersom alla
projekt är olika.
På grund av dessa faktorer är det inte överraskande att mjukvaruprojekt inte möter deadlines
och överstiger budget. Orsaken till misslyckade projekt är ofta dålig projektledning enligt
Hughes & Cotterell (2009). Hantering av utvecklingsteam inom mjukvaruutveckling är en
komplicerad uppgift för en projektledare. Komplexit uppstår på grund av att projekt ofta har
begränsade resurser. Det förekommer även distribuerade grupper som kräver lämpliga, vilket
ytterligare komplicerar uppgiften (Bohner, McCrickard & Smith 2005).
Det globala datorföretaget IBM undersökte orsakerna till varför IT-projekt misslyckas och
identifierade fem nyckelområden som påverkar huruvida projekt kan anses vara lyckade eller
misslyckande. De fem nyckelområdena är:


Projektledning (54%)
Affärer (21%)
2



Människor (14%)
Metod (8%)
Teknisk (3%)
Första punkten ovan, projektledning (54%), visar att mer än hälften av projekten i studien
misslyckas på grund av bristande projektledning. Undersökningen visar att projektledning
har stort inflytande på om ett projekt lyckas eller misslyckas (Quotient, 2012).
I början av 1960-talet fanns det ett antal modeller som idag betraktas som de traditionella
utvecklingsmetoderna t.ex. Vattenfallsmodellen, Spiralmodellen och olika inkrementella
modeller. Dessa modeller uppvisar både starka och svaga sidor och utgår från att man har
fullkomlig förståelse av kraven i det första stadiet av utvecklingsprocessen. Detta innebär
svårigheter eftersom de flesta kunder inte vet vad de vill ha från början (Bandinelli et al.
1995). Därför introducerades en ny grupp av metoder under 1980-talet, som betraktas som
agila metoder, för att eliminera bristerna i de traditionella metoderna. Rehman et al. (2010)
menar att agila metoder inte är tillräckligt för att eliminera de brister som finns hos de
traditionella metoderna. Det menar även att projektledning är ett av de viktigaste områdena
inom mjukvaruutveckling och att projektledning har en mycket viktig roll i såväl traditionella
och agila sammanhang. Utan rätt projektledning är det omöjligt att leverera ett bra resultat,
oavsett om det är traditionella eller agila metoder som används under utvecklingen (Rehman
et al. 2010).
1.3. Syfte och identifierade frågeställningar
Syftet med denna uppsats är att undersöka hur tillämpningen av de olika
utvecklingsmetoderna inom mjukvaruutveckling samspelar med de egenskaper som
kännetecknar en framgångsrik projektledare och således hur det kommer att påverka
projektets resultat. För att kunna uppnå det ovannämnda syftet med uppsatsen behöver
följande två frågeställningar besvaras:
Frågeställning 1: Vilka egenskaper kännetecknar en framgångsrik projektledare?
Frågeställning 2: Hur samspelar egenskaperna identifierade i frågeställning 1 med
utvecklingsmetoder för mjukvaruutveckling?
Med definitionen av ordet samspel i detta sammanhang avses hur de egenskaper som
kännetecknar en framgångsrik projektledare påverkar de olika utvecklingsmetoderna.
1.4. Avgränsning
Projektledning är ett stort område som finns i de flesta branscher. Därför har uppsatsen
avgränsats till att endast undersöka projektledarskap inom mjukvaruutveckling. Inom de
agila utvecklingsmetoder kommer Scrum, Extreme Programming och Dynamic Systems
Development Method att undersökas. Inom de traditionella utvecklingsmetoderna kommer
Vattenfallsmodellen, Rational Unified Process och Spiralmodellen att undersökas. Urvalet
motiveras i teoretisk referensramavsnittet.
3
2. Metod
Detta metodavsnitt presenterar tillvägagångssättet for uppsatsen. Vilket synsätt som har legat
till grund för arbetet, vilken forskningsstrategi som har använts samt hur datainsamlingen
har skett. Kapitlet avslutas med en källkritik och en metoddiskussion där författaren
diskuterar varför den valda metoden har använts och vilka fördelar och nackdelar det finns
med metodvalet.
2.1. Hermeneutik
Denna uppsats utgår från en hermeneutisk forskningsmetod i form av insamling av material.
Hermeneutik betyder ungefär tolkningslära och är en vetenskaplig inriktning där man
studerar, tolkar och försöker förstå grundbetingelserna för det insamlade materialet (Patel &
Davidson 2011). Enligt Bryman (2011) är syftet med en hermeneutisk metod att genom analys
av det insamlade materialet försöka få fram textens mening utifrån upphovsmannens
perspektiv. Detta har även varit grundvalet av synsätt för denna uppsats. Det är nödvändigt
att förstå helheten och sträva efter att förstå textens objektivitet för att kunna dra slutsatser
utan att generalisera.
2.2. Forskningsstrategi och datainsamlingsmetod
Kvantitativ och kvalitativ metod är två undersökningsmetoder som brukar användas inom
forskning. Kvantitativ data är mätbar och kan uttryckas i siffror och tal eller andra
mängdtermer menar Halvorsen (1992). Kvantitativ forskning kan betraktas som en
forskningsstrategi som betonar kvantifiering när det gäller insamling och analys av data
medan kvalitativ forskning vanligtvis lägger vikt vid ord under insamlingen och analysen av
data. Eliasson (2013) menar att kvantitativa metoder passar bra för att göra generaliseringar
medan kvalitativa metoder däremot passar bra för att tränga in på djupet i en frågeställning.
I denna studie tillämpas den kvalitativa metod som Marshall & Rossman (2010) betecknar
som Analys av dokument och material. En kvalitativ metod är mest lämpad för denna uppsats
då syftet med uppsatsen är att få en djupare förståelse för ämnet.
Primärdata och sekundärdata är de två typer av data som man bruka skilja mellan.
Primärdata är ny data som forskaren själv samlar in genom att använda sig av en eller flera
datasamlingsmetoder (Halvorsen 1992). Primära källor kan ofta innehålla nytt tänkande, nya
upptäckter eller ny information. Sekundärdata är data som redan existerar och som någon
annan samlat in. Bryman (2013) menar att en sekundäranalys har ofta flera fördelar för en
student som ska göra ett större eller mindre projekt. Det kan vara ett bra metodiskt val
eftersom man på så sätt får mer tid till analys och tolkningen av informationen.
Datainsamling i denna uppsats är från sekundärdata och har skett genom en litteraturstudie.
2.2.1. Litteraturstudie till frågeställning 1
För att kunna besvara frågeställning 1 har ACMs och IEEEs databaser använts eftersom
dessa två databaser är inriktad mot teknik och datavetenskap. De huvudsakliga söktermer
som använts för att kunna besvara vad som kännetecknar en framgångsrik projektledare är:



Software project management
Project leadership
Successful project leadership
4







Successful project management
Project management failure
Good project management
Good project leadership
Bad project management
Bad project leadership
Management skills
Dessa söktermer har kombinerats för att hitta relevanta källor. Nedan följer en tabell av hur
artiklarna har sållats för att se vilka artiklar som bidrar till att besvara frågeställning 1.
Samtliga söktermer har används i samtliga två databaser för att kunna värdera om de olika
databaserna ger samma sökresultat. Söktermer som har använts är:
S1: Software project management OR software project leadership AND managing people.
S2: Successful project management software OR Successful project leadership AND people.
S3: Project management failure OR project leadership failure AND people.
S4: Good project management OR good project leadership AND software.
S5: Bad project management OR Bad project leadership AND software
S6: Project management skills OR project leadership skills AND people.
Tabell 1: Sammanfattning av sökresultat och filtrering ACM.
ACM
Efter titel
Efter abstrakt
Efter artikeln
S1
99
26
12
2
S2
89
22
10
0
S3
2
1
1
1
S4
218
36
14
0
S5
63
21
6
2
S6
201
32
16
5
Relevant: 10
Nedan följer en lista på de relevanta artiklarna:







Raccoon, L.B.S. 2006. A Leadership Primer for Software Engineers.
Keretho, S., Lent, B & Pinkowska, M. 2011. Process Based Identification of Software
Project Manager Soft Skills
Chen, P., Chen, C & Chern, C. 2012. Software project team characteristics and team
performance: Team motivation as a moderator.
Gao, J & Ma, H. 2009. A Research On the Construction of Team Leadership
Effectiveness and its relationship with Big-five Personality.
Li, F & Wang, Y. 2009. How does project managers´personality matter?: building the
linkage between project managers´ personality and the success of software
development projects.
Howard, A. 2001. Software Engineering Project Management.
Jalil, Zunera & Shahid, A. 2008. Is Non Technical Person A Better Software Project
Manager.
5



Creighton, W. J. 1990. Managing Technical Staff.
Judge, T & Bono, J. 2000. Five-factor model of personality and transformational
leadership.
Eisenberg, H. & Graziano, W. 1997. Agreeableness: A dimension of personality.
Tabell 2: Sammanfattning av sökresultat och filtrering IEEE.
IEEE
Efter titel
Efter abstrakt
Efter artikeln
S1
84
31
11
2
S2
66
22
9
2
S3
53
19
6
1
S4
258
58
19
4
S5
57
26
8
0
S6
179
45
18
8
Relevant: 17
Nedan följer en lista på de relevanta artiklarna:

















Durham, R. & Durham, M. 2007. What to do when things go wrong an ethical solution.
Komchaliaw, S & Wongthongtham, P. 2010. A state of the art review on software
project performance management
Khan, R & Spang, K. 2011. Critical Success Factors for International Projects.
Jeng, D. 2011. Structural analysis on Team Iternal Soft Factors to Project Success.
Barrick, M & Mount, M. 1991. The Big Five Personality Dimensions and Job
Performance: A Meta-Analysis.
Furnham, A & Hough, L. 2002. Importance and use of personality variables in work
settings.
Thite, M. 1999. Leadership: a critical success factor in IT project management
Gemuenden, H & Hoegl, M. 2001. Teamwork quality and the Success of Innovative
Projects: A theoretical concept and empirical evidence.
Costa, P & McCrae, R. 1991. Facet scales for agreeableness and conscientiousness: A
revision of the NEO personality inventory.
Dvir, D., Sadeh, A & Malach-Pines, A. 2006. Projects and project managers: the
relationship between project managers’ personality, project types, and project success.
Hassan, M., Rezaei, M & Shahhosseini, V. 2012. Competency Based Optimized
Assignment of Project Managers to Projects.
Merrill, D & Collofello, J.S. 1997. Improving software project management skills using
a software project simulator.
Carbone, T & Sampson, G. 2004. Project Manager Skill Development: A Survey of
Programs and Practitioners. .
El-Sabaa, S. 2001. The skills and career path of an effective project manager.
Tarim, T. 2013. Managing Technical Professionals: When to Know to Transition From
Technology Manager to Individual Contributor
Brewer, J. L. 2005. Project Managers, Can We Make Them or Just Make Them Better?
Hocenski, Z & Popovic, K. 2009. Conflict management.
6
2.2.2. Litteraturstudie till frågeställning 2
Även ACMs och IEEEs databaser har använts för att besvara på frågeställning 2. Sökningen
utfördes på samma sätt som för frågeställning 1. Söktermer som har används är:
T1: Project management and interaction development methods
T2: Software project management and interaction development methods
T3: Management and interaction traditional development methods
T4: Management and interaction agile development methods
T5: Software project management and interaction traditional development process
T6: Software project management and interaction agile development process
Tabell 3: Sammanfattning av sökresultat och filtrering ACM.
ACM
Efter titel
Efter abstrakt
Efter artikeln
T1
56
3
0
0
T2
11
1
0
0
T3
8
0
0
0
T4
3
0
0
0
T5
5
0
0
0
T6
0
0
0
0
Relevant: 0
Tabell 4: Sammanfattning av sökresultat och filtrering IEEE.
IEEE
Efter titel
Efter abstrakt
Efter artikeln
T1
26
2
0
0
T2
15
0
0
0
T3
12
1
0
0
T4
4
0
0
0
T5
5
0
0
0
T6
3
0
0
0
Relevant: 0
Från denna litteraturstudie erhålls 0 relevanta artiklar. Resultatet kan bero på att det inte
finns så mycket forskning kring områdena projektledning och utvecklingsmetoder
tillsammans. Det finns mycket forskning om dessa två områden som enskilda ämnen.
7
2.3. Källkritik
Det gäller att vara källkritiskt till all typ av informationsinhämtning. Källor bör i samtliga
fall sättas i relation till det sammanhang som man avser använda dem, vilket leder till en
kritisk reflektion i form av en prövning eller värdering i urvalet av källor. För att bedöma
informationsinsamlingen föreslår Rienecker & Jørgensen (2008) att aspekter så som
författarens auktoritet, analysens konsistens, källans ämnesmässiga status, källans
objektivitet och ett antal andra aspekter bör beaktas ur ett källkritiskt perspektiv. Enligt
(Thurén 2013) är källkritik en samling metodregler för att ta reda på vad som är sant, eller
åtminstone vad som är sannolikt. För att kunna bedöma trovärdigheten för de källor som
används ska dessa granskas kritiskt. Thurén (2013) beskriver källkritiska principer utifrån
fyra kriterier som ska finnas i åtanke vid granskning av källans trovärdighet:




Äkthet - källan ska vara det den utger sig för att vara.
Tidssamband - ju längre tid som har gått mellan händelse och källans berättelse, desto
större skäl finns det att tvivla på källan.
Oberoende - källan ska inte vara en avskrift eller ett referat av en annan källa.
Tradering är en form av beroende som betyder att informationen förts vidare i många
led. För att informationen ska vara tillförlitlig krävs att minst två källor som är
oberoende av varandra påstår samma sak.
Tendensfrihet - misstanke kan finnas om den källa som används ger en falsk bild av
verkligheten. Det finns intressen som förvränger verklighetsbilden av personliga,
ekonomiska, politiska eller andra intressen.
Källor som har använts har framförallt bestått av vetenskapliga artiklar från ACMs och
IEEEs databaser. De vetenskapliga artiklar som har använts har alla blivit kritiskt
granskade av uppsatsens författare utifrån Thuréns (2013) kriterier. Artiklarna har bedömts
som trovärdiga källor då samtliga författare har refererat och citerat till andra källor. Vilket i
sin tur underlättar avgörandet huruvida källan är lämplig och vilka källor man kan sätta
störst tilltro till. Även läroböcker som använts har betraktas som trovärdiga då författarna
som har skrivit läroböckerna har lång erfarenhet inom forskningsområdet. Böckerna är
tryckta av välkända bokförlag och har därmed granskats noga före publicering.
Elektroniska källor från diverse webbsidor som har använts håller dock inte lika stor
trovärdighet som de övriga källorna ur en källkritisk synpunkt utifrån Thuréns (2013)
kriterier. Eftersom avsikten med webbsidor ofta inte är helt tydlig och även i vilket syfte
texten har skrivits kan vara otydligt, är det som undersökare väsentligt att noga granska
källan utifrån Thuréns (2013) kriterier. På grund av att digitala källor kan förändras väldigt
snabbt är det avgörande att ha detta i åtanke då man som författare använder sig av en
elektronisk källa.
2.4. Metoddiskussion
Metoden som använts i denna uppsats har en kvalitativ utgångspunkt i form av en
hermeneutisks grund. Det är väsentligt att ställa sig kritisk till de valda metoderna och
angreppssätten då olika former av metoder kan innehålla varierande osäkerhetsmått. På
grundval av de frågeställningar som utformats bedöms den valda metoden trots detta som
lämplig eftersom det finns hänvisningar till andra undersökningar där samma metod
föreskriver framgång. De frågeställningar som uppsatsen utgår ifrån kräver en mer
omfattande undersökning. Således är en hermeneutisk utgångspunkt lämplig då det handlar
om tolkningslära. En kvalitativ metod med djupintervjuer med ett antal projektledare samt
utvecklare hade kunnat ge ett annorlunda resultat. På grund av tidsbrist samt kontaktbrist
8
har denna metod uteslutits. Det resultat som utmynnar från denna uppsats bedöms påverkas
av det faktum att andra eller kompletterande metodval inte använts, men inte i den grad att
resultatet är osannolikt.
9
3. Teoretisk referensram
Detta avsnitt presenterar sex olika utvecklingsmetoder inom mjukvaruutveckling för att skapa
förståelse för hur metoderna verkar. Ramverket som presenteras här är projekt,
Vattenfallsmodellen, Rational Unified Process, Spiralmodellen, Scrum, Extreme Programming
och Dynamic Systems Development Method.
3.1. Projekt
Mjukvaruutveckling sker normalt i projektform. Projekt kan definieras som:
”Ett projekt är målorienterat, det vill säga har ett specifikt slutresultat, och består av ett antal
aktiviteter som skall genomföras under en avgränsad tid med begränsade resurser och budget”
(Wohlin 2005, s 45).

Målorienterat - Wohlin (2005) menar att ett projekt bör formuleras kring ett tydligt
mål. Med tydligt mål i detta sammanhang menas att målet bör vara unikt för varje
projekt.

Slutresultat - ett projekt bör resultera i något konkret och är nära relaterat till målet
(Wohlin 2005).

Aktiviteter - ett projekt innehåller normalt ett antal aktiviteter som ska genomföras
och som tillsammans leder projektet fram till målet. Projektledarens uppgift är att
planera aktiviteterna så att de kan genomföras på bästa möjliga sätt (Wohlin 2005).

Avgränsad tid - ett projekt har oftast en startpunkt och slutpunkt och karakteriseras
av att det är begränsad med tid (Wohlin 2005).

Begränsade resurser och budget - att ett projekt har tillgång till ett visst antal
personer, viss utrustning och vissa lokaler är en begränsning i resurser. Ett projekt
förväntas att genomföras inom vissa givna kostnader, så kallade begränsning i budget
(Wohlin 2005).
Projektledaren är den som har det övergripande ansvaret för projektet. Tonnquist (2007)
beskriver att ett projekt består av fyra faser:




Förstudie - där förutsättningar analyseras samt att projektuppdraget specificeras.
Planering - handlar om att planera hur genomförandet av projektet ska se ut.
Genomförande - efter planeringen ska genomförande ske genom att utvecklingsteamet
arbetar för att uppnå ett resultat.
Avslut - när resultatet är levererat sker ett avslut där projektet utvärderas och
slutligen avvecklas projektet.
10
Figur 1: Projektmodell som visar projektets livscykel.
3.2. Introduktion till traditionella och agila utvecklingsmetoder
Vattenfallsmodellen, Rational Unified Process och Spiralmodellen tillhör de traditionella
metoderna. Scrum, Extreme Programming och Dynamic Systems Development Method tillhör de
agila metoderna. Anledningen till valet av just dessa är för att de är vanligt förekommande
metoder inom litteratur för mjukvaruutveckling. Metoderna nedan presenteras endast
översiktligt och beaktas endast den nödvändiga information som behövs för att kunna förstår
uppsatsen.
3.3 Vattenfallsmodellen
Vattenfallmodellen är uppdelad i olika faser och varje fas ska vara avklarad innan nästa
påbörjas. Uppstår det ett fel försöker man lösa felet innan man går vidare till nästa fas,
eftersom metoden inte förespråker att gå tillbaka till föregående fas. Faserna exekveras
systematiskt i en sekventiell ordning. Vattenfallsmodellen har tydliga mål för varje fas.
Dokumentation produceras i varje fas i Vattenfallsmodellen. Detta gör det synligt för
projektledare som kan övervaka framstegen mot utvecklingsplanen (Sommerville 2010). Den
första formella beskrivningen av Vattenfallsmodellen anses vara från 1970 i en artikel skrivit
av Winston W. Royce. Men ordet ”Vattenfallsmodellen” användes inte, istället presenterade
Royce modellen som en bristfällig modell (Royce 1970). Royce (1970) menade faktiskt att man
behöver gå tillbaka till vissa steg under utvecklingen men detta ignorerades senare. I
originalartikeln beskriver Royce (1970) följande steg i modellen, som består av:







Systemkrav
Programvarukrav
Analys
Design
Kodning
Testning
Underhåll
De olika faserna i Vattenfallsmodellen kan se olika ut beroende på projektet, men de
huvudsakliga målen med modellen är desamma, att varje fas ska avslutas innan nästa
påbörjas. Nedan beskrivs de olika faserna enligt Sommerville (2010).

Krav definition - analys och definition av krav är det första steget i
utvecklingsprocessen. Funktionella- och icke funktionella krav bryts ner för att ge en
tydlig ram för utvecklingsprocessen.
11

System- och mjukvarudesign - systemdesign är processen för att definiera arkitektur,
komponenter, moduler, gränssnitt och data för att uppfylla specificerade krav.
Mjukvarudesign är den process som skapar en specifikation av en
programvaruartefakt, avsedd att uppnå målen med hjälp av en uppsättning av
primitiva komponenter.

Genomförande och enhetstestning - enhetstestning innebär att kontroller görs för att
säkerställa att varje enhet uppfyller specifikationen. Målet med enhetstestning är att
isolera varje del av systemet och visa att de enskilda delarna är korrekta.

Integration och systemtestning - målet med systemtestning är att säkerställa att det
integrerade systemet som helhet är funktionellt komplett och uppfyller både de
funktionella och icke funktionella krav. Efter testning levereras systemet till kunden.

Drift och underhåll - underhåll innebär korrigering av fel som inte upptäcktes i
tidigare faser, förbättra genomförandet av systemenheter och förbättra systemets
tjänster så som nya krav som upptäckts.
Fördelar:
 Utvecklingsteamet sparar tid genom att modellen är relativt överskådlig och lätt att
förstå.
 Vem som helst ska kunna implementera systemet om kravspecifikationen och designen
är tillräckligt bra.
 Dokumentation finns som ska hjälpa till och se var man avslutade arbetet och vad som
ska göras om ett projekt ska återupptas i framtiden.
Nackdelar:
 Man måste ha 100% överblick från start till slut.
 Förändringar och tillägg blir mycket komplicerade och resurskrävande eftersom det
inte är möjligt att gå tillbaka till föregående fas.
 Många dokument, vissa är onödiga.
12
Figur 2: Illustration på Vattenfallsmodellens olika faser.
Egen bild
Källa: Sommerville (2010)
3.3. Rational Unified Process
Rational Unified Process kommer i fortsättningen att skrivas som RUP. RUP är en iterativ
utvecklingsprocess och tanken är att RUP ska skräddarsys så att det passar den enskilda
organisationen och projektet. Utvecklingsmodellen ägs numera av IBM och utvecklas av IBM
Rational Software (IBM, 2014). RUP projekt delas in i fyra faser som ett projekt går igenom.
Varje fas avslutas med en definierad milstolpe där specifika delmål måste uppfyllas. Varje fas
består av en eller flera iterationer beroende på projektet. Under varje iteration utförs
aktiviteter med syfte att skapa en eller flera artefakter. De fyra faserna är:

Förberedelse - systemkrav samlas in för att fastställa den grundläggande idén för
systemet. Totala kostnader och risker för utvecklingen av systemet identifieras och
beslut om vidare utveckling ska göras fortlöpande (Sommerville 2010).

Etablering - hela systemet måste vara förstått för att kunna fatta beslut angående
systemets arkitektur (Sommerville 2010).

Konstruktion - denna fas innebär systemdesign, programmering och testning
(Sommerville 2010).

Överlämning - överlämningsfasen innebär att leverera systemet till slutanvändarna
och få det att fungera i en verklig miljö (Sommerville 2010).
Inom varje iteration kategoriseras uppgifterna i nio discipliner, sex tekniska och tre stödjande
discipliner. De sex tekniska är:

Affärsmodellering
13




Krav
Analys och design
Implementering
Test och distribution
De tre stödjande disciplinerna är:



Konfiguration och förändringsledarskap
Projektledning
Miljö
Arbetsflödet för projektledning inom RUP är ett ramverk för hantering av projekt och risker.
Det innehåller även praktiska riktlinjer för planering, bemanning, genomförande och
övervakning av mjukvaruprojekt (IBM, 2014). RUP är uppbyggd av olika element som
beskriver vad som ska produceras, visar de nödvändiga kunskaper som krävs och
beskrivningar av hur specifika utvecklingsmål ska nås. De olika elementen är följande:
 Roller (vem) som definierar en uppsättning av vad relaterat till kompetens, färdigheter
och ansvar. Inom RUP-processen är det rollerna som definierar hur individerna ska
utföra arbetet.
 Aktiviteter (hur) beskriver en enhet av arbete som en individ i en roll kan bli ombedd
att utföra och som ger ett meningsfullt resultat. Exempel på aktivitet kan vara att
projektledaren planerar en iteration för utvecklingsteamet.
 Artefakt (vad) är den påtagliga produkten för projektet. Artefakter används som
underlag av utvecklingsteamet för att utföra en aktivitet (IBM, 2014).
RUP baseras även på sex stycken tillämpningar och användning av dessa minskar risker i
mjukvaruprojekt. Dessa sex tillämpningar är:

Utveckla iterativt - planera systemet inkrementellt baserat på kundens prioriteringar.
I en iterativ utvecklingsmodell är det möjligt att gå tillbaka och t.ex. ändra på
systemkrav och planera om följande iterationer (Sommerville 2010).

Hantera systemkrav - funktionella och icke-funktionella krav bör dokumenteras för att
lätt kunna hantera förändringar (Sommerville 2010).

Använd komponentbaserad arkitektur - komponenter är delsystem som uppfyller en
specifik funktionalitet av hela systemet. Komponentbaserad arkitektur ger flexibilitet
och effektivare programåtervinning (Sommerville 2010).

Modellera visuellt - visuella modeller fångar upp arkitekturens och dess komponenters
struktur och beteende, samt hjälper till att kommunicera olika aspekter av mjukvaran
(Sommerville 2010).

Kontinuerlig kvalitetskontroll - se till att mjukvaran uppfyller de organisatoriska
kvalitetsstandarderna. Systemkvalitet definieras genom att värdera systemets
tillförlitlighet, funktionalitet och prestanda (Sommerville 2010).

Kontrollera förändring- förändringar är ofrånkomliga i mjukvaruutveckling. RUP
hjälper till att kontrollera, följa upp och dokumentera förändringar (Sommerville 2010).
14
Figur 3: RUPs olika faser och discipliner.
Egen bild
Källa: http://theexplorationofmyworlds.wordpress.com/2012/07/02/rup-rational-unifiedprocess/
3.4. Spiralmodell
Modellen som presenteras nedan är en blandning av både Boehms (1986) och Wohlins (2005)
Spiralmodell. Spiralmodellen är en variant av iterativ utveckling som ämnar kombinera
riskhantering med iterativ utveckling och den är även influerad av Vattenfallsmodellen och
bygger enligt Wohlin (2005) på följande nyckelord:







Budget
Bestäm mål
Alternativ
Begränsningar
Riskanalys
Prototyp
Utveckla och testa
Modellen är byggd kring en spiral och varje varv i spiralen består av fyra faser. De två första
faserna är likadana för samtliga varv i Spiralmodellen.

Varv 1 - budget för projektet bestäms i den första fasen i det innersta varvet, målet
sätts beroende på budgeten. Alternativa lösningar identifieras utifrån målet, sedan
identifieras begränsningar. En riskanalys genomförs i den andra fasen genom
prototyputveckling som betyder att information tas fram för att kunna göra en
utvärdering. En övergripande modell tas fram som beskriver hur systemet ska fungera
i den tredje fasen på första varvet. En livscykelplan för produkten skrivs och krav på
produkten tas fram i den sista fasen på första varvet (Boehm 1986).

Varv 2 - produktkraven bryts ned till krav på programvaran i den tredje fasen, även
avstämning av kraven gentemot kund och marknad sker. Utvecklingsplan görs i den
sista fasen (Wohlin 2005).

Varv 3 - design genomförs i den tredje fasen och integrationstest planeras i den fjärde
fasen (Boehm 1986).
15

Varv 4 - detaljerad design, kodning och test genomförs i den tredje fasen och upprepas i
ett antal iterationer och leverans sker slutligen i den sista fasen (Wohlin 2005).
Figur 4: Spiralmodellens olika varv och faser.
Egen bild
Källa: http://www.torefriskopp.se/annat/minska-risken-med-iterativ-utvecklingsmodell
3.5. Scrum
Syftet med Scrum är att effektivisera arbetet och arbetsfördelningen genom att införa olika
typer av roller. De olika rollerna består av Product Owner, Scrum Master och Scrum Team.
Product Owner, som också kallas för produktägaren, är den som ansvarar och företräder alla
som jobbar med projektet. Product Owner är även den som tar emot, hanterar och prioriterar
önskemål och ändringar för en produkt. En Scrum Master som fungerar som en coach för
Scrum Teamet och ser till att regler skapas och följs. Scrum Master är även den som hanterar
eventuella konfliker i teamet. Att säkerställa överlevnad av processen är Scrum Masterns
uppgift. Scrum Mastern har en coachande och rådgivande roll men skiljer sig från en
projektledare då en Scrum Masters roll saknar ledningsansvar. Det finns ingen definierad
projektledarroll i Scrum. Den sista rollen är Scrum Team som är gruppen som gör det
praktiska arbetet. Scrum Teamet ingår individer med olika färdigheter och gruppen arbetar
under självorganiserande förhållanden (Schwaber 2004).
Olika komponenter inom Scrum:

Product backlog – en lista med krav på systemet som ska utvecklas. Produktägaren
ansvarar för och prioriterar backlogen (Schwaber 2004).
16

Sprint backlog - den del av produktbacklogen som Scrum Teamet åtar sig att
implementera under en sprint. Definierar arbetet eller arbetsuppgifter (Schwaber
2004).

Inkrement - det som skapas i varje sprint, d.v.s. tillskott av nya egenskaper eller
funktioner. Inkrementet måste vara användbart ifall produktägaren genast väljer att
implementera funktionen (Schwaber 2004).

Sprint - i Scrum delas arbetet in i sprintar och längden är normalt 2-4 veckor
(Sommerville 2010). Sprinten inleds med en Sprint planning och avslutas med en
Sprint review. Under sprinten sker dagligen Daily Scrums (Schwaber 2004).

Daily Scrum - dagliga planeringsmöten för Scrum Teamet som maximalt får ta 15
minuter. Scrum Teamet inspekterar sin progress så här långt i sprinten och var och en
i teamet svarar på följande tre frågor: Vad har du gjort sedan igår? Vad har du
planerat att göra nu intill nästa Daily Scrum? Vad hindrar dig? (Schwaber 2004).

Sprint review - som kan översättas som sprintgranskning, görs i sluten av sprinten.
Sprintgranskning är ett fyra timmars möte, där status för projektet presenteras inför
produktägaren och andra intressenter. Syftet är att presentera hur långt Scrum
teamet kommit, vad som är klart och vad som ska göras härnäst (Schwaber 2004).

Spring retrospective – med detta menas återblick. Scrum Teamet tillsammans med
Scrum Mastern och produktägaren går igenom erfarenheter från sprinten och
identifierar möjliga förbättringar till nästa sprint (Schwaber 2004).

Sprint planning - produktägaren, Scrum Mastern och Scrum Teamet går igenom de
önskemål som finns. Genom att jämföra de tidsuppskattade och prioriterade
önskemålen med tillgänglig tid tas en sprint backlog fram av produktägaren som
Scrum teamet åtar sig att genomföra.
Figur 5: Scrum processen.
Egen bild
Källa: http://www.bestoutcome.com/overview-of-scrum.html
17
3.6. Extreme Programming
Extreme Programming kommer vidare i uppsatsen att förkortas som XP. XP utvecklades på
grund av att många mjukvaruprojekt avbröts eller att projektplanen inte kunde hållas. Det är
vanligen en projektledare som hjälper utvecklingsteamet på rätt spår samt underlättar
processen. Projektledaren är även den som hanterar resurser och den externa
kommunikationen (Xprogramming, 2014). XP bygger på fyra värderingar och dessa består av:

Kommunikation och återkoppling - den optimala kommunikationsmetoden kan sägas
vara ”face to face”-kommunikation. Kunden är på plats, vilket innebär att kontinuerlig
kommunikation blir möjligt mellan utvecklarna och kunden. Kunden har möjlighet att
ändra systemkraven så att de viktigaste kraven hanteras först. Kommunikation är
viktig för återkoppling (Hughes & Cotterell 2009).

Enkelhet - enklast möjliga design ska användas för att implementera användarens
krav (Hughes & Cotterell 2009).

Ansvar - utvecklare är ansvariga för systemets kvalitet (Hughes & Cotterell 2009).

Mod - alla utvecklarna ska vara ärliga med vad de kan göra och inte kan göra (Hughes
& Cotterell 2009).
Förutom de fyra värderingarna inom XP finns det också tolv tillämpningar som stöttar de fyra
värderingana:

Planeringspelet - den process där funktionerna i nästa leverans bestäms och var och en
av dessa funktioner dokumenteras i en kort textbeskrivning (Xprogramming, 2014).

Små leveranser - tiden mellan leveranserna av funktionerna bör vara så kort som
möjligt (Xprogramming, 2014).

Metafor - enkel beskrivning av hur systemet ska fungera (Xprogramming, 2014).

Enkel design - all kod ska hållas enkel genom en enkel design. Upptäcks det onödigt
komplexitet i koden tas denna bort (Xprogramming, 2014).

Testning - utförs samtidigt som kodning och är till för att kontrollera att funktionen är
korrekt och hjälper till att klargöra kraven. Det krävs två tester, enhetstestning som
fokuserar på koden som utvecklare har skrivit och funktionstestning som är
användorienterad och kontrollerar korrekthet av en viss funktion (Xprogramming,
2014).

Omstrukturering av kod - genom att kontinuerligt ta bort identisk och onödigt komplex
kod (Xprogramming, 2014).

Parprogrammering - där all kodning utförs av två utvecklare, en som skriver koden och
den andra som observerar genom att diskutera, kommentera och ge förslag.
Partnerutbyte sker konstant. Därför är det viktigt att man har kännedom om de
funktioner som är under utveckling (Xprogramming, 2014).

Gemensamt ägarskap - även om det parprogrammeras så äger alla utvecklarna koden
gemensamt. Alla har rätt att ändra i all kod, oavsett om den är skriven av dem själva
eller någon annan (Xprogramming, 2014).
18

Kontinuerlig integration - eftersom ändringar görs och för att säkerställa att alla
komponenter fungerar tillsammans (Xprogramming, 2014).

40-timmars arbetsvecka - programmerare tänker och arbetar bättre utvilade. Därför
har XP en tillämpning som heter 40-timmars arbetsvecka, vilket innebär att
utvecklarna inte bör arbeta mer än 40 timmar i veckan. I extrema fall kan övertid
behövas men övertidsarbete är inte tillåtet i mer än två veckor i rad (Xprogramming,
2014).

Kunden på plats - för en effektivare kommunikation med utvecklarna, och för att
kunna besvara frågor, definiera systemet samt utföra tester, finns kunden på plats på
heltid (Xprogramming, 2014).

Kodningsstandard - då koden ägs av alla finns det en konsekvent kodningsstandard
som följs av alla utvecklarna (Xprogramming, 2014).
Figur 6: XPs tolv tillämpningar.
Egen bild
Källa: http://xprogramming.com/what-is-extreme-programming/
3.7. Dynamic Systems Development Method
Dynamic Systems Development Method kommer i fortsättningen att skrivas som DSDM.
DSDM är en iterativ och inkrementell utvecklingsmetod som omfattar principerna för agil
utveckling. DSDM Atern lanserades 2007 och är en metod för projektledning och
lösningsleverans som menar att fler mjukvaruprojekt misslyckas på grund av mänskliga
problem än tekniska problem. DSDM Atern fokuserar på att hjälpa utvecklingsteamet att
arbeta effektivt för att tillsammans uppnå projektmålet. Metoden fokuserar på tidiga
leveranser av verklig nytta för ett företag, användare eller kund. DSDM Atern består av åtta
principer. Dessa principer leder utvecklingsteamet i den attityd de måste ha och de tankesätt
som ska vidtas för att leverara konsekvent. Metoden fokuserar även på ett projekts livscykel
19
med en flexibelt definierad uppsättning principer, samt tydliga roller och ansvarsområden för
att möjliggöra en leverans (Dsdm, 2014). De åtta principerna består av:

Fokus på affärsbehov - systemet som levereras ska tillfredsställa det nuvarande
affärsbehovet.

Leverera i tid - deadlines ska alltid följas.

Samarbeta - för att ett beslut ska kunna fattas effektivare och snabbare krävs det att
både utvecklare och användare integreras tillsammans i projektet.

Aldrig kompromissa kvalitet - realistiska projektmål sätts upp tidigt i projektet. Tidig
och kontinuerlig testning av funktionerna sker löpande.

Utveckla iterativt - fokus på täta och många små leveranser.

Bygga stegvis från företagsets grunder - för bättre affärsnytta eftersträvas leveranser
så tidigt som möjligt.

Kommunicera kontinuerligt - för projektets effektivitet krävs det kommunikation och
samarbete mellan projektets intressenter.

Demonstrera kontroll - planer och framsteg görs synliga för alla. Framsteg mäts genom
fokus på leverans snarare än på genomförda aktiviteter.
DSDM Atern hjälper ett mjukvaruprojekt att genomgå en kontrollerad start fram till en
punkt där förståelsen för projektet är tillräckligt bra för att börja bygga lösningen iterativt och
inkrementellt. Processen har fem faser som består av:





Genomförande
Grunder
Utforskning
Teknik
Distribution
Dessa föregås av en förprojektering som följs av en efterprojektfas. Förprojektfasen
säkerställer att det är rätt mjukvaruprojekt som startas. Målet med detta är att bekräfta att
projektet ligger i linje med affärsstrategin, samt att planera resurshantering i
genomförandefasen. Förprojektfasen bör vara kort och koncis. Projektet bör utvärderas
kontinuerligt under hela projektets gång för att se att slutprodukten ger fördelar vid
användning och överväga kostnaderna för projektet. Under genomförandefasen avgörs det om
projektet är lönsamt både ur ett affärsperspektiv och ett teknisk perspektiv (Hughes &
Cotterell 2009).
20
Figur 7: DSDM processen.
Egen bild
Källa: http://www.lshift.net/practice/managing-projects/agile
21
4. Resultat
Detta avsnitt beskriver de resultat som framkommit ur litteraturstudiens genomförande för att
besvara frågeställning 1, ”Vilka egenskaper kännetecknar en framgångsrik projektledare?”. De
resultat som framkommit är indelade i relationsförmåga, personlighet, kompetens och
kommunikationsförmåga.
4.1. Relationsförmåga
Raccoon (2006) menar att projektledaren måste engagera sitt utvecklingsteam genom ett
socialt kontrakt. Genom det sociala kontraktet påverkar projektledaren och utvecklingsteamet
omgivningen. En projektledare ska kunna använda sitt inflytande för att främja
utvecklingsteamet, intressenter och ändamål för att uppnå projektmålet. Det är sannolikt att
utvecklingsteamet känner tillit för projektledaren om projektledaren inte missbrukar sin
auktoritet. Komchaliaw & Wongthongtham (2010) menar att förtroende har en positiv effekt
på samarbete och prestation. Ökat förtroende har en direkt positiv inverkan på
utvecklingsteamets attityd. Keretho, Lent & Pinkowska (2011) anser att effektivitet bestäms
av ömsesidigt förtroende, som bygger på personlig kännedom om varandra. Därför är det
viktigt att relationen mellan projektledare och utvecklingsteamet är god. Utvecklingsteamet
blir engagerade med hjälp av projektledarens färdigheter och ett effektivt sätt att leda
utvecklingsteamet är att utveckla ett mentorskap. Alla projektledare behöver sina utvecklare
oavsett hur effektiva de är. Projektledare arbetar för att uppnå ett projektmål och
utvecklingsteamet är kärnan i utvecklingsprocessen.
Projektledaren är den som främst ska få arbetsprocessen att fungera genom att samarbeta och
samordna med sitt utvecklingsteam. Han/hon är även den som påverkar sitt utvecklingsteam
direkt genom tal, skrift och sin närvaro (Raccoon 2006). Varje person påverkas medvetet eller
omedvetet av människor som man integrerar med. Projektledare påverkar sitt
utvecklingsteam medvetet genom att använda sitt inflytande för att ta fram de bästa i sitt
utvecklingsteam och tillsammans föra mjukvaruprojektet mot målet. Chen, Chen & Chern
(2012) menar att projektledaren bör fokusera mer på utvecklingsteamets motivation för att
kunna uppnå ett lyckat resultat. Keretho, Lent & Pinkowska (2011) menar att motivation av
utvecklingsteamet är en viktig aktivitet för en projektledare och motivationen skapas genom
uppbyggnad av en god relation. Utvecklingsteamets motivation ökar engagemanget för
projektet och således effektiviteten och framgången menar Khan & Spang (2011).
Projektledarskap handlar om att projektledaren har personliga och vardagliga interaktioner
med sitt utvecklingsteam. Projektledaren kan både vara en ”yttre ledare” som ställer
uppenbara mål men även en ”inre ledare” som främjar personliga relationer. Projektledaren
och utvecklingsteamet förväntar sig mycket av varandra. Projektledaren förväntar sig att
utvecklingsteamet samarbetar med varandra och genom det levererar ett gott resultat.
Utvecklingsteamet förväntar att projektledaren har förtroende för dem. Det är viktigt för
utvecklingsteamet, men även för mjukvaruprojektet, att projektledaren i ett tidigt skede
tydligt uttrycker målet för projektet så alla i utvecklingsteamet kan sträva efter detta.
Närvaron i projektet är viktigt för en projektledare. Det är genom projektledarens närvaro
som engagemang skapas hos utvecklingsteamet. En projektledare måste ha beslutsamhet,
förtroende och den uthållighet som krävs för att få saker gjorda. Att vara optimistisk är en
egenskap som en projektledare bör ha. Om projektledaren inte tror att utvecklingsprojektet
kommer att lyckas så kommer förmodligen inte heller utvecklingsteamet att tro på det. Och
då kommer projektet med största sannolikhet att misslyckas (Raccoon 2006).
22
Oftast är det inte projektledaren som väljer utvecklingsteam för att utveckla mjukvaran.
Utvecklingsteamet som skapats är det man leder, även om det inte är just de människorna
man vill ha i utvecklingsteamet eller vill arbeta med vid ett senare tillfälle. Men effektiva
projektledare uppmärksammar sina projektmedlemmar och frammanar kompetens från var
och en av dem. Projektledaren tar också hänsyn till vem de är och vad de är kunniga till att
utföra (Raccoon 2006). Projektresultatet beror enligt Jeng (2011) på hur väl ett
utvecklingsteam fungerar ihop. En viktig faktor som påverkar projektet är alltså relationen
mellan utvecklingsteamet och projektledaren.
4.2. Personlighet
Projektledaren spelar en viktig roll i de flesta projekt inom mjukvaruutveckling.
Projektledarens ledarskapsnivå är avgörande för ett projekts framgång eller misslyckande.
Gao & Ma (2009) menar att projektledarens personlighet har en stor påverkan på
utvecklingsteamets effektivitet. Ledarskapsbeteende är en viktig dimension av mänsklig
beteende och är starkt präglat av individens personlighet. Människors attityder och beteende
bestäms till stor del av deras personlighet. Människors personlighet återspeglas i deras
tankar, beteende och livsstil. Därför är det rimligt att projektledarens personlighet spelar en
stor roll i mjukvaruutvecklingsprocessen (Li & Wang 2009).
Barrick & Mounts (1991) Five Factor model beskriver personlighetsdrag med fem faktorer. Li
& Wang (2009) betraktar dessa fem faktorer som indikatorer för utvecklingsprojektets
framgång men också av hur projektledarens personlighet påverkar utvecklingsteamet genom
förmedling av ledarskapskonstruktioner. De fem faktorerna för personlighetsdragen är:

Öppenhet - avser en generell uppskattning för känslor, äventyr, ovanliga idéer, fantasi,
nyfikenhet och olika erfarenheter. De projektledare som ofta är villiga att pröva nya
saker är människor med hög öppenhet medan låg öppenhet i denna dimension är
människor som ofta föredrar stabilitet (Li & Wang 2009). Öppenhet är viktigt för
förändring. Mjukvaruutveckling verkar i en bransch som påverkas av många
oförutsägbara faktorer som kan påverka ett projekt negativt (Furnhamn & Hough
2002). En låg öppenhet hos projektledaren kan leda till misslyckande med att hantera
tekniska förändringar. Och är därmed ett hot mot det tekniska ledarskapet eftersom
teknik och metoder inom mjukvaruutveckling ständigt förändras (Thite 1999). Judge &
Bono (2000) menar att öppenhet är viktigt för en projektledare då denna verkar som
samordnare mellan individer i gruppen. Öppenhet gynnar utvecklingsteamets arbete
och därmed dess prestationsförmåga.

Neuroticism - som ibland kallas för emotionell instabilitet, är tendensen att uppleva
negativa känslor såsom ilska, ångest och depression. Projektledare med hög
neuroticism är känsliga för stress och är mer benägna att tolka vanliga situationer som
hotfulla. De är ofta på dåligt humör eftersom deras negativa emotionella rektioner
tenderar att kvarstå under lång tid. Dessa problem kan minska förmågan att tänka
klart, fatta beslut och hantera stress på ett effektivt sätt. Individer med hög
neuroticism tenderar att misslyckas med att leverara ett positivt ledarskap, då de har
lätt att bilda negativa frågeställningar. De med låg neuroticism ofta välanpassade i en
dynamisk miljö. En projektledare med låg neuroticism kan bättre hantera de frågor
som uppkommer under utvecklingsprocessen och leverera ett ledarskap på hög nivå (Li
& Wang 2009).

Vänlighet - en snäll, omtänkssam, hjälpsam och samarbetsvillig personlighet i detta
sammanhang (Eisenberg & Graziano 1997). I mjukvaruutvecklingsprojekt där
mänskliga interaktioner och samarbeten är viktiga, är det uppenbart att vänlighet
23
kommer att underlätta aktiviteter som innebär samarbete och samverkan mellan olika
individer. Samarbete och effektiv kommunikation är en av de viktigaste faktorerna för
att ett projekt ska lyckas. Projektledare med hög vänlighet är mer benägna att ge stöd
och vägledning i utvecklingsteamet (Gemuenden & Hoegl 2001).

Samvetsgrannhet - är tendensen på att visa självdisciplin och sträva efter prestation.
En samvetsgrann person är någon som planerar snarare än att agera spontant.
Personer som har hög samvetsgrannhet är ofta drivna och genom hårt arbete villiga att
uppnå hög standard på sin arbetsprestation (Costa & McCrae 1991). De är angelägna
att göra sitt bästa för att förbättra sitt ledarskap. Det blir möjligt för projektledaren att
ses som en förebild för sina underordnade och stimulera utvecklingsteamet att prestera
bättre och uppnå målet (Li & Wang 2009).

Extraversion – används för att beskriva människor som är fulla av energi. Dessa
individer är sociala, aktiva, självsäkra, positiva, utåtriktade och har en tendens att
söka stimulans och andras sällskap (Dvir, Sadeh & Malach-Pines 2006). Projektledare
inom mjukvaruutveckling behöver hantera många interna som externa frågor, samt
bygga relationer med kunder för att uppnå framgång i projektet. En högt extravert
personlighet passar i socialt relaterat arbete så som mjukvaruutveckling. Hög
extraversion påverkar inte bara internt ledarskap, det är även positivt förknippat med
framgång för mjukvaruutvecklingsprojekt (Li & Wang 2009).
4.3. Kompetens
Hassan, Rezaei & Shahhosseini (2010) menar att projektledarens kompetenser har en direkt
inverkan på utvecklingsteamets prestation. Eftersom utvecklingsprojekt plågas av kostnader
som är större än budget, schema som går över tiden och kvalitetsproblem finns det ett tydligt
behov av effektivitet som projektledningskompetens. Många projekt hade kunnat lyckas
bättre om vissa gemensamma projektledningsfallgropar hade undvikits. Merrill & Collofello
(1997) menar att dålig projektledning kan öka utvecklingskostnaderna snabbare och mer än
någon annan faktor. Planering, uppföljning och styrning är projektledarens största uppgifter
inom mjukvaruutveckling. För att kunna hantera dessa krävs det kompetens. En viktig
kompetens är att känna till de vanliga projektledningssvårigheterna och att ha färdigheter att
kunna erkänna dessa svårigheter och anpassa sig efter nya omständigheter (Merrill &
Collofello 1997). Enligt Merrill & Collofello (1997) är projektledarens uppgift väldigt komplex.
Mjukvaruprojekt måste följas upp kontinuerligt, övervakning måste ske konstant och problem
som inträffar ska reageras på snabbt och smidigt. Därför behövs praktisk och aktiv erfarenhet
för att effektivisera projektledningen. Det finns tre typer av ledarkompetenser, dessa är
mänskliga, organisatoriska och tekniska.
Eftersom det är människor som är ansvariga för leverans av projektet menar Durham &
Durham (2007) att mänskliga färdigheter ofta är den viktigaste utav de tre
ledarkompetenserna för en projektledare. Khan & Spang (2011) menar att projektledarens
kunskaper, färdigheter och förmågor är avgörande för projektet. För att en projektledare ska
kunna leda gruppen mot det planerade målet krävs det förståelse för projektmiljön, kunskap
och social kompetens. Carbone & Sampson (2004) menar att få organisationer genomför
internutbildning för sina projektledare inom projektledningsområdet. Istället förlitar de sig på
att arbetslivserfarenhet utvecklar projektledare och att de tekniska färdigheterna främjar
projektledarens förmåga. Istället menar El-Sabaa (2001) att det är viktigare för en
projektledare, oavsett bransch, att ha mänsklig kompetens än teknisk kompetens. Keretho,
Lent & Pinkowska (2011) menar att en projektledare som har förmåga att hantera de
mänskliga faktorerna bidrar till högre effektivitet. Därför är projektledarens kompetens
24
avgörande för ett effektivt projekt. Projektledare som förstår mänskliga kompetenser har
även lättare att arbeta och kommunicera med människor och tar oftare hänsyn till
utvecklingsteamets behov. Detta bidrar till en hög motivationsfaktor inom projektet. Det är
absolut inte nödvänligt att en projektledare ska vara den person som är bäst på att utföra en
viss uppgift, eller mest kunnig om uppgiften. Det är viktigare att projektledaren har förmågan
att se till att en uppgift blir utförd av de personer som är mest kvalificerade (Creighton 1990).
Det finns betydande skillnader mellan enskilda utvecklare. Att projektledare väljer rätt
personer till att utföra projektet kan avsevärt förbättra möjligheterna till framgång. Att
känna till utvecklarens tekniska kompetens, kvalifikationer och erfarenhet är ett krav. Men
lika viktigt är det att förstå de olika mjukvaruutvecklarnas personligheter, då människor
arbetar på olika sätt beroende på deras personlighet. Individens personlighet kan påverka
utvecklarens vanor och sätt att tänka på och hur han/hon förstår kraven för en uppgift, samt
hur han/hon löser ett problem. Genom att matcha utvecklare till ett särskilt projekt med deras
personligheter skapas produktivitet. Valet av personal till ett projekt måste skräddarsys med
de utvecklare som har den personlighet som passar till just det projektet. Tarim (2013) menar
att många utvecklare lämnar ett projekt på grund av inkompetenta projektledare. För att
minimera den tid som en utvecklare lägger på en uppgift, är det projektledarens ansvar att
tilldela personalen deras roller, aktiviteter och uppgifter i projektet. Det bästa sättet att göra
det på är att uppskatta utvecklarnas personligheter och använda dem på bästa sätt inom
ramarna för projektet (Howard 2001).
Att kunna hantera teknisk personal är en svår uppgift för projektledarna. I många fall är
teknisk personal intensiva individer som tycker bäst om att utföra sitt arbete på ett självstyrt
sätt. Motstånd är vanligt när en projektledare försöker ge en riktning om hur arbetet ska
utföras. Teknisk personal och projektledare kan uppleva egokonflikter. Problem uppstår när
dessa sammandragningar skapar hinder för projektet. Projektledaren och personalen är
beroende av varandra för att kunna leverera ett resultat. Därför måste en attityd av
ömsesidig respekt utvecklas (Creighton 1990). Jalil & Shahid (2008) menar att förr i tiden
fanns det en missuppfattning om att en framgångsrik projektledare bör har en skicklig
tekniskt kompetens. Man trodde att en projektledare med teknisk kompetens kan påverka
utvecklingsteamet. Men många erkänner nu att en projektledare bör fokusera mer på de
mänskliga faktorerna.
4.4. Kommunikationsförmåga
En viktig aspekt av projektledning är förmågan att kommunicera effektivt. En projektledare
ska ha förmåga att lyssna och förstå utvecklingsteamet och de externa kunderna. Genom en
effektiv kommunikation kan projektledaren och utvecklingsteamet förstå förväntningarna
man har på varandra. Återkoppling mellan projektledaren och resten av utvecklingsteamet
blir också lättare med effektiv kommunikation. Det kommer även att vara lättare att lösa
problem och uppgifter (Brewer 2005). Med en effektiv kommunikation menas att alla tankar
och övertygelser uttrycks tydligt och öppet (Creighton 1990). Det är även viktigt att en
projektledare kommunicerar tydligt så att alla nivåer i organisationen förstår. Samma
budskap ska nå fram, oavsett vilken position man har i organisationen. Projektledaren är
centrum för all sorts projektkommunikation. Det är hans/hennes skyldighet att hantera
uppdateringar om projektet (Hocenski & Popovic 2009).
Spridning av information är oerhört viktigt för att alla i utvecklingsteamet ska kunna ta del
av den information som är betydelsefull för projektet. Att en projektledare kan kommunicera
och relatera projektmål till sin personal är direkt knutet till framgång (Creighton 1990). De
flesta misslyckade projekt beror på ineffektiv kommunikation menar Komchaliaw &
25
Wongthongtham (2010). Det finns många olika typer av hinder som kan försämra
kommunikationen, t.ex. fysiska hinder som ofta handlar om miljö, som att det är för varmt,
kallt eller störande. Det finns även mentala hinder i form av stress. En projektledare bör
förutse dessa hinder och kommunicera i en miljö där dessa hinder sannolikt inte kommer att
existera. Dålig kommunikation leder ofta till sämre prestation.
Khan & Spang (2011) menar att en av de mest kritiska faktorerna för att kunna slutföra ett
projekt är kommunikation. Återkoppling är en av de viktigaste typerna av kommunikation
som en projektledare utför. Återkoppling kan vara både positiv och negativ men ska alltid
vara av konstruktiv natur. Det är viktigt att kritiken tydligt uppfattas och tolkas tydligt av
den utvecklare som tar emot kritiken och att han/hon förstår att kritiken är baserad på
beteende. Det är olämpligt för en projektledare att kritisera en utvecklare som person. Det är
en projektledares ansvar att kommunicera med personal om hur deras arbete uppfattas.
Därför bör återkoppling ske kontinuerligt (Creighton 1990). Enligt Keretho, Lent &
Pinkowska (2011) är effektiv kommunikation en av de viktigaste framgångsfaktorerna för
projektledaren i ett projekt. Kommunikationsfärdigheter behövs för att optimera prestation
menar Jalil & Shahid (2008).
Figur 8: Dessa fyra egenskaper kännetecknar en framgångsrik projektledare.
4.5. Diskussion av resultatet
De resultat som beskrivits ovan omfattar egenskaper som är viktiga för en framgångsrik
projektledare. Dessa egenskaper är relationsförmåga, personlighet, kompetens och
kommunikationsförmåga. Dessa fyra egenskaper har framkommit under litteraturstudien och
är relevanta för en projektledare som leder ett mjukvaruutvecklingsprojekt. Projektledare
med positiva kvaliteter i dessa egenskaper och som leder ett projekt kommer med stor
sannolikhet att lyckas. Det krävs allt mer från en projektledare för att kunna hantera de
förändringar som behövs i ett mjukvaruutvecklingsprojekt.
Det blir svårt att hantera ett utvecklingsteam om projektledaren inte skapar en bra relation
med de individer som arbetar med projektet. Genom en bra relation skapas även tillit som är
betydelsefullt för att kunna leda utvecklingsteamet. Det räcker inte med att skapa en bra
relation med sitt utvecklingsteam, det krävs även att projektledaren har vissa
26
personlighetsdrag. De personlighetsdrag som är relevanta för en projektledare är att vara
öppen, emotionell stabil, vänlig, samvetsgrann och extravert. Då mjukvaruutvecklingsprojekt
är komplexa behövs det en projektledare som har de kompetenser som krävs för att kunna
leda utvecklingsteamet mot målet. Eftersom projektledaren är den som styr projektet är det
betydelsefullt att projektledaren är kompetent att kunna slutföra projektet tillsammans med
utvecklingsteamet. Den sista egenskapen som krävs för en framgångsrik projektledare är
kommunikationsförmåga. En projektledare som inte ha förmågan att kommunicera är ingen
bra projektledare. Eftersom mjukvaruutvecklingsprojekt är ett samarbete mellan olika
individer, bör alla som är involverade i projektet får ta del av information som behövs för att
kunna utföra projektet.
Att uppsatsen har avgränsats till dessa fyra egenskaper beror på att det endast är det
mänskliga interaktionerna mellan projektledaren och utvecklingsteamet som är relevant.
Dessa fyra egenskaper anses då vara de mest relevanta för en projektledare att besitta för att
kunna leda ett projekt.
27
5. Analys
I detta analysavsitt kommer uppsatsens resultatdel och teoretiska referensavsnitt att
analyseras för att presentera samverkan mellan de olika utvecklingstemoderna och de
egenskaper som kännetecknar en framgångsrik projektledare. Analysen baseras på vad som
utmärker en viss utvecklingsmetod i förhållande till de olika framgångsrika egenskaper na som
en projektledare bör ha.
5.1. Vattenfallsmodellen
5.1.1. Relationsförmåga
Ledarskapsrelationer i Vattenfallsmodellen handlar om hur projektledaren utvecklar
relationer med projektets intressenter och utvecklingsteamet för att kunna skapa en optimal
process. Det är avgörande att projektledaren lyckas engagera och motivera sitt
utvecklingsteam för att projektmålet ska kunna uppnås. Projektledare som besitter
egenskapen att kunna påverka andra individers känslor och uppfattningar för att lugna
gruppen kommer att skapa ett mer effektivt utvecklingsteam. Det finns en ömsesidig
förväntning mellan ledare och utvecklingsteamet som grundar sig på tillit och förtroende och
därför är det avgörande att samtliga som är involverade i projektet delar samma målbild och
outtalade förväntningar menar Keretho, Lent & Pinkowska (2011). Om en skild målbild råder
skulle detta skapa hinder i arbetet med Vattenfallsmodellen och projektledaren måste således
besitta kompetensen att påverka utvecklingsteamets känslomässiga inställning till projektet.
Det är väsentligt att projektledaren vårdar och värnar om relationerna inom gruppen
samtidigt som han/hon följer upp och observerar hur relationerna utvecklar sig och har ett
sinne för att analysera dynamiken inom utvecklingsteamet. Anledningen till att denna aspekt
är viktig i implementation av Vattenfallsmodellen grundas på att arbetet är beroende av att
en fas färdigställs helt innan en ny påbörjas (Sommerville 2010). Planen som ligger till grund
för Vattenfallsmodellen i projektet bör utarbetas och formas av projektledaren men i nära
samarbete med utvecklingsteamet för att ta hänsyn till alla medlemmar.
5.1.2. Personlighet
Att använda Vattenfallsmodellen kräver stor tillsyn av projektledaren. Det är projektledarens
ansvar att kontrollera och bestämma när nästa utvecklingsfas ska påbörjas. Därför bör även
projektledarens personlighetsdrag, som kan delas in enligt Five Factor model (Barrick &
Mount 1991) som tidigare nämnts i resultatdelen, vara synliga för utvecklingsteamet. En
projektledare som har öppenhet, vänlighet, samvetsgranhet och extraversion på en hög nivå
tillsammans med låg neuroticism kommer att kunna motivera sitt utvecklingsteam och genom
det skapa ett bättre resultat. Att en projektledare har den personlighet som krävs för att leda
utvecklingsteamet är viktigt oavsett vilken utvecklingsmetod som används. Men särskilt
betydelsefullt i Vattenfallsmodellen eftersom detta är en metod som kräver stor
uppmärksamhet av projektledaren.
5.1.3. Kompetens
Vid användning av Vattenfallsmodellen behöver projektledaren ha de mänskliga, tekniska och
organisoriska kompetenser som krävs. Det kräver att projektledaren har alla dessa tre
kompentenser, och kan kombinera dessa på bästa möjliga sätt för att uppnå ett gott resultat.
Att dessa ledarskapskompetenser är grundläggande för användning av Vattenfallsmodellen
beror på att modellen är en utvecklingsprocess som kräver att en projektledare har 100%
överblick från start till slut. Och alla dessa tre kompetenser behövs för att kunna utföra
28
arbetet på ett effektivt sätt (Sommerville 2010). Hassan, Rezaei & Shahhosseini (2010) menar
att projektledarens kompetenser har en direkt inverkan på utvecklingsteamets prestation.
Dessa kompetenser är inte bara viktiga för att en projektledare ska kunna utföra sitt arbete
korrekt, det är även viktigt för teamet att de har en ledare som har de kompetenser som krävs
för att kunna vägleda utvecklingsteamet.
5.1.4. Kommunikationsförmåga
Utan en effektiv kommunikation kommer ett mjukvaruutvecklingsprojekt med all sannolikhet
att misslyckas. Kommunikation är nyckel till framgång (Komchaliaw & Wongthongtham
2010). All nödvänlig information som behövs måste kommuniceras vidare till alla de som
berörs av den. Då Vattenfallsmodellen är en dokumenttung process krävs det att
projektledaren hanterar dessa dokument samt kommunicerar med sitt utvecklingsteam så de
känner till nödvändig information för att uppnå målet (Gustavsson 2013). Utan
kommunikation blir det svårt att avgöra om utvecklingsfasen är färdig och om nästa fas kan
påbörjas. Även kommunikation i form av återkoppling är viktigt i detta läge. Utan fungerande
kommunikation försvåras utvecklingsteamets arbete, då det kan vara svårt för
utvecklingsteamet att förstå vilka deras roller är samt vilka arbetsuppgifter som ska utföras i
projektet.
5.2. RUP
5.2.1. Relationsförmåga
Ledarskapsrelationens dimension hos projektledaren består som sagt både av en yttre och
inre roll. I implementation av RUP handlar det om att i ett tidigt skede sätta upp realistiska
och nåbara mål för projektgruppen. Eftersom utvecklingsprocessen i RUP består av de fyra
olika faserna samt de olika iterationerna (IBM, 2014), är det betydelsefullt att relationen
mellan projektledaren och utvecklingsteamet byggs upp i starten. En god relation som byggs
upp från starten bidrar till högre tillit från både projektledarens och utvecklingsteamets sida.
Detta ökar motivationsfaktorn hos utvecklingsteamet (Chen, Chen & Chern 2012). Raccoon
(2006) menar att det handlar om att utveckla stabila relationer inom utvecklingsteamet för
att skapa effektivitet och samordning.
5.2.2. Personlighet
Då projektledning är en disciplin som är involverad under alla faser i utvecklingsmetoden
RUP är det av stor betydelse hur projektledarens personlighet påverkar utvecklingsteamet
och även hur projektet kommer att påverkas av projektledarens personlighet. Eftersom
projektledarens personlighet återspeglas i hur han/hon tänker, beter sig samt hur
hans/hennes livsstil ser ut, påverkas även utvecklingsteamet som han/hon arbetar med (Gao
& Ma 2009). RUP är en metod som kräver att faserna samverkar och därför är det sannolikt
att utvecklingsteamet följer sin projektledares personlighet.
5.2.3. Kompetens
RUP är uppbyggt av olika element som beskriver vad som ska produceras och vilka roller och
arbetsuppgifter som utvecklingsteamet har. Därför är det avgörande att en projektledare har
de kompetenser som krävs för att kunna tilldela dessa roller och uppgifter till
utvecklingsteamet (Merrill & Collofello 1997). Det kan vara avgörande för ett projekts resultat
att projektledaren har förmågan att tilldela arbetsuppgifter till den som är mest lämpad av
29
utvecklarna. Projektledaren bör även ha kompetens att inse att alla individer arbetar olika
beroende på deras personlighet. Det är projektledarens ansvar att koordinera så att projektets
mål uppfylls och samtidigt ta hänsyn till varje enskild utvecklare. Att ha mänsklig kompetens
är viktigt men likaså att ha teknisk kompetens när utvecklingen tillämpas med RUP, då alla
faser som ingår i RUP kräver teknisk kompetens. Tekniska individer kan vara svåra att
handskas med, då de tycker om att arbeta på ett självstyrt sätt, därför är det viktigt att
projektledaren har den tekniska kompetens som krävs för att kunna hantera dessa utvecklare
på bästa möjliga sätt (El-Sabaa 2001).
5.2.4. Kommunikationsförmåga
Projektledarens kommunikationsförmåga är en viktig del när RUP tillämpas för att projektet
ska kunna utföras på ett effektivt sätt. Även om faserna, elementen som beskriver hur arbetet
ska utföras och de sex tillämpningarna är väl definierade och väl beskriver hur arbetet ska
utföras för att nå ett slutresultat för projektet, är kommunikation fortfarande den metod som
ser till att hinder inte uppstår (Sommerville 2010). Hur välplanerat ett projekt än är kan olika
typer av hinder alltid förekomma. Därför bör projektledaren inte undervärdera
kommunikationens betydelse (Khan & Spang 2011). En bättre kommunikation leder oftast till
bättre prestation.
5.3. Spiralmodellen
5.3.1. Relationsförmåga
Det är betydelsefullt för projektledaren att skapa en relation med de utvecklare som ska
utföra arbete i projektet, då dessa utvecklare är kärnan för att genomföra arbetet.
Spiralmodellen är en metod med definierade arbetsuppgifter och mål under varje varv
(Wohlin 2005). Det är projektledarens ansvar att påverka sitt utvecklingsteam medvetet
genom sitt inflytande för att ta fram de bästa i sitt utvecklingsteam och tillsammans föra
projektet mot målet. Samarbete och samordning är viktigt när Spiralmodellen tillämpas då
varje varv utförs av individer som påverkar det slutliga projektresultatet på olika sätt (Jeng
2011).
5.3.2. Personlighet
Projektledarens ledarskapsnivå är avgörande för ett projekts framgång eller misslyckande.
Ledarskapsnivån beror på hans/hennes beteende och basaeras på personlighetsdrag (Gao &
Ma 2009). Spiralmodellen är en metod där projektledaren är involverad och synlig. I varje
varv krävs det att han/hon har en personlighet som utvecklingsteamet kan återspegla sig i för
att projektet ska nå sitt mål. Det är avgörande att projektledaren har en personlighet med hög
öppenhet, eftersom riskhantering är en aktivitet som pågår under hela Spiralsmodellens
livscykeln. Risker kan många gånger vara oförutsägbara och under hög osäkerhet. Därför
krävs det att projektledaren är öppen för de förändringar som kan ske när risker inträffar
(Judge & Bono 2000).
5.3.3. Kompetens
Eftersom Merrill & Collofello (1997) menar att dålig projektledning ökar
utvecklingskostnaderna snabbare och mer än någon annan faktor, är det viktigt att en
projektledare har de kompetenser som behövs för att kunna leda sitt utvecklingsteam mot
målet. Spiralmodellen kräver planering, uppföljning och styrning av projektledaren, och för
att kunna hantera dessa krävs det att projektledaren har den rätta förmåga att kunna utföra
arbetet på ett effektivt sätt. Mjukvaruutvecklingsprocessen måste följas kontinuerligt och
30
problem som inträffar ska det snabbt reageras på för att minska de effekter som kan innebära
negativ påverkan i projektet. Khan & Spang (2011) menar att utan projektledarens rätta
förmåga att hantera dessa problem kommer projektet med stor sannolikhet att misslyckas.
5.3.4. Kommunikationsförmåga
En utvecklingsprocess som Spiralmodellen med väl definierade mål och beskrivning av hur
arbetet ska utföras kan uppfattas som enklare för projektledare. Risken finns att
kommunikationen mellan projektledare och resten av utvecklingsteamet blir sämre då de
anser att kommunikationen inte behövs eftersom målen och arbetsuppgifter är väldefinierade
i Spiralmodellen. Kommunikation behövs, oavsett hur tydligt Spiralsmodellens arbetssätt är.
Det är projektledarens ansvar att informera och uppdatera sitt utvecklingsteam om det sker
förändringar med projektet. För varje varv som är genomfört bör projektledaren ge
återkoppling på arbetet. Återkoppling kan vara både negativ och positiv (Hocenski & Popovic
2009). Det är projektledarens skyldighet att kommunicera till sitt utvecklingsteam hur
arbetet uppfattas och därför bör återkoppling sker kontinuerligt efter varje varv under
utvecklingsfasen.
5.4. Scrum
5.4.1. Relationsförmåga
Scrum baseras på tydliga rollbeskrivningar och är beroende av självstyrande individer i
utvecklingsteamet eftersom en bestämd projektledarroll saknas (Schwaber 2004). Scrum
Mastern har en coachande, engagerande roll men har inga större beslutsbefogenheter utöver
sin roll i Scrum Teamet. För att skapa framgångsrika mjukvaruutvecklingsprojekt med
Scrum-modellen som metod förutsätter det att Scrum Mastern arbetar för att skapa hållbara
relationer inom utvecklingsteamet. Därför bör Scrum Mastern i detta fall fokusera mer på den
inre dimensionen av projektledarskapet, d.v.s. att främja personliga relationer (Raccoon 2006).
Scrum Mastern besitter inte alla de befogenheter som normalt ingår i projektledarrollen.
Ledarskapet som Scrum Mastern har handlar om att främja interaktionen, engagemanget och
relationerna i utvecklingsteamet.
5.4.2. Personlighet
Avsaknaden av den tydliga projektledarrollen i Scrum resulterar i att vissa drag i
personligheten hos Scrum Mastern inte är lika avgörande för att effektivt ledarskap. Detta
handlar mer om att graden av ledarskapsförmåga inte är lika viktig då Scrum Mastern inte
har den befogenheten. Egenskaperna i Five Factor model (Barrick & Mount 1991) är dock lika
avgörande även i projekt som utgår ifrån Scrum-modellen, om inte viktigare. Scrum Mastern
bör vara en projektledare som lyckas påverka utvecklingsteamet med sin personlighet i form
av dessa drag. Karaktären Scrum Master ska skapa balans, motivering och vara ett stöd för
utvecklingsteamet i arbetet och måste göra detta genom sin personlighet.
5.4.3. Kompetens
Projektledarens kompetenser är viktiga i Scrum-modellen eftersom denne måste besitta
förmågan att underlätta och öppna upp för kommunikation i projektet för att hantera problem
som kan uppkomma under utvecklingsteamets arbete. Detta är en mänsklig kompetens och
denna förmåga kan anses vara den mest avgörande för att kunna bidra med ett effektivt
ledarskap (Durham & Durham 2007). Scrum Mastern måste vara lyhörd för
utvecklingsteamets behov och förstå olika människors personligheter. Beslutsfattandet inom
Scrum görs i utvecklingsteamet och utgår således från en självstyrning i projektet. Scrum
31
Mastern och utvecklingsteamets konflikter kan minskas genom att ansvar ligger hos den
enskilde individen under utvecklingsprocessen. Scrum Mastern bör därför besitta förmågan
att skapa en miljö där respekt utvecklas inom projektet, annars kan självstyrningen bidra
med en oönskad effekt i projektet i form av egna priorteringar.
5.4.4. Kommunikationsförmåga
Kommunikationen är basen i Scrum-modellen och genom dagliga möten och ständig planering
och återkoppling skapas ett flexibelt arbetssätt (Schwaber 2004). För att kommunikationen
verkligen ska fungera i praktiken är Scrum Masterns roll som kommunikatör avgörande då
det är denne som främjar relationer inom utvecklingsteamet och fungerar som samordnare för
utvecklingsteamets intressen. Kommunikationen handlar inte bara om öppna dialoger utan
även förmågan att verkligen förstå och lyssna till utvecklingsteamets olika behov (Keretho,
Lent & Pinkowska 2011). Att förmedla tydliga budskap i alla led är avgörande i Scrummodellen och det är Scrum Masterns uppgift att se till att kommunikationen fungerar som det
främsta medlet för att nå projektmålet. Om Scrum Mastern, eller övriga medlemmar för den
delen, skulle ha en bristande kommunikationsförmåga skulle det skapa stora svårigheter i
implementering av Scrum i projektet.
5.5. XP
5.5.1. Relationsförmåga
Eftersom projektledarrollen är otydligt definierad i XP blir det svårt att skapa samhörighet,
engagemang och motivering hos utvecklingsteamet. Relationerna inom utvecklingsteamet är
viktiga för att kunna utföra arbetet och nå projektmålet. Projektarbetet skulle kunna utföras
på egen hand av teamet men utan en tydlig ledarinsats kan det komma att leda till skilda
föreställningar och attityder i utvecklingsteamet (Jeng 2011), samtidigt som det blir svårt att
hantera konflikter. Ett scenario i XP kan vara att en otydlig ledarroll leder till att
integrationen av människorna i utvecklingsteamet minskar. Detta kan i sin tur resultera i
svårigheter att nå projektmålet (Raccoon 2006).
5.5.2. Personlighet
XP är en utvecklingsmetod som har för avsikt att hantera komplexa mänskliga samarbeten
(Hughes & Cotterell 2009). Detta kräver att projektledaren besitter samtliga egenskaper
enligt Five factors modellen Barrick & Mounts (1991). Detta kräver mycket av projektledaren
eftersom denne bör ha förmågan att kunna anpassa sina karaktärsdrag efter olika situationer
och olika människor. Projektledaren måste ha förmågan att hantera både interna och externa
dimensioner i arbetet. Med XP är detta särskilt relevant då kunden är närvarande då
utvecklingsteamet programmerar (Xprogramming, 2014). Därför är det viktigt att
projektledaren i sådana fall lyckas skapa extraversion både hos sig själv samt
utvecklingsteamet för att lyckas i externa och sociala sammanhang.
5.5.3. Kompetens
För en projektledare i XP-sammanhang är det även i detta fall avgörande att det finns en
förståelse för de mänskliga kompetenserna menar Keretho, Lent & Pinkowska (2011). Det
handlar om att denne innehar förmågan att planera och leda projektet mot slutmålet. I detta
avseende är det också viktigt att projektledaren har en förståelse för den komplexa
projektmiljön och besitter tillräckligt med erfarenhet för att kunna leda projektet framåt med
XP-modellen. Då det handlar om att skapa effektivitet i mänskliga samarbeten är det viktigt
att projektledaren förstår och i högsta grad anpassar arbetet efter de mänskliga aspekterna.
32
Kompetensen att selektivt kunna bestämma vem som är rätt person för rätt arbete bör också
finnas hos projektledaren (Creighton 1990).
5.5.4. Kommunikationsförmåga
En av XP:s fyra värderingar är kommunikation och återkoppling. Detta handlar om att
löpande ha kontakt med kunden och att identifiera åtgärder för att uppnå önskvärt resultat
(Hughes & Cotterell 2009). Projektledarens kommunikationsförmåga är central för att kunna
nå ut med information och ge tydliga budskap till utvecklingsteamet (Hocenski & Popovic
2009). XP är en modell som möjliggör detta genom att kommunikation och återkoppling är en
viktig aspekt i utförande av metoden (Hughes & Cotterell 2009). Detta gör att projektledaren
och utvecklingsteamet ständigt måste arbeta med öppenhet och uppföljning.
5.6. DSDM
5.6.1. Relationsförmåga
Projektledarens roll i DSDM handlar om att genom relationsuppbyggande skapa effektiva
utvecklingsteam som arbetar samordnat mot projektmålet (Dsdm, 2014) För att kunna göra
detta krävs det att denne har en god förmåga att förstå känslomässiga samspel och genom
detta kunna skapa gemensamma föreställningar och attityder till projektet inom
utvecklingsteamet (Raccoon 2006). DSDM utgår ifrån ett agilt utvecklingsperspektiv vilket
innebär fokus på flexibilitet och förändringsbara processer. Men grundtanken med DSDM är
också det faktum att misslyckade mjukvaruutvecklingsprojekt ofta beror på mänskliga
problem snarare än tekniska problem (Hughes & Cotterell 2009). På grund av denna
tankegång är det helt avgörande att projektledaren kan främja relationer inom
utvecklingsteamet (Keretho, Lent & Pinkowska 2011).
5.6.2. Personlighet
Projektledarskapet är väsentligt i DSDM eftersom det är projektledaren som genom sina
befogenheter delegerar ansvarsområden och utför rollbeskrivningar. För att kunna skapa ett
utvecklingsteam som arbetar iterativt och inkrementellt, vilket DSDM förutsätter, är
projektledares personlighetsdrag avgörande (Eisenberg & Graziano 1997). Projektledaren
måste ha en känsla för mänskliga beteenden och kunna återspegla sin egen vision av
projektet till utvecklingsteamet. Öppenhet är grunden i agila projekt då det är detta som
skapar grunden för förändring (Thite 1999). Projektledarens förmåga att kunna ge vägledning
i projektet påverkar även utvecklingsteamets prestation vilket i sin tur påverkar hur de olika
arbetsstegen genomförs i projektets olika faser.
5.6.3. Kompetens
Projektledarens roll utgår framförallt ifrån att ledaren besitter förståelse för mänskligt
beteende eftersom det är dennes uppgift att samordna utvecklingsteamet genom dessa.
Ledningsrollen i DSDM handlar till stor del om detta samtidigt som färdigheterna i form av
planering, styrning och uppföljning också är avgörande (Dsdm, 2014). Om projektledarens
förmåga inför detta brister kommer detta att skapa svårigheter i arbetet med DSDM. Det
kräver en proaktiv reaktionsförmåga hos projektledaren för att kunna balansera såväl den
tekniska som den mänskliga dimensionen (Creighton 1990).
5.6.4. Kommunikationsförmåga
Projektledarens förmåga till kommunikation är också väsentlig inom DSDM eftersom det är
denne som ställer upp ansvars- och rollfördelning och skapar den gemensamma strävan att
uppnå projektmålet (Merrill & Collofello 1997). Det är avgörande att projektledaren således
33
förmedlar ett konkret budskap till utvecklingsteamet gällande vad som ingår i DSDM:s åtta
principer för att implementeringen ska bli effektiv. Det finns dock inte en väldefinierad metod
för återkoppling i DSDM vilket också anses vara en viktig aspekt i kommunikationsförmågan.
Efterprojektfasen omfattar reflektion men det kan dock finnas en avsaknad av uppföljning och
återkoppling i de olika faserna överlag vilket leder till att projektledaren måste ta
återkopplingsbegreppet i större beaktning vid arbete med denna utvecklingsmetod (Hughes &
Cotterell 2009).
34
6. Slutsats
Detta avsnitt besvarar de två uppställda frågeställningarna. För att tydligöra resultatet av
frågeställning 2 finns en tabell som visar om framgångsrika projektledares egenskaper har en
stor eller liten påverkan på de olika utvecklingsmetoderna.
Det som karaktäriserar ett gott projektledarskap är att projektledaren kan skapa relationer
med sitt utvecklingsteam och främjar sambandet mellan dem. Projektledaren bör också ha
den personlighet som krävs för att kunna motivera och engagera sitt utvecklingsteam. De
personlighetsdrag som krävs är öppenhet, emotionell stabilitet, vänlighet, samvetsgrannhet
och extraversion. Det handlar även om att projektledaren har de kompetenser som behövs för
att kunna hantera projektet och har en kommunikationsförmåga för att kunna upplysa om
nödvänlig information som berör projektet. Projektetresultatet påverkas negativt om
samspelet inte finns mellan utvecklingsmetod och egenskaper hos framgångsrika
projektledaren. T.ex. en utvecklingsmetod som förutsätter kommunikation men om
projektledare saknar kompetensförmågan kan det medföra problem som leder till ett
misslyckat projekt. Förståelse och balans mellan dessa måste finnas. Projektledarens
egenskaper måste vara påtagliga i alla typer av projekt. En annan aspekt kan vara att
projektledaren har alla dessa goda egenskaper men utvecklingsprojektet kan ändå misslyckas
p.g.a. utvecklingsmetoden som använts inte stödjer dessa egenskaper. Förbättrat samspel
mellan de goda egenskaperna och utvecklingsmetoder leder till lyckade projekt.
Tabell 5: Visar om det är stor eller liten påverkan som framgångsrika projektledares
egenskaper har på de olika utvecklingsmetoderna.
Vattenfallsmodellen
RUP
Spiral
Scrum
XP
DSDM
Relationer
Stor
Stor
Stor
Stor
Stor
Stor
Personlighet
Stor
Stor
Stor
Liten
Stor
Stor
Kompetenser
Stor
Stor
Stor
Liten
Liten
Stor
Kommunikation
Stor
Stor
Stor
Stor
Stor
Stor
Som matrisen i tabell 5 ovan visar har de fyra egenskaper som kännetecknar en framgångsrik
projektledare stor påverkan när Vattenfallsmodellen, RUP och Spiralmodellen tillämpas.
Dessa tre metoder betraktas som de traditionella utvecklingsmetoderna. Det gemensamma
med dessa tre metoder är att projektledaren är den som har det största ansvaret under hela
utvecklingsprocessen. Det finns ett tydligt fokus på projektledarens arbetsuppgifter i de
metoderna. Därför är det inte helt överraskande att projektledaren har så stor påverkan inom
de traditionella metoderna. Man kan säga att traditionella metoder är beroende av
projektledaren. Därför är det betydelsefullt att en projektledare som tillämpas någon av de tre
traditionella metoderna har de egenskaper som kännetecknar en framgångsrik projektledare
för att projektet ska uppnå ett lyckat resultat.
Framgångsrika projektledares egenskaper har minst påverkan med tillämpning av Scrum.
Det kan bero på att det inte finns en tydlig projektledarroll inom Scrum. Scrum Mastern
saknar ledningsansvar vilket betyder att projektet inte är beroende av Scrum Mastern
35
eftersom projektet är självstyrande av de individer som utför arbetet. Men det betyder inte att
Scrum Mastern inte har påverkan alls. Eftersom Scrum-modellen styrs och utförs av de olika
individerna är det betydelsefullt att Scrum Mastern kommunicerar kontinuerligt och ger
återkoppling. Därför är Scrum Masterns kommunikationsförmåga viktig. Att Scrum Mastern
har en bra relation med teamet är också viktigt och har en stor påverkan inom Scrummodellen. Även om Scrum Mastern saknar ledningsansvar är Scrum Mastern fortfarande den
som motiverar sitt team. Därför är det viktigt att skapa en bra relation med teamet för att
kunna öka prestationen. Dock är Scrum Masterns kompetens och personlighet inte lika
avgörande. Eftersom arbetsuppgifterna är självstyrda av teamet är Scrum Masterns
kompetens inte lika viktigt i detta sammanhang. De egenskaper som kännetecknar en
framgångsrik projektledare har både stor och liten påverkan under XP-processen. De
egenskaper som har liten påverkan är projektledarens kompetensförmåga. Eftersom XPs tolv
tillämpningar är särskilt riktat till utvecklarna själva krävs det inte stor insats av
projektledaren själv. Men de andra tre egenskaper har stor påverkan. Även om
projektledarollen inte är väldefinierad i XP är relationsbandet mellan projektledare och
teamet alltid viktigt. Det är genom en bra relation som tillit skapas och tillit ökar
motivationsfaktorn. Alla de fyra egenskaper som kännetecknar en framgångsrik projektledare
har stor påverkan när DSDM tillämpas. Även om DSDM betraktas som en agil metod på
grund av att metoden är iterativ och inkrementell är metodens synsätt väldigt lik de
traditionella metoderna. DSDM är en metod för projektledning som påminner om de synsätt
som finns hos de traditionella metoderna. Eftersom projektledning är kärnan i DSDM har de
egenskaper som är viktiga för en projektledare stor inflytande i DSDM.
36
7. Vidare forskning
Det finns mycket forskning kring projektledning och de olika utvecklingsmetoderna för
mjukvaruutveckling var för sig. Men det finns väldigt lite forskning om dessa två aspekter
tillsammans. Det har varit svårt att hitta relevant information om samspelet mellan
projektledare och de olika utvecklingsmetoderna. Det mesta som har skrivits handlar enbart
om projektledning eller utvecklingsmetoder utan någon som helst interaktion mellan dessa
två ämnen. Projektledning och utvecklingsmetoder är två ämnen som är högaktuella.
Eftersom projektledning är viktigt inom mjukvaruutveckling och många misslyckade projekt
beror på dålig projektledning borde forskning kring samspelet mellan dessa två ämnen
undersökas mer. Nya utvecklingsmetoder introduceras för att minska antalet misslyckade
projekt. Men statistik visar att antalet misslyckade projekt fortfarande är väldigt oroväckande
för branschen En dålig projektledare som har svårt med att leda utvecklingsteamet kommer
med stor sannolikhet inte att lyckas med att leverera ett gott resultat till kunden, oavsett
vilken utvecklingsmetod de än använder. Även om en projektledare har alla de egenskaper
som kännetecknar en framgångsrik projektledare är det nästan omöjligt att lyckas med ett
projekt om det är fel utvecklingsmetod som används. Vidare forskning kan t.ex. vara hur
projektledning och utvecklingsmetoder påverkar varandra, i vilken grad påverkan sker eller
om en projektledare med speciella egenskaper ska använda en speciell utvecklingsmetod.
Djupintervjuer med ett antal projektledare och utvecklare hade varit intressant för att se om det ger
samma resultat som litteraturstudien. Man kan dock förutse att projektledare och utvecklare har
skilda målbilder om vilka egenskaper som kännetecknar en framgångsrik projektledare. Vilka
egenskaper som kännetecknar en framgångsrik projektledare för en utvecklare kan nog blir mer
snarlikt resultatet från litteraturstudien. Detta därför att resultaten från litteraturstudien handlar om
interaktionen mellan projektledare och utvecklare. Synpunkter från olika projektledare skulle kunna
ge annorlunda resultat. En projektledare fokuserar mer på själva projektet än på de mänskliga
interaktionerna vilket kan ge ett annorlunda resultat.
37
Källförteckning
Agilemanifesto. (2001). Manifesto for agile software development. http://agilemanifesto.org/.
(Hämtad 2014-09-02).
Bakka, J., Fivelsdal, E & Lindkvist, L. (2006). Organisationsteori. 5. uppl. Malmö: Liber AB.
Bandinelli, S., Fuggetta, A., Lavazza, L., Loi, M & Picco, G.P. (1995). Modeling and improving
an industrial software process. IEEE Transaction on Software Engineering. vol. 21, no. 5.
pp.440-454.
Barrick, M & Mount, M. (1991). The Big Five Personality Dimensions and Job Performance: A
Meta-Analysis. Personnel Psychology 44. pp. 1-26
Boehm, B. (1986). A spiral model of software development and enhancement. SIGSOFT
Software Engineering Notes. Vol 11, no4. pp. 22-41.
Bohner, S. , McCriskard, S & Smith, J. (2005). Project Management for the 21st Century:
Supporting Collaborative Design through Risk Analysis. 43rd ACM Southeast Conference. pp.
300-305.
Brewer, J. L.( 2005). Project Managers, Can We Make Them or Just Make Them Better?
SIGITE ´05. pp. 167-173.
Bryman, Alan. (2011). Samhällsvetenskapliga metoder. 2. uppl. Stockholm: Liber AB.
Carbone, T & Sampson, G. (2004). Project Manager Skill Development: A Survey of Programs
and Practitioners. Engineering Management Journal 16.3. pp. 10-16.
Chen, P., Chen, C & Chern, C. (2012). Software project team characteristics and team performance: Team motivation as a moderator. 19th Asia-Pacific Software Engineering Conference.
pp. 565-570.
Costa, P & McCrae, R. (1991). Facet scales for agreeableness and conscientiousness: A revision
of the NEO personality inventory. Personality Individual Differences. pp. 887- 898.
Creighton, W. J. (1990). Managing Technical Staff. 18th annual ACM SIGUCCS. pp. 63-65.
Durham, R. & Durham, M. (2007). What to do when things go wrong an ethical solution. IEEE
Paper No. PCIC-2007-3
DSDM. (2014). Atern principles. http://www.dsdm.org/content/4-atern-principles. (Hämtad
2014-05-01).
Dvir, D., Sadeh, A & Malach-Pines, A. (2006). Projects and project managers: the relationship
between project managers’ personality, project types, and project success. Project Management
Journal. pp. 36-48.
Eliasson, A. (2013). Kvantitativ metod från början. 3. uppl. Lund: Studentlitteratur AB.
El-Sabaa, S. (2001). The skills and career path of an effective project manager. International
38
Journal of Project Management 19. pp.1-7.
Eisenberg, H. & Graziano, W. (1997). Agreeableness: A dimension of personality. Handbook of
Personality Psychology. Academic Press. pp. 795-824.
Furnham, A & Hough, L. (2002). Importance and use of personality variables in work settings.
Comprehensive Handbook of Psychology. Vol. 12. pp. 131-169.
Gao, J & Ma, H. (2009). A Research On the Construction of Team Leadership Effectiveness
and its relationship with Big-five Personality. International Colloquium on Computing,
Communication, Control, and Management. pp. 457-460.
Gemuenden, H & Hoegl, M. (2001). Teamwork quality and the Success of Innovative Projects:
A theoretical concept and empirical evidence. Organization Science, Vol. 12. No. 4. pp. 435–
449.
Gustavsson, T. (2013). Agile- konsten att slutföra projekt. 2. Uppl. Karlstad: TUK Förlag AB.
Halvorsen, K. (1992). Samhällsvetenskaplig metod. 1. uppl. Lund: Studentlitteratur AB.
Hassan, M., Rezaei, M & Shahhosseini, V. (2012). Competency Based Optimized Assignment
of Project Managers to Projects. 12th International Conference on Computer Modelling and
Simulation. pp. 311-316.
Hocenski, Z & Popovic, K. (2009). Conflict management. ICSE’09 Workshop. pp. 15-19.
Howard, A. (2001). Software Engineering Project Management. Communications of the ACM.
Vol. 44, No 5. pp. 23-24.
Hughes, B & Cotterell, M. (2009). Software Project Management. 5. uppl. Glasgow: McGrawHill Education.
IBM. (2014). IBM Rational Unfied Process (RUP).
http://www01.ibm.com/software/rational/rup/ (Hämtad 2014-04-28).
Jalil, Zunera & Shahid, A. (2008). Is Non Technical Person A Better Software Project Manager.
International Conference on Computer Science and Software Engineering. pp. 1-5.
Jeng, D. (2011). Structural analysis on Team Iternal Soft Factors to Project Success. IEEE
International Conference on Fuzzy Systems. pp. 523-530.
Judge, T & Bono, J. (2000). Five-factor model of personality and transformational leadership.
Journal of Applied Psychology. pp. 751–765.
Khan, R & Spang, K. (2011). Critical Success Factors for International Projects. The 6th IEEE
International Conference on Intelligent Data Acquisition and Advanced Computing Systems.
pp. 879-883.
Keretho, S., Lent, B & Pinkowska, M. (2011). Process Based Identification of Software Project
Manager Soft Skills. Eighth International Joint Conference on Computer Science and Software
Engineering. pp. 343-348.
Komchaliaw, S & Wongthongtham, P. (2010). A state of the art review on software project
performance management. IEEE International Conference on Digital Ecosystems and
Technologies. pp.653-655.
39
Kontract. (2013). Fem vanliga fallgropar i IT-projekt. http://www.kontract.se/academy/femvanliga-fallgropar-i-it-projekt (Hämtad 2014-02-21).
Li, F & Wang, Y. (2009). How does project managers´personality matter?: building the linkage
between project managers´ personality and the success of software development projects. 24th
ACM conference. pp. 867- 874.
LTH (Lunds tekniska högskola). (U.å). Projektledning.
http://www.bekon.lth.se/fileadmin/byggnadsekonomi/Projektledning.pdf. (Hämtad 2014-08-16).
Marshall, C & Rossman, G (2010). Designing Qualitative Research. 5. uppl. Thousand Oaks:
CA: Sage.
Merrill, D & Collofello, J.S. (1997). Improving software project management skills using a
software project simulator. Frontiers in Education Conference. Vol 3. pp. 1361-1366.
Patel, R & Davidson, B. (2011). Forskningsmetodikens grunder. 4. uppl. Lund:
Studentlitteratur AB.
Quotient. (2012). The importance of a great project manager.
http://quotient.net/blog/2012/6/25/the-importance-of-a-great-project-manager/ (Hämtad 201403-10).
Raccoon, L.B.S. (2006). A Leadership Primer for Software Engineers. ACM SIGSOFT
Software Engineering Notes. Vol. 3, No 4. pp. 10-15.
Rehman, I., Rauf, A., Shahid, A & Ullah, S. (2010). Scope management in agile versus
traditional software development methods. National Software Engineering Conference 2010.
Rienecker, L & Jørgensen, P. (2008). Att skriva en bra uppsats. 2. uppl. Malmö: Liber AB.
Royce, Winston. (1970). Managing the Development of Large Software Systems. IEEE
WESCON. pp. 1-9.
Schwaber, K. (2004). Agile project management with scrum. 1. uppl. Microsoft Press.
Sommerville, I. (2010). Software engineering. 9. uppl. Boston: Pearson Education.
Tarim, T. (2013). Managing Technical Professionals: When to Know to Transition From Technology Manager to Individual Contributor. IEEE ENGINEERING MANAGEMENT REVIEW,
VOL. 41, NO. 4. pp.3-4.
Taylor, H & Woelfer, J. (2009). Critical Skills IT Project Management and How They are
Learned. ACM SIGMIS CPR 09. pp. 103-112.
Thite, M. (1999). Leadership: a critical success factor in IT project management. In Proceedings of Portland International Conference on Management of Engineering and Technology:
Technology and Innovation Management. pp. 298-303.
Thurén, T. (2013). Källkritik. 3. uppl. Malmö: Liber AB.
Tonnqist, B.( 2007). Projektledning. 2. uppl. Stockholm: Bonnier Utbildning.
40
Wohlin, C. (2005). Introduktion till programvaruutveckling. 1. uppl. Lund: Studentlitteratur
AB.
Xprogramming. (2014). What is Extreme Programming. http://xprogramming.com/what-isextreme-programming/. (Hämtad 2014-05-01).
41