Projektplaneringsverktyg och mjukvaruprojekt

Storlek: px
Starta visningen från sidan:

Download "Projektplaneringsverktyg och mjukvaruprojekt"

Transkript

1 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 Huvudämne: Datavetenskap Program: Data och telekom Datum för slutseminarium: Handledare: Göran Hagert Examinator: Marie Friberger

2

3 Resumé Projektarbete är ett dominerande arbetsätt inom de flesta branscher. I IT/ISbranschen ä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.

4

5 Innehåll 1. Inledning Bakgrund Problemformulering Syfte Frågeställning Målgrupp Avgränsning Definitioner Metod Metodval Induktiv eller deduktiv ansats Kvalitativ sekundäranalys Flermetodsforskning Strategi vid litteraturval Dominerande litteratur Presentation av studiens huvudlitteratur Strategi vid val av undersökningsobjekt Två kategorier av projektplaneringsverktyg Ytterligare sållning Metoddiskussion Källkritik Teori Mjukvaruprocesser Processmodeller Vattenfallsmodellen Inkrementell utveckling Återanvändning Generella steg för projektledning Förstudie Planering Genomförande Överlämning Avslut Agil projektledning Scrum... 20

6 3.4.2 Scrum-master och produktägare Resultat och diskussion Övergripande projektplanering Resultat Diskussion Avgränsa och integrera Resultat Diskussion Planera Resultat Diskussion Organisera Resultat Diskussion Sammanfattning och jämförelser Resultat Sammanfattning av funktioner Presentation av undersökningsobjekten Diskussion Avslutande diskussion Endast ett hjälpmedel Urvalet kan påverka Projektplaneringsverktygets värde Studiens styrkor och svagheter Vidare studier Källförteckning... 45

7 Figurförteckning 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 Tabell 1: Sammanfattning av funktioner...37 Tabell 2: Jämförelse av projektplaneringsverktyg...39

8

9 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 1

10 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 har The Standish Group s CHAOS Manifesto granskat över 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). 2

11 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/ISbranschen ä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. 3

12 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 4

13 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). 5

14 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). 6

15 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) 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) 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 7

16 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) 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: 8

17 Halmstad högskola Karlstads universitet Linnéuniversitet Luleås universitet Malmö högskola Skövde högskola Stockholms universitet Umeås universitet Uppsalas universitet 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 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 9

18 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 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 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 ITresurser (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 10

19 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 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). 11

20 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) 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 12

21 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. 13

22 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. 14

23 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) 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). Kravdefinition Design Implementation och enhetstest Integration och systemtest Införande underhåll och 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. 15

24 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) 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). Specifikation Första versionen Översiktlig beskrivning Utveckling Mellanliggande versioner Validering Slutversion 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). 16

25 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). Kravspecifikation Komponentanalys Kravändring Systemvalidering Utveckling och integration Systemdesign med återanvändning 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). 17

26 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). Förstudie Planering Genomförande Överlämning Avslut Figur 4: Generella arbetssteg för projektledning 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 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. 18

27 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) 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). Initiera och följa upp Anpassa planerna Bedöma risk och möjlighet 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 Ö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. 19

28 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) 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) 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). 20

29 Sprint 2-4 v. Produktlogg Etapplogg Delleverans Dagliga möten 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) 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). 21

30 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 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 22

31 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öras parallellt 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 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. 23

32 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. 24

33 Förändringar i tidsplanen Det som är gemensamt i litteraturen är att planer är i ständigt behov av att kunna ändras på ett effektivt sätt. Utifrån detta är en självklar funktion i ett planeringsverktyg att aktiviteter, tidsplan och resursbehov med lätthet måste gå att ändra. Tydliga behov utifrån att olika variabler har inbördes beroende (Jansson & Ljung 2004) är också att när en ändring görs i en variabel måste det få genomslagskraft även i de variabler som är direkt kopplade, såsom när en aktivitet tas bort måste även resursbehovet och tidsplanen per automatik korrigeras. För att användningen av scrum skall bli så effektiv som möjligt behövs en direkt koppling till produktloggen, som i sin tur går att dela in i flera etapploggar 4.2 Avgränsa och integrera Resultat Planeringsfasen inleds vanligen med att projektet måste avgränsas. En kartläggning görs över vilka som har förväntningar eller krav på projektet, vem som kan tillföra resurser eller har intressen som kolliderar. Nyckelintressenter är särskilt kartlagda beträffande hur de förväntas påverka projektet. Med intressent menas alla organisationer och individer som berörs av, eller kan påverka projektet. Drar man det till sin spets betyder det att hela världen är en intressent (Jansson & Ljung 2004). Vanligen nöjer man sig med mindre än så, men det kan vara vanskligt att bedöma och identifiera alla intressenter som kan utöva en påverkan på projektet. Viktiga intressenter kan hittas inom flera områden såsom uppdragsgivare, finansiärer, slutanvändare, kund och kundens kund (Jansson & Ljung 2004). Tonnquist (2010) tar upp fler exempel på intressenter, såsom företagsledning, beställare, leverantörer, andra projekt, allmänheten, fackföreningar och faktiskt projektgruppen som skall genomföra själva projektet är en intressent. Här delas intressenterna in i kärnintressenter, primärintressenter och sekundärintressenter. Den förstnämnda är de med beslutsfattande och/eller har drivande roller i projektet. Primärintressenter är de som i hög grad påverkas av projektet, och vill därför vara med och påverka. Den sistnämnda är de som har ett relativt lågt intresse och troligen inte kommer att aktivt påverka projektet, men är ändå av intresse (Tonnquist 2010). Vanligt är att en matris görs där intressenterna radas upp och kommenteras. De intressenter som anses viktigast analyseras in på individnivå (Jansson & Ljung 2004, Tonnquist 2010). Krav och behov Vidare analyseras krav och behov för att ta fram en tydlig specifikation över vad projektet skall tillfredställa. I denna fas ligger fokus på att ta fram en kravspecifikation som fastställs av projektbeställare, kund och de som står för genomförandet. Kravspecifikationen ligger till grund för att utforma beskrivningar av det tänkta resultatet, och är den referens som används för att avgöra när ett projekt är klart (Jansson & Ljung 2004). Vid användandet av det agila arbetssättet scrum är det i produktloggen som kraven specificeras, och här är kravspecifikationen något mindre detaljerad, och är oftast beskriven utifrån 25

34 kundens terminologi (Gustavsson 2011). Inom mjukvaruutveckling innebär detta att allt tolkas löpande, och reella krav sätts upp efterhand. Kraven på de funktioner som finns inom närmaste framtiden är detaljerat beskrivna, medan de som ligger längre fram har en mer översiktlig beskrivning (Gustavsson 2011). PBS En målformulering görs, vilken bör sikta på tydlighet, realism, mätbarhet och förankring. De mål som vanligen arbetas fram inom alla projekt är verksamhetsmål, effektmål och projektmål. Dessa har flera syften, såsom att veta när man är klar, se en mening med sitt engagemang och kunna förmedla vad det går ut på (Jansson & Ljung 2004). Här förespråkas en teknik vid namn Product Breakdown Structure och förkortas PBS (Figur 7), vilket är vedertaget begrepp även på svenska. Självgående dammsugare 1. Damsugarenhet 2. Drivanordning 3. Dockningsstation 1.1 Kropp 2.1 Motor 3.1 Nätanslutning 1.2 Avfallspåse 2.1 Mikrochip 3.2 Mikrochip Figur 7: Product Breakdown Structure (PBS) Oberoende om det rör sig om ett plandrivet eller agilt arbetssätt är PBS en vanlig metod för att definiera krav och mål. Den går ut på att skapa sig en överblick över de faktiska komponenter, t.ex. vad en programvara kan tänkas innehålla. Ovanstående är endast ett mindre exempel, och vid genomförandet av en projektplan förgrenas det ytterligare ända tills det hela blir hanterbart. T.ex. blir mjukvaran indelad i mindre och mindre komponenter, kan t.ex. gränsen dras vid enskilda objekt Diskussion I den inledande delen av planeringsarbetet är således ett sätt att avgränsa projektet och få en struktur, för att vidare förstå de krav och komponenter som ingår. Enligt Jansson och Ljung (2004) ingår detta under själva planeringsarbetet, medan Tonnquist (2010) menar att detta ingår under förstudiearbetet. Egentligen skiljer sig inte synsätten något nämnvärt, utan Tonnquist (2010) innefattar en del planering i förstudiefasen, medan Jansson och Ljung (2004) har det som en del av de elva logiska stegen, och ingår under den inledande planeringsfasen. Det som genomsyrar hela uppstarten av planeringsarbetet är behovet av någon form av dokumenthantering kopplat till projektplaneringsverktyget. Modellerbar PBS Den viktigaste är en PBS som tillåter modellering av komponenterna, vilket ger en bra översikt, både övergripande och på detaljnivå. Även i det agila arbetssättet är 26

35 det bra med PBS (Gustavsson 2011), och görs vid framtagandet av färdplanen, fast då är nedbrytningen något mindre detaljerad. PBS går direkt att koppla till tidoch resursplaneringen, vilket gör den bra till att korrigera bemanning och budget. Därav vikten med att den är modellerbar efterhand som ändringar i kraven behöver göras. Detta går också samman med de direkta beroenden som finns vid planering och realiseringen av ett projekt (Jansson & Ljung 2004). När en komponent behöver utökas, ändras eller tas bort kan resursen (bemanningen) med lätthet flyttas till mer behövande uppgifter, och budgeten kan direkt korrigeras. Strukturen i en PBS gör det möjligt att till varje komponent koppla en anteckningsfunktion med beskrivningar av själva komponenten. 4.3 Planera Resultat När det är klart vilket resultat som skall åstadkommas, samt avgränsning i krav och projektmål är gjorda, 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. Vid det här laget är det strategi för genomförandet som är i fokus. Strategi betyder: Läran om användningen av militära och andra maktmedel för att i kamp med en motståndare nå politiska mål, såväl krigsmål som andra mål såsom att bevara fred, upprätthålla neutralitet och att ändra eller bevara maktförhållanden (nationalencyklopedin 2012). Numera används begreppet i ett vidare sammanhang, och inom projektledning betyder det ungefär tillvägagångssätt (Jansson & Ljung 2004). Ett sätt, är att tänka i scenarier för att diskutera alternativa strategier. Olika vägval kan påverka olika variabler vid genomförandet. Jansson och Ljung (2004) menar att följande fem steg kan vara bra att gå igenom oavsett vilken typ av projekt det rör sig om: 1. Vilka är de kritiska framgångsfaktorerna: Identifiera vilka områden som bara inte får gå fel i projektet, och alltså är kritiska framgångsfaktorer. 2. Vad kan hota projektets framgång: Tänka igenom vilka situationer som kan uppstå och är ett direkt hot mot de kritiska framgångsfaktorerna, och gör en riskanalys. 3. Vad säger kraven om möjliga strategier: Under kravanalysen har krav samlats in som innebär begränsningar av tillvägagångssätten. 4. Identifiera och bedöm tänkbara strategier: Diskutera vilka strategier som är tänkbara för att hantera det som de kritiska framgångsfaktorerna handlar om. 5. Välj projektstrategier: Besluta om viktiga strategier för viktiga områden för att klara de kritiska framgångsfaktorerna. 27

36 WBS Nu när kravanalysen och beskrivningen av resultatet har givit en tydlig bild av projektet, behöver projektarbetet struktureras. Här förespråkas (Jansson & Ljung 2004, Tonnquist 2010) att en Work Breakdown Structure (WBS) görs för att bryta ner projektarbetet i mindre hanterbara delar (Figur 8). Projektet A B C D E F G H I J K L M N Figur 8: Work Breakdown Structure (WBS) I en WBS (vedertaget begrepp även på svenska) sätts projektets namn i topp, för att vidare bryter ner det enligt en hierarkisk struktur, ända tills det inte går att bryta ner mer. När aktiviteterna inte går att bryta ner mer så bildare de arbetspaket (Jansson & Ljung 2004, Tonnquist 2010). Arbetspaketen är projektets minsta beståndsdel, och ligger till grund för arbetsfördelningen. Top down eller bottom up När projektet skall brytas ner med en WBS finns två angreppssätt. Det ena angreppssättet är top down, vilket innebär att man börjar nedbrytningen med att bestämma indelningen på första nivån, t.ex. efter projektresultatets delar, för att sedan vidare bryta ner i mindre och mindre delar tills de är lagom stora arbetspaket. Andra angreppssättet är bottom up, vilket innebär att man börjar med att skriva ner alla arbetspaket som kan tänkas ingå, för att vidare gruppera arbetspaketen, och på såsätt ta fram huvudgrupper. Top down är lämplig när det rör sig om ett okänt och svårbestämt projekt inom t.ex. nya områden. Bottom up lämpar sig när projektgruppen är väl förtrogen med projektuppgiften. Båda angreppsätten kan inom större projekt kombineras (Jansson & Ljung 2004). Därefter sammanställs och beskrivs arbetspaketen. Logiskt nätverk och kritisk linje När arbetspaketen är framtagna kan tiden för vart och ett uppskattas för att vidare analysera beroenden. Vanligaste sättet är att rita ett logiskt nätverk med hjälp av de framtagna aktiviteterna (Figur 9) (Jansson & Ljung 2004, Tonnquist 2010). 28

37 M1 1 START A (6v) B (2v) C (2v) M2 SLUT D (4v) E (5v) F (1v) Figur 9: Logiskt nätverk Andra namn för samma sak är nätverksdiagram och nätplan (Jansson & Ljung 2004, Tonnquist 2010). Olika tekniker förespråkas för att uppskatta tidsförhållanden i projektet. Inom det agila arbetssättet förekommer också nätplanen, och tas fram i samband med färdplanen, men illustrerar då när olika leveranser måste ske (Gustavsson 2011). Ett nätverksdiagram ritas upp med avsikten att illustrera de beroenden som finns, t.ex. när vilket objekt måste kodas/implementeras innan man vidare kan börja på nästa. Nätverksdiagrammet är också bra för att se den totala ledtiden i projektet, samt hur den kritiska linjen ter sig (se Figur 9 fetstil). Man letar då efter den kedja av sammanhängande arbetspaket som har längst sammanlagd ledtid. Denna kedja kallas projektets kritiska linje (Jansson & Ljung 2004:321). PERT och CPM Två vanliga tekniker är Program Evaluation and Review Technique (PERT) och Critical Path Method (CPM), där vedertagna svenska begrepp är PERT och CPM. Båda teknikerna bygger på en ledarskapssyn som utgår från att verkligheten kan förutsägas om man bara bearbetar planeringsdata tillräckligt väl. Bäst fungerar metoderna i projekt som är stora, komplexa och där man är väl förtrogen med den typ av arbete som ska genomföras (Jansson & Ljung 2004:325). PERT utvecklades i första hand för att kunna hantera stora projekt inom den amerikanska marinen på 1950-talet, och är en mycket vanlig teknik inom projektplanering. Tekniken fungerar bäst inom större och mer komplexa projekt. Den bygger på att tre ledtider arbetas fram för varje aktivitet: en optimistisk, en pessimistisk och en trolig. Dessa värden ligger sedan till grund för att beräkna, med viss sannolikhet, när projektet är klart. PERT tekniken tar alltså hänsyn till att ledtiden för aktivitet är osäker. CPM utvecklades ungefär samtidigt inom DuPoint Company, och kan till viss del liknas vid PERT. Båda teknikerna utgår ifrån resursåtgång, men CPM använder sig inte av osäkerhetsmått, utan istället tillför man mer resurser i anknytning till den kritiska linjen för att kompensera eventuella avvikelser i arbetspaketens ledtid. 29

38 Milstolpeplan Längs den kritiska linjen sätts milstolpar (se Figur 9 M1 och M2) upp, och är ett sätt att knyta ihop flera aktiviteter som är beroende av resultatet av en aktivitet eller händelse (Jansson & Ljung 2004). En milstolpe är något som skall ha uppnåtts (Tonnquist 2010), t.ex. kravanalysen klar, kravspecifikationen färdigställd, etc. Vanligen integreras milstolparna i nätverksdiagrammet, men kan med fördel lyftas ur och bilda en milstolpeplan (Tonnquist 2010). En milstolpeplan ritas enligt ett nätverksdiagram utan att arbetspaketen finns med, och bör enligt Tonnquist (2010) innefatta maximalt 20 milstolpar. Finns det fler än så bör de delas in i flera nätverksdiagram. Avsikten med en milstolpeplan är att ha tydliga avstämningspunkter som hjälper projektledaren att följa arbetet. Inom det agila arbetssättet är det under framtagandet av leveransplanen som milstolpar sätts upp. Inom traditionell projektledning har begreppet etappmål samma betydelse som milstolpe, men i agil projektledning skiljer sig etappmålens betydelse, och är till för att beskriva vad de olika etapperna innefattar för mål (Gustavsson 2011). Inom det agila arbetssättet ritas vanligen inte en milstolpeplan upp, utan en etapplan. Tidsplan Nästa steg är att göra en tidsplan, och det vanligaste verktyget är Gantt-schemat (Tonnquist 2010) (se Figur 10). Användningen av Gantt-schema går tillbaka långt före begreppet projekt fick den betydelsen det har idag. Henry Gantt utvecklade tekniken i början av 1900-talet, och var ursprungligen till för att grafiskt åskådliggöra hur arbetsuppgifter i en verksamhet fördelas mellan olika individer eller grupper, och när i tiden dessa skulle genomföras (Jansson & Ljung 2004). Figur 10: Gantt-schema Numera har Gantt-schemat utökats med milstolpar (Figur 10, se M1 och M2), beroenden mellan aktiviteter och beslutspunkter. Gantt-schemat har blivit en symbol för tidsplanering (Jansson & Ljung 2004). Resursgraf och resurshistogram Vidare är det av vikt att identifiera resurskonflikter som är ofrånkomliga, och vanliga metoder är att göra en resursgraf (Figur 11) eller ett resurshistogram (se Figur 12) (Jansson & Ljung 2004, Tonnquist 2010). 30

39 Figur 11: Resursgraf i tabellform Figur 12: Resurshistogram Båda fungerar för att se överutnyttjande och att hantera resurskonflikter. En resursgraf är mer detaljerad än ett resurshistogram. I resursgrafen visas överskottet i form av ett negativt värde i tabellen. Exemplet ovan (Figur 11) påvisar ett överskott på 40 timmar. I ett resurshistogram sammanställs antalet resurser som är inplanerade i de olika aktiviteterna i projektet per dag. Om man tänker sig att aktivitet sju har sex dagar inplanerade för genomförande, och en reservtid på en dag, illustreras det med en markering (Figur 12, se svartmarkering). Budget När resurskonflikterna identifierats är det dags att göra en budget för att beskriva hur mycket projektet kommer att kosta totalt. Projektkalkylering kan göras grovt eller detaljerat, beroende på vilka krav som finns ifrån den övriga organisationen. Även här kan begreppen top down och bottom up (Tonnquist 2010) användas på liknande sätt som vid en WBS. Top down innebär att en grov bedömning görs, genom att jämföra liknande projekt som tidigare genomförts. Bottom up innebär en detaljerad kalkylering av varje enskild aktivitet. Att strukturera en budget kan göras på flera sätt. Vanliga sätt enligt Jansson och Ljung (2004) är: Budget efter projektarbetsstruktur eller produktstruktur: Innebär att man delar in budgeten på samma sätt som arbetet är indelat i arbetspaket eller komponenter (WBS eller PBS). Budget per organisatorisk del: Bygger på att budgeten delas in på delprojekt eller team. Budget enligt moderorganisationens behov: Projektets kostnader kommer att bokföras i moderorganisationens bokföringssystem, och är därigenom en del av den totala kostnaden, vilket betyder att de ramar som finns måste följas. Kalenderindelad budget: Innebär man går efter när i kalendertid olika arbetspaket genomförs, och tar fram kostnaden t.ex. veckovis. Vilken metod som används är individuellt, och beroende på vilken organisation som projektet genomförs inom. Det vanligaste sättet inom mjukvaruutveckling är, som nämns ovan, att följa den arbetsstruktur som finns i form av tidigare nedbrytning av projektet (WBS) (Sommerville 2010). 31

40 4.3.2 Diskussion Vid ett byggprojekt finns också risker, men det finns en trygghet i att de oftast går att beräkna ända ner på skruv och spiknivå, medan inom mjukvaruutveckling har man inget direkt att ta på, utan en så hållbar plan som möjligt tas fram för att vidare korrigeras efterhand. Så länge det rör sig om mindre mjukvaruprojekt är den agila metoden, i form av scrum, bra just för att delkomponenter kan användas i tidigt stadium och utvärderas. Detta gör att planeringen kan begränsas till endast en kort tidsperiod. Problemet med agila processer är att de inte lämpar sig för stora system med lång livslängd, och inte när det rör sig om system med hög säkerhet. Här har en plandriven process klara fördelar (Sommerville 2010). I kravspecifikationen finns sammanställningen av de analyserade kraven, och dessa ger i sin tur möjliga strategier. Inom mjukvaruutveckling är det vanligt att man utgår ifrån kraven för att ta fram användningsfallscenarion (Sommerville 2010), och de kan i sin tur råda klarhet i arbetsstrukturen. Sommerville (2010) menar att den perfekta modellen för att genomföra ett mjukvaruprojekt inte finns, utan vanligen kombineras olika processmodeller. Under ett större projekt kan det mycket väl finnas behov av att kombinera agil och plandriven process för att skapa en flexibilitet. Här ser vi ett behov av att kunna hantera både agil och plandriven planering kombinerat i ett och samma planeringsverktyg. Kombinera PBS och WBS Tidigare nämns att Jansson och Ljung (2004) ser en stor betydelse i att all planering sker i ett visst flöde, och att allt är beroende av vartannat. Tonnquist (2010) har något öppnare synsätt när det gäller beroenden, men under denna fas, som berör strukturering av projektarbetet, är ordningsföljden något som de har gemensamt (Figur 13). WBS och/eller PBS Nätplan med aktiviteter, milstolpar och kritisk linje Aktivitetslista, Tidsplan - Gantt-schema Resursgraf och/eller resurshistogram Figur 13: Projektplaneringsflöde Dessa är viktiga verktyg i planeringsarbetet, och vi ser ett stort behov av dessa funktioner i ett projektplaneringsverktyg. Att kunna arbeta med antingen WBS eller PBS, eller en kombination är viktigt i alla typer av projekt, och då framförallt inom mjukvaruutveckling med tanke på komplexiteten (Fox & Spence 2005). Vid första anblick kan WBS och PBS verka som samma teknik, vilket inte är fallet. PBS (Product Breakdown Structure) är precis vad namnet beskriver en nedbrytning av själva produkten som skall tillverkas, medan WBS (Work Breakdown Structure) är en nedbrytning av hela projektarbetet. Vid en komplex uppgift är det vanligt att båda teknikerna används och integreras med varandra. En PBS görs oftast i ett tidigare skede än en WBS, och är mycket till för att få en koll på vilka komponenter själva artefakten består av. En WBS är mycket mer detaljerad än en PBS, och lämpar sig inte för alla typer av projekt. 32

41 PBS och WBS som hjälpmedel i framtida projekt När det rör sig om en agil process fungerar inte en WBS pga. att den för detaljerad, utan här är en PBS att föredra (Gustavsson 2011). Även inom plandrivna projekt kan en WBS låsa utvecklare till vissa lösningar i ett tidigt stadium. Allt beror på vilken typ av projekt, och vilken utvecklingsprocess som används. Både WBS och PBS fungerar bra vid användning av t.ex. objektorienterade programmeringsspråk, då enskilda objekt kan fungera som avgränsade arbetspaket. En stor fördel med att göra en WBS är att den kan vara ett hjälpmedel i framtida identifiering av aktiviteter i liknande projekt (McManus & Wood-Harper 2003). Detta genom att kunna gå tillbaka till tidigare projekts WBS för att utkristallisera vilka objekt som kan ingå i en intern återanvändningsprocess (Sommerville 2010). Nätplan Nätplanen spelar också en stor roll för att se beroenden, samt att en kritisk linje kan ritas upp för att se den totala ledtiden. För att uppskatta ledtiden för varje arbetspaket rekommenderas PERT och CPM. Metoderna PERT och CPM är något som även framhålls av andra forskare (se t.ex. Maylor 2005) som bra verktyg vid framtagningen av nätplanen. Kritik mot kritiska linjen Kritiska linjen har stor betydelse, och är något som hela planeringsarbetet kretsar kring. Det finns dock forskare som kritiserar det vanliga sättet att utgå ifrån den kritiska linjen i planeringsarbetet. Goldratt (1997) menar att kritiska linjen endast tar hänsyn till logiska beroenden, och att projektets totala ledtid är beroende av mer än så. Han menar att den totala ledtiden är beroende av en kedja av aktiviteter, såsom resursberoenden (t.ex. nyckelpersoner), och enskilda individers beteende när de planerar sitt arbete. Användningen av kritiska linjen är i de flesta fall en vedertagen teknik (se även Antvik & Sjöholm, 2005), och i denna uppsats väljer vi utifrån studerad litteratur att se den som ett viktigt verktyg för beräkningen av den totala ledtiden. Även att kunna markera milstolpar och sätta upp en milstolpeplan påvisas som viktiga funktioner, och något som även andra forskare framhåller (se exempelvis Antvik & Sjöholm, 2005). Gantt-schema som tidsplaneringsmetod Den vanligaste förekommande tidsplaneringsmetoden är gantt-schemat (Tonnquist 2010), och är den metod som är mest utbredd när det gäller traditionell projektplanering enligt en plandriven process. Gantt-schemat är kanske det mest centrala och betydelsefulla för projektplanering, och något som framhålls av ledande forskning inom projektledning (se även Antvik & Sjöholm 2005, Högberg 2007, Lock, 2001). Inom agil projektledning används även Gantt-schema, men då för att illustrera leveransplanen, och inte för enskilda aktiviteter. En tänkbar funktion, förutom milstolpar och aktiviteter, är att komplettera gantt-schemat med är en indikator på att vi faktiskt är i fas med allt. Alltså en uppföljningsfunktion att använda sig av i realiseringsfasen. Identifiera resurskonflikter Vidare framhåller Jansson och Ljung (2004) resursgrafen i tabellform som ett bra sätt att identifiera resurskonflikter, medan Tonnquist väljer att använda sig av resurshistogram för att illustrera resurskonflikter. Här ser vi ett behov av båda då 33

42 resursgrafen är bra för att se exakta värden, medan resurshistogrammet ger en snabb återkoppling till beroendet. Vi ser även en fördel i att integrera funktion för att kunna ta fram och hantera en budget. Detta för att snabbt kunna koppla enskilda aktiviteter med en direkt kostnad. 4.4 Organisera Resultat Att organisera projektet innebär att dela upp arbetet mellan de människor som ingår i projektgruppen (Jansson och Ljung 2004). En bra organisation gör att deltagarna kan agera samordnat, beslutsamt, självständigt och snabbt (Jansson & Ljung 2004:377). OBS Projektledaren är instoppad i en grupp för att leda gruppen istället för att organisationens chefer skall sköta det operativa arbetet. Eftersom ett projekt är en engångsföreteelse måste en ny organisation skapas för varje projekt (Jansson & Ljung 2004). Det vanligaste sättet är att beskriva organisationen i form av en hierarkisk struktur med ansvarsområden, en såkallad Organizational Breakdown Structure (OBS) (Figur 14). Projektbeställare Namn, produktchef Projektledare Namn Programmering Namn Teknisk konstruktion Namn Kundutbildning Namn AB CD EF GH I Figur 14: Organizational Breakdown Structure (OBS) Ett organisationsschema kan vidare kompletteras med flera funktioner. Organisationsschemat kan innehålla styrgrupp, referensgrupp, resursägare, stab etc. Allt beror på vilka behov man har och hur det skall användas. Att ha ett organisationsschema innebär att alla vet sina arbetsuppgifter (vilka arbetspaket man ansvarar för). För att ta fram ett hållbart organisationsschema är de viktigt att se över vilka förutsättningar som finns för genomförande av projektet, och om projektledningsfunktionen kan delas upp (Jansson & Ljung 2004). 34

43 Kommunikation Sista steget är att planera för kommunikationen inom projektgruppen och med externa intressenter. För att projektgruppen ska veta vad den ska göra, projektledaren ha kontroll och beställaren känna sig trygg är det viktigt att kommunikationen fungerar i ett projekt (Tonnquist 2010:159). Mål, planer, resultat och ändringar måste snabbt och effektivt kunna förmedlas både internt och externt. Att planera kommunikationen är viktigt för projektgruppens existens. Planering av kommunikationen har ett syfte till, nämligen att underlätta och uppmuntra kommunikationen som bidrar till samhörighet, trygghet, öppenhet, meningsfullhet och handlingskraft (Jansson & Ljung 2004:403). Kommunikationen kan ske på flera plan, men i denna uppsats är det i första hand hur kommunikationen sker rent tekniskt. Än en gång refererar vi till annan litteratur när det rör sig om det mer gruppsykologiska perspektivet (se exempelvis Svedberg 2007) Diskussion Rätt kompetens för uppgiften, samt ett övergripande ansvar för respektive arbetspaket! Det är viktigt att organisationsstrukturen i projektgruppen identifieras. Jansson och Ljung (2004) menar att en bra organisation leder i förlängningen till att gruppmedlemmarna agerar samordnat. Användningen av OBS-metoden är ett bra komplement till en WBS just för att gruppmedlemmarna vet sina ansvarsområden. Rätt bemanning med hjälp av OBS Såhär långt fram i planeringen har krav fastställts, projektet brutits ner, nätplan gjorts för att se beroenden, kritiska linjen tagits fram, resurskonflikter utretts, budget tagits fram och tidsplanen fastställts. Respektive gruppmedlem tilldelas ansvarsområde efter kompetens. Projektledaren får också en överblick på vilka kompetenser gruppen eventuellt saknar. Det som inte framkommit tidigare i planeringen syns tydligt när organisationsschemat är fastställt. Ytterligare bemanning kan tillkomma i form av interna och/eller externa konsulter. Styrkan med en OBS är att respektive gruppmedlem får sina arbetsuppgifter fastställda. Tänker man sedan i termerna projektplaneringsverktyg anser vi att det är av stor vikt att kunna använda sig av en OBS som är modellerbar, och där en ändring får genomslagskraft i den övriga planeringsstrukturen. Den ger också tydliga signaler på vilken kompetens som saknas om en gruppmedlem av någon anledning skulle avvika. Kommunikationsplattform Avslutningsvis framhålls kommunikationen som en av de viktigaste faktorerna för ett framgångsrikt projekt. Finns det inte en bra plattform att tillgå är det inte mycket till övers för projektarbetet. Med plattform menas en plats där 35

44 gruppmedlemmarna snabbt kan komma i kontakt med varandra, och förmedla framgångar och problem. Viktigt är att projektledaren hela tiden kan se vad som händer, för att snabbt kunna agera vid eventuella problem och ändringar. Jansson och Ljung (2004) påpekar att ändringar i projektplanen garanterat kommer att ske, och då måste gruppen snabbt kunna ta dela av ändringarna. Tänkbar funktion är att integrera en kommunikationsfunktion i planeringsverktyget för att med lätthet kunna dra paralleller mellan planeringsstrukturen, och de problem som eventuellt uppkommer. Ännu tydligare blir kommunikationens brister vid agila processer, som helt och hållet bygger på att gruppmedlemmarna har en nära kommunikation sinsemellan. Skillnaden är att vid agila processer, såsom scrum, träffas vanligtvis gruppmedlemmarna dagligen och kan kommunicera fysiskt, medan vid en plandriven processer kan det gå i princip hur lång tid som helst mellan fysiska träffar. Det kan vara så att gruppmedlemmarna arbetar i olika städer, länder eller till och med olika världsdelar, vilket ställer stora krav på ett kommunikationsverktyg. 4.5 Sammanfattning och jämförelser Resultat Med hjälp av studerad litteratur, och annan stödlitteratur, har vi nu fått fram en rad tänkbara funktioner som ett planeringsverktyg kan tänkas innehålla. Gemensamma nämnaren i de tänkbara funktionerna är vikten av att genomföra planeringsarbetet i en logisk ordningsföljd, samt att vid realiseringsarbetet kunna göra ändringar på ett ställe i planen, vilket bör ge genomslagskraft även på övriga delar. Tonnquist (2010) tar till en början inte upp några direkta beroenden, men när planeringsarbetet når det vi valt att kalla sin mittfas (planera), förespråkas samma logiska ordning som Jansson och Ljung (2004) (Figur 13 projektplaneringsflöde). Sammanfattning av funktioner För att då återkoppla till vår huvudfråga angående vilka funktioner ett projektplaneringsverktyg, avseende mjukvaruutveckling, bör tillhandahålla i relation till den dokumenterade projektledningsmetodiken, påvisar ovanstående analys av materialet att följande variabler (Tabell 1) är av vikt vid projektplanering. 36

45 Funktion Dokumenthantering Tabell 1: Sammanfattning av verktygsfunktioner (mätinstrument) Product Breakdown Structure (PBS) Work Breakdown Structure (WBS) Nätverksdiagram Critical Path Method (CPM) Program Evaluation and Review Technique (PERT) Kritisk linje Milstolpeplan Etapplan Aktivitetslista Tidsplan (Gantt-schema) Produktlogg Resurshistogram/resursgraf Budgethantering Förklaring Hantera dokument såsom kravspecifikation, arkitekturdokument, designdokument och testdokument. Med hantering av dokument menas en snabb åtkomst, och möjlighet att kunna koppla ihop övriga planen med exempelvis kraven. Bryta ner den tänkta produkten i nödvändiga delar, samt kunna modellera med delarna. Denna metod är framförallt för stöd inom agila metoder. Bryta ner projektet till arbetspaket, kunna modellera, kunna lägga till och ta bort arbetspaket. Rita upp en nätplan och klargöra inbördes beroenden. Hantera osäkerhet inom projektplaneringen. Hantera osäkerhet inom projektplaneringen. Kunna per automatik få kritiska linjen utritad. Kunna se vad den faktiska ledtiden är för genomförandet. Nätplan med milstolpar för att ge en snabb överblick av projekt. Denna funktion behövs för att kunna hantera scrum, och skall kunna delas in i etapper. En aktivitetslista med möjlighet att kunna beskriva aktiviteter och koppla till tidsplanen. Tidsplan med aktiviteter, milstolpar och en möjlighet till uppföljning av tidsplanen, samt en indikator på att allt är i fas. En produktlogg med möjlighet att kunna hantera flera etapploggar. Denna funktion behövs för att kunna hantera scrum. Identifiera resurskonflikter och överbelastning. Budget direkt kopplad till aktivitetslistan och tidsplanen. Organisationsschema med ansvarsfördelning. Organizational Breakdown Structure (OBS) Kommunikation Möjlighet till kommunikation mellan gruppmedlemmar, externa och interna intressenter, t.ex. diskussionsforum. 37

46 Presentation av undersökningsobjekten Nedan följer undersökningsobjekten tillsammans med en kortare beskrivning (hämtat från respektive). Hur urvalet är gjort presenteras i metodavsnittet (se avsnitt 2.3), och följande fakta är till för att ge en kortare beskrivning, samt om det rör sig om en traditionell eller molnbaserad tjänst. Ace Project: Lanserades år 2001 som ett gratisalternativ under namnet FreeTaskManager, för att sedan år 2003 byta till nuvarande namn. Idag är programmet molnbaserat, och tillhandahåller både gratis och betalversioner. Är i det närmaste unikt med att tillhandahålla molnbaserad tjänst gratis. Copper Project: Lanserades år 2001 av Element Software. Endast betalversion med molnbaserad lagring. Microsoft Project: Första versionen av Microsoft Project lanserades redan år 1984 till DOS, och kom till genom att den dåvarande chefen för produktutveckling, Alan M. Boyd, arbetade fram en specifikation som ett mindre företag i Seattle utvecklade. Året efter köpte Microsoft alla rättigheter till programmet och lanserade version två samma år. Första versionen till Windows släpptes år 1990, och därefter har flera versioner släppts. Finns endast i betalversion, och lagring sker lokalt. Mingle: Lanserades år 2007 av ThoughtWorks Studios, och är specialiserat på agil projektplanering. Verktyget stödjer flera typer av agil utveckling, bl.a. scrum. Endast betalversion med molnbaserad lagring. OpenProj: Lanserades år 2008, och sägs vara ett gratisalternativ till Microsoft Project. Verktyget har laddats ned sammanlagt över gånger, och sägs vara i bruk i 142 länder. Lagring sker lokalt. Open Workbench: Lanserades redan år 1984 och sägs vara ett gratisalternativ till Microsoft Project. Utvecklades av Applied Business Technology, Corporation (ABT), vilka blev uppköpta av Niku Corporation år Vidare köptes de i sin tur upp av CA Corporation år 2005, som i dag äger och driver utvecklingen. Lagring sker lokalt. Pivotal Tracker: Utvecklades år 1989 av Pivotal Labs, och var till en början inriktat på traditionell projektledning. År 2008 gick fokus över på agila metoder, och år 2011 fanns det över registrerade användare. Project Kickstart: Första versionen lanserades år 1992 till Dos, men gick fr.o.m. andra versionen över till Windows miljö. Ägs och utvecklas av Experience in Software, Inc. i Berkeley, Kalifornien. Finns endast i betalversion, och lagring sker lokalt. Projectplace: Är ett planeringsverktyg med ursprung i Sverige, och första versionen lanserades år Projectplace har en stor spridning, och har över registrerade användare i 250 länder. Betalversion med molnbaserad lagring. 38

47 ProjectSpaces: Lanserades år 2000 av Forum One Communications. Endast betalversion med molnbaserad lagring. Jämförelse av undersökningsobjekten Nedan (Tabell 2) jämförs urvalet av projektplaneringsverktyg mot varandra och mot det framtagna mätinstrumentet (Tabell 1). Open Workbench och Open Proj innefattar flest funktioner, följt av Microsoft Project. De Agila verktygen (Mingle och Pivotal Tracker) innefattar i princip alla funktioner som man kan förvänta av en agil approach, medan de planeringsverktyg som riktar sig mot traditionell planeringsteknik har en större avsaknad. För att då återkoppla till vår underfråga angående hur ledande planeringsverktyg står sig gentemot varandra, den dokumenterade projektledningsmetodiken och ledande mjukvaruutvecklingsmetoder, håller tre av verktygen (Microsoft Project, Open Workbench och OpenProj) avsedda för traditionell projektplanering en god nivå, även om det finns mer att önska. Dessa tillhandahåller det mest centrala, och kan ses som självklara hjälpmedel vid planering och realisering av projektet. Tabell 2: Jämförelse av projektplaneringsverktyg Diskussion Intressant att notera är att Microsoft Project verkar ha en stark förankring i den planeringsteknik som förespråkas inom projektledningsmetodiken, med tanke på antalet funktioner som uppdagades. En förklaring kan vara att verktyget har en lång historia, och antagligen utvärderats av flertalet projektledare under åren. Intressant är också att de verktyg som utger sig för att vara ett gratisalternativ (Open Workbench och OpenProj) till Microsoft Project innehar fler funktioner. 39

Kursöversikt Certifierad Mjukvarutestare

Kursöversikt Certifierad Mjukvarutestare Kursöversikt Certifierad Mjukvarutestare Kurs Poäng (5 yh poäng/vecka) Examensarbete 20 Grunderna inom test 20 Kommunikation i arbetslivet 15 Lärande i arbete 1 60 Lärande i arbete 2 60 Projektarbete 15

Läs mer

PROJEKTLEDNING inom produktutveckling. Individuell inlämningsuppgift KPP039 Produktutvekling 3 Boris Mrden 2010-01-10

PROJEKTLEDNING inom produktutveckling. Individuell inlämningsuppgift KPP039 Produktutvekling 3 Boris Mrden 2010-01-10 PROJEKTLEDNING inom produktutveckling Individuell inlämningsuppgift KPP039 Produktutvekling 3 Boris Mrden 2010-01-10 Innehållsförteckning Inledning... 3 Projektarbete... 4 Projektledning & Ledarskap...

Läs mer

Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation

Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation Kurs: Designm etodik, 3 p Delm om ent: Datum : 2 0 0 3-1 2-1 8 Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation Nils Järgenstedt [ it3 jani@ituniv.se] Innehållsförteckning INLEDNING...

Läs mer

Projekt som arbetsform

Projekt som arbetsform Innehåll Olika slags projekt Projektmodeller Planeringsmodeller 1 En föränderlig värld Människor idag vill vara med och påverka sin situation Delaktighet i verksamheten Ökad konkurrens Osäkerhet på marknaden

Läs mer

Ramverk för projekt och uppdrag

Ramverk för projekt och uppdrag Peter Yngve IT-centrum 2011-02-10 1.0 1 (9) Ramverk för projekt och uppdrag Peter Yngve IT-centrum 2011-02-10 1.0 2 (9) BAKGRUND/MOTIV... 3 MÅL OCH SYFTE... 3 DEFINITIONER AV PROJEKT... 3 MODELL FÖR PROJEKTSTYRNING...

Läs mer

Metoder för Interaktionsdesign

Metoder för Interaktionsdesign Metoder för Interaktionsdesign Föreläsning 4 Projektmetodik och Scrum Kapitel 9-12 + 14, Scrumbok Det högra spåret Vi lämnar nu det vänstra spåret de mjukare delarna och går in på det högra spåret som

Läs mer

Anvisningar till rapporter i psykologi på B-nivå

Anvisningar till rapporter i psykologi på B-nivå Anvisningar till rapporter i psykologi på B-nivå En rapport i psykologi är det enklaste formatet för att rapportera en vetenskaplig undersökning inom psykologins forskningsfält. Något som kännetecknar

Läs mer

Agila Avtal. avtalsformer som kan fungera. Carina Meurlinger carina.meurlinger@agero.se

Agila Avtal. avtalsformer som kan fungera. Carina Meurlinger carina.meurlinger@agero.se Agila Avtal Hur man säljer in agila projekt olika avtalsformer som kan fungera Carina Meurlinger carina.meurlinger@agero.se Min syn på saken och kundens Detta är vad vi alla önskar Lite om mig själv Carina

Läs mer

Processbeskrivning Systemutveckling

Processbeskrivning Systemutveckling ProcIT-P-015 Processbeskrivning Systemutveckling Lednings- och kvalitetssystem Fastställd av Sven Arvidson 2011-09-12 Innehållsförteckning 1 Inledning 3 1.1 Symboler i processbeskrivningarna 3 2 Systemutvecklingsprocessen

Läs mer

Projekt- och kvalitetsstyrning på Frontec

Projekt- och kvalitetsstyrning på Frontec Projekt- och kvalitetsstyrning på Frontec Detta dokument beskriver hur Frontec bedriver utvecklingsprojekt med kvalitetssäkring FSAB_LS020_Projekt och kvalitetsstyrning A.doc Sida 1(6) Frontec kan projekt

Läs mer

PMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning

PMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning PMM (Process Maturity Metrics) PMM är en metod för att mäta processmognad i utvecklingsprojekt. I korthet går metoden ut på att man utvärderar sin utvecklingsprocess med avseende på ett antal framgångsfaktorer

Läs mer

Riktlinjer Projektmodell fo r Kungä lvs kommun

Riktlinjer Projektmodell fo r Kungä lvs kommun Riktlinjer Projektmodell fo r Kungä lvs kommun Riktlinjerna är antagna av förvaltningsledningen 2013-01-28 och gäller tillsvidare. (Dnr KS2012/1542) Ansvarig för dokumentet är chefen för enheten Utveckling,

Läs mer

BESKRIVNING AV PROCESSMETODEN SCRUM

BESKRIVNING AV PROCESSMETODEN SCRUM NORDSCRUM BESKRIVNING AV PROCESSMETODEN SCRUM NORDSCRUM BESKRIVNING AV PROCESSMETODEN SCRUM INNEHÅLLSFÖRTECKNING inledning... 3 SCRUM... 3 Bakgrund... 3 Faser... 3 Ramverket... 3 Nordscrum... 4 StudentProjekt...

Läs mer

Projektstyrning - kortversionen. 2013-09-04 Jan-Åke Olofsson

Projektstyrning - kortversionen. 2013-09-04 Jan-Åke Olofsson Projektstyrning - kortversionen 2013-09-04 Jan-Åke Olofsson Projektstyrning är en hjälp att nå dit du vill Om det inte spelar någon roll vart du kommer, ja då kan du klara dig utan projektstyrning eller

Läs mer

Utbildningsplan. IT, projektledning och affärssystem

Utbildningsplan. IT, projektledning och affärssystem Dnr HS 2013/118 Fakulteten för humaniora och samhällsvetenskap Utbildningsplan IT, projektledning och affärssystem Programkod: Beslut om fastställande: SGIPA Föreliggande utbildningsplan är fastställd

Läs mer

Innehåll (3) Innehåll (2) Innehåll (5) Innehåll (4) Innehåll (6) Innehåll (7) Dokumenthistorik. beställare, Översiktlig beskrivning av projektet

Innehåll (3) Innehåll (2) Innehåll (5) Innehåll (4) Innehåll (6) Innehåll (7) Dokumenthistorik. beställare, Översiktlig beskrivning av projektet Bilden hämtad från http://www.liu.se/cul-resurser/lips/kartor/fore.htm Projektplanering Om inte projektet planeras noga, kommer det garanterat att misslyckas Projektplanen Krav på en projektplan Beskriver

Läs mer

Människa- datorinteraktion, MDI, vt 2012, Anvisningar för projekt- /grupparbete

Människa- datorinteraktion, MDI, vt 2012, Anvisningar för projekt- /grupparbete Människa- datorinteraktion, MDI, vt 2012 Anvisningar för projekt- /grupparbete Kursens projektuppgift består av att genomföra ett projektarbete i grupper om 3-4 personer. Uppgiften ska sedan presenteras

Läs mer

Molntjänster -- vad är molnet?

Molntjänster -- vad är molnet? En e-bok från Visma Spcs Molntjänster -- vad är molnet? Vad du bör tänka på för att göra rätt val till ditt företag Molntjänster -- vad är molnet? En guide till att förstå molntjänster Innehåll Hänger

Läs mer

Fakulteten för ekonomi, kommunikation och IT. Utbildningsplan. Programmet för personal och arbetsliv SGPAR

Fakulteten för ekonomi, kommunikation och IT. Utbildningsplan. Programmet för personal och arbetsliv SGPAR Fakulteten för ekonomi, kommunikation och IT Utbildningsplan Programmet för personal och arbetsliv Programkod: Beslut om fastställande: Programmets benämning: SGPAR Utbildningsplanen är fastställd av fakultetsnämnden

Läs mer

Projektplan, Cykelgarage

Projektplan, Cykelgarage Projektplan, Cykelgarage Johan Anderholm, (dt08ja5@student.lth.se) Jon Andersen (dt08ja8@student.lth.se) Marcus Carlberg (dt08mc4@student.lth.se) Simon Ekvy (dt08se2@student.lth.se) Stefan Johansson (dt08sj7@student.lth.se)

Läs mer

Kursinformation. Metodik för programvaruutveckling. Utvecklingsprocessen för programvara. Innehåll. Processmodell. Exempel

Kursinformation. Metodik för programvaruutveckling. Utvecklingsprocessen för programvara. Innehåll. Processmodell. Exempel Kursinformation Metodik för programvaruutveckling Föreläsning 3 Latex ok för litteraturstudierapport (prata med mig bara) Nästa föreläsning är av Björn Regnell (jag är med också) Presentationer imorgon

Läs mer

PROJEKTSKOLA 1 STARTA ETT PROJEKT

PROJEKTSKOLA 1 STARTA ETT PROJEKT PROJEKTSKOLA I ett projekt har du möjlighet att pröva på det okända och spännande. Du får både lyckas och misslyckas. Det viktiga är att du av utvärdering och uppföljning lär dig av misstagen. Du kan då

Läs mer

Riktlinjer för bedömning av examensarbeten

Riktlinjer för bedömning av examensarbeten Fastställda av Styrelsen för utbildning 2010-09-10 Dnr: 4603/10-300 Senast reviderade 2012-08-17 Riktlinjer för bedömning av Sedan 1 juli 2007 ska enligt högskoleförordningen samtliga yrkesutbildningar

Läs mer

Spelplanen ändras. 1. Agila arbetssätt växer sig starkare. 2. Förenkling, transparens och flexibilitet blir ledstjärnor i förändringsarbeten.

Spelplanen ändras. 1. Agila arbetssätt växer sig starkare. 2. Förenkling, transparens och flexibilitet blir ledstjärnor i förändringsarbeten. Spelplanen ändras Allt fler är överens om att vi står inför en förändring i sättet att se på och arbeta i projekt och organisationer. Trender kommer och går men det finns några som kommer att bestå och

Läs mer

Projektkaos. Chaos-rapporten. 34% av projekten avslutades i tid och enligt budget... ... 66% misslyckades!

Projektkaos. Chaos-rapporten. 34% av projekten avslutades i tid och enligt budget... ... 66% misslyckades! Projektkaos. Chaos-rapporten 34% av projekten avslutades i tid och enligt budget...... 66% misslyckades! 1 Standish Group, 2003 (www.standishgroup.com) Praxis Hantera krav Använd komponentarkitekturer

Läs mer

Utvecklingen av ett tidregistrerings- och faktureringssystem

Utvecklingen av ett tidregistrerings- och faktureringssystem Datavetenskap Opponenter: Anders Heimer & Jonas Seffel Respondenter: Daniel Jansson & Mikael Jansson Utvecklingen av ett tidregistrerings- och faktureringssystem Oppositionsrapport, C-nivå 2006:10 1 Sammanfattat

Läs mer

KÖPA MARKNADSUNDERSÖKNING. En guide för dig som överväger att göra en marknadsundersökning

KÖPA MARKNADSUNDERSÖKNING. En guide för dig som överväger att göra en marknadsundersökning KÖPA MARKNADSUNDERSÖKNING En guide för dig som överväger att göra en marknadsundersökning INNEHÅLLSFÖRTECKNING INNEHÅLLSFÖRTECKNING... 2 INLEDNING... 3 BEHÖVER NI VERKLIGEN GENOMFÖRA EN UNDERSÖKNING...

Läs mer

Utvärdering några grundbegrepp

Utvärdering några grundbegrepp Utvärdering några grundbegrepp Fredrik Björk, Projektledning, Malmö högskola 2005-11-07 Inledning: varför skall man utvärdera? Varför skall man utvärdera en verksamhet? Svaret på den frågan är inte så

Läs mer

Guide för Innehållsleverantörer

Guide för Innehållsleverantörer Library of Labs Content Provider s Guide Guide för Innehållsleverantörer Inom LiLa ramverket är innehållsleverantörer ansvariga för att skapa experiment som "LiLa Learning Objects", att ladda upp dessa

Läs mer

Agile - det moderna synsättet på mjukvaruutveckling Ordet Agile kommer från engelskan och kan närmast översättas med flexibel, dynamisk och smidig. Med det menar vi dynamiska projekt som konstruktivt kan

Läs mer

fafner ledarskap- och organisationsutveckling Tingsryd 090930

fafner ledarskap- och organisationsutveckling Tingsryd 090930 fafner ledarskap- och organisationsutveckling Tingsryd 090930 PROJEKTARBETE Projekt handlar om hur tillfälliga organisationer hanteras så att RÄTT PROBLEM löses på RÄTT SÄTT vid RÄTT TIDPUNKT 1 Olika sorters

Läs mer

Exempel på verklig projektplan

Exempel på verklig projektplan Exempel på verklig projektplan Detta är ett exempel på en proffessionell projektplan hämtad ur verkliga livet. Den visas inte i sin fullständighet, det mesta är bortklippt, men strukturen och mycket av

Läs mer

Projektmodell. 1. Riktlinjer projektmodell 1 (6) 2010-03-12

Projektmodell. 1. Riktlinjer projektmodell 1 (6) 2010-03-12 12 1 (6) Projektmodell Projektmodell Projektmodell... 1 1. Riktlinjer projektmodell... 1 2. Projektförutsättningar... 2 2.1 Uppdragsgivaren... 2 2.2 Direktiv... 2 2.3 Förstudie... 2 2.4 Beslut... 2 2.5

Läs mer

Introduktion till projektledning

Introduktion till projektledning Introduktion till projektledning OL108A Fredrik Björk Hur hänger projektledning och SHE ihop? Projekt: förändringsfokus Många SHE- ini?a?v startas med projektstöd Som projektledare oba Ent. Egenskaper

Läs mer

Hur lyckas med förändring?

Hur lyckas med förändring? 1 Hur lyckas med förändring? Mattias Hermansson, förändringsledare 2 Agenda förändringsmättnad förändringsledning ledarskap och samarbete fokus 3 Vem är Mattias Hermansson? Förändringsledare Chef Föreläsare

Läs mer

Kurser och seminarier från AddQ Consulting

Kurser och seminarier från AddQ Consulting och seminarier från AddQ Consulting Vår vision är att genom fokus på kvalitet och effektivitet inom IT bidra till att underlätta människors vardag. Kompetensutveckling är nyckeln till framgång för dig

Läs mer

Projektplan, milstolpar och organisation

Projektplan, milstolpar och organisation Projektplan, milstolpar och organisation Syftet med planering Att hantera osäkerhet ju mindre osäkerhet man kan acceptera i ett projekt, desto mer detaljplanering behövs; man måste dock vara vaksam så

Läs mer

Fakulteten för ekonomi, kommunikation och IT. Utbildningsplan SGITD. IT-Designprogrammet. Study programme in IT-Design

Fakulteten för ekonomi, kommunikation och IT. Utbildningsplan SGITD. IT-Designprogrammet. Study programme in IT-Design Fakulteten för ekonomi, kommunikation och IT Utbildningsplan IT-Designprogrammet Programkod: Programmets benämning: Inriktningar: SGITD IT-Designprogrammet Study programme in IT-Design Affärssystem och

Läs mer

Exempel på gymnasiearbete inom humanistiska programmet språk

Exempel på gymnasiearbete inom humanistiska programmet språk Exempel på gymnasiearbete september 2012 Exempel på gymnasiearbete inom humanistiska programmet språk Ungdomsspråk i spanska bloggar Elevens idé Calle är genuint språkintresserad. Han har studerat spanska,

Läs mer

Projektplan för utvecklingen av Kryssarklubbens nya webbplats

Projektplan för utvecklingen av Kryssarklubbens nya webbplats Projektplan för utvecklingen av Kryssarklubbens nya webbplats Sammanfattning Detta dokument beskriver hur Kryssarklubbens nya webbplats skall tas fram. Planen är ett resultat av det arbete som gjorts av

Läs mer

UTBILDNINGSPLAN Magisterprogram i pedagogiskt arbete 60 högskolepoäng. Master Program in Educational Work 60 credits 1

UTBILDNINGSPLAN Magisterprogram i pedagogiskt arbete 60 högskolepoäng. Master Program in Educational Work 60 credits 1 UTBILDNINGSPLAN Magisterprogram i pedagogiskt arbete 60 högskolepoäng Master Program in Educational Work 60 credits 1 Fastställd i Områdesnämnden 2015-XX-XX Gäller fr.o.m. HT 2015 1. PROGRAMMETS MÅL 1.1.

Läs mer

LUNDS UNIVERSITET. Projektledning

LUNDS UNIVERSITET. Projektledning Projektledning 1 Vad är ett projekt?? 2 Vad är ett projekt? PMIs definition är: Ett projekt är en temporär satsning i syfte att skapa en unik produkt, tjänst eller resultat. Kännetecken Temporär Unik Successivt

Läs mer

Datorsalar Niagara och Orkanen

Datorsalar Niagara och Orkanen [DNR] 1 (av 8) Styr- och handledningsdokument Dokumenttyp: Beslutsdatum: Beslutande: Giltighetstid: Dokumentansvarig: Diarienummer: Projektplan Projekt datorsalar [DNR] Datorsalar Niagara och Orkanen Revisionsinformation

Läs mer

SYSTEMUTVECKLING METODER & MODELLER. Suzana Ramadani

SYSTEMUTVECKLING METODER & MODELLER. Suzana Ramadani SYSTEMUTVECKLING METODER & MODELLER 1 Processlinjen Produktlinjen Livscykelmodellen systemutveckling systemering Analys Design Realisering Implementering Förändringsanalys Verksamhetsanalys Förvaltning

Läs mer

Projektledarutbildning 6 dagar

Projektledarutbildning 6 dagar Projektledarutbildning 6 dagar Nercia Utbildning AB I Sverige finns ca 1600 utbildningsföretag med olika utbud av program och kurser, de flesta med ett redan färdigt upplägg som sedan anpassas efter kunden.

Läs mer

PROJEKTLEDNING. Vad är ett PROJEKT? Ett projekt:

PROJEKTLEDNING. Vad är ett PROJEKT? Ett projekt: PROJEKTLEDNING Page: 1 Vad är ett PROJEKT? Ett projekt: är unikt ej återkommande har definierad budget är tidsbegränsat har väldefinierade mål har en temporär organisation Page: 2 Page 1 Projektets omgivning

Läs mer

Varje rätt svar ger 0.5 poäng. (max 3p)

Varje rätt svar ger 0.5 poäng. (max 3p) Fråga 1) Följande fråga beaktar skillnaden mellan marknadsdriven och kontraktsdriven produktutveckling. Para ihop varje scenario med det alternativ som passar bäst. A Kontraktsdriven produktutveckling

Läs mer

Att välja verktyg för portföljhantering. - Vad vet en leverantör om det?

Att välja verktyg för portföljhantering. - Vad vet en leverantör om det? Att välja verktyg för portföljhantering - Vad vet en leverantör om det? Agenda Problem som ska lösas med verktyg Olika typer av verktyg Att utvärdera och välja verktyg Egenutvecklat eller standard Förankring

Läs mer

Interaktionsdesign som profession. Föreläsning Del 2

Interaktionsdesign som profession. Föreläsning Del 2 Interaktionsdesign som profession Föreläsning Del 2 Vikten av att göra research Varför behöver vi göra research? En produkt blir aldrig bättre än den data som denna baseras på Men Vi har redan gjort en

Läs mer

Användningscentrering i agila utvecklingsprojekt. johanna.sarna@valtech.com Valtech

Användningscentrering i agila utvecklingsprojekt. johanna.sarna@valtech.com Valtech Användningscentrering i agila utvecklingsprojekt johanna.sarna@valtech.com Valtech Vem är jag? Johanna Särnå Jobbar på Valtech sedan 3 år tillbaka Jobbar där med användbarhet och projektledning Certifierad

Läs mer

Från idé till projektplan

Från idé till projektplan Från idé till projektplan Detta är ett bakgrundsmaterial som hjälper dig koka ner din idé till en projektplan. Detta tar inte hänsyn till projektplanens formalia dvs hur den rent konkret är strukturerad.

Läs mer

Utbildningsplan Benämning Benämning på engelska Poäng Programkod Gäller från Fastställd Programansvar Beslut Utbildningens nivå Inriktningar

Utbildningsplan Benämning Benämning på engelska Poäng Programkod Gäller från Fastställd Programansvar Beslut Utbildningens nivå Inriktningar Utbildningsplan 1 (6) Benämning Magisterprogrammet i politik och krig Benämning på engelska Masters Programme in Politics and War Poäng: 60 hp Programkod: 2PK15 Gäller från: Höstterminen 2015 Fastställd:

Läs mer

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur Objekt-orienterad utveckling Saker man vill uppnå: Objektorienterad analys och design Sven-Olof Nyström Uppsala Universitet 16 mars 2005 en systematisk metod för att gå från problembeskrivning till färdigt

Läs mer

En snabbare väg till framgång Ett agilt angreppssätt för BI Johan Petersson

En snabbare väg till framgång Ett agilt angreppssätt för BI Johan Petersson En snabbare väg till framgång Ett agilt angreppssätt för BI Johan Petersson Acando Johan Petersson Visit me at LinkedIn: se.linkedin.com/in/johpet 2 Acando 2014-29-08 Acando - översikt Enterprise Consulting

Läs mer

Betygskriterier för Examensarbete, 15hp Franska C1/C3, Italienska C, Spanska C/C3

Betygskriterier för Examensarbete, 15hp Franska C1/C3, Italienska C, Spanska C/C3 Uppsala universitet Institutionen för moderna språk VT11 Betygskriterier för Examensarbete, 15hp Franska C1/C3, Italienska C, Spanska C/C3 För betyget G skall samtliga betygskriterier för G uppfyllas.

Läs mer

Kurs 1. Informationsförmedlingens vetenskapliga och sociala sammanhang, 30.0 hp

Kurs 1. Informationsförmedlingens vetenskapliga och sociala sammanhang, 30.0 hp Kurs 1. Informationsförmedlingens vetenskapliga och sociala sammanhang, 30.0 hp (Gäller ht-14) För godkänt kursbetyg ska den studerande avseende kunskap och förståelse känna till och redogöra för: - grundlinjen

Läs mer

Implementering - teori och tillämpning inom hälso- och sjukvård

Implementering - teori och tillämpning inom hälso- och sjukvård Implementering - teori och tillämpning inom hälso- och sjukvård Siw Carlfjord Leg sjukgymnast, Med dr IMH, Linköpings universitet There are not two sciences There is only one science and the application

Läs mer

Slutrapport. Innovativt utbildnings- och forskningsmaterial användning av 3D visualisering och animering för att bemöta pedagogiska utmaningar

Slutrapport. Innovativt utbildnings- och forskningsmaterial användning av 3D visualisering och animering för att bemöta pedagogiska utmaningar Innehåll Slutrapport Innovativt utbildnings- och forskningsmaterial användning av 3D visualisering och animering för att bemöta pedagogiska utmaningar Emin Halilovic, projektledare 1 Basfakta... 3 1.1

Läs mer

Att skriva en vetenskaplig rapport

Att skriva en vetenskaplig rapport Att skriva en vetenskaplig rapport Eventuell underrubrik Förnamn Efternamn Klass Skola Kurs/ämnen Termin Handledare Abstract/Sammanfattning Du skall skriva en kort sammanfattning som är en koncentrerad

Läs mer

Att fatta rätt beslut vid komplexa tekniska upphandlingar

Att fatta rätt beslut vid komplexa tekniska upphandlingar Att fatta rätt beslut vid komplexa tekniska upphandlingar Upphandlingsdagarna 2015 Stockholm 29 januari 2015 1 Inledning Den här presentation kommer att undersöka de vanligaste fallgroparna vid komplex

Läs mer

QC i en organisation SAST 2008-09-16

QC i en organisation SAST 2008-09-16 QC i en organisation SAST 2008-09-16 1 Agenda Hur är vi organiserade inom test på SEB? Hur är QC uppsatt på SEB? Hur arbetar vi med QC i en stor organisation? Uppfyllde QC våra förväntningar och hur har

Läs mer

IT-projektledning - introduktion 725G62

IT-projektledning - introduktion 725G62 IEI Tommy Wedlund Läsanvisningar, IT-projektledning introduktion, 725G62 IT-projektledning - introduktion 725G62 Läsanvisningar tentamen inför tentamen I tentamen ingår följande kurslitteratur: The IBM

Läs mer

Collaborative Product Development:

Collaborative Product Development: Collaborative Product Development: a Purchasing Strategy for Small Industrialized House-building Companies Opponent: Erik Sandberg, LiU Institutionen för ekonomisk och industriell utveckling Vad är egentligen

Läs mer

Om organisationen. Vad är en multiprojektorganisation. Projektportföljen. Projektet i organisationen multprojektorganisering - kommunikation

Om organisationen. Vad är en multiprojektorganisation. Projektportföljen. Projektet i organisationen multprojektorganisering - kommunikation Projektet i organisationen multprojektorganisering - kommunikation anneli linde Om organisationen Vad är en multiprojektorganisation Hur fungerar en sådan organisation Vilka är de typiska utmaningarna

Läs mer

Projektspecifikation

Projektspecifikation Handläggare Vårt diarienummer Datum Sidan 1(9) 2011-03-02 Projektspecifikation Projekt: Läkemedel projektnummer 2265 Beställare: Äldreomsorgsförvaltningen Skriven av: Eva Almén-Åström Datum: 100209 Godkänd

Läs mer

INITIATIVKRAFT LEDER TILL FRAMGÅNGSRIKA PROJEKT. Webinar 2012-05-10

INITIATIVKRAFT LEDER TILL FRAMGÅNGSRIKA PROJEKT. Webinar 2012-05-10 INITIATIVKRAFT LEDER TILL FRAMGÅNGSRIKA PROJEKT Webinar 2012-05-10 PROJECTPLACE ÄR EN SAMARBETSTJÄNST ONLINE PROJECTPLACE Social collaboration tool 750 000 användare 150 länder 7 språk PROJECTPLACE Social

Läs mer

Anvisningar för presentation och opponering. En liten guide för presentation och opponering av kandidat- och magisteruppsatser

Anvisningar för presentation och opponering. En liten guide för presentation och opponering av kandidat- och magisteruppsatser Anvisningar för presentation och opponering En liten guide för presentation och opponering av kandidat- och magisteruppsatser Idén med uppsatsskrivande Att öva sig i det vetenskapliga hantverket; dvs.

Läs mer

Förberedelse PM för examensarbete i Industriell ekonomi och Maskinteknik

Förberedelse PM för examensarbete i Industriell ekonomi och Maskinteknik Förberedelse PM för examensarbete i Industriell ekonomi och Maskinteknik Introduktion Examensarbetet är ingenjörsutbildningarnas avslutande kurs (härefter kallad exjobbs-kursen) där du skall tillämpa kunskaper

Läs mer

Tentamen TEIO04 Projektledning 2010-03-09

Tentamen TEIO04 Projektledning 2010-03-09 Tentamen TEIO04 Projektledning 2010-03-09 RÄTTNINGSMALL Sidhänvisningar till Tonnquist: Projektledning, 3e upplagan A Faktafrågor I denna del finns totalt 8 huvudfrågor som maximalt ger 4 poäng per fråga.

Läs mer

Utbildningsplan för masterprogrammet i hälsoinformatik 4HI10

Utbildningsplan för masterprogrammet i hälsoinformatik 4HI10 Utbildningsplan för masterprogrammet i 4HI10 Inrättad av Styrelsen för utbildning 2009-11-06 Fastställd av Styrelsen för utbildning 2009-11-24 Sid 2 (7) 1. Basdata 1.1. Programkod 4HI10 1.2. Programmets

Läs mer

Examensarbeten hösten 2014

Examensarbeten hösten 2014 Examensarbeten hösten 2014 2/8 Förslag till examensarbeten på SPV Hos oss kan du ansöka om att skriva uppsats inom flera olika ämnesområden. För oss är uppsatsen ett bra sätt att få delar av vår verksamhet

Läs mer

Aktiviteter vid avtalets upphörande

Aktiviteter vid avtalets upphörande SID 1 (10) Bilaga 4h Aktiviteter vid avtalets upphörande Förfrågningsunderlag Upphandling av ett helhetsåtagande avseende IT-stöd för pedagogiskt genomförande inom Skolplattform Stockholm Box 22049, 104

Läs mer

REVEAL Course PM2 Level 2 Intermediate Topic: Project Management

REVEAL Course PM2 Level 2 Intermediate Topic: Project Management REVEAL Course PM2 Level 2 Intermediate Topic: Project Management Kurs Projektledning 2 Nivå 2 Mellan Projektledning Module 1: Projekt planen DU 1.1 Projekt planen Strukturen i en projektplan DU 1.2 Work

Läs mer

Perspektiv på kunskap

Perspektiv på kunskap Perspektiv på kunskap Alt. 1. Kunskap är något objektivt, som kan fastställas oberoende av den som söker. Alt. 2. Kunskap är relativ och subjektiv. Vad som betraktas som kunskap är beroende av sammanhanget

Läs mer

Tillgängliga resurser. Definitionen av en sund budget. DU 2.1 Riskhantering och beredskapsplaner Definitionen av risk i projektledning.

Tillgängliga resurser. Definitionen av en sund budget. DU 2.1 Riskhantering och beredskapsplaner Definitionen av risk i projektledning. REVEAL Course PM3 Level 2 Advanced Topic: Project Management Reveal kurs projektledning Nivå Avancerad Ämne: Projektledning Modul 1: Projektets budget: resurser och definitionen av en sund budget DU 1.1

Läs mer

Projektprocessen. Projektprocess

Projektprocessen. Projektprocess Dnr Mahr 19-2014/563 1 (av 6) Projektprocess Datum: Version: Dokumentansvarig: 150116 1.0 Jenny Wendle Stöddokument för det grafiska dokumentet Projektprocessen grafisk 1.0 Projektprocessen Projektprocessen

Läs mer

Pro jacere Projektil Projektor Projicera 2. Projektattribut Ett projekt

Pro jacere Projektil Projektor Projicera 2. Projektattribut Ett projekt Projektledning 1 1.2 Projicere Projekt Pro jacere Projektil Projektor Projicera 2 Definition av projekt PMBOK Ett projekt är en temporär satsning i syfte att skapa en unik produkt, tjänst eller resultat.

Läs mer

Effek%va(App+projekt(

Effek%va(App+projekt( APP+A+THONE 5mars2014 ProjektledningochLeveransprocessför Effek%vaApp+projekt ProjektM+handelHögskolanVäst MatsAhlberg,Connecta 89%avvärldensprojektlyckasintenåsinamål Standish Group International, 2013

Läs mer

Testning som beslutsstöd

Testning som beslutsstöd Testning som beslutsstöd Vilken typ av information kan testning ge? Vilken typ av testning kan ge rätt information i rätt tid? Hur kan testning hjälpa din organisation med beslutsstöd? Hur kan produktiviteten

Läs mer

Time Cares tjänsteerbjudande

Time Cares tjänsteerbjudande Time Cares tjänsteerbjudande Time Cares tjänsteerbjudande Time Care tjänsteerbjudande Hur utbildar och stöttar vi våra chefer att leda verksamheter där varje krona har en berättelse och varje minut ett

Läs mer

Projektarbete med IT-verktyg - modulanpassat

Projektarbete med IT-verktyg - modulanpassat Projektarbete är att arbeta på ett strukturerat sätt. Genom att kombinera projektmetodik, kunskap om och hur ett projekt fungerar, och ett planeringsverktyg, IT-stöd, kan Du få ett strukturerat och effektivt

Läs mer

729G27. Pilot, skrivande och avslutning. Johan Blomkvist IDA-HCS-IxS Twitter: @hellibop

729G27. Pilot, skrivande och avslutning. Johan Blomkvist IDA-HCS-IxS Twitter: @hellibop 729G27 Pilot, skrivande och avslutning Johan Blomkvist IDA-HCS-IxS Twitter: @hellibop Dagens Skrivande Piloten Rester från förra gången validering Någon slags sammanfattning 2 Jag är på semester till 16

Läs mer

Webbsystems inverkan på innehåll och användbarhet på webbplatser - oppositionsrapport

Webbsystems inverkan på innehåll och användbarhet på webbplatser - oppositionsrapport Webbsystems inverkan på innehåll och användbarhet på webbplatser - oppositionsrapport Respondenter: Emma Henriksson och Ola Ekelund Opponenter: Eva Pettersson och Johan Westerdahl Sammanfattande omdöme

Läs mer

Projektplan. LiTH Reglering av Avgaser, Trottel och Turbo 2008-02-11. Fredrik Petersson Version 1.0. Status. Reglerteknisk Projektkurs RATT LIPs

Projektplan. LiTH Reglering av Avgaser, Trottel och Turbo 2008-02-11. Fredrik Petersson Version 1.0. Status. Reglerteknisk Projektkurs RATT LIPs Fredrik Petersson Version 1.0 Status Granskad 2008-02-11 NL, PA Godkänd 1 2 PROJEKTIDENTITET VT 2008, RATT-Gruppen Linköpings tekniska högskola, ISY- Fordonssystem Namn Ansvar Telefon E-post Daniel Ahlberg

Läs mer

Skriv! Hur du enkelt skriver din uppsats

Skriv! Hur du enkelt skriver din uppsats Skriv! Hur du enkelt skriver din uppsats Josefine Möller och Meta Bergman 2014 Nu på gymnasiet ställs högra krav på dig när du ska skriva en rapport eller uppsats. För att du bättre ska vara förberedd

Läs mer

Att skapa projektgruppen

Att skapa projektgruppen Dag 4 Att skapa projektgruppen och Kunskapshantering Att skapa projektgruppen s 75-102 i boken Förstudie Planering Genomförande Avslut Initiering av projekt Alla individer har sina egna mål Om alla individer

Läs mer

Projekt intranät Office 365 av Per Ekstedt

Projekt intranät Office 365 av Per Ekstedt Projekt intranät Office 365 av Per Ekstedt 1 BESKRIVNING AV UTFÖRANDE Uppdraget planeras att genomföras med ett agilt arbetssätt samt best practice från Microsoft gällande SharePoint online. Uppdraget

Läs mer

REVISIONSRAPPORT. Landstinget Halland. Granskning av projektredovisning. styrning och uppföljning 2004-05-18. Leif Johansson

REVISIONSRAPPORT. Landstinget Halland. Granskning av projektredovisning. styrning och uppföljning 2004-05-18. Leif Johansson REVISIONSRAPPORT Granskning av projektredovisning styrning och uppföljning Landstinget Halland 2004-05-18 Leif Johansson INNEHÅLLSFÖRTECKNING INNEHÅLLSFÖRTECKNING...1 1. Uppdrag...2 2. Syfte och metod...2

Läs mer

Processbeskrivning Test

Processbeskrivning Test ProcIT-P-017 Processbeskrivning Test Lednings- och kvalitetssystem Fastställt av Sven Arvidson 2012-06-20 Innehållsförteckning 1 Inledning 3 1.1 Symboler i processbeskrivningarna 3 2 Testprocessen 4 2.1

Läs mer

Gymnasiearbetets titel (huvudrubrik)

Gymnasiearbetets titel (huvudrubrik) Risbergska skolan Program Gymnasiearbetets titel (huvudrubrik) Underrubrik Titeln på rapporten måste givetvis motsvara innehållet. En kort överrubrik kan förtydligas med en underrubrik. Knut Knutsson BetvetA10

Läs mer

Allmän studieplan för utbildning på forskarnivå i Fastighetsvetenskap TEVFTF00

Allmän studieplan för utbildning på forskarnivå i Fastighetsvetenskap TEVFTF00 1 Allmän studieplan för utbildning på forskarnivå i Fastighetsvetenskap TEVFTF00 Studieplanen är fastställd av Fakultetsstyrelsen för Lunds Tekniska Högskola, LTH, 2007-09-24 och senast ändrad 2014-03-10

Läs mer

Projektmetodik II. HF1005, Informationsteknik och ingenjörsmetodik för Datateknik. Projektarbete

Projektmetodik II. HF1005, Informationsteknik och ingenjörsmetodik för Datateknik. Projektarbete Projektmetodik II HF1005, Informationsteknik och ingenjörsmetodik för Datateknik Projektarbete Förväntade resultatet är t.ex. en produkt Vi behöver arbeta med Analys Faktainsamling Genomförande Rapportering

Läs mer

Professionell masterutbildning i programvaruteknik

Professionell masterutbildning i programvaruteknik Professionell masterutbildning i programvaruteknik Mälardalens högskola Blekinge Tekniska Högskola Chalmers Tekniska Högskola & Göteborgs Universitet Swedish Institute of Computer Science Swedsoft i samarbete

Läs mer

NYFIKEN PÅ PROJEKTLEDNING MÄSSA 2008

NYFIKEN PÅ PROJEKTLEDNING MÄSSA 2008 Sid: 1 (5) NYFIKEN PÅ PROJEKTLEDNING MÄSSA 2008 En spännande mässa där utställarna är särskilt utvalda av våra studenter. Ni som besökare är också speciella, ni är uppdragsgivare, kunder, föreläsare,ledningsgrupp

Läs mer

ALLMÄN STUDIEPLAN FÖR UTBILDNING PÅ FORSKARNIVÅ I TEKNISK PSYKOLOGI. TFN-ordförande 2007-09-10

ALLMÄN STUDIEPLAN FÖR UTBILDNING PÅ FORSKARNIVÅ I TEKNISK PSYKOLOGI. TFN-ordförande 2007-09-10 ALLMÄN STUDIEPLAN FÖR UTBILDNING PÅ FORSKARNIVÅ I TEKNISK PSYKOLOGI TFN-ordförande 2007-09-10 1 Ämnesområde Ämnet teknisk psykologi omfattar utvecklingen av effektiva produktsystem och produkter med hänsyn

Läs mer

Förändringsstrategi anpassad till just din organisations förutsättningar och förmåga

Förändringsstrategi anpassad till just din organisations förutsättningar och förmåga Förändringsstrategi anpassad till just din organisations förutsättningar och förmåga Att bedriva effektiv framgångsrik förändring har varit i fokus under lång tid. Förändringstrycket är idag högre än någonsin

Läs mer

Projektarbete. Johan Eliasson

Projektarbete. Johan Eliasson Projektarbete Johan Eliasson Projekt Definition: En grupp av projektdeltagare utför under ledning av en projektledare en klart definierad uppgift, på en viss tid, med begränsade resurser Resurserna kan

Läs mer

Unit testing methodology

Unit testing methodology Department of Computer Science Per Hurtig Stefan Lindberg & Fredrik Strandberg Unit testing methodology Opposition Report, C/D-level 2005:xx 1 Övergripande utvärdering Helhetsintrycket av uppsatsen är

Läs mer

Umeå Universitet Kursplan Dnr: 515-2098-96 Institutionen för Tillämpad fysik och elektronik

Umeå Universitet Kursplan Dnr: 515-2098-96 Institutionen för Tillämpad fysik och elektronik Umeå Universitet Kursplan Dnr: 515-2098-96 Institutionen för Tillämpad fysik och elektronik PROJEKTLEDARUTBILDNING I, 10 poäng Project Management Kurskod: Ansvarig institution: Ämne: Nivå: Utbildningsområde:

Läs mer