A stakeholder is more than a name on a register
Stakeholders bring authority, knowledge, expectations, constraints and sometimes competing definitions of success. Treating every stakeholder the same creates noise; treating stakeholder engagement as an ongoing activity creates alignment.
What to learn about each stakeholder
- What outcome do they care about?
- What do they know that the project team may not?
- What decisions can they make?
- What could make them resist the change?
- What information do they need, and when?
Power is not the only dimension
A person with low formal authority can still be critical if they operate the process every day. A senior sponsor may have high authority but limited operational knowledge. The engagement plan should reflect both influence and information needs.
| Stakeholder | What they care about | Useful engagement |
|---|---|---|
| Sponsor | Business value, investment, major decisions | Decision reviews and outcome reporting |
| End user | Usability, workflow, real-world constraints | Interviews, demos, acceptance |
| Operations | Process impact, supportability | Process workshops and transition planning |
| Technical lead | Feasibility, architecture, technical risk | Solution workshops and technical reviews |
Stakeholder conflict is information
When sales wants speed, operations wants control and customers want simplicity, the conflict is not merely a communication problem. It reveals trade-offs the project needs to make explicit.
Artifact: stakeholder map
Create a simple register with stakeholder, role, influence, interest, concerns, decision rights, communication preference and engagement approach. Review it as the project changes.