Why People Keep Surprising You
You plan a project carefully. The schedule works, the budget is approved and the sponsor is happy. Then, three weeks before launch, someone you never spoke to says: "Nobody asked us." Work stops while you go back and repair the damage.
Usually this isn't bad luck. Someone with a stake in the work was left off your list. This lesson covers the first and most important skill in stakeholder management: knowing who counts.
Step 1: Apply the Three-Part Test
A stakeholder is any individual, group or organisation that:
- Affects your project. They can approve it, block it, fund it, slow it down or shape it.
- Is affected by your project. Their work, budget, tools or routines will change.
- Believes they are affected by your project, whether or not they really are.
The major frameworks use the same idea. PMI describes a stakeholder as someone who "may affect, be affected by, or perceive itself to be affected by" a decision, activity or outcome of a project. PRINCE2 uses almost the same wording. The idea goes back to R. Edward Freeman's 1984 book Strategic Management: A Stakeholder Approach.
The third part is the one people forget. Someone who wrongly believes your project threatens their team will act on that belief. If you leave them out because "it doesn't really affect them", the resistance will still arrive. It will just come later and cost more to deal with.
Do this: For each person or group you're unsure about, ask the three questions in order. One "yes" makes them a stakeholder.
Step 2: Work Through a Realistic Example
Scenario: You're coordinating the move from paper expense claims to a new cloud expense app at a 600-person company.
Run the test on a few candidates:
- Finance Director: Affects the project (owns the budget and signs off). Stakeholder.
- Sales staff who travel weekly: Affected (they'll submit every claim in the new app). Stakeholder.
- The software vendor: Affects the project (configuration, deadlines, contract terms). Stakeholder.
- Warehouse staff who rarely claim expenses: They're barely affected. But a rumour says the app will track their mileage. They believe they're affected, so they're stakeholders.
Step 3: Sort Stakeholders into Categories
Two simple distinctions help you check whether your list is balanced. Each stakeholder gets one label from each pair.
Internal or external?
- Internal: inside your organisation. Examples: Finance Director, sales staff, IT service desk.
- External: outside it. Examples: the software vendor, the external auditors, the tax authority whose rules the app must follow.
Direct or indirect?
- Direct: they take part in the work or use what it delivers. Examples: sales staff, the vendor, the finance team processing claims.
- Indirect: they feel the effects from a distance. Examples: the auditors (they'll see records in a new format), the warehouse staff, line managers whose approval routine changes slightly.
The two pairs combine. The vendor is external and direct. The auditors are external and indirect. Sales staff are internal and direct.
Do this: If almost every name on your list is internal and direct, you have probably missed someone. Look for the external and indirect people next.
Step 4: Hunt for Hidden Stakeholders
Some stakeholders are rarely on the first draft because they aren't senior and aren't in the project team. Check for these three types every time.
- Gatekeepers. These people control access to approvals, decision-makers or resources. Examples: the information security team that must approve any new cloud app, procurement, or the executive assistant who manages the Finance Director's diary.
- Risk of leaving them out: A late security review or a contract stuck in procurement can stop launch completely, even after the sponsor has said yes.
- End users. These are the people who will actually use the output every day, as opposed to the managers who ordered it. Examples: travelling sales staff and the accounts clerks who check claims.
- Risk of leaving them out: The tool matches the specification but doesn't fit real work. Users fall back on workarounds or spreadsheets, and the benefits never arrive.
- Support teams. These teams keep the result running after go-live. Examples: the IT service desk, payroll and HR (who answer policy questions).
- Risk of leaving them out: On launch day the service desk gets dozens of calls about a system nobody trained them on. Confidence in the project drops in the first week.
Do this: Ask three questions. "Who has to approve or allow this?" "Who will use this every day?" "Who gets the phone call when it breaks?"
Template: First-Pass Stakeholder List
Copy this table and fill one row per stakeholder:
| Stakeholder | Affects / Affected / Believes affected | Internal or External | Direct or Indirect | Hidden type? (Gatekeeper / End user / Support / None) |
|---|---|---|---|---|
The next level turns this rough list into a proper stakeholder register.
Checklist
- I applied all three parts of the test, including "believes they are affected".
- My list includes at least one external stakeholder.
- My list includes indirect stakeholders, not only the project team.
- I have named the gatekeepers who must approve or allow the work.
- I have named the real end users, not just their managers.
- I have named the teams who will support the result after launch.
Key Takeaways
- A stakeholder is anyone who affects, is affected by, or believes they are affected by your project.
- What people believe drives how they behave, so people who only believe they're affected still count.
- Each stakeholder is internal or external, and also direct or indirect.
- Gatekeepers, end users and support teams are the stakeholders most often missed.
- Most surprises from people come from leaving someone out, so build the list early and with care.
For how stakeholders fit into project roles and governance more generally, see the Project Management Essentials course.