Avslut

har jobbat med Office 365. Därför skapades lathund om Office 365 som samtliga användare fick ta del av.

Karlsson och Duvsten (2004) skriver att det kan finnas problem med att användare som inte är engagerad att medverka i projektet eller medverkar på ett ineffektivt sätt. Vad beträffar användarnas engagemang i projekt A menar Julia att det varierade. Enligt Julia var en del användare engagerad och ställde frågor det märktes att de ville medverka i projektet. Medan somliga användare inte var så engagerad att delta i projektet. I projekt D menar Patrik att användarna var engagerad att medverka i projektet.

Författarna Karlsson och Duvsten (2004) påpekar också vikten av kommunikation mellan användare och projektgrupp. För att det kan uppstå skiljaktigheter vid samarbete mellan projektgruppen och användarna. Det är förekommande att användarna inte är alltid säkra på vad de vill ha utav IT-systemet och dem kan ha svårt att tolka informationen rätt som ges av projektgruppen. Kommunikationen mellan projektgruppen och användarna var goda enligt Julia. Respondenten förklarar att en av konsulterna som jobba i projektet representerar beställaren, vilket gjorde att användarna visste vem den personen var och det underlättade kommunikationen. I projekt D anser Patrik att kommunikationen mellan användarna och projektgruppen var bra. Möten med användarna med mellan rum ägde rum, och även digitala träffar har inträffat. Patrik menar att respons av användarna beträffande prototypen skede ofta. Santos (2014) skriver att ett IT-projekt kan anses som misslyckat om det får motstånd av användarna och inte används. Patrik menar att planeringsdelen inte fick acceptans av användarna. Det förekom brister i användbarheten i att planera en övning. Enligt Patrik var inte det lätt att använda prototypen eftersom det var alldeles för tungrodd. Projekt A fick acceptans av användarna. Julia säger att acceptanstester genomfördes för att kontrollera om användarna är nöjda och accepterar IT-systemet.

4.7 Avslut

I livscykelns sista fas avslutas projektet. Innan projektet kan beräknas som avslutat bör man kontrollera att alla krav är uppfyllda och beställaren är nöjd med IT-systemet. Det skede ingen överlämning i projekt D. Enligt Patrik blev det inte en riktigt överlämning av IKT-prototypen eftersom det enbart var en prototyp. Patrik nämner att beställare och leverantör var samma organisation. Dock anser Patrik att resultatet blev till en viss del lyckat. Även i projekt C förekom inte överlämning av IT-system. Tony menar att en överlämning inte skede eftersom tv systemet ägdes av de själva. Sist menar Tony att beställaren inte blev nöjd med projektet, detta berodde på missförstånd på förväntningarna. I projekt B förekom inte överlämning av IT-system. Enligt Jon berodde det på att systemet skrotades eftersom beställaren inte blev nöjd. Julia säger att överlämnandet av IT-projekt gick så till att hon tillsammans med beställaren hade ett möte där man gick igenom allting. Julia menar att det snarare var ett acceptansmöte där beställaren granskade och godkände IT-systemet.

Görling (2009, s.44) nämner att en analys bör göras för att se hur projektet gick; vad som gick mindre bra, vad som kan förbättras och vilka erfarenheter som man kan ta med sig till näst kommande projekt. I projekt D gjordes en analys efter projektet var avslutat. Det finns även en

50

detaljerad slutrapport. Patrik förtäljer att samtliga projektdeltagare tillsammans med huvudprojektledaren uträttade en slutrapport. Patrik påpekar bättre kommunikation och tydlighet som delprojektledare när det gäller förbättringspotentialer. I projekt C förekom inte en analys. Tony menar att det var ett litet IT-projekt och därför gjordes inte en analys efter projektavslut. Tony hävdar att analys inte är förekommande när det gäller små IT-projekt. I projekt B förekom inte heller en analys efter projektet var avslutad. Jon menar att han ville lägga det hela bakom sig eftersom resultatet blev misslyckat. Däremot medger Jon att nu i efterhand det borde ha gjorts en analys för att ta lärdom av det misslyckade IT-projektet. Julia menar att en kort analys genomfördes i projekt A. Anledningen till att det gjordes en analys berodde på att näst kommande projekt skulle vara av samma slag. Julia menar att analysen gjordes för att inte begå samma misstag två gånger. 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.

En analys av projektbudget bör också genomföras för att förstå om budgeten överskred eller om det var inom den angivna budgetramen (Projektledning 2018c). Julia menar att det tog cirka sex veckor innan projektet blev färdigt. Den ursprungliga planen var fyra veckor. Projektbudgeten överskred eftersom förseningar i projektet förekom. Julia poängterar att det viktigaste i slutändan är att beställaren blev nöjd med projektet. Projektbudgeten för projekt C överskred inte. Projektbudgeten för projekt B överskred också. Jon förklarar att tid och pengar konsumerades för ingenting eftersom kvalitén på systemet inte var god. Vad beträffar projektbudget för projekt D menar Patrik att den slutgiltiga budgeten inte överskred.

51

Slutsatsdiskussion

Detta kapitel omfattar en genomgång och diskussion av analyskapitlet.

5.1 Förstudiefas - Projektledare

Samtliga projekt hade en definierad projektledare. Enligt Görling (2009) kan rollen som projektledare se olika ut beroende på projektets karaktär. I projekt A var Julias roll enbart som projektledare. I projekt B var Jon projektledare och utvecklare. Projekt C var Tonys roll bara projektledare. Patriks roll i projekt D var delprojektledare. Patriks överordnad var huvudprojektledaren som hade ansvaret för hela projektet.

Vad beträffar projektledarens personal och tekniska kompetens finns det variationer mellan dessa fyra projekt. Julia anser att det förekom brister i den tekniska kompetensen. Vissa tekniska aspekter var det svårt för Julia att begripa. Men projektgruppen hjälpte till och gav henne råd när hon inte förstod. Däremot själva styrandet av projektet gick ganska bra enligt respondenten. Men när det gäller projektledarens kompetens för projekt B är det inte på topp. Jon har förklarat att kompetensen för själva projektledning var operativ. Men den sociala kompetensen lede till att projektet inte togs på allvar. Respondenten har en bra relationen med beställaren vilket gjorde att projektet inte togs på allvar. Projekt storleken påverkade också att projektet underskattades. Respondenten Tony tycker att hans kunskap och erfarenhet för projekt V var bra. Respondenten har tillagt att har jobbat med likande projektet tidigare, särskilt projekt som berör tv-system. I projekt D tycker Patrik att projektledarens erfarenhet och kunskap var goda. Det var inte första gången för projektledaren att styra forskningsprojekt.

Ledarskapsförmågan för projekt A var ganska bra och styrandet av projektet gick ganska bra till enligt Julia. Däremot förekom inte ledarskapsförmåga för projekt B. Respondenten menar att han har ledarskapsförmåga IT-projekt och där funkade allting bra. Ledarskapsförmågan var goda rörande projekt C. Det var inte första gången för Tony att bedriva IT-projekt. Tony att inta rollen som projektledare. Att vara lyhörd och ta hänsyn till vad projektgruppen har att säga och även fatta beslut tillsammans med projektgruppen är viktigt enligt Tony. Huvudprojektledarens ledarskapsförmågor var utmärkta anser Patrik. Huvudprojektledaren delegerade arbetet nedåt mot delprojektledarna.

Samspel och kommunikation i projekt D var lysande. Det funkade bra att jobba med projektledaren eftersom den personen var lyhörd. Projektledaren litade på delprojektledarnas arbetssätt. Julias samspel och kommunikation inom projektet var ganska. Julia höll ett bra kommunikationsflöde med projektgruppen, särskilt när fel uppstod. Däremot förekom problem med kommunikationen från projektgruppens sida. I projekt C funkade samspel och kommunikation bra. Tony jobba nära med projektgruppen. Fördelen med det är att samspel och kommunikation blir väldig god. Det framkommer att kommunikation och samspel i projekt B inte var bra. Enligt Tony kunde det hända att den andra personen i projektet försvann vilket medförde att Jon blev ensam i projektet. Respondenten tillägger att projektets storlek var avgörande, att det var ett litet projekt som lede till projektunderskattning.

52

Jag anser att huvudfaktorn projektledare har haft inverkan på projekt B. Projektledaren för projekt B har underskattad projektet vilket har medfört att projektet har misslyckat. Vad gäller projekt A, C och D bedömer inte jag att huvudfaktorn projektledare har haft inverkan på de nämnda projekten.

5.2 Förstudiefas - Krav

Projekt A bedrevs utan en kravspecifikation. Respondenten Julia anser att det inte var nödvändigt med en kravspecifikation. Projektet hoppade direkt in i planeringsfasen och jobbade utifrån planeringsfasen. En snabb förstudie genomfördes under planeringsfasen där två konsulter undersökte beställarens tidigare system för att få en förståelse. Julias svar tyder på att detta projekt var möjligt att bedriva utan en kravspecifikation. Det var inte alldeles för många krav som skulle uppfyllas eftersom det var en migreringsprojekt. En av konsulterna jobbade för beställaren vilket innebar att den personen visste vilka krav som skulle uppfyllas. Julia fastslår att en kravspecifikation inte var nödvändigt för just detta projekt. Även projekt B sakna en kravspecifikation. Projektet misslyckades på grund av att det inte fanns en kravspecifikation enligt Jon. En kravspecifikation uträttades inte eftersom Jon och beställaren verkade ha en bra bild över vad som skulle göras. En förstudie uteslöts också på grund av tidsbrist. Enligt Jon det största problemet att jobba utan en kravspecifikation är hantering av kundens förväntningar. Jon menar att de inte visste hur IT-systemet skulle se ut eller vilka extra funktioner som skulle vara tillgängliga. Jon fastslår att en kravspecifikation borde formulerats.

Projekt C innehöll en kravspecifikation. Fastän kravspecifikationen inte var väldig tydligt. Otydligheter i förväntningarna var det som gjorde att projektet misslyckades. Enligt Tony förekom missförstånd mellan beställare och leverantör när det gäller förväntningar, vem som ska göra vad. Projekt D omfattades av en kravspecifikation. Kravspecifikationen utgjorde en beskrivning om hur prototypen skulle fungera och se ut. Enligt respondenten valdes ett CMS system för IKT-prototypen.

I projekt C krav samlades in genom möten. Tony tillsammans med beställaren hade kontinuerliga möten där diskussionsämnet handla om krav. I projekt D skedde insamling av krav genom en förstudie med fokus på intervjuer. Men även en studie med hjälp av systemet Ozlab genomfördes för att undersöka användarnas önskemål.

I projekt C Tony tillsammans med beställaren samla in och skapade kraven. Medan projekt D var det själva projektgruppen som tog hand om förstudiefasen och skapelsen av krav. Beställare och leverantör var en och samma organisation.

Krav i projekt C prioriterades löpande under hela projektets gång och det som inte behövdes i slutet av arbetet prioriterades bort. Prioritering av krav förverkligades även i projekt D. Någon prioriteringsteknik förekom icke i projekt C, det var snarare diskussioner med beställaren om vilka krav som skulle bort prioriteras. Däremot en variant av MoSCow metoden applicerades i projekt D för prioritering utav krav.

Det råder inget tvivel om att kravspecifikationen i projekt C inte innehöll acceptanskriterier. Tonys åsikt är att kravspecifikationen borde även innehålla acceptanskriterier eftersom det hade underlättar beställarens förväntningar. Däremot projekt D omfatta av acceptanskriterier.