StakeSource: Moving Beyond Expert Intuition with Crowdsourced Stakeholder Analysis

TL;DR

Stakeholder analysis is the "Achilles' heel" of software engineering. StakeSource is an automated web-based tool that solves this by crowdsourcing stakeholder identification. By treating stakeholders as nodes in a social network and using algorithms like PageRank and Betweenness Centrality, the tool identifies overlooked participants and prioritizes them with academic rigor—turning a manual, error-prone process into a scalable, algorithmic one.

Background: The High Cost of the "Hidden" Stakeholder

Project failure is rarely a failure of code; it is almost always a failure of context. When a lead requirements engineer misses a critical stakeholder group—such as external users or regulatory bodies—the resulting product is fundamentally misaligned with reality. In large-scale systems (like the UCL RALIC project cited in the paper), the complexity exceeds any individual's mental map. The authors argue that the solution isn't "better experts," but a better "networked intelligence."

The Core Insight: Stakeholder-Sourcing

Instead of experts providing the list, they provide the seed. StakeSource uses a Snowballing Technique:

1. Seeds: Experts enter a few known stakeholders (e.g., Project Manager, Lead Dev).
2. Referrals: StakeSource automatically emails these seeds, asking them to recommend others using a standardized form.
3. Expansion: New recommendations are automatically contacted, expanding the network until it reaches a point of "role saturation" (where no new roles are discovered).

Methodology: Social Network Analysis (SNA) as a Prioritization Engine

Once the data is "sourced," StakeSource converts the recommendations into a directed graph. The nodes are people/roles, and the edges are the recommendations. This is where the paper moves from simple survey-taking into technical depth.

1. The Architecture of Influence

The tool calculates several SNA metrics to give "weight" to stakeholders:

• Betweenness Centrality: Identifies "brokers" who sit between disparate groups. These are the people you go to if you want to resolve conflicting requirements.
• PageRank: Adapted from Google’s algorithm, it identifies stakeholders who are recommended by other influential stakeholders.
• Closeness Centrality: Measures how "close" a stakeholder is to all others, indicating how quickly they can spread information or influence the project.

Figure 1: The Recommendation Interface—the data entry point for the "crowd."

2. Identifying Potential Problems

Beyond just listing names, the authors use the divergence between metrics to flag risks. For example:

• Involvement Problems: High Degree Centrality (recommended by many) but low Betweenness (not central to communication) might indicate someone who is important but over-stretched or disengaged.
• Communication Gaps: High Betweenness but low Closeness suggests a bottleneck—someone who controls information flow but is hard to reach.

Experimental Validation: The RALIC Case Study

The methodology was tested on the Replacement Access, Library and ID Card (RALIC) project at UCL.

• The Baseline: Standard checklists were used, and a major group (external library users) was completely missed.
• The StakeSource Result: The tool successfully mapped over 60 stakeholder groups. It precisely identified the "Library Systems Manager" as a key node who, in turn, pointed toward the "Membership Officer," eventually uncovering the "external library users" who were essential to the system's success.

Figure 2: The StakeSource Dashboard, showing the social network graph (C), prioritization rankings (A), and the risk sensitivity slider (B).

Critical Analysis & Conclusion

Why this matters

The shift from "Expert-Centric" to "Network-Centric" is profound. In modern Software Engineering (SE), the bottleneck is no longer compute; it is the Knowledge Acquisition Bottleneck. StakeSource provides a mathematical framework to bridge this gap.

Limitations

• Incentive Design: The tool assumes stakeholders will answer. In highly political or toxic corporate environments, stakeholders might strategically hide colleagues or misrepresent influence.
• Data Quality: "Merger" of similar roles (e.g., 'Ph.D. Student' vs. 'Research Student') still requires some manual expert cleanup, though the paper suggests autocomplete helps mitigate this.

Future Outlook

As we move into an era of AI-driven project management, tools like StakeSource could be integrated with corporate Slack or Teams data to passively map stakeholder networks without even requiring manual referrals, further reducing the friction of Requirements Engineering.

Takeaway:

If you are managing a project with more than 20 stakeholders, relying on your own memory is a recipe for failure. Trust the network; trust the algorithm.