Beyond Participation

1 Introduction

The mantra of modern change management - “turn those affected into participants” - has become a guiding principle in Requirements Engineering. Yet, this well-meaning advice can backfire when applied prematurely. In practice, involving stakeholders too early, before the organizational foundation for RE has been set up, often leads to confusion, inefficiency, and frustration. This phenomenon, which often is referred to as the “participation trap,” results in endless alignment meetings, unclear responsibilities, and a lack of tangible progress, eventually leading to frustration for everyone involved.

To avoid this trap, we should reverse the conventional sequence. Before inviting stakeholders to take part, we should first ensure that the organizational environment is ready to support their involvement. This means embedding RE into the very fabric of the organization - its structures, processes, and culture - so that it is not perceived as an alien imposition but as a natural and valuable part of how the organization works.

2 Don’t Hate the Player. Hate the Game!

To understand why organizational embedding must precede stakeholder involvement, it helps to borrow a metaphor from the world of sports. In this case specifically, football – however, pretty much every sport or even other games work, if you prefer. Imagine being asked to play a match on an unmarked, uneven field with no goals and no ball. The rules are unclear, the boundaries undefined, and the players unsure of their roles. Under such conditions, even the most enthusiastic participants would quickly become frustrated or disengaged.
This analogy captures the reality of many RE initiatives that are launched without first considering and setting up a clear organizational context. Stakeholders are invited to take part in a process that lacks structure, direction, and purpose. The result is not collaboration, but confusion and resistance.
The phrase “Don’t hate the player. Hate the game!” encapsulates this idea. Resistance from stakeholders is often misinterpreted as a personal or cultural issue, when in fact it is a systemic one. People are not the problem - the environment in which they are asked to work is. Nor can we define, control or decide people’s behavior, we can merely give them the boundaries, methods, tools and conditions, in and with which they can act. Before we can expect meaningful participation, we must first ensure that the “game” of RE is properly defined, structured, and supported.
With this in mind, we now turn to the foundational step in creating such an environment: preparing the playing field.

2.1 The Playing Field: Preparation Over Participation

Again, imagine inviting players onto a field with no boundaries, no goals, and no equipment. Chaos is inevitable. In RE, this translates to involving stakeholders before setting up clear guidelines, leading to confusion, frustration, and a lack of acceptance. Stakeholders, left without guidance, may improvise or act based on limited experience, which rarely yields best results.
To prevent this, requirements engineers must take on the role of “groundskeepers.” Their task is to prepare the playing field by defining the scope of RE activities, setting clear goals, and providing the necessary tools and infrastructure that are proper for the current context - enough to get started without closing off future options. This preparation ensures that when stakeholders are eventually invited to take part, they do so in an environment that supports meaningful and productive engagement.

It is important to note that this does not require a formalized RE process from the outset. Rather, it requires a thoughtful, context-sensitive approach that provides just enough structure to enable progress without overwhelming the organization with complexity.
For small, non-regulated teams, informal tools may suffice. In more complex, regulated environments, a professionalized approach is needed. Regardless, the principle is still: the field must be ready before play begins.
To prepare the playing field effectively, organizations can, for example, implement a “RE Readiness Checklist” before starting stakeholder involvement. This checklist might include items such as: defining the RE scope, identifying key interfaces with other departments, selecting initial tooling (e.g., a shared backlog or requirements repository), and assigning preliminary roles. This ensures that foundational elements are in place before collaboration begins.

2.2 The Rules: Clarity and Adaptability

Imagine you are playing a game, and no one knows the rules. A game without known rules inevitably devolves into frustration. In RE, this means defining, documenting, and communicating methodologies and processes so that all stakeholders work with a shared understanding.
Even the best-prepared playing field is of little use without a clear set of rules. In RE, these rules take the form of methodologies, processes, and standards that guide how requirements are elicited, documented, validated, and managed. Without them, stakeholders are left to interpret the process in their own way, leading to inconsistencies, misunderstandings, and ultimately, most likely failure.

The rules must be defined, documented, and communicated in a way that is accessible and understandable to all participants. This includes not only the “what” and “how” of RE activities but also most-importantly the “why” - the rationale behind the chosen approach. When stakeholders understand the purpose and value of the process, they are more likely to engage with it constructively.

Importantly, these rules should not be static. Just as the rules of a sport evolve over time, so too must RE methodologies adapt to changing organizational needs, technological developments, and stakeholder expectations. Continuous reflection and refinement are essential to maintaining relevance and effectiveness.

2.3 Managing Deviations: The Role of the Referee

Where there are rules, there will inevitably be rule violations. These deviations are not necessarily a sign of failure; they can be valuable indicators of deeper issues within the process. The key is to understand the reasons behind them. Was the rule misunderstood? Is it outdated or overly rigid? Or was it deliberately bent to achieve a specific goal?

Requirements engineers must function as referees - fair, consistent, and pragmatic. They must distinguish between harmful violations and constructive adaptations. Sometimes, breaking a rule is necessary to achieve a better outcome. In such cases, the violation should be acknowledged, analyzed, and, if appropriate, used as a basis for revising the rule.

This needs a mindset that values pragmatism over formalism. Not every rule is sacred, and not every deviation is a problem. What matters is the intent behind the action and its impact on the overall process.
One practical approach to managing deviations is to set up a lightweight “Deviation Log” where exceptions to the RE process are recorded along with their rationale and outcomes. This not only promotes transparency but also creates a feedback loop for continuous improvement. Over time, patterns in the log can reveal systemic issues or opportunities to refine the rules.

2.4 Leading the Game: The Importance of Expert-Driven Decision-Making

In any game, someone must lead. In RE, this leadership role falls to those with the ability and experience to make informed decisions about the process. Unfortunately, in the name of inclusivity, organizations often fall into the participation trap of treating methodological decisions as democratic processes. The result is decision-making paralysis, where the voices of the uninformed carry as much weight as those of the experts.

This is not to say that stakeholder input is unimportant. On the contrary, it is essential. But it must be looked for at the right time and in the right way. Methodological decisions should be made by those with the requisite knowledge, then communicated clearly and transparently to the broader organization. This approach ensures that the process is both effective and credible.

The goal is not to exclude people but to create a process that is robust enough to support their involvement. In conclusion, “It’s not about ignoring people forever - just long enough to build the right stage for them to perform.”

3 RE as Part of the Organizational DNA

For RE to be truly effective, it must be more than a process - it must be part of the organization’s identity. Too often, RE is treated as a compliance exercise, running parallel to development – as a shadow process - rather than being integrated with it. This leads to redundant documentation, misaligned processes, and low acceptance among stakeholders.
When RE is perceived as an external imposition, it is seen merely as overhead, generating resistance and little value. Only when RE clearly addresses a real problem does it gain legitimacy.

To avoid this, organizations must engage in what I call “meta-RE” - a process of applying RE principles to the design of the RE process itself. This involves finding the specific problems that RE is intended to solve, selecting appropriate methods and tools, and tailoring the approach to fit the organizational context.

This is not a one-size-fits-all endeavor. Every organization is different and so must be its RE approach. The key is to ensure that the process is purposeful, proportionate, and aligned with the organization’s goals and capabilities.

3.1 Meta-RE: Understanding the Problem

Before introducing any RE method, you should engage in "meta-RE" - understanding the actual problem(s) that RE is meant to solve and the specifics of the context and environment it is applied in – similar to the use case and system context analysis we apply in product development. Too often, organizations invent problems to justify elaborate RE frameworks, or they replace functioning solutions with more complex ones, leading to waste.
The guiding principles: do not fix what isn’t broken! - If existing practices already meet the needs, there is no benefit in replacing them. And RE must be expedient! - It should never be an end in itself.
A practical way to apply meta-RE is to conduct a “Problem Framing Workshop” before selecting any RE methods. In this session, cross-functional stakeholders collaboratively find the core challenges the RE process should address - such as misaligned expectations, regulatory gaps, or inconsistent documentation. Using simple tools like a problem canvas or cause-effect diagrams, the team can visualize the root issues and prioritize them. This ensures that the RE process is not just a best-practice import, but a targeted response to real organizational needs.

3.2 Tailoring RE: No One-Size-Fits-All

The RE approach cannot be standardized across all organizations. While business challenges - or problems - may seem similar, each context requires tailored solutions. Once the use cases and needs are understood, the next step is to select the proper methods and tools. A first architectural step if you will - again, just like in product development. These must interact as a coherent system - just as sodium and chlorine are dangerous alone but essential together as table salt, RE methods only provide value when they work together.
My recommendation: Don't get lost in individual details and only treat symptoms. Instead, think about your RE approach holistically, have a vision and work towards it. Don't lose sight of the big picture when it comes to specific building blocks (methods and tools). After all, it's great if we excel in individual disciplines, but that doesn't help us if the results can't be used by the others involved.
We may be able to remedy individual symptoms but not address the problem as a whole. That's why it's often better to have a bit of something as a whole, instead of one discipline that's running perfectly and the others that aren't doing anything or are only rudimentary.

3.3 The Recipe: The Right Dose at the Right Time

It is not enough to choose methods and tools; their depth and application must also be appropriate. Over-engineering leads to process fatigue and disengagement.
What I often see, similar to the previous point, is that we like to get lost in the details and, for example, define an extremely complicated and sophisticated traceability concept. This may be nice in theory, but if the requirements and artifacts are poor in terms of content, it is of relatively little use to us at first. We therefore always have to keep an eye on how much of what makes sense at what point in time and also in what order we should address the topics (for example, to lay the foundations).
In RE, as elsewhere, the dose makes the poison. Simplicity is an art: do enough to solve the problem, but not more. Focus on a minimal, purpose-driven approach; complexity can be added later if needed. And most importantly, the solution must fit the problem.

3.4 Evolution: Continuous Adaptation

As product requirements evolve, so must RE processes. Regulatory changes, shifts in product portfolios, or new customer expectations may require adjustments. Practitioners should regularly reflect on and adapt their processes, letting go of outdated practices when necessary. Because if a problem no longer exists, the solution may also become obsolete. Therefore, don't always just do more. Have the courage to leave things out. Growth in process complexity often leads to waste; have the courage to remove what is no longer needed.
If you don't do this, your approach and the effort involved will grow continuously and the amount of waste you generate will also grow. So also have the courage to let go of things that worked in the past but perhaps no longer have a reason to exist today.
To summarize, this means: Focus on a minimal, purpose-driven approach that solves real problems, avoids unnecessary complexity and evolves with product development.

4 The Awkward Dance of Initial Resistance: Navigating the Human Dimension

Even with the best preparation, resistance is inevitable. But it is not a sign of failure - it is a natural part of the change process. I like to think of it as a dance: awkward at first, but graceful with practice. The key is to approach it with patience, empathy, and structure.
You may not be an experienced dancer in general; you may be with someone you've never danced with before, you may not know the steps yet and you may not have been able to practice. What will probably happen? You'll step on each other's toes and perhaps have relatively little fun at first.
It's the same in RE. In which the resistance, like the dance, steps on your toes. But you can get into the groove and get used to each other and end up putting on a great performance.
How do we get there? Again, in four steps.

4.1 Step by Step: Building Trust

Building trust is the first step. This means starting small, celebrating early successes, and showing the value of the process. As confidence grows, so does engagement too.
If I'm simply pushed onto the dance floor without knowing the steps and I'm just told to waltz, I won't feel like it and will probably refuse to join in at first. The more confident I feel, the easier it will be for me. That's why I want to concentrate on the first steps first, not see all the figures straight away and not learn all the dances straight away, but start with one and then with the basics. And every time I succeed at something, I become more confident and have more fun with the whole thing.
What conclusions can we draw from this for the context of RE and dealing with resistance? Stakeholders do not necessarily need to understand the entire process/methodology at once. Start with the basics, celebrate small successes, and gradually build confidence. Overwhelming stakeholders with unnecessary complexity is counterproductive. Accordingly, reduce the information you give to your stakeholders to what is relevant for the specific stakeholder group. Of course, it is always good to provide a vision, and, to some extent, this is also necessary for understanding and communication. However, always make it as easy as possible for your stakeholders. Just like dancing. Start with the basic steps first and then gradually expand and improve.
Celebrate small successes to support motivation and find fellow campaigners. Don't lock yourselves away in a closet and merrily define the methodology in front of you; rather proactively communicate successes and use network effects to signal that something is progressing and that it is having an impact. Nothing has a better effect on people than success stories and you should make use of them.
A useful practice is to pilot the RE process in a small, low-risk project or team. This “sandbox” approach allows for experimentation and learning without high stakes. Early wins from such pilots can be displayed through internal case studies or short presentations, helping to build trust and momentum across the organization.

4.2 Adapting to the Partner: Reacting to Stakeholder Feedback

So far, we have practiced the steps on our own and can remember the step sequence. If a second person, a dance partner, comes into play, the whole thing becomes a little more complicated and you have to start paying attention not only to yourself but also to someone else. Suddenly the whole thing takes on a new dynamic and your steps and movements start to elicit a reaction. So, we need a certain flexibility and must adapt.
Flexibility is essential. Stakeholders must feel that their feedback is heard and valued. Feedback from implementation/application should be used to refine the approach. However, this does not mean implementing every suggestion, but it does mean creating channels for dialogue and being willing to adapt when appropriate. Value feedback as input for reflection and provide transparent responses to show appreciation and support trust.

4.3 Practice Makes Perfect: Implementing and Communication Change

Just like dancers who rehearse their steps until they move with grace and confidence, RE practitioners and stakeholders alike benefit from repeated practice. The first implementation of a new RE process may feel awkward or uncertain, but with each iteration, the organization becomes more fluent in its application. This repetition not only improves execution but also builds trust in the process. Mistakes and missteps are not failures - they are opportunities to refine the approach and adapt it to real-world conditions. Over time, what once felt unfamiliar becomes second nature, and the organization develops the resilience to sustain and evolve its RE practices.
But keep an eye on your stakeholders and make sure that there is no feeling of constant change. Otherwise, a mood of “we'll just do it however we want, they can't commit to anything” will quickly set in among the stakeholders. The art lies in the way you communicate and the support you offer in implementing your approach. Communicating changes to those who are affected will directly reduce the perceived number of changes. Communicate and make transparent why something is changing in order to make it comprehensible. And support implementation after a change has come into force.

4.4 Leading the Dance: It’s Better to be Wrong Than to Make No Decision

Every dance needs a leader. In RE someone must take responsibility for guiding the process, making decisions, and supporting momentum. Without this leadership, the process will flounder, and resistance will harden into opposition.
Because if you, as the experts, don't decide, you lose the trust of the people and they must be creative themselves, typically not with the consequence of a better result. Therefore: Don’t be afraid to make decisions!
And it's also okay to be wrong. In my opinion, it is much worse not to make a decision than to make a wrong one that seemed right at the time. Delay due to decisions not being made typically leads to enormous frustration and makes you appear insecure and indecisive as an expert. You don't have to shoot from the hip with every decision. By no means. But you should increasingly avoid creating waste by not making decisions.
In summary: Take responsibility and leadership in requirements engineering. Avoid decision vacuums and the participation trap!

5 Conclusion: Creating the Stage for Sustainable Success

Requirements Engineering is not just about gathering requirements - it is about creating the conditions in which meaningful collaboration can occur. This requires more than stakeholder involvement; it requires organizational embedding.

By preparing the playing field, defining the rules, managing deviations, and leading with ability, organizations can create a process that is not only effective but also resilient. Stakeholders will then be invited into a process that is clear, purposeful, and supportive - one in which they can take part with confidence and enthusiasm.

The central messages are clear:

• It is not about ignoring people forever-only long enough to create the right stage for participation.
• Focus on a minimal, purpose-driven approach that solves real problems, avoids unnecessary complexity, and evolves alongside product development.
• Take responsibility and leadership in Requirements Engineering. Avoid decision vacuums and the participation trap.

In short, before we ask people to play the game, we must first make sure the game is worth playing.

Added reading

• Die Partizipations-Falle intrinsify.de/video/partizipations-falle, last visited: 10 July 2025
• Agiles Systems Engineering blog.sophist.de/2022/09/13/agiles-systems-engineering-spagat-zwischen-problemloeser-und-selbstzweck, last visited: 10 July 2025
• Den Blick für das Wesentliche wahren blog.sophist.de/2022/10/21/den-blick-fuer-das-wesentliche-wahren-wertschoepfende-taetigkeiten-im-agilen-systems-engineering, last visited 10 July 2025