Innan jag påbörjar utvärderingen tänker jag på nytt gå igenom den generella analysmodell jag beslutat att använda för att analysera ett urval av de kravhanteringsproblem identifierade i undersökningen. Modellen bygger som tidigare nämnt på en enkel struktur hämtad från skolverket och det går lätt att följa deklarerat resonemang utifrån den. I bilden nedan illu-streras stommen till modellen.
Figur 5:1: Analysmodellen (Skolverket, 2007).
Förutom bestämda kriterium som framgår av modellen kommer jag även att ge egna kom-mentarer och reflektioner i respektive sakförhållande. I metoden finns modellen grundligt förklarad men jag anser att det kan vara relevant att åter belysa ett par centrala aspekter med betydelse för hur modellen bör tolkas. I analysmodellen pekar attributet åtgärder mot både kolumnen för orsak samt konsekvens, vilket är helt korrekt. Min intention är att komma fram till en realiserbar lösning som kontrollerar helheten och inte bara framförva-rande element som skulle vara det självklara resultatet om jag istället använde en cyklisk modell. Min motiveringen är följaktligen att med hjälp av modellen finna en komplett lös-ning som inte enbart fokuserar på källan till problemet utan dessutom avser att förekomma symptomen.
De fyra mest frekvent omnämnda problemen hämtade från undersökningen kommer att analyseras utifrån angiven analysmodell. Övriga delar av analysen sker utifrån en hermeneu-tisk ansats där min förförståelse spelar en väsentlig roll för hur jag tolkar resultatet
Problem I
Att tiden är ett stort problem i kravhanteringsprocessen är påtagligt utifrån givet resultat i undersökningen. Med utgångspunkt i problemet har jag därför utvärderat tänkvärda orsa-ker, konsekvenser samt lämpliga åtgärder. Jag har således tolkat resultatet från den empiris-ka studien i relation till problemet och därtill adderat egna kommentarer i modellen som at-tribut under kategorin för åtgärder. Härnäst följer en tolkande diskussion hur jag kommit fram till deklarerat resonemang samt några reflektioner i förhållande till teoretisk referens-ram vald för uppsatsämnet. (Följande tre problem kommer att bemötas på samma sätt, d.v.s. i den typ av struktur jag tillämpar för att analysera problem I).
Samtliga respondenter uttryckte att tiden utgjorde ett kravhanteringsproblem med omfat-tande konsekvenser för fortsatt arbete. Utifrån deras resonemang förstod jag att dålig pla-nering för kravhanteringsprocessen var en utav orsakerna till detta liksom att tiden alloke-rad prioritealloke-rades andra delar av projektet. Enligt Eriksson (2007) är kravhanteringsarbetet i många fall mycket omfattande varav han i sin litteratur förespråkar ett iterativt arbetssätt. Fördelarna med att arbeta iterativt är att snabbare återkoppling kan ges och bättre överblick serveras. Utifrån Erikssons resonemang tolkar jag det som en lämplig åtgärd att arbeta ite-rativt för att kunna tidsoptimera kravhanteringsprocessen. Det iterativa arbetssättet medför nämligen också ett stöd för att driva olika aktiviteter parallellt. På fallföretaget finns verktyg för att bedriva processen iterativ dock tolkar jag det som att man inte tillämpar metodiken till fullo, här finns således mer att ge. Även Reynolds (2006) kastar i sin artikel ljus på hur ett systemutvecklingsprojekt som utvecklas iterativt har större chans att hålla bestämd tids-ram och därtill dessutom leverera funktionalitet som stämmer överrens med behovet. Niazi & Shastry (2003) omnämner i sin artikel att vi måste förstå kravhanteringsprocessen roll i systemutvecklingsprojekt för att kunna förbättra och reducera problemnivån. I
under-sökningen var det framförallt de respondenter i rollen som teknisk projektledare som belys-te betydelsen av att förstå kravhanbelys-teringsprocessens funktion. De förklarade vid flertal till-fällen hur viktigt det var att få beställaren och resterade delar av verksamheten införstådda med processens relevans och kommande betydelse för utvecklingsfasen. Hos IT-aktören kunde jag tyda en viss frustration över den begränsade förståelsen inom verksamheten. I projektgruppen skiljer sig erfarenhet och kunskap åt vilket påverkar inställningen till hur systemutvecklingsprojekt lämpligast bör drivas för ett framgångsrikt resultat. Inom IT funktionen finns enligt min uppfattning större förståelse för varför kravhanteringsproces-sen bör prioriteras mer tid. Inom verksamheten anser man emellertid också att den otill-räckliga tidsramen utgör ett stort problem men jag tolkar det inte som att denna kategori alla gånger är lika medvetna om varför det är viktigt att prioritera tid i denna fas. Olika erfa-renheter, kunskap och förståelse för systemutveckling styr alltså hur vederbörande part uppfattar problematiken i kravhanering. Alla parter är dock väl medvetna om de konse-kvenser som följer som ett resultat av problemet angivet. Det faller sig troligtvis mer natur-ligt för vederbörande att relatera till konsekvenser som är explicita och tydliga.
Sammanfattningsvis har analysen av det första problemet resulterat i följande konklusioner: • Alla respondenter är väl medvetna om tidens betydelse för en framgångsrik krav-hanteringsprocess dock upplever jag att de respondenter med teknisk bakgrund har större förståelse för varför tiden är en avgörande faktor.
• Jag anser att en iterativ arbetsform skulle gynna processen ur ett tidsperspektiv vil-ket är centralt för problemställningen.
• Slutligen tolkar jag att det krävs att hela projektgruppen arbetar efter ett homogent mönster för att komma tillrätta med upplevd problematik. Alla berörda parter mås-te förstå processens betydelse för att tillsammans kunna reducera problemnivån.
Problem II
Liksom att tiden är en karakteristisk felkälla i kravhanteringsprocessen var svarsfrekvensen från undersökningen hög vad gällde kravhanteringsproblemet en bristande kravspecifika-tion. Att kravspecifikationen i de flesta fall brister i något avseende är ingen nyhet. Det in-tressanta i undersökningen är att medvetenheten kring detta specifika problem är hög men trots det finns det en likgiltighet för dokumentet. Alla respondenter diskuterade flitigt pro-blematiken, orsaker och konsekvenser men jag uppfattade aldrig att det fanns ett direkt en-gagemang för att göra en drastisk förändring. Det framgick flertalet bra åtgärder och idéer för att komma tillrätta med problemet men återigen kände jag aldrig någon dynamik i ställ-ningstagandet. Jag tror att de flesta är väl medvetna om hur problemet påverkar kravhanter-ingsprocessen samt resultatet men man är bekväm och orkar helt enkelt inte att finna en lösning.
Som nämnt i föregående problemställning finns det sällan tid, tid att göra det som verkligen krävs för att grundligt komma tillrätta med detaljer som är avgörande för helheten, för re-sultatet. Jag tror det krävs att disciplinen i systemutvecklingsprojekt mognar och att man in-ser att allt kan inte vara gjort igår då det är komplexa uppgifter med stor osäkerhet som ska lösas. Reynolds (2006) talar i sin artikel om hur vi bör bemöta osäkerheten i kravhanter-ingsprocessen. Ofta finns inte all information tillgänglig vid en och samma tidpunkt för att beskriva ett fullständigt behov. Utmaningen är som han nämner att kunna leverera de krav
som är kända och samtidigt göra det möjligt att leverera övriga i takt med att de framträder. Jag tolkar det Reynolds föreskriver som ett lämpligt koncept för praktisk tillämpning som skulle kunna generera goda förutsättningar att förhindra att dokumentet som skapas blir ofullständigt eller irrelevant.
För att nå ett fullständigt resultat fodras att alla parter tar ett ansvar. Pozgaj, Sertic & Boban (2003) skriver i sin artikel om en metod för effektiv kravhantering som syftar till hur ansvar bör fördelas. De skriver så här; för att vi ska kunna samla och beskriva krav på ett bra sätt rekommenderas att alla medlemmar i projektteamet bör ha ansvar för uppgifter nära kopp-lade till deras kompetens. På så vis blir alla deltagare ansvariga för att samla och beskriva de krav som ligger inom deras kompetensområde Jag tolkar metoden som mycket inspireran-de och som en frisk fläkt skänker inspireran-den oss ett nytt perspektiv på hur ansvarstaganinspireran-de ska op-timeras för att generera ett bättre underlag. Att använda en best practice likt den Pozgaj, Sertic & Boban beskriver upplever jag som ett gott alternativ för att komma i ordning med bestämt problem. Det finns en viss säkerhet i att bruka best practices då andra tidigare har använt samma verktyg med god verkan.
Vidare anser jag att problemet måste lyftas till en strategisk nivå för att konsekvenserna ska få fäste och verkligen uppdagas istället för att negligeras och fösas åt sidan. Jag anser att lyf-ter man problemet och skapar nya rutiner för att hanlyf-tera kravspecifikationen finns det goda möjligheter för att lyckas. Det är såldes centralt att alla är med och skapar förändring för att förankra de nya rutinerna väl. Alla typer av förändringsarbete har en viss tendens till mot-stånd och det gäller därför att, som nämnt, först lyfta problemet och därefter skapa en gemensam vision för en önskvärt framtidsbild. En uttalad vision är ett bra hjälpmedel för att få alla engagerade för en och samma målbild. Målbilden ska vara konkret och det ska vara explicit uttryckt vad som genereras respektive vad som förkastas för att öka förståelsen och toleransen för en förändring.
Jag tror själva på att iterativ utveckling av dokumentet skapar förutsättning för ett bättre re-sultat. Att arbetat iterativ erbjuder kontinuerlig utvärdering av resultatet samt att kraven som samlas är ajour med de förväntningar och behov som finns. Därtill har det stor bety-delse att språket är anpassat efter de parter berörda av dokumentet. Det måste finnas logik i det som dokumenteras för att informationen ska kunna tillämpas optimalt. När jag genom-förde studien fanns det dem som inte omnämnde språket som ett hinder fastän det latent framgick att det var ett problem. Jag tror att det är känslosamt att erkänna att det här för-står jag inte. Genom att arbeta med ett anpassat språk kompletterat med bilder finns det möjlighet för alla parter att känna igen det som dokumenteras samtidigt som det öppnar upp möjligheter för alla att kritisk granska de krav som dokumenteras. När alla parter har förutsättning att förstå dokumentinnehållet ökar oddset för att resultatet ska stämma över-rens med de förväntningar som finns. Först då kan vi betrakta kravhanteringsprocessen som framgångsrik.
Analysen av problem två kan summeras i följande punkter:
• Jag tolkar det som att systemutvecklingsprojekt behöver mogna för kravhanterings-processen ska få utrymme att utvecklas.
• Därtill betonar jag betydelsen av ansvar för att förebygga en bristfällig kravspecifi-kation. Jag anser att Pozgaj, Sertic & Boban redogör för en tillämpningsbar metod som skänker nytt perspektiv på hur ansvartagande kan optimera processen.
• Slutligen betonar jag även nya rutiner, iterativ utveckling och ett anpassat språk för att alla parter ska kunna känna igen sig och förstå innehållet. Att skapa förändring
Problem III
I förhållande till systemutvecklingsprojekt är beställarrollen i många fall inkomplett. Det krävs andra typer av erfarenhet och kunskaper för att driva rollen optimalt tillskillnad från ordinära verksamhetsprojekt. Det är som nämnt vid ett tillfälle i undersökningen ”ett be-ställningsförfarande på detaljnivå” som krävs. Jag tolkade samtliga respondenter som väl medvetna om denna problematik och vilka orsakerna är. Även de respondenter med en tydlig beställarroll markerade på hur deras okunskap och brist på erfarenhet i förhållande till uppgiften ibland utgör ett hinder i processen. Respondenterna delade emellertid med sig av färre åsikt för de konsekvenser som problemet resulterar i. Detta tolkar jag som en sig-nal på att man ignorerar de åtgärder som finns att tillämpa och istället väljer att arbeta som man alltid gjort. Fram tills att någon ifrågasätter handlingen kommer det att fortsätta på det här sättet. Jag har förhoppningar om att lyfta detta till en relevant frågeställning för att för-hoppningsvis kunna förebygga, eller bäst av allt eliminera detta problem som enligt min mening är av relativt banal karaktär. Det handla egentligen bara om att orka arbeta på rätt sätt med rätt roll för att få till stånd en lösning.
Vidare anser jag att det är otroligt viktigt att man delar med sig av kunskap och erfarenhet inom gruppen så att alla parter kan dra nytta av den. Likaså ska tilldelad roll ske efter prin-cipen bäst lämpad för att undvika oengagemang. Med rollen ska det följa ett tydligt ansvar som sätter prägel på vad som förväntas av rollinnehavaren. Det är mycket orättvist att till-dela en roll slumpmässigt, dels för vederbörande rolltagare, dels för projektgruppen men framförallt för kunden. Att arbeta med tydliga roller skapar en bra bas för en effektiv ar-betsprocess där alla är väl medvetna om vad de förvänts bidraga med. För att ytterligare
tolka situationen av rollens betydelse kontra arbetsprocessens effektivitet har jag valt att tolka situationen utifrån FIRO-modellen. För att nå den slutliga och eftertraktade samhö-righeten krävs det att alla roller och förväntningar är glasklara för vederbörande part så att slutligen broar kan byggas mellan gruppens olika deltagare.
I undersökningen kände jag tendens till att många roller inte tillsätts utifrån de grundprin-ciper som egentligen borde styra. Det är därför viktigt att markera vilken betydelse bestäl-larrollen har i ett systemutvecklingsprojekt. Beställaren måste vara väl medveten om vilket ansvar rollen för med sig och själv avgöra om han eller hon är kapabel att fylla platsen op-timalt. God självinsikt och ett mod att våga ta eller förkasta rollen är centralt för att komma tillrätta med problemet. Rollen som beställare får inte påtvingas oavsett om rolltagaren är kapabel eller ej. Kapacitet för rollen måste gå hand i hand med vilja att agera som beställa-re, annars är konsekvenserna de samma. Som Dimberly & Burton (1999) nämner är roll-fördelningen inom gruppen betydelsefull för dess effektivitet.
Då jag tolkade respondenternas input i detta avseende tycker jag att alla delade en mogen inställning till betydelsen av beställarens roll för en framgångsrik kravhanteringsprocess men det fanns ingen märkbar benägenhet att förändra aktuell situation.
Det går att sammanfatta analysen av problem III i följande punkter:
• Beställarerollen i ett systemutvecklingsprojekt betraktar jag som inkomplett i förhål-lande till ordinära verksamhetsprojekt. Framförallt är det avsaknad av kunskap och erfarenhet som gör att jag tolkar situationen som ofullständig. Acceptansen för de-taljnivån är otillräcklig och försvårar beställarrollen i kravhanteringen.
• Jag tolkar det som att det finns en viss brist på förståelse för problemet. De flesta väljer att arbeta kvar enligt gamla rutiner istället för att se till en ny lösning.
• Det är centralt att arbeta med tydliga roller för att åstadkomma en effektiv arbets-process.
Problem IV
Att kommunikationsprocessen är en faktor av stor betydelse för kravarbetet klargjorde re-sultatet från undersökningen. Bristfällig kommunikation är ett kravhanteringsproblem som tydligt präglar processens framgång. Att kommunicera effektivt kräver mer än vad man tror. Det finns flera faktorer med stor betydelse för kommunikationsprocessens avance-mang därav bland andra valet av kommunikationskanal, omgivningen och inte minst bud-skapet i sig.
Enligt Maltén (1998) är kontextmodellen ett bra verktyg för att beskriva kommunikations-begreppet. I modellen framgår det hur budskapet pendlar mellan sändare och mottagare samt betydelsen av aspekter som kodning, avkodning, val av kanal, feedback och kontext. Jag tolkar likt Maltén att all kommunikation sker i ett sammanhang, en kontext, som har betydelse för kommunikationsprocessen. Att förstå hur omgivningen påverkar sättet vi kommunicerar på är en förutsättning för att komma tillrätta med processen.
Alla respondenter visade återigen god förståelse för problematiken och diskuterade flitigt konsekvenserna av en mindre väl fungerande kommunikationsprocess. De respondenter med större erfarenhet och kunskap av systemutveckling tolkade jag som något mer med-vetna om orsakerna till problemet. De kunde framförallt relatera till konkreta källor till-skillnad från övriga respondenter som hellre diskuterade konsekvenserna av problemet. Detta grundar sig troligtvis på skillnader i erfarenhet och kunskap men också personligt in-tresse för processen. Några i undersökningen visade ett gediget engagemang för syftet med
studien tillskillnad från andra som ”gärna ställde upp” men aldrig riktigt visade samma in-tensitet i intervjun.
Det finns som Dimberly och Burton (1999) nämner flera olika syften med att kommunice-ra. Ett av behoven vi vill tillgodose är förmågan att samarbeta. Vi kommunicerar följaktli-gen för att kunna samarbeta och det är just i samarbetet mellan människor som kommuni-kationsprocessen har sitt största behov och syfte. Teorin lyfter fram en centrala argument för att förstå innebörden i att kommunicera. Att kommunicera rätt, effektivt och målmed-vetet är en förutsättning för maximal framgång i kravhanteringsprocessen. Jag tolkar likt Maltén (1998) att i samspelet mellan människor spelar sättet vi kommunicerar på en avgö-rande roll. Fungerar kommunikationen ökar premisserna för att kravhanteringsprocessen ska fungera och resultera i det som förväntas. I och med att det är ett storartat samarbete som sker mellan olika aktörer med olika erfarenhet, kompetens och kunskap är det centralt att kunna kommunicera för att gå vidare i processen mot givet mål. Det gäller att alla är medveten om och tar ansvar för sitt budskap. Är berörd sändare dessutom medveten om att mottagaren påverkas av ytter omständigheter då den tolkar budskapet är också möjlig-heten större att sändaren tar ansvar och direkt återkopplar till att budskapet mottagits kor-rekt. För att kommunicera effektivt handlar det inte bara om att kunna föra fram ett bud-skap utan lika mycket om att lyssna effektivt. Genom att verkligen lyssna på det budbud-skap som sänds minskar risken för missförstånd betydligt. Alla parter måste vara aktiva i kom-munikationsprocessen och dessutom vara medveten om vad det är som orsakar bristfällig kommunikation.
Enligt min åsikt är förmågan att kommunicera avgörande för att nå ett gemensamt mål. Kan vi inte kommunicera kommer vi heller inte framåt i processen. Vi måste lära oss att skicka anpassade budskap, att lyssna och återkoppla för att inte fördröja avancemanget i kravhanteringsprocessen. Alla måste förstå betydelsen av effektiv kommunikation för att kunna tillämpa konceptet. När alla är medvetna är de också mottagliga på ett helt annat vis och förhoppningsvis förändringsbenägna. Det finns kanske behov av att någon förmedlar kunskapen för att alla ska få en rättfärdig chans att ta del av den och förstå hur mycket det betyder för slutresultatet att kommunikationen fungerar. Idag pratas det mycket om lärande organisationer, d.v.s. att alla ska dela kunskap med varandra för att på så vis snabbare ut-vecklas. För att lösa problemet med bristfällig kommunikation måste de som förstår hur kommunikationsprocessen fungerar dela med sig av sina kunskaper till sina arbetskamra-terna. Kontentan är att vi måste lära oss att kommunicera effektivt och det gör vi lättast genom praktisk erfarenhet. Jag tror därför också att det är centralt att efter ett projektavslut utvärdera hur kommunikationen påverkat processen för att kunna lära sig av det som hänt och på så vis förändra situationen till den bättre. Kommunikation är inget ”gripbart” fe-nomen, det handlar istället om att ta vara på erfarenheter för att vid nästa tillfället kunna förändra till det bättre.
Analysen kan sammanfattas i nedanstående punkter:
• Jag tolkar det som att det krävs mycket mer än vad vi tror för att kommunikationen ska fungera. Ofta är vi omedvetna om de faktorer som påverkar processen.
• Sättet vi kommunicerar på har stor betydelse för vår förmåga att samarbeta med andra människor.
• Att kommunicera väl handlar inte enbart om att framföra ett budskap utan lika mycket om att lyssna effektivt.