To manage risk in a DH project, keep a living risk register: list each risk, score its likelihood and impact on a 1-5 scale, multiply to get a priority, assign an owner and one of four responses, and review it monthly. The risks that actually sink digital humanities projects — key-person dependency, tool abandonment, data-rights ambiguity, and post-grant infrastructure loss — are predictable and manageable once they are written down. This guide gives you the steps and the defaults.

Step 1: Build a risk register

A register is a spreadsheet, not a methodology. Five columns are enough to start: the risk, likelihood (1-5), impact (1-5), owner, and response.

ID | Risk                                   | L | I | Score | Owner    | Response
R1 | Lead developer leaves mid-project      | 3 | 5 |  15   | PI       | mitigate
R2 | Transkribus model unavailable later    | 2 | 4 |   8   | curator  | mitigate
R3 | Rights unclear on 1900s photographs    | 4 | 4 |  16   | archivist| avoid
R4 | Server funding ends with the grant     | 5 | 4 |  20   | PI       | transfer

Score = likelihood x impact. Sort descending and you have your priority list in one glance.

Step 2: Score risks with a 5x5 matrix

Rate likelihood and impact each from 1 (low) to 5 (high) and multiply. Use these defaults for what to do with the result:

Score	Band	Action
15-25	High	active response required now
5-14	Medium	monitor, plan a response
1-4	Low	accept and log

The point of numbers is not false precision — it is to force the conversation. When a historian rates rights ambiguity at impact 5 and a developer rates it at 2, the gap is the useful information.

What risks are unique to DH projects?

Generic project-risk checklists miss the ones that matter here. Watch specifically for:

• Key-person dependency — the pipeline runs only on one person's laptop. The most common and most damaging DH risk.
• Tool and platform abandonment — a free hosted service, plugin or model is deprecated. Anything you do not control is a risk you carry.
• Data-rights ambiguity — orphan works, unclear copyright on 20th-century material, or sensitive personal data in historical records.
• Post-grant collapse — the site or server has no funding once the grant ends, so the output vanishes.

Step 3: Choose a response for every risk

Assign one of four standard responses to each register entry — never leave the column blank:

1. Avoid — change the plan so the risk cannot occur (e.g. exclude the rights-unclear photographs).
2. Mitigate — reduce likelihood or impact (e.g. document the pipeline and cross-train a second person to defuse key-person risk).
3. Transfer — shift it via a contract or service (e.g. deposit the data in an institutional repository so its survival is the library's responsibility, not your server's).
4. Accept — log it and write a contingency for when it fires.

# mitigation for R1 (lead developer leaves)
- [ ] Pipeline runs from a README on a clean machine — tested monthly
- [ ] All code in shared Git repo, not a personal account
- [ ] Second team member can run the full build
- [ ] Container image pins the environment

How do you handle the biggest risk — key-person dependency?

Treat documentation and shared infrastructure as risk controls, not bureaucracy. The test is brutal and simple: if the key person did not come back tomorrow, could the project continue from what is written down and committed? Move code off personal accounts into a shared repository, pin the environment in a container, and rehearse a clean rebuild. Most key-person risk evaporates the day someone other than the author successfully reruns the pipeline.

Step 4: Review on a cadence

Risks are not static. Review the register monthly, at every milestone, and whenever scope changes. A tool you depend on can be deprecated overnight; a rights question can escalate when you decide to publish. Closing a risk that no longer applies is as valuable as adding a new one — it keeps the register trusted.

Pitfalls to avoid

• Writing the register once and never reopening it.
• Scoring everything "medium" to avoid hard conversations.
• Leaving the owner or response column blank.
• Logging only technical risks and ignoring rights, funding and people.
• Confusing a risk (might happen) with an issue (already happening) — track issues separately.

Key Takeaways

• A simple risk register reviewed monthly is the core of DH risk management.
• Score likelihood x impact on a 5x5 matrix; 15+ demands an active response now.
• The DH-specific killers are key-person dependency, tool abandonment, rights ambiguity and post-grant collapse.
• Assign every risk one of four responses: avoid, mitigate, transfer, accept.
• Defeat key-person risk by making someone other than the author rerun the pipeline successfully.
• Review at every milestone and scope change; close stale risks to keep the register trusted.

Frequently Asked Questions

What is the simplest way to start managing risk in a DH project?

Keep a single risk register spreadsheet. List each risk, score its likelihood and impact 1-5, multiply for a priority score, name an owner and a response. Reviewing it monthly is 80% of effective risk management.

What risks are unique to digital humanities projects?

Key-person dependency on a single technical contributor, tool or platform abandonment, data-rights ambiguity over historical sources, and the loss of infrastructure when grant funding ends. These rarely appear on generic project-risk lists.

How do I score a risk objectively?

Use a 5x5 matrix: rate likelihood and impact 1 (low) to 5 (high), and multiply. Scores of 15+ demand an active response now; 5-14 get monitored; under 5 are accepted and logged. The numbers force prioritisation conversations.

What is the single biggest risk in most DH projects?

Key-person dependency — the project lives in one person's head or laptop. The mitigation is documentation, shared repositories and cross-training, none of which feel urgent until that person leaves.

How often should I review the risk register?

Monthly for active projects, plus a review at every major milestone and whenever scope changes. Risks are not static; a tool you depend on can be deprecated overnight.

What are the four standard responses to a risk?

Avoid (change the plan so the risk cannot occur), mitigate (reduce its likelihood or impact), transfer (shift it via a contract or service), or accept (log it and prepare a contingency). Every risk on the register should be assigned one.

Related reading

• Designing for DH project sustainability
• Scope a digital humanities project
• DH project data handoff
• The 3-2-1 rule for archives
• A rights-clearance workflow