Projektplaneringsverktyg och mjukvaruprojekt

MALMÖ HÖGSKOLA

Examensarbete

15 högskolepoäng, grundnivå

Projektplaneringsverktyg

och mjukvaruprojekt

Project planning tools and software projects

Författare: Peter Jönsson

Examen: Kandidatexamen 180 hp Handledare: Göran Hagert Huvudämne: Datavetenskap Examinator: Marie Friberger Program: Data och telekom

Projektarbete är ett dominerande arbetsätt inom de flesta branscher. I IT/IS-branschen är det utbrett arbetssätt och en central del av hur organisationer är uppbyggda. I denna uppsats behandlar vi projektarbete inom IT/IS-branschen, med fokus på tid- och resursplanering, samt realisering av mjukvaruprojekt. Utifrån ledande projektledningsmetodik tas ett mätinstrument fram med tänkta funktioner i ett projektplaneringsverktyg, för att vidare undersöka ledande verktyg på marknaden. Projektarbete är historiskt sätt ett nytt fenomen, och fortfarande finns det mycket outforskat. Studien bygger på en kvalitativ sekundäranalys av den projektledningslitteratur som dominerar på svenska högskolor och universitet. Det vägs även in annan litteratur för att styrka våra slutsatser. I teoridelen redovisar vi vilka mjukvaruprocesser som är vanligast vid ett ingenjörsmässigt förhållningssätt, samt de generella arbetssteg som används inom projektledningsmetodik. Det teoretiska ramverket ligger vidare till grund för analysen. Uppsatsen avrundas sedan med att presentera empirin, och vidare görs en löpande analys av materialet. Vi påvisar 16 viktiga funktioner som ett planeringsverktyg bör tillhandahålla, samt en brist hos ledande verktyg på marknaden. Slutligen diskuteras studiens validitet, och förslag till vidare studier tas upp.

Abstract

In the IT/IS industry it is the dominating practices and a central part of how organizations are structured. In this report we deal with project work in the IT/IS industry, focusing on the time and resource planning, and realization of software projects. Based on the leading project methodology a benchmark is developed with thoughtful features in a project planning tool to further investigate the leading tools in the market. Project work is historically a new phenomenon, and there are still many unexplored. The study is based on at qualitative secondary analysis of the project management literature that dominates in Swedish universities. It also considered in other literature to substantiate our conclusions. In the theoretical part we present the software processes that are common at an engineering approach, and the general work steps used in the project management methodology. The theoretical framework is also the basis the analysis. The paper is the rounded up to present empirical data, and a continuous study of the material is made. We demonstrate 16 key features such as planning tool should provide, as well as a weakness of the leading tools in the market. Finally, the validity of the study are discussed, and suggestions for further study are given.

Nyckelord: projektledning, projektledningsmetodik, projektplaneringsverktyg, mjukvaruprocess, mjukvaruutveckling, programvarukonstruktion.

1. Inledning ... 1 1.1 Bakgrund ... 1 1.2 Problemformulering ... 3 1.3 Syfte ... 4 1.4 Frågeställning ... 4 1.5 Målgrupp ... 4 1.6 Avgränsning ... 5 1.7 Definitioner ... 5 2. Metod ... 7 2.1 Metodval ... 7

2.1.1 Induktiv eller deduktiv ansats ... 7

2.1.2 Kvalitativ sekundäranalys... 7

2.1.3 Flermetodsforskning ... 8

2.2 Strategi vid litteraturval ... 8

2.2.1 Dominerande litteratur ... 9

2.2.2 Presentation av studiens huvudlitteratur ... 9

2.3 Strategi vid val av undersökningsobjekt ... 10

2.3.1 Två kategorier av projektplaneringsverktyg ... 10 2.3.2 Ytterligare sållning ... 11 2.4 Metoddiskussion ... 11 2.4.1 Källkritik ... 12 3. Teori ... 14 3.1 Mjukvaruprocesser ... 14 3.2 Processmodeller ... 15 3.2.1 Vattenfallsmodellen ... 15 3.2.2 Inkrementell utveckling ... 16 3.2.3 Återanvändning ... 17

3.3 Generella steg för projektledning ... 18

3.3.1 Förstudie ... 18 3.3.2 Planering ... 18 3.3.3 Genomförande ... 19 3.3.4 Överlämning ... 19 3.3.5 Avslut ... 20 3.4 Agil projektledning ... 20 3.4.1 Scrum ... 20

4. Resultat och diskussion ... 22

4.1 Övergripande projektplanering ... 22

4.1.1 Resultat ... 22

4.1.2 Diskussion ... 23

4.2 Avgränsa och integrera ... 25

4.2.1 Resultat ... 25 4.2.2 Diskussion ... 26 4.3 Planera ... 27 4.3.1 Resultat ... 27 4.3.2 Diskussion ... 32 4.4 Organisera ... 34 4.4.1 Resultat ... 34 4.4.2 Diskussion ... 35

4.5 Sammanfattning och jämförelser ... 36

4.5.1 Resultat ... 36

Sammanfattning av funktioner ... 36

Presentation av undersökningsobjekten ... 38

4.5.2 Diskussion ... 39

5. Avslutande diskussion ... 41

5.1 Endast ett hjälpmedel ... 41

5.2 Urvalet kan påverka ... 42

5.3 Projektplaneringsverktygets värde ... 42

5.4 Studiens styrkor och svagheter ... 42

5.5 Vidare studier ... 43

Figur 1: Vattenfallsmodell...15

Figur 2: Inkrementell utveckling...16

Figur 3: Återanvändningsprocess...17

Figur 4: Generella arbetssteg för projektledning...18

Figur 5: Projektets realiseringsflöde...19

Figur 6: Scrummodell...21

Figur 7: Product Breakdown Structure (PBS)...26

Figur 8: Work Breakdown Structure (WBS)...28

Figur 9: Logiskt nätverk...29

Figur 10: Gantt-schema...30

Figur 11: Resursgraf i tabellform...31

Figur 12: Resurshistogram...31

Figur 13: Projektplaneringsflöde...32

Figur 14: Organizational Breakdown Structure (OBS)...34

Tabellförteckning

1

1. Inledning

Inledningsvis presenteras en bakgrund till studien, samt tidigare forskning inom projekt, projektledning och projektplanering som är av relevans för studiens problemformulering. Vidare mynnar problemformuleringen ut i syfte och frågeställning. Inledningen avrundas sedan med vilken målgrupp denna uppsats riktar sig till, hur undersökningen är avgränsad och en lista med definitioner.

1.1 Bakgrund

Mjukvara finns överallt i vår vardag och är en viktig del i samhället. En modern värld fungerar inte utan det. Nästan alla elektriska produkter har med någon form av mjukvara, och ser man i det stora perspektivet är all infrastruktur beroende av det. Till exempel är dagens finansiella system uppbyggda och beroende av avancerad mjukvara. Mycket av industriell tillverkning är automatiserad och även den beroende. Därför ställs det bara större och större krav på utvecklingen av mjukvara (Sommerville 2010).

Mjukvara är något som är abstrakt och ”intangible”, vilket närmast kan översättas som icke påtaglig eller icke fysisk. Några problem som utvecklingen står inför är ökade krav på system, snabbare leveranser, nya möjligheter som inte är testade tidigare, system som inte har tillverkats med ingenjörmässiga metoder och system som uppstår oplanerat (Sommerville 2010).

Utvecklingen av mjukvara bedrivs i de flesta fall i projektform och består av en grupp individer med olika expertområden varav minst en som leder projektet. Ordet projekt kommer från de latinska orden pro som betyder fram och jacere som betyder kasta. Flera andra ord har samma ursprung, såsom projektera, projektion och projektil (Jansson & Ljung 2004). Ordet projekt används ofta i vardagligt språk och syftar då vanligen på t.ex. projektet komma i form, projektet att resa på semester, renovera huset, etc. I arbetslivet talas det om att projekt är att utveckla en ny produkt (Jansson & Ljung 2004).

Ordet grupp härstammar från italienskans gruppo och betyder ungefär knut, skara

eller hop (Wessén 1982). Enligt Homans (1974) definieras en grupp med ett antal människor som kommunicerar med varandra under en viss tidsperiod, och är till antalet tillräckligt få för att varje individ skall kunna kommunicera med alla i konstellationen. Kommunikationen måste vara ansikte mot ansikte och inte i andra hand. Enligt nationalencyklopedin (2012) är individer som har något gemensamt en grupp. Alltså talar teorierna emot varandra, då Homan menar att gruppen måste existera så pass länge att medlemmarna hinner kommunicera med varandra, medan enligt nationalencyklopedin räcker det att några individer har något gemensamt.

Svedberg (2007) talar om två typer av grupper (formella och informella), där t.ex. sju personer i en hiss är ett exempel på en informell grupp. De sju personerna i hissen utgör en informell grupp såvida det inte sker ett strömavbrott under en

2

tidsperiod så ansikte mot ansikte kommunikation uppstår. Homan och Svedberg har alltså liknande definition på begreppet. Svedberg (2007) beskriver även att i en grupp samspelar medlemmarna för att nå ett mål eller för att utföra en uppgift, och sätter den nedre gränsen för antalet medlemmar till tre för att få kallas för grupp. I denna studie är det Svedbergs definition på grupp som aktuell. Sätts begreppen projekt och grupp ihop får man enligt Svedberg (2007) en grupp som ges ett uppdrag eller en beställning, en budget och en deadline. Medlemmarna har ofta olika kompetenser, och kan komma från olika organisationer.

Projektgrupper innefattar alltid minst en projektledare, vars uppgift är att leda projektet för att gruppen skall kunna skapa det avsedda resultatet. Individen som har rollen projektledare skall inte själv skapa resultatet (om individen inte har dubbla roller förstås), utan leda de individer som skall skapa det. Projektledarens huvudsakliga uppgift är att underlätta för gruppmedlemmarna, så att de tillsammans kan nå projektmålet (Jansson & Ljung 2004).

Samtidigt som begreppet projekt fick den betydelse det har idag, myntades ett annat begrepp vid namn programvarukonstruktion eller programvaruteknik (software engineering). Begreppet innefattar tekniker för kravhantering, design, evolution, kvalitet, projektledning mm. Detta innebär att mjukvaran tillverkas enligt ingenjörsmässiga metoder, och identifieras av att lösa problem genom att tillämpa tekniker, metoder och verktyg. Det innebär också att arbeta inom organisatoriska och finansiella ramar, samt att se till alla aspekter av produktionen, såsom planering och verktygsutveckling (Sommerville 2010). Egenskaper all mjukvara bör tillhandahålla är att den är lätt att underhålla, pålitlig, användbar och effektiv (Sommerville 2010).

Mellan 1985-2009 har The Standish Group’s CHAOS Manifesto granskat över 70000 IT/IS projekt, och statistiken påvisar att mindre än en tredjedel av projekten anses lyckade (år 2009 lyckades 32 %). Kriterierna för att ett projekt skall anses lyckat är att det levereras i tid, inom budget och med önskad funktionalitet. Mjukvaruprojekt är kända för att dras med förseningar, inte hålla budget och inte uppfylla användarens krav (Fox & Spence 2005). Söderlund (2005) menar att orsaken till att projekt misslyckas beror på bristande kvalitet, förseningar och en budget som spricker. Kriterierna som framhålls för att projekt skall anses mer eller mindre framgångsrikt avser specifikationskrav, tid och budget gentemot utfallet.

Enligt Söderlund (2005) är projekt som tidsmässigt sträcker sig över en längre tid mer benägna att avvika ifrån tidsplanen. Även Sommerville (2010) tar upp problemet med att mjukvaruprojekt fortfarande har en hög grad av misslyckanden, och menar att generellt har användare och kunder låga förväntningar. Ett vanligt förekommande fenomen är att mjukvaruprojekt eskalerar genom att mer resurser tillförs samtidigt som den negativa informationen angående eventuella tidsproblem förbises, vilket är mycket kostsamt, och innebär en stor risk att projektet misslyckas (Korzaan & Morris 2009).

3

1.2 Problemformulering

Det som frekvent tas upp som en bidragande faktor till att mjukvaruprojekt misslyckas är att tidsplanen spricker. Chen m.fl. (2009) menar att mjukvaruprojekt har gått ifrån en traditionell kostnadsorienterad syn till en mer tidsorienterad, vilket hänger ihop med ett mer föränderligt organisationsklimat. Tids- och resursplanering är viktigt att beakta i ett projekt, samt att tydligt kunna avgränsa och organisera. Projektledarens kontroll över situationen är en viktig nyckel, samt möjligheten att kunna spåra och ha översikt över framstegen som görs. Korzaan och Morris (2009) menar att det finns ett uppenbart behov av projektplaneringsverktyg, tekniker och metoder för att eliminera problem med att värdefulla resurser går till spillo.

Mjukvaruutveckling innebär en komplex värld som ständigt tar nya riktningar, och där dagens nyheter fort övergår till att bli gårdagens. Stora krav ställs på dagens mjukvara, och det är sällan att begränsningen är direkt kopplad till det programmeringsspråk eller programmeringsverktyg de är framtagna i utan problemen ligger i den komplexa värld den befinner sig i. Fox och Spence (2005) menar att den ökade komplexiteten inom mjukvaruutveckling, där tusentals uppgifter är sammankopplade och beroende av spårning och kontroll, gör att valet av verktyg är viktigt för att planera och styra ett projekt. Viktiga begrepp är just spårning och kontroll över situationen. Alltså ställs det höga krav på de verktyg som är avsedda för att planera och realisera IT/IS-projekt.

Utbudet av datorprogram för att tids- och resursplaner är omfattande, vilket ger utöver Korzaans och Morris (2009) forskning anledning att tro att det finns ett behov. Det två senaste decennierna har det genomförts stora investeringar i projektplanering och projektstyrning, men antalet misslyckade projekt inom IT/IS-branschen är fortfarande på samma nivå (Fowler & Lock 2006). Kan det vara så att planeringsverktygen är undermåliga, är valet av verktyg fel, används de fel eller används de överhuvudtaget? Projektplaneringsverktyg är ett bra hjälpmedel för den aktive projektledaren, men det är inte alltid de matchar hur denne arbetar och fattar sina beslut (Fox & Spence 2005). Fox och Spence (2005) menar att en viss typ av ledarskapsstil passar bättre i kombination med ett projektplaneringsverktyg, vilket i sin tur leder till en bättre tidsprecision.

Föreliggande litteraturgenomgång visar att sambandet mellan misslyckade projekt och projektplaneringsverktyg inte är tillräckligt utforskat idag. Statistiken visar att det finns stora problem inom IT/IS-projekt, men det innebär inte att det finns några samband. Med ovanstående forskning i åtanke är det av relevans att ta reda på vad ett planeringsverktyg bör tillhandahålla funktionsmässigt, samt hur väl marknadens verktyg står sig.

Enklare jämförelser mellan projektplaneringsverktyg finns att tillgå, men är oftast intetsägande och utan någon djupare analys. Ett problem är vilka kriterier de skall uppfylla för att överhuvudtaget kunna jämföras. Att ställa planeringsverktygen sida vid sida är intetsägande då man inte vet vad som bör jämföras. Det behövs alltså någon form av mätinstrument för att genomföra en jämförelse.

4

1.3 Syfte

Syftet med denna studie är att ta fram ett mätinstrument utifrån dokumenterad projektledningsmetodik, med inriktning tid, resurs, avgränsning och organisering. Detta för att undersöka och kartlägga vilka funktioner som kan tänkas efterfrågas på ett projektplaneringsverktyg i förhållande till mjukvaruutveckling i projektform. Utifrån detta jämförs ledande projektplaneringsverktyg för att få en uppfattning i hur de står sig gentemot varandra och emot den faktiska projektledningsmetodiken.

Huvudsyftet är alltså framtagandet av själva mätinstrumentet, och jämförelsen verktygen emellan är till stor del för att ta reda på om det finns brister som kan vara bidragande till att mjukvaruprojekt misslyckas. Med denna undersökning vill vi ”översätta” projektledningsmetodik till reella funktioner i ett planeringsverktyg.

1.4 Frågeställning

Frågeställningen är indelad i en huvudfråga, samt en underfråga. Med huvudfrågan avser vi att med hjälp av en kvalitativ sekundäranalys ta fram ett mätinstrument utifrån dokumenterad projektledningsmetodik. Denna metodik ställs i relation till vedertagen mjukvaruprocess för att ta fram vilka funktioner ett projektplaneringsverktyg bör tillhandahålla.

Huvudfråga:

Vilka funktioner bör ett projektplaneringsverktyg, avseende mjukvaruutveckling, tillhandahålla givit en dokumenterad projektledningsmetodik?

Med underfrågan avser vi att jämföra ledande projektplaneringsverktyg, för att ta reda på hur de står sig gentemot det mätinstrument som tagits fram i huvudfrågan. Med detta tillvägagångssätt förväntar vi oss att kunna svara på vilka funktioner som tillhandahålls och vilka som saknas, för att få ett heltäckande planeringsverktyg avseende mjukvaruutveckling.

Underfråga:

Hur väl står sig ledande projektplaneringsverktyg gentemot varandra, det framtagna mätinstrumentet, och ledande mjukvaruprocesser?

Underfrågan bygger på att huvudfrågan går att besvara. Det primära med undersökningen är att söka svar på huvudfrågan.

1.5 Målgrupp

Tänkt målgrupp för denna uppsats är individer med anknytning till projektarbete, både projektledare och övriga projektmedlemmar. Den förväntas också läsas av individer som beslutar vilka inköp som görs i fråga om planeringsverktyg för att underlätta och förbättra, samt står inför en större investering. Framförallt riktar sig uppsatsen till individer med utbildning inom projektledning och

5

programvarukonstruktion. Anledningen till det sistnämnda är då någon direkt utbildning inom projektplaneringsverktyg inte sker inom ämnet projektledning, och här förväntas ett stort intresse pga. faktorn att ”känna igen sig i verktyget”.

1.6 Avgränsning

Denna undersökning inriktar sig första hand på mjukvaruutveckling som utförs i projektform, men förväntas även kunna ta fram riktlinjer inom andra branscher. Fokus i denna undersökning ligger på tids- och resursplanering, samt att effektivt kunna avgränsa och organisera med hjälp av kunskaper inom projektledningsmetodik, samt användningen av projektplaneringsverktyg. Projektledning innebär mycket mer än att kunna hantera de metoder som finns när det gäller planering. Man får inte glömma att det viktigaste är hanteringen av de individerna som ingår i projektgruppen, och hur dessa inverkar på det slutgiltiga resultatet (Svedberg 2007).

Mycket mer än den faktiska projektplaneringstekniken skulle vid ett längre perspektiv kunna vägas in, men i denna undersökning tas inte hänsyn till faktorer såsom struktur, kultur, processer (se exempelvis Bakka m.fl. 2006), ledarskapet i ett gruppsykologiskt perspektiv (se exempelvis Svedberg 2007 eller Northouse 2010), kreativitet och motivation (se exempelvis King & Andersson 2002), makt och genus (se exempelvis Backman 2005), för att bara nämna några. I sista avsnittet ger vi exempel på fler forskningsområden inom ämnet.

1.7 Definitioner

Alla begrepp som är av vikt för att uppnå uppsatsen syfte förklaras efterhand som de används. Vissa begrepp förklaras av olika anledningar inte, men är av vikt för helhetsförståelsen. Dessa begrepp, samt förklaring följer nedan:

Användare: Annat begrepp är brukare. De individer som kommer att använda projektresultatet (Jansson & Ljung 2004).

Artefakt: Av människan konstruerat verktyg, t.ex. en dator eller datorprogram (Preece m.fl. 2007).

Effektmål: Projektet startas för att skapa något som kommer att bidra till att verksamhets- eller affärsmålet uppfylls. Projektets resultat väntas alltså ge en viss effekt (Jansson & Ljung 2004).

IS: Informationssystem inom mjukvara och datorsystem (Preece m.fl. 2007).

IT: Informationsteknik inom datorhårdvara (Preece m.fl. 2007).

Klass: En mall eller mönster som beskriver hur objekt med samma uppbyggnad och egenskaper ser ut (Skansholm 2005).

6

Kund: Den externa motparten som moderorganisationen skall tillfredställa genom projektet, t.ex. den som beställt den produkt som projektet skall leverera (Jansson & Ljung 2004).

Ledtid: Ledtiden är den kalendertid som behövs för att utföra arbetet. Det är alltså ledtiden som ligger till grund för tidplanen (Jansson & Ljung 2004).

Objekt: En modell av ett verkligt eller tänkt föremål (en instans av en klass) (Skansholm 2005).

Objektorienterad programmering: Programvara som är uppbyggt av ett eller flera objekt som är återanvändnings- och ändringsbara (Skansholm 2005). Exempel: C#, C++, Java, Perl, Python, m.fl.

Projektbeställare: Chef i moderorganisationen som beslutat att genomföra en uppgift i projektform och som lämnar över uppgiften till projektledaren (Jansson & Ljung 2004).

Projektbudget: Är en fastställd sammanställning av förväntade kostnader och intäkter. Detta efter projektkalkylen visat att projektet klarar ställda lönsamhetskrav. Budgeten fungerar som styrinstrument under projektets genomförande (Jansson & Ljung 2004).

Projektmål: Projektets mål är ett visst resultat som skall levereras från projektet. Man kan säga att detta skall vi uppnå sedan kan vi sluta (Jansson & Ljung 2004).

Referensgrupp: Grupper eller enskilda personer som man utnyttjar för att få goda råd (Jansson & Ljung 2004).

Resursplanering: Här ingår bl.a. material, utrustning, människor och pengar (Duncan 1998).

Resursägare: Chefer som tillhandahåller viktiga resurser projektet är i behov av, t.ex. verktyg, material och den personal som skall genomföra projektarbetet (Jansson & Ljung 2004).

Stab: Stödjer projektledaren med uppföljning, sammanställning av information och förberedelser av möten (Jansson & Ljung 2004).

Styrgrupp: Beställare samt personer med befogenhet att besluta och styra över resurser (Antvik & Sjöholm, 2005).

Tidsplanering: Planering av tidsåtgång i ett projekt avseende den tid projektdeltagarna behöver för att utföra sina uppgifter (Tonnquist 2010).

Verksamhetsmål: Med ett projekt har man en vision och ett verksamhetsmål. Visionen beskriver ett scenario i framtiden. I verksamhetsmålet har man omsatt visionen till mätbara termer (Jansson & Ljung 2004).

7

2. Metod

I följande metodavsnitt beskrivs de metodval som gjorts, och vilka argument som finns för dessa val. Vidare följer val av sekundärmaterial för vidare analys, och projektplaneringsverktyg för jämförelse. Metodavsnittet avrundas sedan med en metoddiskussion som tar upp fördelar och nackdelar med metodvalen och källkritik.

2.1 Metodval

En undersökning görs vanligtvis med en kvantitativ eller kvalitativ metod. Med en kvantitativ metod ligger tyngden på kvantifiering vid insamling och analys av data, med fokus på det som går att beskriva med siffror. Viktiga drag i en kvantitativ undersökningsmetod är: mätning, generalisering, replikation och kausalitet (Bryman 2011). Används en kvalitativ metod ligger vikten på ord och inte siffror vid insamling och analys av data. Huvudsakliga intresseområden för kvalitativ forskning är: världen som undersökningsobjekten upplever den, process, flexibilitet, strukturlöshet, beskrivning och kontext, samt begrepp och teori som resultat av forskningsprocessen (Bryman 2011). En kvantitativ metod är bra för att ta reda på hur många eller hur vanligt ett fenomen är, medan en kvalitativ metod är mer djupgående, söker sammanhang och är bra när det är frågan om generaliseringar inom undersökningsobjektet. Även flermetodsforskning förekommer, och till en början tillämpades termen för att beskriva studier som kombinerar enbart kvalitativa eller enbart kvantitativa forskningsmetoder. Numera har termen fått en annan betydelse, och står för en kombination av både kvantitativ och kvalitativ forskning (Bryman 2011).

2.1.1 Induktiv eller deduktiv ansats

I studier används antingen en deduktiv eller induktiv ansats. En deduktiv metod använder sig i regel av kvantitativa insamlingsmetoder, kontra den induktiva metoden som i huvudsak använder sig av kvalitativa insamlingsmetoder (Bryman 2011). I det deduktiva angreppssättet går forskningsriktningen ifrån teori till observation/resultat, medan i det induktiva angreppssättet går forskningsriktningen ifrån observation/resultat till teori. Det finns emellertid forskning där man inte strävar efter att följa någon av dessa riktningar. Flera forskare föredrar att uppfatta sambandet mellan forskning och teori som i huvudsak något induktivt oavsett kvalitativ eller kvantitativ metod (Bryman 2011).

2.1.2 Kvalitativ sekundäranalys

I denna undersökning tillämpas i huvudsak en kvalitativ metod i form av en sekundäranalys av kvalitativ data. Tidigare har analys av kvalitativ data endast rört sig om den data man själv har samlat in, och en sekundäranalys varit förknippad med något kvantitativt. Sekundäranalyser av data har förekommit inom kvantitativ forskning under en lång tid, men ganska nyligen har sekundäranalyser tillämpats på kvalitativa data, och blir allt vanligare (Bryman

8

2011). Det finns egentligen inte några uppenbara skäl för att kvalitativa data inte kan användas för en sekundäranalys, utan alla tänkbara skäl som finns vid kvantitativ datainsamling finns även vid den kvalitativa (Bryman 2011). Vid en sekundäranalys av kvalitativa data är det möjligt för forskaren att bearbeta den data som inte granskats i den primära undersökningen, och nya tolkningar kan möjliggöras (Bryman 2011).

2.1.3 Flermetodsforskning

Som nämns ovan är det i huvudsak en kvalitativ metod som tillämpas i denna undersökning, och det vanligaste vid denna typ av metod är ett induktivt angreppssätt, men här väljer vi att gå ifrån det traditionella synsättet med att gå ifrån observation/resultat till teori och istället utgå ifrån teorin. Att utgå ifrån teorin är förknippat med en kvantitativ metodansats, och även hur resultatet av verktygsjämförelsen presenteras i denna uppsats kan ses som något kvantitativt. Därmed kan denna undersökning betraktas som en kombination av kvalitativ och kvantitativ forskning, alltså en flermetodsforskning. Anledningen till detta angreppssätt är att det mätinstrument vi avser att ta fram i denna undersökning ligger till grund för att vidare utvärdera ledande projektplaneringsverktyg. Angreppssättet bygger på att projektledningsmetodiken analyseras för att huvudfrågan skall kunna besvaras, och i sin tur förväntas svaret även kunna ge svar på underfrågan. Något som rekommenderas vid flermetodsforskning är att resultat och diskussion slås samman (Bryman 2011).

2.2 Strategi vid litteraturval

Då frågeställningen syftar till att den ledande projektledningsmetodiken skall utgöra riktvärde för vad ett projektplaneringsverktyg bör tillhandahålla för funktioner, behövs en sammanställning och ett urval göras. Här väljer vi att begränsa oss till den litteratur som används på Sveriges universitet och högskolor. Sökningar gjordes på internet för att ta fram vilka skolor som tillhandahåller utbildning inom ämnet projektledning.

De flesta universitet och högskolor publicerar vilken litteratur som innefattas på respektive utbildning. Med de som inte publicerar den litteratur som är aktuell upprättades en mejlkontakt. All litteratur undersöktes, och den litteratur som inte stämmer överens med syftet i denna undersökning sållades bort. Den litteratur som kvalificerar sig används som huvudlitteratur tillsammans med annan stödlitteratur som komplement. Utifrån sammanställningen av litteraturen utkristalliseras de variabler som ligger till grund för jämförelsen av de utvalda projektplaneringsverktygen.

Nio universitet och högskolor har utbildning inom projektledning och tillhandahålls både på grund- och avancerad nivå. Utbildningarna innefattar olika inriktningar inom projektledning såsom IT, bygg, etc. men litteraturen som används är densamma, och detta beror på att projektledningsmetodik skall kunna ligga till grund oavsett vilken typ av projekt som skall genomföras. Universitet och högskolor som tillhandahåller utbildning inom projektledningsmetodik är:

9  Halmstad högskola  Karlstads universitet  Linnéuniversitet  Luleås universitet  Malmö högskola  Skövde högskola  Stockholms universitet  Umeås universitet  Uppsalas universitet

2.2.1 Dominerande litteratur

Varje universitet och högskola har flera kurser inom ämnet, och den litteratur som dominerar inom projektledningsmetodik med inriktning på projektplanering är

Projektledningsmetodik (Jansson & Ljung 2004) och Projektledning (Tonnquist 2005). Denna kurslitteratur ligger till grund för det mätinstrument som vi arbetar fram i denna undersökning, med reservation för att boken projektledning har uppdaterats till nyare upplaga (Tonnquist 2010). Även en nyare upplaga av boken

projektledning (Tonnquist 2012) har tillkommit med bl.a. hur projekt i olika branscher ser ut, och hur ett agilt (se avsnitt 3.4 för förklaring av agil process) arbetssätt kan integreras med ”traditionell” projektledningsmetodik (se avsnitt 3.3 för förklaring). Den sistnämnda projektledningsboken ligger även den till grund, med anledning av att agil utvecklingsprocess ofta används vid mjukvaruutveckling (Sommerville 2010). Med anledning av att agila processer har ett stort inflytande inom mjukvaruutveckling behövs en ytterligare fördjupning i denna approach, och här används Agil projektledning (Gustavsson 2011). Stöd har tagits ifrån Software Engineering (Sommerville 2010) för att ta fram ett teoretiskt ramverk inom mjukvaruutveckling.

2.2.2 Presentation av studiens huvudlitteratur

Boken Projektledningsmetodik (Jansson & Ljung 2004) behandlar olika roller som florerar inom begreppet projektledning, samt begreppet i sig. Den tar upp projektets indelning i faser, och påvisar viktiga skillnader mellan olika typer av projekt. Huvuddelen av boken behandlar projektledarens verktyg och tekniker för att definiera, avgränsa, planera, organisera, leda, överlämna och avsluta projektuppgiften. Boken är både ett läromedel för universitet och högskolor, samt en handbok för den aktive projektledaren. Författarna har en lång erfarenhet av projektledning och projektledningsfrågor.

Boken Projektledning (Tonnquist 2010, 2012) riktar sig liksom ovanstående till alla typer av projekt oavsett bransch. Både projektledaren och metodiken beskrivs på ett sätt som gör boken användbar både som lärobok och som handbok vid praktiskt projektarbete. Upplagan från år 2012 riktar sig liksom upplagan från år 2010 i första hand mot traditionell projektledning, men tar även in den agila approachen, samt föreslår en kombination mellan de olika arbetssätten. Författaren är en erfaren projektledare och föreläsare inom ämnet projektledning.

I boken Agil projektledning (Gustavsson 2011) ger författaren en teoretisk stomme, samt den praktiska tillämpningen av agila metoder. Konkreta exempel varvas med

10

tankesätt som ligger till grund för ett agilt arbetssätt. Här tas agil process upp som en viktig del inom IT-branschen, samt hur den börjar få fäste även i andra branscher. Författaren har arbetet med agila metoder sedan år 2002.

Boken Software Engineering (Sommerville 2010) ger ett teoretiskt ramverk för mjukvaruutveckling med en ingenjörsmässig approach. Den beskriver processer för framtagningen av mjukvara, samt tillämpningsbara projektmetoder. Författaren tar upp projektledningsmetodik som en betydande del inom begreppet software engineering.

2.3 Strategi vid val av undersökningsobjekt

Projektplaneringsverktyg delas liksom den mesta mjukvara in i allmän (generic products) och beställd (customized eller bespoke products), där den allmänna kontrolleras av beställaren, och den beställda av utvecklaren. Det är inte alltid en skarp linje mellan denna indelning. Vissa stora system kan köpas in som allmän mjukvara, men sedan behöva så mycket konfiguration att den i slutändan kan betraktas som beställd (Sommerville 2010). I denna undersökning är det ett urval av allmänna projektplaneringsverktyg som jämförs. Ursprungligen var målet att jämföra och analysera 25 % av marknadens projektplaneringsverktyg, för att få ett generaliserbart resultat även utanför själva undersökningsobjekten, men efter att ha ”scannat” av internet med sökord som project management tool och project management software visade sig att listan med planeringsverktyg blev mycket omfattande. För att göra ett urval bland planeringsverktygen behöver de först delas in i två kategorier.

2.3.1 Två kategorier av projektplaneringsverktyg

I den första kategorin är de som innebär att användaren/kunden står för all lagring och en lokal installation. I denna uppsats refererar vi till begreppet traditionell, och anledningen är att denna typ är vanligare historiskt sett. Denna typ av planeringsverktyg kan i sin tur delas in i de som innebär en kostnad, och de som är fria för alla att använda. Något löst utryckt kan man kalla dessa för licens och

open source. Ett licensprogram innebär vanligen en kostnad för kunden, medan open source är gratis eller till viss del gratis. I denna uppsats använder vi begreppen kostnad och kostnadsfria, och syftar då på licens respektive open source. Utifrån ovanstående problemformulering är avsikten att undersöka ett urval av både de som innebär en kostnad, och de som är kostnadsfria.

I den andra kategorin med planeringsverktyg är de som vi valt att kalla

molnbaserade. Flera förklaringar finns på begreppet molnet och flertalet forskare väljer att luta sig mot Brandls (2010) förklaring. Molnet är en samling av IT-resurser (servrar, databaser och tillämpningar) som är tillgängliga på begäran av kunden. Dessa sköts och levereras av en molntjänstleverantör över internet (Brandl 2010). Alltså har användaren/kunden inte något lokalt program installerat, utan en leverantör står för programmet, service och lagring av data. I denna uppsats refererar vi till begreppet molnbaserat, och väljer att göra det synonymt med engelskans Cloud Computing. Begreppet kan kort beskrivas som en

11

tjänst som levererar någon form av datorbaserad resurs från annan plats än var man har sitt eget användande (Rittinghouse & Ransome 2010). Planeringsverktyg som är molnbaserat kräver i de allra flesta fall en månatlig kostnad som baseras på antalet användare, och/eller antalet samtidiga projekt.

2.3.2 Ytterligare sållning

Anledningen till att först kategorisera verktygen på detta sätt är att få en bredd som annars inte är möjlig med andra variabler. Generellt har inga av verktygen som uppdagades någon specifik inriktning utan de flesta skall fungera i alla branscher. Några få verktyg är dock riktade mot en viss bransch, såsom bilindustrin och väganläggning, och dessa sållas bort utan vidare undersökning. Vidare gallras alla planeringsverktyg som befinner sig i betastadiet bort, samt de som är helt nylanserade. Vissa planeringsverktyg är en del av en helhetslösning, vilket innebär att användaren/kunden blir låst till att använda sig av dedikerade lösningar. Detta kan innebära att en organisation blir låst till vissa helhetslösningar, och dessa sållas också bort pga. att i denna undersökning fokuseras det på helhetslösningen i själva planeringsverktyget.

Som nämns ovan är verktygen generellt inriktade på planering inom alla typer av branscher, och är då i första hand inriktade på en plandriven process (se avsnitt 3.1), men då denna undersökning fokuserar på mjukvaruutveckling är det av stor relevans att ta med planeringsverktyg med inriktning på agil utvecklingsmetod. Anledningen till detta är att den agila metoden är utbredd och en vanligt arbetssätt inom mjukvaruutveckling (Tonnquist 2012). Agila projektplaneringstekniker går att integrera med traditionella, men i första hand bör ett verktyg passa in i de behov en organisation har (Tonnquist 2012). Inga licenser köps in för att genomföra denna undersökning, utan endast verktyg som tillhandahåller demoversioner med full funktionalitet undersöks.

Med ovanstående i åtanke blir antalet planeringsverktyg något mer hanterbart. En del planeringsverktyg har många år bakom sig på marknaden, och förväntas därigenom vara väl etablerade och inneha bra heltäckande lösningar. Vissa stoltserar med många användare, används i flera olika typer av bransch och har vunnit priser vid olika event. Dessa ger upphov till närmare undersökning, och det som till sist avgör urvalet är en bedömning utifrån författarens tidigare kunskap i området.

2.4 Metoddiskussion

Det finns både fördelar och nackdelar med detta metodval. En fördel med en kvalitativ sekundäranalys är att datan ofta är beprövad och av god kvalitet. Kvalitativ forskning brukar normalt generera stora mängder data, vilket innebär att materialet inte utnyttjas till fullo vid den primära undersökningen (Bryman 2011). En nackdel med en kvalitativ sekundäranalys är att återanvändning av kvalitativ data försvåras av att den som utför sekundäranalysen inte har samma förståelse för den sociala kontext som den ursprungliga forskaren skaffat sig. Detta kan försvåra tolkningen av data (Bryman 2011).

12

När en undersökning görs med ett visst syfte kan det verka som all data tömts på all intressant information under den första analysen, men en intressant datamängd kan analyseras på flera olika sätt (Bryman 2011). En kvalitativ sekundäranalys har därmed ett syfte som den primära undersökningen inte haft eller tänkt sig, och ger därför nya möjligheter att användas i ett annat syfte. Anledningen till att undersökningen bygger på en kvalitativ sekundäranalys till skillnad mot mer traditionella kvalitativa datainsamlingsmetoder, såsom intervjuer och observationer (Bryman 2011), är att inte bli färgad av eventuella favoriseringar av planeringsverktyg, utan få ett bredare perspektiv och en neutralare syn. Ett annat argument för en sekundäranalys är att få en större översikt över vad projektledningsmetodiken säger gentemot vad ett förmodligen begränsat antal projektledare skulle kunna ge.

Nackdelen med att inte ta med aktiva projektledares syn är att det förmodligen är skillnad på hur vi ”bör” förhålla oss till det som finns dokumenterat när det gäller projektledningsmetodik och ”hur” vi egentligen gör. Brundell-Öhman (2008) menar att ingen metodik kan ersätta det sunda förnuftet, och att tekniker och verktyg endast är ett stöd för den ”tänkande projektledaren”. Eventuellt kan detta påverka hur projektledare, beroende på erfarenhet, använder sig av planeringsverktyg. En alternativ metod kan vara att ta fram ett mätinstrument med hjälp av en kvalitativ sekundäranalys för att sedan låta aktiva projektledare verifiera eller falsifiera det framtagna mätinstrumentet. Denna kan då ligga till grund för en hypotes som man med en kvantitativ metoddesign kan verifiera eller förkasta, och på så sätt göra förändringar. Vidare kan det ”nya” mätinstrumentet matchas mot projektplaneringsverktyg på marknaden. Bryman (2011) tar upp denna approach, med att låta en kvalitativ metod ta fram ny teori för att sedan med en kvantitativ metod testa teorin. Det är dock sällsynt med denna approach i en och samma studie pga. dess omfång (Bryman 2011).

2.4.1 Källkritik

Mediascanning är en metod som rekommenderas när data hämtats ifrån sekundära källor. Metoden går ut på att all data ses med kritiska ögon, och det gäller att vara observant på om informationen är subjektivt skriven, och därför vinklad för att läsaren skall få en viss bild av en bransch eller en organisation (Wahlström 2004).

Källan ska vara det den utger sig för att vara (äkthet). Ju längre tid som har gått mellan en händelse och källans berättelse om denna händelse, desto större skäl finns det att tvivla på källan (tidssamband). Källan ska ”stå för sig själv” och inte vara en avskrift eller ett referat av en annan källa (oberoende). Man ska inte ha anledning att misstänka att källan ger en falsk bild av verkligheten på grund av politiska, ekonomiska eller personliga skäl, eller har andra intressen för att förvränga verklighetsbilden (tendensfrihet) (Thurén 2004).

En nackdel med att använda kurslitteratur är att den tenderar att vara skriven för att ”fånga läsaren”, vilket medför att man som läsare måste vara observant för att fånga det väsentliga. Vetenskapliga artiklar är ofta skrivna utan onödig

13

information, men problemet är att de endast täcker mindre och mer specifika områden. Då projektledningsmetodik är ett stort område är det svårt att få en helhetsbild med endast vetenskapliga artiklar.

Vi ser en fördel i att göra urvalet av litteratur utifrån universitet och högskolor. Detta ger en tillförlitlighet pga. att materialet oftast är beprövat vid flera tillfällen. För att öka tillförlitligheten vägs även andra forskares syn in i analysen av resultatet, vilket medför en ökad dignitet när slutsatser dras av undersökningen.

14

3. Teori

I följande teoriavsnitt beskrivs mjukvaruutveckling utifrån tre grundprocesser. Vidare beskrivs två metoder som dominerar sättet att bedriva projektledning på. Detta bildar ett teoretiskt ramverk, vars syfte är att ha rätt förhållningssätt i resultat- och diskussionsavsnittet. Det som i första hand tas upp i detta avsnitt är vad varje fas innebär för att i resultat- och diskussionsavsnittet presentera tekniker som används, vilket i sin tur skall generera tänkbara funktioner i ett projektplaneringsverktyg. Att ta fram ett teoretiskt ramverk att förhålla sig till är en vanlig ansats vid genomförandet av en kvalitativ sekundäranalys.

3.1 Mjukvaruprocesser

Sommerville (2010) beskriver en mjukvaruprocess som en samling aktiviteter, vars syfte är att producera en mjukvaruprodukt. Dessa aktiviteter kan innefatta utveckling av mjukvara från ”scratch” i standard programmeringsspråk som C, Java, Python, etc. Emellertid behöver inte mjukvaruutveckling ske på detta sätt utan numera modifieras ofta befintlig och beprövad mjukvara för att uppnå ny funktionalitet. Både tidigare allmän och beställd mjukvara kan ligga till grund för den nya mjukvaran som skall produceras.

Det finns flera mjukvaruprocesser som på olika sätt används inom mjukvaruutveckling, men det som enligt Sommerville (2010) ingår i alla processer är:

 Specifikation: Funktionaliteten i mjukvaran och dess begränsning.

 Design och implementering: Mjukvaran måste tillverkas för att möta specifikationen.

 Validering: Mjukvaran måste valideras för att möta kundens förväntningar.  Evolution: Mjukvaran måste kunna möta ändringar i kundens behov. En process beskriver bl.a. aktiviteter som:

 Kravvalidering: Krav arbetas fram och analyseras.

 Design av arkitektur: Den övergripande designen arbetas fram.  Enhetstest: Rutiner för testning av systemet arbetas fram.

 Dokumentationsrutiner: Rutiner för vilka, hur och vad som dokumenteras.  Artefakter: Vad är resultatet av aktiviteten.

 Roller: Vem ansvarar för vad (projektledare, programmerare, etc.).  Pre/post villkor: Vilken status är sann före och efter en aktivitet.

Inom en del organisationer finns det inga definierade processer och de utnyttjar inte mjukvaruutvecklingsmetoder (software engineering methods). Det finns ingen idealtyp när det gäller processer inom mjukvaruutveckling, utan dessa fungerar mer som riktlinjer och ett sätt att förhålla sig. Mjukvaruutveckling delas vanligen in i plandrivna och agila processer.

15

Plandrivna processer innebär dokumenttunga program, och fungerar bäst när kunden vet vad den vill ha, samt är bra vid höga säkerhetskrav. Agila processer innebär att allt byggs upp av mindre delar, och fungerar bäst när kunden är osäker på vad den vill ha. Programmet kan i tidigt stadium ”sjösättas” och utvärderas.

3.2 Processmodeller

En process är en abstrakt modell som förenklat beskriver de verkliga aktiviteterna som utförs. Det är viktigt att framhålla att en processmodell är just en modell och inget annat. Den beskriver inte den viktigaste faktorn angående de individer som är involverade (Sommerville 2010). För att förstå vad plandriven respektive agil process är behövs processmodeller som illustrerar allt i ett arkitekturperspektiv. Grundtyper för processmodeller är vattenfallsmodell, inkrementell utveckling och återanvändningsprocess (Sommerville 2010).

3.2.1 Vattenfallsmodellen

Vattenfallsmodellen, eller mjukvarulivscykel (software life cycle) (Figur 1) uppkom under 1970-talet och är i grunden en mer generell ingenjörsprocess inom systemutveckling. Den bygger på ett logiskt flöde av faser, och detta genom att när en fas är färdig går det vidare till nästa. Fasen man lämnar bakom sig anses då helt avklarad. Vattenfallsmodellen är ett exempel på en plandriven process (Sommerville 2010).

Figur 1: Vattenfallsmodell

Kravdefinition: Här tas det fram vad systemet skall tillhandahålla, samt avgränsningar, och mål sätts upp i samråd med användaren/kunden.

Kravdefinition Implementation och enhetstest Design Införande och underhåll Integration och systemtest

16

Design: Den övergripliga arkitekturen tas fram, samt beskrivning av mjukvaran, och vilka relationer som finns.

Implementation och enhetstest: Mjukvaran realiseras i mindre programdelar och varje del verifieras med specifikationen.

Integration och systemtest: Delarna sätts samman och checkas av så att mjukvaran möter kraven. Efter att allt har testats levereras det till kunden.

Införande och underhåll: Normalt är detta den längsta fasen, och har egentligen inte något definitivt slut. Under införandet kan justering komma att ske, och under fasen underhåll kan ett långvarigt servicearbete pågå.

Resultatet av varje fas genererar ett eller flera dokument, vilka fungerar som ett avslut på fasen. Nästa fas startar inte förrän föregående är helt avklarad. I praktiken är inte gränsen lika knivskarp såsom modellen visar utan de överlappar och ger information mellan varandra (Sommerville 2010).

3.2.2 Inkrementell utveckling

Inkrementell utveckling är baserat på en idé om att tillverka enklare varianter av ett system eller delsystem, för att sedan ”sjösättas” och invänta respons ifrån användaren/kunden. Flera versioner implementeras och utvärderas innan den slutgiltiga versionen står klar (Figur 2).

Figur 2: Inkrementell utveckling

Inkrementell utveckling är en fundamental del av den agila approachen (se avsnitt 3.3 för närmare beskrivning av begreppet agil), och är bättre än vattenfallsmodellen när det kommer till utveckling av bl.a. e-handelsplatser, och där kraven är svårtolkade (Sommerville 2010). I inkrementell utveckling reflekteras det över vilket sätt ett problem löses och inte över eventuella problem som kan komma att dyka upp. Alla misstag och problem som stötts på sparas i en logg som ligger till stöd för den fortsatta utvecklingen. Inom inkrementell utveckling är det lättare och billigare att rätta till fel löpande Sommerville (2010). Normalt innehåller varje version som släpps endast de mest akuta funktionerna, och kan därigenom invänta den respons som användarna/kunderna ger, för att sedan gå vidare med justeringar och ny funktionalitet (Sommerville 2010).

Översiktlig beskrivning Specifikation Utveckling Validering Första versionen Slutversion Mellanliggande versioner

17

3.2.3 Återanvändning

Som tidigare nämnts är det vanligt att befintlig mjukvara köps in och modifieras, och delar eller hela system återanvänds för att skapa ny mjukvara (Figur 3). En återanvändningsprocess är varken plandriven eller agil, och kan innefatta traditionell och/eller agil projektplaneringsteknik (Sommerville 2010).

Figur 3: Återanvändningsprocess

Kravspecifikation och systemvalidering: Dessa steg fungerar på samma sätt som i andra processmodeller. En kravspecifikation över den slutgiltiga produkten tas fram och fastställs. Valideringen består av att systemet testas och godkänns av utvecklare och mottagare.

Komponentanalys: Sökning sker efter tänkbar befintlig mjukvara för återanvändning. Normalt finns ingen exakt match utan valet sker efter hur nära den ligger det som söks.

Kravändring: Allteftersom mjukvaran samlas/köps in analyseras den för att ta reda på hur bra den passar in jämfört med specifikationen, och därefter modifieras den. Ofta får beslut om modifieringar göras både i kravspecifikationen och i den insamlade/inköpta mjukvaran.

Systemdesign och återanvändning: I denna fas tas den övergripande designen fram, och beslut fattas om vilka nya komponenter som måste tillverkas ifrån grunden.

Utveckling och integration: Själva implementeringsfasen innefattar att tillverka de komponenter som inte kan tas in externt, samt att integrera de insamlade/inköpta komponenterna för att ta fram den nya mjukvaran.

Återanvändning har som främsta syfte att reducera mängden egentillverkning av mjukvara, vilket i sin tur kan ge lägre tillverkningskostnad (Sommerville 2010). Det bygger på att modifieringen av mjukvaran inte får dra ut på tiden utan måste vara en snabb process för att inte kosta mer än att tillverka den från grunden. Denna metod passar bäst inom olika typer av nätservice, färdiga objekt ifrån objektorienterade programmeringsspråk, och när ett det befintliga systemet ligger mycket nära det system som skall tillverkas (Sommerville 2010).

Kravspecifikation Komponentanalys Kravändring

Systemdesign med återanvändning Utveckling och

integration Systemvalidering

18

3.3 Generella steg för projektledning

Begreppet projektledningsmetodik handlar om att planera och leda arbetet i projekt, och innefattar tekniker för att analysera projektidén, leda realiseringsarbetet, leda överlämningsarbetet samt avveckling av projektorganisationen (Figur 4).

Figur 4: Generella arbetssteg för projektledning

3.3.1 Förstudie

I denna uppsats används begreppet projektledningsmetodik som något som kan syftas till projektplanering. Projektledningsmetodik handlar till största delen om att planera och leda arbetet i projektet. Alla projekt har sitt ursprung i någon form av idé om att skapa något nytt, uppfylla en kunds önskemål eller förbättring av något befintligt.

I begynnelsen finns en idé som handlar om att skapa något nytt, uppfylla önskemål från en kund eller förbättra något i organisationen. Där startar uppdraget att leda projektet. Idén kan vara tydlig eller otydlig, väl beskriven eller oartikulerad. Men oavsett hur mycket eller litet som är givet är projektidén utgångspunkt för det projekt som ska planeras och man behöver förstå den för att kunna gå vidare (Jansson & Ljung 2004:115).

Inled alltid projektarbetet med att göra en förstudie med syfte att minska osäkerheten kring projektet. Frågor som bör besvaras kan vara: Är problemställningen riktig? Kommer projektet att ge önskade effekter? Har vi rätt förutsättningar? (Tonnquist 2010:33).

Varför kan man inte sätta igång med planeringen direkt? Innan planeringsarbetet sätts igång är det viktigt av flera skäl att analysera projektidén. Anledningar kan vara att alla redan har egna bilder av projektet, och det är lätt att föreställa sig fel eftersom uppgiften är ny, därför är det viktigt att se svaga punkter.

3.3.2 Planering

Under planeringsfasen tas grundläggande planer för projektet fram, vilket sedan är utgångspunkten för arbetet under realiseringsfasen. Planeringsarbetet skall resultera i beskrivningar av det kommande projektet. Under realiseringsfasen anpassas planerna allteftersom ”verkligheten” bjuder på överraskningar. Projektledning handlar om att leda projektet så att det lyckas, dvs. att alla intressenter är nöjda.

19

Att planera ett projekt innebär att utarbeta tids- och resursplaner, kalkylera kostnader, organisera arbetet och att analysera risker. Projektledarens uppgift är att se till att detta blir gjort (Tonnquist 2010:103).

3.3.3 Genomförande

Realiseringsarbetet kan sedan upprepas om och om igen under hela realiseringsfasen (Figur 5) innan slutmålet nås.

För att säkerställa att ett projekt håller sig på rätt kurs behöver man fortlöpande följa upp utfallet och om nödvändigt göra förändringar. Man måste alltså både titta bakåt i tiden för att granska det man hittills gjort och bedöma det arbete som återstår att göra (Tonnquist 2010:191).

Figur 5: Projektets realiseringsflöde

Med initiera menas att alla praktiska hinder måste elimineras, och allt som behöver något hangripligt stöd måste få det. Vidare inriktas projektledningen på att följa upp arbetet, dvs. samla information om hur det går och ”mäta framstegen”. Framsteg och problem skall analyseras, samt risker och möjligheter

måste identifieras, värderas och prioriteras. Beslut måste tas om eventuella åtgärder för att hantera möjligheter och risker.

Planer är inte avsedda att hålla. De är snarare något att hålla sig i (Jansson & Ljung 2004:123).

Efterhand som förutsättningarna ändras och arbetet tar nya riktningar måste även planerna anpassas.

3.3.4 Överlämning

Oräkneliga exempel finns på projekt som skapat något mycket bra, men där resultatet gått till spillo. Exempel på detta är alla webbplatser som utvecklats, men där ingen underhåller dem utan de bara förfaller. Det finns även projekt som aldrig avslutas pga. att de enda individerna som kan ge kunden ett fortsatt stöd är kopplade till projektet.

Initiera och följa upp Anpassa planerna Bedöma risk och möjlighet

20

Det gäller alltså att veta vem som ska ta över efter projektet, så att resultatet inte går förlorat och så att fortsatt förvaltning och underhåll kan organiseras på ett effektivt sätt (Jansson & Ljung 2004:167).

Kasta inte bort nyttan av projektet genom att slarva med införandet av projektets resultat. Det är här som grunden läggs för om det ska bli en kvarstående effekt efter det att projektet är avslutat (Tonnquist 2010:237).

3.3.5 Avslut

När mottagarna av resultatet har accepterat att ta över ansvaret för förvaltningen kan ett projekt avslutas. Det som återstår är att städa och reflektera över den gångna tiden, samt att sätta punkt. Något som inte får glömmas bort är att ta till vara på de erfarenheter som var och en fått.

Ett väl utfört avslut hjälper till att skapa en positiv bild av projektet som kan överskugga eventuella problem och konflikter som hanteras under genomförandet (Tonnquist 2010:251).

Resultatet är redan överlämnat och det som återstår är dels att städa upp (ofta bokstavligt!), att ta chansen att samla ihop lärdomar av det som deltagarna varit med om och att sätta punkt (Jansson & Ljung 2004:177).

3.4 Agil projektledning

Benämningen Agile är historiskt sett ny (2001), och kommer ifrån begrepp som lättrörliga eller lättviktiga metoder (Gustavsson 2011). I Sverige är det sedan ett antal år tillbaka det försvenskade ordet Agil en vedertagen benämning. Agil projektledningsmetodik har precis som ”traditionell” projektledningsmetodik samma arbetssteg (se Figur 1), men alla arbetsstegen sker flera gånger under ett och samma projekt (Tonnquist 2012).

3.4.1 Scrum

Den vanligaste agila arbetsmetoden inom mjukvaruutveckling är Scrum. Etapperna i Scrum kallas sprintar och varje sprint sträcker sig vanligtvis över två till fyra veckor, med dagliga möten (Figur 6).

Scrum är en agil arbetsmetod som framförallt används inom mjukvaru- och systemutvecklingsprojekt. Men inget hindrar att metoden även används i andra typer av projekt (Tonnquist 2012:148).

21

Figur 6: Scrummodell

Krav bryts ned i korta delmål och aktiviteter som samlas i en produktlogg. Vidare delas produktloggen upp i flera etapploggar, en för varje sprint. Tanken är att varje sprint skall leverera ett komplett användbart resultat, därigenom har alla arbetssteg (se Figur 1) genomförts på en gång.

De täta leveranserna skapar engagemang och gör att produktägaren kan se hur projektet rör sig framåt (Tonnquist 2012:148).

3.4.2 Scrum-master och produktägare

Allt detta leds av en Scrum-master, som har till främsta uppgift att agera som en

coach för projektgruppen. När scrum används har projektmedlemmarna inte några uttalade roller, förutom scrum-mastern som har en sammanhållande funktion för gruppen. Med coach menas att scrum-mastern inte går in och direkt styr projektgruppen, utan mer stöttar och hjälper för att allt skall bli så autonomt och effektivt som möjligt. En scrum-master beslutar om ”hur vi arbetar agilt” och har till skillnad från en projektledare ingen beslutsrätt i val av teknisk lösning, vem som gör vad, utan detta arbetas fram gemensamt (Gustavsson 2011).

Arbetet leds av en scrum-master, som har till främsta uppgift att agera som coach för teamet. Scrum fungerar bäst i små team, fem till sju deltagare som jobbar nära varandra, helst i samma rum. En stor projektgrupp bör alltså delas upp i mindre team (Tonnquist 2012:148).

Scrum-mastern delar vanligtvis sitt ”ledarskap” med en produktägare. I bästa fall kan en representant från kunden anta rollen som produktägare. Skulle sedan produktägaren inte ha möjlighet att närvara kan ett språkrör inom den egna organisationen utses för att bevara dess intressen (Gustavsson 2011).

Produktlogg Etapplogg

Sprint 2-4 v.

Delleverans Dagliga möten

22

4. Resultat och diskussion

Vanligt fenomen vid genomförandet av en kvalitativ sekundäranalys är att teori och resultat är nära relaterade till varandra, då de ofta kommer ifrån samma källa. Resultatet och diskussionsavsnittet är uppbyggt enligt ett projektplaneringsavsnitt med en övergripande metodik för att vidare delas in i tre underavsnitt som mer djupgående går in på planeringsteknik. I varje avsnitt följer en löpande diskussion av materialet rörande tänkbara funktioner i ett planeringsverktyg. Utifrån detta får vi ett nytt resultat, vilket består av en sammanställning över en tänkbar funktioner i ett planeringsverktyg, och en jämförelse mellan de utvalda undersökningsobjekten.

4.1 Övergripande projektplanering

4.1.1 Resultat

Jansson och Ljung (2004) delar in planeringsarbetet i tre faser (avgränsa och integrera, planera arbetet och organisera). Vidare delas planeringsarbetet in i elva logiska steg, där tre av stegen ingår under avgränsa och integrera, sex steg under

planera och två steg under organisera. Att det är logiska steg innebär att alla måste göras i just den ordningen som de förespråkas, och det går inte att hoppa över något steg. I stora projekt kan det vara befogat att genomföra varje steg som ett avskiljbart arbetssteg för att göra det tydligt om vad som ingår. Många gånger i praktiken går stegen mer eller mindre samman, och viktigt är då att notera att det rör sig om logiska steg och inte arbetssteg.

Här följer en kort beskrivning av de logiska steg som ingår i respektive tema, hämtade från Jansson och Ljung (2004). Dessa återkommer längre fram i avsnittet med tekniker för att ta sig igenom respektive steg. Anledningen till att vi använder oss av dessa faser är för att de fungerar bra tillsammans med övriga litteratur, och att empirin också presenteras i ett logiskt flöde.

Fasen avgränsa och integrera

1. Analysera intressentsituationen: Det första som görs är att analysera vilka som har förväntningar eller krav på projektet, vem som kan tillföra resurser eller har intressen som kolliderar med projektet.

2. Analysera krav och behov: Nästa steg är att analysera vilka krav/behov de olika intressenterna har. I analysen innefattas också prioritering av kraven genom att titta på relationen mellan kvalitet, kostnad och tid.

3. Beskriva resultat och projektmål: När kraven är införstådda kan man översätta dem till reella beskrivningar av projektresultatet. Vanligt är att flera kompletterande beskrivningar behövs, såsom realiseringsförslag, vilka beskriver teknisk lösning, konkreta leveranser och ett projektmål som sammanfattar det viktigaste.

Fasen planera arbetet

4. Välja strategier: När man har klart för sig vilket resultat som skall åstadkommas, samt vilka begränsningar som finns avseende hur

23

projektarbetet skall gå till, kan strategier väljas för genomförandet. Alltså vilket tillvägagångssätt som skall användas inom viktiga områden som t.ex. arbetssätt, teknik, arbetsplats och verktygsval.

5. Strukturera projektet: När tillvägagångssättet är klart kan arbetet struktureras och delas upp i mindre aktiviteter som går att planera, specificera, delegera och följa upp.

6. Uppskatta resurs och tidsåtgång: Därefter kan resursförbrukningen beräknas, och hur lång ledtiden blir för varje aktivitet.

7. Analysera beroenden: Aktiviteterna kan inte genomföras slumpmässigt, utan en beskrivning av inbördes beroenden måste göras. Alltså vilka som kan görasparallellt och vilka som måste göras i sekvens.

8. Göra tidsplan: När man har översikt över alla aktiviteter, ledtider och inbördes beroenden kan allt placeras ut efter en tidsaxel.

9. Göra budget: Nu kan man utifrån alla aktiviteter och deras resursförbrukning beräkna kostnaden fördelat över ett tidsperspektiv, och vilka typer av kostnader som finns.

Fasen organisera

10.Definiera projektorganisationen: Nu när alla resultat som skall levereras är klara, och vi vet vilket arbete som krävs, vilka resurser som går åt, och när i tiden arbetet skall utföras kan ansvarsområde definieras och bemannas.

11.Planera för kommunikation: Det sista som skall definieras är hur vi kommunicerar i projektgruppen och hur informationen görs tillgänglig, så att beslut snabbt kan tas och för att alla skall kunna klara sina åtaganden.

Likheter och skillnader i fasbeskrivningarna

Tonnquist (2010) har liksom Jansson och Ljung (2004) faser till grund i projektplanering (planering av projektet, ekonomi, risk & kvalitet och kommunikation), och beskriver under varje fas vad som bör göras, samt med vilken teknik. Egentligen är det inte någon större skillnad på författarnas sätt att beskriva projektplanering, utan det som Jansson och Ljung har valt att kalla ett logiskt steg innefattas av Tonnquists fasbeskrivningar, och där Tonnquist tar upp vad som skall göras, innefattas i Jansson och Ljungs faser. Tonnquist synsätt skiljer sig på denna punkt, med att inte sätta upp ett lika detaljerat logiskt flöde utan är något mer öppen. Jansson och Ljung väljer att se planeringsfasen något bredare, medan Tonnquist tar upp vissa aspekter under det arbetsteg som heter förstudie, men generellt är det samma typ av teknik som används.

4.1.2 Diskussion

Båda har alltså liknande synsätt på hur ett projekt skall planeras på bästa sätt, och det som i första hand skiljer sig är den logiska kedjan av steg som Jansson och Ljung (2004) förespråkar, medan Tonnquist (2010) mer kommer med beskrivningar utan något inbördes beroenden. Omorganisering i projektgruppen kan leda till att expertis försvinner och behöver ersättas, vilket har en direkt inverkan på när en aktivitet kan ske. Intressenter kan ändra sig, vilket i sin tur leder till att de ursprungliga kraven och resultaten behöver korrigeras, och det projektmål som sattes upp i början kan behöva utökas eller revideras. Detta är bara för att nämna några få beroenden, och allt som beskrivs av Jansson och Ljung (2004) i de elva logiska stegen påverkar på ett eller annat sätt vartannat.

24

Här ser vi en styrka i att som Jansson och Ljung se allt som ett logiskt flöde med inbördes beroenden att ta hänsyn till i den ständigt föränderliga ”verkligheten”, och då framförallt i realiseringsarbetet. Janson och ljung (2004) menar att det är de elva logiska stegen som bör användas som referensram när man planerar ett projekt, eller till och med när man tar ställning till enstaka ändringar, medan Tonnquist (2010) inte går in på de beroenden som finns i själva planen.

Riktar vi oss då mot mjukvaruutveckling, som är känt för att ha en ständig föränderlig verklighet och många beroenden, kan detta leda till att ursprungsplanen behöver ändras flera gånger pga. att ny teknik tillkommer under projektfasen. Att mjukvara är intangible leder till att i många aktiviteter måste ledtiden uppskattas. Detta i kombination med att det är vanligt att kunden inte vet riktigt vad den vill ha, ger flera beroenden (Sommerville 2010). Dessa faktorer gör att ett agilt arbetssätt är vanligt förekommande vid mjukvaruutveckling (Tonnquist 2010).

Planering i fem nivåer

Vid första anblick verkar projektledningsmetodiken ha en stark förankring i det plandrivna arbetssättet, och stämmer väl överens med vattenfallsmodellen (Sommerville 2010), men går även att applicera på det agila arbetssättet. Anledningen till att det är fullt applicerbart är att både agil och plandriven process har samma arbetssteg i grunden, och det som skiljer sig är hur de används (Gustavsson 2011). I det plandrivna arbetssättet planeras hela projektfasen ifrån start till mål, medan i det agila arbetssättet planeras varje etapp som ett projekt i sig, och därigenom går det att använda sig av samma faser, samt de elva logiska stegen i båda arbetssätten.

I traditionell projektledning planeras ett projekt med alla ingående detaljer i en enda plan, medan inom den agila approachen delas en plan in i fem nivåer (Gustavsson 2011):

1. Vision: Visionen ligger hela tiden kvar, samt vad projektet skall resultera i, och är den mest långsiktiga planen av projektet.

2. Färdplan: En färdplan är en översiktlig bild av när olika sorters projektresultat skall vara färdigställda, men utan ingående detaljer och garanterade datum. Färdplanen är näst efter visionen den mest långsiktiga planeringen av projektet och bör inte gå in på detalj.

3. Leveransplan: En leveransplan skall innehålla exakta tidsgränser och viktiga datum för projektet. Leveransplanen tas fram under projektets uppstart, men ändras vanligtvis flera gånger under projektets gång, efterhand som förutsättningarna ändras.

4. Etapplan: För varje etapp skall det levereras ett specifikt projektresultat, och slutdatumet för varje etapp är något som projektgruppen alltid strävar efter. Det som inte uppnås när en etapp är över stryks och tas upp vid uppstartsmötet när nästa etapp skall planeras.

5. Daglig plan: Vanligt är att varje dag startas med ett kort möte där allt tas upp som står inför dagens agenda. Dessa möten hålls vanligen på stående fot och varar ca 15 minuter för att bli så effektiva som möjligt.