Managing Requirements Change the Informal Way: When Saying 'No' is Not an Option

Software has always been considered as malleable. Changes to software requirements are inevitable during the development process. Despite many software engineering advances over several decades, requirements changes are a source of project risk, particularly when businesses and technologies are evolving rapidly. Although effectively managing requirements changes is a critical aspect of software engineering, conceptions of requirements change in the literature and approaches to their management in practice still seem rudimentary. The overall goal of this study is to better understand the process of requirements change management. We present findings from an exploratory case study of requirements change management in a globally distributed setting. In this context we noted a contrast with the traditional models of requirements change. In theory, change control policies and formal processes are considered as a natural strategy to deal with requirements changes. Yet we observed that “informal requirements changes” (InfRc) were pervasive and unavoidable. Our results reveal an equally ’natural’ informal change management process that is required to handle InfRc in parallel. We present a novel model of requirements change which, we argue, better represents the phenomenon and more realistically incorporates both the informal and formal types of change.

💡 Research Summary

The paper investigates how software projects handle requirements changes that occur informally, especially in globally distributed teams where traditional, formal change‑control processes often prove inadequate. While the software engineering literature has long emphasized formal change‑request documents, approval workflows, and version‑control mechanisms as the primary means of managing change, the authors argue that this “formal‑first” mindset does not reflect the realities of fast‑moving business environments and distributed development.

To explore the phenomenon, the researchers conducted an exploratory case study over 18 months in a multinational software company. Two project teams, located on different continents, were observed through semi‑structured interviews (24 in total), regular on‑site observations (twice a week), and analysis of project artefacts such as requirement specifications, change logs, and meeting minutes. Qualitative coding revealed a distinct category they label “Informal Requirements Change” (InfRc). InfRc refers to any requirement modification that bypasses the official change‑request process and emerges through informal channels—instant messaging, ad‑hoc meetings, or spontaneous conversations with customers.

The findings show that InfRc is pervasive. It appears most frequently when requirements are initially vague, when market pressure forces rapid delivery, or when high trust exists among stakeholders. Importantly, InfRc has a dual impact. On the negative side, it can increase project risk by expanding scope, delaying schedules, and reducing traceability. On the positive side, it enables swift decision‑making and rapid implementation, thereby enhancing team agility and often improving customer satisfaction. The authors also observed a “transition” mechanism: informal changes that grow beyond a certain threshold are eventually fed into the formal change‑control pipeline, receiving official approval and documentation.

Based on these observations, the authors propose a “dual‑management model” that runs formal and informal change‑management streams in parallel. The model consists of four coordinated activities: (1) detection of informal changes (e.g., monitoring chat channels or ad‑hoc meeting notes), (2) lightweight recording of key metadata (who, when, what, impact), (3) risk assessment to determine whether the change threatens project goals, and (4) selective migration of the change into the formal process when necessary. Trust‑based communication structures among team members and stakeholders are emphasized to ensure that informal decisions are still aligned with overall objectives.

The study further highlights how organizational culture, team size, technology stack, and collaboration tools shape the prevalence and handling of InfRc. Teams that enjoy high autonomy and trust tend to accept informal changes readily but may suffer from poor traceability if changes are not logged. Conversely, highly hierarchical teams resist informal changes, potentially missing market opportunities. Real‑time collaboration platforms such as Slack or Microsoft Teams amplify the speed of informal change propagation; therefore, tool configuration (channel organization, log retention policies) becomes a critical factor in managing InfRc.

In conclusion, the paper challenges the prevailing “formal‑first” paradigm and argues that modern software development—especially in globally distributed settings—requires an explicit acknowledgment of informal change flows. The proposed dual‑management model offers a pragmatic framework that allows organizations to remain flexible (“saying no is not an option”) while still controlling risk. The authors suggest future work to quantitatively evaluate the model’s impact, integrate automated detection tools, and test its applicability across different industries and project types.