Identifying and analysing stakeholders

You cannot engage stakeholders you have not found, and you cannot engage them well if you do not understand what they want and how much they can influence the project. Identification and analysis are therefore the foundation of everything else in this course. They start before the project is formally approved, when the business case and charter are drafted, and they continue until closure. This lesson covers sources and techniques for identifying stakeholders, the stakeholder register, and the main analysis models: the power/interest grid and its variants, the salience model, the stakeholder cube and simple scoring.

Where to look for stakeholders

Stakeholder identification works best as a deliberate search rather than a list written from memory. Useful sources include the business case and charter, which name sponsors, customers and objectives; organization charts, which show who owns affected processes and staff; contracts and agreements, which name suppliers, partners and their obligations; lessons learned from similar projects, which often record stakeholders that earlier teams missed; regulatory requirements, which identify authorities and the evidence they expect; and the people already identified, who can be asked "Who else should we talk to?" That last question, sometimes called snowball identification, is one of the most productive techniques available.

Workshops and brainstorming with the core team and sponsor quickly produce a first list. Interviews with experienced staff add depth. For projects with public impact, a community or geographic scan, such as a map of who lives, works or operates near a site, catches groups that office-based teams overlook. Questionnaires can reach large groups, and document analysis catches formal obligations. A good starting prompt is to walk through the project life cycle and ask who is involved, consulted, affected or able to object at each stage.

The stakeholder register

The main output of identification is the stakeholder register, a living document that records who the stakeholders are and what the project knows about them. A register typically includes identification information (name or group, organization, role, contact details, relationship owner), assessment information (interests, expectations, requirements, influence, attitude, phase of most interest) and classification (category, priority, current and desired engagement). On agile projects the same information may be held in a lighter form, such as a stakeholder board or personas, but the purpose is identical.

Some register content is sensitive. A note that a director is hostile to the project, or that a union is planning a campaign, could damage relationships if it circulated widely. Keep sensitive assessments where only those who need them can see them, describe behaviour factually rather than with labels, and remember that privacy law may apply to personal information about individuals.

In Canada, personal information collected about individuals in a commercial context is governed by the Personal Information Protection and Electronic Documents Act (PIPEDA) or by substantially similar provincial laws in Quebec, Alberta and British Columbia. Public bodies follow federal or provincial public-sector privacy laws. A register that records opinions about named people is personal information, so collect only what the project needs, restrict access and retain it no longer than necessary.

The power/interest grid

The best-known analysis tool places stakeholders on a two-by-two grid by their power (ability to affect the project) and their interest (how much they care about it). Each quadrant suggests a default engagement strategy. Variants use influence instead of interest (power/influence grid), or impact (the stakeholder's ability to cause changes to planning or execution) in place of power.

The grid has limits. It is a snapshot, while power and interest change: a quiet executive becomes highly interested once the budget is threatened, and an individual end user with little power can gain a great deal by organizing colleagues or going to the media. The grid also ignores attitude: a high-power, high-interest stakeholder who is a champion needs very different handling from one who is opposed. Many teams therefore colour or label the dots by attitude, or add arrows to show where they want each stakeholder to move.

The salience model

The salience model, developed by Mitchell, Agle and Wood in 1997, classifies stakeholders by three attributes: power (the ability to impose their will), legitimacy (the appropriateness of their involvement, through contract, law, ownership or moral claim) and urgency (the time sensitivity and criticality of their claims). Stakeholders with all three attributes are definitive and demand immediate attention. Those with two attributes are expectant; those with one are latent.

The salience model is useful for large, complex stakeholder communities, especially where some groups have urgent but contested claims. It reminds project managers that legitimacy and urgency matter alongside power, and that stakeholders move between classes: a dependent group of residents becomes definitive if they win the support of a powerful authority.

The stakeholder cube and other variants

Some guidance describes a stakeholder cube, which adds a third dimension to the grid, typically attitude (supportive or resistant) or activity (active or passive), giving eight segments. Another variant, the directions of influence, classifies stakeholders as upward (senior management, the sponsor), downward (the team and specialists), outward (customers, suppliers, regulators, the public) and sideward (peers such as other project managers competing for shared resources). The directions model is a useful check that communication is planned in every direction, not just upward to the sponsor.

Simple scoring

When a project has dozens of stakeholders, a simple weighted score helps rank them. Each stakeholder is rated on a few criteria, such as power, interest and urgency, the ratings are weighted and summed, and the result is combined with attitude to highlight the stakeholders who are both important and not yet supportive. Scores are a conversation aid, not a precise measure: they help a team agree priorities and make assumptions visible.

# Prioritize stakeholders with a simple weighted score (illustrative weights)
stakeholders = {
    # name: (power, interest, urgency, attitude) each scored 1-5; attitude 1 = opposed, 5 = champion
    "Sponsor (VP Operations)": (5, 5, 3, 5),
    "Chief nursing officer":   (5, 3, 4, 2),
    "Unit managers":           (3, 5, 4, 3),
    "Nurses' union":           (4, 4, 5, 1),
    "IT security":             (4, 2, 2, 3),
    "Patients' council":       (2, 4, 2, 4),
}
w_power, w_interest, w_urgency = 0.5, 0.3, 0.2

rows = []
for name, (p, i, u, a) in stakeholders.items():
    score = w_power * p + w_interest * i + w_urgency * u
    risk = score * (6 - a)          # higher when important AND unsupportive
    rows.append((name, score, a, risk))

print(f"{'Stakeholder':26}{'Priority':>9}{'Attitude':>9}{'Risk':>7}")
for name, score, a, risk in sorted(rows, key=lambda r: -r[3]):
    print(f"{name:26}{score:9.1f}{a:9d}{risk:7.1f}")

Stakeholder                Priority Attitude   Risk
Nurses' union                   4.2        1   21.0
Chief nursing officer           4.2        2   16.8
Unit managers                   3.8        3   11.4
IT security                     3.0        3    9.0
Patients' council               2.6        4    5.2
Sponsor (VP Operations)         4.6        5    4.6

In this illustrative output, the union and the chief nursing officer rise to the top of the risk ranking because they combine high priority with low support. The sponsor has the highest priority score but low risk, because she is already a champion. That combination tells the project manager where engagement effort is most needed now.

Making analysis useful

Analysis is only worth doing if it changes what the team does. For each high-priority stakeholder, the analysis should lead to concrete answers: who owns the relationship, what the stakeholder needs to know or decide, how and how often they will be engaged, and what would move them toward greater support. Those answers feed the stakeholder engagement plan in the next lesson and the communications management plan in lesson 6.