Nebojša Taušan

Research Question: How do managers address the challenges of implementing a cloud ERP system in the case company? Motivation: Numerous studies, including systematic literature reviews and empirical research (Abd Elmonem, Nasr, & Geith, 2016; Awan et al., 2021; Vukovic et al., 2025), have identified various challenges in establishing cloud ERP systems. These challenges include change management, legal and compliance issues, integration, data security, privacy, the need for skilled employees, adjustments to business processes, management efficiency, cloud vendor selection, and migration to cloud management. Many of these challenges significantly burden organizations and should be addressed by different levels of management. However, there are very few studies that explicitly focus on strategies to overcome these challenges, particularly those affecting managerial positions within organizations. Idea: The primary objective of this research is to understand and articulate how management encounters resistance concerning the four categories of managerial challenges identified in our previous study (Vukovic et al., 2025) during the establishment of cloud ERP systems. Data: Qualitative data were collected through open interviews with key managers in the organization located in the Republic of Serbia (fluid and water management industry) and by reviewing organizational documents relevant to the research topic. The data collection took place between November 2024 and March 2025. Tools: Qualitative research was conducted in the form of a single case study, using a deliberately selected organizational sample to address the research question. The collected data were subsequently analysed using thematic analysis. Findings: The study identified 14 countermeasures and grouped them according to four categories of challenges involved in establishing cloud systems. For the first category, business process adjustment, the countermeasures include pre-project planning, risk mitigation, adopting a hybrid implementation approach, and providing people support. For the second category, change management, the countermeasures are social activities, transparency, recognition and gratitude, and the selection of key users. For the third category, management efficiency, the countermeasures consist of maintaining on-site presence, improving coordination, and participating in governing bodies. For the fourth category, integration, data security, and privacy, the countermeasures are the use of technical tools, cooperation with vendors, and conducting external audits. Contribution: This study offers a real-world example of how a mid-sized entity within a large multinational company addresses the managerial challenges associated with the establishment of cloud ERP systems.

Context . Technical debt (TD) prevention allows software practitioners to apply practices to avoid potential TD items in their projects. Aims . To uncover and prioritize, from the point of view of software practitioners, the practices that could be used to avoid TD items, the relations between these practices and the causes of TD, and the practice avoidance reasons (PARs) that could explain the failure to prevent TD. Method . We analyze data collected from six replications of a global industrial family of surveys on TD, totaling 653 answers. We also conducted a follow up survey to understand the importance level of analyzed data. Results . Most practitioners indicated that TD could be prevented, revealing 89 prevention practices and 23 PARs for explaining the failure to prevent TD. The article identifies statistically significant relationships between preventive practices and certain causes of TD. Further, it prioritizes the list of practices, PARs, and relationships regarding their level of importance for TD prevention based on the opinion of software practitioners. Conclusion . This work organizes TD prevention practices and PARs in a conceptual map and the relationships between practices and causes of TD in a Sankey diagram to help the visualization of the body of knowledge reported in this study.

Context. Technical debt (TD) monitoring allows software professionals to track the evolution of debt incurred in their projects. The technical literature has listed several practices used in the software industry to monitor indebtedness. However, there is limited evidence on the use and on the reasons to avoid using these practices. Aims. This work aims to investigate, from the point of view of software practitioners, the practices used for monitoring TD items, and the practice avoidance reasons (PARs) curbing the monitoring of TD items. Method. We analyze quantitatively and qualitatively a set of 653 answers collected with a family of industrial surveys distributed in six countries. Results. Practitioners are prone to monitor TD items, revealing 46 practices for monitoring the debt and 35 PARs for explaining TD non-monitoring. Both practices and PARs are strongly associated with planning and management issues. The study also shows the relationship found among practices, PARs and types of debt and presents a conceptual map that relates practices and PARs with their categories. Conclusion. The results of this study add to a practitioners’ capability to monitor TD items by revealing the monitoring practices, PARs and their relationship with different TD types.

Context: The presence of technical debt (TD) brings risks to software projects. Managers must continuously find a cost-benefit balance between the benefits of incurring in TD and the costs of its presence in a software project. Much attention has been given to TD related to coding issues, but other types of debt can also have impactful consequences on projects. Aims: This paper seeks to elaborate on the growing need to expand TD research to other areas of software development, by analyzing six elements related to TD management, namely: causes, effects, preventive practices, reasons for non-prevention, repayment practices, and reasons for non-repayment of TD. Method: We survey and analyze, quantitatively and qualitatively, the answers of 653 software industry practitioners on TD to investigate how the previously mentioned elements are related to coding and non-coding issues of the software development process. Results: Coding issues are commonly related to the investigated elements but, indeed, they are only part of the TD Management stage. Issues related to the project planning and management, human factors, knowledge, quality, process, requirements, verification, validation, and test, design, architecture, and the organization are also common sources of TD. We organize the results in a hump diagram and specialize it considering the point of view of practitioners that have used agile, hybrid, and traditional process models in their projects. Conclusion: The hump diagram, in combination with the detailed results, provides guidance on what to expect from the presence of TD and how to react to it considering several issues of software development. The results shed light on TD management of software elements, beyond source code related artifacts.

ContextAdvances in technical debt research demonstrate the benefits of applying the financial debt metaphor to support decision-making in software development activities. Although decision-making during requirements engineering has significant consequences, the debt metaphor in requirements engineering is inadequately explored.ObjectiveWe aim to conceptualize how the debt metaphor applies to requirements engineering by organizing concepts related to practitioners’ understanding and managing of requirements engineering debt (RED).MethodWe conducted two in-depth expert interviews to identify key requirements engineering debt concepts and construct a survey instrument. We surveyed 69 practitioners worldwide regarding their perception of the concepts and developed an initial analytical theory.ResultsWe propose a RED theory that aligns key concepts from technical debt research but emphasizes the specific nature of requirements engineering. In particular, the theory consists of 23 falsifiable propositions derived from the literature, the interviews, and survey results.ConclusionsThe concepts of requirements engineering debt are perceived to be similar to their technical debt counterpart. Nevertheless, measuring and tracking requirements engineering debt are immature in practice. Our proposed theory serves as the first guide toward further research in this area.

Technical debt (TD) can be injected at any stage of software development, spreading across other phases and causing various problems. This article presents a model for conceptualizing TD causes, effects, payment practices, and reasons for payment avoidance, with a prioritization schema for technical and nontechnical roles.