Orsaker till att små IT-projekt kan misslyckas

(1)

Grigori Safarjan

Orsaker till att små IT-projekt kan misslyckas

En intervjustudie kring fyra misslyckade små IT- projekt

Reasons why small IT projects can fail

An interview study about four small IT projects that failed

Informatik Kandidatuppsats

Termin: HT-2020

Handledare: Katarina Groth Jansson

(2)

Abstract

IT-projekt bedrivs åt organisationer som har beställt det och förväntar sig ett lyckat utfall. Men det händer att IT-projekt misslyckas. Vad som orsakar att ett IT-projekt misslyckas beror på projektets karaktär. Majoriteten av de projekt som klassats misslyckat berör stora IT-projekt.

Studier genomförs kring misslyckade stora IT-projekt eftersom stora misslyckade IT-projekt slutar oftast med en kostsam nota. Däremot finns inte många studier rörande små IT-projekt.

Syftet med uppsatsen är att undersöka fyra små misslyckade IT-projekt för att komma fram till vad som har orsakat att respektive IT-projekt fått ett misslyckat utfall. I denna uppsats har tre undersökningsfrågor besvarats: U1 Vilken eller vilka orsaker bidrog till att var och en av de fyra små IT-projekten misslyckats? U2: Finns det gemensamma orsaker mellan de fyra små IT-projekten som har misslyckats? U3: Hur kunde respektive IT-projekt fått ett mer lyckat utfall?

Datainsamling genomfördes med hjälp av intervjuer där författaren har intervjuat fyra respondenter.

Följande faktorer kan ha orsakat att de fyra små IT-projekten fick ett misslyckat utfall. Brister i projektgrupp, användarmedverkan, projektplan, krav och projektledare har haft påverkan på de fyra IT-projekten. Projekt B har orsakats av projektplan, projektledare, krav, projektgrupp samt användarmedverkan. Projekt A har orsakats av faktorn projektplan. Projekt C har misslyckats på grund av krav. Projekt D har misslyckats på grund av projektplan. Det framkommer att faktorn krav är en gemensam orsak som går att identifiera både i stora och små IT-projekt.

Nyckelord: IT-projekt, misslyckat små IT-projekt, projektledare, krav, projektgrupp, projektplan, ledningsgrupp, användarmedverkan.

(3)

Innehållsförteckning

Inledning ... 1

1.1 Problemområde ... 1

1.2 Syfte ... 2

1.3 Undersökningsfrågor ... 2

1.4 Målgrupp ... 2

1.5 Metod ... 2

Kvalitativ ansats ... 2

Datainsamling ... 2

Deduktivt arbetssätt ... 3

Undersökningens struktur ... 3

1.6 Etiska överväganden & GDPR ... 5

Forskningens fyra huvudkrav ... 5

GDPR ... 5

Litteraturöversikt ... 6

2.1 Källkritik ... 6

2.2 Vad är IT-projekt? ... 6

2.3 Projektlivscykeln... 7

Förstudiefasen ... 7

Planeringsfas ... 9

Genomförandefas ... 11

Avslut ... 12

2.4 Små IT-projekt ... 12

2.5 Projektframgång ... 12

2.6 Tidigare studier om misslyckade (små) projekt ... 13

IT Project Success Factors: An Experience Report ... 13

What factors lead to software failure? ... 14

Implementing small & medium IT projects in small & medium enterprises ... 15

Critical Failure Factors (CFFs) of IT Projects ... 15

2.7 Sammanfattning av litteraturgenomgång ... 15

Empiri ... 20

3.1 Formulering av intervjuguide ... 20

3.2 Presentation av respondenter ... 20

(4)

3.3 4 små IT-projekt ... 21

3.4 Projekt A – Migrering ... 22

Förstudiefas – Projektledare ... 22

Förstudie fas – krav ... 23

Planeringsfas – Projektgrupp ... 23

Planeringsfas – projektplan ... 24

Genomförandefas – Ledningsgrupp ... 25

Genomförandefas – Användarmedverkan ... 26

Avslut ... 26

3.5 Projekt B – Ledningssystem ... 27

Förstudiefas – Krav ... 28

Planeringsfas – projektplan ... 29

Genomförandefas – Användarmedverkan ... 29

Avslut ... 30

3.6 Projekt C – Live tv system ... 30

Förstudiefas – krav ... 31

Planeringsfas – Projektplan ... 33

Genomförandefas - Användarmedverkan ... 34

Avslut ... 34

3.7 Projekt D – Prototyp för krissövning ... 35

Förstudiefas – Krav ... 36

Planeringsfas – Projektplan... 38

Genomförandefas - Ledningsgrupp ... 38

Genomförandefas - Användarmedverkan ... 39

Avslut ... 40

Analys ... 41

4.1 Förstudiefas - Projektledare ... 41

4.2 Förstudiefas - Krav ... 42

(5)

4.3 Planeringsfas – projektgrupp... 43

4.4 Planeringsfas – Projektplan ... 44

4.5 Genomförandefas - Ledningsgrupp ... 47

4.6 Genomförandefas - Användarmedverkan ... 48

4.7 Avslut ... 49

Slutsatsdiskussion ... 51

5.1 Förstudiefas - Projektledare ... 51

5.2 Förstudiefas - Krav ... 52

5.3 Planeringsfas – Projektgrupp... 53

5.4 Planeringsfas – Projektplan ... 54

5.5 Genomförandefas - Ledningsgrupp ... 56

5.6 Genomförandefas - Användarmedverkan ... 57

5.7 Avslut ... 58

5.8 Sammanställning av kapitlet ... 58

Slutsatser ... 60

Omnämnande ... 65

Bilagor ... 69

Tabellförteckning

Tabell 1 Bearbetad och analyserat data ... 4

Tabell 2 Sammanfattning av projektlivscykeln ... 18

Tabell 3 Sammanställning av identifierade faktorer som kan ha påverkat att små IT-projekt har misslyckats 19 Tabell 4 Presentation av respondenter... 21

Tabell 5 Sammanställning av faktorer som kan ha orsakat projekt misslyckanden ... 59

(6)

1

Inledning

Kapitlet inledes med en beskrivning av problemområdet, därefter förklaras studiens syfte, vad som ska undersökas, studiens målgrupp och sen förklaras studiens metod och kapitlet avslutas med en beskrivning om forskningsetik och GDPR.

1.1 Problemområde

Informationsteknologi (IT) utvecklas ständigt och nya IT-system utvecklas konstant. Ett IT - projekt skapas för att utveckla ett nytt IT-system åt organisationen som har beställt produkten och när målet är uppnått skall projektet eliminera sin egen existens (Görling 2009, s.42;

Wiktorin 2018, s.215). Ett IT-projekt är en produkt som ska användas av personerna i en organisation, exempelvis på en sådan produkt är dokumenthanteringssystem eller ett intranät (Nyström & Tentak 2009, s.6). Organisation som beställer ett IT-projekt förväntar sig ett lyckat IT-system. Emellertid förekommer det att IT-projekt inte blir lyckad och det är inte ovanligt.

IT-projekt kan bli en känslig och komplicerad process där det finns många faktorer som kan orsaka att IT-projekt blir en misslyckad och kostsam historia (Nyström & Tentak 2009, s.6).

När det talas om misslyckat IT-projekt rör det sig om stora och komplexa projekt. Stora IT- projekt som misslyckas slutar med en dyr nota, och just därför diskussioner och undersökningar kring stora IT-projekt är väldigt förekommande (The Standish Group 2015). Varje år läggs ner flera miljontals kronor på misslyckade IT-projekt som slutar med att pengarna kastas i sjön (Danielsson 2017a). Ett exempel på en sådan misslyckad IT-projekt är Försvarsmaktens SAP projekt som gick ut på att implementera SAP:s affärssystem i verksamheten. Det tog åtta år att genomföra projektet och kostade 3,3 miljarder kronor, vilket överskred den ursprungliga budgeten som låg på 2 miljarder kronor (Selander 2016).

Diskussioner kring små IT-projekt inträffar sällan. Det är stora IT-projekt som undersöks för att hitta bakomliggande orsaker till misslyckandet. I The Stadish Group rapport (2015) framgår det att endast 4 % av de undersökta små IT-projekten ansågs som misslyckat, medan stora IT- projekt tar hem vinsten med 38 % misslyckanden. I undersökningsrapporten framgår det att stora IT-projekt misslyckas mer än vanligt medan små IT-projekt inte fallerar ofta (The Standish Group 2015).

Det finns många studier som har lyft upp faktorer som har orsakat stora IT-projektens fall (Danielsson 2017a; Santos 2014). Men som det nämndes tidigare finns inte det många studier som har genomförts kring små IT-projekt. Därför är det intressant att genomföra en närmare undersökning kring små IT-projekt för att lyfta fram orsaker som har även påverkat små IT- projektets utfall.

(7)

2 1.2 Syfte

Syftet med uppsatsen är att undersöka fyra små misslyckade IT-projekt för att komma fram till vad som har orsakat att respektive IT-projekt fått ett misslyckat utfall.

1.3 Undersökningsfrågor

I denna rapport kommer tre frågor besvaras. U1 ställs för att få en förståelse vad som har orsakat att respektive projekt fått ett misslyckat resultat. U2 handlar om att undersöka om samma orsak eller orsaker har påverkat mer än ett IT-projekt. U3 ställs för att veta vad som kan göras annorlunda till nästa gång när ett litet IT-projekt bedrivs.

Undersökningsfrågor som besvaras i denna rapport är:

• U1: Vilken eller vilka orsaker bidrog till att var och en av de fyra små IT-projekten misslyckades?

• U2: Finns det gemensamma orsaker mellan de fyra små IT-projekten som har misslyckats?

• U3: Hur kunde respektive IT-projekt fått ett mer lyckat utfall?

1.4 Målgrupp

Studiens målgrupp är yrkesverksamma personer som jobbar med IT-projekt eller företag som bedriver IT-projekt.

1.5 Metod

Kvalitativ ansats

Denna studie är inriktad mot kvalitativ forskning, eftersom denna uppsats skall upplysa nya problem och sträva efter en djupare helhetsbeskrivning av nuvarande problemområde (Patel &

Davidson 2019, s.52). Kvalitativ undersökning handlar om att tolka och förstå till exempel människors upplevelser eller hur man kan beskriva och förstå sociala situationer och sammanhang. Kvalitativ forskning innebär också att upptäcka nya problem och möjligheter samt sträva att nå en djupare helhetsbeskrivning av nuvarande situation (Patel & Davidson 2019, s.53).

Datainsamling

Patel och Davidson (2019, s.94) redogör ett antal olika tekniker som kan användas för att samla in data. En av dessa tekniker är intervjuer. En person som medverkar på en intervju och besvarar på frågorna namnges respondent. Intervjuaren träffar intervjupersonen och genomför intervjun, likväl kan intervjuer genomföras via telefonsamtal (Patel & Davidson 2019, s.94). Fördelen med intervjuer är att intervjuaren kan hjälpa respondenten om den personen inte förstår sig på en fråga. Vissa respondenter vill hellre uttrycka sig med egna ord och just därför är det bra att använda sig av intervjutekniken. Intervjuerna som ligger grund till datainsamling för denna undersökning är ostrukturerad med en låg grad av standardisering, vilket innebär att frågorna

(8)

3

ställs i en formulerad ordning. Ostrukturerad intervju lämnar maximalt utrymme för respondenten att svara inom (Patel & Davidson 2019, s.98). Patel och Davidson (2019, s.95) nämner även enkäter för insamling av data. Nackdelen med enkäter är att respondenten kan se hela enkäten och anpassa svaren. Enkäter passar inte alla respondenter då vissa vill utrycka sig med egna ord. På dessa grunder har jag valt intervjutekniken för datainsamling framför enkäter.

Deduktivt arbetssätt

Till min undersökning har jag använt ett deduktivt arbetssätt (Patel & Davidson 2019, s.26–

27) där jag har undersökt teori och tidigare studier för att få en uppfattning på vad som orsakar att små IT-projekt misslyckas. De faktorer som hittades för små IT-projekt blev grupperat i sex huvudfaktorer, dessa sex huvudfaktorer användes för att testa teorin i förhållande till empirin.

Med hjälp av teori och empiri kom jag fram till de faktorer som har orsakat att små IT-projekt misslyckats.

Undersökningens struktur

Kapitlet redogör om undersökningens struktur steg för steg.

1.5.4.1 Förberedelser

Med hjälp av teorikapitlet (kapitel 2) har det varit möjligt att få en uppfattning vad ett IT-projekt är och hur det genomförs och vilka faser som finns i projektet. Teorikapitlet utgör ett underlag för intervjuguiden som har används för att kunna besvara undersökningsfrågorna. Författaren har använd sig av tidigare studier om misslyckade små IT-projekt, detta för att överhuvudtaget kunna formulera en intervjuguide (bilaga 3). Dock har det inte varit lätt att hitta många studier just om små misslyckad IT-projekt. Likväl har fyra tidigare studier undersökts, och dessa fyra studier handlar till en viss del om små misslyckade IT-projekt (kapitel 2.6). Till en viss del eftersom det framgår inte alltid storleken på projektet som de tidigare forskarna har undersökt.

De fyra studierna har framställt i en tabell samt vilka faktorer som har orsakat att IT-projekten har misslyckat (tabell 2).

1.5.4.2 Urval av respondenter

Respondenterna i denna undersökning är projektledare. Totalt har fyra respondenter deltagit i denna undersökning. Dessa fyra personer representerar fyra olika IT-projekt (kapitel 3).

Respondenterna har fått berätta under intervjun om vad som har varit misslyckat med deras IT- projekt. Urval av dessa fyra respondenter har gjorts på ett villkor, och det är att respondenterna har deltagit i ett litet IT-projekt. Respondenterna har valts ut genom att författaren har kontaktat dem via mejl och frågat ifall om dem kan delta i undersökning om små misslyckade IT-projekt.

Respondenterna själva har bestämt datum för intervju. Alla intervjuer har genomförts digitalt 1.5.4.3 Genomförande

Undersökningarna har genomförts med intervjuer. Samtliga intervjuer har skett digitalt, detta på grund av rådande situationen med COVID 19. Som hjälpmedel har Microsoft Teams och Zoom, som är videokonferensprogram, har använts för att kunna intervjua med respondenterna.

Några dagar innan intervjusessionen ägde rum har respektive respondent fått ta del av

(9)

4

samtyckesblanketten (bilaga 1) samt informationsbrevet (bilaga 2) via deras angivna e- postadress. Innan intervjuerna kunde påbörjas, har författaren frågat ifall om respondenten har läst igenom informationsbrevet och skrivit under samtyckesblanketten. Samtyckesblanketten har signerats med e-signatur och därefter skickats tillbaka till författaren. Därefter har intervjusessionen startats i gång med videoinspelning. Intervjusessionen har spelats in och det har framgått i samtyckesblanketten. Inspelningen gjordes med hjälp av Zooms och Microsofts inbyggda inspelnings funktion. Inspelningen har använts för att transkribera det som respondenterna har sagt under intervjun. Respondenterna fick från början berätta om sig själva och därefter ställdes de faktiska frågorna. Efter intervjun var avklarad har inspelningen avslutats och tacksägelser riktats mot respondenten för sitt deltagande.

1.5.4.4 Bearbetning och analys av intervjudata

Videoinspelningarna från intervjun har transkriberat för att kunna besvara undersökningsfrågorna. Patel och Davidson (2019, s.139) nämner att det finns olika sätt att bearbeta data beroende på forskningsmetod. Vid kvalitativ bearbetning arbetar man oftast med textmaterial i form av bok, artikel, dagbok och anteckningar. Även videoinspelning och ljudinspelning räknas med (Patel och Davidson 2019, s.150). Eftersom denna studie är kvalitativ och det innebär bearbetning av videoinspelning. Det första som gjordes var att spela upp videointervjuerna ett antal gånger och samtidigt transkribera allt som sades i videointervjun. Som hjälpmedel har Microsoft Word dokument använts, där respondenternas svar antecknats ner. Efter transkribering processens slut påbörjades bearbetning av data.

Allwood (2011) nämner att det finns många sätt att bearbeta data vilket sätt man ska göra det på beror på data och på en själv. Eftersom obearbetade data från början är svårbegriplig måste man reducera texten och analysera vad det handlar om (Allwood 2011). Arving (2012) förklarar hur man kan bearbeta sin kvalitativa data. Metoden som selekterades för att bearbeta och analysera data går ut på att bearbetning och analys sker i löpande text med tabell. Det transkriberade materialet bröts ner i meningsbärande enheter, de meningsenheterna kondenserades till kortare meningar och därefter abstraherades till en kod. Vilket gjorde att koden beskrev meningsenhetens innehåll (Arving 2012). Innehållet i koderna presenterades i underkategorier och alla underkategorier sammanfördes till en huvudkategori (Arving 2012).

Tabell 1 demonstrerar ett exempel hur bearbetad och analyserad data ser ut.

Tabell 1 Bearbetad och analyserat data Meningsbärande

enhet Kondenserad

meningsenhet Kod Underkategori Huvudkategori

R1.Det som de gjorde fel var att typ inte flagga … när ett fel stod i systemet...

Det som gruppen gjorde fel var att dem inte flaggade när ett fel uppstod i systemet.

Gruppen glömde flagga och säga till när ett fel uppstod i systemet.

Projektgruppens kommunikation inom projektet

Projektgrupp

(10)

5 1.6 Etiska överväganden & GDPR

Forskningens fyra huvudkrav

Vetenskapsrådet (2012) skriver att det är ytterst viktigt för oss forskare hur vi behandlar undersökningens deltagare och deras personuppgifter. Det finns fyra huvudkrav på forskning:

informationskravet, samtyckeskravet, konfidentialitetskravet och nyttande kravet.

Informationskravet innebär att forskaren ska informera deltagaren vilket syfteundersökningen har och även redovisa studiens villkor. Forskaren ska även nämna att undersökningen är frivillig och deltagaren har rätt att avbryta sin medverkan (Vetenskapsrådet 2012). I denna undersökning har samtliga deltagare i förhand informerats om syftet med undersökningen (bilaga 2).

Samtyckeskravet betyder att forskaren måste få undersökningsdeltagarens samtycke innan undersökningen kan påbörjas. Detta kan göras med hjälp av samtyckesblankett som den berörda deltagaren ska få valet att skriva under eller inte. Samtliga deltagare skrev under samtyckesblanketten i bilaga 1. D de blev också informerade att de avbryta sitt deltagande utan några helst konsekvenser.

Konfidentialitetskravet handlar om att insamlade personuppgifter ska bevaras på ett sådant sätt att obehöriga inte kan ta del av dem. Det är även viktigt vid avrapportering att deltagarpersonerna förblir oidentifierbar för utomstående (Vetenskapsrådet 2012). Samtliga deltagare i denna undersökning har önskat att förbli konfidentiella och deras önskan har respekterats av författaren.

Nyttjandekravet handlar om att de uppgifter som samlas in får endast användas för forsknings- ändamål, det får inte användas eller utlånas för kommersiellt bruk eller andra icke vetenskapliga syften (Vetenskapsrådet 2012). Insamlade data har endast använts för uppsatsen.

GDPR

Dataskyddsförordningen trädde i kraft den 25 maj 2018 och denna lag berör alla EU-länder. I praktiken innebär den att personuppgifter enbart får samlas in för vissa berättigade ändamål, att inte fler uppgifter än nödvändigtvis får samlas in och att personuppgifterna inte får sparas längre tid än det behövs. Det är också viktigt att hantera personuppgifterna på ett tryggt sätt. Den som behandlar personuppgifter måste ta ansvar för att förordningens regler ska följas och även kunna bestryka det genom skriftlig dokumentation (Karlstads Universitet 2020).

För att det skulle vara möjligt att genomföra undersökningar har en GDPR-blankett fyllts i och skickat in till Karlstads universitets. I GDPR blanketten skrevs ner syftet med undersökningen, vilka personuppgifter som ska samlas in, hur dessa personuppgifter ska hanteras samt bevaras.

I informationsbrevet (bilaga 2) finns det en förklaring om vad personuppgiftsbehandlingen innebär. Det framgick även i informationsbrevet att när arbetet är slutfört så kommer alla personuppgifter raderas. Vad som beträffar hur personuppgifterna bevaras, så har samtliga personuppgifter bevarats på en lösenordskyddat Windows-dator.

(11)

6

Litteraturöversikt

I litteraturkapitlet beskrivs problemområdet. Kapitlet börjar med en förklaring om IT- projektets grunder därefter projektlivscykeln, om små och stora IT-projekt och tidigare studier om små samt stora IT-projekt. Kapitlet avslutas med en sammanfattning av litteraturkapitlet.

2.1 Källkritik

De vanligaste källorna för kunskap är böcker artiklar publicerade i vetenskapliga tidskrifter eller rapporter som är digitaliserad (Patel & Davidsson 2019, s.62). På internet finns det stora möjligheter att hämta information. Denna studie har använt olika informationskällor. Bland annat böcker, PDF – rapporter, webbtidningar och e-böcker. Karlstads universitetsbibliotek har också använts för att hämta information om vetenskapliga artiklar och uppsatser. Patel och Davidsson (2019, s.89) menar att en forskare ska ta ställning till varför ett dokument har tillkommit, när har det tillkommit och vem som var upphovsmannen. Denna studie har en kritisk inställning till de källor som har samlats in.

Avsikten har varit att använda de senaste källorna som finns inom ämnesområdet för att få aktualitet i undersökningen. Det har inte alltid varit möjligt att fullfölja denna intention. Det finns källor som är äldre än tio år i denna uppsats. Likväl källor som Görling (2009), Eriksson (2008) och Karlsson och Duvsten (2004) har bedömts som aktuella eftersom kunskapsbidraget inte avgörs av utgivningsåret utan av själva innehållet.

Det har inte varit lätt att hitta många studier just om små IT-projekt. De sökord som har använts Google Scholar och universitetets Onesearch för att hitta information om små IT projekt är:

”Misslyckat IT-projekt”, ”small IT-project”, ”small failed IT-project”, ”small software project”, ”Misslyckat små IT-projekt”,”Små IT-projekt” (kanske stavningarna begränsade sökningarna onödigt mycket, har jag insett i efterhand). Fyra tidigare undersökningar har gjorts om små IT-projekt. I två av studierna framkommer det en närmare storlek på projekten medan i de resterande två inte förekommer beskrivningar om det (se kapitel 2.7). Därför finns det skäl att vara kritisk till de källor som berör små IT-projekt.

2.2 Vad är IT-projekt?

Ett IT-projekt är ett tillfälligt arbete som går ut på att skapa en unik produkt eller tjänst. När ett projekt uppnår sitt mål ska projektet eliminera sin egen existens (Schwalbe 2016, s.4). IT- projekt kan vara stora eller små och involvera från en person till flera tusentals personer.

Projektlängden varierar från att det kan ta en dag till att det kan ta flera år tills projektet uppnår målet. Ett exempel på vilka tjänster eller produkter som kan skapas med IT-projekt, kan vara att utveckla ett nytt IT-system eller att ett tv bolag implementerar ett IT-system som gör det möjligt för tittarna att rösta på tävlande (Schwalbe 2016, s.5).

Schwalbe (2016, s.6) beskriver att projekt kan finnas i alla former och storlekar, vidare förklarar författaren att det finns egenskaper som definierar ett projekt. En av dessa definitioner är att ett IT-projekt ska ha ett unikt syfte och väldefinierat mål (Schwalbe 2016, s.6). Ett IT- projekt

(12)

7

kräver också resurser, ofta från olika områden. Resurser inkluderar människor, hårdvara, programvara och andra tillgångar. Många projekt kan komma i kontakt med andra avdelningar för att uppnå de unika syftena (Schwalbe 2016, s.6). Verksamheten kan också behöva hyra in konsulter för att kunna uppnå målet. Emellertid är resurser begränsade och måste förbrukas effektivt för att uppnå. I ett projekt kan det finnas osäkerhet, detta eftersom varje projekt är unikt är det ibland svårt att definiera målet tydligt, uppskatta hur lång tid det kommer krävas för att slutföra målet eller bestämma hur mycket det kommer att kosta. Externa faktorer kan också orsaka osäkerhet i projektet, till exempel en leverantör som bestämmer sig att gå ur verksamheten eller att en projektmedlem som behöver oplanerad ledighet (Schwalbe 2016, s.6).

Varje projekt kan begränsas på olika sätt, många gånger av dess omfattning, tid och kostnadsmål. Dessa begränsningar kallas ibland som trippelbegränsning. För att skapa ett framgångsrikt projekt måste en projektledare överväga omfattning, tid och kostnad och balansera dessa tre ofta konkurrerande mål (Schwalbe 2016, s.7). Att hantera trippelbegräsningen handlar om att avgränsa mellan omfattning, tid och kostnadsmål för ett projekt. Man kan tillexempel behöva öka budgeten för ett projekt för att uppnå mål och tidsmål, eller att minska omfattning av ett projekt för att uppnå tids- och kostnadsmål (Schwalbe 2016, s.7).

2.3 Projektlivscykeln

I projektlivcykeln finns fyra faser. De fyra faserna är förstudiefas, planeringsfas, genomförandefas och avslut (Görling 2009, s.43). Projektlivscykeln är en metod som tillämpas i ett IT-projekt för att definiera projektets olika faser. Varje projekt följer samma mönster med att ha en början, ett mitten och ett slut. Beroende på projekttyp kan mitten-delen se annorlunda ut för alla (Görling 2009, s.43). Man delar upp projektet i olika faser eftersom planering av projektets olika moment får en bättre struktur. På så viss blir det lättare att följa projektets utveckling, även tydligare bild av vad som ska göras och vart i projektet man befinner sig (Projektledning 2018a; Görling 2009; s.43).

Förstudiefasen

I denna fas samlas in information om projektet. Därefter utses en projektledare. Sist skapas en kravspecifikation.

2.3.1.1 Insamling av information

I förstudiefasen samlas in all information om IT-projektet. I denna fas diskuteras projektets mål och objektiv med alla involverade i projektet så att man kan ställa samman alla krav för projektet (Projektledning 2018a). En dialog med alla projektets intressenter till projektet ska genomföras för att se vilka krav de ställer fram och vad de förväntar sig av projektet.

Intressenter är de personer som är engagerade i projektaktiviteter eller påverkas av det. Dessa intressenter inkluderar projektsponsor (även kallad för projektbeställare), projektgrupp, kunder, användare och leverantör (Projektledning 2018a). Dessa intressenter har mer än sällan olika behov och förväntningar. Efter insamling av all information och fastställning av projektets mål ska allt sättas ihop i ett första dokument (Karlsson 2007). Man får en bra insikt på vad som kommer krävas för att påbörja projektet och hu lång tid det kommer att krävas för att kunna

(13)

8

slutföra. Ett första utkast för projektschema skapas och under fasen baseras de aktiviteter som behöver utföras för att uppnå projektmålet (Görling 2009, s.43).

I förstudiefasen ingår även en nulägesanalys. Meningen med nulägesanalys är att skapa en verklig bild av verksamheten och samtidigt hitta områden som behöver bli bättre. Med hjälp av nulägesanalys kan företaget se vart de befinner sig idag och vart de kommer befinna sig i framtiden. Nulägesanayls hjälper företaget för att se styrkorna och svagheterna i själva företaget (Projektledning 2019). Vem som ansvarar för förstudiefasen kan variera, dock är det oftast beställaren som har ansvaret för förstudiefasen (Projektledning 2017).

2.3.1.2 Utse projektledare

Karlsson (2007) nämner att en projektledare utses i förstudiefasen, dock kan det förekomma att en projektledare utses i planeringsfasen, om det inte har gjorts en förstudie. En projektledare är den person som leder IT-projektet. Personen som får rollen som projektledare har ett stort ansvar för IT-projektets välgång. Den rollen kan se olika ut beroende på projektets karaktär (Görling 2009, s.45). Arbetsuppgifterna för en projektledare kan variera beroende på bransch och organisation, de flesta projektledare utför dock liknade uppgifter oavsett skillnader (Schwalbe 2016, s.22). Att lyckas som projektledare krävs personalkompetens, affärskompetens och teknisk kompetens. Som projektledare måste man ha en mängd olika färdigheter och kunna bestämma vilka färdigheter som är viktigare i olika situationer (Schwalbe 2016, s.24). En projektledare måste vara bekväm att leda och kunna hantera förändringar, eftersom de flesta projekt introducerar förändringar i organisationer och involverar förändringar inom själva IT-projektet (Schwalbe 2016, s.24). Projektledaren måste även fatta viktiga projektbeslut och kunna ansvara för de beslut som har tagits. För att kunna lyckas med IT- projektet krävs det att projektledaren besitter mjuka färdigheter, med andra ord mänskliga relationer. Dessa färdigheter inkluderar effektiv kommunikation, ledarskap, motivation, förhandling, konflikthantering och problemlösning. Dessa mjuka kompetenser kan hjälpa projektledaren med att förstå, navigera och möta intressenternas behov och förväntningar genom att leda, kommunicera, lösa problem och påverka organisationen (Schwalbe 2016, s.25).

2.3.1.3 Insamling av krav

Karlsson (2007) nämner att krav samlas in i förstudiefasen.

Oavsett IT-projektets storlek måste det finnas krav. Ett krav är helt enkelt ett önskemål om vad IT-systemet måste göra och vilka egenskaper den ska ha. Kraven låter de som utvecklar IT- systemet få en snabb överblick över funktionaliteten som behövs. Det ger även beställaren en möjlighet att specificera vad IT-systemet ska uppfylla (Olsson 2017).

Felaktiga krav kan leda till att ett IT-projekt misslyckas. Om ett IT-projekt levereras senare än den angivna tidsramen eller om budgeten överskrider, kan det bero på att kraven är inte korrekt.

Även beställaren kan bli missnöjd på grund av felaktiga krav (Eriksson 2008, s.19). Eftersom felaktiga krav kostar pengar att åtgärda och ju senare det upptäcks desto dyrare blir det att åtgärda, därför att ett IT-system måste justeras om ifall kraven ska ändras i efterhand och det leder till förseningar och högre kostnader (Eriksson 2008, s.23).

(14)

9

Krav kommer från många intressenter, exempelvis från användare och chefer. Beställaren är den part som beställer IT-systemet och leverantören är den part som levererar IT-system. Som regel är det beställaren som definierar och skapar kraven och leverantören tar över kravspecifikationen och jobbar utifrån det (Eriksson 2008, s.28; Projektledning 2017). När krav ska samlas in börjar man med att definiera syfte och mål, målgrupp och avgränsning.

Under insamlingen samlas de övergripande kraven in, de krav som kommer att bilda underlag för kommande arbete (Eriksson 2008, s.31).

Krav kan samlas in genom workshops, intervjuer och enkäter (Wiktorin 2018, s.199; Eriksson 2008, s.32). Syftet med kravinsamling är att upptäcka intressenternas önskemål på det kommande IT-system, och även att få en uppfattning hur mycket det kommer att kosta samt hur mycket tid som kommer krävas för att färdigställa ett IT-system (Görling 2009, s.78). Vanliga problem inom insamling av krav är att användarna saknar den tekniska kompetensen och har därför svårt att uttrycka sina behov. Beställaren kan också vara oengagerade i kravinsamlingen vilket medför att fel krav samlas in (Eriksson 2008, s.62). Det brukar ske att beställaren anser att leverantören ska tala om hur systemet ska se ut. Emellertid måste IT-systemet utvecklas i ett nära samarbete mellan beställare och leverantör, annars finns det risk att leverantören levererar ett system som inte passar beställarens användningsområde (Eriksson 2008, s.63).

Krav som har samlats in måste prioriteras för att identifiera de krav som ger mest värde för pengarna respektive de krav som är sammankopplade med störst risker. Prioritering av krav görs av beställaren med hjälp av leverantören (Eriksson 2008, s.32). Många gör kravprioritering baserat på sin maggropskänsla utan speciellt mycket eftertanke. Prioritering bör göras kontinuerligt under projektets gång för att undersöka om kravens prioriteringar gäller fortfarande. Det finns många goda anledningar att prioritera kraven, bland annat prioritering gör det lättare för projektledare att tilldela rätt resurser till kraven. Prioritering hjälper leverantören att förstå vad som är viktigast för beställaren (Eriksson 2008, s.106–107).

Prioritering av krav kan göras med hög, medel och låg teknik. Denna teknik går ut på att prioritera kraven på en tavla med gula lappar. Deltagarna diskuterar över de krav som bör ligga högst upp, därefter de minst betydelsefulla kraven längst ner (Eriksson 2008, s.111; Wiktorin 2018, s.210).

Efter att kraven är prioriterade ska det dokumenteras. En väl formulerad kravspecifikation underlättar för alla inblandade från både beställare och leverantör. Kravspecifikationen kan ses som ett formellt kontrakt mellan beställaren och leverantören och fastställer vad beställaren vill ha att systemet ska innehålla. Kravspecifikationen möjliggör också acceptanskriterier som ligger till grund för en objektiv bedömning om systemet är färdig (Eriksson 2008, s.127; Shen 2020).

När förstudien är avslutat påbörjas nästa fas, som är planeringsfasen (Karlsson 2007).

Planeringsfas

I planeringsfasen måste projektets medlemmar väljas ut. Avsnittet inleds därför med att beskriva hur dessa väljs och vilka roller som de har i projekten.

(15)

10 2.3.2.1 Projektmedlemmarna

Under planeringsfasen ska projektledaren tilldela projektgruppen deras arbetsuppgifter (Projektledning 2018d). Projektgruppen består av de personer som ska utföra arbetet under IT- projektets gång för att uppnå projektmålet. Projektledaren bör välja ut de personer som är mest lämpliga för IT-projektet, de personer som har erfarenhet och kunskap som matchar bäst för IT-projektet (Projektledning 2018d). Det är viktigt att det finns respekt och tilltro mellan projektledaren och projektdeltagarna, om inte så är fallet kan projektet misslyckas (Danielsson 2018). The Standish Group (2013) förklarar att kommunikationsförmåga är också viktigt inom projektgruppen. Santos (2014) skriver att projektgruppen ska vara begåvad och engagerad.

Begåvad och engagerad projektgrupp ökar välgången hos ett IT-projekt (Elner & Ravn 2010).

2.3.2.2 Projektets aktiviteter i planeringsfasen

I planeringsfasen skapas även en projektplan som fungerar som ett underlag för IT-projektet, en instruktion som upplyser hur projektmålet ska uppnås (Projektledning 2018c; Görling 2009, s.44). Det är projektledaren som skapar en projektplan, dock är det viktigt att projektledaren samarbetar med projektgruppen för att skapa en bra plan (Projektledning 2018c; Schwalbe 2016, s.271). Projektplanen beskriver vad som ska göras, hur det ska genomföras, vem som gör vad och när det ska vara fullbordat (Görling 2009, s.44). Det första som bör göras är att definiera IT-projektets mål samt omfattning. I projektplanen ska finnas följande beståndsdelar; budget, tidsplan, kommunikationsplan och riskanalys.

Tidsplanen utgör en beskrivning över de aktiviteter som finns och hur lång tid skall tilldelas åt varje arbetsuppgift (Projektledning 2018c; Hughes 2012, s.22). Tidsplanen krävs också för att försäkra sig om att ett IT-projekt fullföljer den faktiska tiden. Dessutom blir det möjligt att bestämma IT-projektets slutdatum samt hur mycket det kommer att kosta (Projektledning 2018a).

Meningen med en kommunikationsplan är att säkerställa lämplig generering, insamling, spridning, lagring och disponering av IT-projektet (Schwalbe 2016, s.390).

Kommunikationsplanen definierar vilka de inblandade i projektet är, vad deras roll är och hur kommunikationen ska flöda mellan dessa inblandade personer (Projektledning 2018b). Det är avgörande för projektgruppen och projektledaren att säkerställa en god kommunikation med ledningsgruppen och IT-projektets andra intressenter. I kommunikationsplanen bör det också framgå intressenternas informations- och kommunikationsbehov, det vill säga vem som behöver information och vilken typ av information som ska ges (Schwalbe 2016, s.391).

Wiktorin (2018, s.426) skriver att i en projektplan skall även riskerna med IT-projektet identifieras och analyseras. Projektriskhantering kan många gånger resultera i en förbättring av IT-projektets framgång. Riskhantering hjälper projektledaren samt projektgruppen att förstå naturen hos IT-projektet (Schwalbe 2016, s.426). En bra riskhantering går ofta obemärkt förbi om man jämför med krishantering, vilket betyder en uppenbar fara för ett IT- projekts framgång.

Krisen får i sin tur hela projektgruppens intensiva intresse. Att åtgärda en kris har mycket större synlighet, ofta åtföljd av belöningar från ledning, än framgångsrik riskhantering. Däremot när riskhantering är effektiv resulterar det i färre problem, och när det finns få problem resulterar det i snabbare lösningar. Risker skiljer sig från problem (Schwalbe 2016, s.427). En risk är en

(16)

11

oplanerad händelse som kan hända, men har ännu inte gjort det. Ett problem är en oplanerad händelse som har redan inträffat och som kräver att projektledaren begär eller initierar åtgärder som inte tidigare planerats (Hughes 2012, s.14; Schwalbe 2016, s.429). Projektledaren och projektgruppen bör hålla ett flertal planeringsmöten tidigt i projektet för att utveckla riskhanteringsplanen. Projektledaren och projektgruppen bör också granska projektplan, riskkategorier, lärdomar från tidigare projekt för att skapa en riskhanteringsplan (Schwalbe 2016, s.433).

Att skriva en projektplan kan upplevas onödigt eftersom det är en tidskrävande aktivitet (Schwalbe 2016, s.98). Många gånger skapas inte en projektplan eller så uträttas en vag projektplan eftersom projektgruppen vill disponera sin tid på ett annat moment i IT-projektet (Projektledning 2018c). Likväl behövs projektplanen för formella skäl också, för att få godkännande för att genomföra projektet. Till exempel kan det handla om leveranstider eller hur projektet ska verkställas (Projektledning 2018c). Genom att planera projektet i tid kan man spara tid i ett senare skede, eftersom grunderna för arbetet är redan applicerad (Projektledning 2018c).

Efter att projektplanen är upprättad och beställaren gett sitt godkännande, initieras nästa fas som är genomförandefasen (Karlsson 2007).

Genomförandefas

I genomförandefasen utförs de aktiviteter som finns planerat i andra fasen, nämligen projektplan. Det är i denna fas som mest resurser och tid går åt eftersom det är i genomförandefasen som IT-systemet utvecklas (Santos 2014). Det är projektgruppens arbete att utveckla IT-systemet, medan projektledaren samordnar nödvändiga resurser (PMBOK 2017, s.23). De nödvändiga resurserna kan ordnas av företagsledningen, som är en grupp av individer på högsta ledningsnivå i en organisation som bedriver själva organisationen (Menz 2011). Det är en fördel om IT-projektet får stöd av ledningen när det kommer till att skaffa resurser, eftersom ett IT-projekt kan påverkas av intern politik (Danielsson 2017b; Santos 2014).

Ledningsgruppen har ett stort inflyttande på utgången av ett IT-projekt. Att få stöd från företagsledning har en påverkan om ett IT-projekt får tillgång till resurser som krävs (Santos 2014). Det är också viktigt att ledningen inte gör ändringar i tidsplanen eller hanterar resurser utan att samarbeta med projektledaren. Ledningsstöd och engagemang är också viktigt för projektledaren och även att ledningen inte hindrar projektledaren att hantera och genomföra projektet (Santos 2014; Schwalbe 2016, s.54). Det bästa sättet att döda ett projekt är att spara pengar och resurser. Om projektledaren har stöd och engagemang från ledningen kommer de också att ha nödvändiga resurser och inte distraheras av händelser som inte påverkar deras specifika projekt (Schwalbe 2016, s.54).

I genomförandefasen bör även användarna medverka för att få en hög acceptans för IT- projektet. Att få hög acceptans kan ske genom att användarna får vara med i utvecklingsarbetet och påverka projektet (Karlsson & Duvsten 2004). Författarna Karlsson och Duvsten (2004) menar att involvering av användare i IT-projekt sker genom att beställaren som lånar ut användarna. Beställaren bör förklara för användarna vad det innebär att medverka i ett IT- projekt eftersom det är inte alltid begripligt för användarna vad det gäller att medverka i ett IT- projekt (Karlsson & Duvsten 2004). Det brukar ske att personer som medverkar i projektet inte

(17)

12

har kunskap om IT-projekt, vilket leder till varierande resultat (Santos 2014). Det finns problem med att användare inte vill medverka i, eller medverkandet är på ett ineffektivt sätt. Projektet kan anses som misslyckat om det får motstånd av användarna och inte används (Santos 2014).

Avslut

I projektlivcykelns sista fas avslutas projektet. Innan projektet kan beräknas om avslutat bör man gå igenom ett par punkter för att bekräfta att alla krav är uppfyllda och rätt resultat levereras till kunden samt att kunden/användaren är nöjd med IT-systemet. En analys ska också göras för att se hur projektet gick, vad som gick mindre bra, vad som kan förbättras och vilka erfarenheter man kan ta med sig till näst kommande projekt (Görling 2009, s.44). Man bör också analysera projektbudgeten för att förstå om projektbudgeten överskred eller om det var inom den angivna budgetramen (Projektledning 2018f). Alla dokument som berör projektet bör sammanställas och arkiveras. I framtiden kan man använda projektets dokument som ett hjälpmedel för att se hur man kan gå till väga i liknade projekt för att uppnå målet (Projektledning 2018b; Görling 2009, s.44).

2.4 Små IT-projekt

De flesta organisationer är beroende av olika IT-projekt, både stora och små. Fastän små projekt har unika utmaningar som inte finns i stora projekt, kan små projekt ändå dra nytta av de bästa metoderna för projektledning (Rowe 2007). Oavsett projektstorlek är projektledaren ansvarig för projektets framgång (Rowe 2007). Att hantera projekt kräver tid, hårt arbete och disciplin.

Skillnaden mellan att hantera större och mindre projekt är inte bara tid, ansträngning och disciplin utan också processen och verktygen. Även erfarna projektledare står ibland inför utmaningen att hantera små projekt (Rowe 2007). De flesta projektledningsmetoder är utformade för stora projekt och kan inte enkelt anpassas för mindre projekt. För att uppnå maximala fördelar behövs en metod som är särskilt utformad för små projekt som inkluderar skalbara och anpassningsbara projektledningsprocesser, verktyg och tekniker (Rowe 2007).

Ledarskap är också viktigt, ofta måste projektledare för små projekt leda genom inflytande och inte auktoritet (Rowe 2007).

När det gäller definition av små IT-projekt så varierar det från litteratur till litteratur. Enligt Rowe (2007) som är utgivare för Project Management Institute (PMI) menar att ett litet IT- projekt ska ha en kort varaktighet och vara mindre än sex månader. Rowe (2007) nämner också att projektgruppens storlek ska vara mindre än tio personer i ett litet IT-projekt. När det gäller projektbudgeten, ska det inte kosta mer än 75 000 dollar (ca 680 000 SEK, beroende på valutakursen). Rowe (2007) skriver också att ett litet IT-projekt ska använda projektledaren som den primära källan för ledarskap och beslutfattande. Att förbättra ett befintligt informationssystem eller utveckla en webbplats är två exempel på små IT-projekt (Rowe 2007).

2.5 Projektframgång

Vad som definierar ett lyckat projekt kan variera från litteratur till litteratur. Hughes (2012, s.2) definierar vilka kriterier som måste gå i uppfyllelse för att projekt ska anses som lyckat. Att de

(18)

13

angivna målen uppnås och att IT-projekt levereras inom tids och budgetramen är viktiga kriterier menar Hughes (2012, s.2). Vidare menar författaren att ett IT-system som ska levereras till beställaren fungerar enligt överenskomna specifikationer. Det sista som Hughes (2012, s.2) nämner är att beställaren blir tillfredsställd med IT-systemet som har levererats.

Denna uppsats utgår från Hughes (2012) kriterier för vad som är lyckat, och konstruera kriterier för misslyckande som motsatser. Detta för kunna bedöma de IT-projekt som ska undersökas i denna rapport. Med andra ord gäller följande kriterier för ett misslyckat IT-projekt: när tid och budget överskrids, IT-systemet inte levereras till beställaren enligt överenskomna specifikationer samt att beställaren inte blir nöjd med IT-systemet.

2.6 Tidigare studier om misslyckade (små) projekt

I detta kapitel redovisas fyra studier om små misslyckade IT-projekt. I studien ska små IT- projekt (utifrån den definition som finns i kapitel 2.3) diskuteras men det är inte alltid helt tydligt vilken storlek det är på de projekt som diskuteras i rapporterna. Fokuset är vilka faktorer som de kommer fram till och som har betydelse för misslyckandet.

IT Project Success Factors: An Experience Report

Würtemberg et al. (2011) vid Kungliga Tekniska Högskolan undersökte fem IT-projekt där dessa fem ansågs som misslyckat. Författarna definierar ett lyckat IT-projekt när tid, budget och kvalitén uppfylls. Författarna analyserade vilka faktorer som orsakade att dessa IT-projekt misslyckades. Ur författarnas rapport har projekt 2, 3 och 5 uteslutits eftersom dessa tre IT- projekt handlar om stora IT- projekt medan projekt 1 och 4 är små IT-projekt.

Projekt 1

Målet med Projekt 1 var att utveckla en ny generation av utrustning för mätning av planhet i metallplattor. Utvecklingen av denna nya utrustning innehöll både hårdvara och mjukvara utveckling. Detta projekt var ett internt projekt i ett av de största system tillverkaren i Norden.

Slutprodukten var avsedd att sälja till kunder som ett standardverktyg. Ledningens strategi hade fokus på att leverera produkten med hög kvalité snarare än att produkten skulle levereras i tid och inom budget. Alla resurser i projektet var interna kompetenser, alltså inga dyra externa konsulter som påverkade projektets budget när tidsschemat överskred. Projektets mål skapades av projektledaren (Würtemberg et al. 2011).

Författarnas beskriver i analysen vilka faktorer som orsakade att IT-projektet misslyckades.

Projektet fick inte stöd från ledingen. Systemkraven och användarkraven var inte noggrant beskrivet vilket innebar att alla inblandade inte förstod de krav som fanns i kravspecifikationen.

Övriga krav som kommunikationsproblem inom projektgruppen samt sena förändringar i kraven låg också till grund att IT-projekt ansågs som misslyckat (Würtemberg et al. 2011).

Projekt 4

Projekt 4 omfattade integration och implementering av en ny webbsida för en svensk kommun.

Efter förstudiens utförande i samband med upphandlingsprocessen var projektet planerat att engagera 13 personer under sex månader tid (Würtemberg et al. 2011). Som webbsidans ram angavs i kraven fortfarande var under utveckling och hade förändrats mycket eftersom

(19)

14

projektgruppen hade använt det förra gången blev de beroende av företagets supportdisk ansvarig för ramverket, en tjänst som endast är öppen fyra timmar i veckan. Under projektet visade det sig att många krav var oklara. En företagskonsult utnämndes därför för att rätta till vad kunden verkligen ville ha från webbsidan. Detta resulterade i flera sena ändringar, dock ökade kommunikationen med slutanvändaren, vilket var positivt för den kommande genomförandet. De tekniska svårigheterna och det sena kravförändringar orsakade att projektet slutade i september 2010 i stället för augusti 2010 (Würtemberg et al. 2011).

I projekt 4 härstammade de flesta problemen från det faktum att projektgruppen inte förstod miljön och behoven hos slutanvändarna från början. När den utsedda företagskonsulten började arbeta aktivt med slutanvändaren, de flesta av dessa problem löstes. Det är därför antagligen att tiden kunde ha sparats och att sena ändringar kunde ha gjorts tidigare om kommunikationen med kunden hade etablerats i ett tidigare skede (Würtemberg et al. 2011).

What factors lead to software failure?

Verner et al. (2008) har undersökt ett antal IT-projekt där de hittade ett antal faktorer som orsakade att IT-projekt misslyckas. Författarna har undersökt såväl stora som små IT-projekt. I rapporten fram går det vilka projekt som är små och vilka som är stora, därav har projekt 24 samt projekt 13 valts ut eftersom dessa nämnda IT-projekt är små till storleken.

Projekt 24

Detta IT-projekt var en intern utveckling med sex anställda och en projektledare med 14 års erfarenhet. Det identifierades sex faktorer som orsakade att denna IT-projekt misslyckades. Det här projektet komplexitet underskattades och inte heller användare samt utvecklare var inblandad i uppskattningar, även om projektledaren gjorde projektuppskattning (Verner et al 2008). Ett aggressivt schema påverkade utvecklingsprocessen och projektgruppens motivation, på samma sätt som deras motivation. Skulden kan läggas på de svaga schema och de som var inblandade i projektets uppskattningar, vilket var en grupp bestående av ledning och projektledare. Enligt respondenten som författarna intervjuade så berättade personen att organisationen klippte projektbudgeten mot slutet av projektet (Verner et al. 2008).

Projekt 13

Projekt 13 hade en projektledare med tre års erfarenhet. Projektet var en intern utveckling med tio projektmedlemmar. Projektets problem inkluderar att projektledaren inte fick full befogenhet att hantera projektet. Varken projektledare eller utvecklare var involverade i projektuppskattningar. Projektuppskattningarna genomfördes utan lämpliga krav och det förekom ingen metod för kravinsamling (Verner et al. 2008). Övriga faktorer som påverkade IT-projektet var att projektet inte var tillräckligt bemannat, projektledaren kontrollerade inte projektet och personalen belönades inte för att arbetat långa timmar. Skulden för misslyckandet i projekt 13 måste delas mellan ledning och projektledare, emellertid det mesta av skulden borde falla på ledning som hindrade projektledaren och underskattade projektet (Verner et al. 2008).

(20)

15

Implementing small & medium IT projects in small & medium enterprises

Dumitrescu et al. (2014) undersökte faktorer som orsakar att IT-projekt får ett misslyckat resultat. Genom en fallstudie undersökte författarna två IT-projekt, ett litet projekt och ett mellanstort projekt. Båda IT-projekten handlar om att migrera email system från lokal server till Microsofts molntjänst. I slutsatskapitlet beskriver författarna vilka faktorer som orsakade att IT-projekten misslyckades.

Författarna nämner att brist på ledarskap är en viktig faktor för lyckat IT-projekt, att inte tillräckligt med vikt lades för de processer som upprätthöll ledarskapet under hela projektet.

Författarna nämner också att svag riskhantering också var en faktor som orsakade att IT- projektet misslyckades. Det förekom okunskap om risker inom projekten, vilket ledde till att den ursprungliga budgeten överskreds (Dumitrescu et al. 2014). Vidare påpekade författarna även att projekten saknade stöd från ledningen. Författarna noterar att det är förekommande att små och medium IT-projekt inte får stöd från ledningsgrupp. Dumitrescu et al. (2014) utpekar också att användarmedverkan är viktigt för ett lyckat IT-projekt, i rapporten framgår det att användarna inte var med från början till slutet av projektet. Sist nämner författarna att det är viktigt att förstå sig på affärsprocessens komplexitet, författarna förklarar att det förekom brister för förståelse av affärsprocessens komplexitet.

Critical Failure Factors (CFFs) of IT Projects

Dr Sudhakar (2016) vid Hyderabad universitet i Indien genomförde en undersökning för att få en uppfattning vilka faktorer som orsakar att IT-projekt misslyckas. Författaren baserade sin undersökning på litteraturgenomgång av konceptuella och empiriska studier. I studierapporten beskriver författaren om stora IT-projekt men även beskrivningar om små IT-projekt förekommer. Emellertid framgår det inte i empirikapitlet storleken på IT-projekt som har undersökts. Av det orsaken kommer alla faktorer redovisas här.

Sudhakar (2016) kom fram till vilka faktorer som orsakar att IT-projekt får ett misslyckat resultat. Orealistiskt projektschema och tidsfrister är bland annat faktorer som har orsakat.

Författaren nämner vidare att brist på riskhantering, vaga krav och ineffektiv kommunikation är också faktorer som kan orsaka att IT-projekt misslyckas. Även brist på användarmedverkan, brist på resurser, orealistiska förväntningar, brist på ledningsstöd, förändrade krav, brister i projektplanering och inget behov av ledningsstöd är faktorer som identifierades av Sudhakar (2016). I rapporten rankas faktorer från högst till lägst där det högsta är kritiska faktorer som ledde till att IT- projekt misslyckas.

2.7 Sammanfattning av litteraturgenomgång

Sammanfattningen utgör en kortfattat beskrivning av hela litteraturkapitlet.

Ett IT-projekt är ett tillfälligt arbete som går ut på att skapa en unik tjänst eller produkt och när målet är uppfylld, ska projektet eliminera sin egen existens. Ett IT-projekt är unikt och har ett syfte. IT-projekt kräver resurser av olika slag.

Organisationer är beroende av olika IT-projekt, både stora och små. Hantera IT-projekt kräver tid, hårt arbete och disciplin. Projektledarens ledarskapsförmåga är viktigt för små IT-projekt.

(21)

16

Små IT projekt ska ha en kort varaktighet, upp till sex månader, ha tio eller färre projektmedlemmar. Ett litet IT-projekt kan vara att utveckla en webbplats eller förbättra ett befintligt IT-system.

Projektlivscykeln har fyra faser, förstudiefas, planeringsfas, genomförandefas och avslut.

I förstudiefasen samlas information om IT-projektet och diskuteras projektets mål och objektiv med alla involverade i projektet. Projektets intressenter är de personer som är engagerad i projektet och påverkas av det. En nulägesanayls bör också genomföras för att skapa en verklig bild av verksamheten, men samtidigt hitta områden som behöver bli bättre. Vem som ansvar för förstudiefasen kan variera, dock är det oftast beställaren som är den ansvariga parten som sköter förstudiefasen.

I förstudiefasen utses även en projektledare. Projektledaren leder IT-projektet. Projektledaren har ett stort ansvar för projektets välgång. Rollen för en projektledare kan se olika ut beroende på projektets karaktär. Även arbetsuppgifterna kan variera för projektledaren beroende på IT- branschen. För att lyckas som projektledare krävs personalkompetens, affärskompetens och teknikkompetens. En projektledare måste vara bekväm att leda och kunna hantera förändringar, eftersom de flesta projekt introducerar förändringar i organisationer och involverar förändringar inom själva IT-projektet.

I förstudiefasen samlas även krav. Ett krav är ett önskemål om vad IT-systemet ska göra och vilka egenskaper den ska ha. Krav låter projektgruppen att få en snabböverblick över funktionalitet som behövs. Krav ger också beställaren möjlighet att specificera kommande IT- systemets funktionalitet. Felaktiga krav kan leda till att ett IT-projekt misslyckas. Krav kommer från många intressenter, exempelvis från användare och chefer. Som regel är det beställaren som definierar och skapar kraven och leverantören tar över kravspecifikationen och jobbar utifrån det. Krav kan samlas in genom workshops, intervjuer och enkäter. Syftet med kravinsamling är att upptäcka intressenternas önskemål på det kommande IT-systemet. Vanliga problem inom insamling av krav är att användarna saknar den tekniska kompetensen och har därför svårt att uttrycka sina behov. Beställaren kan också vara oengagerade i kravinsamlingen vilket medför att fel krav samlas in. Krav som har samlats in måste prioriteras för att identifiera de krav som ger mest värde för pengarna respektive de krav som är sammankopplade med störst risker. Prioritering av krav görs av beställaren med hjälp av leverantören. Efter att kraven är prioriterade ska det dokumenteras. En väl formulerad kravspecifikation underlättar för alla inblandade både från beställare och leverantör.

Under planeringsfasen, tilldelar projektledaren projektgruppens arbetsuppgifter.

Projektgruppen består av personer som ska utföra arbetet under projektets gång för att uppnå projektmålet. Projektledaren bör välja ut de personer som är mest lämpliga för IT-projektet, de personer som har erfarenhet och kunskap som matchar bäst för IT-projektet. Projektgruppen ska svara vara motiverad och begåvad. Projektledaren och ledningen bör se till att projektgruppen är motiverad och känner sig uppskattade för det arbetet som de gör.

I planeringsfasen skapas även en projektplan som fungerar som ett underlag för IT-projektet, en instruktion som upplyser hur projektmålet ska uppnås. Det är projektledaren som skapar en projektplan, dock är det viktigt att projektledaren samarbetar med projektgruppen för att skapa

(22)

17

en bra plan. I projektplanen ska finnas följande beståndsdelar; budget, tidsplan, kommunikationsplan och riskanalys. Tidsplanen utgör en beskrivning över de aktiviteter som finns och hur lång tid skall tilldelas åt varje arbetsuppgift. Kommunikationsplan säkerställer lämplig generering, insamling, spridning, lagring och disponering av IT-projektet.

Kommunikationsplanen definierar vilka de inblandade i projektet är, vad deras roll är och hur kommunikationen ska flöda mellan dessa inblandade personer. Riskhantering hjälper projektledaren samt projektgruppen att förstå naturen av IT-projektet. En bra riskhantering går ofta obemärkt förbi krishantering, vilket betyder en uppenbar fara för ett IT- projekts framgång.

Projektledaren och projektgruppen bör hålla ett flertal planeringsmöten tidigt i projektet för att utveckla riskhanteringsplanen. Att skriva en projektplan kan upplevas onödigt eftersom det är en tidskrävande aktivitet. Många gånger skapas inte en projektplan eller så uträttas en vag projektplan eftersom projektgruppen vill disponera sin tid på ett annat moment i IT-projektet.

I genomförande fasen sker de aktiviteter som finns i projektplanen. I denna fas går mest tid och resurser åt eftersom det är i genomförande fasen som IT-systemet utvecklas. De nödvändiga resurserna kan ordnas av ledningsgruppen, som är en grupp av individer på högsta ledningsnivå i en organisation som bedriver själva organisationen Ledningsgruppen har ett stort inflyttande på utgången av ett IT-projekt. Att få stöd från företagsledning har en påverkan om ett IT-projekt får tillgång till resurser som krävs. Ledningsstöd och engagemang är också viktigt för projektledaren och även att ledningen inte hindrar projektledaren att hantera och genomföra projektet.

I genomförandefasen bör även användarna medverka för att få en hög acceptans för IT- projektet. Att få hög acceptans kan ske genom att användarna får vara med i utvecklingsarbetet och påverka projektet. Det brukar ske att personer som medverkar i projektet inte har kunskap om IT-projekt, vilket leder till varierande resultat. Det finns problem med att användare inte vill medverka i, eller medverkandet är på ett ineffektivt sätt. Projektet kan anses som misslyckat om det får motstånd av användarna och inte används.

I projektlivscykelns sista fas avslutas projektet. Innan projektet kan beräknas om avslutat bör man gå igenom ett par punkter för att bekräfta att alla krav är uppfyllda och rätt resultat levereras till kunden samt att kunden/användaren är nöjd med IT-systemet. En analys ska också göras för att se hur projektet gick, vad som gick mindre bra, vad som kan förbättras och vilka erfarenheter man kan ta med sig till näst kommande projekt.

(23)

18

Tabell 2 Sammanfattning av projektlivscykeln

Förstudiefas Vad?

• Samla in information om projekt

• Utse projektledare

• Samla in krav

• Vem gör det?

• Oftast är det beställaren som har ansvaret för hela förstudiefasen, dock kan leverantören göra det tillsammans med beställaren

• Beställaren utser projektledare

Planeringsfas Vad?

• Projektgrupp skapas

• Projektplan skapas

• Projektplanen innehåller: budget, tidsplan, kommunikationsplan och risk plan.

Vem gör det?

• Projektledaren skapar projektgrupp och väljer ut lämpliga personer för projektet

• Projektledaren tillsammans med projektgruppen skapar en projektplan.

Genomförandefas Vad?

• Utveckla IT-system

• Skaffa fram nödvändiga resurser

• Ledningsstöd för projektet

• Involvera användarna i projektet.

Vem gör det?

• Projektledaren tillsammans med projektgruppen utvecklar IT- system

• Projektledaren ser till att projektet får tillgång till resurser.

• Det är ledningsgruppen som har tillgång till de nödvändiga resurserna.

• Beställaren involverar användarna i projektet

Avslut Vad?

• Projektanalys

• Lämna över IT-system

• Arkivera allt dokument berörande IT- projekt

Vem gör det?

• Leverantören lämnar över IT-system till beställaren

• Projektledaren analyserar projektet

• Projektledaren arkiverar allt dokument

(24)

19

Kapitel 2.6 handlar om tidigare studier om misslyckade IT-projekt. Tabell 3 utgör en sammanställning av alla faktorer som kan ha orsakat att små IT-projekt misslyckats.

Utifrån studiens syfte och frågeställningar har relevant litteratur använts och redovisat här i kapitel 2. I litteraruten har ett antal olika faktorer upptäckts som har orsakat att små IT-projekt misslyckats. Samtliga faktorer kommer användas senare för att formulera en intervjuguide (kapitel 3.1).

Tabell 3 Sammanställning av identifierade faktorer som kan ha påverkat att små IT-projekt har misslyckats Studie

1:

Würte mberg et al.

(2011)

Riskanal

ys Projektl

edarens erfarenh et

Kommuni kations brister med användarn a

Ledning

sstöd Kravförä

ndringar Intern kommuni kation

Projektöv ervaknin g

Sena förändrin gar i kraven

Vag kravsp ecifikat ion

Studie 2:

Verner et al.

(2008)

Projektl edare fick inte full befogen het att hantera projektet

Ingen metod för kravinsa mling

Leveransb eslut fattades inte med lämplig kravinfor mation

Projektle dare hade ingen inmatnin g i projektu ppskattn ing

Personal som inte belönades för att arbetat långa timmar

Projektle daren kontroller ade inte projektet

Projektet var inte tillräcklig t bemannat

Beställar en deltog inte vid projektup pskattnin g

Projekt unders kattnin g

Utvecklar na deltog inte vid projektup pskattnin g

Aggressivt projektschem a påverkade projektgruppe ns motivation

Leveransda tum påverkade utvecklings processen

Studie 3:

Dumitr escu et al. (2014)

Brist på ledarska p

Svag riskhant ering

Ledningsst

öd Använda

rna deltog inte i projektet från början till slutet

Brister för förståelse av affärsproc essens komplexit et

Studie 4:

Sudhak ar (2016)

Dålig projektp lanering

Oklara projekt mål

Olämplig projektupp skattning

Brist på lednings stöd

Brist på engagema ng från ledning

Brist på riskhante ring

Orealistis kt tidschem a

Brister i projekto mfattning

Projekt ledaren s metode r

Ineffektiv kommuni kation

Vaga krav