Appearance
Managing DH project stakeholders means identifying everyone with a stake in the outcome, mapping them by power and interest, and giving each group the message they actually care about at an agreed cadence. For historians and archivists this is the difference between a project the institution champions and one that quietly loses support. The workflow is short: identify, map, plan communication, engage, and re-map as the project evolves.
Step 1: Identify every stakeholder, not just the funder
Stakeholders are anyone affected by or able to affect the project. In DH that list is wider than it first appears: the funder, the host institution or library, subject scholars, technical staff, the source community whose records you are using, and the eventual public audience. Each measures success differently. A funder wants demonstrable impact and a clean final report; a librarian wants something sustainable they will not be left maintaining; the source community wants their history handled with care. Write the full list before you do anything else.
Step 2: How do I prioritise stakeholders?
Map them on a power-interest grid. It tells you, in one diagram, how much effort each relationship deserves.
| Low interest | High interest | |
|---|---|---|
| High power | Keep satisfied (e.g. senior management) | Manage closely (e.g. funder, PI) |
| Low power | Monitor (e.g. casual public) | Keep informed (e.g. scholars, source community) |
The grid prevents two failure modes: over-reporting to people who do not care, and under-communicating with people who quietly hold a veto. Re-draw it at milestones, because positions shift — a low-interest dean becomes high-interest the moment the project hits the press.
Step 3: Build a communication plan
A communication plan is one table that answers, per group: what they care about, what message they need, who delivers it, through which channel, and how often.
text
Stakeholder | Cares about | Channel | Cadence | Owner
Funder | impact, milestones | written report | quarterly | PI
Host library | sustainability | meeting | monthly | curator
Subject scholars | scholarly accuracy | mailing list | milestone | lead scholar
Source community | respectful use | in-person/call | milestone | PI + liaison
Public audience | the story | blog/social | ongoing | commsAgreeing cadence up front matters: stakeholders fill silence with worst-case assumptions, so a predictable rhythm is itself reassurance.
Why is the source community the most overlooked stakeholder?
Because they are rarely on the money chain, source communities — the descendants and communities whose histories your records represent — get left off the stakeholder map, yet they hold the strongest moral stake. Overlooking them creates ethical and reputational risk that no funder report can repair. Engage them early, give them a named liaison and a real channel, and treat their input on how their history is represented as a requirement, not a courtesy.
Step 4: Engage, and make trade-offs visible
Good engagement is two-way. Reporting to stakeholders is the easy half; the harder half is absorbing their input without letting it silently inflate scope. When a stakeholder asks for "just one more feature", route it through a written change request that shows the cost in time and budget:
markdown
# Change request CR-07
Requested by: Head of Special Collections
Change: add a per-item provenance timeline to the public site
Impact: +3 dev weeks, +£0 budget — would slip launch by 1 month
Decision: deferred to phase 2 (PI, 2024-09-28)This converts "can you just..." into an explicit, owned decision, and protects the relationship by making the cost — not your reluctance — the reason for a no.
Step 5: Re-map as the project evolves
Stakeholder management is a loop, not a launch task. Revisit the grid and the plan at every milestone: people change roles, new funders appear, a quiet community becomes an active partner. A stakeholder map drawn once at kick-off and never updated is usually wrong by the midpoint.
A practical checklist
- List every stakeholder, including the source community and future maintainers.
- Place each on a power-interest grid.
- Write a one-table communication plan with owners and cadence.
- Give high-stake groups a named contact, not "the team".
- Route scope changes through written, costed change requests.
- Re-map at every milestone.
Key Takeaways
- Identify all stakeholders, including source communities and the people who will maintain the output later.
- Prioritise with a power-interest grid; manage closely those who are both powerful and interested.
- A one-table communication plan with owners and cadence prevents silence from breeding mistrust.
- The source community is the most overlooked stakeholder and the one with the strongest moral stake.
- Make scope-change trade-offs explicit through written, costed change requests.
- Re-map stakeholders at every milestone — positions and players shift mid-project.
Frequently Asked Questions
Who are the typical stakeholders in a digital humanities project?
Funders, the host institution or library, subject scholars, technical staff, the source community whose records you use, and the eventual public audience. Each cares about a different outcome, so each needs a different message.
How do I prioritise which stakeholders to focus on?
Map them on a power-interest grid. Manage high-power, high-interest people closely; keep high-power, low-interest people satisfied; keep informed those with high interest but low power; and monitor the rest lightly.
What is the most overlooked stakeholder in DH?
The source community — the descendants or communities whose histories the records represent. They are rarely on the funding chain but have a strong moral stake, and ignoring them creates ethical and reputational risk.
How often should I communicate with stakeholders?
Match cadence to the grid position: monthly or milestone updates for those you manage closely, lighter quarterly summaries for those you merely keep informed. Agree the cadence and channel up front so silence is not mistaken for trouble.
What goes in a stakeholder communication plan?
For each stakeholder group: what they care about, what message they need, who delivers it, through which channel, and how often. One table covers it for most projects.
How do I handle a stakeholder who keeps changing the scope?
Route every change through a written change-request and the risk/scope process, showing its cost in time and budget. Making trade-offs visible turns 'just one more thing' into an explicit, owned decision.