Avgränsa och integrera

4.2.1 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

26

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.

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.

4.2.2 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

Självgående dammsugare

1. Damsugarenhet 2. Drivanordning 3. Dockningsstation 1.1 Kropp 1.2 Avfallspåse 2.1 Motor 2.1 Mikrochip 3.1 Nätanslutning 3.2 Mikrochip

27

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 tid- och 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

4.3.1 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.

28

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

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

Projektet

A B C

D E F G H I

29

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. START A (6v) B (2v) C (2v) SLUT D (4v) E (5v) F (1v) M2 M1 1

30

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

31

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

32

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

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.

WBS och/eller PBS Nätplan med aktiviteter, milstolpar och kritisk linje Aktivitetslista, Tidsplan - Gantt-schema Resursgraf och/eller resurshistogram

33

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å

34

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

4.4.1 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

In document Projektplaneringsverktyg och mjukvaruprojekt (Page 33-44)