de skulle kunna komma med förslag om hur ledningssystemet ska se ut och fungera. Det går tyda att tidsbristen var en avgörande orsak till att användarmedverkan uteslöts. Enligt min åsikt borde användarmedverkan ha ägt rum. Vad beträffar projekt C, anser jag att användarmedverkan inte var nödvändigt eftersom Tonys förklaring upplyser om att det var ett färdigt system i grund och botten som enbart skulle anpassas efter kommande TV-sänding.
5.7 Avslut
Någon överlämning av projekt D förekom ej eftersom det enbart var prototyp. Enligt Patrik blev resultatet till en viss del lyckat. Även i projekt C förekom inte en överlämning av projekt. Enigt Tony skedde inte överlämning eftersom själva systemet ägdes av de själva och inte skulle lämnas över till beställaren. Enligt Tony blev inte beställaren nöjd med projektet eftersom missförstånd på förväntningar förekom. I projekt B förekom inte heller en överlämning av IT-projekt. Jons svar tyder att systemet skrotades eftersom beställaren inte blev nöjd. Överlämning av projekt A hände genom att Julia tillsammans med beställaren gick igenom allting och en acceptanstest genomfördes där beställaren granskade och godkände IT-systemet.
En analys efter projekt D var avslutat genomfördes. En detaljerad slutrapport finns på CriseIT webbsida. Samtliga projektdeltagare tillsammans med projektledaren uträttade en slutrapport. Patrik påpekar bättre kommunikation och tydlighet som delprojektledare när det gäller förbättringspotentialer. Någon analys förekom inte vad beträffar projekt C. Enligt Tony är inte det förekommande med analys för små IT-projekt. I projekt B förekom ej en analys. Enligt Jon borde en analys genomföras för att ta lärdom av det misslyckade IT-projektet. En kort analys genomfördes i projekt A. Julias svar indikerar på att en analys genomfördes eftersom näst kommande projekt skulle vara av samma slag. Analysen gjordes av projektledaren tillsammans med projektgruppen. Julia säger att de lärdomarna som hon tar med sig är att lägga ner mer tid på riskhanteringsprocessen och inte underskatta ett litet IT-projekt.
Det tog cirka sex veckor för projekt A att fullbordas. Den ursprungliga planen var fyra veckor. Projektbudget överskred på grund av förseningar förekom i projektet. Enligt Julia är det viktigaste att beställaren till slut blev nöjd med projektet. Projektbudgeten för projekt C överskred inte. Däremot överskred projektbudget för projekt B. Jons förklararing är att tid och pengar konsumerades för ingenting eftersom kvalitén på systemet inte var duglig. Vad beträffar projektbudget för projekt D menar Patrik att den slutgiltiga budgeten inte överskred.
Avslutfasen är med för att komplettera hela projektlivscykeln samt få en djupare förståelse för respektive projekt. Genom avslutfasen har det varit möjligt att få ett bättre underlag för respektive projekt. Sista fasen kompletterar och förtäljer ytterligare information om projekten. Därav har frågor om avslut ställts också.
5.8 Sammanställning av kapitlet
Efter att ha undersökt projekt A, B, C samt D har ett antal faktorer identifierats som kan ha orsakat att IT-projekten misslyckats. I projekt A har huvudfaktorn projektplan identifierats som en orsak till att projektet misslyckats. Vidare i projekt B har fem huvudfaktorer haft inverkan på projekt B, dessa fem är kravspecifikation, projektledare, projektgrupp, projektplan och
59
användarmedverkan. Därefter i projekt C framkommer det att kravspecifikation orsaka att projektet misslyckades. Sist när det gäller projekt D så har projektplan orsakat att projektet fick ett misslyckat resultat. Dessa sammanfattningar finns sammanställda i Tabell 5.
Tabell 5 Sammanställning av faktorer som kan ha orsakat projekt misslyckanden
Projekt: Kravspecifikation Projektledare Projektgrupp Projektplan Ledningsgrupp Användarmedverkan
A X
B X X X X X
C X
60
Slutsatser
Slutsatsen sammanbinder analysen med teorin. Syftet med uppsatsen uppfylls och undersökningsfrågorna besvaras.
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.
Nedan besvaras studiens undersökningsfrågor i tur och ordning.
U1: Vilken eller vilka orsaker bidrog till att var och en av de fyra små IT-projekten misslyckades?
Projekt A
Huvudfaktorn krav kan inte bedömas ha haft påverkan på projekt A. Även om en kravspecifikation inte förekom i projektet. Under intervjun med Julia har det framkommit att styrandet av IT-projekt gick väl till även om det inte fanns en kravspecifikation. Jag anser att anledningen till att krav inte har påverkat just projekt A beror på att det var en migreringsprojekt. Julia har också nämnt att det var för få krav som skulle uppfyllas. En projektmedlem som representera beställaren hade kännedom över de krav som skulle verkställas.
Huvudfaktorn projektledare anses inte ha orsakat att projektet fick ett misslyckat utfall. Det förekom brister i den tekniska kompetensen, för Julia var det svårt att begripa vissa tekniska aspekter. Däremot själva styrandet av projektet gick bra till. Dessutom höll projektledaren en bra kommunikationsdialog med projektgruppen när fel uppstod.
Huvudfaktorn projektgrupp kan inte bedömas som en orsak till projekt misslyckanden. Av Julias svar går det bedöma att projektgruppens kunskap samt erfarenhet var bra. Projektledaren utvalde de personer som har haft kunskap och erfarenhet och jobbat med projekt som denna tidigare. Projektgruppen var också engagerad att delta i projektet. Det enda som brast var kommunikationsdialogen.
Huvudfaktorn planering kan bedömas ha haft en inverkan på IT-projektet. I projektplanen fanns en tidsplan, kommunikationsplan och även en riskhanteringsplan. Det förekom brister i det sistnämnda planen. Min bedömning är att alldeles för få risker identifierades kring projektet. Även Julia anser att mera tid borde ha ägnats åt riskhantering. Julia och projektgruppen underskatta projektet till en viss del, de trodde inte att ett litet IT-projekt kunde innehålla många risker. Det förekom förseningar i projektplanen redan i början av genomförandefasen. Dessa förseningar berodde på icke förutsedda risker som dök upp.
Huvudfaktorn ledningsgrupp kan inte bedömas som en orsak till att projektet misslyckades. Projektet fick inte stöd av ledningsgrupp eftersom en ledningsgrupp existera inte. Men ändå anser jag att en ledningsgrupp inte behövdes för ett projekt som detta. Enligt min mening även om en ledningsgrupp skulle finnas så hade inte det hjälpt projektet eftersom felet inte var grundad på en saknad ledningsgrupp.
61
Huvudfaktorn användarmedverkan bedöms inte ha orsakat IT-projektet. Tio användare medverka i projektet. Vissa användare var engagerad att medverka i projektet medan andra inte var det. Även variation förekom i användarnas kunskap att medverka i projektet. Men jag anser att användarmedverkan inte har påverkat projektet på ett negativt sätt.
Projekt B
Projektledare kan också haft en inverkan på projektet på ett negativt sätt. Enligt min bedömning har projektledaren orsakat att projektet misslyckats. Projektledaren tog inte projektet på allvar och underskattning förekom. Projektledaren skapade varken en kravspecifikation eller en projektplan. Jon har också medgett att på grund av tidsbrist och för att det var ett litet IT-projekt så ville han fixa det hela snabbt utan några officiella dokument. Därav bedömare jag att huvudfaktorn projektledare har orsakat projektet.
Krav kan ha orsakat att projekt B misslyckades. Under intervjun med Jon blir det uppenbart att projektet inte hade en kravspecifikation. Det framgår att Jon inte visste om beställarens förväntningar eftersom det inte fanns en kravspecifikation. Även en förstudie uteslöts på grund av tidsbrist. Jon fastslår att en kravspecifikation borde ha formulerats. Jag anser också att en kravspecifikation borde ha skapats.
Huvudfaktorn projektgrupp kan också anses ha orsakat att projektet misslyckat. Engagemang förekom icke i projektet. Den andra projektmedlemmens engagemang för projektet inte var bra. Kommunikationsbrister förekom också.
Huvudfaktorn projektplan bedöms som en bidragande orsak till att projektet misslyckades. Det råder inget tvivel om att en projektplan saknades i projektet. På grund av tidsbrist och projektunderskattning så upprättades inte en projektplan. Jon har bekänt att en projektplan borde ha skapats.
Huvudfaktorn ledningsgrupp kan ej bedömas ha orsakat att projektet misslyckats. Det förekom inte en ledningsgrupp för projekt B. Jons åsikt är att en ledningsgrupp inte var nödvändigt för detta projekt. Även om projektet skulle få stöd av en ledningsgrupp så hade inte det spelat roll eftersom problemet berodde på projektunderskattning.
Huvudfaktorn användarmedverkan kan bedömas ha orsakat projekt B. I detta projekt någon medverkan av användarna förekom ej. Enligt Jon borde användare medverkat i projektet eftersom de kunde ha förbättrat användbarheten för ledningssystemet genom att komma med förslag om hur systemet ska se ut och fungera. Tidsbristen var också en avgörande orsak till att användarmedverkan uteslöts. På dessa grunder anser jag att användarmedverkan kan ha orsakat.
Projekt C
Huvudfaktorn projektledare kan inte bedömas ha haft inverkan på projektet. Projektledarens ledarskapsförmåga var goda. Jag anser att projektledarens sociala och tekniska kompetens var också bra. Även kommunikation och samspel i projektet var positivt. Därav anser jag att projektledare inte har haft en påverkan.
62
Huvudfaktorn krav enligt min bedömning kan ha orsakat att projekt C misslyckats. Det framgår att missförstånd på förväntningar mellan leverantör och beställare har inträffats. Kravspecifikationen var inte alldeles för tydligt. I kravspecifikationen förekom inte acceptanskriterier, enligt Tony borde även acceptanskriterier finnas med eftersom det hade klargjort beställarens förväntningar. Jag anser också att acceptanskriterier borde ha skapats. På dessa grunder anser jag att kravspecifikation kan ha orsakat att projektet misslyckats.
Huvudfaktorn projektgrupp kan inte anses ha påverkat IT-projektet negativt. Projektgruppens engagemang var högt enligt Tony. Gruppen besatt de kunskaper och erfarenhet som krävdes för att kunna delta i projektet. Även kommunikationsförmågan inom projektet höll en bra nivå. Under intervjun har inte Tony nämnt något som kan betraktas att projektgruppen kan ha påverkat projektet negativt. Därav anser jag att projektgrupp inte har påverkat.
Huvudfaktorn planering kan inte anses ha orsakat att projektet misslyckats. Det har framkommit att projektplanen har innehållit en tidsplan och en kommunikationsplan. Någon riskhanteringsplan har ej förekommit. Däremot diskussioner kring risker har ägt rum. Under diskussionerna har risker antecknats ner, dock har inte en konkret riskhanteringsplan uträttats. Huvudfaktorn ledningsgrupp bedöms att inte har orsakat att projektet misslyckats. Det har inte existerat en ledningsgrupp för projekt C. Enligt respondenten behovet av en ledningsgrupp inte var nödvändigt eftersom det var ett litet IT-projekt. Jag anser att även om projekt C skulle omfatta av en ledningsgrupp så hade det ändå inte hjälpt projektet. Felet vilade inte på en saknad ledningsgrupp utan på förväntningar.
Huvudfaktorn användarmedverkan anses inte ha haft en inverkan på projektet. Av respondentens svar är det möjligt tolka att systemet inte behövde medverkan av användarna eftersom det var ett färdigt byggt system som inte skulle samla in användarnas synpunkter. Av den anledningen är min bedömning att en frånvarande medverkan av användare inte har orsakat projektets utfall.
Projekt D
Huvudfaktorn projektledare bedöms inte ha orsakat projektet. I detta projekt fanns en huvudprojektledare samt fyra delprojektledare. Under intervjun har fokus varit riktat mot huvudprojektledaren. Det har framkommit att projektledarens ledarskapsförmåga var lysande. Dessutom var Projektledarens tekniska kompetens bra eftersom det inte var första gången för den personen att bedriva ett projekt av samma slag. Även samspel och kommunikation mellan projektgrupp och projektledare var utmärkt. Därför har jag bedömt att projektledaren inte har påverkat projektet.
Vad beträffar huvudfaktorn krav så kan inte det bedömas ha orsakat projektet. Det förekom en kravspecifikation som utgjorde en beskrivning om hur prototypen skulle se ut och fungera. Det har gjorts ett antal förstudier med intervjuer för att samla in krav. Krav har också prioriterats. Dessutom har acceptanskriterier förekommit i kravspecifikationen. Av respondentens svar har jag kommit till den slutsatsen att krav inte kan ha påverkat att projektet misslyckats.
Huvudfaktorn projektgrupp kan inte anses ha haft en inverkan på projektet. Under intervjun har frågorna ställts om projektgruppen som utveckla själva prototypen. Projektgruppens kunskap
63
och erfarenhet förblev goda. Lysande kommunikations aktivitet och engagemang existerade i projektgruppen. Därav anser jag att huvudfaktorn projektgrupp inte har orsakat projektet. Huvudfaktorn projektplan kan bedömas ha påverkat projektet. En upprättad övergripande projektplan förekom. Dessutom fanns fyra delprojektplan för respektive delprojekt. Det var projektgruppen tillsammans med delprojektledarna samt huvudprojektledaren som skrev samtliga projektplan. Under intervjun har frågor ställts om den övergripande projektplan. Utrymme för tidsplan och kommunikationsplan har funnits i projektplanen. Någon typ av riskhantering har också återfunnits. Men av respondentens svar har jag tolkat att alldeles för få timmar har spenderats åt riskhantering. Och det är riskhanteringen som jag anser kan ha orsakat att projektet misslyckats. Om mera tid hade ägnats åt riskhantering så kanske skulle det upptäckts nackdelarna med CMS miljö för krisövning. Patrik svar tyder att från början har ett CMS- system valts för prototypen, men det har inte fungerat som det skulle. Därför lades prototypen ner och sen togs det upp igen i CriseIT2 igen, men denna gång valdes LMS miljö i stället. Därför är min slutsats att mera tid borde ha ägnats åt riskhantering.
Huvudfaktorn ledningsgrupp enligt min bedömning kan inte ha orsakat projektet. Ledningsgruppen var engagerad i projektet och utförde en massa arbete. Ledningsgrupp har varken hindrat delprojektledarna eller huvudprojektledaren att hantera projektet. Projektet har också fått nödvändiga resurser. Dessutom fanns en referensgrupp som fungera som ett stöd för projektgruppen. Därför anser jag ledningsgrupp inte har påverkat projektet.
Huvudfaktorn användarmedverkan bedöms inte ha orsakat projektet. Användarnas kunskap varierade. Många gånger var de experter på själva övningsdelarna, men det var inga som var nybörjare på datorovana direkt. Engagemang för att delta i projektet förekom. Det fanns också en kommunikationsdialog mellan projektgruppen och användare. Projektgruppen fick ofta respons av användarna gällande prototypen. Planeringsdelen fick inte acceptans av användarna. Brister förekom i användbarheten i att planera en övning. Prototypen var alldeles för tungrodd för användning.
U2: Finns det gemensamma orsaker mellan de fyra små IT-projekten som har misslyckats? Krav är en gemensam faktor som har orsakat både projekt B och C. En kravspecifikation förekom ej i projekt B, vilket ledde till misslyckat utfall eftersom beställarens förväntningar inte kunde förverkligas. I projekt C framgår det att kravspecifikationen inte var tydligt. Missförstånd mellan beställare och leverantör inträffades eftersom kraven inte var tydliga. Kravspecifikationen innehöll inte heller acceptanskriterier, vilket borde ha inkluderats eftersom det hade underlättat beställarens förväntningar.
Huvudfaktorn projektplan kan ha orsakat projekt A, B samt D. I projekt A framgår det att riskhantering inte skötes noggrant. Det framgår också att det berodde på projektunderskattning eftersom projektledaren inte trodde att ett litet IT-projekt kunde vara omringad av flertals risker. Projektplan saknades i projekt B. På grund av tidsbrist och projektunderskattning så uteslöts en projektplan. Vad beträffar projekt D, jag anser att det berodde på vag riskhantering. Om mer tid hade ägnats åt riskhantering så kanske skulle det upptäckas tidigare nackdelarna med ett CMS-miljö just för krisövning.
64
U3: Hur kunde respektive IT-projekt fått ett mer lyckat utfall?
Projekt A
Det är viktigt att inte underskatta ett litet IT-projekt. På grund av projektunderskattning så brast det i riskhanteringsprocessen. Jag anser att mer tid borde ha ägnats åt riskhanteringsprocessen. Projektgruppen borde kanske ha undersökt tidigare projektet av samma slag för att en bättre bild över de risker som vilade över projektet.
Projekt B
Beträffande projekt B, anser jag att en projektplan borde ha uträttats eftersom projektplan fungerar som ett underlag för projektet. Utan en plan blir det svårare att bedriva ett projekt. En kravspecifikation borde också ha formulerats. Det framgår att beställarens förväntningar inte kunde uppfyllas eftersom det inte fanns en kravspecifikation. Krav är helt enkelt önskemål, något som beställaren vill ha. Men utan en kravspecifikation blir det svårare att uppfylla det eftersom det inte finns adekvat beskrivning över de krav som ska uppnås. I genomförandefasen borde även användare medverka i projektet. Dock någon medverkan från användare förekom inte i projektet. Användare som medverkar i ett projekt kan komma med respons om kommande system. Det är ändå i slutändan användarna som ska använda projektet och därför är det viktigt att användare deltar i projektet och ger sina synpunkter om IT-systemet. Det framgår att även projektgruppen inte var engagerad för projektet. En mera engagerad projektgrupp ökar välgången för projektet. Jag anser att det är till en viss del projektledarens uppgift att motivera och hålla projektgruppen engagerad. Till sist anser jag att det är viktigt att projektledaren styr projektet med goda ledarskapsförmågor. Den personen borde vara engagerad för projektet. Jag bedömer att projektledaren var varken engagerad eller lede projektet regelrätt. Projektledaren borde ha skapat en projektplan en kravspecifikation, engagera sin projektgrupp samt arrangera så att användare medverkar i projektet. Allt detta skede på grund av att projektledaren underskatta projektet.
Projekt C
I detta projekt borde en tydligare kravspecifikation ha åstadkommits. Det framgår att missförstånd på förväntningar mellan beställare och leverantör har inträffats. Även acceptanskriterier borde finnas med i kravspecifikationen. En tydligare kravspecifikation kunde ha uteslutit missförstånd på förväntningar.
Projekt D
Enligt mig mera tid skulle ha spenderats på att identifiera risker med projektet. Om tillräckligt med tid hade ägnats åt riskhantering, förmodligen skulle det upptäckas nackdelarna med ett CMS system just för detta IT-projekt. Det är också viktigt att betona att detta var en prototyp som gick ut på att undersöka om CMS miljö var passande för krisövning. Ändå anser jag att riskerna med projektet borde tas hand om bättre.
65
Omnämnande
Jag vill tacka respondenterna för sin medverkan. Utan er hade inte denna undersökning varit möjlig att genomföra. Jag vill även tacka min handledare Katarina Groth Jansson som har ledsagat mig igenom skrivandet av denna rapport.
66
Referenser
Allwood, M. (2011). En liten lathund om kvalitativ metod med tonvikt på intervju.
https://studentportalen.uu.se/uusp-filearea-tool/download.action?nodeId=459535&toolAttachmentId=108197 [2020-08-12] Andersson, H. (2021). Välkommen till Ozlab. https://www.kau.se/ozlab [2021-05-05] Arving, C. (2012). Tre exempel på hur man kan beskriva sin kvalitativa dataanalys.
https://studentportalen.uu.se/uusp-filearea-tool/download.action?nodeId=1100168&toolAttachmentId=214739 [2020-11-21] Dalen, M. (2008). Intervju som metod. 1.Uppl. Malmö: Gleerups utbildning. Danielsson, L. (2017a). Därför misslyckas projekt fortfarande.
https://computersweden.idg.se/2.2683/1.686551/darfor-misslyckas-projekt-fortfarande [2020-04-19]
Danielsson, L. (2017b). 9 sätt att sabba projekt med internpolitiskt käbbel.
https://computersweden.idg.se/2.2683/1.674542/9-projekt-intern-politik [2020-11-30] Danielsson, L. (2018). Se varningssignalerna innan projektet kraschar.
https://cio.idg.se/2.1782/1.698024/kraschade-projekt [2020-05-25] Danielsson, L. (2019). 10 tvärsäkra sätt att misslyckas på it-avdelningen.
https://computersweden.idg.se/2.2683/1.684682/it-avdelningen-misslyckas?queryText=kravspecifikation [2020-06-10]
Dumitrescu, F. Prodan, A. & Stoica, M. (2014). Implementing small & medium IT projects in small & medium enterprises. https://ideas.repec.org/a/cmj/networ/y2014i3p45-53.html [2020-10-02]
Elner, F. & Ravn, A. (2010). Motivationsteori inom projektarbete. Kandidatuppsats. Stockholm: Kungliga Tekniska Högskolan.
https://www.diva-portal.org/smash/get/diva2:490796/FULLTEXT01.pdf [2021-01-10]
Eriksson, U. (2008). Kravhantering för IT-system. 2. Uppl. Lund: Studentlitteratur AB. Eriksson, U. (2017). Project Failure – Common Reasons Why IT Projects Fail.
https://reqtest.com/agile-blog/common-reasons-projects-fail/ [2020-05-29]
Görling, S. (2009). Att arbeta med IT-projekt. 2.Uppl. Lund: Studentlitteratur AB.
Hughes, B. (2012). PROJECT MANAGEMENT FOR IT-RELATED PROJECTS. 2.uppl.UK: BCS Learning & Development Ltd.
Hedenborg, V. (2014). Polisens kritiserade IT-system avvecklas.
http://www.dn.se/nyheter/sverige/polisens-kritiserade-it-systemavvecklas/. [2021-01-11]. Holmstedt, M. (2009). Kravinsamling genom omvänd användarmedverkan. Kandidatuppsats. Karlstad: Karlstads universitet.portal.org/smash/get/diva2: 272397/FULLTEXT01.pdf [2021-01-11]
Karlstads Universitet. (2020). GDPR FÖR STUDENTER.