Today, it is common to work with or within projects in most industries. One such business area is the IT and software industry. In this industry you work almost exclusively with projects. However, the industry is very risk-affected and a high number of projects are not completed. This is due to several different risk factors, such as inadequate communication, incompetence or lack of motivation. This study has researched the risks that project managers in the IT and software industry are experiencing and how the project managers proceed to manage these risks. The study was conducted through a qualitative interview study with a total of 8 project managers in this industry. The risks that they experience are prevalent risks related to the structure of the communication in the project, incompetence of the project managers, unmotivated project members and unclear objectives in the project. The handling of the communication risks meant that the project manager often worked out a strategy for communication with involved parties. The respondents did not reveal any specific method for managing risks associated with incompetence. Unmotivated project members were often handled by adaptation to the unmotivated party or through discussions with the specific person. Risks associated with unclear objectives were often handled by adaptation to the affected party or through overtime and more frequent communication within the project and with the customer. / Idag är det vanligt att arbeta med projekt inom de flesta branscher.  Ett sådant verksamhetsområde är IT- och mjukvarubranschen. I denna bransch är projektarbeten centrala i arbetet. Dock är den branschen väldigt riskdrabbad och en hög grad av projekten slutförs ej. Detta beror på flera olika riskfaktorer, exempelvis bristfällig kommunikation, okunskap eller motivation. Denna studie har studerat vilka risker som projektledare inom IT- och mjukvarubranschen upplever är förekommande och hur projektledarna går tillväga i syfte att hantera dessa risker. Studien har genomförts genom en kvalitativ intervjustudie med totalt 8 projektledare som är verksamma inom denna bransch. De risker som de upplever är förekommande är framförallt risker relaterade till formgivningen av kommunikationen i projektet, okunskap hos projektledare, omotiverade projektmedlemmar och otydliga målsättningar i projektet. Hanteringen av kommunikationsriskerna innebar att projektledaren ofta arbetade fram en strategi för kommunikation tillsammans med berörda parter. Någon specifik metod för hantering av risker som är kopplade till okunskap framgick inte av respondenterna. Omotiverade projektmedlemmar hanterades ofta genom anpassning till den omotiverade parten eller genom samtal med berörd part. Risker som var kopplade till otydliga målsättningar hanterades ofta genom anpassning till berörd part eller genom fler arbetade timmar och mer frekvent kommunikation inom projektet eller med kunden.

Den ökade globaliseringen av arbetsmarknaden har resulterat i att internationella projekt bedrivs i högre omfattning. Detta är särskilt vanligt inom mjukvarubranschen, där företag ofta anställer dataspecialister från andra länder för att bredda sin kompetens. Internationella projekt innebär fler kulturskillnader på arbetsplatserna. Detta kan både äventyra och berika ett projekt, beroende på hur projektdeltagarna upplever och hanterar olikheterna. I den här studien är syftet att undersöka hur projektdeltagarna i en multikulturell projektgrupp, i mjukvarubranschen, upplever de olika kulturskillnaderna. I takt med att arbetsplatserna blir mer multikulturella har det skapats ett ökat behov av att få kunskap om olika kulturer. För detta är Hofstedes kulturdimensionsteori en vanligt förekommande referensram, vilken är en grov generalisering av olika kulturer. Detta leder in på studiens andra syfte, som innebär att studera om generaliseringarna av kulturer kan användas för att förstå hur projektdeltagare upplever kulturskillnaderna i en multikulturell projektgrupp. Undersökningen har genomförts genom en kvalitativ fallstudie inom mjukvarubranschen, där två indier och två svenskar i en projektgrupp inom mjukvarubranschen har intervjuats. Projektgruppen och respondenterna har befunnit sig i Karlstad, Sverige. Empiri har relaterats främst till Hofstedes kulturdimensionsteori. Med utgångspunkt från analysen har det studerats om Hofstedes teorier kan tillämpas i syfte att få förståelse för projektdeltagarnas upplevelser av kulturskillnaderna i en projektgrupp. Studien är inriktat på multikulturella projekt och tar inte hänsyn till projekt generellt. Endast de kulturskillnader som omfattas av Hofstedes fem kulturdimensioner beaktas. Det finns en sjätte kulturdimension, men den behandlas inte i den här undersökningen. Hofstedes kulturdimensionsteori visar tydliga kontraster mellan de undersökta kulturerna, men det framgår dock att respondenternas upplevelser av kulturskillnaderna inte är lika tydliga som Hofstedes undersökning åskådliggör. Slutsatsen av detta är att så pass generella beskrivningar av kulturer inte är applicerbara på individnivå, utan passar bättre att tillämpa när stora grupper ska studeras. Under intervjuerna framgår det att de indiska respondenterna upplever att de påverkas mer av kulturskillnaderna i projektgruppen än vad de svenska respondenterna upplever att de själva gör. Projektdeltagarna upplever att kulturskillnaderna påverkar gruppen främst informellt och inte gällande det formella arbetet. Respondenterna anser inte att kulturskillnaderna påverkar gruppen i någon större utsträckning, vilket troligtvis kan bero på att det finns en viss förkunskap och erfarenhet av varandras och andras kulturer, det vill säga kulturell intelligens. En annan bidragande faktor kan vara att de indiska respondenterna verkar ha en förmåga att anpassa sig till den svenska kulturen och arbetssättet. För vidare forskning skulle det vara intressant att studera hur kulturskillnaderna i en projektgrupp påverkar projektdeltagarnas samarbete. För att studera påverkan istället för upplevelser, skulle studien troligtvis behöva vara mer omfattande, såsom ett större antal respondenter under en längre tidsperiod. / The labor market has become more globalized, which has resulted in an increase of international projects. This is especially common in the software industry, where companies often hire computer specialists from other countries, to broaden the organizations’ expertise. International projects mean more cultural differences at workplaces. This can both disadvantage and enrich a project, depending on how the project participants perceive and handle the differences. The intention for this study is to explore how the project participants in a multicultural project, in the software industry, experience the cultural differences. As the workplaces become more multicultural, there is an increased need for knowledge about different cultures. For this, Hofstede’s cultural dimensions theory is a frequently used reference, which is a broad generalization of different cultures. This leads to the second aim for this study, which is to examine if generalizations of cultures can be used to understand how project participants perceive cultural differences in a multicultural project. The study was conducted through a qualitative case study in the software industry, where two Indians and two Swedes in a project were interviewed. The project team and the respondents are placed in Karlstad, Sweden. Empirical data has been related mainly to Hofstede’s cultural dimensions theory. In the analysis it has been studied if Hofstede’s theories are suitable to use for understanding the project participants' perceptions of the cultural differences in a project. The study is focusing on multicultural projects and does not considering projects in general. Only those cultural differences covered by Hofstede’s five cultural dimensions have been taken into account. There is a sixth dimension in Hofstede’s theory, but this one has not been considered in this study. Hofstede’s cultural dimension theory is showing obvious contrasts between the studied cultures, but it appears though that the respondents' perceptions of cultural differences are not as clear as in Hofstede’s study. The conclusion is that general descriptions of cultures are not applicable on individuals, but are suitable for studying large groups. During the interviews, it appears that the Indian respondents consider that they are more affected by cultural differences in the project, than the Swedish respondents do. The project participants perceive that cultural differences affect the group mostly informal and not concerning the formal work. The respondents do not believe cultural differences affect the group in any significant way, which is probably due to that there is some prior knowledge and experience of each other and other cultures, namely cultural intelligence. Another contributing factor could be the Indian respondents’ ability of adapting to Swedish culture and its way of working. For further research it would be interesting to study how cultural differences in a project influence the project participants' cooperation. To study the influence rather than the perceiving, the study would probably have to be more substantial, such as a greater number of respondents for an extended period of time.

I det teknikväxande samhället bidrar mjukvaruutveckling till stora it-relaterade utgifter och investeringar. Industrier utvecklar stödjande programvara för sin produktion och mjukvaruföretag levererar digitala system för kunder som behöver uppfylla ett behov. Utvecklingsteamen jobbar under press för att leverera så bra programvara som möjligt och samtidigt hålla sig inom budgetramar som satts upp enligt avtal. För att nå sina mål kan utvecklare introducera teknisk skuld i systemen, dvs. att bristfälliga lösningar byggs före kvalitetslösningar. Teknisk skuld behöver inte vara ett problem för stunden men på sikt kan konsekvenserna av skulderna bli problematiska och kräva resurser att kunna hanteras. Tidigare forskning visar att drygt en fjärdedel av en utvecklares tid går åt för att hantera teknisk skuld. Vid åtgärdande av teknisk skuld brukar refaktorisering vara ett vanligt verktyg att ta till, vilket innebär att skriva om källkod utan att förändra det visuella beteendet för användaren. Syftet med följande uppsats är att undersöka olika branscher som utvecklar mjukvaraoch deras hantering av teknisk skuld genom att belysa vilka faktorer som avgör om och när refaktorisering skall ske, och hur argumentationerna för refaktorisering skiljer sig åt mellan branscherna. Uppsatsen baseras på kvalitativa intervjuer med aktörer från både industri- och mjukvaruföretag. Empirin från intervjuerna analyseras med hjälp av en ontologisk mappning kring typer av teknisk skuld, som sedan har applicerats i ramverket Technical Debt Quadrant. Resultatet visar att industribranschens avgörande faktorer för refaktorisering var konsekvensen av skuldens påverkan samt hur pass förändringsbenägen den skuldbelagda funktionaliteten var. Branschen ansåg att tidpunkten för att refaktoriseravar bäst lämpad i samband med vidareutveckling av en funktion som innehöll teknisk skuld. I konstrast visade resultatet för mjukvarubranschen att faktorerna för refaktorisering var konsekvensen av skuldens påverkan samt vilka ekonomiska förutsättningar som fanns för projektet. Tidpunkten för när refaktorsering var lämplig avgörs när företagen anser att avkastningen för investeringen att refaktorisera är som högst eller när inget annat val finns. Resultatet visar även att branscherna hade olika fokus för hur de argumenterar för refaktorisering. Industrin argumenterade mer med systemet i fokus, hur det kundeförändras med tiden och att det skulle bli lätthanterligt att underhålla med tiden. Mjukvarubranschen hade mer ekonomiska aspekter som argument, dvs. att de analyserade situationen och beslutade huruvida refaktoriseringen är lönsam eller inte. / In the technology-growing society, software development contributes to large itrelated expenditures and investments. Industrial companies develop supporting software for its production and software companies deliver digital systems for customers to satisfy a need. The development teams work under pressure to deliver as good software as possible and at the same time stay within budget frameworks according to agreements. To achieve their goals technical debt in systems can be introduced, which means that deficient solutions are built before quality solutions. Technical debt does not have to be a problem at first, but in the long run the consequences of the debts can become problematic and require resources to be managed. When fixing technical debt, refactorization is a common tool to resort to, which means to rewrite source code without changing the visual behaviour to the user. Previous research shows that just over a quarter of a developer's time is spent managing technical debt. The purpose of the thesis is to examine different industries that develop software and their management of technical debt by highlighting which factors determine if and when refactoring should take place, and how the arguing for refactorization differentiate between the industries. The thesis is based on qualitative interviews with actors from both industrial and software companies. The empirical data from the interviews are analysed with the help of an ontological mapping around types of technical debt, and later applied in the framework Technical Debt Quadrant. The results show that the industry companies' decisive factors for refactorization were the consequence of the debt's impact and how prone to change the indebtedness functionality was. The industry considered that the time to refactorize was best suited in connection with the further development of a function that contains technical debt. In contrast, for the software companies the results showed that the factors for refactorization were the consequences of the debt's impact and what financial prerequisites there were for the project. Appropriate timing for refactoring wasdetermined when the companies consider that the return on the investment to refactorize is at its highest or when there is no other choice. The results also show that the industries had different focus on how they argue for refactorization. The industry argued more with the system in focus, how it could change over time and that it should be easy to maintain while the software industry had more economic aspects as an argument, ie. that they analyzed the situation and made choices whether the refactorization is profitable or not.