Functions Represented
10
Different mandates touching many of the same external relationships
Strategy
The coordination problem underneath a fragmented approach to external relationships.
The Mandate
One Relationship. Many Parts of the Organization.
The organization interacted with many of the same external stakeholders through different functions. Legal, Finance, Compliance, Corporate Affairs, Community Relations, Education, Public Relations, and other teams approached those relationships through different mandates.
Each department maintained its own records, context, priorities, and history.
What they lacked was a shared view of the relationship.
Ten functions did not have ten separate stakeholder management problems. They had one shared coordination problem fragmented across ten functions.
One function could plan outreach without knowing another had recently contacted the same person. Relevant context could remain inside one department while another team needed it. Opportunities to coordinate activity or combine efforts depended on people discovering one another’s plans manually.
The mandate was therefore larger than replacing spreadsheets. The organization needed a shared way to understand who it was engaging, what had already happened, what was planned next, and where different functions could coordinate.
Execution
How ten different ways of working became a shared set of requirements.
Functions Represented
Ten Functions. Ten Views of the Same Problem.
Discovery
Requirements in Practice
Ten internal stakeholders representing different functions participated in discovery. Each viewed stakeholder management through a different operational lens: what information mattered, which activities needed tracking, where coordination broke down, and what would make the work easier.
Interviews identified common needs and requirements unique to particular functions. The team compiled, classified, and translated the findings into evaluation criteria. The result was a shared definition of what the organization needed before making a technology decision.
The Evaluation Sequence
Stakeholder Discovery
Interviewed ten representatives to understand how each function managed external relationships and where coordination failed.
Requirements Synthesis
Consolidated shared needs, functional differences, information requirements, workflow expectations, and usability priorities.
Market Scan
Identified potential platforms and interviewed vendors against the organization’s operating requirements.
Usability Evaluation
Assessed the top three platforms across approximately 50 usability variables, including navigation, workflow completion, interaction clarity, and ease of use.
Decision Support
Combined requirement fit, usability evidence, vendor capabilities, implementation considerations, and cost into a final recommendation.
The Project Team
Product OwnerBusiness ArchitectBusiness AnalystProduct Design and User Experience10 Functional Stakeholders
Divergence
Why replacing spreadsheets alone would preserve the underlying coordination problem.
The Reveal
The Spreadsheet Was Not
the Problem.
Fragmentation Was.
Spreadsheets were the visible limitation. Replacing them alone would preserve the underlying coordination problem.
The work required information to move across functional boundaries. A better standalone tool for each department would preserve the same fragmented relationship model inside newer technology.
The requirement extended beyond better recordkeeping. It was shared organizational visibility.
The Coordination Gap
Required Work and Reality
| The Work Required | Existing Condition |
|---|---|
| Shared stakeholder visibility | Records held within departments |
| Coordinated outreach | Activity planned independently |
| Relationship history | Information fragmented by function |
| Planning across functions | Limited awareness of other teams |
| Reusable organizational knowledge | Context dependent on who knew whom |
| Business impact visibility | No consolidated view across functions |
From Requirements to Market
Build or Buy Became an Evidence Question
Feature volume no longer defined the strongest option. The decision centered on which platform best supported the operating model described by the stakeholders. The team assessed each candidate through four lenses.
Four Decision Lenses
Requirement Fit
Could different functions accomplish the work they needed to perform?
Usability
Could people with different workflows and levels of technical comfort use the platform effectively?
Shared Visibility
Could relevant relationship activity and history cross departmental boundaries?
Economics
Did the capability justify the software and implementation cost?
The Evaluation Standard
The Strongest Platform Balanced the Whole
The strongest platform balanced organizational fit, usability, shared visibility, and economics. A longer feature list could not determine the decision.
Stakes
How functional fit, usability, and economics shaped the final platform decision.
The Decision
Choosing the Best Fit
at Lower Cost
The final decision balanced what the organization needed against usability and cost. The alternatives included an SAP platform.
Annual Cost Difference
$200KLower annual software cost than the SAP alternative
The selected platform cost approximately $200,000 less per year than the SAP alternative while more closely matching requirements identified through stakeholder discovery and usability evaluation.
Evidence Discipline
Adoption Risk | Evaluated Early
Direct user involvement and structured usability evaluation reduced reliance on assumptions about how people would use the platform.
Coordination Capacity | Designed Into Requirements
Shared visibility across departmental activity became an explicit selection criterion.
Information Reuse | Enabled by the Selected Model
Relationship history and organizational context could become available beyond the department originally capturing it.
Custom Build Risk | Avoided Through Market Validation
The organization tested existing products against actual requirements before committing to custom development.
Insight
The structural finding behind a successful technology decision across functions.
The Structural Finding
The Organization Had
Relationships. It Did Not
Have Relationship Memory.
Each department knew its own interactions. The organization lacked a shared institutional picture of those relationships.
Teams could hold pieces of the same external relationship without readily seeing who had engaged whom, what had happened, what was planned next, or where another function held useful context.
The organization had information. The information stopped at functional boundaries.
Shared stakeholder management changed the intended unit of visibility from “What is my department doing?” to “What does the organization know, and what is the organization planning to do?”
The Leadership Finding
The Operating Problem Came Before the Technology
The software decision succeeded because the organization defined the operating problem before choosing the technology.
Frontline requirements established what the work demanded. Synthesis across functions identified what needed to be shared. Structured evaluation tested whether candidate platforms could support it. Economic comparison distinguished among platforms capable of meeting the need.
Alignment came first and created the criteria for choosing the right technology.
The problem looked like outdated tooling. Underneath it was fragmented organizational memory.