Stakeholder management is the systematic identification, assessment and involvement of all the people and groups who can influence a project or are affected by its outcome. It sounds administrative and is in practice the area where projects most often fail — not on the technology but because somebody decisive was not involved.
Who belongs in the circle
The circle is wider than the project team. It includes the client side, future users, adjacent departments whose processes will change, the operations function that must carry the result afterwards, and functions such as data protection, security, procurement and staff representation. Two groups are commonly overlooked: those who will be disadvantaged by a change, and those who formally decide nothing but shape opinion.
Classification by influence and impact
The conventional classification uses two axes: how strongly can somebody influence the project, and how strongly are they affected by the outcome? That yields four groups with different treatment. High influence and high impact requires close involvement. High influence with low impact requires information, so that resistance does not arise from ignorance. High impact with low influence requires communication and participation, because later acceptance is decided here. The rest are observed.
Silent opponents
The most dangerous constellation is not open disagreement but quiet rejection. Someone who objects can be engaged. Someone who agrees and does not contribute blocks invisibly — dates slip, input does not arrive, decisions get deferred. Recognising and naming those patterns is the actual work, and it cannot be delegated.
It is not a one-off analysis
A stakeholder analysis at project start is useful and outdated after three months. People change, priorities shift, and a group’s exposure often only becomes clear once the change becomes concrete. The analysis therefore belongs tied to fixed points — phase transitions, for instance — rather than produced once and filed.
The link to method
Formal process models provide for involvement at defined points, for example through phase approvals in which the client side confirms progress. Those points are not formalism but forced opportunities at which misunderstandings surface while they are still cheap to correct.
Practical consequence
Two questions suffice for a usable start: who could make this project fail, and who has to work with the result afterwards? The answers cover the overwhelming majority of relevant stakeholders — and they are asked explicitly surprisingly rarely.