”Vad är kundnöjdhet?” - En studie om hur systemutvecklare sammankopplar behov och förväntningar i en agil process

Kandidatuppsats 15 hp Företagsekonomiska institutionen Uppsala universitet VT 2017

Datum för inlämning: 2017-06-01

Isak Kabir Maja Engvall Handledare: Anna Bengtson

Sammanfattning

I denna undersökning studeras vilka metoder systemutvecklare tillämpar för att hjälpa kunden att

förstå vad deras behov och önskemål är i ett agilt systemutvecklingsprojekt. Syftet är att bidra

till ökad förståelse för vad kundnöjdhet utgör. Genom att studera hur konsulter sammankopplar

kunders behov och förväntningar, menar Kano Noriaki (1984) att kundnöjdhet uppnås. För att

kunna undersöka vilka metoder som ligger till grund för förståelsen av behov och efterfrågan har

teorier kring agil utveckling kompletterats med teorier inom kommunikation och kundnöjdhet i

form av en undersökningsmodell. Studien baserades på kvalitativa intervjuer med tre IT-

konsultföretag inom systemutveckling. Resultatet tyder på att förtroendeskapande, laborativt

skapande av kravspecifikation, motkrav, tillgänglighet och flexibilitet är metoder som de

konsulterna använder i olika utsträckning inom företagen. Kundnöjdheten utvärderas främst med

fokus på kvantiteten av antalet uppfyllda krav, medan vissa tillämpar en kvalitativ undersökning

som fokuserar på huruvida kunden skulle rekommendera företaget till någon i deras nätverk.

1

Innehållsförteckning 1 Inledning 2

1.1 Problematisering 31.2 Syfte 41.4 Avgränsning 4

2 Teori 52.1 Hur uppnås kundnöjdhet? 52.2 Agil utveckling 62.3 Kravspecifikation 72.4 Lära känna kund 82.5 Kunddialog 82.6 Hantering av barriärer mot kund 92.7 Utvärdera kundnöjdhet 92.8 Undersökningsmodell 10

3 Metod 133.1 Tillvägagångssätt 133.2 Val av företag 133.3 Intervjuer 143.4 Analys av kvalitativa data 163.5 Övriga källor 163.6 Källkritik 16

4 Empiri 184.1 Bakgrund 184.2 Agil utvecklingsprocess 184.3 Lära känna kund 204.4 Kravspecifikation 214.5 Kunddialog 234.6 Hantering av barriärer mot kund 244.7 Utvärdera kundnöjdhet 26

5 Analys 285.1 Företagsanalys 285.2 Komparativ analys 36

6 Slutsats 437 Avslutande diskussion och vidare forskning 438 Källförteckning 469 Appendix 52

9.1 Bilaga 1 - Intervjuguide 52

2

1 Inledning

Behovet av digitala tjänster har vuxit i takt med att organisationer önskar att automatisera och

datorisera sina interna processer i allt större utsträckning. Många organisationer tar därför hjälp

av konsulter vars uppdrag är att tillföra den IT-kompetens som efterfrågas för att uppnå den

önskade digitaliseringen. I takt med att efterfrågan på IT-konsulter ökar, växer även konkurrensen

mellan systemutvecklingsföretag fram. Detta leder till att systemutvecklare lägger mycket

resurser på att bibehålla kunder genom att skapa kundnöjdhet. Johansson (2007, 110) menar att

förståelsen av kundbehov utgör nyckeln i ett lyckat projekt och för att uppnå kundnöjdhet. Det

vill säga att kunden är nöjd med slutprodukten utifrån givna förutsättningar som enbart kan

uppnås i de fall där förväntan på produkten överensstämmer med kundens egentliga behov

(Project Smart, 2014).

För att förstå vad en kund önskar, krävs det därmed att systemutvecklaren förstår kundens

behov. Wheatcraft (2013) menar att det utgör en svårighet för vissa konsulter att förstå kundens

behov, eftersom en del kunder inte vad de vill ha förrän dem har sett resultatet. Dessa kunder kan

uttrycka sig i stil med: “Visa mig några stenar, så kommer jag berätta för dig vilken sten som är

den rätta!”. Det finns därmed en risk att det som efterfrågades inte alls var vad de i själva verket

menade eller ville ha. Även John McNeece som var designer av kryssningsfartyg menade att det

finns svårigheter i att identifiera kundens behov och nämnde i en tidningsartikel att “...om Henry

Ford frågade människor huruvida han skulle bygga en bil, skulle de förmodligen säga åt honom

att de helst velat ha en snabbare häst.” (Miller, Greg. 1999).

Därmed använder systemutvecklare sig utav kravspecifikationer för att specificera

kundens önskemål och behov. Kravspecifikationer är ett sätt att förstå en kunds behov genom att

översätta behoven i skriftliga krav (“systemet skall…”). Däremot är dessa krav oftast inte

tillräckliga för att möta kundens behov. Johansson (2007,110) menar att kunden kan ha

svårigheter med att initialt identifiera sina behov, vilket kan resultera i att dem levererar en tom

kravspecifikation till systemutvecklaren. Det finns även situationer där kunden levererar en till

synes komplett kravspecifikation, men som inte uppfyller kundens behov.

Problematiken enligt Gottesdiener (2007) grundar sig i att kundkrav inte alltid är påtagligt

och konkret för att kunna skrivas ner samtidigt som det krävs en del ansträngning och skicklighet

att urskilja, analysera och kontrollera kraven. Skriftliga krav har en viss poäng när det gäller

formella specifikationer, men däremot skildrar de sällan kundens behov ur ett effektivt och

holistiskt perspektiv. Detta menar Tsui et al. (2014) beror på arbetsprocesser inom

utvecklingsbranschen har under lång tid präglats av traditionella metoder.

3

Gemensamt för dessa traditionella metoder är bland annat strikt dokumentering och behov

av väldefinierade krav. Beath & Orlikowski (1994) menar även att de traditionella metoderna inte

fokuserar på att involvera kunden i utvecklingen, vilket är en väsentlig del för att öka nivån av

kundnöjdhet. Pikkarainen et al. (2008) belyser samtidigt att involvering av kund innebär en

komplikation och ett dilemma för systemutvecklaren, i form av till vilken grad kommunikation

och interaktion ska skapas och upprätthållas med kunden.

År 2001 skapades därför principerna Agile Manifesto (Agile Maniefesto, 2001) där 17

ingenjörer uppmärksammade bland annat ovanstående som en brist hos de traditionella

metoderna. De belyste att de traditionella metoderna bidrog till en alltför byråkratisk

dokumentation och bundenhet vid orealistiska projektplaner och förespråkade istället iterativa

metoder som med utökat kundfokus går under namnet “Agila metoder”. Inom agila metoder

förespråkas istället interaktioner framför processer och omfattande dokumentation som i sin tur

genererar flexibilitet. Fokus på kundinvolvering framför förhandling av kontrakt är ytterligare en

aspekt som är viktig enligt det agila manifestet. Detta leder i sin tur till ökad sannolikhet att

uppfylla kundens önskemål (Beath och Orlikowski, 1994).

1.1 Problematisering

Enligt företaget Version-One (2013) som arbetar med agil metodutveckling, använder sig 65–

90 procent av systemutvecklingsföretagen i Europa och USA idag av agila metoder, men i de

flesta fall är kundinvolverandet inte högt prioriterat. Detta kan vara ett resultat av att

kundinvolverandet inom det agila forskningsområdet inte har studerats lika djupgående. En

motsättning kan identifieras i att företag å ena sidan förespråkar kundinvolvering genom att

tillämpa agila metoder, men å andra sidan inte väljer att involvera kunden i lika hög grad.

Många kunder tenderar att initiera projekt med avsaknad av tydliga behovsramar

(Goldkuhl 1993, 23). Samtidigt menar Zeithaml & Bitnér (2002) vikten av att identifiera

kundens behov under utvecklingsprocessen i syfte att uppnå kundnöjdhet. Studier har tidigare

genomförts gällande kundinvolvering generellt inom projekt för utvecklande av

informationssystem, kopplat till antingen “kundnöjdhet” (Mann och Maurer, 2005) eller

“kundkommunikation" (Korkala et al. 2009). Däremot belyser studierna och övrig forskning

inte kombinationen av att studera hur systemutvecklingsföretag arbetar med kunden i syfte att

vägleda dem till att förstå deras behov hos slutprodukten med den agila processen som ramverk.

Denna utredning berör därmed ett annorlunda perspektiv och kan ge ytterligare underlag till

kundinvolveringens effekt inom agil systemutveckling.

4

1.2 Syfte

Syftet med studien är att bidra till ökad förståelse för vad kundnöjdhet är och undersöka vilka

metoder konsulter tillämpar för att hjälpa kunden att förstå deras egentliga behov i

systemutvecklingsprojekt. Det vill säga att kundens vilja, förväntan och efterfrågan av IT-

system överensstämmer med kundens behov. Detta bidrar i sin tur till forskningen kring vilken

påverkan kundinvolvering har på resultatet hos projekt inom agil systemutveckling och hur

samspelet mellan kund och systemutvecklare utspelar sig. Studien baseras på följande

frågeställning:

• Hur arbetar konsulter inom systemutvecklingsföretag med att sammankoppla förväntan

och behov i en agil utvecklingsprocess i syfte att uppnå kundnöjdhet? Denna

frågeställning kan brytas ner i tre underfrågor:

• Hur påverkar kundinvolverandet sammankoppling av förväntan och behov?

• Vilka metoder tillämpas i syfte att sammankoppla förväntan och behov inom

agil systemutveckling?

• Hur utvärderas huruvida kundnöjdhet uppnås?

1.4 Avgränsning

Denna studie fokuserar på att undersöka den agila utvecklingsprocessen inom IT-projekt mellan

olika IT-konsulter och kunder. Kund i fråga menas med den totala organisation som beställer

produkten av konsultföretaget. Studien har avgränsats till att studera företag från den svenska

konsultbranschen som arbetar med agil systemutveckling och enbart undersöka

systemutvecklarens perspektiv.

5

2 Teori

Teoriavsnittet inleds med en bakgrund i vad kundnöjdhet är samt hur det uppnås och vad de

centrala begreppen förväntan, behov och krav innebär. Därefter beskrivs den agila

utvecklingsprocessen. I teorin belyses även komponenter som kan användas som verktyg i syfte

att öka förståelse av kundens behov. Dessa teorier möjliggör analys av hur kundbehovet

identifieras genom konsultens arbetsmetodik. Tillsammans genererar teorierna en

undersökningsmodell som utgör den centrala delen i analysavsnittet med den agila

utvecklingsprocessen som ramverk.

2.1 Hur uppnås kundnöjdhet?

Kundnöjdheten definieras i denna rapport av att förväntan och behov möts och uppfylls. Detta

uppnås via samproduktion mellan kund och konsult. Kotler et al (2002) beskriver

behovsuppkomsten som ett internt stimuli, i form av exempelvis hunger och törst. Uppkomsten

av behov kan även uppstå i form av ett externt stimuli i samband med att en kund exempelvis

går förbi en matbutik och blir hungrig. Det finns därmed olika anledningar till varför kunden

köper en viss produkt eftersom en produkt kan tillgodose ett eller flera behov. En kunds

behovstillstånd kan enligt De Chernatony och McDonald (2003) variera från tidpunkt till

tidpunkt, där behovet speglar en viss tidpunkt och en specifik situation.

Förväntan beskriver vad kunden vill ha eller tror sig vilja ha menar Parasuraman et al.

(1988, 17) vilket han uttrycker i form av “... förväntningar är definierade som önskan eller

begär hos en kund”, medan behovet skildrar förståelsen av vad kunden behöver. Schneider och

Bowen (1995) menar att behoven är mer omedvetna i kontrast till förväntningar som är mer

medvetna och specifika i sin natur. Vidare menar Noriaki Kano (1984) i sin kundnöjdhets

modell att: “Kundnöjdhet undersöker kundernas uttalade behov och outtalade önskningar och

hur de samspelar”. De förväntningar som kunden uttrycker är bara en delmängd av behovet,

“Produktförväntningarna som uttalas av kunder utgör enbart toppen av ett isberg. Det är

därmed nödvändigt att fastställa kundens gömda behov och problem”. Med andra ord

karakteriseras avsaknad av kundnöjdhet med att slutprodukten inte avspeglar kundens

förväntan och verkliga behov. Figuren nedan illustrerar hur kundnöjdhet uppnås.

Figur 1: Illustration över hur kundnöjdhet uppnås som bygger på Noriakis

kundnöjdhetsmodell.

6

Figuren illustrerar att kundnöjdhet uppnås när kundens förväntan överensstämmer med deras

egentliga behov.

2.2 Agil utveckling

Den agila metoden karakteriseras som kundfokuserad och flexibel utvecklingsform (Avison

och Fitzgerald 2006, 14-19) där kund och systemutvecklare kontinuerligt för en dialog under

utvecklandet av ett IT-system. Metoden är inkrementell, vilket innebär att utvecklandet delas

upp i dellösningar som presenteras efter en viss tid.

En agil utvecklingsprocess antar oftast projektform (Project management institute,

2004, 4), där projekten är temporära och unika till skillnad från verksamhetsarbete som är mer

pågående och repetitivt. Enligt Avison & Fitzgerald (2006, 14–19) tillämpas projekt i syfte att

hantera efterfrågan som inte kan adresseras inom ramarna för organisationens verksamhet.

Metoden bygger på att det är vid ett tidigt stadium av ett projekt eller ett behov visar sig vara

svårt att definiera och identifiera alla restriktioner och mål som man vill uppnå med sin produkt.

Genom att kunden är involverad och delaktig under processens gång kan den föra en dialog

med systemutvecklaren och på så sätt har systemutvecklaren möjligheten att bli medveten om

vad kunden har för behov. Detta sker kontinuerligt under utvecklandets framfart och

kravspecifikationerna kan se annorlunda ut i olika skeden.

2.2.1 Agil utvecklingsprocess

Den agila utvecklingsmetoden möjliggör förändringar av inriktning hos ett projekt genom hela

utvecklingsprocessen. Detta eftersom den välkomnar modifierade kravspecifikationer i

slutfasen av utvecklandet och fokuserar på att repetera iterationer tills önskad produkt är

framtagen (Agile Methodology, 2008). Nedanstående visar på den agila utvecklingsprocessen.

Figur 2: Agil utvecklingsprocess (Xandermar, 2016).

7

Figuren ovan illustrerar regelbundna iterationer, vilka innehåller utvecklingscykler där de

funktionaliteter som ingår i det aktuella inkrementet utvecklas och integreras samt testas inom

cykeln. Resultatet granskas sedan vilket även ger möjlighet för återkoppling från kunden.

Därefter presenterar utvecklingsteamet ett leveransbart inkrement av produkten och kunden kan

då avgöra huruvida den är redo för leverans. Annars registreras bristerna och förs vidare till

nästa inkrement tills önskad produkt är framtagen (Agile Methodology, 2008).

2.2.2 Relationen mellan systemutvecklare och kund inom agila utvecklingsmetoder

För att skapa kundnöjdhet, krävs det ett ömsesidigt samarbete mellan utvecklingsteamet och

kunden (Bettencourt et al., 2002, 100). Detta eftersom kunden i åtskilliga fall inte är tillräckligt

insatt för att förstå termer och modeller inom systemutveckling. Kunden är även främst

intresserad av resultat i form av fungerande mjukvara. En agil utvecklingsprocess kräver därför

flexibla och engagerade kunder som är villiga att arbeta enligt förutsättningarna hos den agila

utvecklingsprocessen (Agile Manifesto, 2001). Att kunden inte är mottaglig för detta kan

resultera i att utvecklingsprocessen havererar och här är det viktigt att kunden är villig att arbeta

agilt (Guneskaran, 1999). Kundinvolvering är därmed viktigt för att identifiera behov (Lianga,

2012) samtidigt som det ger ett starkare relationsband för att skapa kundnöjdhet (Lin och Chen,

2006).

2.3 Kravspecifikation

Inom agil mjukvaruutveckling är kravspecificering grenen som berör de verkliga målen (Zave,

1997, 315), funktionerna och begränsningar hos ett mjukvarusystem. Nuseibeh & Easterbrook

(2001, 1) belyser att kravspecifieringen genomförs genom identifiering av behov och

intressenter i form av kund, användare och utvecklare.

Den främsta metoden för kravinsamling sker genom ostrukturerade intervjuer för att

förstå kundens krav (Dieste, Juristo och Shull, 2008). En ostrukturerad intervju bygger på ett

impulsivt upplägg mellan kund och systemutvecklare. Studier har även påvisat att

kravdefiniering kräver kontinuerlig kommunikation (Ovaska, Rossi och Smolander, 2005),

eftersom förväntningar och kundens attityd till produkten ändras med tiden.

Kraven delas i denna rapport in i projektkrav och systemkrav. Systemkrav kan delas in

i funktionella och icke-funktionella krav. Funktionella krav skildrar vad produkten ska utföra

och beskriver funktionaliteten i den önskade produkten medan icke-funktionella krav beskriver

på vilket sätt den måste uppföra sig i mått på exempelvis prestanda, användarvänlighet,

underhållbarhet, förändringsbarhet, tillgänglighet, säkerhet och skalbarhet (Tsui et al, 2014. 2).

Inom projektkrav ingår budget, tid och omfattning vilka är krav som generellt specificeras

8

initialt vid en upphandling av ett projekt och vid skedet där kund och systemutvecklare lär

känna varandra (Microsoft, 2016).

2.4 Lära känna kund

Att lära känna sin kund utgör en viktig del av den agila utvecklingsprocessen för att förstå

kundens behov (Lindberg, 2001) och skapa ett förtroende innan projektet (Stone et al., 2000).

Att ge någon ens förtroende är ett risktagande, och båda parterna tror att relationen kommer att

leda till något gott (Lugmann, 2005). Gulati & Olroyds (2005) beskriver detta i sin teori om

kundkännedom i fyra steg. Första steget innebär att samla in information om exempelvis

svårigheter och möjligheter i ett samarbete, identifiera kunden och inge förtroende. Det andra

steget ska sedan den nyvunna informationen analyseras för att förstå kundens uppträdande och

agerande under liknande omständigheter som det pågående projektet. I det tredje steget och

med nyvunnen kunskap om kunden från tidigare steg kan ett agerande förutspås och vad för

behov kunden har. I sista steget sprids och omhändertas information inom företaget för att

kunna jobba mot att erhålla en nöjd kund. I samtliga steg utgör kunddialogen en viktig del i att

lära känna kunden.

2.5 Kunddialog

Kunddialog utgör en väsentlig del i att identifiera kundens preferenser och förväntningar, och

samtidigt undvika misstag i produktionen (Prahalad 2004). Lindberg (2001) framhäver att

genom kunddialog kan företag i sin tur öka kundkännedomen och förbättra kundrelationen på

lång sikt. Studier visar även att kontinuerlig kommunikation (Mollokken-Ostvold och Furulund,

2007) mellan kund och systemutvecklare bidrar till att projektplanen hålls inom tidsramen.

Dock menar Barki & Hartwrick (1994) att enbart involvera kunden i teamet inte innebär ett

framgångsrecept i sig utan beror även på kundens personlighet, drivkraft och engagemang inom

projektet som även Kotler (2001) tar upp. Genom att agila utvecklingsprocesser i sin natur

består utav korta tidsintervall, ökar kundens förståelse kring projektet och på så vis även deras

engagemang i och med att kunden får en kontinuerlig insyn i utvecklingen (Kautz, 2009).

För att skapa ett starkt band till kunden inom dessa korta tidsintervall används visuella

kundmöten (Daft et al., 1987, 356), där parterna träffas och diskuterar specifikationer,

prototyper och implementering istället för att ha en telefon- eller mailkonversation. Visuella

möten karaktäriseras som den starkaste kommunikationskanalen då den möjliggör omedelbar

återkoppling och tar hänsyn till exempelvis kroppsspråk och emotionellt innehåll. Detta

förutsätter att kunden är tillgänglig för att kunna skapa en god relation och att kunden ska

integreras i gruppen (Highsmith, 2004).

9

Kunddialog möjliggör även för förändring av kravspecifikationen under projektets

gång, vilket även kan ske sent i utvecklingsfasen (Kautz, 2009). Som en konsekvens av

otillräcklig kunskap finns det däremot risk att kunden ställer för höga krav på produkten eller

avstår från att deltaga i utvecklingsprocessen (Fitzgerald, Hartnet och Conboi, 2008). Detta är

ett exempel på en befintlig barriär, vilken kan identifieras och hanteras via kunddialog.

2.6 Hantering av barriärer mot kund

Kotler et al (2002) menar att kultur är det som påverkar en kunds behov och beteende i största

grad och utgör en dynamisk process som uppstår inom en grupp eller ett samhälle där

värderingar, behov och beteende inlärs. Varje kultur har ett gemensamt synsätt baserat på

liknande erfarenheter och situationer och kan kännetecknas utifrån nationaliteter,

organisationsstruktur och geografiska regioner bland annat. Därmed skapas kulturella barriärer

som ett resultat av skillnader mellan samhörigheter. En kunds beteende är även influerat av dess

sociala roll och status och kan utgöra en social barriär i ett samarbete. En person kan inneha

olika roller i olika grupper och det påverkar vilken typ av inflytande och beteende som utövas.

Utifrån rollen kan detta spegla köpbeteenden av produkter (Kotler et al., 2002).

Peter Galison (1999) belyser ett fenomen kallat pidgin, vilket är ett förenklat språk som

uppstår när aktörer från olika kulturer möts och ska utbyta information och varor. Fenomenet

uppkommer oftast som ett resultat av att språket kan vara alltför komplex för att läras ut till en

annan kultur, vilket utgör en lingvistisk barriär. Det finns därmed kulturella skillnader som en

konsekvens av kunskapsbarriär i form av branschspecifika skillnader samt religiösa

(Leinninger, McFarland, 2002) och sociala skillnader (Galison, 1999). I relationer som gränsar

över kulturer och barriärer är det därför väsentligt att ha god sammanhållning och visa öppenhet

som resulterar i ett förtroende för parterna under arbetet. Förtroende i sin tur kan minska de

kulturella och sociala skillnaderna som uppstår och bidra till kundnöjdhet (Bridge Global,

2012).

2.7 Utvärdera kundnöjdhet

Kundnöjdhet ökar sannolikheten för att kunden återkommer och rekommenderar företagets

tjänster till ytterligare potentiella kunder (Bergman & Klefsjö, 2010, 54). McNeale (1994) och

Gustafsson (2009) menar att mätning av klagomål inte genererar ett relevant mått på

kundnöjdhet, eftersom kunden ofta tar avstånd från att klaga. Ett flertal undersökningar

(Gustafsson, 2009) visar på att enbart fem procent av missnöjda kunder faktiskt uttrycker sina

klagomål till företaget. Därav är det essentiellt för konsulten att under projektets gång och via

utvärdering fånga upp åsikter. En viktig beståndsdel i syfte att uppnå kundnöjdhet är att kundens

10

behov och förväntningar uppfylls, som är utgångspunkten i denna rapporten. Därav finns ett

behov av utvärdering för försäkran om kundnöjdhet (Zeithaml och Bitnér, 2002). Konsulterna

kan sedan mäta kundnöjdhet (Echeverri och Edvardsson, 2002) i form av exempelvis

enkätundersökningar vilket genererar ett holistiskt perspektiv samt status på projektet.

2.8 Undersökningsmodell

Genom de teorier som beskrivits ovan har en undersökningsmodell genererats med

den agila utvecklingsprocessen som ett ramverk och de resterande teorierna som den centrala

delen av modellen som innefattar kundinvolverandet av olika former. Detta eftersom den agila

processen fokuserar på kunden och kommunikation, vilket genomsyrat de nya teorierna:

kravspecifikation, lära känna kund, kunddialog, hantering av barriärer och utvärdera

kundnöjdhet. Dessa teorier ger upphov till nya block som kan sammankopplas till den agila

utvecklingsprocessen.

Figur 5: Undersökningsmodellen med den agila utvecklingsprocessen som ramverk och teorier

som har som mål att uppnå kundnöjdhet genom ökad kundinvolvering.

Dessa block underlättar processen med att hjälpa kunden att förstå deras behov och kunna

specificera dem i form av förväntan, där förväntan i denna rapport refereras som kraven.

Kravspecificering i sin tur sammankopplas med det initiala steget i den agila

utvecklingsprocessen i syfte att förtydliga vikten av att identifiera kundens behov och

förväntan. En god kundkännedom ger möjligheter till att på en djupare förståelse av kundens

problem och systemutvecklare kan därmed vägleda kunden till en optimal lösning. Genom

hantering av barriärer underlättas förståelsen och effektiva dialoger mellan kund och konsult

kan hållas. Kunddialog kan i sin tur sammankopplas med samtliga delar i den agila processen,

11

men används huvudsakligen i delen “Granska & Återkoppla” vilket sker efter varje iteration i

syfte att ge kunden utrymme till att förmedla åsikter kring det levererade inkrementet.

Detsamma gäller hantering av barriärer i syfte att skapa förtroende under projektets gång och

sammankopplas även med det initiala steget vid projektstart. Slutligen kan utvärdering av

kundnöjdhet kopplas ihop med den sista delen i den agila processen som uppnås då produkten

anses vara färdig. Under detta moment kan kundnöjdhet identifieras och konsulten kan få

slutgiltig återkoppling på hur kunden upplevt samarbetet.

2.8.1 Teoretisk operationalisering

Analysen baseras på att jämföra undersökningsmodellen med det empiriska underlaget för att

determinera vilka metoder som används inom de olika teoriområdena för att uppmuntra till att

öka förståelsen för kundens behov. Metoderna kan därefter jämföras mellan de olika företagen

och analysen ger även utrymme för att belysa vilka element som anses vara viktigast för att

uppnå ett optimalt resultat där förväntan möter behov. Nedan följer en analysmall där viktiga

faktorer inom respektive teoriområde har sammanfattats i tabellform.

Tabell 1 - Teoretisk operationalisering och referenser

Koncept från undersökningsmodell

Centrala aspekter med referenser

Agila metoder/Interna verktyg • Utvecklingsmetod (Agile Methodology, 2008) • Karaktär hos iterationer (Agile Methodology, 2008) • Kundens vilja att arbeta agilt (Guneskaran, 1999)

Lära känna kund • Förtroende innan projekt (Stone et al., 2000) • Kundkännedom: svårigheter och möjligheter, förstå

uppträdande, förutspå agerande, omhänderta information (Gulati och Oldroyd, 2005)

Krav • Ostrukturerade intervjuer (Dieste, Juristo och Shull, 2008)

• Systemkrav (Tsui et al, 2014. 2) • Projektkrav (Microsoft, 2016)

Kunddialog • Tillgänglighet (Highsmith, 2004) • Kontinuerlig kommunikation (Mollokken-Ostvold och

Furulund, 2007) • Möjlighet att ändra kravspecifikation (Kautz, 2009) • Framgång bygger på kundens personlighet, drivkraft

och engagemang (Barki & Hartwrick, 1994) • Visuella möten (Daft et al., 1987. 356)

12

Hantering av barriärer mot kund

• Förtroende under projektet (Bridge Global, 2012) • Kulturell barriär - identitet, hierarki (Kotler et al.,

2002) • Social barriär (Kotler et al., 2002) • Kunskapsbarriär (Leinninger, McFarland, 2002) • Lingvistikbarriär (Galison, 1999)

Utvärdera kundnöjdhet • Mäta kundnöjdhet (Echeverri & Edvardsson, 2002)

I tabellen åskådliggörs centrala aspekter som studien använder i utvärderingen av hur företagen

arbetar med att sammankoppla behov och förväntningar i en agil process. Dessa nyckelord

tillsammans med de centrala aspekterna möjliggör ett ramverk för studiens intervjuguide.

Därmed har studien använt sig av de centrala aspekterna i utformandet av intervjufrågor som

beskrivs i avsnitt 3.3.2 mer utförligt.

13

3 Metod Metodavsnittet inleds med val av tillvägagångssätt och efterföljs av motivering för val av

företag. Sedan beskrivs intervjuer som den primära informationskällan vilket inkluderar val av

intervjupersoner, utformande av intervjuguide, metod operationalisering samt genomförande

av intervju. Metodavsnittet avslutas med hur den kvalitativa datan ska analyseras, övriga källor

som legat till grund för undersökningen samt källkritik.

3.1 Tillvägagångssätt

Denna studie bygger på en kvalitativ metod som bygger på ett explorativt och holistiskt

perspektiv och ger en överskådlig beskrivning av hur systemutvecklare sammankopplar behov

och förväntningar i en agil utvecklingsprocess. Eftersom studien bygger på en undersökning

och beskrivning av sociala och komplexa system snarare än mätdata, är det lämpligt att välja

ett kvalitativt angreppssätt. Vidare realiseras studien genom att tillämpa intervjuer som en form

av materialinsamling eftersom det ger utrymme för följdfrågor, djupare förståelse och en

beskrivning av relationen mellan kund och systemutvecklare. Detta är något som en kvantitativ

studie inte tar hänsyn till, vilket är nödvändigt i en relationsstudie där känslor och attityder kan

inverka i en djupare förståelse av respondentens svar (Svensson och Starrin, 2003, 15–18).

3.2 Val av företag

Rapporten bygger på material från intervjuer med representanter från tre olika IT-

konsultföretag. Ur ett bekvämlighetsperspektiv har ett avgränsat geografiskt område valts ut,

vilket motsvaras av Stockholm-Uppsala regionen. Urvalet av företag genomsyras av

heterogenitet med avseende på arbetssätt och storlek på företagen, vilket ger utrymme för att

utföra en kvalitativ studie som sträcker sig över olika typer av företag inom samma bransch. Ett

annat kriterium vid urvalet av företag, bygger på att företaget använder sig av en agil metod vid

systemutveckling.

Följande är information från år 2015 som beskriver konsultföretagen som valts ut för

intervju (Allabolag.se, 2017)

Tabell 2 - Företagsbeskrivning

Företag Oms. (TKR)

Registreringsår Kontorsläge Antal anställda

Intervjudatum Intervjulängd Respondent

Precisit 2 714 2014 Uppsala, Stockholm

4 2/11/2016 155 min Jacob Selg

Netlight 747 372

1999 Stockholm 714 10/11/2016

121 min

Johan Andersson

14

03/04/2017 35 min Johan Andersson

Accigo 116 266 2004 Stockholm 87 17/11/2016 06/02/2017

123 min 65 min

Ola Brehm David Effemey

I ovanstående tabell summeras en kort bakgrund kring de olika företagen som valt ut, men även

antalet intervjuer och vilka respondenter som valts ut.

Precisit är ett av företagen i studien och arbetar med att komplettera och förstärka det befintliga

utvecklingsteamet hos en kund för att hitta rätt balans (Precisit, 2016). Ett år efter att Precisit

etablerats på marknaden, började Jacob Selg år 2015 arbeta som systemutvecklare med

mediateknik som bakgrund. Netlight är å andra sidan ett Stockholmsbaserat konsultföretag som

erbjuder kunder kompetens inom IT och management (Netlight, 2017). Johan Andersson

(2016) är systemutvecklare på Netlight sedan fyra år tillbaka och har sedan dess arbetat inom

banksektorn och retail med varierande tekniska roller såsom systemutvecklare, gruppledare

eller arkitekt. Accigo är likt Netlight ett IT-konsultföretag som är baserat i Stockholm, där Ola

Brehm arbetar som affärsområdesansvarig inom webbutveckling och produktivitetsinriktade

lösningar hos Accigo sedan fyra år tillbaka. David Effemey (2017) är kravanalytiker på Accigo

och har arbetat i företaget under två och ett halvt år och arbetar idag inom samma projekt som

Brehm.

3.3 Intervjuer

3.3.1 Val av intervjupersoner

Studien har inriktat sig på att intervjua representanter från de tre olika konsultbolagen inom

systemutvecklingsbranschen kring Stockholmsregionen. Vid val av lämplig respondent är det

vidare viktigt att vid kontakt med olika företag vara tydlig med vad som ska undersökas och

vad materialet ska användas till för att undgå missförstånd och öka validiteten av respondentens

svar (Eriksson och Wiedersheim-Paul, 2006). Målet var även att intervjua medarbetare med

olika bakgrund och erfarenheter för att få med olika aspekter och synvinklar på hur processen

ser ut i en agil systemutvecklingsmiljö.

3.3.2 Utformande av intervjuguide

Vid utformandet av en intervjuguide, utgick studien från intervjuarens tio dödssynder som

Eriksson & Wiedersheim-Paul (2006) tagit fram. Detta är en lista som bygger på faktorer som

15

bör undvikas vid utformandet av intervjufrågor. En av dessa faktorer är bland annat att ställa

ledande frågor och att ge ett påstående istället för en fråga är även lämpligt att undvika vid

formulering av intervjufrågor. Det är dessutom viktigt att formulera frågor som är öppna för

diskussion vilket kan lyfta fram ytterligare aspekter på utbredningsområdet (Eriksson och

Wiedersheim-Paul, 2006). Intervjuguiden strukturerades med hjälp av sex teman i form av agila

metoder, kravspecifikation, lära känna kund, hantering av barriärer mot kund, kunddialog och

utvärdering av kundnöjdhet. Dessa i sin tur bygger på de teoretiska ramverken som ligger till

grund för rapporten. I syfte att säkerställa intervjuguidens relevans och verifiering av lämplighet

hos intervjurespondenter har samtliga frågor skickats ut till respondenter på förhand. Vid

genomgång av respondenternas svar kategoriseras datan i segment med liknande egenskaper.

Dessa sammankopplas i sin tur med de teman som bygger på de teoretiska ramverken.

3.3.3 Metod operationalisering

I syfte att besvara studiens frågeställning skapades en intervjuguide med frågor inom respektive

koncept från undersökningsmodellen. Nedan redovisas exempelfrågor inom respektive

koncept.

Tabell 3 – Metod operationalisering

Koncept från undersökningsmodell

. Exempelfrågor

Agila metoder/Interna verktyg

Vilket/vilka element anser ni vara viktigast i hela processen och varför?

Lära känna kund Hur skapar ni förtroende innan projektet startas?

Krav Hur sker kravinsamlingen? • Arbetar ni fram dem tillsammans med kunden eller

ber ni kunden att initialt leverera en kravspecifikation?

Kunddialog Vilken betydelse tycker ni att kundens tillgänglighet har på projektet?

Hantering av barriärer mot kund

Upplever ni kommunikationssvårigheter och skillnader gentemot kunder och hur hanterar ni i sådana fall dessa?

Utvärdera kundnöjdhet Hur arbetar ni med kundfeedback i slutet av projektet?

Ovanstående frågor är utformade utifrån de centrala aspekterna som härrör från koncepten i

undersökningsmodellen. För att uppnå detta har nyckelord för varje motivationsfaktor från den

teoretiska referensramen använts. Exempelvis var frågan “Hur skapar ni förtroende innan

16

projektet startas?” sammankopplad med aspekten förtroende innan projekt (Stone et al., 2000).

Dessa frågor i sin tur ska besvara hur de olika koncepten används i form av metoder i konsultens

arbete i att förstå kundens behov och förväntningar.

3.3.4 Genomförande av intervju

Intervjumetoden är av semistrukturerad karaktär med ett antal centrala frågor som sedan ger

utrymme för ett interaktivt samtal och nya diskussionsområden. Detta öppnar för ett samtal där

informatören i viss utsträckning har möjlighet att styra vart intervjun leder och vilken

information som tas upp. Syftet är att respondenten inte ska ledas av intervjuaren (Hedin 1996,

6). Studien innefattar ett face-to-face intervju per företag och sedan en uppföljning via

videokonferens vid behov.

3.4 Analys av kvalitativa data

Respektive intervju spelades in för att sedan ordagrant transkriberas i syfte att förebygga

utlämnande av information. För att tematiskt kunna analysera respektive företag organiserades

insamlade data utifrån analysmodellens huvudkategorier. Efter en tematisk analys per företag

genomfördes en komparativ analys vilket enligt Wellington & Szczerbinski (2007) kan

tillämpas i syfte att extrahera likheter och skillnader i företagen sinsemellan. Detta möjliggör

en analys på detaljnivå som kan visa på vilka verktyg som används för att sammankoppla

förväntan och behov samt på en översiktlig nivå förstå hur verktygen samverkar i den agila

processen.

3.5 Övriga källor

Utöver intervjuer som datainsamlingsmetod har det empiriska underlaget kompletteras med

sekundärkällor i form av bland annat information från de intervjuade företagens hemsidor.

3.6 Studiens trovärdighet

Eriksson & Wiedersheim-Paul (2006) förespråkar att källor bör granskas med avseende på dess

validitet, reliabilitet och relevans vilket appliceras på denna undersökning. Därmed granskas

huruvida varje källa i denna undersökning mäter vad den utger sig för att mäta, om den är

tillförlitlig och om den är väsentlig i förhållande till problematiseringen. Empirin baseras till

största del på intervjuer med representanter från svenska systemutvecklingsföretag inom

Stockholmsområdet, vilka arbetar med agil systemutveckling.

17

Genom att tillämpa intervju som metod finns viss risk för att informationen är vinklad

och ensidig med eller utan avsikt (Eriksson, Wiedersheim-Paul 2006, 166-167). Dock är dessa

representanter troligtvis de personer som har störst inblick i vilka aktiviteter som den agila

utvecklingsprocessen består av i syfte att öka kundinvolveringen eftersom dem deltar själva i

utvecklingen. Dessutom valideras studiens problemställning mot studiens teorimodell, genom

att undersöka huruvida varje teoridel är relevant för att besvara problemformuleringen.

Studien omfattar enbart systemutvecklarens perspektiv vilket kan påverka resultatets

reliabilitet. Studien avgränsas till att undersöka vilka metoder systemutvecklare tillämpar men

skulle kunna styrkas av kunden genom att verifiera att de metoder systemutvecklarna utger sig

för att använda stämmer. Dock finns det svårigheter med att hålla intervjuer med kunden då

sådan information kan vara känslig och svårtillgänglig.

18

4 Empiri

4.1 Bakgrund

4.1.1 Precisit

Sedan ett år tillbaka arbetar Selg (2016) på Precisit i ett utvecklingsteam på tio personer som

tar fram ett patienthanteringssystem för en kund inom vården. I detta projekt arbetar en

testgrupp som en del av utvecklingsgruppen, med arbetslivserfarenhet inom IT eller sjukvård.

Innan dess har Selg (2016) utvecklat en webbapplikation åt en kund inom mediebranschen på

Precisit.

4.1.2 Netlight

Andersson (2016) arbetar sedan ett år tillbaka på Netlight i en utvecklingsgrupp på 25 personer

hos en kund inom banksektorn. Anderssons uppgift är att arbeta med den tekniska

implementation av regelverk som tillkommit efter finanskrisen 2008. Där har en produktägare

utnämnts som tar beslut om prioritering i samråd med intressenter. Produktägaren kan vara en

konsult eller anställd som innehar ett management profil och branschspecifik kompetens i syfte

att fungera som en brygga mellan utvecklingsgruppen och intressenter.

4.1.3 Accigo

Sedan ett år tillbaka arbetar Brehm (2016) och Effemey (2017) på Accigo med en kund inom

telekombranschen som är positionerade i Norden. Detta samarbete sker tillsammans med tio

indiska konsulter från partnerbolaget Sigmatech. De är totalt 15 konsulter från Accigo som

arbetar med att bygga deras dokumentationsplatform. Projektet involverar en produktägare och

en projektledare från kundens sida, där projektledaren driver projektet medan produktägaren

arbetar inom juridik och försäkrar resultatet av produkten. Utvecklingsteamet är uppdelat i

arbetsströmmar med fokus på utveckling, test, förändringsledning och krav. Brehm (2016)

menar att kravgruppen utgör kärnan i projektet som har störst kunskap om projektets status och

nästkommande iterationer.

4.2 Agil utvecklingsprocess

4.2.1 Precisit

Den agila utvecklingsprocessen har inom de projekt som Selg (2016) arbetat på Precisit,

anpassats efter kundens situation. Detta beror exempelvis på kundens tidigare erfarenhet,

19

geografiskt avstånd och tillgänglighet. De viktigaste elementen hos den agila processen i

kontexten att förstå kundens behov är enligt Selg korta iterationer med återkoppling,

kravspecifikationen samt att kunden är villig att vara involverad under processens gång.

Testgruppen formulerar arbetsuppgifter vilka sedan utvecklarna bearbetar utifrån märkningar

och prioritet.

Ett agilt element som Selg (2016) saknar i projektet är tidsestimering av projektets

uppgifter. Med hjälp av tidsestimering menar Selg att det tydligare går att motivera varför det

tar lång tid att utveckla en särskild funktionalitet. Genom att veta hur lång tid varje uppgift tar

separat kan utvecklarna enkelt få en överblick av hur många timmars arbete en iteration

innehåller. Detta underlättar vid motiverande av varför övriga funktionaliteter förflyttas till

nästa iteration som ett resultat av tidsbrist.

4.2.2 Netlight

I det projekt Andersson (2016) arbetar med idag på Netlight, ingår cirka 25 utvecklare och i

detta projekt menar han att det en hel del kringliggande planering och synkronisering krävs.

Detta kan resultera i att det ibland inte blir lika agilt som man önskat. En risk med agil

systemutveckling menar Andersson är att det kan resultera i overhead i form av överflödigt

arbete och ett förflyttat fokus på mätbara siffror och diagram som visar på hur framgångsrik

den agila processen är. Det har även en tendens att bli ganska många möten som inte är så

produktiva alla gånger.

Andersson belyser att kunder ofta är villiga att jobba agilt, men att det kan kräva

omfattande interna omställningar eftersom kunden inom banksektorn är vana att arbeta med

traditionella metoder. Däremot är kunden i detta fall öppen för att arbeta agilt och har en

kontinuerlig återkoppling, vilket kan exemplifieras i att utvecklingsteamet i samspel med

kunden implementerar nya förändringar som inkommer tätt inpå en release. Iterationer

genomförs en gång per vecka. Detta på grund av att mer frekventa releaser oroar kunden att

vidbehålla systemet i liv.

4.2.3 Accigo I det projekt som Brehm (2016) och Effemy (2017) arbetar med idag, utgör prioritering av krav

och kravspecifikationen de viktigaste byggstenarna i en agil process, vilka utgör möjliga

kontaktytor för kunden. Brehm (2016) belyser dock att kunden i fråga vanligtvis applicerar en

traditionell process på systemutvecklingsprojekt. I projekten engagerar sig kunden mer om de

uppfattar att projektet går dåligt eller är mindre engagerade om de är nöjda med hur projektet

20

fortlöper. Brehm belyser även att genom minskat engagemang från kundens sida leder det till

att de inte kommer att kunna förklara djupgående vad som levereras och varför.

I projekten använder Brehm (2016) sig utav iterationsplanering, demo av resultat och

retrospektiv. Brehm menar att iterationsplaneringen som genomförs var tredje vecka kan ta

onödigt lång tid som ett resultat av diskussioner om hur en user stories ska implementeras. I ett

ytterligare moment som införts, benämnt inför-iterationsmötet, försöker de därför förbereda det

som sen ska in i iterationsplanering, så att en del av dörrarna stängs.

Brehm (2016) belyser struktur som ett önskvärt element för att komplettera den agila

processen som han menar i annat fall kan resultera i svag ledning. Brehm menar att man bör

initiera en huvudplan för vad projektet och att den sedan bör ägas av en styr

grupp som sköter prioriteringsarbetet och vad som bör genomföras i respektive fas. Vidare

menar Brehm att den agila metoden inte bör ses som regelbok som måste följas till punkt och

pricka, vilket i vissa fall har lett till konflikter då medarbetare blivit frustrerade över att principer

inte följts.

4.3 Lära känna kund

4.3.1 Precisit

Att skapa kundkännedom, samla information om kunden och knyta relationsband är något Selg

(2016) menar att han inte avsatt mycket tid till innan olika projektet startat igång. Istället

använder Precisit sig av tidigare projekt som referensram i syfte att vinna förtroende och erhålla

projektet och även uppdatera sina kunskaper inom specifika programmeringsspråk som kan

utnyttjas i samarbetet.

“Kunden vill ha något konkret, visa tidigare projekt och vila ögonen på. Det blir tydligt.

Vi gör sällan prototyper men visar istället tidigare projekt. Man har inte tid att göra prototyper

innan.” Selg, Intervju 2016-10-02

I det första projektet hade Selg (2016) någorlunda förståelse för verksamheten och

bransch kunden verkade i medan hos hans nuvarande kund har han tillgång till testgruppen som

minskar behovet av att lära känna kunden. Eftersom företaget Selg arbetar hos idag främst

arbetar med kunder inom vården, har testgruppen anlitats för att fylla denna funktion.

4.3.2 Netlight

Andersson (2016) belyser konsulters möjlighet att välja uppdrag utifrån deras intresse och

kunskapsbakgrund. Andersson nämner att Netlight studerar noggrant ut vilka de väljer att ingå

i ett samarbete med och anser att det är viktigt att kundens kultur, värderingar, arbetsmetoder,

21

framgångsfaktorer, framtida problem och kundsegment överensstämmer med Netlights egna.

Denna kundkännedom kan antingen erhållas genom att Netlights medarbetare tidigare arbetat

hos kunden och kan skildra denna inofficiella data, eller att säljavdelningen träffar företaget

och försöker få reda på detta genom ett informellt möte.

När kunden och konsulten träffas är viktigt att kunna vara ärlig med att de inte är expert

på allt, men att de är problemlösare och kunniga menar Andersson (2017). Vidare anser

Andersson att de till exempel försöker spegla kunden i hur de sitter eller hur de andas för att

känna samhörighet. Detta är något som säljavdelningen arbetar med att kontinuerligt utbilda

konsulter i olika scenarios och hur man använder kroppsspråk och tal på bästa sätt.

4.3.3 Accigo

Brehm (2016) menar att Accigo lär känna kunden initialt genom att se över kundens hemsida

och årsredovisning samt att en säljare initialt arrangerar ett första möte för att presentera

verksamheten och dess framgångsfaktorer. Brehm (2016) belyser även att ett förtroende uppstår

mellan individer och inte specifikt till företaget vilket gör att efter att en konsult påbörjat en

relation med en kund blir det svårt att byta ut konsulten mot någon annan.

4.4 Kravspecifikation

4.4.1 Precisit

I det nuvarande projektet som Selg (2016) arbetar med på Precisit, erhöll utvecklingsgruppen

initialt en gedigen dokumentation av krav som sedan visade sig vara bristfällig och

kompletterades därefter. Därmed hölls dialoger för att utreda möjligheten att implementera

kraven. I dessa fall ställer även utvecklingsgruppen motkrav i form av tid, omfattning eller

budget. Under revidering av krav belyser Selg att det är viktigt att vara tillmötesgående från

både kundens och konsultens sida.

Under projektet har huvudsyftet med produkten varit densamma sedan start. Selg menar

dock generellt att kunden kan oftast ha en tydlig idé om att det ska gå att utföra någonting i det

färdiga systemet, men vet inte hur det skall genomföras beskriver Selg (2016). Om

utvecklingsgruppen identifierar att kundens initiala förväntan inte överensstämmer med deras

behov berättar Selg att utvecklingsgruppen förbereder en generell lösning. Vidare prioriteras

kraven generellt genom att de krav som berör funktionalitet prioriteras högre än krav som berör

design. Här sköter Precisit hur prioritering av krav sker baserat på vad de tror att kunden önskar

levererat och i vilken ordning menar Selg. Konsulterna får direkt återkoppling från kunden då

de sedan visar vad som utvecklats.

22

4.4.2 Netlight

Enligt Andersson (2016) kan kravinsamlingen anta olika former av diskussioner eller

workshops med interaktiva moment såsom att skissa diagram på Netlight. Till vilken

utsträckning som projektgruppen initialt arbetar med kravspecifikation varierar enligt

Andersson. I de fall förändringar av initialt definierade krav genererar påtagliga risker belyses

vikten av att samtliga berörda intressenter är närvarande i syfte att generera en detaljrik

kravspecifikation.

En risk som Andersson (2017) belyser är att kunder utan teknisk bakgrund kan ställa

krav som enligt dem är triviala men i själva verket är tekniskt komplexa att genomföra. Där

menar Andersson att systemutvecklaren behöver sätta stopp, om det kräver mer tid eller pengar

om önskemålet går utanför det initiala syftet, vilket kräver en kunskapsbas att basera sina

argument. Vidare sker prioritering av kraven genom att prestanda har en tendens att

nedprioriteras till förmån för krav som berör funktionalitet, tills de blir ett problem. Andersson

(2017) menar att det funktionaliteten som är det viktigaste, så länge det inte blir uppenbara

prestandaproblem vilket skulle resultera i att prestandan istället blir högprioriterad.

4.4.3 Accigo

Kravinsamlingen på Accigo genomförs enligt Brehm (2016) genom en förundersökning i form

av en serie av åtta till tolv workshops med kund som fokuserar på planering, mål, vision samt

förvaltning. Brehm (2016) belyser vikten av att samla personer med mandat kring att ta beslut

kring mål från kundens sida under respektive workshop. Sedan skapas kravspecifikationen

genom att en designer utifrån samtalet och reaktioner under en workshop tar fram skisser på ett

lösningsförslag. I de fall då Effemy (2017), som är kravställare på Accigo, upplever att kundens

förväntan inte överensstämmer med deras behov vägleder han kunden via dialoger och

visualisering. Vidare menar Effemy (2017) att de initiala workshopsen inkluderar moment där

intressenter från kundens sida delas in i mindre grupper för att belysa problem och dess

bakgrund. Gruppernas åsikter sammanknyts därefter för att generera en helhetsbild av

problemet genom en summering. Brehm (2016) belyser summeringen som ett viktigt moment

vilket skapar ett gott förtroende hos kunden. I fallet med kunden inom telekommunikation

berättar Brehm att de inte hann genomföra en förundersökning som ett resultat av en begränsad

tidplan.

Förslag till prioritering av krav bestäms oftast av konsulten menar Brehm. Han belyser

även vikten av att presentera samtliga alternativ samt vikten av att tidsestimera kraven i syfte

möjliggöra motivering av särskilda alternativ. Brehm (2016) belyser även att krav kan ställas

från konsultens sida vilket han exemplifierar med ett tillfälle då en funktion behövde lanseras

23

under en begränsad tidplan. Accigo efterfrågade då ett beslut internt hos den person som skulle

ta ägarskap för en delprodukt i syfte att möjliggöra vidareutvecklingen.

4.5 Kunddialog

4.5.1 Precisit

I båda projekten som Selg (2016) arbetat med på Precisit har dialogen initialt varit mindre

intensiv än senare i utvecklingsprocessen, allt från en gång i månaden till en gång i veckan.

Selg menar att det kan förklaras med att initialt har kunden och utvecklarna en god idé om de

grundläggande beståndsdelarna i systemet genom en detaljerad kravspecifikation, vilket gör att

mycket tid initialt läggs på att sätta upp de grundläggande miljöerna och ramverken utan att

generera input från kunden. Selg (2016) menar även att Precisit’s kunder kommer sällan med

förändringar under utvecklingscyklerna utan ger återkoppling efter att de fått någonting att

utvärdera efter varje iteration.

På grund av det geografiska avståndet mellan parterna träffar utvecklingsteamet kunden

via videokonferens. Den enda gången de träffas i person är när kunden genomför

acceptanstester och går igenom samt godkänner delar av produkten tillsammans med

testgruppen. Selg (2016) menar att kundens tillgänglighet under processens gång är essentiellt

för projektet, speciellt då iterationer sker på veckobasis. Om kunden då inte kan närvara under

en vecka och besitter en specifik kunskap som är essentiell för genomförandet av ett moment,

kan processen stagnera. Att kunden ska vara delaktig i den agila processen kan därmed

användas som ett motkrav från utvecklingsgruppen menar Selg.

4.5.2 Netlight

Kunden består i Anderssons nuvarande projekt av ett 50-tal intressenter vilka alla vill ge

återkoppling på utvecklingsarbetet inkluderande drift och upphandlings medarbetare samt

slutanvändare vilka är positionerade i ett annat land. Oftast kommer slutanvändarnas feedback

sent och i slutet av en iteration, och i det fallet får man använda återkopplingen i nästa iteration

(Andersson, 2016).

Andersson (2016) skildrar att återkoppling sker ett par gånger i veckan, eftersom

konsulter oftast sitter hos kunden och även i hans fall. I annat fall hade feedbacken varit mer

standardiserad och inte lika spontan om konsulterna hade befunnit sig på Netlights kontoret.

Han ser gärna att kunden kommer med feedback på daglig basis, men däremot är det inget

uttalat krav från Netlights sida att kunden förväntas vara tillgänglig. Återkopplingen är

regelbunden under projektet men blir intensifierad närmare projektets slutfas. Kunden finns

24

dock inte alltid tillgänglig när det behövs såsom att nyckelpersoner kan vara sjuka. Därmed

krävs det att man inväntar dessa personer eller implementerar utifrån vad man tror. Andersson

(2017) anser att oavsett om kunden har tydliga krav och behov är det väsentligt att kunden är

tillgänglig för att ge feedback för ett lyckat projekt. Å ena sidan kan tydliga krav vara ett tecken

på hög medvetenhet om IT-projekt, men det kan också vara ett resultat av att de har en tydlig

bild av vad de tror sig vilja ha i slutändan.

4.5.3 Accigo

Kunddialogen förs via respektive arbetsström på veckobasis på Accigo (Brehm, 2016). Sedan

kan täta dialoger mellan individer ske mellan de fasta mötena. Under kunddialogen kan önskan

om kravförändringar uppstå, men nya krav appliceras dock i en nästkommande iteration.

Däremot om kunden innehar en hierarkisk organisationsstruktur menar Brehm att det finns en

risk för att kravförändringar går förlorad på grund av rädsla för att framföra en åsikt eller ett

beslut.

Inom projektet har Brehm (2016) arbetat på plats i kundens lokaler, vilket han belyser

som en fördel då konsulterna kommer närmare verksamheten. På grund av begränsade lokaler

hos kunden arbetar konsulterna idag istället i Accigos lokaler. Kommunikation har skett genom

videokonferenser och trots att en lokal är bokad för att mötas i person tenderar representanter

från kundens sida att deltaga i mötet via videokonferens. Enligt Brehm har engagemanget inte

varit som önskat och ibland har projektet stagnerat på grund av att produktägaren eller

projektledaren varit frånvarande.

4.6 Hantering av barriärer mot kund

4.6.1 Precisit

När nya förändringar och krav önskas hanteras dessa genom testpersonerna från kunden till

utvecklingsteamet. På samma sätt kan testgruppen föra vidare information från

systemutvecklarna till kunden om ett krav inte kan uppnås inom önskad tid på grund av

komplexitet. Selg (2016) beskriver att: “När det går genom testarna fungerar de som ett slags

filter som tar in kundens önskemål, analyserar dem och gör om dem till faktiska tasks som vi

kan använda i våran agila vardag.” Selg, Intervju 2016-10-02

Selg (2016) förklarar även att det inte fanns någon liknande testgrupp tillgänglig i

projektet med media kunden. Då fick utvecklarna kraven och önskemålen direkt från kunden,

vilka i sin tur tar lång tid att tolka. Testpersonerna har även koll på den övergripande processen

och målet med projektet. Selg menar därför att i de fall han inte har tillgång till en liknande

25

testgrupp och själv inte har god kundkännedom är det hans ansvar ur ett serviceperspektiv att

arbeta med att lära känna kunden och deras behov bättre. Annars kan missförstånd i hur krav

tolkas uppstå som i sin tur kan resultera i oönskad implementering och orealistiska krav menar

Selg. Ett exempel på detta är när kunden efterfrågade en realtidslösning för notiser som en

ytterligare funktionalitet till systemet, vilket utvecklarna tolkade som en komplex lösning som

skulle behöva mer tid och resurser än specificerat.

4.6.2 Netlight

Projekt består oftast av personer som är experter inom verksamheter och personer som agerar

som tekniska experter menar Andersson (2016) på Netlight. Han belyser vikten av att involvera

aktörer som kan fungera som översättare i syfte att undvika missförstånd mellan parterna. I

projektet Andersson arbetar med idag har de översättare vilka tenderar att vara antingen

kravansvarig, projektledare eller verksamhetskunniga personer med en bred förståelse. Vidare

menar han att utvecklarna ibland hamnar i beroendeställning till översättare på grund av deras

specifika kompetens som kan vara essentiell för att förstå en viss domän inom verksamheten.

Av eget initiativ har Andersson (2016) skapat en egen ordlista med förkortningar i syfte

att öka verksamhetsförståelsen, vilket i sin tur hjälper utvecklingsarbetet. Han beskriver även

hur missförstånd kan uppstå som ett resultat av exempelvis en hierarkisk organisationsstruktur

hos kunden. Denna struktur kan resultera i att individer längre ner i hierarkin inte vågar uttrycka

sig, vilket ökar risken för att viktig information går förlorad. Ett exempel på missförstånd som

uppstod var när han arbetade mot systemutvecklare i Indien som sällan berättade om de inte

förstod något, vilket visade sig senare när produkten levererades och det inte alls avspeglade

vad de trott att de kommit överens om.

För att uppehålla en bra relation är det viktigt vara ärlig menar Andersson (2016). Han

belyser enkla medel såsom att leverera vad som utlovats vilket exempelvis kan vara att skicka

en viss information under en eftermiddag. Ytterligare medel kan vara att anordna

gruppaktiviteter som kan föra gruppmedlemmarna närmare varandra på ett personligt plan.

Andersson menar att det är viktigt att kunden är införstådd med vad som är rimligt och vad som

kan åstadkommas utifrån givna förutsättningar. I annat fall menar han att det finns risk för att

kunden ställer orealistiska krav.

4.6.3 Accigo

Brehm (2016) menar att det är viktigt att konsulten kan prata kundens verksamhetsspråk. Ett

exempel som belyser detta är när deras arkitekt använt sig ett språk som uppfattas väldigt

abstrakt och akademiskt. Därmed uppstår ett problem där jurister som inte förstår något om

26

datamodeller och metadata har svårigheter att kommunicera med varandra. Dessutom kan det

uppstå begreppsförvirring även om kunden är tekniskt kunnig. Ett exempel är att Accigo arbetar

med att ta fram en prototyp, som tas fram i testsyfte för att lära sig mer och för sedan skapa en

slutlig produkt. Samtidigt tolkar vissa kunder detta som slutprodukten och förväntar sig inget

mer, men blir å andra sidan chockade över att produkten inte är färdig vid det laget. Brehm

anser att man måste gå ifrån den teknokratiska approachen och istället använda metaforer och

kontrollfrågor, för att visa på att man är mån om att de förstår och att konsulten är intresserad

av deras åsikter. Att kunna möta kunder och förstå deras tankar är något som bygger på

konsultens talang och intresse menar Brehm. Effemy (2017) menar att missförstånd undviks

genom att involvera en stor grupp av intressenter från kunden med olika kunskaper. På så vis

kan någon från kundens sida hjälpa till att förklara i de fall någon annan part hos kunden inte

förstår.

Eftersom kunden inom telekom är ett internationellt företag med flera aktörer, måste

information paketeras för att kunna rapporteras vidare menar Brehm. I detta företag är engelska

koncernspråket med verksamheter i nordiska länder där språkkunskaperna är väldigt

varierande. Dialogen sker på oftast på svenska men övergår ibland till engelska om de vill vara

säkra på att inte blir missförstådda. Vidare är en del av kundgruppen från Finland, som helst

svarar jakande eller nekande och broderar inte ut sina svar. Brehm (2016) menar dock att även

om missförstånd uppstår, är det alltid kunden som har rätt oavsett och som konsult utvecklas

en känslighet för missförstånd när det uppstår första gången och det bidrar till att

kundkännedomen ökar.

4.7 Utvärdera kundnöjdhet

4.7.1 Precisit

För att mäta kundens tillfredsställelse använder Precisit ingen specifik metod för att avgöra

detta menar Selg (2016). Eftersom återkoppling sker i form av acceptanstester under projektet

och kunden godkänner delar av produkten varannan månad, blir detta ett underlag för

avgörandet om kunden är nöjd eller inte.

“När de accepterar pengarna och produkten, och om kraven är uppfyllda så är det

indirekt klart och kunden är nöjd” Selg, Intervju 2016-10-02

4.7.2 Netlight

Huruvida kunden är nöjd bygger oftast inte på att systemutvecklaren levererar en perfekt

produkt utan snarare att man levererat 80 procent av kravspecifikationen och att 20 procent inte

27

är fulländad. Andersson menar istället att det inte finns något större värde i att avlägga tre till

fyra månader för att färdigställa de resterande delarna. Samtidigt finns det svårigheter i att veta

huruvida kunder är nöjda, men att det i så fall avspeglas i en sammanställning av återkoppling

under projektets gång.

4.7.3 Accigo

Att mäta kundens tillfredsställelse och avgöra om deras förväntningar och behov har

sammankopplats har Accigo tidigare använt sig av en enkätundersökning som ställts en gång

om året med antal frågor. Eftersom enkäten varit tidskrävande att fylla i, valde Accigo att göra

en enklare undersökning, där man frågar kunden hur stor chansen är på en skala 1-10 att de

skulle rekommendera oss till någon i sin organisation eller sitt nätverk. Detta märks även om

kunden inte är nöjd menar Brehm (2016) i samband med att kunden börjar dividera med timmar

och kronor fram och tillbaka. Då anser de att de inte får värde för pengarna.

28

5 Analys

Denna analys delas upp i två delar där den första fokuserar på att analysera respektive företag

för att sedan i den andra delen jämföra samtliga faktorer i den agila processen mellan de olika

företagen.

5.1 Företagsanalys

5.1.1 Precisit

5.1.1.1 Agil utveckling

Återkoppling, kravhantering och kundens vilja i att vara en del av den agila processen belyses

av Precisit som de viktigaste delarna i den agila processen. Kundinvolverandet belyses därav

tydligt som en essentiell del från konsultens sida. Det som främst saknas i den agila processen

menar Precisit är tidsestimering av krav. Detta framhäver ett behov av ett verktyg för att belysa

komplexiteten i uppgiften, men även möjligheten att kunna argumentera för särskilda alternativ

i syfte att leda arbetet i lämplig riktning och ställa motkrav. Det visar även på att det finns

svårigheter att applicera en helhetsbild på projektet och svårt att veta vad som möjligt att

implementera inom projektramen.

5.1.1.2 Lära känna kund

Inom de projekt Selg (2016) arbetat med har kundkännedom antingen funnits som ett resultat

av tidigare haft branschkunskap eller som i nuvarande projekt att testgruppen fungerar som en

brygga till kunden med verksamhetskunskap. För att bygga tillit inför projektet arbetar Precisit

genom att presentera tidigare projekt, vilket visar på en mekaniskt förtroende som upprättas,

där man skapar ett förtroende istället för att inge det. De tidigare projekten används på så sätt

för att inge ett intryck av att deras projekthantering är lyckade och pålitliga samt skapa en

positiv bild och påverka kundens förväntningar på företaget. Detta kan räcka för att vinna ett

uppdrag, men kan inbegripa svårigheter i att skapa ett förtroende eftersom det kan ses som

tomma ord och ingen verkan. Precisit belyser även att det sällan görs prototyper i brist på tid.

Dock hade en prototyp påvisat deras praktiska färdigheter och kunskaper, som i sin tur inger ett

förtroende och tecken på genomförbarhet av projektet i det långa loppet.

5.1.1.3 Krav

I de fall konsulterna upptäcker att kundens initiala förväntan inte överensstämmer med deras

behov förbereds en generell lösning. Detta visar på att konsulterna fokuserar på att följa

kundens efterfrågan istället för att fokusera på kundens behov. Samtidigt finns en öppenhet för

29

förändring av produkten, men detta visar på att man som systemutvecklare utför det som

förväntas av en och lägger därmed inte fokus på vad de själva identifierar som kundens

egentliga behov. Det finns på så vis utrymme för konsulterna att fokusera i större utsträckning

på att framföra vad de identifierat som behov i syfte att öka förståelse och skapa en kravdialog.

Selg menar att kraven prioriteras generellt av systemutvecklarna som i första hand behandlar

funktion, framför användarvänlighet och design och vad de tror att kunden önskar sig vilja ha

först. Att funktionella krav prioriteras framför icke-funktionella krav kan vara ett resultat av att

det är svårt att specificera användarvänlighet i en kravspecifikation. Samtidigt ligger

användarvänligheten i slutanvändarens öga och något som en systemutvecklare har svårt att

utvärdera och prioriteras därmed inte i första hand.

Vidare belyser Precisit att en tydlig och detaljerad kravspecifikation kan resultera i att

kunden blir mindre involverad. Detta kan bero på ett flertal faktorer såsom avsaknad av nära

relation till utvecklingsgruppen och att en god kundkännedom inte har uppnåtts utan enbart en

verksamhetsförståelse genom testarna. Avsaknad av nära relation resulterar i ett minskat

förtroende för parterna under arbetet som Bridge Global (2012) nämner. Samtidigt belyser

Fitzgerald, Hartnet och Conboi (2008) att regelbundna möten krävs för att uppnå en god

kunddialog och möjligheten att ändra kraven. Däremot visar detta inte vara tillräckligt då

testarna även kan skapa en kulturell och social barriär mellan kunden och systemutvecklarna.

Det kan även bero på, som Precisit nämner, att produkten sakta växer fram i kundens ögon och

att tankar och idéer inte har formats än i ett tidigt skede och därmed blir mindre involverad.

5.1.1.4 Kunddialog

Precisit beskriver att kundens tillgänglighet är essentiellt för projektet i relation till de

utvecklingscykler som tillämpas på veckobasis, och används som ett motkrav från

utvecklingsgruppen. Detta är något som Highsmith (2004) även instämmer med och beskriver

som en förutsättning för att skapa en god relation. I de projekt Precist arbetat med har projekten

haft en tydligt definierad målbild och därav inte haft ett behov av kontinuerlig återkoppling

initialt. Initiering av ramverk och uppbyggnad av en skelettstruktur genomförs därav relativt

självgående utan behov av kunddialog. Precisit menar att en diskussion behöver genomföras

när kunden och konsulten har svårigheter med att förklara hur en funktionalitet ska utvecklas.

På grund av det geografiska avståndet mellan parterna använder de sig av visuella möten i form

av videokonferens, vilket är i linje med vad Draft et al. (1987) förespråkade.

5.1.1.5 Hantering av barriär mot kund

Krav och önskemål om förändringar i projektet hanteras genom testgruppen som transformerar

önskemål till uppdrag åt konsulterna och på samma sätt omvandlas utvecklarnas åsikt om

30

genomförbarhet till kundens verksamhetsspråk. Testgruppens funktion blir därav att

sammanknyta kunden och utvecklingsteamet genom att fungera som länken och filtret mellan

de två parterna. Filtreringen överkommer svårigheter med avsaknad av domänspecifik

förståelse, då de även fungerar som översättare med kunskap inom respektive domän. Detta

tyder på att testgruppen överkommer både kunskapsbarriärer och lingvistikbarriärer. Vidare har

testgruppen en förståelse genom att ha verkat i båda branscherna, och kan därmed spegla ett

förtroende och kulturell samhörighet där de träder in i olika roller i form av att vara läkare och

systemutvecklare i diskussionerna. Kunden såväl som konsulterna känner på så vis samhörighet

med testgruppen och testgruppen kan i sin tur identifiera sig i deras situationer.

I de fall Precisit inte har tillgång till branschspecifik kunskap menar han att det är hans

ansvar som konsult att överkomma befintliga barriärer, såsom i önskemålet av en

realtidslösning. Detta är ett exempel på en kunskapsbarriär som testpersonerna överkommer

med sin tekniska kunskap inom systemutveckling. Testgruppen kan dock utgöra ett hinder i den

sociala barriären där systemutvecklarna inte får direkt anknytning till kunden och inte kan

framföra direkt feedback utan att det sköts genom mellanhänder. På så vis finns det risk för att

essentiell information inte når fram och att konsulten inte lär känna kunden på ett personligt

plan.

5.1.1.6 Utvärdera kundnöjdhet

Precisit beskriver att den slutgiltiga betalningen av produkten och att fler krav inte inkommit

innan produkten blivit färdigställd tyder det på att kunden är nöjd. Detta påvisar att Precisit

utvärderar kundnöjdheten genom att uppfylla kravspecifikationen som levererats samt möta

kundens förväntningarna genom att vara lyhörda och följa vad kunden vill ha till punkt och

pricka. Genom acceptanstesterna ställs förväntningar och vad kunden vill ha framförallt mot

resultat och kundens behov utelämnas.

5.1.2 Netlight

5.1.2.1 Agil process

Utifrån empirin går det att uttyda en öppenhet för att kompromissa i den agila metoden till

förmån för kundens behov och att ständigt agera alert. Att dialogen är kontinuerlig och ärlig

ger en prestigelös miljö där alla i projektet är med på samma villkor och kommer till tals, vilket

kan förebygga sociala barriärer. På samma sätt menar Netlight att det från kundens sida krävs

en öppenhet för att arbeta agilt, vilket kan kräva omfattande interna omställningar och ett

tankesätt som är i linje med den agila processen. Det går därför att uttyda att närvarande och

samspel av öppenhet och flexibilitet från både kund och konsults sida utgör en viktig faktor.

31

Andersson nämner även att han arbetar med cirka 25 systemutvecklare, vilket medför att

processen i sig inte blir lika agil som önskat. Detta kan tolkas som att han menar att agil

systemutveckling fungerar i små utvecklingsgrupper då det inte krävs lika mycket

synkronisering från lika många intressenter.

5.1.2.2 Lära känna kund

Netlights initiala process med fokus på matchning av företagskultur, arbetsmetoder och

värderingar minskar sannolikheten att kulturella barriärer skulle uppstå enligt Kotler et al.

(2002). Dock visar det sig att traditionella metoder använts i de projekt som Andersson varit

med i, vilket tyder på att Andersson med matchning menar att kunden och Netlight har en

gemensam vision och att nuvarande situation inte är det som avgör utan hur kunden tänker

långsiktigt.

Konsulterna hos Netlight har även möjlighet att välja uppdrag utifrån intresse och

kunskapsbakgrund, vilket skapar en bättre förutsättning för att det ska bli en god matchning.

Detta visar på att företagsmatchningen inte enbart är väsentlig utan även att personerna inom

projektet har ett gemensamt intresse. Ett informellt möte mellan konsult och kund genomförs i

syfte att kontrollera att uppdraget är i enlighet med konsultens förväntningar och kundens

önskemål. Andersson belyser vikten av att konsulten är ärlig med att inte vara expert på allting,

vilket de överkommer genom problemlösning och ambitioner. På så vis etableras ett förtroende

där kunden förstår konsulten och deras ambitioner i projektet och gentemot dem som kund.

Utöver kunskap och intresse belyses även från Netlights sida personkemi som en viktig faktor,

vilket överkommer sociala barriärer. Genom att spegla kunden i hur den sitter och andas, lär

sig konsulterna att förstå kundens agerande och uppträdande vilket möjliggör identifiering av

karaktärer och beteendemönster i olika situationer som Gulati & Olroyds (2005) tar upp. Detta

underlättar för identifiering av situationer där kunden inte förstår konsulten, vilket tydliggör

behov av förtydligande.

5.1.2.3 Kravspecifikation

Identifiering av samtliga parter belyses från Netlights sida som nyckeln till att skapa en lyckad

kravhantering. De belyser dock i ett annat sammanhang att det finns en risk att information hos

en kund med hierarkisk organisationsstruktur går förlorad då individer längre ner i hierarkin

inte vågar uttrycka sig. Det finns även risk för att nyckelpersoner är frånvarande enligt Netlight.

Konsulterna behöver därav information om kundens hierarkiska struktur samt identifiera och

uppmuntra till spridning av specifik kunskap hos nyckelpersoner i syfte att förebygga sådana

händelser.

32

Vidare har kravinsamlingens interaktiva sessioner möjlighet att eliminera befintliga

kunskapsbarriärer genom att via visualisering, formulera ett problem på en enklare nivå vilket

i sin tur leder till att den lingvistiska barriären minimeras. I fall då kunden önskar krav som är

tekniskt komplexa eller går utanför ramarna av resurser, behöver konsulten sätta stopp genom

att ställa motkrav i form av projektkrav vilka är tid, omfattning och pengar. Motiveringen bör

ske med visualisering i syfte att eliminera de befintliga kunskapsbarriärerna. Idag prioriteras

funktionella krav framför krav som berör icke-funktionella. Att funktionaliteten identifieras

som viktigast kan vara ett resultat av att den främsta dialogen med kunden är gentemot

beställare och inte slutanvändaren.

5.1.2.4 Kunddialog

Då kunddialogen är regelbunden och intensifieras närmare slutfasen av projektet kan en

öppenhet för att arbeta agilt identifieras. Dock belyser Netlight att kundens tillgänglighet i

sådana situationer kan upplevas bristfällig på grund av otillräckligt engagemang och

frånvarande av nyckelpersoner. Därmed finns det ett behov av att lära känna kunden och

noggrant identifiera samtliga intressenter och nyckelpersoner för att förebygga att projektet

stagnerar i en sådan situation och förstå kundens agerande. Detta visar på vikten av att kundens

drivkraft och engagemang är väsentlig och något som Barki och Hartwrick (1994) nämner som

saknas i detta fall.

Eftersom konsulterna sitter hos kunden sker kunddialog och återkoppling utifrån

behovsbasis. Samtidigt förstärker den fysiska närvaron konsulternas relation till verksamheten,

vilket i sin tur möjliggör identifiering av kulturella barriärer. Det vill säga vilka aktörer vars

information riskerar att gå förlorad som ett resultat av hierarkisk organisationsstruktur.

Närvarandet möjliggör även för projektets medlemmar att överkomma sociala barriärer då det

finns större utrymme till att lära känna varandra gentemot fallet då konsulterna är stationerade

hos Netlight. Samtidigt har det visat sig enligt Netlight att det varit otillräckligt engagemang

från kundens sida, vilket visar på ett missförstånd angående hur mycket man förväntat sig att

de ska vara tillgängliga genom att detta inte kommunicerats ut till kunden. På så vis kan sociala

barriärer identifieras trots att konsulten befunnit sig i samma lokaler som kunden.

Vidare belyses att slutanvändarnas nya krav tenderas att tas i beaktning under

nästkommande iteration. Detta påvisar att slutanvändarna inte har möjlighet att påverka

kravspecifikation, eftersom återkopplingen kommer i slutfasen av utvecklingscykeln.

5.1.2.5 Hantering av barriärer mot kund

Netlight menar att ett projekt ofta involverar personer med domänspecifik kunskap såsom

verksamhetskunskap samt teknisk kunskap inom systemutveckling vilka tenderar att agera

33

översättare i syfte att undvika missförstånd. Översättarna hjälper konsulterna att överkomma

kulturella och kunskapsmässiga barriärer. Det finns dock en risk för att konsulterna hamnar i

beroendeställning till översättarna på grund av deras tvärvetenskapliga kompetens.

Översättarna har huvudsakligen en annan roll och kan därav inte ständigt finnas tillgängliga att

hjälpa konsulterna med verksamhetsspecifika frågor.

Att Netlight underhåller en ordlista med förkortningar visar på drivkraft till att minska

de kulturella och branschspecifika barriärerna som finns gentemot kunden och något som

Galison (1999) även förespråkar. Sociala barriärer förebyggs med hjälp av gruppaktiviteter som

anordnas både från Netlights och kundens sida. Att lyfta en medarbetare som gjort någonting

bra är även en metod som tillämpas som hjälper att överkomma de sociala barriärerna. Vidare

påpekar de att det är viktigt att leverera det som utlovas, vilket kan fungera som ett sätt att

bibehålla förtroende.

5.1.2.6 Utvärdera kundnöjdhet

Andersson använder i dagsläget inget specifikt ramverk eller teknik för att mäta kundnöjdhet

då han menar att det ska kunna återfås via kunddialog. Det bygger på att kunddialogen

genomsyras av öppenhet och ärlighet, samtidigt som det kan vara svårt att garantera att kunden

är öppen menar han. Netlight menar även att huruvida kunden är nöjd inte är ett resultat av att

produkten är perfekt utan att majoriteten av produkten har levererats. Detta belyser att konsulten

tolkar förtroendet i form av att hålla vad som lovas prioriteras högre än att produkten blir perfekt

enligt kundens mått.

5.1.3 Accigo

5.1.3.1 Agil utveckling

Inom det projekt Brehm arbetar med går det att uttyda ett varierat engagemang från kunden

som beror av deras uppfattning om huruvida projektet fortlöper som önskat. Därmed beror

kundinvolverandet på kundens uppfattning av projektets status, vilken nödvändigtvis inte

överensstämmer med konsultens. Det går därmed att uttyda en avsaknad av kontinuerligt

engagemang, trots att Accigo menar att kunden är villig att arbeta agilt. De belyser att minskat

engagemang innebär att de inte kan förklara vad som levereras, vilket kan tolkas som att Accigo

är väldigt måna om att kunden förmåga att äga produkten intellektuellt och inte funktionaliteten

enbart.

Vidare kan införandet av inför-iterationsmöten tyda på en önskan om ökad effektivitet

av iterationsplaneringen som Accigo menar oftast tar för lång tid. Totalt är en iteration tre

veckor lång. Detta kan vara ett resultat av att kunden inte varit tillräckligt involverad. Vidare

34

nämner Brehm avsaknaden av effektivitet och struktur som en brist hos det agila ramverket

vilket i sin tur kan generera svag ledning. Önskan om ökad styrning kan tolkas som ett resultat

av saknat engagemang från kundens håll, vilket ger upphov till färre kontaktytor än önskat och

avsaknad av direktiv från kunden. Kundens bristande involvering har resulterat i att konsulterna

själva tolkar hur funktioner ska implementeras samt prioriteras. Accigo belyser en huvudplan

för vad projektet ska leda till som önskvärd i syfte att förebygga svag ledning i projektet, men

kan även ses som resultat av att svagt engagemang och feedback som konsulterna vill ha en

plan för vad projektet ska leda över.

5.1.3.2 Lära känna kund

Accigo belyser att kunden vill genomföra ett projekt med konsulter de kan lita på, vilket visar

på att förtroende uppstår mellan individer och inte direkt till ett företag. Accigo visar därmed

på en medvetenhet om sociala barriärer som kan mitigeras via förtroendeskapande. Vidare

presenteras verksamheten och dess framgångsfaktorer vid ett första möte för att ge en bild av

företagets bakgrund och förmåga att ansvara och tackla nya utmaningar, samtidigt som det

skapar ett förtroende istället för att det inges. Denna situation visar inte på ett risktagande som

kan uppstå vid en osäkerhet som karakteriserar förtroende, utan beskriver en lovande situation.

De initiala möten som går inom ramarna för att lära känna kund blir desto detaljrikare

över tid och involverar parter såsom arkitekter. Detta skapar utrymme för laborativt arbete

vilket möjliggör minskning av eventuella kunskapsbarriärer och kulturella barriärer genom att

träffa olika personer och få en bättre helhetsbild. Utöver ökad kundkännedom ges även kunden

möjlighet att få en uppfattning av vilka typer av personer de arbetar med, vilka erfarenheter de

har och om de har förståelse för deras problem. Därmed kan både konsulten och kunden bilda

sig en uppfattning om kundens problem och stämma av huruvida de har en gemensam bild av

problemen och kundens behov.

5.1.3.3 Kravspecificering

Under kravsessionerna belyses visualisering som ett väsentligt verktyg för att undvika

missförstånd och generera samsyn och på så vis överkomma lingvistiska och kunskapsbarriärer

och låta skisser tala för sig. Detta är ett verktyg där konsulten upplever att kundens förväntan

inte överensstämmer med deras behov kan användas. Ett lösningsförslag skapas sedan av

personer med teknisk kunskap utifrån åsikter och beslut från sessionerna, vilket innefattar en

kravlista med tillhörande skisser. Materialet är därmed ett pedagogiskt resultat av

samproduktion mellan kund och konsult som underlättar kunskapsdistribution för involverade

parter. Den slutliga summeringen har som funktion att förebygga eventuella missförstånd vilket

Accigo menar stärker befintligt förtroende. Detta kan tolkas genom att summeringen utgör ett

35

sätt att stämma av huruvida de har en gemensam målbild och förstår varandra. Dock finns det

risk för liksom Brehm exemplifierat att kunden är villig att spendera en bråkdel av

rekommenderad tid på förundersökning. Sessionerna ger därmed möjlighet att hantera

befintliga barriärer, men till vilken utsträckning en sådan förundersökning kan genomföras

beror på kundens förutsättningar och när produkten behöver levereras. I detta fall fanns en kort

tidsplan.

De krav som kan komma från konsultens sida berör oftast kundens engagemang. Ett

exempel belyser hur Accigo efterfrågade en förankring och ett beslut av den person som hade

mandat och skulle ta ägarskap för den berörda delprodukten. Motkravet kan därmed

karaktäriseras som ett verktyg till att förebygga eventuella hinder och effektivisera

utvecklingsprocessen. Att konsulten tar fram förslag till prioritering visar på bristande

engagemang från kundens sida. Vid önskan om ställningstagande från kunden presenterar

konsulten samtliga alternativ, vilket visar på avsaknad av samproduktion. Tidsestimering av

krav kan fungera som ett verktyg till motivering av särskilda alternativ samt vid ställanden av

motkrav.

5.1.3.4 Kunddialog

Kunddialogen förs via respektive arbetsström på veckobasis eftersom det skapar kortare

kommunikationsvägar och kan visa på öppenhet och tillgänglighet. Vidare har tillgänglighet

från kunden sida enligt Accigo inte varit som önskat och ibland har projektet stagnerat på grund

av att produktägaren eller projektledaren varit frånvarande. Trots att konsulterna arbetade på

plats hos kunden och att en lokal bokats till respektive möte genomfördes kommunikationen

främst via videokonferens. Detta visar på en öppenhet till ökad interaktion från kundens sida

men avsaknad av engagemang. Kunden har istället föredragit att träffas över virtuella möte

jämfört med ett fysiskt möte, vilket dels tyder på att man avhållit sig att träffas i person i ett

gemensamt rum och dels tyder på att sociala barriärer finns och en samhörighet saknas.

Avsaknaden av samhörigheten kan bero på att kommunikationen sker genom respektive

arbetsström, och att alla intressenter inte involveras eftersom det bygger på vem kunden väljer

att samtala med. Detta kan innebära att det finns svårigheter att skapa en personlig relation, då

dialogen sker mellan olika personer över tid, att kunddialogen bygger på kundens initiativ och

att det inte finns någon utsedd person som föra dialogen mellan kund och utvecklingsgruppen.

Kravdiskussion belyses av Accigo som ett vanligt förekommande moment inom

kunddialog, men däremot förskjuts eventuella förändringar till nästkommande iteration vilket

belyser en rigid utvecklingsprocess och mindre flexibilitet. Dock kan ytterligare

36

funktionaliteter lyftas in om utvecklandet fortlöper snabbare än beräknat vilket gör

tidsestimering till ett nödvändigt verktyg.

5.1.3.5 Hantering av barriärer mot kund

Accigo belyser vikten av att konsulten förstår kundens verksamhetsspråk genom exemplet med

arkitekten som använt domänspecifikt språk och i sin tur skapat lingvistiska barriärer och

kunskapsbarriärer. Att utomstående parter använder begrepp och ett språk som kan uppfattas

abstrakt kan tolkas som en kunskapsbarriär samtidigt som språket som uppfattats som

akademiskt kan tolkas som en lingvistisk barriär i synnerhet och kulturell barriär kring hur man

förhåller sig till den akademien. Verktyg Brehm uppmärksammar i syfte att överkomma

kommunikationssvårigheter är att tillämpa metaforer och kontrollfrågor. Detta menar Accigo

visar på att konsulten är mån om kundens åsikter, vilket i sin tur kan generera förtroende.

Visualisering är ett ytterligare verktyg som kan hjälpa och minimera befintliga barriärer genom

att kommunikation via ett förenklat språk som är mottagligt för flera parter.

Ytterligare lingvistiska barriärer kan uppstå som ett resultat av att kunden verkar i ett

internationellt företag. I syfte att förebygga missförstånd hos kunden används koncernspråket i

dialoger för att säkerställa att korrekt information förmedlats. Andra typer av barriärer som

existerar hos kunden är sociala och kulturella vilka kan återfinnas i exempelvis att en del av

kundgruppen är från Finland där svar inte tenderar att bli utbroderade. Vid eventuella

missförstånd menar Accigo att kunden alltid har rätt, vilket i sin tur leder till att konsulten får i

uppdrag att utveckla en känslighet för missförstånd i syfte att undvika dem. I kontexten att

uppehålla och bygga förtroende kan utvecklandet av en sådan känslighet snarare tolkas som ett

försök att undanhålla information vilket i sin tur motarbetar en öppen och ärlig dialog.

5.1.3.6 Utvärdera kundnöjdhet

Vid mätning av slutlig kundnöjdhet fokuserar Accigo på att genom avskalade undersökningar

generera hög svarsfrekvens. Frågorna fokuserar på huruvida kunden skulle rekommendera

Accigo till någon inom kundens nätverk, vilket kan tolkas som att fråga huruvida kunden skulle

återkomma till Accigo vid behov och är enligt Bergman & Klefsjö (2010) en god indikation på

att kunden återkommer. Accigo belyser även att det märks om kunden inte är nöjd genom

klagomål rörande timmar och pengar vilket omfattas av projektkrav.

5.2 Komparativ analys

5.2.1 Agil utvecklingsprocess

37

Inom samtliga företag belyses kundens vilja och engagemang till att arbeta agilt som en

essentiell del i syfte att uppnå ett framgångsrikt projekt, vilket är i enlighet med Agile Manifesto

(2001). Detta kräver ett tankesätt som är i linje med den agila processen som inkluderar

flexibilitet och öppenhet för förändring, vilket kan vara svårt att identifiera inom studerade

projekt där kunderna vanligtvis applicerar en traditionell utvecklingsprocess. Därmed kan

identifiering av en agil process som fungerar för samtliga medarbetare inom ett projekt uttydas

som ett viktigt moment i tidigt skede. Inom samtliga projekt som studien belyser har den agila

utvecklingsprocessen antagit olika former och varit sammansättningar av olika verktyg som

prioriterats inom respektive projekt. Dock finns det ytterligare utrymme till att i större

utsträckning involvera kunden i beslut om utformande.

Vidare går det att uttyda olika önskemål om projektets strukturella utformning. Precisit

önskar en helhetsbild på projektet i syfte att inte förbise de långsiktiga målen vilken de menar

saknas i den nuvarande utvecklingsprocessen. Accigo belyser konkreta åtgärder såsom ökad

styrning och en huvudplan, vilket kan ses som ett resultat av bristande kundengagemang och

för att kompensera om kundengagemanget är svagt. Detta löstes exempelvis via inför-

iterationsplaneringen. Netlight belyser vidare att kringliggande planering behövs i projekt ju

fler utvecklare som är involverade, vilket ger upphov till en mindre agil process. Detta innebär

att Netlight menar att det är storleken på projektet som avgör agiliteten hos projektet. Sedan

belyses även risker med att arbeta “för” agilt från både Netlight och Accigos sida. Netlight

belyser en risk i att överarbeta det agila, för att visa mätningar på hur framgångsrik den agila

processen är medan Accigo menar att ramverket inte behöver följas till punkt och pricka

samtidigt som hans medarbetare vill det. Detta innebär att Netlight poängterar vikten av att

fokusera på kunddialog, genom att kunna erhålla återkoppling och inte att visa upp diagram och

siffror för sakens skull. Därav belyser Netlight vikten av en balansgång mellan fokus på

leveransen av produkten och uppehälle av den agila processen. Accigo belyser problemet med

att jobba för agilt inom sitt utvecklingsteam medan Netlight belyser problematiken med att

jobba för agilt med kunden. Olika intressenter är olika villiga att arbeta agilt och detta är viktigt

att diskutera innan projektet påbörjas, något som Guneskaran (1999) även framäver.

Den agila processen innefattar utifrån konsulternas perspektiv därmed inte ett ramverk

med metoder som är essentiella inom utvecklingsprocessen. Önskemål och tidigare erfarenheter

av att arbeta agilt behöver även tas i beaktning. Återigen tyder detta på att konsulterna i

samproduktion med kunden kan komma närmre den optimala agila utvecklingsprocessen givet

tidigare erfarenhet. Detta kan i sin tur fylla funktionen som konsulterna önskar i form av ökad

struktur då det ger en tydligare bild av hur kundinvolverandet kommer att utformas under

projektet.

38

Tidslängden på iterationerna varierar även mellan företagen och respektive projekt från

en vecka till tre veckor för Accigos del. Det går därmed uttyda att det inte finns en specifik

längd på iterationer. Netlight menar att allt för frekventa iterationer oroar kunden och på så vis

går det inte ha kortare iterationer och större kundinvolvering medan Accigo nämner att tre

veckor är en tidsperiod som upprättats på grund av avsaknad av kundengagemang. På så vis

finns ett dilemma, till vilken grad kommunikationen och interaktionen ska ske och upprätthållas

med kunden som även Pikkarainen et al (2008) uppmärksammade.

5.2.2 Lära känna kund

Konsulterna applicerar olika strategier inför ett projekt i syfte att inge förtroende och lära känna

kunden i förtroendeskapande syfte. Precisit inger ett förtroende via referensobjekt och Accigo

genom att berätta om vilka framgångsfaktorer de haft i syfte att försäkra kunden om

genomförbarhet av önskat projekt. Kunden får på så vis en bild av konsulten medan konsulten

inte lär känna kunden via denna metod. Därmed begränsas möjligheter till att identifiera

svårigheter och möjligheter, förstå uppträdande och agerande vilket Gulati och Oldroyd (2005)

förespråkar via ökad kundkännedom. Netlight å andra sidan implementerar en utarbetad process

i syfte att lära känna kund samt på samma sätt ge kunden en chans att lära känna konsulten. De

olika momenten som processen inkluderar ger parterna möjlighet till att utföra en matchning av

lämplig konsult till kunden. Via det informella mötet ges konsult och kund möjlighet till att lär

känna varandra på ett personligt plan. I ett tidigt skede kan Netlight med denna process

identifiera eventuella barriärer på ett socialt och kulturellt plan. Ytterligare ett verktyg Netlight

tillämpar är att via utbildning lära konsulterna förstå kundens agerande och uppträdande vilket

i sin tur ökar möjligheten till att identifiera eventuella kunskapsbarriärer och sociala barriärer.

Accigo tillämpar ett liknande tillvägagångssätt i syfte att lära känna kund med avsaknad av den

systematiska matchningen av konsult och projekt som Netlight använder. Dock menar Brehm

att de på Accigo i tidigt stadie kan involvera personer med domänspecifik kunskap i laborativ

miljö vilket kan resultera i minskande av eventuella barriärer. De initiala momenten Accigo

och Netlight använder ger möjlighet till att få en gemensam bild av problemen och kundens

behov. Att Netlight till skillnad från Accigo och Precisit har möjlighet att tillämpa en

systematisk matchningsprocess där konsulten kan utgå från preferenser och kunskap kan bero

på att de är betydligt fler anställda och varit verksamma länge och har därmed en större

kundkrets. Översiktligt kan komponenten som består av att lära känna kund karaktäriseras som

en icke central del i undersökningsmodellen hos Accigo och Precisit.

39

5.2.3 Kravspecifikation

Samtliga företag använder interaktiva sessioner initialt i projektet för att via samproduktion

utreda och sammanställa krav. De interaktiva sessionerna kan tolkas som ostrukturerade

intervjuer vilket förespråkas av Dieste et al (2008) med inslag av kreativa moment. Det

slutgiltiga materialet för kravspecifikation tenderar dock att formas och utarbetas på olika sätt

från detaljrikt till översiktligt. Precisit belyser även att dem använder och kompletterar

eventuellt befintligt material medan Netlight arbetar från start tillsammans med kunden att

skapa en detaljerad kravspecifikation. Inom Accigo tar de snarare avstånd från

kravspecifikation i en traditionell bemärkelse och tar istället fram tillsammans med kunden ett

lösningsförslag. Från Accigos håll är detta en metod att via laborativt arbete ta fram ett

pedagogiskt material med skisser och kravlista vilket kan spridas internt. Detta underlättar i sin

tur för att återfå feedback från eventuella intressenter hos kunden som inte lyckats identifieras

initialt. Dock har kunder inte visat sig vara villiga att spendera tillräcklig tid till

förundersökningen, vilket kan vara ett resultat av att det presenteras som ett fristående moment.

Inom Netlights och Accigos fall har kravinsamlingen och de initiala momenten uppfattats i

större utsträckning som en del av projektet. Detta är ett essentiellt moment som via

samproduktion och interaktiv framtagning av krav kan hjälpa kunden att förstå deras behov,

vilken i huvudsak genomförs initialt i processen likt specificerat i undersökningsmodellen.

Netlight belyser att samtliga berörda intressenter bör involveras i kravspecificering, medan

Accigo belyser att de personer som har mandat att ta beslut främst bör involveras. Att involvera

intressenter samt aktörer med mandat och inte enbart beställaren som i Netlights och Accigos

fall, visar på att en IT-lösning är påverkar flera delar av en verksamhet och att det inte handlar

om att enbart hitta en rätt teknik utan även transformera hur människor arbetar och

kommunicerar.

Vidare handlar de flesta krav från konsultens sida om projektkrav, vilket respondenterna

menar motsvaras av tid, omfattning och pengar i enlighet med Microsoft (2016) och ställs ofta

som motkrav när kunden exempelvis uttrycker önskemål om ytterligare systemkrav. Ytterligare

ett medel som Accigo och Precisit uttrycker att de använder är att ställa krav i form av

engagemang, att de efterfrågar förankring hos kunden i en fråga. Detta kan utvecklas ytterligare

för att ställa krav angående engagemang i form av återkoppling och involverande.

5.2.4 Kunddialog

Tillgänglighet och flexibilitet från konsultens sida kan uttydas inom samtliga företag som en

metod för att uppehålla den agila processen inom utvecklingsarbetet. Highsmith (2004)

framhåller tillgängligheten som en förutsättning för att skapa relationsband, något som Precisit

40

använt som motkrav för att kunna arbeta agilt. Kunddialog belyses inom samtliga studerade

projekt som en essentiell komponent genom hela projektet. Precisit visar på öppenhet till att

förändra krav inom iterationen, vilket även Kautz (2009) menar kan ske sent i utvecklingsfasen.

Dock belyser Brehm (2017) och Andersson (2017) att förändringar av krav träder i kraft under

nästkommande iteration. Därmed är de mottagliga för förändringar av krav när som helst under

projektet, men med fördröjning av implementering av förändringen.

Vidare belyser Kotler (2001) kundens personlighet, drivkraft och engagemang som

betydelsefulla i syfte att uppnå ett framgångsrikt projekt. I Netlights fall har personligheten och

personkemin varit väsentlig, medan i Precisit’s fall så har engagemang och drivkraft varit

väsentlig och i Accigos har ingen av dessa varit avgörande. Vidare är visuella möten en metod

för att skapa samproduktion och möjliggöra för visualisering vilket har genomförts inom

samtliga projekt.

5.2.5 Hantering av barriärer mot kund

Barriärer hanteras inom Precisit och Netlight med specifika personer som agerar medlare.

Precisit har en dedikerad testgrupp med ansvar att fungera som en kommunikationslänk mellan

konsult och kund. Denna grupp innehar domänspecifik kunskap inom verksamheten samt

systemutveckling, vilket gör att de kan ha förståelse för respektive part i frågor och på så vis ge

ett sammanvävt perspektiv till diskussioner. Medlaren i Netlights fall är en person som i övrigt

arbetar med exempelvis krav eller projektledning och har övergripande kunskap inom samtliga

områden. Detta visar på ett mindre strikt förhållningssätt till vilken utsträckning medlare

tillämpas.

I syfte att förebygga den beroendeställning som kan uppkomma till medlaren bör de

snarare ses som en resurs till att öka kunskap om kunden och verksamheten istället för att enbart

använda de som filter. På så vis kan även sociala barriärer överkommas då de kan inneha olika

roller i olika grupper, vilket påverkar vilket typ av inflytande och beteende som utövas i enlighet

med Kotler et al. (2002). Inom Accigo belyses snarare metaforer, kontrollfrågor och

visualisering som verktyg i syfte att överkomma barriärer. Metaforer och visualisering har som

funktion att förenkla komplexa beskrivningar, vilket i sin tur tar bort lingvistiska barriärer och

minskar kunskapsbarriärer. Ytterligare verktyg som tillämpas i syfte att minimera lingvistiska

barriärer är att använda kundens koncernspråk inom samtliga kommunikationskanaler. Även

experter inom olika områden såsom designer och arkitekter används för att förstå deras

specifika problem och behov. Däremot är det viktigt att poängtera att det nödvändigtvis inte är

expertisen som överkommer hindren från att förstå behoven utan det är genom själva dialogen.

Därmed bör fokus vara på att identifiera förmågan hos en person att förstå kundens språk och

41

skapa ett klimat som gör att kunden är öppen att dela med sig av sina tankar. Att kunna göra

sig förstådd och förstå andra personer är en expertis i sig och kräver ingen specifik roll.

Ett verktyg som Netlight är ensam om att tillämpa är en ordlista av verksamhetsspecifika

termer i syfte att öka kundkännedom och bidra till att minimera kulturella barriärer. Netlight

skapar även sammanhållning gentemot kunden via gruppaktiviteter, uppmärksamma

prestationer från medarbetare och att hålla det som utlovas. Enligt Bridge Global (2012)

resulterar sammanhållningen i sin tur i förtroende som kan minska kulturella och sociala

skillnader. Brehm menar att en känslighet snarare utvecklas i syfte att undvika missförstånd

som ett resultat av sociala barriärer. Därmed går det att uttyda att Accigo snarare utvecklar ett

verktyg för att hantera och reagera gentemot de sociala barriärerna istället för att minimera dem.

I Precisits fall kan testgruppen istället ge upphov till sociala barriärer då konsulterna inte får en

direkt relation till kunden, men inger förtroende eftersom de utvecklat en samhörighet med

kunden. Vikten av att överkomma de sociala barriärerna kan identifieras i att en samhörighet

leder till ärlighet och förtroende inom utvecklingsprojektet. Därmed kan medarbetarna

tillsammans komma närmre en produkt som i slutändan avspeglar kundens behov via

transparens. Samtliga respondenter pekar på att det är konsulternas ansvar att överkomma

barriärer vilket ger ytterligare motiv till att använda verktyg och metoder vilka har som funktion

att minimera barriärer.

5.2.6 Utvärdera kundnöjdhet

Utvärdera kundnöjdhet är den komponent i undersökningsmodellen som förekommer sist i

processen i syfte att utvärdera projektet. Bergman & Klefsjö (2010) belyser att kundnöjdheten

ökar sannolikheten för att en kund återkommer och rekommenderar företagets tjänster till andra

kunder. Detta är ett mått som Accigo tillämpar för att uppnå kundnöjdhet genom

enkätundersökning likt vad Echeverri & Edvardsson (2002) förespråkar. Till skillnad från

Accigo mäter Precisit och Netlight kundnöjdhet genom att uppfylla kravspecifikationen som

levererats. Skillnaden emellan kan belysas i att Precisit fokuserar på kvantiteten genom att

uppfylla samtliga krav medan Netlight utöver kvantiteten även använder sig av ett kvalitetsmått

genom att försäkra att 80 % av resultatet är hög kvalitativt. Vidare menar McNeale (1994) och

Gustafsson (2009) att mätning av klagomål inte genererar ett relevant mått på kundnöjdhet.

Däremot menar Accigo och Precisit att detta kan mätas under kunddialogen, genom att en

diskussion sker kring resultatet kontra de förväntningar som finns. Accigo exemplifierar det i

att kunden börjar dividera med pengar fram och tillbaka och Selg anser att klagomålen oftast

framkommer om de inte vill godkänna acceptanstesterna. Netlight har även insett att kunder

42

ofta tar avstånd från att klaga, men genom att kunddialogen genomsyras av öppenhet och

ärlighet så kan man förebygga att missnöje kommer i skymundan.

43

6 Slutsats

Syftet med studien var att undersöka hur konsulter inom systemutvecklingsföretag arbetar med

att sammankoppla förväntan och behov i en agil utvecklingsprocess och förstå hur kundnöjdhet

utvärderas. Undersökningen har genomförts med tre IT-konsultföretag och baserats på

intervjuer med IT-konsulter. De faktorer som har identifierats som konsulten använder sig för

att hjälpa kunden att förstå deras verkliga behov är: förtroendeskapande, medel för att

överkomma barriärer, laborativt skapande av kravspecifikation, motkrav samt tillgänglighet

och flexibilitet. Metoderna appliceras i olika utsträckning inom de olika företagen, där Netlight

och Accigo är framstående vad gäller initialt förtroendeskapande genom att fokusera på att lära

känna kund i tidigt skede. Precisit är å andra sidan framstående i hur de överkommer barriärer

under projektets gång genom medlare i form av en testgrupp med tvärvetenskaplig kunskap.

Studien visar även att sociala barriärer och att lära känna kund inte har varit av största

betydelse för att sammankoppla behov och efterfrågan. Detta eftersom en avsaknad av

engagemang från kunden sida identifierats som ett problem hos samtliga projekt som

undersökts. Detta kan även bero på angreppssättet i de agila projekten består av att påbörja

arbetet och lära känna kunden under tiden. Dock riskeras denna komponent glömmas bort,

vilket leder till att en del företag haft problem med kommunikationen med kunderna. Detta kan

bero på en svag relation till kunden och förståelse för hur kunden arbetar. Genom att lära känna

kunden innan projektet påbörjas, kan konsulter få en förståelse för hur tillgänglig kunden är och

vilken arbetsmetod som passar kunden bäst.

Kundnöjdheten utvärderas med fokus på kvantiteten av antalet uppfyllda krav och

genom kunddialogen under projektets gång hos Netlight och Precisit. Detta speglar att

företagens syn på kundnöjdhet, som fokuserar främst på leverans av produkt och förväntningar

framför att kontrollera att kundens behov uppfylls. Att missnöje även skulle framgå under

kunddialogen är något som Gustafsson (2009) motsäger eftersom ett fåtal av alla missnöjda

kunder faktiskt uttrycker sina klagomål till företaget. Sammantaget finns det ingen specifik

metod att fånga upp kundfeedback på, vilket gör det svårt att säkerställa om kunden är nöjd.

Accigo tillämpar istället en kvalitativ undersökning som fokuserar på huruvida kunden skulle

rekommendera Accigo till någon i deras nätverk. Det finns däremot risk för att kundnöjdheten

i sin tur avspeglar själva samarbetet och inte huruvida behov sammankopplats med

förväntningar.

Denna studie belyser komplexiteten i att definiera en gyllene väg inom agila

systemutvecklingsprojekt för att uppnå kundnöjdhet. Beath & Orlikowski (1994) menar att

44

kundinvolveringen under utvecklingen är väsentlig för att öka nivån av kundnöjdhet, samtidigt

som Version-One (2013) framhäver att företag inte väljer att involvera kunden i lika hög grad.

Studien visar däremot att ett gap i hur begreppet kundinvolveringen tolkas, där konsulten är

villig att involvera kunden i större grad och förväntar sig att kunden är engagerad och delaktig

i projektet medan kunden tolkar begreppet som tillgänglighet vid eget behov och intresse.

45

7 Avslutande diskussion och vidare forskning

Ett viktigt resultat från denna studie som inte går inom ramarna för frågeställningen är att en

anpassning av den agila processen behöver göras efter förutsättningarna för varje specifikt

projekt. Därmed är det inte möjligt att definiera en allmängiltig agil utvecklingsprocess som är

optimal för samtliga tekniska utvecklingsprojekt. Ytterligare en faktor som identifierats som en

brist hos företagen är avsaknad av metod i syfte att identifiera samtliga intressenter i ett tidigt

stadie. Detta belyses som en viktig faktor inom samtliga företag men med avsaknad av faktiska

medel för att nå samtliga intressenter utöver eventuella verktyg som minimerar kulturella

skillnader. Genom att från projektets start nå ut till samtliga intressenter som produkten berör,

ökar möjlighet till att i ett tidigare skede identifiera kundens behov.

Ytterligare en tillämpning som kan användas inom vidare forskning är att applicera en

annorlunda infallsvinkel i form av förändrad definition av kundnöjdhet. Bettercourt et al (2002)

menar exempelvis att kundens upplevelser avspeglar den prestandan hos produkten och

servicekvalitén i hur lösningen levereras. En annorlunda infallsvinkel kan ge upphov till

annorlunda koncept att basera det analytiska ramverket på.

Sedan kan en homogen grupp av företag undersökas istället för en heterogen med

avseende på storlek på företag. Det kan ge utrymme för att utföra en kvantitativ studie med

möjlighet till att generalisera utifrån de metoder som denna studie resulterat i.

Ett perspektiv som kan lyftas ytterligare är att IT-projekt ofta resulterar i

verksamhetstransformationer och påverkar en betydande andel av kundens anställda i avseende

hur de arbetar och kommunicerar. Detta belyser vikten av att involvera samtliga berörda

aktörer. Att snarare se ett IT-projekt som processförändrande än en avskild förändring belyser

vikten av att få en helhetsbild av kunden under projektet. Dessutom utgör kunden i fråga enbart

beställaren av produkten, och de kompromisser och diskussioner som förs kanske inte speglar

helhetsbilden av företaget, utan utgör deras egna perspektiv. Här är det viktigt att

slutanvändaren involveras för att säkerställa kvaliteten och nyttan i produkten. En kritisk faktor

i studien och valet av respondent är att studien inte intervjuar kunden i fråga, utan bara fokuserar

på systemutvecklarens perspektiv. Däremot bygger denna studie inte på en jämförelse mellan

parterna utan utgör snarare en beskrivning av hur systemutvecklaren bemöter en kund och dess

förväntan och behov i en agil utvecklingsprocess. Vidare är det rent konkret svårt att hålla en

intervju med företagets kund eftersom denna information kan vara känslig och kunden är en

sekundär partner och ingen del av systemutvecklingsföretaget i fråga.

46

8 Källförteckning

Abrahamsson, Pekka., Salo, Outi., Ronkainen, Jussi., Warsta, Juhani. 2002. Agile software

development methods review and analysis. 1. uppl. Kaitoväylä: VTT.

Avison, David., Fitzgerald, Guy. 2006. Information systems development. 4. uppl. Berkshire:

McGraw-Hill Education.

Agile manifesto. http://www.agilemanifesto.org/ (Hämtad: 2015-09-25)

Agile Methodology. The Agile Movement. 2008. http://agilemethodology.org/ (Hämtad: 2017-

04-20)

Allabolag. Accigo AB. 2016. http://www.allabolag.se/5566541602/Accigo_AB (Hämtad:

2017-04-03)

Allabolag. Netlight Consulting AB. 2016.

http://www.allabolag.se/5565756227/Netlight_Consulting_AB (Hämtad: 2016-11-03)

Allabolag. Precisit AB. 2016. http://www.allabolag.se/5569615031/Precisit_AB (Hämtad:

2017-04-07)

Barki, Henri., Hartwick, Jon. 1994. Measuring user participation, user involvement and user

attitude. Mis Quarterly, (18:1): 59-82.

Bergman, Bo. Klefsjö, Bengt. 2010. Quality: from Customer Needs to Customer Satisfaction.

Studentlitteratur.

Bettencourt L, Ostrom A, Brown S, Roundtree R. California management review: Client co-

production in knowledge-intensive business services. Graduate Schools of Business

Administration, University of California; 2002;44:100.

Blomqvist, R & Österberg, B .1999. Det kundnära företaget: Att utveckla konkurrenskraft ur

kundrelationer. 1. uppl. Malmö: Liber ekonomi.

47

Echeverri, P. & Edvardsson, B. 2002. Marknadsföring i tjänsteekonomin, Studentlitteratur,

Lund: 45-47.

De Chernatony, L. & McDonald, M. 2003. Creating Powerful Brands. Oxford:238-243

Daft, R. Lengel, R. Trevino, L. 1987. Message Equivocality, Media Selection, and Manager

Performance:Implications for Information Support Systems MIS Quarterly, vol. 11, pp. 355-

366

Dieste, Oscar., Juristo, Natalia., Shull, Forrest. 2008. Understanding the customer: What do

we know about requirements elicitation? IEEE Software. (25:2): 11-13.

Eriksson, Lars Torsten. Wiedersheim-Paul, Finn. 2006. Att utreda, forska och rapportera. 8:2.

uppl. Malmö: Liber AB.

Fitzgerald, Brian., Hartnett, Gerard., Conboy, Kieran. 2006. Customising agile methods to

software practices at Intel Shannon. European Journal of Information Systems, 15: 200-213.

Francino, Yvette. 2015. User story.

http://searchsoftwarequality.techtarget.com/definition/user-story (Hämtad: 2017-03-12)

Galison, Peter. 1999. The Science Studies Reader. Trading Zone - Coordinating Action and

Belief:145-158

Goldkuhl, Göran, 1993, Verksamhetsutveckla datasystem, Linköping: Affärsliteratur AB, 23

Gottesdiener, Ellen. 2007. Software requirements: Using models to understand users' needs.

http://searchsoftwarequality.techtarget.com/tip/Software-requirements-Using-models-to-

understand-users-needs (Hämtad: 2017-04-30)

Gulati, Ranjay. Oldroyd, James B. 2005. The quest for customer focus. Harvard Business

Review. (83:4): 92-101.

Guneskaran, Angappa. 1999. Agile manufacturing: A framework for research and

development. Int. J. Production Economics. Massachusettes: Elsevier, 87-105.

48

Gustafsson, A .2009. Customer satisfaction with Service recovery. Journal of Business

Research, 62, 1220-1222

Hedin, Anna. Ht 1996. Liten lathund om kvalitativ metod med tonvikt på intervju.

Highsmith, Jim. 2004. Agile Project Management: Creating Innovative Products. 2. uppl.

Boston: MA, Addison-Wesley.

Hugo Messer, 2012. Öppenhet och förtroende i offshorerelationer. BRIDGE Global.

http://bridge-global.com/blog/sv/openness-and-trust-in-offshore-relationships (Hämtad: 2017-

04-04)

Hyväri, Irja. 2007. Project Management Effectiveness in different organizational conditions.

Helsinki: School of Economics.

Johansson, Hans. 2007. Determining Project Requirements. CRC Press: 110-111

Kano, Noriaki; Nobuhiku Seraku, Fumio Takahashi, Shinichi Tsuji. 1984.“Attractive quality

and must-be quality”. Journal of the Japanese Society for Quality Control (in Japanese) 14

(2): 39–48

Kautz, Karlheinz. 2009. Customer and User Involvement in Agile Software Development.

Agile Processes in Software Engineering and Extreme Programming, Sardinia: Springer :

168-173

Kotler, P., Armstrong, G., Saunders. J. & Wong, V. 2002. Principles of Marketing. Essex:

Pearson Edication Limited.

Leininger, M. and McFarland, M. R. 2002. The theory of culture care and the ethnonursing

research method. Transcultural nursing: Concepts, theories, research, and practice, 3, 71-98.

Lianga, Y. P. 2012. The Relationship between Consumer Product Involvement, Product

Knowledge and Impulsive Buying Behavior. Procedia-Social and Behavioral Sciences, 57,

325-330. http://dx.doi.org/ 10.1016/j.sbspro.2012.09.1193

49

Lin, C. 2002. Segmenting customer brand preference: demographic or psychographic.

Journal of product & brand management, vol.11, number 4:2002: 249-268

Lindberg – Repo, K. 2001. Customer Relationship Communication: analyzing communication

from a value generating perspective: 229-239

Luhmann, N. 2005, Förtroende- en mekanism för reduktion av social komplexitet. Riga:

Bokförlaget Daiddalos

Malmö högskola. Systemutvecklare. http://edu.mah.se/sv/Program/TGSYA (Hämtad: 2015-

10-02)

Matzler, K. & Hinterhuber, H.H. 1998. How to make product development projects more

successful by integrating Kano's model of customer satisfaction into quality function

deployment, Technovation, vol. 18, no. 1, pp. 25-38.

McNeale, R.M. 1994. Making customer satisfaction happen. Chapman & Hall, London

Microsoft. 2016. Projekttriangeln https://support.office.com/sv-se/article/Projekttriangeln-

8c892e06-d761-4d40-8e1f-17b33fdcf810 (Hämtad: 2017-05-20)

Miller, Greg. 1999. Creating Cruise Ships with an Eye on Next Generation. The Cruise Industry

News Quarterly 9: 67

Molokken-Ostvold, Kjetil. Furulund, Kristian M. 2007.The Relationship between Customer

Collaboration and Software Project Overruns. Agile Conference: 75

Muller, Matthias M. Padberg, Frank. 2003. Analyzing the cost and benefit of pair

programming. In Software Metrics Symposium. Proceedings. Ninth International, pages 166–

177. IEEE, 2003.

Netlight. 2017. About Us. https://www.netlight.com/about-us/ (Hämtad 2017-05-21)

Nuseibeh, Bashar. Easterbrook, Steve. 2000. Requirements Engineering: A Roadmap.

50

Ovaska, Päivi. Rossi, Matti. Smolander, Kari. 2005. Filtering, negotiating and shifting in the

understanding of information system requirements. Scandinavian Journal of Information

Systems. (17:1): 31-66.

Papadopoulosa, Georgios. 2014. Moving from traditional to agile software development

methodologies also on large, distributed projects. Procedia - Social and Behavioral Sciences.

Madrid: Elsevier: 455 - 463.

Parasuraman, A., Zeithmal, V. A., & Berry, L. L. 1988. A multipleitem scale for measuring

consumer perceptions of service quality. Journal of Retailing, 12-40.

Prahalad, K & Venkatram, R. 2004. Co-optioning Customer Competence. Harvard Business

Review: 81

Precisit AB. 2017. Solutions http://www.precisit.se/#/solutions (Hämtad 2017-04-05)

Project Management Institute. 2004. A guide to the project management body of knowledge

(PMBOK guide). Newtown Square, Pa, Project Management Institute.

Rouse, Margaret. TechTarget. 2015. Agile retrospective.

http://searchsoftwarequality.techtarget.com/definition/Agile-retrospective (Hämtad: 2017-04-

12)

Rouse, Margaret. TechTarget. 2005. Prototyping Model.

http://searchcio.techtarget.com/definition/Prototyping-Model (Hämtad: 2017-04-12)

Rouse, Margaret. TechTarget. 2008. Release.

http://searchsoftwarequality.techtarget.com/definition/release (Hämtad: 2017-04-12)

Schneider, B. and Bowen, D.E. 1995. Winning the Service Game, Harvard Business School

Press, Boston, MA.

Stone, M., Machtynger, L. & Woodcock, N. 2000, Customer relationship marketing: get to

know your customers and win their loyalty, 2.th edn, Kogan Page, London.

51

Svensson, P. G., & Starrin, B. 2003. Kvalitativa studier i teori och praktik. Studentlitteratur,

15-18.

Tsui, Frank. 2014. Essentials Of Software Engineering. 3. uppl. Burlington: Jones & Bartlett

Learning

Version-One. Agile development survey. https://www.versionone.com/pdf/7th-Annual-State-

of-Agile-Development-Survey.pdf (Hämtad: 2015-04-22)

Wellington J. & Szczerbinski M. 2007. Research Methods for the Social Sciences,

New York: Continuum International Publishing Group.

Wheatcraft, Lou. 2013. Why Do My Requirements Keep Changing?. Requirements Experts.

http://reqexperts.com/blog/2013/03/why-do-my-requirements-keep-changing/ (Hämtad: 2017-

04-20)

Xandermar. 2016. Agile Methodology https://www.xandermar.com/our-process/agile-

methodology (Hämtad: 2017-05-20).

Zave, P. 1997. Classification of Research Efforts in Requirements Engineering. ACM

Computing Surveys, 29(4): 315-321.

Zeithaml, V., Bitner, M.J. & Gremler, D. 2006. Services Marketing- Integrating customer

focus across the firm, 4: e upplagan, McGraw-Hill, New York: 87-89

52

9 Appendix

9.1 Bilaga 1 - Intervjuguide

1. Presentation

a. Berätta lite om dig själv.

b. Vilken position har ni?

c. Hur länge har ni varit i företaget?

d. Vilka typer av konsultuppdrag har ni haft?

2. Agila metoder

a. Använder ni någon särskild agil metod/process inom systemutveckling?

b. Vilka processer/metoder använder ni?

c. Kan du beskriva hur den agila processen ser ut?

i. Vart involveras kunden i projektet?

d. Vilket/vilka element anser ni vara viktigast i hela processen och varför?

e. Saknar ni några element i den agila metoden som berör kundinvolvering?

f. Finns det några problem en agil systemutvecklingsmetod? Vilka i så fall?

g. Är alla kunder villiga att vara tillgängliga för att jobba agilt?

3. Kravspecifikation (Krav och behov)

a. Hur sker kravinsamlingen?

i. Arbetar ni fram dem tillsammans med kunden eller ber ni kunden att

initialt leverera en kravspecifikation?

b. Upplever ni att kundens initiala förväntan ibland skiljer sig från deras faktiska

behov? På vilket sätt?

c. Ställer kunden enbart krav eller kan systemutvecklaren även ställa krav? På

vilket sätt i så fall?

d. Hur bestäms prioritering av krav och vilka faktorer spelar in?

4. Lära känna sin kund

a. Hur samlar ni in information om kunden innan ett projektet startar?

b. Hur skapar ni förtroende innan projektet startas?

5. Kunddialog (Tillgänglighet och återkoppling)

a. Hur ofta förs en dialog mellan dig och kunden?

i. Är kravspecifikationen öppna för förändring när som helst?

b. Hur ser kommunikationssättet ut? Har ni visuella möten eller möten per

telefon?

53

i. Hur ser fördelningen ut och varför?

c. Är kommunikationen regelbunden under projektet eller är den olika intensiv

under projektets gång?

d. Vilken betydelse tycker ni att kundens tillgänglighet har på projektet?

e. Hur jobbar ni med kundfeedback under projektet?

f. Hur påverkar tydliga kravspecifikationer utvecklingsarbetet?

6. Hantering av barriärer mot kund

a. Är det viktigt att kunden är kunnig inom systemutveckling för att projektet ska

lyckas? Varför i så fall?

b. Förekommer det att kunden levererar orealistiska krav? Varför?

c. Upplever ni kommunikationssvårigheter och skillnader gentemot kunder och

hur hanterar ni i sådana fall dessa? Hanterar ni olika roller (ingenjör, business

manager) på olika sätt?

d. Har ni upplevt att missförstånd har uppstått? Varför?

e. Hur skapar ni förtroende under projektet?

7. Utvärdera kundnöjdhet

a. Vilka faktorer skulle leda till att kunden inte är nöjd med slutprodukten?

b. Hur vet ni att era kunder är nöjda?

c. Hur arbetar ni med kundfeedback i slutet av projektet?