As a Requirements Engineer and IT Business Analyst, I explore human behavior to improve elicitation and collaboration. Erikson’s Epigenetic Principle for Stakeholder Solutions helps me understand motivation, growth, and conflict in projects. Therefore, I can address stakeholder needs with more empathy, guide discussions more clearly, and support better project outcomes.
What Is Erikson’s Epigenetic Principle?
Erik Erikson described human development as a sequence of psychosocial stages. Each stage introduces a central developmental challenge. Moreover, experiences at earlier stages can influence how a person approaches later challenges.
The epigenetic principle provides the underlying logic. Development follows an ordered process, but social relationships and experiences influence how that process unfolds.
For Requirements Engineering, I do not interpret this principle literally. A project does not develop like a person. Nor can I explain stakeholder behavior through a developmental model alone.
Instead, I use Erikson’s principle as a reminder that stakeholder behavior has a history and a context.
This distinction matters. It prevents me from turning a psychological theory into a simplistic classification system.
Why This Matters in Requirements Elicitation
Stakeholders rarely enter an elicitation session without prior experiences. They may remember failed projects, ignored requirements, difficult suppliers, unrealistic schedules, or poorly managed changes.
Consequently, two stakeholders can respond very differently to the same proposal.
For example, one stakeholder may welcome an iterative approach. Another may demand detailed specifications before approving anything. The second stakeholder may not simply be resistant to change. Previous projects may have taught that person that ambiguity creates risk.
Therefore, I try to understand the reasons behind a position before I challenge it.
A stakeholder position tells me what someone wants. The context behind that position helps me understand why.
That difference improves elicitation.
I Look Beyond the Stated Requirement
A stakeholder may say:
“We need an approval step before every change.”
I could record that statement as a requirement. However, I first investigate the underlying need.
Perhaps the stakeholder wants stronger governance. Perhaps unauthorized changes caused problems in the past. Alternatively, the stakeholder may fear losing control over an important process.
Therefore, I ask questions such as:
- What problem should the approval solve?
- What happens today without this approval?
- Who carries the risk?
- Which previous experiences influence this concern?
- Under which conditions could a lighter control work?
This approach helps me move from positions to needs.
I do not treat stakeholder statements as isolated facts. I investigate the experiences, goals, constraints, and risks behind them.
I Treat Conflict as Information
Erikson placed conflict at the center of development. In Requirements Engineering, conflict also deserves attention.
However, I do not view stakeholder conflict as something that I must immediately eliminate. Instead, I first use it as information.
A disagreement may reveal competing business goals. It may expose unclear responsibilities. Furthermore, it may identify different assumptions about risk, cost, usability, security, or quality.
For example, operations may prefer stability while product management prefers rapid change. Both positions can be rational.
Therefore, I make the conflict explicit. Then I identify the underlying interests and constraints.
Good elicitation does not hide disagreement. It turns disagreement into information that supports better decisions.
I Consider the Stakeholder’s Environment
People do not make decisions independently from their environment.
Roles, responsibilities, incentives, organizational culture, authority, team relationships, and previous decisions all influence stakeholder behavior.
Therefore, I ask not only what a stakeholder personally prefers. I also consider the system around that person.
A department manager may reject a new process because it increases operational risk. A user may resist a new interface because productivity targets leave little time for learning. A subject matter expert may insist on detailed documentation because that person carries regulatory responsibility.
In each case, the behavior becomes easier to understand when I examine the surrounding context.
As a result, I avoid simplistic labels such as “difficult stakeholder” or “resistant user.”
I try to understand behavior before I evaluate it.
I Adapt My Elicitation Approach
Once I understand the stakeholder context, I can adapt my approach.
For example, I may provide more structure to stakeholders who need predictability. Conversely, I may use prototypes when stakeholders struggle to express abstract requirements.
I may also involve several groups when conflicting perspectives affect the same requirement. Furthermore, I can use models to make assumptions visible and reduce ambiguity.
However, adaptation does not mean agreeing with every stakeholder.
I still need to challenge unsupported assumptions, identify contradictions, and protect agreed project goals.
Empathy improves Requirements Engineering when I combine it with analytical discipline.
I Avoid Psychological Classification
There is also an important limit to this approach.
I cannot infer a stakeholder’s personality, developmental history, or psychological state from a few project interactions. Moreover, Erikson’s theory does not provide a requirements elicitation technique.
Therefore, I do not classify stakeholders according to Erikson’s stages.
Instead, I extract a more general lesson: people develop through experience, and those experiences influence how they interpret new situations.
This perspective encourages curiosity without pretending that I can diagnose people.
Practical Questions I Use
When stakeholder behavior surprises me, I can ask:
- What does this stakeholder need to achieve?
- What risk does the stakeholder perceive?
- Which previous experience may influence the current position?
- Which organizational pressures affect the decision?
- Which assumptions remain unstated?
- Is the disagreement about goals, solutions, priorities, or constraints?
- What evidence could help resolve the disagreement?
- How can I adapt the elicitation method without compromising the objective?
These questions turn a psychological perspective into practical Requirements Engineering behavior.
Conclusion
Erikson’s epigenetic principle does not give me a method for specifying requirements. However, it offers a useful perspective on stakeholder interaction.
People bring previous experiences into new situations. Social environments shape their expectations. Conflicts often reveal important needs. Therefore, I gain more from stakeholder behavior when I investigate its context instead of judging it at face value.
For me, the practical lesson is simple: effective requirements elicitation requires me to understand not only what stakeholders say, but also the context that makes their statements reasonable to them.
That understanding does not replace analysis. Instead, it strengthens it. As a result, I can ask better questions, uncover deeper needs, manage disagreements more constructively, and develop requirements that reflect the real problem rather than only its most visible symptoms.
What’s Next?!
Applying psychological principles like Erikson’s can greatly improve how we understand and support stakeholders. However, I also need to understand how people organize knowledge and interpret new information. That is why I continue with How to Understand and Apply Piaget’s Schema Concept as a Requirements Engineer. Still, challenges and conflicts are inevitable. The key to lasting success lies in how I address them. Effective conflict resolution strengthens trust, collaboration, and project outcomes. Want to discover proven strategies to turn disagreements into progress? Continue reading Conflict Resolution in the Requirements Process for Project Success.
Build a Strong Starting Point in Requirements Engineering
Begin with Requirements Engineering to develop a clear overview of this essential discipline. It explains how clear requirements bring focus, support teamwork, and guide better decisions throughout a software project. As a result, you can see how requirements engineering helps turn early ideas into useful and successful software solutions.
Then read Personal Growth to strengthen the human side of requirements work. In this main article, I connect self-understanding, change, habits, discipline, decisions, stress, personality, cognition, and openness with practical stakeholder work. It also shows how personal growth improves stakeholder management, elicitation, body language, presentation, storytelling, repartee, negotiation, and effective communication. Therefore, you can grow as a person and become more effective as a requirements engineer.
Credits: Photo by RDNE Stock project from Pexels